ETH 1.X: New Idea of ​​Stateless Ethereum "REGENESIS"

source|Ethereum Blog

Author | Griffin Ichiba Hotchkiss

first level title

Eth 1.x: New idea of ​​stateless Ethereum "reGenesis"This week we will beTech tree

Update to add some new major milestones for Ethereum 1.x development, these milestones are not considered a full implementation of Stateless Ethereum, but goals that we can reasonably achieve in the medium term.

At the same time, some goals that are relatively close to us are already preparing for EIP, such as code chunking (code merkleization) and state binary tree. In this article, I will illustrate the progress that has been achieved, and attach links so that readers can drill down into areas of interest.

first level title

binary treeCurrently Ethereum uses sixteen forksPatricia Merkel Tree

To encode the state, but converting to binary will bring significant efficiency improvements, especially in terms of witness size. A complete recoding of the state of Ethereum requires the development of new paradigms, as well as a clear transition strategy. Finally, a decision needs to be made whether to chunk the smart contract code and incorporate this process into the binary tree transition or as a standalone update.

binary tree paradigmThe binary tree concept is a bit simpler than the current hex tree structure. A hexadecimal tree has sixteen possible paths to traverse from the root to a child node, whereas a binary tree has only two. With the renormalization of the state tree, we have the opportunity to address significant inefficiencies in Ethereum’s five-year run. Also, we have the opportunity to make the state more adaptable to the performance challenges of real-world database coding (inPrevious article on state growth

mentioned in).ethresearch.

A discussion of the formal binary tree specification and chunking rules can be found at

transition to binary tree

It's not just the destination of the binary tree paradigm that matters, the journey itself is valuable too! In an ideal transition, there would be no disruption to the network's transaction processing, meaning clients would need to build new binary trees while processing new blocks that appear every fifteen seconds.The transition strategy that currently looks most promising is called"override" method

, which is based in part on geth's new snapshot synchronization protocol. In general, new state changes are added to existing hexadecimals in binary paradigm, which means there will be a mixture of binary and hexadecimal during the transition. Unaffected states are transitioned to background processing. Once converted, the two layers are merged into a single binary tree.

It's important to note that client diversity also plays a very important role in the binary translation process. Each client will need to implement its own version of the transition, or rely on other clients to do the transition and then wait for the new tree on the other side.

This requires us to "think twice" and all clients need to work together to test and coordinate the transition. For security reasons, it is possible that the network will need to be temporarily out of service during the transition (e.g. to mine some empty blocks), but it is too early to agree on any concrete plans.

code chunking

A large portion of the Ethereum state tree consists of smart contract code, accounting for around 1GB of the 50GB state. All witnesses for smart contract interactions must provide the code of their interaction to calculate codeHash, which may generate a lot of additional data.

There are many ways to divide the code into chunks. According to the complexity, the simpler way is general chunking (for example, each chunk size is 64 bytes), while the more complex way is static analysis based on Solidity functionId or JUMPDEST instruction. The optimal code chunking strategy ultimately depends on whether it is applicable to real data collected from the main network.

reGenesis

textExplanation given by @mandrigin,as well as,as well asFull proposal submitted by @realLedgerwatch

In a nutshell, reGenesis can basically be said to be "the general cleaning of the blockchain". The full state will be conceptually divided into "active" and "inactive" states. The overall "active" state is periodically deactivated, and then new transactions are created to create a new active state almost from scratch (hence the name "reGenesis").

If a transaction requires a previous state, a witness is provided, much like the proofs required in stateless Ethereum: a Merkle proof that a state change is consistent with some inactive state. If a transaction needs the "inactive" part of the state, it will automatically turn it into the "active" state (whether the transaction is successful or not), and this part will be left until the next reGenesis occurs.

One advantage of this is that it creates some economic constraints on using state without actually removing any state. Second, if the transaction sender is blindly repeatedly trying to transact, a witness cannot be generated.

Regarding the significance of reGenesis, it makes Ethereum take a big step towards the ultimate stateless goal, and avoids the biggest challenge to achieve statelessness, that is, how to calculate the witness gas during EVM execution. At the same time, it also enables a certain version of the transaction witness to be propagated in the network, allowing lighter clients and dapp developers to have more opportunities to become familiar with the stateless paradigm and witness generation.

"True" statelessness after reGenesis is a matter of degree: Stateless Ethereum is really just reGenesis after each block.

state network

From the beginning, the optimization of the network protocol was only a "side task" in the technology tree, but as reGenesis entered the territory of stateless Ethereum, it became an important task to explore alternative network primitives for sharing Ethereum chain data (including state). main mission. The current network protocol of Ethereum is a whole, but in fact there are multiple types of data that can be shared through different "sub-networks", and these "sub-networks" can meet different needs.When we discussed this topic earlier in the stateless session, we called it the，"Three Networks"DHT-based

The network can more efficiently serve infrequently changing data types. With the introduction of reGenesis, the "inactive" state can be included in this kind of infrequently changing data, and theoretically it can be applied to the bitstream swarm network, instead of the current one-by-one broadcast by the full node.A network that propagates an invariant state across the network since the last reGenesis is a static state network, which canBased on the new Discovery v5.1 specification in the devp2p library (Ethereum network protocol)

to stretch.Merry-go-Round syncSimilar to beforeSNAP protocol, which can be used to synchronize active state, is an important step towards a fully distributed dynamic state network, enabling clients to quickly synchronize complete state.

epilogue

epilogueFor a more detailed and technical description of each branch of the stateless Ethereum technology tree, readers can refer to, all of these topics can also be discussed in the Eth1x/2 R&D Discord, if you want to join you can ask for an invitation on ethresear.ch. For feedback and suggestions, please reach out to @gichiba or @JHancock on Twitter.

Disclaimer: ECN's translation work aims to deliver high-quality information and learning resources for the Chinese Ethereum community. The copyright of the article belongs to the original author. Reprints must indicate the source of the original text and ethereum.cn. For long-term reprints, please contact ethereumcn@gmail.com Authorize.