Vitalik: Eth2 will increasingly rely on light clients

Editor's Note : On July 28th, Dean Eigenmann asked Twitter on why Twitter used the “execution environment program” to really solve the “state of growth” problem, which sparked a heated debate.

The so-called "state growth" problem means that as the user scale continues to expand and the number of contracts increases, the state data that needs to be stored in the Ethereum node is rising, and the storage and reading performance of the entire node is increasingly High requirements.

In response to this problem, many solutions have been proposed, such as the so-called "state rent" and "stateless client." The state rent requires the user to pay the price for the state that he or she stores. The "stateless client" reduces the access requirements of the entire node to the entire state data by modifying the block structure.

In essence, this is how Eth 2.0 will design a stateful storage scheme and guarantee the availability of state data.

• Gu Yanxi: Bookstore in the Internet Age, Movie Theater in the Blockchain Age
• Suspected "Zhong Bencong" released "My Confession (Part 1)": Reviewing the Origin of Childhood, Bitcoin Name, and the Origin of Nakamoto
• The market responded positively to the positive, and the downward trend has not changed.

In the following, Vitalik briefly explained his views on this issue. What is puzzling is that Vitalik classifies stateless clients as one of the market-oriented storage solutions. But in my opinion, a stateless client is a thorough technical solution to avoid the use of economically complex and costly solutions.

Dean Eigenmann:

For me, the stateless execution environment is not a good way to solve the state growth problem (although no one seems to want to solve this problem). I don't think this solution is feasible, and its incentives may be too complex and will undermine the simplicity of Eth 2.0. @wjvill @VitalikButerin What is your design philosophy?

 

Vitalik:

Let me analyze this debate from my perspective.

Blockchain protocols have traditionally used storage space as a common resource: all nodes store all the content; anyone who uses storage space will apply the cost to all other users.

Such use should be paid for.

However, if you want to pay, you have to face the following problems: It is difficult to determine how to price the storage space, how to determine the size of the target storage space, whether the storage space should be temporarily used or permanently available, how the rent is paid, and so on.

On the other hand, there is a more market-oriented solution for arranging storage resources: for any state data, there must be some users who can benefit from the availability of state data, and other users will be willing to store the data. Therefore, we can allow users to directly contract with the storage to ensure the availability of state data.

Market-based solutions certainly recognize the possibility that some state data will “disappear” (ie not available) if the user is careless. All market-based technologies will encounter this problem.

Therefore, there is a thinking that: yes, we should of course let private contracting become the dominant, but it is related to the convenience of user experience, the agreement should indeed guarantee state availability and storage space supply.

The "stateless client scenario" is completely part of the "marketed storage space" school. Vlad Zamfir is completely part of another camp.

One of the benefits of marketed storage is that you can pay different prices depending on the quality of the state availability assurance service. Of course, another school will say that if users are made aware that their status data may not be used one day, the complexity faced by dApp developers will increase several times.

Having said that, there are still some compromises. For example, in the Execution Environment Plan, you can create an execution environment that requires the block producer to include a random storage key in the block that has been in use for less than a year. This gives the state storage space a guarantee of one year.

However, there are still some open questions to leave for experimental solutions. Statefulness has different levels. For example, if you only want to save a "static witness" attribute, you can save only the ID field of the used receipts; compared to the full state. This is a very lightweight state.

In other words, the situation is becoming more and more clear: Eth2 will increasingly rely on the light client <-> server market, even if it is just for users to get data from more than 1000 shards that they have not synchronized. purpose. State supply is another obligation that can also be put in.

Moreover, there are other methods at the protocol level that can be used to enforce stateful storage guarantees, such as adding a one-year proof of custody to the main type of receipt (so that the execution environment can recover the entire state tree).

(Finish)

Original link:

https://twitter.com/VitalikButerin/status/1155566281229254657

Author: Vitalik

Translation: Ajian

(This article is from the EthFans of Ethereum fans, and it is strictly forbidden to reprint without the permission of the author.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!