Update EIP-7892: harden BPO fork specs with p2p details.

Author: raulk

EIPS/eip-7892.md

@@ -18,14 +18,16 @@ This EIP introduces **Blob Parameter Only (BPO) Hardforks**, a lightweight mecha
 
 Ethereum's scaling strategy relies on Layer 2 (L2) solutions for transaction execution while using Ethereum as a **data availability (DA) layer**. However, the demand for DA has increased rapidly, and the current approach of only modifying blob parameters in large, infrequent hard forks is **not agile enough** to keep up with L2 growth. 
 
-The key motivations for BPO forks are:
+The key motivations for BPO forks are as follows:
 
 1. **Continuous Scaling**  
-   - L2 DA demand is growing rapidly, leading to saturation of blob capacity.
+   - L2 DA demand is growing rapidly, leading to ongoing saturation of blob capacity.
    - Large, infrequent blob parameter changes create high costs and inefficiencies.
    - BPO forks allow for more frequent, safer capacity increases.
 
 2. **Reduced Operational Overhead**  
+   - Performance improvements and further testing will continue to unlock additional capacity.
+   - It is desirable to reduce the time between core devs agreeing on a parameter increase and its effective deployment.
    - Full Ethereum hard forks require significant coordination, testing, and upgrade efforts across clients.
    - By isolating blob parameter changes, BPO forks reduce the complexity of upgrades.
 
@@ -39,12 +41,22 @@ The key motivations for BPO forks are:
 
 ## Specification
 
-BPO forks are a special class of hard fork which **only modifies any of the following** blob-related parameters:
+### Parametric hardforks
+
+BPO forks are a category of **parametric hardforks**, which only change certain protocol parameters at a designated point in time without requiring client-side code changes. The new parameters are activated instantly, with no transition function. These hardforks are consensus-breaking, and therefore receive a `ForkVersion` in the consensus layer.
+
+### Managed parameters
+
+The following blob-related parameters are now managed by parametric configuration:
 
 - **Blob Target (`blob_target`)**: The expected number of blobs per block.
 - **Blob Limit (`blob_limit`)**: The maximum number of blobs per block.
 - **Blob Base Fee Update Fraction (`baseFeeUpdateFraction`)**: Determines how blob gas pricing adjusts per block.
 
+To ensure consistency, when a regular hardfork changes any of these parameters, it MUST do so by adding an entry to the blob schedule.
+
+### Execution layer configuration
+
 To facilitate these changes on the execution layer, the `blobSchedule` object specified in [EIP-7840](./eip-7840.md) is extended to allow for an arbitrary number of block timestamps at which these parameters **MAY** change.
 
 ```json
@@ -72,24 +84,71 @@ To facilitate these changes on the execution layer, the `blobSchedule` object sp
 }
 ```
 
-On the consensus layer, a new parameter is added to the configuration:
+### Consensus layer configuration
 
-```
-BLOB_SCHEDULE:
-  - EPOCH: 348618
+On the consensus layer, a new parameter is added to the configuration. The `FORK_VERSION` is only specified here for pure BPO forks. Regular forks have their own fork version specified in source, even if they alter blob parameters.
+
+```yaml
+BLOB_PARAMETER_SCHEDULE:
+  - EPOCH: 269568     ## Deneb (backported)
+    MAX_BLOBS_PER_BLOCK: 6
+  - EPOCH: 364032     ## Electra (backported)
+    MAX_BLOBS_PER_BLOCK: 9
+  - EPOCH: 400000     ## A future anonymous BPO fork carrying a fork version
+    FORK_VERSION: 0x09000000
     MAX_BLOBS_PER_BLOCK: 24
-  - EPOCH: 355368
+  - EPOCH: 420000     ## A future anonymous BPO fork  carrying a fork version
+    FORK_VERSION: 0x0A000000
     MAX_BLOBS_PER_BLOCK: 56
 ```
 
 The parameters and schedules above are purely illustrative. Actual values and schedules are beyond the scope of this specification.
 
-### Requirements
+**Requirements:**
+
+- Execution and consensus clients **MUST** share consistent BPO fork schedules.
+- The timestamp in EL's `blobSchedule` **MUST** align with the start of the epoch specified in the consensus layer configuration.
+- The `max` field in `blobSchedule` **MUST** equal the `MAX_BLOBS_PER_BLOCK` value in the consensus layer configuration.
+
+### Modified `compute_fork_version`
+
+The `compute_fork_version` helper is updated to account for BPO forks:
+
+```python
+def compute_fork_version(epoch: Epoch, blob_schedule: Sequence[BlobScheduleEntry]) -> Version:
+   # Start with named forks.
+   forks = [
+       (ELECTRA_FORK_EPOCH, ELECTRA_FORK_VERSION),
+       (DENEB_FORK_EPOCH, DENEB_FORK_VERSION),
+       (CAPELLA_FORK_EPOCH, CAPELLA_FORK_VERSION),
+       (BELLATRIX_FORK_EPOCH, BELLATRIX_FORK_VERSION),
+       (ALTAIR_FORK_EPOCH, ALTAIR_FORK_VERSION),
+   ]
+   
+   # Add blob schedule entries that define fork versions (therefore representing BPO forks).
+   bpo_forks = [
+       (entry.epoch, entry.fork_version) 
+       for entry in blob_schedule 
+       if entry.fork_version is not None
+   ]
+   forks.extend(bpo_forks)
+   
+  forks.sort(reverse=True)
+
+   # Find the most recent fork for this epoch.
+   for fork_epoch, fork_version in forks:
+       if epoch >= fork_epoch:
+           return fork_version
+   
+   return GENESIS_FORK_VERSION
+```
+
+### P2P Networking
+
+In the consensus layer:
 
-- Execution and consensus clients **MUST** share consistent BPO fork schedules
-- BPO forks **MUST NOT** conflict with other fork schedules
-- The timestamp in `blobSchedule` **MUST** align with the start of the epoch specified in the consensus layer configuration
-- The `max` field in `blobSchedule` **MUST** equal the `MAX_BLOBS_PER_BLOCK` value in the consensus layer configuration
+- The ENR fields `next_fork_version` and `next_fork_epoch` are set from the configuration for the next BPO fork, if applicable.
+- It's worth noting that p2p topics will roll over when a BPO fork is activated, as the `fork_digest` parameter is derived from the `fork_version` (modified above to account for BPO forks).
 
 ## Rationale