Partial history expiry announcement

Partial History Expiry Announcement: A New Era for Ethereum Nodes

As of today, all Ethereum execution clients support partial history expiry in accordance with EIP-4444. This significant update marks a major shift in the way Ethereum nodes store and retrieve historical data, with far-reaching implications for the network's scalability, security, and usability.

What is Chain History?

By definition, a blockchain is a chain of blocks starting at a specific genesis point. For Ethereum, that occurred on July 30, 2015. Each block includes information about the protocol itself, such as the current gas limit, a list of user transactions, and the result of those transactions encapsulated by a receipt. This data has many uses, including:

• Full validation of the chain requires executing every historical block to ensure that the current head state is correct and all historical states from genesis to today were correct.
• Constructing indexes over the chain history, such as tracking the balance changes of a certain account over time or how the state of a certain application changes.
• General proof-of-past operations, such as proving a certain transaction was sent at some point.
• In rare cases, non-fungible token (NFT) data.

However, accessing a current balance, executing a trade, borrowing assets, etc. will not be interrupted by history expiry. Accounts that have been dormant since genesis are also not affected, as the state for every account continues to be maintained. However, only the current state is maintained, and such queries require an archive node with specialized indexes capable of determining past state values.

Block Validation in Proof-of-Stake

When Ethereum launched with proof-of-work, full validation from genesis was the default. Later on, clients implemented snap sync and other similar styles of syncing where clients jumped to the head of the chain based on the heaviest chain rule, then proceeded to download all contracts and accounts state. Full syncing was retained for those who felt that the heaviest chain rule was not enough to verify the full integrity of the chain.

With the advent of proof-of-stake and the merge, the syncing strategy changed. Because signatures can be generated at basically no cost, clients need to anchor to a recent trusted checkpoint, also known as a weak subjectivity checkpoint. This allows new users to bootstrap to the chain without being tricked by hypothetical long-range attacks from validators who have exited the validator set long ago.

The Introduction of Subjectivity

The introduction of subjectivity further removes the need for users to fully verify every block in the chain, and so for many other reasons, clients adopted a new reverse sync strategy where they walk the chain backwards toward genesis to download the history. Now that most clients do not fully execute the chain, there is little reason to force every Ethereum node to download over 1 TB of data that is not used from the p2p network.

The Default Security Model of History Expiry

The default security model of history expiry does not change from the current status quo. Clients have not fully validated the chain from genesis for over 5 years. The execution layer will continue to provide all headers, which allows cryptographic verification of the chain from genesis. This helps avoid clients from accepting invalid historical data.

Availability, Guaranteed

Until today, every single node on the Ethereum network stored every block from genesis to the head. This provided an extremely high guarantee that history will be available for download by anyone at any time. We believe that it is possible to reduce the number of nodes storing all history while still ensuring high availability. We achieve this with the following distribution channels:

• Institutional providers: organizations who are willing to host historical archives on their own servers.
• Torrent: opt-in permissionless and decentralized hosting for archived history.
• Peer-to-peer network: the same retrieval mechanism as before, except peers who choose to not store the history will dilute the overall availability to some degree.

Client-Specific Commands

While this information is up-to-date as of publishing, commands and flags associated with a particular client are subject to changes. The most up-to-date information will always be each client's respective documentation.

Every full-node focused client supports running without pre-merge data, however the exact process is dependent on the client. Below are instructions to run a pruned node for every execution client.

Go-Ethereum

Available as of version v1.16.0. Full documentation available here.

For an existing node:

Shutdown geth gracefully.

Run the offline prune command geth prune-history --datadir=<path/to/data>

Start geth again.

For a new node:

Use the flag --history.chain postmerge to skip downloading the pre-merge blocks.

Nethermind

Activated by default as of version 1.32.2.

History will only be removed on a newly synced node. Automated pruning will be added in future versions. The full documentation is available here.

In order to disable history-expiry feature:

Use the flags --Sync.AncientBodiesBarrier 0 --Sync.AncientReceiptsBarrier 0.

Besu

Available as of version 25.7.0. Full documentation available here.

For an existing node, either:

Offline prune

Shutdown Besu gracefully.

Run the offline prune command: besu --data-path=<path/to/data> storage prune-pre-merge-blocks

Start Besu with --history-expiry-prune

Wait until all space has been reclaimed, approximately 24-48 hours.

Remove --history-expiry-prune and restart Besu. Online prune

Use the flag --history-expiry-prune when starting the client.

For a new node:

Use the flag --sync-mode=SNAP

Erigon

Available as of version v3.0.12

For new and existing nodes:

Use the flag --history-expiry when starting the client

Reth

Available as of version v1.5.0.

For new and existing nodes:

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

Conclusion

Partial history expiry is a significant update to the Ethereum network, marking a major shift in the way nodes store and retrieve historical data. This update has far-reaching implications for the network's scalability, security, and usability. With the introduction of subjectivity and the adoption of a new reverse sync strategy, clients no longer need to fully execute the chain, and the need to force every node to download over 1 TB of data is eliminated.

The default security model of history expiry remains the same, with clients continuing to provide all headers, which allows cryptographic verification of the chain from genesis. The introduction of institutional providers, torrent, and peer-to-peer network distribution channels ensures high availability of historical data.

As the Ethereum network continues to evolve, it is essential to stay up-to-date with the latest developments and updates. The instructions provided above are subject to change, and the most up-to-date information will always be available in each client's respective documentation.

The future of Ethereum looks bright, with partial history expiry marking a significant step towards a more scalable, secure, and usable network. As the network continues to grow and evolve, it is essential to stay informed and adapt to the changing landscape.

Source: https://blog.ethereum.org/en/2025/07/08/partial-history-exp