EIP-7691 Final

Blob throughput increase

Authors: , , , ,

Canonical data: /latest/eips/7691.json

Increase the number of blobs to reach a new target and max of 6 and 9 blobs per block respectively

Timeline

Pectra

Included

EIP Created Apr 17, 2024

Key Benefits

● Higher data capacity for rollups
● Lower L2 fees in the near term
● Provides extra space before PeerDAS unlocks even more

Trade-offs & Considerations

No trade-offs documented yet.

Stakeholder Impact

End Users

Lower fees on L2s as more blob space becomes available.

Application Developers

Rollup apps benefit from cheaper data availability.

Wallet Developers

No direct changes, potential fee improvements for L2 transactions.

Tooling / Infrastructure

Monitoring should surface new blob target/max parameters.

Layer 2s

Directly increases throughput for rollups using blobs, more L2 scale.

Stakers & Node Operators

Slightly higher data propagation at the p2p layer within safe bounds.

CL Client Developers

Parameters update that needed more optimization and testing

EL Client Developers

Update blob gas accounting and targets.

North Star Goal Alignment

● Scale Blobs: Directly increases data availability for rollups by raising blob capacity, improving throughput.

Abstract

Increases the number of blobs in a block to provide more scale to Ethereum via L2 solution that rely on L1 data capacity.

Motivation

Ethereum, with its rollup centric roadmap, scales by relying on L2. Since the Dencun fork, the blob gas target and maximum was set to 3/6 respectively. The blob gas limit was arrived at based on a series of big block tests performed on the Ethereum mainnet network as well as a series of testnets. The values were chosen cautiously, as it's extremely hard to predict the exact p2p behaviour of Ethereum mainnet.

As we now have the Dencun upgrade live, we are able to use monitoring tools to check the network health. Initial monitoring indicates that we have a stable network with the current gas target and the re-org rate is trending downwards. Additionally, analysis on messages in gossipsub indicate that the inclusion of IDONTWANT messages could bring us a significant bandwidth savings. This allows us to consider starting a series of big block and blob tests to determine the theoretical headroom we currently have. The EIP specifies a proposed new blob gas target and limit based on the series of tests.

This EIP aims to increase the throughput short term to provide some scaling until future solutions are deployed. In order to alleviate valid concerns about solo-stakers, approaches such as the inclusion of a flag indicating the max blobs per block for locally built blocks could be considered.

Specification

Parameters

Constant	Value
`MAX_BLOBS_PER_BLOCK_ELECTRA`	`9`
`TARGET_BLOBS_PER_BLOCK_ELECTRA`	`6`
`MAX_BLOB_GAS_PER_BLOCK`	`1179648`
`TARGET_BLOB_GAS_PER_BLOCK`	`786432`
`BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE`	`5007716`

MAX_BLOBS_PER_BLOCK_ELECTRA and TARGET_BLOBS_PER_BLOCK_ELECTRA are consumed by the consensus layer clients, and starting at PECTRA_FORK_EPOCH replace the respective old max and target values.

MAX_BLOB_GAS_PER_BLOCK, TARGET_BLOB_GAS_PER_BLOCK and BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE are consumed by the execution layer clients, and starting at the epoch when this EIP is activated, replace the old max, target and update fraction values. Any references to MAX_BLOB_GAS_PER_BLOCK and TARGET_BLOB_GAS_PER_BLOCK in EIP-4844 should be updated to the new values defined in this EIP when processing the activation block. The value BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE replaces its previous equivalent when processing the activation block. These changes imply that get_base_fee_per_blob_gas and calc_excess_blob_gas functions defined in EIP-4844 use the new values for the first block of the fork (and for all subsequent blocks).

Rationale

Simplicity

The EIP aims to minimize the amount of testing and implementation effort from the perspective of the client teams, to allow for more resources to be allocated to peerDAS and other scaling research.

While this EIP may not achieve the new optimal blob limit, it offers a compromise for a short term increase.

Update Fraction

The original target and max values from EIP-4844 were at a 1:2 ratio. As a consequence, responsiveness to full and empty blob sections was symmetrical:

full blobs: basefee increases by ~12.5%
no blobs: basefee decreases by ~11.1%

The new target and max values from this EIP are at a 2:3 ratio, which breaks that symmetry. As a consequence, the basefee becomes significantly more responsive to empty blob sections (that are 6 blobs under target) than to full ones (that are 3 blobs over target). This is by design, as it takes two blocks with full blobs in a row to make up for a single block with no blobs. However, it creates the challenge of finding a good compromise base fee sensitivity level.

The BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE value in this EIP is chosen as the mid-point between keeping the responsiveness to full blobs and no blobs constant:

full blobs: basefee increases by ~8.2%
no blobs: basefee decreases by ~14.5%

Backwards Compatibility

The consensus clients would continue to use MAX_BLOBS_PER_BLOCK and TARGET_BLOBS_PER_BLOCK for the deneb fork and once the ELECTRA fork is active, they would use MAX_BLOBS_PER_BLOCK_ELECTRA and TARGET_BLOBS_PER_BLOCK_ELECTRA respectively.

The execution clients would continue to use MAX_BLOB_GAS_PER_BLOCK, TARGET_BLOB_GAS_PER_BLOCK and BLOB_BASE_FEE_UPDATE_FRACTION for the cancun fork and once the prague fork is active, they would use MAX_BLOB_GAS_PER_BLOCK, TARGET_BLOB_GAS_PER_BLOCK and BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE respectively.

Security Considerations

Network Impacts

Through the use of big block/blob tests on Ethereum mainnet as well as testnets, we can earn a high degree of certainty that the blob limit increase would not negatively impact the network. These tests as well as the associated analysis can be performed mostly by non-client team entities, with minimal input required. Since the changes are quite contained, the EIP should be able to reduce the risk of the blob limit increase.

Stability Around Fork Epoch

A blob limit increase at the fork transition is relatively straightforward from an implementation perspective. We would need to deploy an increased amount of monitoring around the fork epoch, but after a period of stability we can assume that the blob limit increase was successful, reducing any unexpected co-ordination efforts.