The Importance of "Statelessness"

Source | dankradfeist.de

Author | Dankred Feist

Before reading this translation, you can first understand the background knowledge of state expansion and statelessness.

Recommend an article:Viewpoint | State Expansion and StatelessnessAuthor: A Jian

first level title

Currently emerging solutions mainly revolve around two directions:

➤ State rent: an ongoing payment to keep the state in active memory

➤ Stateless: The block retains all witnesses, such as the Merkle proof, so no state is needed when verifying the validity of the block

In the direction of "statelessness", there are different concepts worth exploring:

➤ Partial statelessness: Only certain (stale) states need to be witnessed, reducing the number of states required to validate a block

➤ Weak statelessness: the verification block does not need state, but the proposed block needs complete state

In this post, Vitalik proposes how to tease these concepts into a general framework, and shows that partial statelessness and state rent are very similar in that both require some form of payment when making changes to the active state , and a proof to reactivate the stale state.

first level title

Eth1 has been criticized in the past for being very hardware demanding, and while not all of these criticisms are fair (a selection of moderate consumer-grade hardware can also run Eth1 nodes), we need to pay attention to these facts, especially when Scale Ethereum without compromising decentralization. For Eth2, we set very ambitious goals: to be able to run Eth2 nodes and validators on low-cost hardware, even a Raspberry Pi or a smartphone.

This path to scalability has not been easy. Other projects, such as EOS and Solana, require higher performance hardware and network connections. But I think it is necessary to lower the threshold of consensus nodes and P2P nodes to ensure decentralization.

In Eth2, consensus nodes are validators. There are very important differences between the consensus nodes of Eth1 and Eth2:

➤ The consensus nodes of Eth1 are miners. To "vote" for a blockchain, you have to produce blocks. That is, consensus nodes and block producers are inseparable.

➤ In Eth2 or the current first stage (beacon chain), there are two different mechanisms for proposing blocks and forming consensus: every 12 seconds, a randomly selected validator proposes blocks, and consensus is through Attestations are formed, and each validator votes on the blockchain every epoch (every 6.4 minutes). More than 100,000 validators are now voting for consensus every few minutes. Block producers have no influence over consensus (almost[1]), they can only make choices about what is included in a block[2].

Disconnecting block proposers from consensus opens up an important design space. The beacon chain randomly selects block proposers from the set of validators, whereas for shard chains this does not have to be the case:

➤ An interesting possibility for sharding (especially Eth1 performing sharding) is that validators can enter the list of produced blocks. Such validators may require higher performance hardware and may also need to have "full" state.

➤ Another possibility is also what we are currently implementing for data sharding. Anyone can be selected to propose a block, but the specific content of the block is not determined by the proposer. Different participants can make their packaged blocks through bidding block is proposed.

first level title

Another important objection may be that if the cost of block proposals is too high, then decentralization will be compromised, even if we lower the threshold for validators and P2P nodes. But that's not the case, there are important differences between "proposers" and "validators":

➤ For verifiers, we need the vast majority to be honest, that is, more than 2/3 of the ETH pledged. The situation of P2P nodes may be similar, but as far as I know, it does not require a certain proportion of P2P nodes to be honest, but in order to ensure that they can always receive a valid chain, everyone needs to connect to at least one honest P2P node, this The ratio is about 5%, and in practice it could be higher.

➤ For proposers, we have much lower requirements for their honesty. Unlike Eth1, Eth2 proposers do not review past blocks (because they do not vote), and can only decide the content of the blocks they propose. Assuming your transaction isn't particularly urgent, if 95% of proposers try to censor it, the 20th proposer can still package it safely (but low-latency censorship resistance is a different matter, more in practice difficult to achieve).

This is why I am less worried about increasing the hardware requirements for proposers than for validators. If we keep normal validator requirements low, there is no problem with proposers requiring PCs with 128GB of RAM to store large states. My concern is if a PC that meets these requirements is priced at $100K but if we keep it under $5K, once the censorship is found, if the community doesn't react quickly by bringing in more proposers is unreasonable.

Finally, there are other reasons why block proposers may need better hardware and have an advantage in acquiring MEV.

first level title

So far in this article I haven't demonstrated why statelessness is so powerful, shrinking the state from 10 GB to 1 GB or 100 MB in the executable beacon chain proposal seems to save validators a lot of overhead, so why do we need stateless Status?

