The Future of the Ethereum Protocol: The Purge

The Future of the Ethereum Protocol: The PurgeOne of the challenges facing Ethereum is that any blockchain protocol, by default, tends to bloat and become more complex over time. This manifests in two primary ways:1

The Future of the Ethereum Protocol: The Purge

One of the challenges facing Ethereum is that any blockchain protocol, by default, tends to bloat and become more complex over time. This manifests in two primary ways:

1. Historical Data: Every transaction and account ever created at any point in history needs to be permanently stored by every client and downloaded by any new client fully syncing with the network. This results in ever-increasing client burdens and sync times over time even if the chain's capacity remains the same.

2. Protocol Features: It is much easier to add new features than it is to remove old ones, leading to code complexity increasing over time.

For Ethereum to be sustainable long-term, we need to apply strong counter-pressure against both of these trends, reducing complexity and bloat over time. But at the same time, we need to preserve one of the key properties of blockchains: permanence. You can put an NFT, a love letter in your transaction call data, or a smart contract containing a million dollars on chain, go into a cave for ten years, and come out to find it still there for you to read and interact with. For dapps to be comfortable going fully decentralized and deleting their upgrade keys, they need to be sure that their dependencies won't be upgraded in such a way as to break them - especially L1 itself.

The Purge is a part of Ethereum's roadmap for 2023 aiming to address the aforementioned problems and minimize or reverse bloat, complexity, and decay, while maintaining continuity.

The Purge: Key Objectives

The Purge's main objectives are:

1. Reduce client storage requirements: This will be achieved through a reduction or elimination of the need for each node to permanently store all history, and potentially eventually even lowering protocol complexity by eliminating unneeded functionalities.

2. Historical data expiration: This tackles the growing client burden and sync times arising from constant historical data accumulation.

3. State data expiration: This addresses the fact that even if we eliminate the need for clients to store history, client storage requirements will continue to grow as the state grows.

4. Feature cleanup: This addresses the problem of the protocol becoming increasingly complex over time, aiming to reduce protocol complexity by removing unnecessary old features.

Historical Data Expiration

Problem:

As of this writing, a fully synced Ethereum node requires approximately 1.1TB of disk space just for the execution client and another few hundred GB for the consensus client. The vast majority of this is historical data: data about historical blocks, transactions, and receipts, most of which are years old. This means that even if gas limits don't increase at all, the size of a node will increase hundreds of GB per year.

Solution:

Since each block points to the previous one via hash linking (and other structures), it's sufficient to have consensus on the current block to have consensus on the historical ones. As long as the network has consensus on the latest block, any historical block, transaction, or state (account balance, random numbers, code, storage) can be provided by any one participant with a Merkle proof, and that proof allows anyone else to verify that it's correct.

Implementation:

• Use the peer-to-peer network of Ethereum nodes to store old data in a distributed fashion.

• Use erasure coding to increase robustness while keeping the replication factor constant.

• Reuse erasure coding for blob data and also put execution and consensus block data into blobs.

Research:

• EIP-4444: https://eips.ethereum.org/EIPS/eip-4444

• Torrents and EIP-4444: https://ethresear.ch/t/torrents-and-eip-4444/19788

• Portal Network: https://ethereum.org/en/developers/docs/networking-layer/portal-network/

• Portal Network and EIP-4444: https://github.com/ethereum/portal-network-specs/issues/308

• Distributed Storage and Retrieval of SSZ Objects for Portal Network: https://ethresear.ch/t/distributed-storage-and-cryptographically-secured-retrieval-of-ssz-objects-for-portal-network/19575

Tradeoffs:

• How hard to make "past" historical data available.

• The most rigorous approach would involve proof of custody, requiring each Proof-of-Stake validator to store a proportion of history and being cryptographically checked periodically to see if they do so.

• A more lenient approach would set a voluntary standard for how much history each client stores.

Interaction with other parts of the roadmap:

Reducing historical storage requirements will be crucial in making it exceptionally easy to run or spin up a node, even more so than statelessness. The vision of Ethereum nodes running on smartwatches and taking only minutes to set up can only be realized if both statelessness and EIP-4444 are implemented concurrently.

State Data Expiration

Problem:

Even if we eliminate the need for clients to store history, client storage requirements will continue to grow as the state grows: account balances and random numbers, contract code, and contract storage. A user can pay a one-time fee and forever burden present and future Ethereum clients.

Solution:

Introduce a mechanism by which state objects automatically expire over time, ensuring that it is efficient, user-friendly, and developer-friendly.

Implementation:

• Partial state expiration: Divide the state into chunks, with everyone permanently storing a "top-level map" of which chunks are empty or non-empty. The data within each chunk is only stored if it is recently accessed, with a "revival" mechanism provided.

• Address-cycle-based state expiration: Use a constantly growing list of state trees, adding a new empty state tree every cycle, with older state trees being fixed. Full nodes would only need to store the most recent two trees.

Research:

• Blockchain Rental Fees: https://github.com/ethereum/EIPs/issues/35

• Regenesis: https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582

• Ethereum State Size Management Theory: https://hackmd.io/@vbuterin/state_size_management

• Several Possible Paths for Statelessness and State Expiry: https://hackmd.io/@vbuterin/state_expiry_paths

• Partial State Expiration Proposal EIP-7736: https://eips.ethereum.org/EIPS/eip-7736

• Address Space Extension Document Original Proposal: https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485

• Ipsilon Review: https://notes.ethereum.org/@ipsilon/address-space-extension-exploration

• Blog Post Review: https://medium.com/@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6

• What Would Break If We Lose Address Collision Resistance: https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356

Tradeoffs:

• How to balance efficiency, user-friendliness, and developer-friendliness in a state expiration scheme.

• How to approach the tricky problem of address space expansion and contraction to ensure backward compatibility.

Interaction with other parts of the roadmap:

Implementing state expiration may make the transition from one state tree format to another easier, as no need for this transition process may be needed.

Feature Cleanup

Problem:

The protocol becomes increasingly complex over time, which degrades security, accessibility, and trust neutrality.

Solution:

Remove unnecessary old features, reducing protocol complexity.

Implementation:

• Remove the SELFDESTRUCT opcode.

• RLPSSZ conversion.

• Remove old transaction types.

• LOG reform.

• Eventually retire the beacon chain sync committee mechanism.

• Data format harmonization.

• Remove beacon chain committees.

• Remove mixed endianness.

• Simplify gas mechanism.

• Remove precompiles.

• Remove gas observability.

• Static