EIP-8252: Execution-Layer Reorg State Retention Window

EIPs EIPs core
1

Discussion topic for EIP-8252

Update Log

  • 2026-05-07: Initial draft, commit.

External Reviews

None as of 2026-05-07.

Outstanding Issues

  • 2026-05-07: Sensitivity to future changes in INACTIVITY_PENALTY_QUOTIENT_BELLATRIX. The constant REORG_RETENTION_WINDOW = 262_144 is calibrated to Q = 2^24. Any future CL fork that loosens this quotient (slowing the leak) lengthens the leak-bounded non-finality window and requires revisiting the constant. Should the EIP track Q symbolically or remain a hard-coded block count?

  • 2026-05-07: Implementation cost on EL clients. Retaining reconstructible state across ~36 days (8,192 epochs) implies non-trivial disk overhead for snapshot or reverse-state-diff schemes. Looking for concrete numbers from Geth, Reth, Nethermind, Besu, and Erigon teams on:

    • (a) current de-facto retention

    • (b) projected storage delta to comply

    • (c) preferred representation (snapshots vs. reverse diffs vs. hybrid)

  • 2026-05-07: Coordination with EIP-4444 and successors. This EIP intentionally does not constrain block-history retention. Operators sizing storage will combine both budgets; reviewers should sanity-check there is no implicit double-counting or contradiction between this EIP’s state floor and EIP-4444’s block-data ceiling.

  • 2026-05-07: Interaction with EIP-7251 (MaxEB). The leak math (proportional decay, share rebalancing toward 2/3) is independent of individual validator balances, so the formula and the chosen constant should be unaffected. Confirmation from CL researchers welcome.

  • 2026-05-07: Choice of 8,192 epochs vs. alternative round numbers. The chosen value covers up to f ≈ 0.787 initial offline stake. Doubling to 2^14 epochs covers f ≈ 0.93 at 2× the storage cost; halving to 2^12 would only cover f ≈ 0.5. Is the current operating point the right trade-off, or should the constant be tightened/loosened?