Skip to content

Update EIP-7892: clarify one-time enabling change and config-only BPO forks #10812

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+10 −4
Open

Update EIP-7892: clarify one-time enabling change and config-only BPO forks #10812

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 10 additions & 4 deletions EIPS/eip-7892.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ status: Last Call
last-call-deadline: 2025-10-28
type: Informational
created: 2025-02-28
requires: 7840
requires: 4844, 7840
---

## Abstract
Expand Down Expand Up @@ -44,7 +44,11 @@ The key motivations for BPO forks are as follows:

### Definition

BPO hardforks are defined as protocol upgrades that modify only blob-related parameters through configuration, without requiring any client-side code changes. The new parameters take effect immediately at the specified activation time.
Once clients implement the enabling changes defined in this EIP, BPO hardforks are protocol upgrades that modify only blob-related parameters through configuration, without requiring additional client-side code changes. The new parameters take effect immediately at the specified activation time.

### Enabling change

This EIP introduces a one-time enabling change across both the execution and consensus layers so that blob-related parameters are sourced from per-fork schedules defined in client configuration. Specifically, execution clients MUST read `target`, `max`, and `baseFeeUpdateFraction` from the active `blobSchedule` entry (as introduced in [EIP-7840](./eip-7840.md)), and consensus clients MUST carry a corresponding `BLOB_SCHEDULE`. After these enabling changes are implemented in clients, subsequent BPO forks become configuration-only and require no additional client-side code changes.

### Blob schedule configuration

Expand All @@ -58,7 +62,7 @@ To ensure consistency, when a regular hardfork changes any of these parameters,

### Execution layer configuration

To facilitate these changes on the execution layer, each fork in the `blobSchedule` object defined in [EIP-7840](./eip-7840.md) is linked to an activation timestamp via a top-level `<fork_name>Time` field, which holds the Unix timestamp of the activation slot as a JSON number. BPO forks SHOULD be named using the convention `bpo<index>`, where `<index>` starts at `1`. Left padding is unnecessary since these labels are not subject to lexicographic sorting. Activation timestamps are required only for forks that occur **after** Prague.
To facilitate these changes on the execution layer, each fork in the `blobSchedule` object defined in [EIP-7840](./eip-7840.md) is linked to an activation time via a top-level `<fork_name>Time` field, which holds the Unix timestamp of the fork activation as a JSON number. BPO forks SHOULD be named using the convention `bpo<index>`, where `<index>` starts at `1`. Left padding is unnecessary since these labels are not subject to lexicographic sorting. Activation timestamps are required only for forks that occur **after** Prague.

```json
{
Expand Down Expand Up @@ -105,6 +109,8 @@ We modify the functions `get_base_fee_per_blob_gas` and `calc_excess_blob_gas` d
In line with how updating `BLOB_BASE_FEE_UPDATE_FRACTION` was handled in [EIP-7691](./eip-7691.md), the functions use the *current* block's blob schedule.
Moreover, `TARGET_BLOB_GAS_PER_BLOCK` is removed and replaced with `GAS_PER_BLOB * blob_schedule.target`, as it is now redundant.

This constitutes the enabling change on the execution layer: clients MUST parameterize blob fee computation on the active `BlobSchedule` so that future BPO forks can be performed via configuration only, without further client code changes.

```python
class BlobSchedule:
target: U64
Expand Down Expand Up @@ -143,7 +149,7 @@ The parameters and schedules above are purely illustrative. Actual values and sc
**Requirements:**

- Execution and consensus clients **MUST** share consistent BPO fork schedules.
- The slot number in the EL's `blobSchedule` **MUST** align with the start of the epoch specified in the consensus layer configuration.
- The activation timestamp fields in the execution layer configuration **MUST** align with the start time of the epoch specified in the consensus layer configuration.
- The `max` field in the EL's `blobSchedule` **MUST** equal the `MAX_BLOBS_PER_BLOCK` value in the consensus layer configuration.

### Modified `compute_fork_digest`
Expand Down