Ethereum Implements Partial History Expiry to Optimize Node Storage

Ethereum has announced a significant update to its network with the implementation of partial history expiry, in line with Ethereum Improvement Proposal (EIP) 4444. This change, which took effect as of July 8, 2025, allows all Ethereum execution clients to reduce the storage requirements for running a node by 300-500 gigabytes. This reduction is achieved by removing block data prior to the Ethereum Merge, enabling nodes to operate efficiently on a 2 TB disk, according to Ethereum’s official blog.

Understanding Blockchain History

The blockchain’s history is essentially a continuous chain of blocks starting from a defined genesis point, which for Ethereum occurred on July 30, 2015. Each block contains critical information such as protocol details, user transactions, and transaction receipts. While this historical data is crucial for full validation and index construction, it is not regularly accessed by everyday Ethereum users. Instead, it serves more advanced users and developers for tasks such as validating Layer 2 solutions or accessing past state data through archive nodes.

Adapting to Proof-of-Stake

With Ethereum’s transition from proof-of-work to proof-of-stake during the Merge, the network’s syncing strategy has evolved. Previously, full validation from genesis was necessary to verify the integrity of the chain. However, the introduction of proof-of-stake allows for a weak subjectivity checkpoint, reducing the need for nodes to fully verify every block from genesis. This change supports the new reverse sync strategy, minimizing the need for nodes to download and store over 1 TB of unused data.

Ensuring Data Availability

Despite the reduction in stored data, Ethereum ensures high availability of historical data through various channels. These include institutional providers hosting archives, torrent-based decentralized hosting, and the peer-to-peer network. This distributed approach maintains the network’s integrity and accessibility, with Ethereum nodes still capable of retrieving historical data when necessary, ensuring a robust security model.

Client-Specific Implementations

Each Ethereum execution client has implemented the partial history expiry differently. For instance, Go-ethereum supports pruning from version v1.16.0, while Nethermind activates history expiry by default from version 1.32.2. Similarly, Besu and Erigon have introduced their own methods for pruning pre-merge data as of versions 25.7.0 and v3.0.12, respectively. These updates allow node operators to manage disk space more efficiently without compromising the network’s operational capacity.

For developers and node operators, these changes mark a step towards a more scalable and efficient Ethereum network, aligning with the broader goals of decentralization and accessibility that define blockchain technology.

Image source: Shutterstock