Vitalik Buterin outlines plan to make Ethereum purge

Ethereum’s creator Vitalik Buterin announced the network’s next step, which happens to be cutting off the extra weight. He calls it “The Purge.”

In the fifth blog post of his series, Vitalik laid out a ruthless plan to eliminate blockchain bloat, eliminate redundant features, and streamline the protocol. Ethereum’s network is clogged with outdated transactions and complicated legacy features.

The fix? Vitalik wants history and state data culled, protocol features simplified, and nodes made easier to run. This aggressive decision is a response to Ethereum’s rapid data growth.

Right now, a full Ethereum node requires over 1.1 terabytes of storage just for the execution client, with more for consensus data.

As transactions and accounts pile up, storage needs to grow, creating bottlenecks. Without changes, Ethereum risks becoming sluggish, with new clients facing painfully long sync times just to get up to date with the chain.

History expiry: Shrinking Ethereum’s memory load

Instead of every node holding every transaction ever recorded, Vitalik suggests nodes retain recent data only. Historical blocks, older transactions, and receipts get distributed across nodes in small portions.

To Vitalik, history data should operate like a torrent network—nodes store bits of data, ensuring data availability without one node holding everything. “We’re talking hundreds of gigabytes of old blocks piling up each year,” he said.

The current model, with nodes holding all data, has already been adjusted. Consensus blocks, vital for proof-of-stake, are stored for six months, while blobs—larger transaction data blocks—disappear after 18 days.

Vitalik’s new proposal, EIP-4444, pushes for a one-year storage cap on historical blocks and receipts. His end goal? A distributed network where each node stores just a fraction of history, using Merkle proofs and erasure coding to guarantee accuracy.

This distributed history storage won’t reduce Ethereum’s data reliability. Vitalik claims that by boosting node count, data copies will multiply across the network, making each fragment of history well-backed. 

Erasure coding will add resilience, similar to the tech that helps blobs stay available for data sampling. Vitalik also points to the Portal Network and peer-to-peer methods as possible solutions, letting Ethereum manage its data spread without relying on centralized storage.

State expiry: Limiting data permanence

Beyond history, Vitalik’s purge includes a more complicated beast: “state expiry.” Unlike history, state data (things like account balances, nonces, and smart contract storage) is harder to expire. Once created, a state object (such as an account with ETH or a contract’s storage slot) remains accessible to any transaction.

And with each object, Ethereum’s data grows. To contain this, Vitalik proposes automatic expiry, trimming data that hasn’t been touched recently.  The trick is balancing state expiry with Ethereum’s permanence. 

He believes that users should be able to “disappear for five years, come back, and still access their funds.” This system needs efficiency—no extra computations or complex models for developers.

Ethereum has tried various ideas like “blockchain rent,” which charged users to keep their data alive, and “regenesis,” which tried resetting the blockchain to reduce data. Neither took off.

Two new proposals target state bloat. First, there’s “partial state expiry.” The network would split data into chunks, storing only recent chunks while preserving “stubs” (small bits of inactive data) to prove existence. 

If a chunk gets deleted, users can revive it with proof of past data. Vitalik’s design proposal, EIP-7736, uses Verkle trees and a “stem-and-leaf” model to group data. Any data untouched for six months is removed, leaving behind just a stub to be restored when needed.

The second idea is address-period-based expiry, which divides state objects by time. Each account has an “address period,” and only data from the two most recent periods is stored.

If someone wants old data, they will submit a Merkle proof to reinstate it. This period-based setup will require changing address formats, expanding the current 20-byte format to include version numbers and periods.

Vitalik also suggests address space contraction to maintain compatibility. The challenge will then become making sure users understand and trust this period system without sacrificing Ethereum’s core promise of availability.

Feature cleanup: Trimming Ethereum’s code complexity

The final phase of the purge hits protocol complexity. Vitalik says, “Every new feature makes Ethereum harder to use, but removing anything is a nightmare.” The most infamous example is SELFDESTRUCT, an opcode that lets users delete contract storage. 

Originally, it allowed voluntary state clearing, but it’s mostly unused and risks denial-of-service attacks. Ethereum’s Dencun hard fork weakened the opcode, and Vitalik plans to remove it fully soon.

Other bloated features include old transaction types, redundant data formats, and a mixed-endianness protocol setup. These quirks make development confusing and Ethereum harder to upgrade.

Vitalik’s cleanup list also includes transitioning data formats from RLP to SSZ, simplifying gas rules to better manage block resources, and removing unused precompiles like RIPEMD160, MODEXP, and BLAKE. He also supports moving Ethereum to a stateless client model, which would eliminate storage burdens for most nodes.

Some of these changes will require account abstraction, allowing users to handle legacy transaction types through “default account EVM code.” This, Vitalik says, will simplify the Ethereum Virtual Machine (EVM) while cutting code size. Long-term, the EVM itself could get an upgrade.

He explains that Ethereum developers are considering a new execution model like RISC-V or Cairo, or possibly using an EVM Object Format (EOF) to standardize code rules. 

EOF changes gas rules and bans certain instructions to allow modular upgrades, boosting Ethereum’s scalability. This format will reportedly let developers make incremental improvements, ultimately helping Ethereum stay lean.

But Vitalik did give another option. He says , “A more radical Ethereum simplification strategy is to keep the protocol as is, but move large parts of it from being protocol features to being contract code.”