Skip to content

EIP-4444

EIP-4444

Overview

EIP-4444 (Bound Historical Data in Execution Clients) is an Ethereum improvement proposal aimed at reducing node storage requirements by limiting the historical data stored by execution clients. The proposal requires clients to stop serving block headers, block bodies, and receipts older than one year at the P2P layer, and allows clients to prune this historical data locally.

This proposal is an important step toward Ethereum's sustainable development. By reducing historical data storage, it lowers the hardware threshold for running a full node, enabling more people to participate in network validation.

Core Motivation

Storage Pressure Problem Historical blocks and receipts currently consume over 400 GB of disk space (and continue to grow), which typically requires users to have a 1 TB disk to validate the chain. As the network continues to operate, this number keeps increasing, placing an enormous storage burden on node operators.

Non-Essential Nature of Historical Data Historical data is not essential for validating new blocks. Once a client is synced to the tip of the chain, historical data is only retrieved when: - Explicitly requested via JSON-RPC - Peer nodes are attempting to sync the chain

For most routine validation operations, this historical data is unnecessary.

Implementation Details

Data Pruning Strategy Clients can choose to prune data older than a specified period (typically one year): - Historical block headers - Block bodies - Transaction receipts

P2P Layer Changes Execution clients will no longer serve old historical data at the P2P layer, meaning new nodes cannot perform a full historical sync via the traditional devp2p protocol.

Weak Subjectivity Checkpoints New nodes must use a valid Weak Subjectivity Checkpoint to bootstrap from a more recent view of the chain, rather than syncing from the genesis block.

Implementation Status

2025 Progress As of July 2025, all Ethereum execution clients support partial history expiry functionality compliant with EIP-4444: - Geth - Besu - Nethermind - Erigon

Storage Savings Users can expect to reduce disk space requirements by 300-500 GB by deleting block data from before The Merge. While the full rolling history expiry work is still in progress, partial implementation has already significantly improved the storage situation.

Historical Data Preservation

Distributed Storage Solutions Preserving Ethereum history is crucial. EIP-4444 does not mean the loss of historical data, but rather the adoption of distributed out-of-band storage methods:

  • Torrent Networks: Historical data can be packaged and shared via BitTorrent magnet links
  • *IPFS*: Leveraging the InterPlanetary File System's decentralized storage
  • Portal Network: A network specifically designed for light client access to historical data
  • The Graph: Accessing historical blockchain data through indexing services
  • Archive Nodes: Specialized archive nodes can choose to retain the full history

Data Retrievability Although regular validation nodes no longer mandatorily retain the full history, historical data remains accessible through multiple channels, ensuring Ethereum's historical auditability and transparency.

Impact on the Ecosystem

Node Operators - Reduced hardware costs: TB-level storage is no longer required - Lower barriers to entry: More people can run full nodes - Faster sync: Initial sync time is significantly reduced

Application Developers - Historical data queries need adjustment: Cannot rely on all nodes having the complete history - Need to use specialized archival services: Such as Infura or Alchemy archive nodes - RPC call behavior changes: Some historical queries may fail

Block Explorers Block explorers (such as Etherscan) need to run archive nodes or use alternative data sources to provide full historical data access.

Technical Considerations

Sync Mechanism Changes Traditional full sync will no longer be viable. New nodes need to: 1. Obtain a weak subjectivity checkpoint from a trusted source 2. Begin syncing from the checkpoint rather than the genesis block 3. Validate all blocks after the checkpoint

Security Guarantees The security of weak subjectivity checkpoints relies on: - Community consensus and transparency - Cross-verification from multiple independent sources - Client-embedded checkpoint verification mechanisms

Future Outlook

Full Implementation The full implementation of EIP-4444 includes Rolling History Expiry, which automatically deletes historical data beyond a set time window. This work is still ongoing.

Synergies with Other Proposals EIP-4444 synergizes with other Ethereum scalability proposals: - EIP-4844 (Blob data): Blob data is inherently designed for temporary storage - Danksharding: Future sharding schemes also rely on similar data expiry mechanisms - Portal Network: Provides historical data access for light clients

Long-Term Vision Through EIP-4444, Ethereum moves toward a more sustainable, more decentralized direction, lowering the threshold for participating in network validation while ensuring historical data availability through distributed storage solutions.