Ethereum node sync improved to under half a day with EIP-4444 optimizations

With the activation of EIP-4444 on July 8, 2025, Ethereum execution clients can now prune pre-Merge historical data, slashing storage requirements by 300 to 500 GB and enabling new nodes to sync in under half a day.

The result: operators can run a fully functional node on a 2 TB disk with aggressive settings keeping total storage under 0.5 TB.

What EIP-4444 actually changes

EIP-4444 introduces what’s called “partial history expiry.” Instead of requiring every node to store the complete history of the Ethereum blockchain, nodes can now drop older data after a defined retention period. The initial design specified roughly 33,000 epochs, but this was revised to approximately 82,000 epochs, or about one year of history.

Nodes validate the current chain head using weak subjectivity checkpoints. The consensus layer can sync in minutes through checkpoint sync, while the execution layer benefits from not needing to download and verify a decade of transaction receipts. Historical data retrieval mechanisms remain available as an optional feature for operators who need archival access.

All five major Ethereum execution clients have shipped support. Geth v1.16.0, Nethermind 1.32.2, Besu 25.7.0, Erigon v3.0.12, and Reth v1.5.0 each include the necessary flags and configurations.

Why storage was becoming a problem

Prior to EIP-4444, a full node needed more than 400 GB of disk space, and that number was only going in one direction. Every new block, every smart contract interaction, every token transfer added to the pile.

There’s an important distinction worth noting. This change affects full nodes and validators, not archive nodes. Archive nodes, which serve historical queries for block explorers and analytics platforms, will continue storing everything.

The accessibility equation

A sub-half-day sync on under 0.5 TB of storage means a relatively modest consumer-grade machine with a decent SSD can participate in Ethereum’s network, compared to the multi-day sync processes and terabyte-plus storage demands that previously greeted new node operators.

EIP-4444 sits within the “Purge” phase of Ethereum’s roadmap, which Vitalik Buterin has described as focused on reducing protocol complexity and node requirements.

The remaining question is how the network handles the transition period as nodes begin pruning at different rates and historical data becomes distributed rather than universally replicated. The Portal Network and other peer-to-peer data availability solutions are designed to fill this gap, ensuring that historical queries can still be resolved even when most nodes have moved on.