Define REORG_RETENTION_WINDOW = 262_144 blocks (8192 epochs × 32 slots, ~36.4 days) and require EL clients to keep recent state reconstructible (via snapshots, reverse state diffs, or any equivalent representation, in memory or on disk) for every canonical block within this window, so any reorg up to the inactivity-leak-bounded non-finality window can be processed locally.
EL clients have no protocol-defined floor on how far back recent state must remain reconstructible. History-expiry rules govern long-term block-history retention; state-pruning policy is left entirely to clients.
To validate a post-reorg branch handed in via the engine API, an EL must execute its first block against the state of the common ancestor with the local chain. That ancestor cannot lie deeper than the chain's last finalized block, and the distance to last finalization is bounded by the CL's inactivity leak: once finality stalls, the leak quadratically penalizes non-participating validators until their share of active stake falls below 1/3 and finality resumes. A single retention floor aligned to that bound closes this gap.
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
REORG_RETENTION_WINDOW = 262144 blocks.
For every canonical block with number n in the range head - REORG_RETENTION_WINDOW ≤ n ≤ head, EL clients MUST be able to reconstruct that block's post-state without sync. The representation (full snapshots, reverse state diffs, or any equivalent) and its location (memory or disk) are unspecified. State older than the window MAY be discarded.
This EIP does not constrain retention of block headers, bodies, or receipts; those are governed by history-expiry rules.
Under post-merge inactivity-leak parameters (INACTIVITY_SCORE_BIAS = 4, INACTIVITY_PENALTY_QUOTIENT_BELLATRIX = 2^24), a continuously offline validator's effective balance evolves as balance(N)/balance(0) ≈ exp(-N²/(2Q)). For finality to resume from an initial offline-stake fraction f, the offline share must fall below 1/3, giving N > sqrt(2 · Q · ln(2f/(1-f))) epochs (at 225 epochs/day):
Offline fraction f |
Epochs to recover finality | Days |
|---|---|---|
| 0.50 | ~4,822 | ~21.4 |
| 0.60 | ~6,072 | ~27.0 |
| 2/3 | ~6,820 | ~30.3 |
| 0.75 | ~7,754 | ~34.5 |
Recovery time grows with f because the leak only drains offline stake while online stake is unchanged: a larger initial offline share must be shrunk by a larger factor before the online side regains a 2/3 supermajority. Since balances decay as exp(-N²/(2Q)), achieving a larger shrink factor requires a longer leak; the ln(2f/(1-f)) term inside the bound diverges as f → 1.
8,192 epochs (2^13, ~36.4 days) corresponds to ln(2f/(1-f)) = 2, i.e. it covers leak-driven non-finality up to f ≈ 0.787 (~79% initial offline stake); above that fraction, recovery is expected to rely on external sync rather than local state. Encoding it as 8192 × 32 = 262,144 blocks (2^18) gives EL clients a single block-denominated value with no dependency on finalized beacon state.
A deep reorg is processed by rolling state back to the common ancestor with the incoming branch and re-executing forward. The new branch's blocks arrive via the engine API or P2P; the local node does not need to have stored the displaced branch's headers, bodies, or receipts. What it strictly needs is the ability to reconstruct state at the ancestor, which makes state retention the load-bearing requirement for reorg recovery. Block-data retention is a separate, network-serving concern addressed by history-expiry rules.
Reorgs shallower than REORG_RETENTION_WINDOW can be resolved locally. Reorgs deeper than the window are out of scope for this EIP; recovery may require fresh sync from a trusted checkpoint.
EL clients with state-pruning policies more aggressive than REORG_RETENTION_WINDOW must retain additional state (typically as reverse diffs) to comply.
Reconstruction of state older than REORG_RETENTION_WINDOW is out of scope and served by archive nodes.
Copyright and related rights waived via CC0.