EIP-7918 Introduce an execution cost floor for blob fees (Blob base fee bounded by execution cost)
Final · Fees & gas · EIP status Final · created 2025-03-25
Sets a minimum price so that the price of one blob never falls below the price of a fixed amount of execution gas. This prevents the blob fee from falling to 1 wei and losing its price adjustment function.
Why it is needed
The blob base fee adjusts automatically: it rises when usage is above target and falls when it is below. However, when the blob fee becomes a very small share of the total cost a rollup pays, this adjustment stops working. A 10% cut in the blob fee can move the total cost by only 0.0000001%, so the fee keeps falling and ends up stuck at 1 wei, the smallest unit of ether. If demand returns in this state, nearly full blocks have to continue for over an hour before the price recovers its equilibrium. In the meantime users are pushed into first-come bidding competition and the experience gets worse. Swings in resource usage also get in the way of scaling blob space. In addition, nodes perform KZG proof verification, an expensive cryptographic check, for every blob, and at a 1 wei fee blob users barely pay for that computation.
What changes
Today
- When demand is low, the blob base fee falls to 1 wei, and at that level adjusting the fee does not change how demand responds
- When demand returns, nearly full blocks must continue for over an hour before the market price recovers
- Blob users barely pay for the cost of the KZG proof verification that nodes perform for every blob
After EIP-7918
- The price of one blob never falls below the price of 8192 execution gas (BLOB_BASE_COST)
- Fees start from a meaningful level, so the price adjustment mechanism reacts in time to changes in demand
- Blob users always pay a set share of the market price of the computation they require from nodes
Who is affected
- Rollups (L2): The blob price floor is tied to the execution base fee. The blob base fee stays at no less than 1/16 of the execution base fee.
- Node operators and validators: Part of the computation cost, such as the KZG proof verification done for each blob, is now compensated through the blob fee.
- Client teams: Implements a small change that adds one if clause to the calc_excess_blob_gas() function of EIP-4844.
- Ordinary users: Swings in fees and resource usage are reduced when blob demand changes sharply.
In depth
Definition of the reserve price and BLOB_BASE_COST
The constant BLOB_BASE_COST is 2**13 (8192). The reserve price is BLOB_BASE_COST * base_fee_per_gas, which converted to a blob base fee is BLOB_BASE_COST * base_fee_per_gas / GAS_PER_BLOB. The ratio of the blob base fee floor to the execution base fee is fixed at BLOB_BASE_COST / GAS_PER_BLOB = 1/16. Thanks to this floor, the blob fee always accounts for at least BLOB_BASE_COST / (BLOB_BASE_COST + execution_cost) of the total cost, so the fee update mechanism keeps a meaningful price signal.
The if clause added to calc_excess_blob_gas()
One condition is added to EIP-4844's calc_excess_blob_gas(). If BLOB_BASE_COST * parent.base_fee_per_gas > GAS_PER_BLOB * get_base_fee_per_blob_gas(parent), it does not subtract target_blob_gas and returns parent.excess_blob_gas + parent.blob_gas_used * (blobSchedule.max - blobSchedule.target) // blobSchedule.max. Otherwise it returns parent.excess_blob_gas + parent.blob_gas_used - target_blob_gas as before. The target and maximum blob counts come from the blobSchedule in EIP-7840, using the blobSchedule of the current block. Therefore, when computing get_base_fee_per_blob_gas(parent) for the first block after a fork, fake_exponential() must use the new blobSchedule.baseFeeUpdateFraction, and calc_excess_blob_gas() must also use the new blobSchedule.max and blobSchedule.target.
The problem of inelastic demand
Blob demand can be expressed as Q(b + c), where b is the blob base fee and c is the execution cost per unit of blob gas (execution_cost * base_fee_per_gas / GAS_PER_BLOB). From the fee update mechanism's point of view, c is a fixed value, so when c > 0 there is an inelastic region where lowering b further does not increase demand. The demand curve becomes effectively vertical, and the supply curve is also perfectly inelastic (vertical) in the long run, so the equilibrium blob fee swings sharply even with small changes in demand or execution fees. If execution costs are so high that equilibrium cannot form at the target supply, the blob fee simply falls to the 1 wei boundary. The reserve price solves this by forcing the equilibrium to form on the boundary between the target supply curve and the reserve price curve.
Comparison with KZG proof verification cost
Nodes verify the KZG proofs attached to blobs to check that the commitments match the actual blobs. The cost a smart contract pays for one point evaluation is POINT_EVALUATION_PRECOMPILE_GAS (50000). In PeerDAS (EIP-7594), execution layer nodes batch-verify CELLS_PER_EXT_BLOB (128) cell proofs per blob before putting it in the transaction pool, which costs about 15 times one point evaluation. Full nodes verify while holding 4 columns, and supernodes verify 128 columns. Nodes also sample SAMPLES_PER_SLOT (8) additional columns each slot. Compared with this burden, the source judges BLOB_BASE_COST (8192) to be a relatively modest value.
Why a ratio was designed instead of a fixed threshold
The unit cost of data services keeps falling with technological progress. As Ethereum increases blob throughput, the ETH-denominated price per blob should fall too. A fixed threshold unrelated to blob count or execution fees is not sustainable, because it would need constant readjustment to keep the same effect. This proposal avoids the problem by tying the floor to the execution base fee as a ratio. However, in an extreme scenario where only blobs grow by tens of times while block space stays the same (1000 blobs per block, 30 million execution gas), even if all blobs sell at the reserve price, 21.5% of revenue comes from blob gas, which makes BLOB_BASE_COST too high. The source holds that Ethereum is not currently on such a trajectory, and that if block space and blob space grow at a similar pace, the floor stays at an appropriate level.
Delayed response to execution fee spikes
In the execution-fee-driven region where the if clause is true, the blob fee only rises according to blob_gas_used * (max - target) // max and cannot fall. The maximum increase per block is the same as before. If the execution base fee spikes, it can take several blocks for the blob fee to catch up to the floor, but the source explains that this is not a problem and can even be seen as an advantage, since the fee follows smoothly.
Historical data validation and security
Applying the reserve price to real data from 3 weeks in November 2024, when the execution base fee averaged about 16 gwei, and 3 weeks in March 2025, when it averaged about 1.3 gwei, EIP-7918 follows the higher of the existing fee curve and the reserve price curve. The distribution of about 900,000 blocks starting at block number 22075724 (4 months, from November 2024 to March 2025) was analyzed the same way. This analysis does not reflect the effect the floor would have on the equilibrium price itself; in practice, if demand at the floor level exceeds target supply, the fee rises above it. On security, one blob only settles at a price of at least BLOB_BASE_COST in execution gas, and to the authors' knowledge there is no security risk. The status of this EIP is Final, and the specification is settled.