Buterin mapped an Ethereum “Purge” to curb node storage and protocol bloat

Ethereum co-founder Vitalik Buterin published a detailed account of “The Purge” on October 26, 2024, setting out possible ways to prevent Ethereum’s storage burden and protocol complexity from increasing indefinitely.

The essay was the fifth installment in Buterin’s October 2024 series on possible futures for Ethereum. It did not announce a hard fork, an implementation decision or an activation date. Instead, it organized several existing research tracks into a long-term objective: make nodes easier to operate and clients easier to maintain without abandoning Ethereum’s promise that applications and records should remain verifiable.

That distinction mattered. Buterin was influential in Ethereum research, but he could not unilaterally change the network. Any concrete proposal would still require specifications, client implementations, testing and agreement among the protocol’s distributed development community.

Why storage had become a roadmap issue

Buterin estimated on October 26 that a fully synchronized Ethereum execution client required roughly 1.1 terabytes of disk space, with a consensus client adding several hundred gigabytes. He attributed approximately 800 gigabytes of the execution requirement to historical data and about 300 gigabytes to state.

Those figures were contemporaneous approximations rather than a standardized benchmark. Actual storage depended on the client, configuration, database behavior, pruning settings and synchronization method. Their importance was therefore directional: a node’s resource requirements could keep rising even if Ethereum’s block-gas limit remained unchanged.

History and state also presented different engineering problems. Historical blocks, transactions and receipts are needed for looking backward, but they are not all required to validate the next block once a node has reached the chain tip. State—balances, nonces, contract code and contract storage—can be accessed by future transactions and is consequently harder to discard.

History expiry and EIP-4444

For historical data, Buterin highlighted EIP-4444, a networking proposal created on November 2, 2021. Its specification called for execution clients to stop serving headers, block bodies and receipts older than one year through Ethereum’s peer-to-peer layer, while allowing clients to prune that material locally.

The proposal did not mean erasing Ethereum’s history. Older records could remain with archive operators or be distributed through systems such as torrents, IPFS or the Portal Network. A requester could verify supplied records against commitments in the canonical chain. The unresolved institutional question was who would preserve and reliably serve that history if ordinary nodes stopped carrying complete copies.

Buterin argued that EIP-4444 would require coordinated client and networking work even though it did not itself require a hard fork. Activating pruning before decentralized retrieval infrastructure was dependable could increase reliance on centralized data providers—the opposite of the accessibility objective.

State expiry remained the harder choice

The essay treated state expiry as less settled. Buterin estimated that state alone was growing by about 50 gigabytes per year. He described alternatives ranging from accepting continued state growth alongside stateless validation to expiring inactive state chunks and restoring them when a user supplied a proof.

Each route carried compatibility or operational costs. Existing contracts assumed persistent storage and fixed address behavior. Buterin therefore presented state expiry as a collection of research choices, not as a finished specification ready for adoption.

Simplification beyond storage

“The Purge” also addressed accumulated protocol features. Buterin pointed to restricted `SELFDESTRUCT` behavior as a precedent for retiring problematic functionality, then discussed possible future cleanup involving transaction types, serialization formats, log bloom filters, precompiles, gas accounting and consensus-layer committees.

EIP-7668 illustrated that approach by proposing empty bloom-filter fields because most applications were already using external indexing services instead of node-level bloom queries. But the proposal acknowledged that applications depending on those filters would break.

The October 26 record was therefore consequential as a design framework, not a completed upgrade. It made the tradeoff explicit: Ethereum could reduce the cost of independent verification and the surface for implementation bugs, but only if preservation, compatibility and data availability were addressed before old responsibilities were removed from ordinary nodes.