Simultaneous implementation of statelessness and state expiration is easier than implementing these two schemes one after the other.
Original title: “V God releases Ethereum’s state expiration and stateless roadmap, simultaneous implementation to solve the problem of state surge”
Written by: Vitalik Buterin, co-founder of Ethereum Translator: Kyle
Source: Babbitt
The state of Ethereum is growing rapidly. At present, the state size alone is about 35 GB. If all Merkle certificates are included, it is more than 100 GB, and it will increase by about half every year. State storage is also a weakness of Ethereum economics: it is also the only mechanism that allows participants to pay once and become a permanent burden on the node. In order to maintain the scalability and sustainability of Ethereum, we need some solutions.
There are two solutions, and they have existed for a long time: weak statelessness and state expiration:
Status expiration: Remove the status that has not been visited recently (for example, the last access was last year) from the status, and need witnesses to restore the expired status. This reduces the amount of state that everyone needs to store to approximately 20-50 GB.
Weak statelessness: only the block proposer is required to store the state and allow all other nodes to verify the block statelessly. To achieve this in practice, it is necessary to switch to the Verkle tree to reduce the size of the witness.
This document describes a multi-stage proposal for the simultaneous implementation of these two ideas. It turns out that this is much easier than implementing these two solutions one after the other. State expiration without a Verkle tree requires a very large witness size to prove the old state, while switching to a Verkle tree without state expiration requires an in-place conversion procedure (such as EIP-2584), which is almost as complicated as implementing only state expiration . However, if carried out at the same time, these two reforms solve the challenges facing each other: State expiration involves the creation of a new state tree every year, allowing Verkle trees to be gradually introduced over time without in-place conversion, while Verkle trees solve The issue of the scale of witnesses is solved.
Related links: The history of state expiration and stateless thinking
Recap: How does the status expiration work?
This is a description of the mechanism proposed here and what is proposed in this document. The core idea is that each period will have a state tree (for example: 1 period ~= 1 year). When a new period starts, an empty state tree will be initialized for that period, and any state update will enter the tree. All writes that occur within a period of time enter the latest tree (so the new tree and the old tree may store the same information or even conflict with each other; the new tree always takes precedence).
Please note that these state expirations of approximately one year are sometimes called “epochs” in history, but I am switching to the term “period” to avoid confusion with the beacon chain period.
Maintain two key principles:
Only the most recent tree (the tree corresponding to the current cycle) can be modified. All old trees are no longer modifiable; objects in the old tree can only be modified by creating copies of them in the new tree, and these copies replace the old ones.
Full nodes (including block proposers) are expected to only hold the latest two trees, so only the objects in the latest two trees can be read without witnesses. Reading older trees requires witnesses.
“Witness” is a short proof that proves that a value or a group of values ​​is located at a certain position in the tree and can be verified by a person with only the root of the tree. For example, you can make a witness to prove that the storage slot 123 of account 0x124f…89ab contains the value 50 in a certain state, and anyone who has the root of the state tree can verify the proof.
State expiration establishes a hybrid state mechanism: consensus nodes need to store the state recently accessed or modified, but the stateless client method based on witness can be used to verify the older state. In other words, an “archive node” can be maintained, it can even store a historical state tree, or a completely stateless node that uses witnesses to verify even the most recent state. However, the gas cost structure and default network format are built around the assumption that nodes store the latest two state trees.
route map
This conversion roadmap is implemented in phases. These stages include:
Cycle 1 hard fork: We start a hard fork from cycle 1 (all the previous content is cycle 0). After this fork, there will be two state trees: the hexadecimal Patricia tree (frozen and no longer editable) and a new Verkle tree (containing all new edits/additions to the state, and the old Copy of state) ( original EIP )
Address cycle expansion: The address is expanded from 20 bytes to 32 bytes. The new address format includes the concept of “address cycle” (previously called “address space”). This allows new contracts to fill new storage slots without the need to provide witnesses. This can be done at any time before the final state expires transition, before or after the cycle 1 hard fork. ( VB proposal , Ipsilon team proposal )
Cycle 2 Hard Fork: We implemented the hard fork that started Cycle 2 and arranged the beginning of the future phase. The cycle 0 hexadecimal Patricia tree is replaced with a Verkle tree, and the client only stores the root, so the state in the cycle 0 tree now needs witnesses to prove it. After that, the status expiration plan has been fully implemented.
Source link: notes.ethereum.org
Disclaimer: As a blockchain information platform, the articles published on this site only represent the author’s personal views, and have nothing to do with the position of ChainNews. The information, opinions, etc. in the article are for reference only, and are not intended as or regarded as actual investment advice.
