This Meta-EIP documents the activation process and plan for history expiry as well as providing links to other EIPs that are related.
EIP-4444 documents the motivation for history expiry itself.
This EIP exists to document the process through which history expiry will be activated on mainnet, the testnet activation on Sepolia, devnet testing and other information surrounding history expiry that doesn't fit cleanly in any of the supporting EIPs.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Execution layer client MUST implement EIP-7642 to support the eth/69 over DevP2P.
Execution layer clients MAY drop pre-merge history according to EIP-7639.
Consensus layer clients SHOULD NOT depend on Execution Layer clients having the deposit logs from pre-merge blocks and SHOULD implement EIP-6110.
Mainnet activation of history expiry will occur shortly (a few days or weeks) after the activation of the Pectra hard fork. The short delay is to ensure that all deposit logs from before the fork have been processed before clients begin dropping history.
Testing of history expiry will occur on the Sepolia testnet. Execution clients may begin dropping pre-merge Sepolia history on 2025-05-01.
Execution clients may test dropping of history on devnets.
Consensus Layer clients have a dependency on pre-merge deposit logs. EIP-6110 will remove this dependency when the Pectra fork is activated.
The Sepolia history drop is intended as a testing ground for the mainnet activation.
The Devnet history drop is intended to test prior to Sepolia to avoid any breakage on the Sepolia network.
History Expiry doesn't require clients to remove this data. It only allows them to. Clients that wish to preserve this history in their client for JSON-RPC use cases are free to do so.
Pre-merge data is available in the e2store archival format. A public list of these archives can be found in the eth-clients historical data endpoints list which can be found on the eth-clients website.
The Portal network also implements a decentralized peer-to-peer solution for storage and retrieval of all of Ethereum's pre-merge block data.
The EIP-7801 DevP2P protocol also provides a peer-to-peer solution for retrieval of this data.
eth protocolClients of the DevP2P eth protocol will need to upgrade to the new eth/69 version specified in EIP-7642
Consensus Layer clients have had a historical dependency on the deposit logs from pre-merge blocks. Dropping history would make these logs inaccessible to the Consensus Layer client. This issue is mitigated by EIP-6110
Execution clients that choose to drop history will no longer be capable of serving JSON-RPC requests for pre-merge requests for the following endpoints without sourcing the data from an alternate data source.
eth_getBlockTransactionCountByHasheth_getBlockTransactionCountByNumbereth_getUncleCountByBlockHasheth_getUncleCountByBlockNumbereth_getBlockByHasheth_getBlockByNumbereth_getTransactionByHasheth_getTransactionByBlockHashAndIndexeth_getTransactionByBlockNumberAndIndexeth_getTransactionReceipteth_getUncleByBlockHashAndIndexeth_getUncleByBlockNumberAndIndexExecution layer clients will no longer be able to implement a full historical sync of history from the DevP2P eth protocol. Clients that wish to retain this functionality will need to source the pre-merge blocks from an alternate source. Clients SHOULD ensure that they continue to correctly validate block data sourced from alternate locations.
Execution layer clients that do a partial sync will need to adjust their syncing algorithms to only go back to the merge block as opposed to the previous behavior of tracing all the way back to genesis. Clients SHOULD ensure that their sync algorithms and other functionality are able to handle this data no longer being locally available.
Copyright and related rights waived via CC0.