Some core developers predict that if the state size continues to increase at the current pace, Ethereum will break within three years.
The leading posited solution to slow its growth is the imposition of "state rent," i.e., charging people to store data. (In some instances this is referred to as "storage rent," but for the purpose of this article, I will be using the term "state rent.")
The effect of this would be largely unpleasant for user experience and would likely have negative implications on existing applications. Moreover, not everyone agrees that the state size issue is as pressing as some make it out to be.
While it is ultimately the core developers who will program the fix, they don't seem eager to decide the appropriate solution on behalf of the Ethereum community. This is because although the problem is technical in nature, the solutions involve making some value tradeoffs that would affect usability. Thus, coordinating around the issue is somewhat difficult. This article attempts to frame the problem – and the proposition of state rent as the solution – in relatively approachable terms.
An Unwieldy Amount of Data
Storing data requires disk space, and syncing that data takes time, both of which are key considerations in a blockchain network where at least some nodes must sync and store the entire chain data (or even significant chunks of it).
This is not just a question of efficiency, but of sustainability and scalability. As it stands, it already takes weeks to fully sync and download an archival node and that's with – let's be honest – minimal usage of the Ethereum network.
If you're not a super technical person, or don't know the ins and outs of the Ethereum blockchain, you might assume that this is because the chain is so long. But that's only part of it. In fact, syncing all the blocks (block headers, block hashes) is only one part of the process.
The problem is that a significant chunk of necessary information – the state trie – is not contained in the blocks themselves. The state trie is a complex structure containing all current accounts and a bunch of cryptographic proofs. Before a node can cryptographically prove anything about any account, this information needs to be made available to a node. It takes just as long, or longer, to sync this information as it does the chain itself.
This isn't a new concern. The Ethereum yellow paper acknowledges the unwieldiness of processing and storing the entire state trie, suggesting: "blockchain compression could perhaps be conducted: nodes in state trie that haven't sent/received a transaction in some constant amount of blocks could be thrown out, reducing … the growth of the state database."
In March, while discussing the idea for what is now referred to as Ethereum 2.0, Vitalik Buterin proposed a model on Ethresearch to collect rent fees as a way to limit state size.
Approaching the Problem from Different Angles
While a long-understood issue, state size has recently become a key topic of discussion in the development community. The Fellowship of Ethereum Magicians has a ring dedicated to Ethereum 1.x, the pre-Casper/Sharding Ethereum upgrades. That ring contains two working groups dedicated to addressing the issue of storing the growing mass of Ethereum data, each from different angles: one working group is dedicated to chain pruning and state reduction (cutting away old and unnecessary data), and one – the state rent working group – is specifically dedicated to managing state growth. While the need for state reduction and chain pruning are closely related to the need to manage state size, the issues require different solutions, and therefore different tradeoffs, and so warrant separate discussions (and articles).
Briefly, the conversation about chain pruning and state reduction centers around tradeoffs between efficiency and scalability, as well as between security and immutability. The conversation around reducing state growth by imposing a state rent requires confronting the fact that imposing a state rent will significantly diminish an already sticky user experience and pose an undue burden on existing applications whose developers were unable to factor state rent into their designs. While both warrant air time, the focus of this article is on the topic of limiting the growth of state trie via state rent.
Why State Rent
The proposed state rent solution would apply to what Alexey Akhunov, Turbo Geth developer and author of a recent (early, rough) Ethereum state rent proposal, refers to as the "active state," which is comprised of "all non-empty accounts and all contracts that have been created but not self-destructed."
The idea behind state rent as a solution to state bloat is twofold: One benefit is that unpaid rent dues are an easy way to identify inactive accounts or unvalued data, which can then be "evicted" from the state. It may also be true that if it costs more to do stuff on Ethereum, people would be smarter about the stuff they do on Ethereum. Charging for the disk space consumed by account activity incentivizes the development of storage-optimized contracts and more data-conscious users. If there are fewer accounts, less-active accounts, or more efficient accounts, then the rate of state trie growth will necessarily slow.
Implications of Imposing State Rent
As it stands, those who see state rent as the most viable (if disagreeable) option are in the process of discussing who should pay the rent, and the specifics about how rent fees might be calculated. These questions have significant implications.
Who might pay the rent is a particularly meaningful question, especially when censorship resistance is taken into consideration. One of the most attractive promises of Ethereum for many in the community is that it enables unstoppable organizations capable of running without much/any human intervention so that a business can never be shut down by a regulatory body, or anyone else. Requiring an organization to pay periodic fees to maintain data availability compromises that promise, at least for already deployed applications whose developers were not able to anticipate this need.
Though, in Akhunov's proposal, he grants that even given advanced notice, it may be difficult for contracts to collect rent fees from users. Additionally, it would be possible for users to behave irresponsibly or maliciously and pump a contract full of data, upping its rent dues. For these reasons, charging contracts state rent based on data storage is complicated.
Even if individual users interacting with applications are the ones who pay for the storage of their data, mandatory state rent could have negative implications for censorship resistance if they are, for whatever reason, prevented from paying – or unable to keep up with – their dues.
It should be noted that if a contract failed to pay its rent fees, the contract or account itself would not be deleted, only the information contained in the active state (such as account balances). The contract could continue to run if the data were made available by another means; Akhunov and others have discussed the possibility of individuals or organizations downloading and storing their own data, or certain nodes electing to do so.
Akhunov attempts to address these concerns in his draft proposal, but concedes that implementing state rent will have drastic consequences.
"Unfortunately, the way I see it, most contracts will need to be re-written, re-deployed, and re-filled with data. To me it is the choice – either contracts need to be changed, or platform has to die."
Maybe Rent Can Wait
Casey Detrio, a core developer working on Ethereum 1.x, authored what he calls "Ethereum 1 dot X: a half-baked roadmap for mainnet improvements." In it, he outlines the issue of limited disk space and some of the proposed solutions to address state bloat. In his summary, he states that some researchers see Ethereum 2.0 as a solution, so long as it is launched relatively quickly. This, of course, comes with the assumption that Casper and sharding will be coming soon, which might be a fairly significant leap. Additionally, the assertion that state size will cease to be a problem under Ethereum 2.0 is not an accepted fact, as sharding does not offer unlimited scalability.
To this point, Detrio cites the concern that "introducing a rent mechanism on Ethereum 1.0 could be confusing to users, as it will likely be different from the rent mechanism introduced on 2.0."
The leading alternative to imposing a state rent is to create stateless clients and stateless contracts. The feasibility of this option is debatable, though. Further, it would force all contracts to be responsible for storing and maintaining their own data, which might be a bit of a stretch.
In the Meantime
In the meantime, more work needs to be done to develop proposals and proofs of concept to test the implications of any given state rent mechanism. Once that happens, it will be up to client and Dapp developers to determine the tradeoffs they're willing to make.