EIP-4444 proposes a bounded serving window for execution history. Its status is
Stagnant in the pinned source, so this page describes a possible future system.
The current retention page states the active eth contract.
Proposed boundary
The proposal sets HISTORY_PRUNE_EPOCHS to 82,125 beacon-chain epochs, about
one year. It says clients SHOULD NOT serve headers, bodies, or receipts older
than that window on the p2p layer, and MAY prune those objects locally. They
would still serve recent history through eth. These are proposed rules from a
Stagnant EIP, not active client policy.
A node could no longer rely on genesis-to-head synchronization through devp2p. The proposal requires checkpoint sync from a valid weak-subjectivity checkpoint and retrieval of the recent chain from execution peers.
Older history
Old history would move to systems with an archival role. The Portal History Network defines content keys and retrieval for block bodies and receipts; it assumes that a client already has headers to verify those objects. Other out-of-band archives may also supply the data.
A client must validate imported history against canonical hashes and consensus rules. The source of a byte string does not make it trusted.
Failure handling
- A client distinguishes unavailable old data from an invalid response.
- A checkpoint-sync client stops when its checkpoint is missing, too old, or not trusted by policy.
- An archival importer verifies every object before it adds it to local state.
- Applications must handle JSON-RPC queries for pruned data without treating absence as proof that an object never existed.
Design rationale
Recent history supports live validation and short-range sync. Old history has different storage and access needs. A separate archival path can preserve that data without requiring every execution node to store it.
History
EIP-4444 first proposed a one-year devp2p serving window in 2021. It remains Stagnant in the pinned EIP set.