EIP-7691 Blob throughput increase
Final · Scaling & data · EIP status Final · created 2024-04-17
Raises the number of blobs per block from a target of 3 and a maximum of 6 to a target of 6 and a maximum of 9. This doubles the L1 data space available to L2s and improves Ethereum's scalability in the short term.
Why it is needed
Under its rollup-centric roadmap, Ethereum leaves scaling to L2s, and L2s post their data to a dedicated L1 space called blobs. In the Dencun fork, the blob count was set at a target of 3 and a maximum of 6. This was a conservative value, because it was hard to predict how the mainnet P2P network would react at the time. After Dencun went live, monitoring showed the network was stable, and the re-org rate (how often blocks are replaced) was trending down. Analysis of message propagation between nodes also confirmed that introducing the IDONTWANT message could save significant bandwidth. In other words, evidence accumulated that the network had headroom, and this proposal aims to raise the blob count to absorb current demand until a full scaling technology such as peerDAS arrives.
What changes
Today
- Blob target of 3 and maximum of 6 per block (as of the Dencun fork)
- Because the target and maximum are in a 1:2 ratio, the blob fee responds symmetrically when it rises and falls
- The L1 data space available to L2s is relatively small
After EIP-7691
- Blob target of 6 and maximum of 9 per block, roughly double
- The target and maximum become a 2:3 ratio, and a new fee update fraction is set to calibrate the reaction speed
- Gives L2 data space some breathing room until long-term scaling technologies such as peerDAS arrive
Who is affected
- L2 (rollups): The blob space that can be posted to L1 roughly doubles, which creates room to reduce the cost burden of data posting.
- Client teams: It is a small change that only requires swapping constant values on both the consensus layer and the execution layer, so the implementation and testing burden is low.
- Validators and solo stakers: Bandwidth load may increase as blocks grow. The source says mitigations such as a flag that limits the maximum number of blobs in locally built blocks can be considered.
- Users: L1 data cost, which feeds into L2 fees, varies with supply and demand, so they are affected indirectly.
In depth
New parameters
For the consensus layer, it defines MAX_BLOBS_PER_BLOCK_ELECTRA = 9 and TARGET_BLOBS_PER_BLOCK_ELECTRA = 6. For the execution layer, it defines MAX_BLOB_GAS_PER_BLOCK = 1179648, TARGET_BLOB_GAS_PER_BLOCK = 786432, and BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE = 5007716. The consensus layer values replace the existing maximum and target values from PECTRA_FORK_EPOCH, and the execution layer values replace the existing maximum, target, and update fraction from the epoch at which this EIP is activated.
Connection to EIP-4844 functions
References to MAX_BLOB_GAS_PER_BLOCK and TARGET_BLOB_GAS_PER_BLOCK in EIP-4844 change to this EIP's new values starting when the activation block is processed. BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE also replaces the existing value from the activation block. As a result, the get_base_fee_per_blob_gas and calc_excess_blob_gas functions defined in EIP-4844 operate with the new values from the first block of the fork.
Why the update fraction was reset
In EIP-4844 the target:maximum ratio was 1:2, so the fee response was symmetric. When blobs were full the base fee rose about 12.5%, and when empty it fell about 11.1%. This EIP's 2:3 ratio breaks that symmetry. Blocks can be up to 6 blobs below the target but only 3 above it, so the fee reacts more strongly to the empty side. Making up for one empty block requires two consecutive full blocks, so this is intended, but it creates the challenge of finding the right level of sensitivity. BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE = 5007716 was chosen as the midpoint between the option that preserves the response on the full side and the option that preserves the response on the empty side. The result is about +8.2% for a full block and about -14.5% for an empty block.
A design that favors simplicity
This EIP aims to minimize the testing and implementation burden on client teams. Keeping it a small change on the level of swapping constants lets teams spend more resources on peerDAS and other scaling research. The source states that this value may not be the optimal blob limit but is a compromise for a short-term increase.
Backwards compatibility and the fork boundary
Consensus clients keep using the existing MAX_BLOBS_PER_BLOCK and TARGET_BLOBS_PER_BLOCK in the Deneb fork, then switch to MAX_BLOBS_PER_BLOCK_ELECTRA and TARGET_BLOBS_PER_BLOCK_ELECTRA once the ELECTRA fork activates. Execution clients use the existing values and BLOB_BASE_FEE_UPDATE_FRACTION in the Cancun fork, then use the new values and BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE once the Prague fork activates.
Security considerations
Testing large blocks and blobs on mainnet and testnets can give confidence that the limit increase does not harm the network, and this testing and analysis can be done by parties other than client teams, which keeps the burden on teams low. Raising the limit at the fork transition is relatively simple from an implementation standpoint, but monitoring should be increased around the fork epoch, and once a stabilization period passes the increase can reasonably be considered a success. On the concern about solo stakers, the source says approaches such as introducing a flag to set the maximum number of blobs in locally built blocks can be considered. This EIP is a specification finalized with Final status.