Ethereum Execution Clients Implement Partial History Expiry to Reduce Node Storage Requirements

As of today, all Ethereum execution clients have implemented support for partial history expiry in accordance with EIP-4444. This development is expected to significantly reduce the disk space required for an Ethereum node by approximately 300-500 GB. The reduction is achieved by removing block data prior to the Merge, allowing a node to fit comfortably on a 2 TB disk. Further details on each specific client can be found here.

By definition, a blockchain is a chain of blocks starting at a specific genesis point. For Ethereum, this genesis occurred on July 30, 2015. Each block contains information about the protocol, such as the current gas limit, a list of user transactions, and the results of those transactions encapsulated by a receipt. While this historical data is not regularly consumed by typical Ethereum users, it serves more sophisticated users and developers.

Accessing a current balance, executing a trade, or borrowing assets will not be interrupted by history expiry. Accounts that have been dormant since genesis are also unaffected, as the state for every account continues to be maintained. However, only the current state is preserved, making it difficult to determine a user’s balance at a specific point in the past without an archive node, which has specialized indexes for such queries.

Changes in Ethereum Node Synchronization

When Ethereum launched with proof-of-work, full validation from genesis was the default. Over time, clients implemented snap sync and other syncing styles, allowing them to jump to the head of the chain based on the heaviest chain rule. With the transition to proof-of-stake and the Merge, the syncing strategy evolved. Clients now anchor to a recent trusted checkpoint, known as a weak subjectivity checkpoint, to prevent long-range attacks from exited validators.

This change in strategy has led to the adoption of a reverse sync method, where clients walk the chain backwards toward genesis to download history. As most clients no longer fully execute the chain, there is little reason to force every Ethereum node to download over 1 TB of unused data from the peer-to-peer network. The introduction of history expiry maintains a 1-of-N trust assumption, ensuring nodes can retrieve history via out-of-protocol means if at least one entity provides the historical blocks.

Client-Specific Implementation Details

Each Ethereum execution client supports running without pre-Merge data, though the process varies by client. For instance, Go-ethereum supports this feature as of version v1.16.0, while Nethermind has activated it by default in version 1.32.2. Besu and Erigon have also incorporated history expiry in their latest versions, with specific instructions available in their respective documentation.

It is important to note that only Mainnet and Sepolia have a non-Merge chain prefix, making pruning possible only on these chains. The non-Merge chain prefix in Sepolia is relatively small, so pruning may have a limited impact on the total disk size required by each client.

Why This Matters: Impact, Industry Trends & Expert Insights

Ethereum execution clients have implemented partial history expiry, significantly reducing node storage requirements by approximately 300-500 GB. This development allows nodes to operate more efficiently, fitting comfortably on a 2 TB disk.

Recent industry reports indicate that EIP-4444, which introduces partial history expiry, aims to reduce the storage burden on Ethereum nodes by limiting retention of historical data. This aligns with the recent implementation, as it reduces the disk space required for Ethereum nodes, enhancing decentralization by potentially encouraging more participants to run nodes.

As per insights from Galaxy Insights, history expiry allows nodes to prune old data, significantly decreasing storage needs and freeing up resources for client software innovation. This supports the impact of the news event by highlighting the enhanced efficiency and scalability of Ethereum nodes through this implementation.

Disclaimer: The views expressed in this article are those of the authors and do not necessarily reflect the official policy of CoinsHolder. Content, including that generated with the help of AI, is for informational purposes only and is not intended as legal, financial, or professional advice. Readers should do their research before taking any actions related to the company and carry full responsibility for their decisions.