EIP-7840 Adding a blob schedule to the execution client configuration (Add blob schedule to EL config files)
Final · Scaling & data · EIP status Final · created 2024-12-12
Adds a blobSchedule entry to the execution client configuration file, so that per-fork target blob count per block (target), maximum count (max), and the fee update coefficient (baseFeeUpdateFraction) can be specified.
Why it is needed
A blob is a large data space attached to a block, and how many can be included per block at most (max) and how many are maintained on average (target) can change with each fork. Ideally these values should be managed by the consensus client, but in practice the execution client also needs these values for several tasks. For example, the eth_feeHistory RPC, which reports fee history, returns a blob gas usage ratio (blobGasUsedRatio), and computing this value requires knowing the maximum blob count. However, exchanging this value for every block via the engine API connecting the two clients would be excessive, and a complex handshake is also undesirable. This EIP takes the middle path by creating a standard place in the client configuration file to record per-fork blob values. It also includes the coefficient that determines how fast the blob gas price moves, so that it too can be adjusted per fork.
What changes
Today
- There is no standard way to inform the execution client of the blob target and max counts
- Sharing the values would require a complex handshake over the engine API
- There is no designated place to record the blob fee update coefficient, which varies by fork
After EIP-7840
- Per-fork values are recorded in the blobSchedule object of the configuration file
- target, max, and baseFeeUpdateFraction must be set for each fork
- Per-fork blob values are adjusted through the configuration file alone, without going through the engine API
Who is affected
- Client teams: The configuration file must read blobSchedule and apply the per-fork target, max, and baseFeeUpdateFraction
- Node operators: Per-fork blob values can be set directly in the configuration file of custom networks
- Wallet & app developers: RPC responses that rely on blob values, such as blobGasUsedRatio in eth_feeHistory, will follow the per-fork configuration
- Ordinary users: There is no directly perceptible change. This is a proposal that organizes how configuration is handled internally within clients
In depth
The shape of the blobSchedule object
A blobSchedule object is added to the client configuration file. The fork name becomes the key, and under each fork the three values target, max, and baseFeeUpdateFraction are recorded. The original text's example sets target 3, max 6, and baseFeeUpdateFraction 3338477 for cancun, and target 6, max 9, and baseFeeUpdateFraction 5007716 for prague. Clients must set these three values for each fork, and when a new fork is introduced, it is extended by adding an entry of the same shape.
What the three parameters do
target is the target number of blobs per block, and max is the maximum number of blobs per block. baseFeeUpdateFraction is a coefficient that determines how sensitively the blob gas price responds to demand changes, added so that the price response speed can be adjusted per fork. Because the three values are recorded together under the fork name, even if the blob count or the sensitivity of the pricing formula changes across forks, only the configuration file needs to be edited.
When configuration is missing or incomplete
The behavior when a given fork's configuration is missing or incomplete is undefined. The original text leaves it up to each client to decide how to handle this situation. A client may error out and halt, or fill in its own defaults, and this EIP does not determine which is correct.
Why a configuration file instead of the engine API
The original text acknowledges the reality that, while blob target and max values are ideally managed solely by the consensus client, the execution client also needs these values for several tasks. A representative case is the eth_feeHistory RPC. The blobGasUsedRatio field this method returns is a value not needed by the core protocol, yet it cannot be computed without knowing max. Passing this value through the engine API on every block was judged excessive, and the configuration file was determined to be a good middle ground. The Motivation section also cites opening a path to dynamically adjust the target and max counts and the fee update coefficient while avoiding a complex handshake over the engine API.
Informational type, Final status
This EIP's type is Informational and its status is Final. It is not a proposal that changes consensus rules such as block validity, but a document that establishes a convention for client configuration files, and its contents are finalized and will not change further. Both backward compatibility issues and security considerations are stated as none found.