Ethereum's node infrastructure became significantly more accessible on July 8, 2025, with the activation of EIP-4444, which enables execution clients to prune pre-Merge historical data. The optimization reduces storage requirements by 300 to 500 GB and allows new nodes to synchronize in under half a day.
Node operators can now run a fully functional node on a 2 TB disk with aggressive settings, keeping total storage under 0.5 TB.
How EIP-4444 Works
EIP-4444 introduces "partial history expiry," allowing nodes to drop older data after a defined retention period rather than maintaining the complete blockchain history. 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 avoids downloading and verifying a decade of transaction receipts. Historical data retrieval mechanisms remain available as an optional feature for operators requiring archival access.
Client Support and Implementation
All five major Ethereum execution clients have shipped support for EIP-4444: 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.
Storage Challenge and Solution
Prior to EIP-4444, a full node required more than 400 GB of disk space, with storage demands continuously increasing with each new block and transaction. The optimization affects full nodes and validators but does not apply to archive nodes, which will continue storing complete historical data for block explorers and analytics platforms.
A sub-half-day sync on under 0.5 TB of storage means consumer-grade machines with adequate SSDs can now participate in Ethereum's network, a significant reduction from previous multi-day sync processes requiring terabyte-plus storage.
Network Considerations
EIP-4444 is part of the "Purge" phase of Ethereum's roadmap, focused on reducing protocol complexity and node requirements. The Portal Network and other peer-to-peer data availability solutions are designed to handle the transition as nodes begin pruning at different rates, ensuring historical queries can still be resolved when most nodes have moved on.
