Statelessness, Verkle Trees, & State Expiry
Decentralization- through some centralization
Ethereum’s State is growing at a rapid pace, with no limits to how big it can get. Without any checks, Ethereum’s State can grow towards infinity, creating massive difficulties when updates to that state need to be made and validated. Statelessness, Verkle Trees, and State Expiry are a collection of concepts that solve this problem. Today’s write-up explains each, their compromises, and their solutions. Enjoy.
*Thank you to Ziad for proofreading.
What is the State?
The State is the current snapshot of all Ethereum accounts, balances, and data. Every time a block is added to the blockchain, the State is updated to reflect the changes that occurred. Validators on Ethereum are responsible for creating the updated State when they add a block to the chain, and for checking the work of other Validators when someone else adds a block. Let’s see this in the block production process today.
An Ethereum Validator assembles transactions into blocks, and when it’s their turn, they add a block to the chain. When that happens, they execute all the transactions in a block to compute the changes they result in. They use those changes to create a new State and a simple proof of what it looks like, called a Root Hash. Finally, Validators broadcast the Root Hash, along with all the data for the transactions they executed, and all the other Validators on the network do the same work, ensuring they arrive at the same result, or Root Hash.
The problem with the process above is that every Validator must maintain a copy of the (growing) Ethereum State. This is because you need to have a copy of the old State to compute the changes to the new one. This increases hardware requirements for all Validators, reducing decentralization.
Statelessness solves this problem. Statelessness does not mean getting rid of the State entirely, but it makes maintaining the State the responsibility of a select group of people.
Proposer-Builder Separation
Statelessness builds on the idea of separating the roles a Validator performs. This concept of splitting a Validator into roles is known as Proposer-Builder Separation, or PBS. PBS is part of the Danksharding upgrade (read my write-up here), and essentially creates a group of Builders that assembles transactions into blocks, and a group of Proposers that select from those blocks and add them to the blockchain.
Building on PBS, Statelessness proposes that only Builders be responsible for maintaining the full state, so that Proposers don’t need to. This makes it very easy to be a Proposer, but increases the difficulty for Builders, increasing Builder centralization. To counter this, Statelessness allows for a new type of role, that of a Verifier. To understand this new paradigm, let’s review how Statelessness actually works.
How Does Statelessness Work?
On trustless, decentralized systems like Ethereum, we need to be able to check the work of others. When a block is added to Ethereum today, each node executes the transactions in a block to verify validity. To do this, they must maintain a copy of the State, as described above.
Statelessness introduces the concept of “Witnesses” to blocks. Witnesses are not people; they’re proofs of all the changes that happen in a particular block. A block’s Witness can be used to verify all the changes a block made to the State, without needing any other data. This means that verifying a block is valid becomes very easy; there’s no need to store any historic data, only to execute a block with its Witness.
While this solves the problem of needing to maintain the State, if every block needs to include some new additional data as the Witness, then the amount of data being transmitted increases, along with hardware requirements, i.e. centralization. To reduce the size of information being transmitted, Statelessness goes hand in hand with another concept named Verkle Trees.
Verkle Trees
Verkle Trees are the proposed future data structure for Ethereum. They transform the Merkle Patricia Trees that Ethereum uses today (read more about that in my write-up here). Instead of hashes, Verkle Trees use “Commitments” to store data. Data in Commitments be verified much more easily, even when someone only wants to verify a portion of the data inside. Hashes, on the other hand, require an all or nothing approach.
Like hashes, these “Vector Commitments” are structured into a tree, achieving several benefits. Mainly, it allows for a much more efficient verification of data. Data can be verified by tracing a single path of elements down the tree. This is impossible with trees made of hashes, since knowing the data in one hash requires knowing the data in every hash beneath it (instead of only the one you’re interested in).
State Expiry
Verkle Trees allow for a phenomenon known as State Expiry. State Expiry involves making old, unused parts of the State, expire. Instead of forcing the State to maintain everything, the State maintains only active things. Things that are inactive expire, but can be made active again when needed.
State Expiry proposes creating a new Verkle Tree to track Ethereum’s State every year. When the year ends, a new Verkle Tree is created, containing all the transactions that’ll happen that year. Builders will be responsible for maintaining each year’s Verkle Tree, and keeping a copy of the one from the year before. But what if your account was last active 3 years (or Trees) ago?
Accounts that have been inactive for a while, and have expired, can be resurrected. This involves a transaction that proves the account is not in the current or last tree, but existed before. This transaction brings the account into the active State Tree, allowing it to do whatever it wants. But what if you want to send money to an expired account?
To send money to an expired account, it would need to be brought into the current Tree so that its balance can be updated. Ordinarily, this would mean the sender would need to pay the resurrection fee to send money to that account. To prevent this from being necessary, State Expiry proposes an additional upgrade known as Address Space Extension, or ASE.
ASE: Address Space Extension
Briefly, Address Space Extension involves enlarging the Ethereum address, with the newly expanded section encoding some data about the address. The data encoded would be the date that the address was first accessed. This new date extension facilitates the transfer of funds to expired addresses.
Thanks to ASE, when someone transfers funds to an expired address, they don’t need to pay for the resurrection cost. Instead, the address the funds were sent to would encode a new value in the date section, for the current date. When the owner of the expired address resurrects it, they’ll have access to all their funds, old and new.
Taken Together
Statelessness makes it extremely easy to be a Verifier; anyone could potentially be one with only a smartphone. This is a trade-off for making being a Builder more difficult; decentralization of Verifiers for some centralization of Builders. It may seem surprising that Ethereum would compromise decentralization in any aspect, but most Ethereum researchers believe that MEV will result in the same centralization anyway. Read more about MEV in my write-up here.
Statelessness attempts to mitigate a likely centralization of Builders by making it exceedingly easy to verify what Builders are doing. It also makes it easier to be a Proposer, since Proposers wouldn’t need to maintain the State anymore. Slightly less Builders, but many more Proposers and Verifiers are its ultimate objectives.
The State itself will become easier to maintain over time thanks to more efficient data storage with Verkle Trees and State Expiry. In the future, the State won’t refer to everything on Ethereum, but everything active within a particular period. This makes State maintenance far more achievable.
Some ancillary benefits include the possibility of lower gas fees. If the State can be allowed to grow more rapidly, then we can comfortably increase the block size, thereby reducing transaction fees. Finally, simple Verifier nodes can allow anyone to engage with the blockchain directly instead of through a centralized provider like Infura or Alchemy.
In Conclusion
Ethereum’s State cannot continue on a trajectory towards infinity; if it does then fewer people can be Validators, making Ethereum centralized - and also inefficient. Statelessness solves this problem by isolating the difficulties of what a Validator does today to a specific role, allowing more accessibility across other areas. This does seem like a pragmatic decision, but the impacts are to be seen.
Thank you for reading, I hope you enjoyed this summary on Statelessness, Verkle Trees, and State Expiry!
If you have any questions, please comment them on this post! If you’d like me to cover any topics, feel free to suggest them in the comments also.
Thank You & Additional Reading!
Thanks a lot for reading! Here are some more resources if you'd like to dive deeper.
Exploring Ethereum's Roadmap: The Role of Verge and Verkle Trees in Stateless Clients by CryptoEQ
The Promise of 'Stateless Ethereum' by Edward Oosterbaan and Sage D. Young
Statelessness & Verkle Trees (Video) by Guillaume Ballet
Weak statelessness and/or state expiry: coming soon by Vitalik Buterin
Sign up if you haven’t already for more simple write-ups on blockchain concepts!
Share a Summary
Thanks again, please consider sharing this write-up below!
Stay kind. Stay curious.
