Blob base fee bounded by execution cost

Abstract

This EIP imposes that the total price of the targeted number of blobs TARGET_BLOB_GAS_PER_BLOCK * base_fee_per_blob_gas stays above the price of a simple blob-carrying transaction TX_BASE_COST * base_fee_per_gas. This ensures that the blob fee auction can function properly, because equilibrium always forms relative to the fee that carries the price signal. The proposed if statement in calc_excess_blob_gas() represents a neutral, simple, and future-proof resolution to current blob fee auction idiosyncrasies.

Motivation

Ethereum deploys a dynamic pricing auction to set the blob base fee, lowering the fee if less gas is consumed than TARGET_BLOB_GAS_PER_BLOCK and raising the fee if more gas is consumed. Such an auction can function well when the blob base fee represents the price signal, allowing the mechanism to control the real price facing the consumer. However, when the cost of a simple transaction carrying the blobs is higher than the total cost of buying the targeted number of blobs per block, the price signal is lost. The blob base fee no longer represents the actual cost facing the consumer, and the protocol cannot adjust the blob base fee to regulate the equilibrium quantity of blobs consumed. The current mechanism can therefore end up repeatedly lowering the blob base fee until it eventually settles at 1 wei. A change in the blob base fee of 10% may under such circumstances shift the total cost of utilizing blobspace by just 0.0000001%. Whenever demand picks up, over an hour of near-full blocks is required to restore a market-clearing equilibrium fee, with the mechanism intermittently resorting to a first-price auction, considered a worse UX by blob consumers. The resulting spikiness in resource consumption is suboptimal for scaling blobspace.

Figure 1 shows how execution costs make the demand curve inelastic, such that a small shift in demand or execution base fee (arrows) can lead to dramatic shifts in the equilibrium blob base fee. To alleviate this, the proposal imposes that the equilibrium (squares) must form somewhere along the edge of the upper-left quadrant, bounded by the supply curve (blue) and the parity line (dashed). Along this parity line, the total cost of buying several (target) blobs equals the cost of a simple transaction. The blob base fee will therefore always be updated relative to the price signal, thus alleviating spikiness while remaining neutral and future-proof. To achieve this, a simple if statement is added to the excess gas update function.

Figure 1. The demand for blobspace under different execution base fees (black to red lines). When execution cost dominates, the demand curve becomes inelastic and parallel to the supply curve, leading the equilibrium fee to change dramatically even with small shifts in the demand curve (arrows). The proposal imposes that the equilibrium (square) forms on the edges of the upper-left quadrant, at the intersection between the target supply curve and demand or along the line where the cost of target blobs equals the cost of a simple transaction.

Specification

The function calc_excess_blob_gas() from EIP-4844 is changed to add parent.blob_gas_used // 3 and not subtract TARGET_BLOB_GAS_PER_BLOCK when updating the excess_blob_gas, if the price of TARGET_BLOB_GAS_PER_BLOCK is below the price of TX_BASE_COST.

def calc_excess_blob_gas(parent: Header) -> int:
    if parent.excess_blob_gas + parent.blob_gas_used < TARGET_BLOB_GAS_PER_BLOCK:
        return 0

    if TX_BASE_COST * parent.base_fee_per_gas > TARGET_BLOB_GAS_PER_BLOCK * get_base_fee_per_blob_gas(parent):
        return parent.excess_blob_gas + parent.blob_gas_used // 3
    else:
        return parent.excess_blob_gas + parent.blob_gas_used - TARGET_BLOB_GAS_PER_BLOCK

Rationale

Fee-inelasticity

This proposal alleviates idiosyncrasies in the blob base fee auction. The fee update mechanism is unaware of the full price of the goods that it regulates the price for and therefore fails to converge on equilibrium in a timely manner. To resolve this, the fee update should be made aware of the price of execution gas. A relatively high cost of execution gas renders changes to the blob base fee less effective in controlling quantity demanded—it is ultimately the execution cost that determines equilibrium formation. Given that the protocol stipulates a long-run perfectly inelastic supply curve (vertical blue line in Figure 1), the blob base fee will simply fall to the boundary of 1 wei whenever the execution cost is too high for consumers to achieve equilibrium formation at TARGET_BLOB_GAS_PER_BLOCK. Thus, in the regime where execution fees dominate, the demand curve is blob fee-inelastic, and whenever the blob fees dominate, the demand curve is execution fee-inelastic. Figure 1 maps the quantity of blobs demanded $Q$ to the blob base fee $f_b$ and the execution cost $c_\text{tx}$:

$$ Q(f_b + c_\text{tx}). $$

The execution cost $c_\text{tx}$ is expressed "per blob gas" to match $f_b$, which is a fee taken out per blob gas. Thus, $c_\text{tx}$ is computed as:

