Ethereum’s long-term sustainability hinges on a critical challenge: reversing the natural tendency of blockchain protocols to grow increasingly bloated and complex over time. Left unchecked, this expansion threatens decentralization, security, and accessibility. Enter The Purge—a pivotal phase in Ethereum’s roadmap focused on reducing protocol complexity and data bloat while preserving the network’s core strength: permanence.
Imagine storing a digital love letter in a transaction, sealing it in a vault, and returning a decade later to find it unchanged and fully interactive. This is the promise of Ethereum. Decentralized applications (DApps) rely on this immutability, especially when removing upgrade keys to achieve full decentralization. They must trust that Layer 1 will not evolve in ways that break their dependencies.
The Purge aims to strike this delicate balance—maintaining continuity while aggressively minimizing bloat and complexity. Biological systems show it's possible: while most organisms age, some achieve biological immortality. Social systems, like Japan’s Ise Shrine rebuilt every 20 years for over a millennium, demonstrate enduring renewal. Ethereum has already made progress: Proof-of-Work is gone, the SELFDESTRUCT opcode is deprecated, and beacon chain nodes now store only six months of data.
Now, The Purge seeks to systematize this renewal for long-term stability.
Core Objectives of The Purge
- Reduce client storage requirements by minimizing or eliminating the need for every node to permanently store full historical data or even final state.
- Lower protocol complexity by removing obsolete or redundant features.
These goals are pursued through three key initiatives: History Expiry, State Expiry, and Feature Cleanup.
History Expiry: Streamlining Data Storage
What Problem Does It Solve?
As of 2025, a fully synced Ethereum node requires approximately 1.1 TB of disk space for execution clients, with consensus clients adding hundreds of GB more. The vast majority of this data is historical—blocks, transactions, and receipts from years past. Even with unchanged gas limits, node size grows by hundreds of GB annually.
This unsustainable growth threatens network decentralization by increasing hardware requirements for validators and full nodes.
How Does It Work?
A key insight enables history expiry: consensus on the latest block implies consensus on the entire chain history. Thanks to cryptographic hashing and structures like those in EIP-4788, any participant can provide a historical transaction with a Merkle proof, allowing others to verify its authenticity independently.
This shifts the model from "every node stores everything" to a distributed storage network, akin to BitTorrent. Instead of each node holding all 1.1 TB, nodes could store random 10% segments. With 100,000 such nodes, each piece of data would still be replicated 10,000 times—matching today’s redundancy.
👉 Discover how decentralized networks maintain data integrity with minimal overhead.
Ethereum has already begun this transition:
- Consensus blocks: stored for ~6 months
- Blobs: stored for ~18 days
- EIP-4444: proposes a 1-year retention period for historical blocks and receipts
The long-term vision is a unified expiry window (~18 days), followed by distributed archival via peer-to-peer networks like the Portal Network. Erasure coding—already used for blobs—can enhance robustness without increasing replication costs.
Key Research & Development Links
Remaining Challenges and Trade-offs
The primary task is building and integrating a distributed storage solution—initially for execution history, eventually for consensus and blob data. Two main paths exist:
- Leverage existing torrent libraries
- Deploy the native Portal Network
EIP-4444 requires no hard fork but needs new network protocol versions. Coordinated client adoption is essential to prevent sync failures.
The deeper question is how much effort to invest in preserving "ancient" history:
- Minimal approach: Stop storing old history; rely on archival nodes and centralized providers.
- Robust approach: Build distributed archival infrastructure first.
Two dimensions define this effort:
- Ensuring maximum node participation in storage
- Integrating archival deeply into protocol sync mechanisms
Advanced solutions like Proofs of Custody could require validators to store historical segments, verified cryptographically. A lighter standard might set voluntary storage percentages per client.
👉 Explore how next-gen blockchain networks are redefining data permanence.
State Expiry: Managing Ever-Growing State
The Challenge
Even with history expiry, Ethereum’s state—account balances, contract code, storage—grows by ~50 GB per year. Users pay once but impose eternal costs on the network.
State expiry is harder than history expiry because the EVM assumes state objects persist forever. While statelessness could shift storage burden to specialized block builders, relying solely on it risks centralization. Hence, state expiry remains crucial.
Proposed Solutions
Partial State Expiry
State is divided into chunks ("stems"). A top-level map tracks which stems are active. Data within stems expires after inactivity (e.g., 6 months), leaving only a 32-byte "stub." Accessing expired data requires a "revival" transaction with a proof.
EIP-7736 implements this using Verkle tree stems (~7936 bytes), grouping account headers, code, and storage slots. Revival ensures user access even after long absences.
Address-Cycle-Based State Expiry
To avoid even stubs, Ethereum could maintain a list of growing state trees, one per cycle (e.g., yearly). Only the latest two trees are stored fully. Accessing older state requires a Merkle proof, which then revives the object in the current tree.
The address cycle mechanism ensures usability: addresses with cycle N can only be accessed in cycle N or later. New objects are stored in current or recent cycles, avoiding proof requirements for fresh deployments.
However, this requires expanding address size beyond 20 bytes, introducing backward compatibility challenges.
Address Space Expansion vs. Contraction
- Expansion: Introduce 32-byte addresses with version, cycle number, and extended hash.
- Contraction: Reserve certain 20-byte addresses (e.g., starting with
0xffffffff) for cycle-based addresses with shorter hashes.
Contraction risks collision attacks on counterfactual addresses (e.g., contracts not yet deployed). While currently requiring ~2^80 hashes, contraction could reduce this to 2^56—within reach of well-resourced attackers.
Remaining Paths Forward
- Adopt statelessness only – Accept slow state growth (~8 TB in decades).
- Partial state expiry – Accept low but non-zero growth.
- Address expansion – Multi-year transition for safety.
- Address contraction – Multi-year risk mitigation.
Notably, address collision risks must be solved regardless—computational advances make 2^80 increasingly feasible.
Feature Cleanup: Simplifying the Protocol
Complexity undermines security and accessibility. Ethereum must actively prune obsolete features.
Key Simplification Opportunities
Outside EVM
- RLP → SSZ: Replace legacy RLP encoding with efficient SSZ.
- Remove old transaction types: Or handle via account abstraction.
- Log reform: Remove Bloom filters (unused); use SNARK-based off-chain log readers.
- Eliminate sync committees: Replace with SNARK-based light client proofs.
- Unify data formats: Merge Merkle Patricia Trees, SSZ, and KZG into one standard.
- Remove beacon chain committees: Obsolete due to L2/blobs.
- Eliminate mixed endianness: Standardize on big-endian (EVM default).
Inside EVM
- Simplify gas mechanics: Unify storage costs; fix memory pricing.
- Remove unused precompiles: Identity, RIPEMD160, MODEXP.
- Make gas non-observable: Breaks some apps but enables future upgrades.
- Improve static analysis: Ban dynamic jumps; enforce EOF.
Balancing Act: Innovation vs. Backward Compatibility
Ethereum’s value lies in reliability—but not at all costs. As William Jennings Bryan warned of the gold standard, we shouldn’t “crucify Ethereum upon a cross of backward compatibility.”
A structured deprecation process—like that used for SELFDESTRUCT—can guide removals:
- Propose removal
- Analyze impact
- Deprecate via EIP
- Remove after years-long transition
The Role of EOF
EVM Object Format (EOF) introduces stricter rules: no gas observation, static jumps only. It enables safer upgrades but adds complexity unless legacy EVM is eventually phased out.
Frequently Asked Questions (FAQ)
What is The Purge in Ethereum’s roadmap?
The Purge refers to Ethereum’s long-term initiative to reduce protocol bloat and complexity by expiring historical data, managing state growth, and removing obsolete features—ensuring sustainable decentralization.
How will history expiry affect blockchain permanence?
While full history won’t be stored by every node, cryptographic proofs ensure verifiable access. Distributed networks like Portal will preserve data integrity without centralization.
Will state expiry cause users to lose funds?
No. Designs like partial expiry and address cycles ensure user funds remain accessible even after long inactivity through revival mechanisms requiring Merkle proofs.
Why remove features like SELFDESTRUCT?
SELFDESTRUCT enabled DoS attacks and increased client complexity. Its removal simplifies codebases and improves security without significant user impact.
How does The Purge support scalability?
By reducing storage and computational burdens on nodes, The Purge lowers barriers to entry—enabling more participants and paving the way for higher throughput and broader adoption.
Could Ethereum run on a smartwatch after The Purge?
With combined statelessness and history expiry, Ethereum nodes could require only gigabytes of storage and minutes to sync—making lightweight devices viable validators.
👉 Learn how cutting-edge blockchain upgrades are shaping the future of decentralized networks.