On the State Rent and pivot to Stateless Ethereum

I should have written this long time ago, but it is never too late.

The last published version of the State Rent proposal was number 3, and it was quite a while ago, back in February 2019.

After publishing it, I started to think about how one could realistically deliver such a project. And, very early on, it has been identified that one would definitely need something I call “ecosystem research”. What is it?

We knew from the very beginning of the State research (from the very first proposal, published in November 2018) that introduction of the proportional state rent on the contract storage (“proportional” meaning that contract gets charged rent proportionally to how many storage items it uses), would make most of the currently existing smart contracts vulnerable to “ griefing” attacks, whereby someone can at a small fixed cost make contract pay some amount of rent in perpetuity, eventually leading to the demise of that contract.

We also had a hypothesis that most or even all Dapps could be re-written in such way that makes them non-vulnerable to such attacks. Notable example is a version of ERC-20 token implementation here. Although it was a good start (my estimates at the time showed that about half of all contract storage was taken by the balances and allowances of various ERC-20 contracts), the tail of the Dapps may be quite long.

It would be the task of the “ecosystem research” to meticulously analyse that tail of the Dapps, re-write them into non-vulnerable form, and engage with the maintainers and users of such Dapps to prepare for the change. It became clear that without such “ecosystem research”, the migration to the State rent regime was very unlikely to succeed.

However, it was not hard to estimate that this “ecosystem research” is a very daunting and expensive (perhaps a few million dollars) task. I certainly was not willing to embark on it myself, mostly because I did not think (and I still don’t) that this was where I would add the most value and gain satisfaction from my work. And since, de-facto, I was the only person researching State rent full time to the best of my knowledge, my conclusion that this will not be done, and we need a different plan.

Therefore, I returned to the idea that we “brushed off” (overlooked?) before embarking on the State rent project, namely “Stateless Clients”, or as I call it now, “Stateless Ethereum”. I first got interested in this back at the end of 2017 (scroll to the end of this), and then started on the Turbo-Geth project. The initial scepticism was based on the fact that the block witnesses would be quite large. But now that we are returning to this, we are asking “how large?”, and “can we make them smaller?”. And this is roughly where I started to get some answers.

We also knew that most probably (more data on this will be coming soon), hexary tree that we have in Ethereum make block witnesses larger than a binary tree would. But it appeared an impossible task to switch Ethereum 1 to binary trees. And again, if you think “why?”, the answer is that is based on the assumption that we will be keeping the current way of storing the state in the database (namely modelling data as a directed graph with edges from hashes to the trie nodes). However, if we change to the model that Turbo-Geth uses, the switching over to binary tree becomes quite straightforward. That is why one of my highest priorities at this moment is to “finish” Turbo-Geth, i.e. to solve all the edge cases and to provide enough evidence that its data model works, and it can be adopted by other implementations.

To recap, the State Rent project is currently “suspended”. And the active research, development and specification is happening around “flat db” state storage model and the Stateless Ethereum. There are some advancements that happened since my last blog post in March, and I hope to get some more data and publish it soon. So far you can look at the format that is currently used to construct block witnesses, and watch the progress of Turbo-Geth, as it is hopefully nearing the “stable” stage (we are still changing a lot of things in the database format, so until this is settled, it is not “stable”): https://github.com/ledgerwatch/turbo-geth/issues