c_tx = TX_BASE_COST * base_fee_per_gas / (GAS_PER_BLOB * N)

Here, N is the number of blobs over which the consumer can amortize its execution cost (set to the target in this proposal). The auction adjusts $f_b$ to achieve a desirable $Q$ at equilibrium. However, if $c_\text{tx}>0$, every demand curve will have an "inelasticity horizon" (see Figure 1), beyond which further reductions in $f_b$ cannot increase $Q$, rendering such fee reductions redundant:

$$ \lim_{f_b \to 0} Q(f_b + c_{\mathrm{tx}}) = Q(c_{\mathrm{tx}}). $$

This proposal ensures that the auction stops reducing $f_b$ before reaching this horizon, specifically at $f_b = c_\text{tx}$. The blob base fee will therefore always be updated relative to the price signal, alleviating spikiness in resource consumption. When the price signal comes from the execution fee, equilibrium forms along the fee parity line in Figure 1, and when the price signal comes from the blob fee, the equilibrium forms along the supply curve.

The demand curve could potentially be somewhat inelastic even under zero execution costs. This would however just be another reason to move forward with this proposal. Regardless of the exact shape of the demand curve—which of course will remain unknown and can vary going forward—the proposal is based on something tangible affecting blob consumers. This makes it a justified neutral bound on the blob base fee.

Designing for the future

Figure 2 once again shows the permitted (green) and restricted (red) regions also captured in Figure 1, but this time with execution base fee on the x-axis. Various settings for fee parity are indicated by black lines. As indicated, the blob base fee would initially have a fee parity threshold approximately 40 times below the execution base fee. Thus, if the execution base fee is 4 gwei, the blob base is bounded at 0.1 gwei, and will not be reduced below this bound during the fee update.

If blob consumers can include many more blobs in their blob-carrying transactions, the execution gas may no longer be as relevant at the same blob base fee, and the blob base fee should be able to settle relatively lower. Therefore, the proposed mechanism adjusts to the number of blobs posted per block. To understand why potential future blob scaling is important to account for when designing the mechanism, consider how the price of storing a fixed amount of data has fallen over the last 80 years. Technological progress generally brings down the unit cost of data services, as observed in many areas following Nielsen’s law and Moore’s law.

In the case of Ethereum's DA services, there is also a specific reflexivity that is important to understand. Aggregate ETH-denominated income from DA affects the fiat-denominated value of the ETH token, reflexively bounding the possible long-run ETH-denominated income, thus bounding the per-unit price of blobs. In essence, when selling more blobs at the same ETH-denominated price, the ETH token becomes more valuable, because the income per token rises. The ETH token price then increases, increasing the fiat-denominated blob costs facing the consumer, pushing down demand at the same blob base fee, thus pushing down the blob base fee under equilibrium.

For this reason, fixed thresholds not relating to blob quantity or the execution fee may not be sustainable. In a scenario where Ethereum sells more blobs per block, the equilibrium blob base fee should ideally have a relatively lower floor. A fixed threshold would thus need to be gradually readjusted to retain the same relative impact.

Figure 2. Proposed restriction imposed on the blob base fee to ensure desirable equilibrium formation. When the blob fee is the primary price signal (green area), equilibrium can form just as today. When the execution fee is the primary price signal (red area), the demand curve becomes too inelastic, and the blob base fee is imposed to rise to the green area, at a pace determined by how many blobs actually get posted. Black lines indicate fee parity between blob data cost and execution costs.

Delayed response during a quick rise in execution fees

When the if statement concludes that Ethereum operates in the execution-fee-led pricing regime, the blob base fee rises in accordance with blob_gas_used // 3, without subtracting TARGET_BLOB_GAS_PER_BLOCK. This is an intuitive way to return to the blob-fee-led pricing regime, retaining the same maximum fee increase while not allowing for a decrease. If the execution base fee rises quickly, there may be a few blocks before the blob base fee catches up (during which TARGET_BLOB_GAS_PER_BLOCK will never be subtracted and the blob fee moves in the direction of the arrows in Figure 2). This is arguably not an issue, and the smooth response in the blob base fee under these circumstances may even be seen as a benefit.

Empirical analysis

Figures 3-4 show price evolution over three weeks in November 2024, when the average execution base fee was around 16 gwei, as well as in March 2025, when the average was around 1.3 gwei. Thresholding of EIP-7762 (blue) and EIP-7918 (green) is applied directly to the original data, without accounting for its potential effect on the equilibrium fee. The equilibrium blob base fee would in reality rise from the threshold level once demand at this fee is above target supply. A target of 6 blobs was used as the amortization factor. As evident, the floor in EIP-7918 becomes higher than the floor in EIP-7762 when execution gas is more expensive, and lower when execution gas is cheaper.

