Stateless Tech Tree: reGenesis Edition

This week we technology tree Although it is not a full realization of Stateless Ethereum, it reflects several new key milestones for Ethereum 1.x R&D that are much more reasonably achievable in the medium term. The most important addition to the technology tree is Alexey’s reGenesis offer. This is far from a well-specified upgrade, but the general sentiment in R&D is that reGenesis provides a less dramatic but much more achievable step toward the ultimate goal of a “fully stateless” vision. Complementing reGenesis in many ways is a static state network that helps distribute state snapshots and historical chain data in a BitTorrent-style DHT-based network. At the same time, more near-term improvements, such as code Merkleization and binary tree representation of states, are moving closer to EIP readiness. Below we’ll explain and clarify the changes, and link to relevant discussions if you’d like to learn more about specific features.

binary try

Ethereum currently uses hexadecimal numbers, but Merkle-Patricia Tree To encode the state, significant efficiencies can be gained by switching to a binary format, especially at the expected witness size. Completely re-encoding Ethereum state requires specifying a new format and a clear strategy for transitioning. Finally, you need to decide whether your smart contract code will also be Merkleized and whether this should be integrated into the binary tree conversion or as a standalone change.

binary trie format

The general idea of ​​a binary tree is a bit simpler (pun intended 🙂 than Ethereum’s current hexadecimal tree structure. Instead of having one of 16 possible paths one can take from the root of the trie towards a child node, a binary trie has two. Completely respecifying state tries provides additional opportunities to improve well-established inefficiencies. It has now been reported that Ethereum has been in operation for over five years. In particular, this can be an opportunity to create a state that is much more adaptable to the real-world performance issues of database encoding. Previous article on national growth).

You can find a discussion of the official binary try specification and Merkleization rules. on ethresearch.

Binary try conversion

It’s not just the destination (in binary try format) that matters, it’s the journey itself! In an ideal transition, there would be no disruption to transaction processing across the network. This means that the client must build a new binary tree. at the same time It’s like dealing with a new block rolling every 15 seconds. Continue to identify the most promising conversion strategies. Overlay methodIt is based in part on geth’s new snapshot synchronization protocol. To briefly summarize, new state changes are added to the existing (hexary) tree in binary form, creating a sort of binary/hexary hybrid during the transition. The untouched state is converted to a background process. Once the conversion is complete, the two layers are merged into a single binary trie.

It is important to remember that binary conversion is one of those situations where client diversity is very important. Every client must either implement its own version of the transition or rely on another client to do the transition and wait for a new try on the other side of the transition. This will certainly be a ‘measure twice, cut once’ situation where all client teams will work together to implement tests and coordinate transitions. For safety and security reasons, the network may need to briefly take service out of service during the transition (e.g. mining a few empty blocks), but agreeing to a specific plan is too difficult to predict at this point. .

Code Merkization

Smart contract code makes up a significant portion of the Ethereum state tree (about 1GB out of ~50GB of state). Witnesses to all smart contract interactions must provide the interacting code to calculate: code hash, this can be quite a bit of additional data. Code Merkleization is a means of breaking contract code into smaller chunks and replacing them. code hash We take the route of another Merkle try. Doing so would allow witnesses to replace potentially large portions of their smart contract code with reference hashes, reducing valuable kilobytes of witness data.

There are a variety of approaches to code merkleization schemes, from simple aspects of universal chunking (e.g. 64-byte fragments) to more complex methods such as Solidity-based static analysis. function id or from the jump guideline. The optimal strategy for code Merkle ultimately depends on what appears to work best on real-world data collected on the mainnet.

regenerate

The best place to process your reGenesis offer is Comment by @mandrigin or Full suggestion from @realLedgerwatchBut the TL;DR is that reGenesis is essentially “spring cleaning for blockchain.” The overall state is conceptually divided into ‘active’ state and ‘inactive’ state. Periodically, the entire ‘active’ state becomes deactivated and new transactions start building the active state again. almost There is nothing (hence the name “reGenesis”). If a transaction requires a stale piece of state, it provides a witness very similar to what is required for stateless Ethereum: a Merkle proof, which proves that a state change corresponds to some inactive state. When a transaction hits the ‘Inactive’ part of the state, it is automatically promoted to ‘Active’ (regardless of whether the transaction succeeds or not) and remains there until the next reGenesis event. This creates some of the economic boundaries on state usage that state rents had, without actually deleting any state, and the sender of a transaction, unable to create a witness, blindly attempts to continue the transaction until everything it touches becomes ‘active’ again. It has nice properties that allow it to do so. .

The fun part about reGenesis is that while it brings Ethereum much closer to the ultimate goal of Stateless, it sidesteps some of the biggest challenges of Stateless, namely how witness gas calculations work during EVM execution. It also has some version of transaction witnesses moving across the network, allowing for thinner and lighter clients and giving Dapp developers more opportunity to become familiar with the stateless paradigm and witness production. “True” Statelessness after reGenesis is a matter of degree. Stateless Ethereum actually performs reGenesis for each block.

state network

Better network protocols have been a ‘side quest’ on the technology tree since the beginning, but with the addition of reGenesis to the scope of Stateless Ethereum, it now seems relevant to look for alternative network primitives for sharing Ethereum chain data (including state). Much better for the main quest. Ethereum’s current network protocol is monolithic. In practice, there are many different types of data that can be shared using different ‘subnetworks’ optimized for different things.

Previously this was said as follows: “Three Networks” from the previous Stateless callwith DHT-based Networks can provide some data more effectively. It doesn’t change from moment to moment. With the introduction of reGenesis, the ‘inactive’ state is suitable for categories of data that do not change and could theoretically be served in a BitTorrent-style swarm network instead of individually from fully synchronized clients as is currently done.

A network that carries a state that has not changed since the last reGenesis event is: static state networkIt can be built on with new extensions. Discovery v5.1 specification for the devp2p library (Ethereum’s networking protocol). Previous suggestions such as Carousel synchronization and (more mature) snap protocol for synchronization Active State would still be a valuable step toward a fully decentralized environment. dynamic state network For clients who want to quickly synchronize their entire state.

finish

A more condensed technology version of all leaves of the stateless technology tree (not just the updated ones) is available at: Stateless Ethereum Specification Repository, lively discussions on all topics covered here can be found on the Eth1x/2 R&D Discord. If you would like to participate, request an invitation at ethresearch.ch. As always, tweet @gichiba or @JHancock for feedback, questions, and suggestions on new topics.