The 1.x Files: The State of Stateless Ethereum

The State of Stateless Ethereum

In the last edition of The 1.x files, we did a quick re-cap of where the Eth 1.x research initiative came from, what's at stake, and what some possible solutions are. We ended with the concept of stateless ethereum, and left a more detailed examination of the stateless client for this post.

Stateless is the new direction of Eth 1.x research, so we're going to do a pretty deep dive and get a real sense of the challenges and possibilities that are expected on the road ahead. For those that want to dive even deeper, I'll do my best to link to more verbose resources whenever possible.

The State of Ethereum

To see where we're going, we must first understand where we are with the concept of 'state'. When we say 'state', it's in the sense of "a state of affairs".

The complete 'state' of Ethereum describes the current status of all accounts and balances, as well as the collective memories of all smart contracts deployed and running in the EVM. Every finalized block in the chain has one and only one state, which is agreed upon by all participants in the network. That state is changed and updated with each new block that is added to the chain.

Give it a Trie

The data structure used in Ethereum is called a Merkle-Patricia Trie. Fun fact: 'Trie' is originally taken from the word 'retrieval', but most people pronounce it as 'try' to distinguish it from 'tree' when speaking. But I digress. What we need to know about Merkle-Patricia Tries is as follows:

At one end of the trie, there are all of the particular pieces of data that describe state (value nodes). This could be a particular account's balance, or a variable stored in a smart contract (such as the total supply of an ERC-20 token). In the middle are branch nodes, which link all of the values together through hashing. A branch node is an array containing the hashes of its child nodes, and each branch node is subsequently hashed and put into the array of its parent node. This successive hashing eventually arrives at a single state root node on the other end of the trie.

Stick it in a Database

At this point we should remind ourselves that the trie structure is just an abstract concept. It's a way of packing the totality of Ethereum state into one unified structure. That structure, however, then needs to be implemented in the code of the client, and stored on a disk (or a few thousand of them scattered around the globe). This means taking a multi-dimensional trie and stuffing it into an ordinary database, which understands only [key, value] pairs.

Sync, Baby, Sync

So far we've limited our scope to what's going on in an individual computer running an Ethereum implementation like geth. But Ethereum is a network, and the whole point of all of this is to keep the same unified state consistent across thousands of computers worldwide, and between different implementations of the protocol.

Can I Get a Block Witness?

We can now start to unpack the concept of stateless Ethereum. One of the main goals is to make new nodes less painful to spin up. Given that only 0.1% of the state is changing from block to block, it seems like there should be a means of cutting down on all that extra 'stuff' that needs to be downloaded before the full sync switchover.

Statelessness is a Spectrum

With the introduction of a block witness, the concept of 'fully stateless' starts to get more defined. At the same time, it's where we start to run into open questions and problems with no obvious solution.

The Roadmap Ahead

The elephant in the research room is witness size. Ordinary blocks contain a header, and a list of transactions, and are on the order of 100 kB. This is small enough to make the propagation of blocks quick relative to network latency and the 15 second block time.

Witnesses, however, need to contain the hashes of nodes both at the edges and deep inside the state trie. This means they are much, much bigger: early numbers suggest on the order of 1 MB. Consequently, syncing a witness is much much slower relative to network latency and block time, which could be a problem.

Conclusion

The concept of stateless Ethereum is a complex and multifaceted one, with many challenges and possibilities on the road ahead. While it's still early days for this research initiative, the potential implications for the Ethereum network and its users are significant. As we move forward, it will be interesting to see how the Eth 1.x group tackles the technical challenges and how the community responds to the proposed solutions.

Source: https://blog.ethereum.org/en/2019/12/30/eth1x-files-state-of-stateless-ethereum