Viewpoint | On State Rent and Stateless Ethereum

Author: Alexey Akhunov

Translation & Proofreading: Ajian & Zeng Wei

Source: Ethereum fans

Editor's Note: This article is from Alexey Akhunov. He is a developer who is completely focused on Ethereum 1.0.

• Starting from the bottom of the card currency: the world's wealth of 36 billion, members were arrested one after another, Chinese believers are still
• Beginner's Guide | Why choose a highly liquid exchange?
• QKL123 market analysis | For the central bank digital currency, what is the country's intention? (1115)

Many people should remember that when the entire blockchain community witnessed the rapid growth of Ethereum's state data and the increasing demand for node storage device performance, the community proposed a variety of solutions, one of which is the name. A “state rent” that is noisy at a time, that is, a rent for a contract that stores data in a state.

As mentioned in the article, Alexey is the only developer who has been the only full-time research state rent program for a long time. Today, he also said that he would suspend state rent research and turn to stateless clients. I think this also means that the efforts to develop state rents at Ethereum have come to an end. I am not a pity, in fact I have never supported the state rent plan. I want to say that the project is like this, it will continue to encounter problems, and there will be new ideas coming out, and there will be many ideas that will prove impossible in the future. I think that the concept of a solution, even if it solves the problem, is ignorance and contempt for the project.

Alexey Come on!

I should have written this article long ago. But it’s not too late to make up for it.

The latest published state rent proposal is the No. 3 program, but it was published in February 2019 and it was a long time ago.

After writing this plan, I began to consider how to implement this project in a reliable manner. Moreover, a long time ago, everyone realized that we absolutely need a project that I call “ecosystem research”. how to say?

The knowledge we had at the beginning of the Ethereum state problem study (originally proposed in November 2018) was: If a proportional state rent was introduced for contract storage (“proportional” means the rent paid by the contract) It is proportional to the state storage space used by it, which will lead to loopholes in existing contracts and is vulnerable to "griefing" attacks. Therefore, some people can use a penny. A small fixed fee causes the contract to pay some rent forever, which eventually leads to the collapse of the contract.

We also assume that most, if not all, dApps can be rewritten to be immune to such attacks. A notable example is a version of the ERC-20 token implementation. Although this is a good start (I estimated at the time that about half of the contract storage was occupied by the balance of various ERC-20 contracts and the reserve fund), the long tail of the dApp may be very long (translator) Note: that is, many types).

In this scenario, the so-called "ecosystem research" is to carefully analyze the long tail of the dApp, rewrite the form of immune vulnerability, and communicate with the maintenance personnel and users of these dApps to prepare for the change. It is now clear that without such an “ecosystem research”, the migration to a state rent system is almost impossible to succeed.

However, it is not difficult to realize that such “ecosystem research” is very difficult and very expensive (may be a few million dollars). I certainly don't want to do it myself, largely because I don't think (and still don't think it is), this is the job I can create the most value and get the most accomplishment. And, as far as I know, I am the only person who is actually the only full-time study of the state rent plan, so my conclusion is: This is not fixed, we need another plan.

Then, I returned to the idea of ​​“abandoning” (or “ignoring”) before investing in a state rent project, called “stateless client”, or my current name is “stateless Ethereum”. I started to have an interest in this program at the end of 2017 (rolled to the bottom in this article), and then during the development of the Turbo-Geth project. My initial suspicions were based on the fact that the size of the block witness data can be quite large. But now we are back to this concept, we are asking: "How big is it" and "Can we narrow down the data?" And this article is my initial attempt to find an answer. (Editor's Note: Chinese translation of the text at the end of the text hyperlink "Preliminary study of stateless client")

We also know that it is quite possible that the hexadecimal Merkel tree used by Ethereum will make the block witness more data than the binary tree (more data will be revealed soon). But it seems that switching Ethereum 1.0 to a binary tree is also an impossible task. If you want to ask: "Why?" The answer is, because we assume that the way we store the state in the database will remain the same (ie, the data will be modularized into a directed graph, and the direction from the hash value to the tree node is the directed graph. One side). However, if we change this mode, switching Turbo-Geth to a binary tree is very straightforward. That's why one of my current top priorities is to "complete" Turbo-Geth, which handles all exceptions and provides sufficient evidence to prove that its data model works, and can be implemented by other implementations. accept.

To sum up, the state rental project is currently “suspended”. The current active research, development, and technical details focus on the "flat db" state storage model and stateless Ethereum. Since I wrote the blog in March, we have made some progress, and I hope to get more data and publish it as soon as possible. You can now go to this page to see the format we are currently using to construct block witness data; you can also see the progress of Turbo-Geth, which is expected to be close to the "stable" phase (we are still making a lot of changes to the data format, So before completing this part of the work, it is still not "stable": https://github.com/ledgerwatch/turbo-geth/issues.

(Finish)

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