Figure 3. Blob base fee evolution with the current fee market (black), with EIP-7762 (blue), and with EIP-7918 (green), during three weeks of November 2024 when the average execution base fee was around 16 gwei. Thresholding is applied directly to the original data, without accounting for its effect on the equilibrium fee.

Figure 4. Blob base fee evolution with the current fee market (black), with EIP-7762 (blue), and with EIP-7918 (green), during three weeks of March 2025 when the average execution base fee was around 1.3 gwei. Thresholding is applied directly to the original data, without accounting for its effect on the equilibrium fee.

Figure 5 shows histograms for the four-month period from the start of Figure 3 to the end of Figure 4, corresponding to approximately 900k blocks beginning at block number 22075724. The histograms employ 100 log-spaced bins per decade (factor-of-ten increase), which are smoothed using a Hanning window of width 41 with mirror-reflected edges. The threshold set by EIP-7918 (green) can operate both below or above the threshold set by EIP-7762 (blue), depending on the cost of execution gas.

Figure 5. Histogram of the blob base fee when applying EIP-7762 (blue) or EIP-7918 (green), with light smoothing applied. A four-month period from November 2024 through March 2025 was analyzed. Thresholding is applied directly to the original data, without accounting for its effect on the equilibrium fee.

Alternative specifications

One potential feature in EIP-7594 is a cap on the number of blobs referenced in each blob-carrying transaction, here referred to as MAX_BLOBS_PER_TX. No final decision has yet been made on this feature. Such a cap would fit with the rationale of the EIP. It could be used as a more direct measure than TARGET_BLOB_GAS_PER_BLOCK in the if statement:

...
if TX_BASE_COST * parent.base_fee_per_gas > MAX_BLOBS_PER_TX * GAS_PER_BLOB * get_base_fee_per_blob_gas(parent):
    return parent.excess_blob_gas + parent.blob_gas_used // 3
...

As Ethereum scales, the number of blobs submitted in the average blob-carrying transaction, as a proportion of the BLOBS_PER_BLOCK_TARGET, will fall. Similarly, the number of blocks where BLOBS_PER_BLOCK_TARGET is submitted in a single blob-carrying transaction will also fall. The mechanism can be designed to account for this. A natural idea is to impose fee parity between execution costs and the square root of the target number of blobs. If the target is 49 blobs per block, then fee parity is set to the cost of 7 blobs, etc. This means that the if statement would be altered by replacing TARGET_BLOB_GAS_PER_BLOCK with integer_squareroot(BLOBS_PER_BLOCK_TARGET * GAS_PER_BLOB**2). Note that if blob-carrying transactions become restricted from including BLOBS_PER_BLOCK_TARGET, this should be accounted for.

Two other alternative variants will now be outlined. In the first, the fee-parity comparison is instead made on the current block's base fees, as derived from the parent block. The computation for the execution base fee is omitted and the variable instead provided as input. This would also require a change to the block validity assert statement (omitted here).

def calc_excess_blob_gas(parent: Header, updated_base_fee_per_gas: (int)) -> int:
    if parent.excess_blob_gas + parent.blob_gas_used < TARGET_BLOB_GAS_PER_BLOCK:
        return 0
    
    # Compute the updated excess_blob_gas and the fee from the parent block as normal
    ret = parent.excess_blob_gas + parent.blob_gas_used - TARGET_BLOB_GAS_PER_BLOCK 
    blob_base_fee_per_gas = fake_exponential(MIN_BASE_FEE_PER_BLOB_GAS, ret, BLOB_BASE_FEE_UPDATE_FRACTION)

    # If the updated execution fee is higher, do not subtract TARGET_BLOB_GAS_PER_BLOCK
    if TX_BASE_COST * updated_base_fee_per_gas > blob_base_fee_per_gas:
        return parent.excess_blob_gas + parent.blob_gas_used // 3
    else:
        return ret

Finally, the last function can be altered to strictly keep the blob base fee above fee parity. This would require the implementation of a fake_log()that inverts the fake_exponential().

def calc_excess_blob_gas(parent: Header, updated_base_fee_per_gas: (int)) -> int:
    ...
    # If the updated execution fee is higher, return the associated excess_blob_gas
    if TX_BASE_COST * updated_base_fee_per_gas > blob_base_fee_per_gas:
        return fake_log(MIN_BASE_FEE_PER_BLOB_GAS, TX_BASE_COST * current_base_fee_per_gas, BLOB_BASE_FEE_UPDATE_FRACTION)
    else:
        return ret

Neither of these two alternatives would likely have a material impact on equilibrium formation.

Security Considerations

The blob base fee will settle at a level where posting the target number of blobs costs at least as much as its blob-carrying transaction. To the best of the author's knowledge, there are no security risks associated with this.

Copyright

Copyright and related rights waived via CC0.