If we go with the flow, the executable Eth1 block can become a shard. In the executable beacon chain proposal, all validators must keep running a full Eth1 execution (or risk signing invalid blocks). While shards should not have this property, only one committee is needed to sign a block in a shard (thus 1/1024 of the validators), and others don't need to trust that the majority of the validators in the committee are honest [3], as long as there is an honest validator who blows the whistle when the committee tries to be evil. And this is only possible if Eth1 is stateless:

➤ We want all validators to have roughly equal load, with no extreme spikes. So sending a validator to be an Eth1 committee member for a long time (e.g. an hour or a day) is actually bad: it means that the validator still has to be able to keep up with the full Eth1 chain in terms of bandwidth requirements . Also, if the same committee is used for a long time (e.g. through a bribing attack), the committee becomes more aggressive

➤ We want to be able to simply give proofs of fraud on Eth1 blocks, as other validators will not be able to be sure that the committee did its job correctly. The simplest way is for the block to be its own proof of fraud: if a block is invalid, the broadcast block itself proves that fraud occurred.

first level title

So what if we went completely stateless but introduced a 10 MB cache? Or 1MB? Easy download even if you just want to check a block, because you have been assigned to a committee, or received that cache as proof of fraud?

You can do this, but we can clearly see that it is unlikely to be optimal if the majority of validators only validate a single block. Let's say we aim for 1 MB blocks, and in addition we have a 1 MB cache, which means that every time a validator wants to validate a block, they have to download 2 MB of data (including the block and the cache) . They have to download the cache every time, unless they download all blocks to keep the cache up to date, which is exactly what we want to avoid.

This means that at the same cost of a 1 MB block size and a 1 MB cache, we can set the cache to 0 and allow the block size to increase to 2 MB.

first level title

In general, I think the voice for full (weak) statelessness trumps partial statelessness or state-rent schemes. This will have less impact on the user: they won't have to think about state at all. The only thing they have to do is add a witness (so that the P2P network can verify valid transactions). The cost of creating a witness is so low that it is conceivable that there will be many related services. In fact most wallets already rely on external services and do not require users to run their own nodes. Getting witnesses is also a tiny feature. [4]

Partial statelessness, or state rent, adds a huge user experience barrier in the path of complete weak statelessness. But consider that trying to achieve statelessness using only binary merkle trees is very difficult, and allowing merkle tree proofs requires changes to the gas, which hurts the user experience.

So in my opinion, we should now work in the direction of verkle tries. This allows us to have manageable proofs of less than 1 MB with only modest gas costs as proposed by EIP-2929 and fees for blocks. Its disadvantages are easily controlled and have little practical impact on users:

➤ Developers need to learn new cryptographic primitives

➤ Add more non-post-quantum-resistant cryptography. The second point sounds scary, but we've introduced KZG commitments in Eth2 for data availability sampling, and we're using elliptic curve-based signatures anyway. Some post-quantum upgrades to the merged Eth1 and Eth2 chains are required, there is currently no practical post-quantum alternative, so we cannot stop moving forward. The next 5 years are extremely important in terms of adoption. The road ahead is to do everything we can, and in 5-10 years, when STARK is strong enough, we will have a full post-quantum upgrade of all primitives.

Overall, verkle tries to address the state of the next five years. Now we will be able to achieve full (weak) statelessness with little to no impact on users and smart contract developers. We will be able to increase the gas limit (as validation becomes faster) and execute more shards, all with little to no impact on security and decentralization.

The toughest nut to crack is getting everyone to understand how KZG promises and verkle tries work. Since Eth2 will use KZG commitments to guarantee data availability, most Ethereum developers will need to work on it.

[1] Little to no impact, as there are now subtle optimizations to improve resistance to certain balance attacks, which do allow proposers to have short-term influence over fork choice.

[2] To be precise, if block producers start to collude and censor large numbers of proofs, there may be an impact, but the impact of a single block producer on consensus is completely negligible.

[3] Dishonest committee misconduct may affect the entire network and cause severe delays, but introducing blocks that cannot be invalidated/unusable

[4] Users who want to run their own nodes will still be able to obtain witnesses through external services. This operation is trustless because witnesses are proofs of themselves given knowledge of the most recent state root

Click "Read the original text" to get the internal link of the article!

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, and the source of the original text and the ETH Chinese website must be indicated when reprinting. For long-term reprinting, please contact eth@ecn.co for authorization.

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, and the source of the original text and the ETH Chinese website must be indicated when reprinting. For long-term reprinting, please contact eth@ecn.co for authorization.