This week we are updating the Tech Tree<\/a> to showcase several new key milestones in Ethereum 1.x R&D that are not entirely a full manifestation of Stateless Ethereum, but significantly more achievable in the mid-term. The most notable inclusion in the tech tree is Alexey’s reGenesis proposal. While it is far from a fully defined upgrade, the prevailing sentiment among R&D is that reGenesis presents a less radical but much more feasible progression towards the ultimate aspiration of a “fully stateless” system. In many respects, complementing reGenesis is a static state network designed to assist in distributing state snapshots and historical chain information within a bittorrent-style DHT-based network. Concurrently, improvements that are more immediate, such as code merkleization and a binary trie depiction of state, are nearing readiness for EIP. Below, I will elucidate and clarify the modifications made, along with links to pertinent discussions should you want to explore any specific feature further.<\/p>\n <\/p>\n \n <\/p>\n <\/p>\n Ethereum presently utilizes a hexary Merkle-Patricia Trie<\/a> for state encoding, but there are significant efficiency improvements possible by transitioning to a binary format, especially considering the expected size of witnesses. A complete re-encoding of Ethereum\u2019s state necessitates the specification of the new format, alongside a clear transition strategy. Lastly, a decision must be reached about whether smart contract code will also be merkleized and whether that should be included in the binary trie transition or treated as a separate modification.<\/p>\n <\/p>\n <\/p>\n The underlying concept of a binary trie simplifies (pun intended :)) Ethereum’s current hexary trie architecture. Instead of traversing one of 16 potential paths from the root of the trie towards child nodes, a binary trie utilizes just 2. With a comprehensive re-specification of the state trie comes further chances to enhance well-established inefficiencies that have become apparent after Ethereum has been active for over 5 years. Specifically, this might provide an opportunity to make the state much more suited to the practical performance challenges of database encoding (as discussed in a prior article on state growth<\/a>).<\/p>\n <\/p>\n The conversation surrounding a formal binary trie specification and rules for merkleization can be found on ethresearch<\/a>.<\/p>\n <\/p>\n <\/p>\n It\u2019s not solely the destination (binary trie format) that matters, but the journey itself! Ideally, the transition would avoid any interruption to transaction processing across the network, indicating that clients must develop the new binary trie while also<\/em> managing new blocks that arrive every 15 seconds. The transition strategy appearing most promising is termed the overlay method<\/em><\/a>, which draws partially from geth’s new snapshotting synchronization protocol. In brief, new state alterations will be added to the existing (hexary) trie in a binary structure, creating a sort of binary\/hexary hybrid throughout the transition. The untouched state will be converted as a background operation. Once the transformation is finalized, both layers will get merged into a singular binary trie.<\/p>\n <\/p>\n It is crucial to recognize that the binary transition represents one context where client diversity plays a vital role. Each client will need to either create their own variation of the transition or depend on other clients to handle the conversion and await the new trie upon completion. This scenario will undoubtedly be a ‘measure twice, cut once’ type of situation, with all client teams collaborating to implement tests and coordinate the transfer. It is conceivable that for the sake of safety and security, the network may need to briefly halt operations (e.g., mine several empty blocks) during the transition, yet reaching consensus on any specific plan remains too far in the future to anticipate at this moment.<\/p>\n <\/p>\n <\/p>\n Smart Contract code constitutes a substantial portion of the Ethereum state trie (approximately 1 GB of the ~50GB of state). A witness for any interaction with a smart contract will inherently need to supply the code it\u2019s interacting with in order to compute a codeHash<\/span>, which could entail a considerable amount of additional information. Code Merkleization offers a method for segmenting contract code into smaller parts and substituting codeHash<\/span> with the root of another merkle trie. This approach would enable a witness to replace potentially large sections of smart contract code with reference hashes, thereby reducing essential kilobytes of witness data.<\/p>\n <\/p>\n Various methods for code merkleization schemes exist, ranging from universally chunking (for instance, into 64-byte segments) on the simpler end to more sophisticated techniques like static analysis based on Solidity’s functionId<\/span> or JUMPDEST<\/span> instructions. The ideal approach for code merkleization will ultimately depend on what proves to be most effective with actual data acquired from the mainnet.<\/p>\n <\/p>\n <\/p>\n The most effective way to grasp the reGenesis proposal is this clarification by @mandrigin<\/a> or the complete proposal by @realLedgerwatch<\/a>, but to summarize, reGenesis is essentially “spring cleaning for the blockchain”. The entire state would hypothetically be divided into an ‘active’ and an ‘inactive’ state. Periodically, the whole ‘active’ state would be deactivated, and fresh transactions would commence building an active state anew from almost<\/em> scratch (which explains the term “reGenesis”). If a transaction requires an older portion of the state, it would provide a witness notably similar to what would be necessary for Stateless Ethereum: a Merkle proof affirming that the state change aligns with some segment of inactive state. Should a transaction interact with an \u2018inactive\u2019 part of the state, it automatically promotes it to \u2018active\u2019 (regardless of whether or not the transactionis prosperous) where it persists until the next reGenesis occurrence. This possesses the advantageous quality of establishing certain economic limitations on state utilization that state rent implemented without actually abolishing any state, and permitting transaction senders unable to generate a witness to merely continue attempting a transaction until everything they engage with is \u2018active\u2019 once more.<\/p>\n <\/p>\n The intriguing aspect of reGenesis is that it brings Ethereum significantly closer to the ultimate objective of Stateless, while evading some of the most substantial hurdles associated with Statelessness, such as the dynamics of witness gas accounting during EVM operations. It also facilitates a variant of transaction witnesses circulating throughout the network, enabling more streamlined, lighter clients and providing dapp developers greater chances to acclimate to the stateless model and witness creation. “True” Statelessness following reGenesis would thus become a matter of extent: Stateless Ethereum essentially evolves into reGenesis after each and every block.<\/p>\n <\/p>\n <\/p>\n An improved network protocol has been a ‘side-quest’ on the technology tree from the outset, but with the addition of reGenesis into the concept of Stateless Ethereum, discovering alternative network primitives for disseminating Ethereum chain data (including state) now appears to align much better with the primary mission. The current network protocol of Ethereum resembles a monolith, whereas in reality, there are various distinct types of data that could be shared using different ‘sub-networks’ tailored for diverse functions.<\/p>\n <\/p>\n <\/p>\n Previously, this concept has been discussed as the “Three Networks” during earlier Stateless discussions<\/a>, with a DHT-based<\/a> network effectively serving some of the data that remains unchanged moment to moment<\/em>. With the introduction of reGenesis, the ‘inactive’ state would fall into the category of static data and could theoretically be managed by a bittorrent-style swarming network instead of piece-by-piece from a fully synchronized client as is practiced currently.<\/p>\n <\/p>\n A network distributing the unaltered state since the last reGenesis event would constitute a static state network<\/em>, potentially developed by enhancing the new Discovery v5.1 specification in the devp2p library<\/a> (Ethereum’s networking protocol). Earlier proposals like Merry-go-Round sync<\/a> and the (more advanced) SNAP protocol<\/a> for synchronizing active<\/em> state would still represent valuable steps toward establishing a fully distributed dynamic state network<\/em> for clients striving to swiftly synchronize the complete state.<\/p>\n <\/p>\n <\/p>\n A more concise and technical version of every leaf in the Stateless Tech Tree (not only the updated ones) can be found on the Stateless Ethereum specs repository<\/a>, with active dialogues on all topics discussed here occurring in the Eth1x\/2 R&D Discord \u2013 please request an invitation on ethresear.ch if you wish to participate. As always, feel free to tweet @gichiba or @JHancock for feedback, inquiries, and ideas for new subjects.<\/p>\n<\/div>\nBinary Trie<\/h2>\n
Binary Trie Format<\/h3>\n
Binary Trie Transition<\/h3>\n
Code Merkleization<\/h3>\n
reGenesis<\/h2>\n
State Network<\/h2>\n
![\"three](\"https:\/\/ethresear.ch\/uploads\/default\/optimized\/2X\/b\/b728931409ca6e21654afb66ae25c050bde125b8_2_1380x782.jpeg\")
<\/p>\nWrapping up<\/h2>\n