Compilation | GaryMa Wu Blockchain about blockchain
Vitalik has jointly mentioned a topic at the recent Korean Blockchain Week, Singapore speech and even the Ethereum Executive Core Developer Conference (ACDE): state, and what follows is related to it. Various solution concepts, such as stateless, state expiry (State Expiry), historical data expiration (EIP-4444), Verkle tree, and even address space expansion\compression (Address Space Expand\Compression). Of course, this is not actually a new roadmap adjustment plan. In the latest roadmap of Ethereum released by Vitalik in November last year, these mainly belong to the key routes of The Verge and The Purge.
This article combines these two key routes and some new thinking challenges to review Vitalik's state solution route.
State
State in Ethereum refers to a comprehensive ledger that includes all externally owned accounts (EOAs), their balances, smart contract deployments, and associated storage. This state is not static; it continues to expand as new users are added and new smart contracts are deployed.
Currently, full nodes must store this ever-growing data set to properly validate blocks and ensure correct state transitions, making the validation process stateful in nature. This growing storage requirement, thereby increasing the hardware requirements for running full nodes, will lead to increasingly centralized validators.
According to etherscan.io/ data, currently running a fast synchronization full node requires at least 1200 Gb (taking the Geth client as an example). This is after state pruning has been performed, the earlier state data is deleted, and only the most recent state is retained. The premise. If it is an archive node, that is, the full node will retain all historical states, including the state of each block, then the required capacity will be about 15,400 Gb, and it will continue to grow in the future, which is what the community often calls "state explosion".
This is what Vitalik emphasized at Korea Blockchain Week: the centralization of nodes is one of the biggest problems facing the Ethereum network and should be solved by making nodes cheaper and easier to run.
In order to deal with this series of challenges, the Ethereum community has been working hard to find ways to improve and optimize, that is, the various solution concepts we exemplified at the beginning.
status solution
Statelessness
The core concept of stateless is to externalize state data, eliminating the need for each node to store 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 (State Proofs).
The main role and significance of statelessness is to reduce the storage burden of nodes, improve network scalability, and enable more nodes to easily participate in verification, 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 such tree structures can become too large, making them less suitable for the witnesses required by stateless models.
To solve this problem, Ethereum plans to transition to Verkle trees, a more efficient data structure. Merkle-Patricia trees and Verkle trees both share an important ability, which is to generate 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 that they are more efficient at 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 older than one year on the peer-to-peer network. Removing historical data significantly alleviates disk space requirements for node operators. At the same time, it also simplifies client software by eliminating the need to adapt code for 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. While this helps reduce the data storage needs of nodes, it also raises concerns about the preservation and recovery of historical data.
State Expiry
Statelessness eliminates the need for validators to maintain complete state when validating blocks. But state isn't going away; its continued growth remains a long-term challenge for the web.
In order to solve this fundamental problem, the community proposed the State Expiry solution.
State expiration will automatically prune those portions of the state that remain unchanged for, say, a year, moving them into a separate tree structure and removing them from the main Ethereum protocol.
It is worth mentioning that state expiration only becomes feasible after migrating to Verkle trees. In addition, Vitalik said at the Korean Blockchain Week KBW2023: If there is statelessness and PBS, state expiration can be low priority.
Because if the Proposer-Builder Separation (PBS) is implemented by then, in the stateless state, although the block builder still needs to access the state to create the block, the block builder at that time has already been expected. Being able to effectively handle the growth of state, because this area allows a certain degree of centralization, the node performance of the builders can naturally meet the needs.
Although protocol-level PBS has not yet been included in the Ethereum main network, we can roughly understand the future trend of the mainnet by understanding the current market distribution of Mev-Boost PBS. The data statistics of mevboost.pics are as follows:
In addition, the implementation of State Expiry involves changes to the Ethereum address format. There are currently two solutions: address space extension vs. address space compression. The former increases the address length to 32 bytes (the current address format is 20 bytes), but it requires complex logic for backward compatibility and the existing contract must also be updated; although the latter retains the 20-byte format, it changes the previous 6 bytes are used to identify the prefix and address cycle. Although this greatly reduces the compatibility problem, it also leads to another problem. The address length is only 14 bytes and it no longer has the ability to resist collisions, thus introducing some addresses. The potential security issues created are also a major challenge currently faced by the community.
Summarize
Now, we can roughly eliminate the before and after priorities based on the implementation difficulties and priorities of the above technical solutions (2\3\4 may be equal):
1. Verkle tree
2.PBS
3. Stateless
4. Historical data expired (EIP-4444)
5. Changes in Ethereum address format (compression/expansion)
6. Status expiration
In summary, the node operation threshold can be lowered, the node decentralization and potential state explosion problems can be maintained, and the state growth can be reduced to optimize the 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
