What is the "stateless" that Vitalik frequently mentioned in recent speeches?

Compiled by: GaryMa, Wu Talk Blockchain

Vitalik has recently mentioned a common topic during the Korea Blockchain Week, his speech in Singapore, and the Ethereum Core Developers Meeting (ACDE): State, along with various related solution concepts such as Statelessness, State Expiry, History Expiry (EIP-4444), Verkle Trees, and even Address Space Expansion/Compression. Of course, this is not a new roadmap adjustment; these mainly belong to The Verge and The Purge key routes in the latest Ethereum roadmap released by Vitalik last November.

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

State

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

Currently, full nodes must store this ever-growing dataset to correctly validate blocks and ensure state transitions are accurate, making the verification process inherently stateful. This increasing storage requirement raises the hardware demands for running full nodes, leading to greater centralization of validators.

According to data from etherscan.io/, running a fast-sync full node currently requires at least 1200 Gb (using the Geth client as an example), even after state pruning, which deletes older state data and retains only the most recent state. If it is an archive node, meaning it retains all historical states, including the state of each block, the required capacity is about 15,400 Gb, and it will continue to grow in the future, commonly referred to in the community as "state explosion."

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

To tackle this series of challenges, the Ethereum community has been working hard to find ways to improve and optimize, namely the various solution concepts we mentioned at the beginning.

State Solutions

Statelessness

The core concept of Statelessness is to externalize 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, verifying and reconstructing the state through State Proofs.

The main role and significance of Statelessness lie in alleviating the storage burden on nodes, improving network scalability, and enabling more nodes to easily participate in validation while still maintaining Ethereum's decentralized nature.

Verkle Trees

Currently, Ethereum relies on Merkle-Patricia trees to hash and compress its state data. However, the size of Merkle proofs in this tree structure can become too large, making them less suitable for the witnesses required by the stateless model.

To address this issue, Ethereum plans to transition to Verkle Trees, a more efficient data structure. Both Merkle-Patricia trees and Verkle trees share an important capability: generating witnesses—cryptographic proofs that allow anyone to easily verify the existence of specific information in the state root.

The advantage of Verkle trees is that they are more efficient in generating smaller proof sizes.

History Expiry (EIP-4444)

EIP-4444 aims to implement history expiry, an upgrade that requires nodes to stop hosting historical blocks older than one year on the peer-to-peer network. Deleting historical data significantly reduces the disk space requirements for node operators. Additionally, it simplifies client software by eliminating the need to adapt code for different versions of historical blocks. Furthermore, the combination of EIP-4444 with Proto-danksharding (PDS) ensures regular data pruning; EIP-4444 prunes data once a year, while PDS prunes data blocks monthly. Although this helps reduce the data storage requirements for nodes, it raises concerns about the preservation and recovery of historical data.

State Expiry

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

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

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

It is worth mentioning that State Expiry only becomes feasible after migrating to Verkle trees. Additionally, Vitalik stated at the Korea Blockchain Week KBW2023 that if there is Statelessness and Proposer-Builder Separation (PBS), State Expiry can be a low priority.

This is because, once the Proposer-Builder Separation is implemented, although block builders will still need access to the state to create blocks, it is expected that they will be able to effectively handle the growth of the state, as this area allows for a certain degree of centralization, and the performance of builders' nodes will naturally meet the demand.

Although the protocol-level PBS has not yet been incorporated into the Ethereum mainnet, we can roughly understand a trend for the future mainnet by looking at the current market distribution of Mev-Boost PBS, as shown in the data from mevboost.pics:

Moreover, the implementation of State Expiry involves changes to the Ethereum address format, with two current proposals: address space expansion vs address space compression. The former increases 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 retains the 20-byte format but uses the first 6 bytes for prefixes and address cycle identification. While this greatly reduces compatibility issues, it introduces another challenge: the address length is reduced to 14 bytes, which no longer has collision resistance, leading to potential security issues in address creation. This is also a significant challenge currently faced by the community.

Conclusion

Now, we can roughly prioritize the implementation challenges and urgencies of the above technical solutions, excluding front-to-back priorities (2, 3, 4 may be treated equally):

1. Verkle Trees

2. PBS

3. Statelessness

4. History Expiry (EIP-4444)

5. Changes to Ethereum Address Format (Compression/Expansion)

6. State Expiry

In summary, this can lower the operational threshold for nodes, maintain the decentralization of nodes, and address the potential state explosion issue, alleviating state growth to optimize network communication load.

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

Reference Links:

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