This week, we’ll be looking at the Tech network and some of the major updates that have been made. Ethereum 1.x R&D is still in its early stages, but stateless Ethereum is a much more achievable goal in the near future. The most significant addition to the tech network is Alexey’s proposed reGenesis. While research and development suggests that reGenesis is a more realistic option in the pursuit of the “fully stateless” vision. The reGenesis plugin has several different uses. It distributes state snapshots and historical data across a DHT-based network. EIP-ready enhancements are being made in other areas such as code merkleization, binary triangle representations of state, and binary tries. If you’re interested in learning more about a certain feature, please explain the changes to us and provide a link to the discussion.
Binary Triangle
Currently, Ethereum uses the Merkle-Patricia Trie for state encoding. There are notable efficiency improvements to be had by switching to a binary format, particularly in terms of token size. A complete recoding of Ethereum’s state is necessary to determine the new format and to develop a strategy for the transition. It is also important to determine if smart contract code can be merkleized, and whether that should be included in the binary transition or remain as a separate change.
Binary Trie Format
The concept of a binary trie is a bit simpler (pun :)) than the hexadecimal trie structure that Ethereum currently employs. Binary tries allow you to choose one of 16 paths from the root node to the child nodes of the trie. This is a new term for state tries and has the potential to increase their effectiveness, which has already been established. This website has been online for more than five years and could be a great opportunity to improve real-world performance issues related to database encoding (as mentioned above). An earlier article about the decline and rise of the state can be read here.
Binary Trie Transition
It’s not about the destination (binary trie format), it’s about the journey. Transaction processing on the network will continue without interruption with a seamless transition. This means that clients will need to be updated with the new binary test. Like new blocks every 15 seconds, the transition strategy looks the most promising to me. You can also use the overlay method, which is partially based on the new geth Snap synchronization protocol. New state changes to existing tries or hexaries will be made in binary format. This will create a type of binary/hexary combination during the transition. As the background process converts the entire state, both layers are combined into a single binary intent. It is important to keep in mind that binary transition can create an environment where customer diversity is essential. Clients can either make their own version or wait for other clients to finish the transformation. This will definitely be a “measure twice, cut once” situation as all customer departments work together to implement the test and coordinate the change. The network may temporarily suspend service (for example, mining empty blocks) as it is difficult for everyone to agree on a plan during this transition.
Merkleization Use This code
Smart contract code is an important part of the Ethereum state (around 1GB out of 50GB of state). Any smart-contract interaction that involves code will need to provide the code with which it is interacting in order to calculate a result. This could contain a lot more information. Code merkleization is a method of reducing the contract code and replacing it with a hash code of the root of another merkle trie. Doing so would allow witnesses to replace large numbers of smart contract codes using reference hashes, eliminating the need for crucial witness data that is otherwise necessary for the execution of a smart contract.
Data has grown exponentially in size.
There are various ways to code Merkleization. These include universal chunking (e.g. into 64-byte bits) and more complex techniques such as SoLibidityStatic analysis or Function ID and JUMP instructions. By examining the mainnet, it is possible to work out the optimal strategy for codemerkleization.
ReGenesis
For more information about the ReGenesis proposal, @mandrigin provides an explanation, or you can read @realLedgerwatch’s proposal. In a nutshell, ReGenesis is a “spring cleaning” for the blockchain, where all transactions that are deemed ‘active’ cease and a new active status is created. This is why it is called “ReGenesis”. If a transaction hits an inactive state part, it automatically raises it to an active status, which remains unchanged until the next ReGenesis event. This can help to significantly reduce the economic utilization of the state.
The best thing about ReGenesis is that it brings out the best in Ethereum’s statelessness. It avoids the biggest issues and makes it possible to be implemented. This is how EVM works in witness gaz accounting. Transactions tokens are transferred across the network in a particular version, allowing for lighter clients and helping developers to become more familiar with stateless design. After ReGenesis, statelessness would be an issue of degree: Ethereum would just be ReGenesis after each block.
State Network
It has been possible to develop a better network protocol with ReGenesis added to the tech tree from the start. The search for alternative network primitives that can share information has been on. It appears that chain data (including state) works now. A more comprehensive search will yield better results. The current Ethereum network protocol is often seen as a single entity, but there are different types of data that can be shared by various ‘subnets’, which can be optimized for particular purposes.
Previously, this has been referred to as the “Three networks” in past stateless calls. You can find more information at DHT-based. Certain data can be better served by a network that is tailored to it, rather than taken from a synchronized client as is currently the case. It would be possible for a network to exist in the same state as it was at the time of the last ReGenesis. This has been called ‘Network Static states’. You can also extend existing structures to create new constructions, such as Discovery v5.1 specifications in the devp2p library and the more mature SNAP protocol. Synchronizing active state is a step towards a fully distributed democracy and can still be useful for clients who want to quickly sync all of the states.
Conclusion
This is a condensed, technical summary of each sheet in the Stateless Tech Tree. All versions are available (not only the current) at the Stateless Ethereum Specification Repository, and there are active discussions about all topics on the Eth1x/2 R&D Discord. You can request an invite at ethersear.ch. For feedback, questions, and suggestions on new topics, tweet @gichiba @JHancock.
