Critical path: Realize stateless verifiers through block witness, and restrain state growth through state shelf life.
Original title: ” Announcement | A New Stateless Ethereum Roadmap “
Author: pipermerriam
Translation & Proofreading: Min Min & A Jian
Some time has passed since the last version of the comprehensive “roadmap” of stateless Ethereum was released, and many things have now changed. It seems that the time has come to “write it all down” again.
What we are not doing
We are not solving the problem of stateless mining.
We do not aim at solving DSA (dynamic state visit) problem, not ready for execution of an additional witness for the transaction data (witness).
Critical Path
It is difficult to determine exactly what our goal is. But I think that as long as we focus on the needs, there will naturally be a target gradient.
Realize stateless verifiers through block witness
We hope/need that the verifier can verify the block without saving the complete state. One proposal is to add a block witness to the block in the protocol, so that the client can use the block witness data to verify the state root obtained by executing the block.
For this, we need:
A: The witness is greatly reduced (as far as the current hexadecimal Patricia tree is concerned, the size of the witness data can be up to 100 MB)
B: Let the verifier get a reliable witness together with the block
We use Verkle Trie to solve demand A and reduce the cost of proof to a constant size (in theory, based on the current gas upper limit of 12.5 million, the upper limit of the proof size is about 800k, and the average is about 200k). See also “Proposal to apply verkle trie to the state of Ethereum”. It is also worth mentioning that the unified verkle trie needs to modify the behavior of the SELFDESTRUCT opcode, or delete the opcode completely.
We solve requirement B by witnessing the message becoming part of the protocol operation (probably using it as the access list in the block header) so that the person receiving the proof can confirm that it is the correct proof of the corresponding block. The responsibility for generating and broadcasting witnesses through gossip has not yet been determined.
Further reading: ” Why is statelessness so important for ETH 2.0?” 》
Suppress state growth through State Expiry
Block proposers (or miners) still need to generate blocks. We do not recommend solving the problem of stateless block mining, because this will make our goal to reduce the increasing burden of state maintenance.
Our goal is to impose economic constraints on the size of the overall state. We plan to achieve this goal through the “state shelf life”.
For details, please refer to: ” Resurrection-conflict-minimized state bounding, take 2-#17 by vbuterin. 》
Roughly speaking, the so-called state shelf life is to make the state “inactivate” after a period of time (about 12 months). The deactivated state is no longer managed by the agreement. Any interaction with the inactivated state needs to be accompanied by a certificate to reactivate the inactivated state. This scheme will not introduce any complicated “lease” mechanism into the EVM, but it actually enforces the “state lease”. The result is a strict upper limit on the overall state scale.
Secondary critical path
Realize stateless client architecture through “portal client”
Extended reading: ” Complete revamp of the “Stateless Ethereum” roadmap-#2 by dankrad “
The current DevP2P Ethereum protocol cannot support stateless clients well. Even if the protocol is modified to support stateless clients, this is not easy. In other words, only by relying on the “critical path”, we can build clients suitable for the Eth1+Eth2 combined infrastructure, but these clients are of little use to most people who use the client to use the JSON-RPC API .
Another ongoing project is to build the network infrastructure necessary to support the widespread deployment of ultra-lightweight “portal clients.” The so-called “portal” means that the client can view the network and related data, but does not have to participate in the agreement in any meaningful way.
“Portal Client” will participate in a dedicated peer-to-peer network designed to meet the following needs:
1. Retrieve any status as needed.
- State Network DHT-Development Update #2-#5 by pipermerriam
2. Retrieve any blockchain history on demand.
- Alexandria-HackMD (obsolete, but conceptually representative)
3. Participate in the gossip broadcast of the transaction, but there is no need to access the status.
- Scalable Transaction Gossip-#3 by pipermerriam
4. Participate in block gossip broadcasting, but do not need to meet the invisible requirements of the DevP2P Ethereum protocol.
Any “stateless client” that wants to attract users of the JSON-RPC API will participate in this type of network. We hope that existing clients will use this type of network to make themselves more lightweight.
This is not a critical path to achieve the main goal of the Eth1 + Eth2 merger, but it helps to extend the stateless client to use cases other than verifiers.
Regenesis (may not clean up the state)
In the past, “Regenesis” had two different meanings:
Use a new genesis block to restart the blockchain and reach a consensus on the genesis status.
To “inactivate” the state, a proof must be provided to allow the state to “reinstate”.
The activation/deactivation mechanism is now classified as a “status validity period” scheme.
There are many benefits to restarting the blockchain with a new genesis block. Among them, the most important point is to liberate all clients from the invisible demands brought about by historical fork rules, and make the client easier. This can also help nodes shorten the synchronization time required to obtain a complete state copy.
Content removed from the critical path
Binary Trie
The main mechanism used to reduce the size of the witness has now been replaced by Verkle Trie.
Reference reading: ” EIP-3102: Binary trie structure “
Code Merkelization
Originally a secondary mechanism to reduce the size of the witness, it has now been replaced by Verkle Trie.
Reference reading: ” EIP-2926: Chunk-Based Code Merkleization “
Source link: ethresear.ch
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.
