Translation:

Title: GaryMa Wu Talks About Blockchain

Vitalik has mentioned a topic in recent events such as the Korean Blockchain Week, speeches in Singapore, and even at the Ethereum Core Developers' Meeting (ACDE): "state." Along with this, various related solution concepts have been discussed, such as statelessness, state expiry, history expiry (EIP-4444), Verkle tree, and even address space expansion/compression. Of course, this is not a new roadmap adjustment. In the latest Ethereum roadmap released by Vitalik in November last year, these mainly belong to the key routes of TheVerge and ThePurge.

This article combines these two key routes and some new challenges to review Vitalik's state resolution route.

State

The state in Ethereum 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 expands continuously with the addition of new users and the deployment of new smart contracts.

Currently, full nodes must store this continuously growing dataset to correctly verify blocks and ensure correct state transitions, making the verification process inherently stateful. This continuously growing storage requirement increases the hardware requirements for running full nodes, leading to increasing centralization of validators.

According to etherscan.io/data, running a fast-sync full node currently requires at least 1200 GB (using the Geth client as an example), even after state pruning has been performed, deleting earlier state data and retaining only the most recent state. If it is an archive node, which retains all historical states, including the state of each block, the required capacity is approximately 15,400 GB, and it will continue to grow in the future, known as "state explosion" 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 this series of challenges, the Ethereum community has been working hard to find ways to improve and optimize, as exemplified by the various solution concepts mentioned earlier.

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 the state through state proofs.

The main role and significance of statelessness is to reduce the storage burden on nodes, improve network scalability, enable more nodes to participate in verification easily, and still maintain 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 proofs 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: generating proofs—cryptographic evidence that allows anyone to easily confirm the existence and public availability of specific information in the state root.

The advantage of Verkle trees is their higher efficiency 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. It also simplifies client software by eliminating the need to adapt to different versions of code for historical blocks. In addition, the combination of EIP-4444 with PDS (Proto-danksharding) 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 also raises concerns about the preservation and recovery of historical data.

State Expiry

Statelessness eliminates the necessity for validators to maintain the complete state when verifying 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 has proposed the state expiry scheme.

State expiry automatically prunes unchanged parts of the state, such as for a 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: if there is statelessness and PBS, state expiry can be of low priority.

Because if proposer-builder separation (PBS) is implemented at the protocol level, even though block builders still need to access the state to create blocks, it is expected that block builders will be able to effectively handle state growth, as this area allows for a certain degree of centralization, and the performance of 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 through the current market distribution of Mev-Boost PBS, as shown in the data statistics on mevboost.pics:

In addition, the implementation of state expiry involves changes to the Ethereum address format, with two current proposals: address space extension 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, while retaining the 20-byte format, uses the first 6 bytes for prefixes and address cycle identification. Although this greatly reduces compatibility issues, it also introduces another challenge: the address length is reduced to 14 bytes and no longer has collision resistance, leading to potential security issues in address creation, which is a major challenge currently faced by the community.

Conclusion

Now, based on the implementation difficulties and urgency of the above technical solutions, we can prioritize them (2/3/4 may be equal in priority):

1. Verkle trees
2. PBS
3. Statelessness
4. History expiry (EIP-4444)
5. Changes to the Ethereum address format (compression/extension)
6. State expiry

In conclusion, this can reduce the threshold for running nodes, maintain the decentralization of nodes, 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

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。