Popular Science What is the stateless that Vitalik has frequently mentioned in recent speeches? What does it mean for the decentralization of Ethereum?

What is the stateless concept frequently mentioned by Vitalik? How does it impact Ethereum's decentralization?

Compilation | GaryMa Wu talks about blockchain

Vitalik mentioned a topic in the recent Korean Blockchain Week, Singapore speeches, and the Ethereum Execution Layer Core Developer Meeting (ACDE): state, along with various related solution concepts such as statelessness, state expiry, history expiry (EIP-4444), Verkle tree, and even address space extension compression (Address SLianGuaice ExLianGuaindCompression). Of course, this is not a new roadmap adjustment. In Vitalik’s latest roadmap for Ethereum released in November last year, these mainly belong to The Verge and The Purge key routes.

This article combines these two key routes and some new ideas to explore Vitalik’s state resolution route.

• An Overview of Mainstream Cryptocurrency Exchange Account Password Leakage Data and Security Mechanism Analysis
• Blockchain Game of ERC-6551 Use Case
• Exclusive Interview with Web3Brand How do AI and Web3 achieve mutual development in the wave of technological advancement?

State

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

Currently, full nodes must store this growing data set to correctly validate blocks and ensure correct state transitions, making the validation process inherently stateful. This growing storage requirement raises the hardware requirements for running full nodes, leading 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) even after state pruning, which deletes earlier state data and only keeps the most recent state. If it is an archive node, meaning a full node that 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, known as the “state explosion” commonly mentioned in the community.

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

To address these challenges, the Ethereum community has been working to find ways to improve and optimize, as exemplified by the various solution concepts mentioned at the beginning.

State Resolution 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 mode, nodes only need to maintain block headers and related transaction information and verify and reconstruct states through state proofs.

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

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 witnesses required by the stateless model.

To address this issue, Ethereum plans to transition to Verkle trees, which are a more efficient data structure. Both Merkle-Patricia trees and Verkle trees share an important capability, which is to generate witnesses – cryptographic proofs that allow anyone to easily confirm the existence and availability 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 on the peer-to-peer network for more than one year. Deleting historical data significantly reduces the disk space requirements for node operators. At the same time, it simplifies client software by eliminating the need to accommodate different versions of historical blocks. In addition, the combination of EIP-4444 and PDS (Proto-danksharding) ensures regular data pruning; EIP-4444 prunes once a year, while PDS prunes data blocks once a month. Although this helps reduce the data storage requirements for nodes, it also raises concerns about the preservation and recovery of historical data.

State Expiry

Statelessness eliminates the need 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 problem, the community has proposed the State Expiry scheme.

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

It is worth noting that State Expiry only becomes feasible after transitioning to Verkle trees. In addition, Vitalik stated at the Korean Blockchain Week KBW2023 that if there is statelessness and PBS, State Expiry can be a low priority.

Because if the Proposer-Builder Separation (PBS) is implemented at the protocol level, even in a stateless environment, the block builders still need access to the state to create blocks, but it is expected that the block builders 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 the builders’ nodes can naturally meet the demand.

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

In addition, the implementation of State Expiry involves changes to the Ethereum address format. Currently, there are two proposals: address space extension vs address space compression. The former increases the address length to 32 bytes (the current 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 identification of address cycles. While this significantly reduces compatibility issues, it also introduces another problem. With only 14 bytes remaining for the address length, it no longer has collision resistance, leading to 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 aforementioned technical solutions, we can prioritize them as follows:

1. Verkle Trees

2. PBS

3. Stateless

4. Historical Data Expiry (EIP-4444)

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

6. State Expiry

In conclusion, these solutions can lower the threshold for node operation, maintain decentralization, address potential state explosion issues, and reduce 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

We will continue to update Blocking; if you have any questions or suggestions, please contact us!