Original translation: GaryMa Wu speaks about blockchain

Vitalik has mentioned a topic recently at the Korean Blockchain Week, Singaporean speeches, and the Ethereum Core Developers Meeting (ACDE): state. Along with it are various related solution concepts, such as statelessness, state expiry, history expiry (EIP-4444), Verkle tree, and address space expansion/compression. Of course, this is not a new roadmap adjustment. These mainly belong to The Verge and The Purge key routes, which Vitalik released in the latest Ethereum roadmap in November last year.

This article combines these two key routes and some new challenging ideas to review the state resolution route in Vitalik's mind.

State

The state in Ethereum refers to a comprehensive ledger that includes all external owned accounts (EOAs), their balances, smart contract deployments, and related storage. This state is not static; it expands continuously with the addition of new users and the deployment of new smart contracts.

Currently, full nodes must store this growing dataset to correctly verify blocks and ensure correct state transitions, making the validation process essentially stateful. However, this growing storage requirement increases the hardware requirements for running full nodes and leads to increasing centralization of validators.

According to etherscan.io data, running a fast-synced full node currently requires at least 1200 GB (using the Geth client as an example), even after performing state pruning and deleting older state data, and only keeping the latest state. If it's an archive node that keeps all historical states, including the state of each block, it would require around 15,400 GB of storage, and this requirement will continue to grow due to the so-called "state explosion" in the community.

This is also emphasized by Vitalik during the Korea Blockchain Week: the centralization of nodes is one of the biggest issues Ethereum network faces, and it should be addressed by making node operation cheaper and easier.

To address these challenges, the Ethereum community has been actively seeking improvements and optimization methods, such as the various solution concepts mentioned earlier.

State Solutions

Statelessness

The core concept of statelessness is externalizing state data, eliminating the need for each node to store the complete state. In this model, nodes only need to maintain block headers and related transaction information, and validate and reconstruct the state using state proofs.

The main purpose and significance of statelessness are to reduce the storage burden on nodes, improve network scalability, allow more nodes to participate in validation easily, while still maintaining Ethereum's decentralization.

Verkle Tree

Currently, Ethereum relies on Merkle-Patricia trees to hash and compress its state data. However, the size of Merkle proofs in this tree structure may become too large, making them less suitable for the witness needed in stateless models.

To address this issue, Ethereum plans to transition to Verkle trees, which are more efficient data structures. Both Merkle-Patricia trees and Verkle trees share an important capability of generating witnesses - cryptographic proofs that allow anyone to easily confirm the existence and public availability of specific information in the state root.

The advantage of Verkle trees is their efficiency in generating smaller proof sizes.

History Expiry (EIP-4444)

EIP-4444 aims to implement historical data expiration, an upgrade that requires nodes to stop hosting historical blocks on the peer-to-peer network for more than one year. Deleting historical data significantly reduces disk space requirements for node operators. Additionally, it simplifies client software by eliminating the need to accommodate different versions of historical blocks. Furthermore, the combination of EIP-4444 and PDS (Proto-danksharding) ensures regular data pruning. EIP-4444 trims the data once a year, while PDS trims it monthly. Although this helps reduce the storage needs of nodes, it also raises concerns about preserving and recovering historical data.

State Expiry

Statelessness eliminates the need for validators to maintain a complete state when validating blocks. However, the state is not lost; its continuous growth remains a long-term challenge for the network.

To address this fundamental issue, the community has proposed a solution called State Expiry.

State Expiry automatically prunes the parts of the state that remain unchanged, such as after a year, and moves them to a separate tree structure, removing them from the main Ethereum protocol.

It is worth mentioning that State Expiry only becomes feasible with the transition to Verkle trees. Additionally, Vitalik stated at the Korea Blockchain Week KBW 2023 that if there is statelessness and PBS, State Expiry can be of lower priority.

Because if, at that time, Proposer-Builder Separation (PBS) is implemented, under statelessness, although block builders still need access to the state to create blocks, it is expected that the block builders can effectively handle the growth of the state, as this field allows a certain degree of centralization, and the performance of their nodes can naturally meet the requirements.

Although protocol-level PBS has not yet been incorporated into the Ethereum mainnet, we can roughly infer a trend for the future mainnet by understanding the current market distribution of Mev-Boost PBS. The data provided by mevboost.pics is as follows:

In addition, the implementation of State Expiry involves changes to the Ethereum address format, and there are currently two options: address space extension vs address space compression. The former involves increasing the address length to 32 bytes (the current address format is 20 bytes), but requires complex logic for backward compatibility and existing contracts must also be updated. The latter, while retaining the 20-byte format, uses the first 6 bytes for a prefix and the identification of address cycles. Although this greatly reduces compatibility issues, it also introduces another challenge: the address length is reduced to only 14 bytes, which no longer provides collision resistance, thereby introducing potential security issues in address creation. This is a major challenge currently faced by the community.

Summary

Now, based on the implementation difficulties and priorities of the technical solutions mentioned above, we can prioritize them as follows (2, 3, 4 can be considered equal):

1. Verkle Trees

2. PBS

3. Stateless

4. Historical Data Expiry (EIP-4444)

5. Changes in Ethereum Address Format (Compression / Extension)

6. State Expiry

In conclusion, this can lower the threshold for running nodes, maintain the decentralization of nodes, and address potential state explosion issues to optimize network communication load.

Of course, there is still a long way to go.

References:
https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356

https://public.bnbstatic.com/static/files/research/ethereum-beyond-the-merge-.pdf

https://www.fx168news.com/article/295525