Ethereum's Possible Future: The Purge

Since October 14, Ethereum founder Vitalik Buterin has been publishing a series of discussion articles on the future development of Ethereum, from "The Merge" to the latest "The Purge", showcasing his vision for the future development of the Ethereum mainnet and solutions to current issues.

The article "The Purge" explores how Ethereum can reduce complexity and storage requirements in the long term while maintaining the chain's durability and decentralization. Key measures include reducing client storage burdens through "historical expiry" and "state expiry," and simplifying the protocol through "feature cleanup" to ensure the sustainability and scalability of the network.

History expiry

What problem does it solve?

Currently, a fully synchronized Ethereum node requires approximately 1.1TB of disk space for the execution client, plus several hundred GB for the consensus client. The vast majority is historical data, and even if the Gas limit remains unchanged, the node size will increase by several hundred GB each year.

What is it and how does it work?

A key feature of historical storage is that achieving consensus on the current state is sufficient to achieve consensus on history. This provides various options for storing historical records, such as networks where each node only stores part of the data.

Ethereum has started to move away from the model where all nodes permanently store all history. Consensus blocks only store data for about 6 months, and Blobs for about 18 days. EIP-4444 aims to introduce a one-year storage period for historical blocks and receipts. The long-term goal is to establish a unified storage period of about 18 days, and then create a P2P network composed of Ethereum nodes to store old data in a distributed manner.

Erasure codes can be used to improve robustness while maintaining the same replication factor. The simplest solution may be to reuse the existing erasure codes of the Blob and also put execution and consensus block data into the blob.

What else needs to be done, what needs to be weighed?

The main tasks include building and integrating a specific distributed solution to store history. The simplest solution is to introduce an existing torrent library or the Ethereum native solution known as the Portal network.

The main trade-off involves how to strive to provide "ancient" historical data. The simplest solution is to immediately stop storing ancient history and rely on existing archive nodes. A safer but more difficult solution is to first build and integrate a torrent network.

interacts with other parts of the roadmap

Reducing historical storage requirements is crucial for making it extremely easy to run nodes. Only by achieving statelessness and EIP-4444 can the vision of running an Ethereum node on a smartwatch be realized.

Limiting historical storage also makes it more feasible for new Ethereum nodes that only support the latest protocol version, thereby simplifying the client.

State expiry

What problem does it solve?

Even if the demand for historical record storage is eliminated, the client storage requirements will still increase by about 50GB each year, as the state ( account balances, contract codes, etc. ) will continue to grow. Users can make a one-time payment, imposing a permanent burden on current and future customers.

What is it and how does it work?

The state is harder to "expire" than history, because the EVM assumes that state objects exist forever once created. The goal is to allow objects to automatically expire over time while maintaining efficiency, user-friendliness, and developer-friendliness.

There are mainly two types of solutions:

1. Partial state expiration: The state is chunked, only storing recently accessed data. EIP-7736 proposes a solution based on Verkle trees, with data not accessed for 6 months only storing a 32-byte root.

2. State expiration based on address cycles: Using a growing list of state trees, adding new empty trees each year. Full nodes only store the most recent two trees. Expired data requires proof to read and write.

What else needs to be done, what needs to be weighed?

Possible future paths include:

1. Achieve statelessness, without introducing state expiration. State continues to grow but only requires special user storage.

2. Implement partial state expiration, accepting a lower but non-zero permanent state growth rate.

3. Implement state expiration through address space expansion. It requires a multi-year process to ensure that the address format conversion is safe and effective.

4. Achieve state expiration through address space contraction. It requires a multi-year process to ensure all security risks are addressed.

Regardless of the solution adopted, it is necessary to address the challenges of expanding and contracting address space, as future address collision attacks will become easier.

Feature cleanup

What problem does it solve?

The simplicity of the protocol is key to security, accessibility, and trusted neutrality. However, protocols tend to become more complex over time by default. We need to be able to remove features and reduce complexity.

What is it and how does it work?

There is no single major fix that can reduce the complexity of the protocol; rather, many small solutions are needed. Some key examples include:

• RLP → SSZ conversion: Replace RLP encoding with better SSZ
• Remove old transaction types
• LOG Reform: Remove unused Bloom filters and other functions
• Remove the Beacon Chain Synchronization Committee mechanism
• Data format unified
• Delete Beacon Chain Committee
• Remove mixed byte order

Some examples in EVM:

• Simplified Gas Mechanism
• Delete the precompiled
• Remove gas observability
• Static analysis improvement: remove dynamic jumps

What else needs to be done, what needs to be weighed?

The main trade-off is between the level of simplification and speed versus backward compatibility. A standardized process needs to be created for non-urgent backward compatibility breaking changes, including steps such as impact analysis, formal EIP deprecation, and eventual removal.

The EVM object format ( EOF ) proposes a series of EVM changes aimed at enabling more upgrades. There is a need to balance the increased complexity against the goal of simplifying the entire EVM.

A more radical approach is to convert most of the protocol's content into contract code, such as turning the EVM into a summary or replacing the EVM with a new VM. This can greatly simplify the protocol, but it requires a trade-off in compatibility.