Upcoming Changes to Ethereum’s Historical Data Policies

As of now, every Ethereum execution client accommodates partial history expiry in compliance with EIP-4444. While efforts towards full, rolling history expiry continue, users can anticipate a reduction in the disk space needed for an Ethereum node by 300-500 GB by eliminating block data prior to the Merge. This enables a node to fit adequately on a 2 TB disk. Refer below for details on each individual client.

Chain history

A blockchain, by its nature, is an interconnected sequence of blocks originating from a designated genesis point. For Ethereum, this was marked on July 30, 2015. Each block carries details about the protocol itself, such as the existing gas limit, a compilation of user transactions, and the outcomes of those transactions encapsulated in a receipt. This information has various applications:

• Comprehensive validation of the chain mandates executing every historical block to confirm that not only is the current head state accurate, but all prior states from genesis to the present are correct.
• Creating indexes over the chain history, for example, tracking the balance modifications of a specific account over time or observing how the status of a specific application evolves.
• For layer 2 solutions that have submitted transactions using calldata, the chain history is necessary for complete validation of their chain or for constructing indexes.
• General proof-of-past operations such as confirming that a specific transaction was executed at a given time.
• In exceptional scenarios, non-fungible token (NFT) data. However, the dominant approach for hosting NFTs on-chain is to save the NFT data either in contract storage or refer to external sources, such as IPFS.

This historical data is not frequently leveraged by Ethereum users and tends to cater to more advanced users and developers. Accessing a present balance, conducting a trade, borrowing assets, etc., will remain unaffected by history expiry. Accounts that have remained inactive since genesis are also not influenced since the state for every account continues to be upheld. However, only the current state is preserved. Consequently, a user’s balance at a particular moment in the past cannot be easily determined from the history alone. Such inquiries necessitate an archive node with specialized indexes capable of ascertaining previous state values.

Block validation in proof-of-stake

Upon Ethereum’s launch with proof-of-work, comprehensive validation from genesis was standard. Subsequently, clients incorporated snap sync and other analogous sync methods where clients advanced to the head of the chain predicated on the heaviest chain rule and then continued to download all contracts and account states. Full syncing remained for those who believed that the heaviest chain rule was inadequate to guarantee the complete integrity of the chain.

With the emergence of proof-of-stake and the merge, the syncing approach has shifted. Since signatures can be generated at virtually no expense, clients must anchor to a recent reliable checkpoint, also referred to as a weak subjectivity checkpoint. This facilitates new users in connecting to the chain without being misled by potential long-range attacks from validators who exited the validator set long ago.

The introduction of subjectivity also diminishes the requirement for users to completely verify every block in the chain, and for various other reasons, clients have embraced a novel reverse sync strategy wherein they traverse the chain backward toward genesis to retrieve the history. Given that most clients do not fully execute the chain, there is minimal justification to compel every Ethereum node to download over 1 TB of extraneous data from the p2p network. Following history expiry, we uphold a 1-of-N trust assumption, akin to other networks, which asserts that if at least one entity supplies the historical blocks, nodes will be able to access the history via alternative protocols.

The default security framework of history expiry does not alter from the present condition. Clients have not fully verified the chain from genesis for more than 5 years. The execution layer will persist in supplying all headers that facilitate cryptographic validation of the chain from genesis. This assists in preventing clients from accepting invalid historical data.

Accessibility, assured

Up until today, every solitary node on the Ethereum network has retained every block from genesis to the head. This offered an exceedingly high assurance that the history would be obtainable for download by anyone at any time. We believe it is feasible to minimize the quantity of nodes preserving all history while still guaranteeing high accessibility. We accomplish this through the following distribution methods:

• Institutional providers — organizations prepared to host historical archives on their own servers.
• Torrent — optional permissionless and decentralized hosting for archived history.
• Peer-to-peer network — the same retrieval method as before, although peers who opt out of storing the history will reduce overall accessibility to a certain extent.

For a catalog of mirrors and torrent files, kindly visit the community-managed documentation https://eth-clients.github.io/history-endpoints/.

Client-specific commands

While this data is current as of publication, commands and flags associated with a specific client are open to modifications. The most current information will always be found in each client’s respective documentation.

Every full-node oriented client is capable of operating without pre-merge data, nonetheless, the precise procedure varies according to the client. Below are directives to operate a pruned node for each execution client. Please take note that only Mainnet and Sepolia feature a non-Merge chain prefix, hence pruning is solely viable on those chains. Furthermore, the non-Merge chain prefix in Sepolia is minor so pruning may have minimal impact on the total disk space required by each client.

Go-ethereum

Accessible since version v1.16.0. Complete documentation can be found here.

For an existing node:

1. Terminate geth gently.
2. Execute the offline prune command geth prune-history –datadir=/to/data>
3. Restart geth.

For a new node:

1. Utilize the flag –history.chain postmerge to bypass downloading the pre-merge blocks.

Nethermind

Enabled by default as of version 1.32.2.

History will solely be deleted on a freshly synced node. Automated pruning will be incorporated in future updates. The complete documentation is available here.

To disable the history-expiry feature:

1. Utilize the flags –Sync.AncientBodiesBarrier 0 –Sync.AncientReceiptsBarrier 0.

Besu

Available since version 25.7.0. Comprehensive documentation accessible here.

For an existing node, either:

Offline prune

1. Shut down Besu gently.
2. Execute the offline prune command: besu –data-path=/to/data> storage prune-pre-merge-blocks
3. Restart Besu with –history-expiry-prune
4. Wait until all space has been reclaimed, roughly 24-48 hours.
5. Eliminate –history-expiry-prune and reboot Besu.
   Online prune
6. Use the flag –history-expiry-prune upon launching the client.

For a new node:

1. Utilize the flag –sync-mode=SNAP

Erigon

Available from version v3.0.12

For newly created and existing nodes:

1. Utilize the flag –history-expiry upon starting the client

Reth

Available as of version v1.5.0.

For both new and existing nodes:

1. Utilize the flag –prune.bodies.pre-merge –prune.receipts.before 15537394 for Mainnet and –prune.bodies.pre-merge –prune.receipts.before 1450409 for Sepolia.