EIP-7892 Blob-parameter-only hard fork (Blob Parameter Only Hardforks)
Final · Scaling & data · EIP status Final · created 2025-02-28
Defines a lightweight hard fork (BPO fork) that changes only the three numbers determining blob capacity (target, max, baseFeeUpdateFraction) via the configuration file. Blob capacity can be raised frequently and in small increments without modifying client code.
Why it is needed
Ethereum delegates transaction execution to layer 2 (L2) and has its base layer serve as a data availability layer that stores the data L2s post. As L2s grow rapidly, demand for this data space, namely blobs, keeps increasing and capacity is becoming saturated. Currently, however, raising blob capacity requires waiting for a large, infrequent regular hard fork. Regular hard forks involve substantial coordination, testing, and upgrade work across clients, making it hard to keep pace with L2 growth. There is also the problem that, right after a major new scaling technology is introduced, the appropriate blob limit is hard to know in advance, forcing developers to pick a compromise value between stability and capacity. This EIP defines a small dedicated fork that changes only blob-related numbers, allowing capacity to be raised quickly and safely as needed after observing mainnet performance and stability. For rollups, this creates predictability that Ethereum will keep scaling.
What changes
Today
- Changing blob capacity requires waiting for a large, infrequent regular hard fork
- Each fork requires client code changes and lengthy coordination and testing
- Right after a new scaling technology is introduced, a conservative limit must be chosen for stability reasons
After EIP-7892
- A BPO fork that changes only blob parameters is scheduled and activated purely through configuration files
- New parameters take effect immediately at the specified activation time without any code changes
- Capacity can be raised in stages after observing mainnet conditions
Who is affected
- L2s and rollups: Predictability that blob capacity will keep increasing becomes grounds for choosing Ethereum over other data availability solutions.
- Client teams: Blob parameters can be changed by simply adding a configuration entry, without the large amount of boilerplate previously needed for each fork.
- Node operators and validators: Execution layer and consensus layer BPO fork schedules must be kept in sync by updating configuration and aligning with the fork time.
- Testing teams: Because parameters are separated into configuration, multiple values can be experimented with while minimizing involvement from client implementers.
In depth
Definition of a BPO fork
A BPO hard fork is a protocol upgrade that changes blob-related parameters through configuration alone, without any client code changes. The target parameters are three: target, the expected number of blobs per block; max, the maximum number of blobs per block; and baseFeeUpdateFraction, which determines how fast the blob gas price adjusts. The new parameters take effect immediately at the specified activation time. For consistency, even when a regular hard fork changes these parameters, it MUST do so by adding an entry to the blob schedule configuration.
Execution layer configuration: blobSchedule and activation time
Associates each fork in the blobSchedule object defined by EIP-7840 with a top-level <fork_name>Time field. This field holds the Unix timestamp of the activation slot as a JSON number. BPO fork names SHOULD follow the bpo<index> convention, like bpo1, bpo2, where index starts at 1; since these are not meant to be sorted lexicographically, left-padding with zeros is not needed. Activation timestamps are only required for forks after Prague, and since there is no backporting, cancunTime and pragueTime are left at 0. The numbers and schedule in the original examples are purely illustrative; actual values are out of scope for this specification.
Changes to blob base fee computation
EIP-4844's get_base_fee_per_blob_gas and calc_excess_blob_gas functions change to take the blob schedule (BlobSchedule: target, max, base_fee_update_fraction) as an explicit argument. As with how EIP-7691 updated BLOB_BASE_FEE_UPDATE_FRACTION, both functions now use the current block's blob schedule. The constant TARGET_BLOB_GAS_PER_BLOCK is removed and replaced by GAS_PER_BLOB * blob_schedule.target.
Consensus layer configuration and EL/CL matching requirements
A new BLOB_SCHEDULE field is added to the consensus layer configuration. It records one entry, with EPOCH and MAX_BLOBS_PER_BLOCK, for every fork after ELECTRA_FORK_EPOCH that changes blob parameters. An entry is created whenever blob parameters change, whether at a regular fork or a BPO fork. There are three requirements. Execution and consensus clients MUST share a matching BPO fork schedule, the slots in the execution layer's blobSchedule MUST align with the start of the epochs recorded in the consensus layer configuration, and the execution layer's max MUST equal the consensus layer's MAX_BLOBS_PER_BLOCK.
Modifications to compute_fork_digest
The fork digest computation function gains current_epoch and blob_schedule arguments. The schedule is sorted by descending epoch to find the entry applicable to the current epoch, and that entry's max_blobs_per_block value is encoded as 4-byte big-endian and XOR-masked into the existing 4-byte digest. If no entry applies, the existing digest is returned unchanged, which lets the BPO mechanism itself be deployed first without any parameter change. This digest is mainly used for domain separation at the p2p layer, and 4 bytes are enough to practically distinguish forks and chains.
P2P networking: the nfd field and topic rotation
An nfd (next fork digest) entry is added to the consensus layer ENR. Its value is a ForkDigest in SSZ Bytes4 format, announcing the digest of the next scheduled fork, whether regular or BPO. A digest is used instead of carrying BPO-specific parameters directly because it is use-case neutral and offers greater long-term flexibility. When discovering peers, nodes MUST evaluate nfd together with the existing eth2 key's ENRForkID::next_* fields. Status requests and responses are unchanged, but responses must carry the updated fork_digest. The gossip topic structure is also unchanged, but because ForkDigestValue changes, all topics automatically rotate at the BPO fork point.
Why not a regular hard fork or on-chain voting
A regular hard fork requires broad coordination and implementation changes that go well beyond parameter tuning. For example, in Lighthouse a typical hard fork implementation involves thousands of lines of preparatory code before the protocol change itself. Keeping parameters in node configuration rather than code allows fast experimentation and adjustment with minimal involvement from client implementers. Reasons given for not creating on-chain voting include that it recently took nearly a year to raise the gas limit to 36M, that blob capacity is a fast-moving target the staking community isn't ready to track, and that it would require far more code changes and governance debate. BPO forks are a simpler, more predictable approach while still leaving room to introduce on-chain voting once blob capacity stabilizes. This EIP is an Informational document in Final status.