This Meta EIP documents the activation details, parameter changes, and specification references for the second Blob-Parameter-Only (BPO) network upgrade, BPO2. It provides a canonical reference of blob target, blob maximum limits, and associated configuration values, enabling transparent tracking of incremental data availability scaling following BPO1 under Ethereum’s Surge roadmap.
Following the publication of the Meta EIP documenting BPO1, this EIP extends the registry approach to BPO2, preserving continuity and enabling historical accuracy of blob capacity increases.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
This section documents the Blob-Parameter-Only upgrade identified as BPO2.
The upgrade modifies blob-related protocol parameters as defined in EIP-7892. No other protocol behavior is affected. All timestamps are expressed as Unix epoch seconds (UTC).
| Field | Value |
|---|---|
| BPO Identifier | BPO2 |
| Activation Time (UTC) | 1767747671 |
| Blob Target | 14 |
| Blob Max | 21 |
| Base Fee Update Fraction | 11,684,671 |
BPO2 represents the second incremental blob capacity increase following BPO1 and continues staged scaling toward higher data availability limits.
For reference, prior blob schedules were established in earlier network upgrades and BPO1:
| Upgrade | Blob Target | Blob Max | Base Fee Update Fraction |
|---|---|---|---|
| BPO1 | 10 | 15 | 8,346,193 |
| Prague | 6 | 9 | 5,007,716 |
| Cancun | 3 | 6 | 3,338,477 |
BPO2 builds directly on the BPO1 parameter baseline.
The parameter values and activation times in this EIP are derived from eth client genesis configuration, including:
Client implementations may expose these values in different formats; this EIP reflects the canonical mainnet configuration values.
Following BPO-1, observations indicated that the network could tolerate increased blob limits, but did not yet provide sufficient data across a wider operating range. BPO-2 extends blob parameters as part of the same incremental scaling approach, enabling further observation of network behavior under higher blob loads.
BPO-2 is intended to collect additional empirical data on blob processing, slot reliability, and overall network stability. It is not motivated by demonstrated demand, but by the need to evaluate system limits in a controlled manner while retaining the ability to pause or adjust parameters based on observed outcomes.
BPO upgrades adjust blob throughput parameters and may impact network load characteristics. Careful monitoring, staged rollout, and ecosystem coordination are required to ensure stability.
Copyright and related rights waived via CC0.