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 Stateless 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.

In the context of Eth 1.x research, it’s important not just to know what state is, but how it’s represented in both the protocol (as defined in the yellow paper), and in most client implementations (e.g. geth, parity, trinity, besu, etc.).

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.

In the simplified diagram above, we can see each value, as well as the path that describes how to get to that value. For example, to get to V-2, we traverse the path 1,3,3,4. Similarly, V-3 can be reached by traversing the path 3,2,3,3. Note that paths in this example are always 4 characters in length, and that there is often only one path to take to reach a value.

This structure has the important property of being deterministic and cryptographically verifiable: The only way to generate a state root is by computing it from each individual piece of the state, and two states that are identical can be easily proven so by comparing the root hash and the hashes that led to it (a Merkle proof). Conversely, there is no way to create two different states with the same root hash, and any attempt to modify state with different values will result in a different state root hash.

Ethereum optimizes the trie structure by introducing a few new node types that improve efficiency: extension nodes and leaf nodes. These encode parts of the path into nodes so that the trie is more compact.

In this modified Merkle-Patricia trie structure, each node will lead to a choice between multiple next nodes, a compressed part of a path that subsequent nodes share, or values (prepended by the rest of their path, if necessary). It’s the same data and the same organization, but this trie only needs 9 nodes instead of 18. This seems more efficient, but with the benefit of hindsight, isn’t actually optimal. We’ll explore why in the next section.

To arrive at a particular part of state (such as an account’s current balance of Ether), one needs to start at the state root and crawl along the trie from node to node until the desired value is reached. At each node, characters in the path are used to decide which next node to travel to, like a divining rod, but for navigating hashed data structures.

In the ‘real’ version used by Ethereum, paths are the hashes of an address 64 characters (256 bits) in length, and values are RLP-encoded data. Branch nodes are arrays that contain 17 elements (sixteen for each of the possible hexadecimal characters, and one for a value), while leaf nodes and extension nodes contain 2 elements (one partial path and either a value or the hash of the next child node). The Ethereum wiki is likely the best place to read more about this, or, if you would like to get way into the weeds, this article has a great (but unfortunately deprecated) DIY trie exercise in Python to play with.

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.

In most Ethereum clients (all except turbo-geth), the Merkle-Patricia Trie is implemented by creating a distinct [key, value] pair for each node, where the value is the node itself, and the key is the hash of that node.

The process of traversing the trie, then, is more or less the same as the theoretical process described earlier. To look up an account balance, we would start with the root hash, and look up its value in the database to get the first branch node. Using the first character of our hashed address, we find the hash of the first node. We look that hash up in the database, and get our second node. Using the next character of the hashed address, we find the hash of the third node. If we’re lucky, we might find an extension or leaf node along the way, and not need to go through all 64 nibbles — but eventually, we’ll arrive at our desired account, and be able to retrieve its balance from the database.

Computing the hash of each new block is largely the same process, but in reverse: Starting with all the edge nodes (accounts), the trie is built through successive hashings, until finally a new root hash is built and compared with the last agreed-upon block in the chain.

Here’s where that bit about the apparent efficiency of the state trie comes into play: re-building the whole trie is very intensive on disk, and the modified Merkle-Patricia trie structure used by Ethereum is more protocol efficient at the cost of implementation efficiency. Those extra node types, leaf and extension, theoretically save on memory needed to store the trie, but they make the algorithms that modify the state inside the regular database more complex. Of course, a decently powerful computer can perform the process at blazing speed. Sheer processing power, however, only goes so far.

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.

The constantly shuffling tokens of #Defi, cryptokitty auctions or cheeze wizard battles, and ordinary ETH transfers all combine to create a rapidly changing state for Ethereum clients to stay in sync with, and it gets harder and harder the more popular Ethereum becomes, and the deeper the state trie gets.

Turbo-geth is one implementation that gets to the root of the problem: It flattens the trie database and uses the path of a node (rather than its hash) as the [key, value] pair. This effectively makes the depth of the tree irrelevant for lookups, and allows for a variety of nifty features that can improve performance and reduce the load on disk when running a full node.

The Ethereum state is big, and it changes with every block. How big, and how much of a change? We can ballpark the current state of Ethereum at around 400 million nodes in the state trie. Of these, about 3,000 (but as many as 6,000) need to be added or modified every 15 seconds. Staying in sync with the Ethereum blockchain is, effectively, constantly building a new version of the state trie over and over again.

This multi-step process of state trie database operations is why Ethereum implementations are so taxing on disk I/O and memory, and why even a “fast sync” can take up to 6 hours to complete, even on fast connections. To run a full node in Ethereum, a fast SSD (as opposed to a cheap, reliable HDD) is a requirement, because processing state changes is extremely demanding on disk read/writes.

Here it’s important to note that there is a very large and significant distinction between establishing a new node to sync and keeping an existing node synced — A distinction that, when we get to stateless Ethereum, will blur (hopefully).

The straightforward way to sync a node is with the “full sync” method: Starting from the genesis block, a list of every transaction in each block is retrieved, and a state trie is built. With each subsequent block, the state trie is modified, adding and modifying nodes as the complete history of the blockchain is replayed. It takes a full week to download and execute a state change for every block from the beginning, but it’s just a matter of time before the transactions you need are pending inclusion into the next new block, rather than being already solidified in an old one.

Another method, aptly named “fast-sync”, is quicker but more complicated: A new client can, instead of requesting transactions from the beginning of time, request state entries from a recent, trusted ‘checkpoint’ block. It’s far less total information to download, but it is still a lot of information to process– sync is not currently limited by bandwidth, but by disk performance.

A fast-syncing node is essentially in a race with the tip of the chain. It needs to get all of the state at the ‘checkpoint’ before that state goes stale and stops being offered by full nodes (It can ‘pivot’ to a new checkpoint if that happens). Once a fast-syncing node overcomes the hurdle and get its state fully caught up with a checkpoint, it can then switch to full sync — building and updating its own copy of state from the included transactions in each block.

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.

But this is one of the challenges imposed by Ethereum’s cryptographically secure data structure: In a trie, a change to just one value will result in a completely different root hash. That’s a feature, not a bug! It keeps everybody certain that they are on the same page (at the same state) with everyone else on the network.

To take a shortcut, we need a new piece of information about state: a block witness.

Suppose that just one value in this trie has changed recently (highlighted in green):

A full node syncing the state (including this transaction) will go about it the old-fashioned way: By taking all the pieces of state, and hashing them together to create a new root hash. They can then easily verify that their state is the same as everyone else’s (since they have the same hash, and the same history of transactions).

But what about someone that has just tuned in? What’s the smallest amount of information that new node needs in order to verify that — at least for as long as it’s been watching — its observations are consistent with everyone elses?

A new, oblivious node will need older, wiser full nodes to provide proof that the observed transaction fits in with everything they’ve seen so far about the state.

In very abstract terms, a block witness proof provides all of the missing hashes in a state trie, combined with some ‘structural’ information about where in the trie those hashes belong. This allows an ‘oblivious’ node to include the new transaction in its state, and to compute the new root hash locally — without requiring them to download an entire copy of the state trie.

This is, in a nutshell, the idea behind beam sync. Rather than waiting to collect each node in the checkpoint trie, beam sync begins watching and trying to execute transactions as they happen, requesting a witness with each block from a full node for the information it doesn’t have. As more and more of the state is ‘touched’ by new transactions, the client can rely more and more on its own copy of state, which (in beam sync) will gradually fill in until it eventually switches over to full sync.

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.

In contrast to beam sync, a truly stateless client would never keep a copy of state; it would only grab the latest transactions together with the witness, and have everything it needs to execute the next block.

You might see that, if the entire network were stateless, this could actually hold up forever– witnesses for new blocks can be produced from the previous block. It’d be witnesses all the way down! At least, down to the last agreed upon ‘state of affiars’, and the first witness generated from that state. That’s a big, dramatic change to Ethereum not likely to win widespread support.

A less dramatic approach is to accommodate varying degrees of ‘statefullness’, and have a network in which some nodes keep a full copy of the state and can serve everyone else fresh witnesses.

• Full-state nodes would operate as before, but would additionally compute a witness and either attach it to a new block, or propagate it through a secondary network sub-protocol.

• Partial-state nodes could keep a full state for just a short number of blocks, or perhaps just ‘watch’ the piece of state that they’re interested in, and get the rest of the data that they need to verify blocks from witnesses. This would help infrastructure-running dapp developers immensely.

• Zero-state nodes, who by definition want to keep their clients running as light as possible, could rely entirely on witnesses to verify new blocks.

Getting this scheme to work might entail something like bittorrent-style chunking and swarming behavior, where witness fragments are propagated according to their need and best connections to other nodes with (complementary) partial state. Or, it might involve working out an alternative implementation of the state trie more amenable to witness generation. This is stuff to investigate and prototype!

For a much more in-depth analysis of what the trade-offs of stateful vs stateless nodes are, see Alexey Akhunov’s The shades of statefulness.

An important feature of the semi-stateless approach is that these changes don’t necessarily imply big, hard-forking changes. Through small, testable, and incremental improvements, it’s possible to build out the stateless component of Ethereum into a complementary sub-protocol, or as a series of un-controversial EIPs instead of a large ‘leap-of-faith’ upgrade.

The road(map) 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.

The dilemma is akin to the difference between downloading a movie or streaming it: If the network is too slow to keep up with the stream, downloading the full movie is the only workable option. If the network is much faster, the movie can be streamed with no problem. In the middle, you need more data to decide. Those with sub-par ISPs will recognize the gravity of attempting to stream a friday night movie over a network that might not be up for the task.

This, largely, is where we start getting into the detailed problems that the Eth 1x group is tackling. Right now, not enough is known about the hypothetical witness network to know for sure it’ll work properly or optimally, but the devil is in the details (and the data).

One line of inquiry is to think about ways to compress and reduce the size of witnesses by changing the structure of the trie itself (such as a binary trie), to make it more efficient at the implimentation level. Another is to prototype the network primitives (bittorrent-style swarming) that allow witnesses to be efficiently passed around between different nodes on the network. Both of these would benefit from a formalized witness specification — which doesn’t exist yet.

All of these directions (and more) are being compiled into a more organized roadmap, which will be distilled and published in the coming weeks. The points highlighted on the roadmap will be topics of future deep dives.

If you’ve made it this far, you should have a good idea of what “Stateless Ethereum” is all about, and some of the context for emerging Eth1x R&D.

As always, if you have questions about Eth1x efforts, requests for topics, or want to contribute, come introduce yourself on ethresear.ch or reach out to @gichiba and/or @JHancock on twitter.

Special thanks to Alexey Akhunov for providing technical feedback and some of the trie diagrams.

Happy new year, and happy Muir Glacier hardfork!

I started to write a post that detailed a “roadmap” for Ethereum 1.x research and the path to stateless Ethereum, and realized that it’s not actually a roadmap at all —— at least not in the sense we’re used to seeing from something like a product or company. The 1.x team, although working toward a common goal, is an eclectic collection of developers and researchers independently tackling intricately related topics. Consequently, there is no “official” roadmap to speak of. It’s not complete chaos though! There is an understood “order of operations”; some things must happen before others, certain solutions are mutually exclusive, and other work might be beneficial but non-essential.

So what’s a better metaphor for the way we get to stateless Ethereum, if not a roadmap? It took me a little bit, but I think I have a good one: Stateless Ethereum is the ‘full spec’ in a tech tree.

Some readers might immediately understand this analogy. If you “get it”, feel free to skip the next few paragraphs. But if you’re not like me and don’t ordinarily think about the world in terms of video games: A tech tree is a common mechanic in gaming that allows players to unlock and upgrade new spells, technologies, or skills that are sorted into a loose hierarchy or tree structure.

Usually there is some sort of XP (experience points) that can be “spent” to acquire elements in the tree (‘spec’), which in turn unlock more advanced elements. Sometimes you need to acquire two un-related basic elements to access a third more advanced one; sometimes unlocking one basic skill opens up multiple new choices for the next upgrade. Half the fun as a player is choosing the right path in the tech trie that matches your ability, goals, and preferences (do you aim for full spec in Warrior, Thief, or Mage?).

That’s, in surprisingly accurate terms, what we have in the 1.x research room: A loose hierarchy of technical subjects to work on, with limited time/expertise to invest in researching, implementing, and testing. Just as in a good RPG, experience points are finite: there’s only so much that a handful of capable and motivated humans can accomplish in a year or two. Depending on the requirements of delivery, it might be wise to hold off on more ambitious or abstract upgrades in favor of a more direct path to the final spec. Everyone is aiming for the same end goal, but the path taken to get there will depend on which solutions end up being fully researched and employed.

Ok, so I’ll present my rough drawing of the tree, talk a little about how it’s arranged, and then briefly go into an explanation of each upgrade and how it relates to the whole. The final “full-spec” upgrade in the tech tree is “Stateless Ethereum”. That is to say, a fully functioning Ethereum mainnet that supports full-state, partial-state, and zero-state nodes; that efficiently and reliably passes around witnesses and state information; and that is in principle ready to continue scaling until the bridge to Eth2.0 is built and ready to onboard the legacy chain.

Note: As I said just above, this isn’t an ‘official’ scheme of work. It’s my best effort at collating and organizing the key features, milestones, and decisions that the 1x working group must settle on in order to make Stateless Ethereum a reality. Feedback is welcome, and updated/revised versions of this plan will be inevitable as research continues.

You should read the diagram from left to right: purple elements presented on the left side are ‘fundamental’ and must be developed or decided upon before subsequent improvements further right. Elements with a greenish hue are colored so to indicate that they are in some sense “bonus” items — desirable though not strictly necessary for transition, and maybe less concretely understood in the scope of research. The larger pink shapes represent essential milestones for Stateless Ethereum. All 4 major milestones must be “unlocked” before a full-scale transition to Stateless Ethereum can be enacted.

The Witness Format

There has been a lot of talk about witnesses in the context of stateless Ethereum, so it should come as no surprise that the first major milestone that I’ll bring up is a finalized witness format. This means deciding with some certainty the structure of the state trie and accompanying witnesses. The creation of a specification or reference implementation could be thought of as the point at which ETH 1.x research “levels up”; coalescing around a new representation of state will help to define and focus the work needed to be done to reach other milestones.

Binary Trie (or “trie, trie again”)

Switching Ethereum’s state to a Binary Trie structure is key to getting witness sizes small enough to be gossiped around the network without running into bandwidth/latency issues. As outlined in the last research call, getting to a Binary Trie will require a commitment to one of two mutually exclusive strategies:

• Progressive. Like the Ship of Theseus, the current hexary state trie woud be transformed piece-by-piece over a long period of time. Any transaction or EVM execution touching parts of state would by this strategy automatically encode changes to state into the new binary form. This implies the adoption of a ‘hybrid’ trie structure that will leave dormant parts of state in their current hexary representation. The process would effectively never complete, and would be complex for client developers to implement, but would for the most part insulate users and higher-layer developers from the changes happening under the hood in layer 0.

• Clean-cut. Perhaps more aligned with the significance of the underlying trie change, a clean-cut transition strategy would define an explicit time-line of transition over multiple hard forks, compute a fresh binary trie representation of the state at that time, then carry on in binary form once the new state has been computed. Although more straightforward from an implementation perspective, a clean-cut requires coordination from all node operators, and would almost certainly entail some (limited) disruption to the network, affecting developer and user experience during the transition. On the other hand, the process might provide some valuable insights for planning the more distant transition to Eth2.

Regardless of the transition strategy chosen, a binary trie is the basis for the witness structure, i.e. the order and hierarchy of hashes that make up the state trie. Without further optimization, rough calculations (January 2020) put witness sizes in the ballpark of ~300-1,400 kB, down from ~800-3,400 kB in the hexary trie structure.

Code Chunking (merkleization)

One major component of a witness is accompanying code. Without code chunking, A transaction that contained a contract call would require the full bytecode of that contract in order to verify its codeHash. That could be a lot of data, depending on the contract. Code ‘merkleization’ is a method of splitting up contract bytecode so that only the portion of the code called is required to generate and verify a witness for the transaction. This is one technique of dramatically reducing the average size of witnesses. There are two ways to split up contract code, and for the moment it is not clear the two are mutually exclusive.

• “Static” chunking. Breaking contract code up into fixed sizes on the order of 32 bytes. For the merkleized code to run correctly, static chunks also would need to include some extra meta-data along with each chunk.
• “Dynamic” chunking. Breaking contract code up into chunks based on the content of the code itself, cleaving at specific instructions (JUMPDEST) contained therein.

At first blush, the “static” approach in code chunking seems preferable to avoid leaky abstractions, i.e. to prevent the content of the merkleized code from affecting the lower-level chunking, as might happen in the “dynamic” case. That said, both options have yet to be thoroughly tested and therefore both remain in consideration.

ZK witness compression

About 70% of a witness is hashes. It might be possible to use a ZK-STARK proofing technique to compress and verify those intermediate hashes. As with a lot of zero-knowledge stuff these days, exactly how that would work, or even that it would work at all is not well-defined or easily answered. So this is in some sense a side-quest, or non-essential upgrade to the main tech development tree.

EVM Semantics

We’ve touched briefly on “leaky abstraction” avoidance, and it is most relevant for this milestone, so I’m going to take a little detour here to explain why the concept is important. The EVM is an abstracted component part of the bigger Ethereum protocol. In theory, details about what is going on inside the EVM should have no effect at all on how the larger system behaves, and changes to the system outside of the abstraction should have no effect at all on anything within it.

In reality, however, there are certain aspects of the protocol that do directly affect things inside the EVM. These manifest plainly in gas costs. A smart contract (inside the EVM abstraction) has exposed to it, among other things, gas costs of various stack operations (outside the EVM abstraction) through the GAS opcode. A change in gas scheduling might directly affect the performance of certain contracts, but it depends on the context and how the contract makes use of the information to which it has access.

Because of the ‘leaks’, changes to gas scheduling and EVM execution need to be made carefully, as they could have unintended effects on smart contracts. This is just a reality that must be dealt with; it’s very difficult to design systems with zero abstraction leakage, and in any event the 1.x researchers don’t have the luxury of redesigning anything from the ground up — They need to work within today’s Ethereum protocol, which is just a wee bit leaky in the ol’ virtual state machine abstraction.

Returning to the main topic: The introduction of witnesses will require changes to gas scheduling. Witnesses need to be generated and propagated across the network, and that activity needs to be accounted for in EVM operations. The topics tied to this milestone have to do with what those costs and incentives are, how they are estimated, and how they will be implemented with minimal impact on higher layers.

Witness Indexing / Gas accounting

There is likely much more nuance to this section than can reasonably fit in a few sentences; I’m sure we’ll dive a bit deeper at a later date. For now, understand that every transaction will be responsible for a small part of the full block’s witness. Generating a block’s witness involves some computation that will be performed by the block’s miner, and therefore will need to have an associated gas cost, paid for by the transaction’s sender.

Because multiple transactions might touch the same part of the state, it’s not clear the best way to estimate the gas costs for witness production at the point of transaction broadcast. If transaction owners pay the full cost of witness production, we can imagine situations in which the same part of a block witness might be paid for many times over by ‘overlapping’ transactions. This isn’t obviously a bad thing, mind you, but it introduces real changes to gas incentives that need to be better understood.

Whatever the associated gas costs are, the witnesses themselves will need to become a part of the Ethereum protocol, and likely will need to incorporated as a standard part of each block, perhaps with something as straightforward as a witnessHash included in each block header.

UNGAS / Versionless Ethereum

This is a class of upgrades mostly orthogonal to Stateless Ethereum that have to do with gas costs in the EVM, and patching up those abstraction leaks I mentioned. UNGAS is short for “unobservable gas”, and it is a modification that would explicitly disallow contracts from using the GAS opcode, to prohibit any assumptions about gas cost from being made by smart contract developers. UNGAS is part of a number of suggestions from the Ethereum core paper to patch up some of those leaks, making all future changes to gas scheduling easier to implement, including and especially changes related to witnesses and Stateless Ethereum.

State Availability

Stateless Ethereum is not going to do away with state entirely. Rather, it will make state an optional thing, allowing clients some degree of freedom with regard to how much state they keep track of and compute themselves. The full state therefore must be made available somewhere, so that nodes looking to download part of all of the state may do so.

In some sense, existing paradigms like fast sync already provide for this functionality. But the introduction of zero-state and partial-state nodes complicates things for new nodes getting up to speed. Right now, a new node can expect to download the state from any healthy peers it connects to, because all nodes keep a copy of the current state. But that assumption goes out the window if some of peers are potentially zero-state or partial-state nodes.

The pre-requisites for this milestone have to do with the ways nodes signal to each other what pieces of state they have, and the methods of delivering those pieces reliably over a constantly changing peer-to-peer network.

Network Propagation Rules

This diagram below represents a hypothetical network topology that could exist in stateless Ethereum. In such a network, nodes will need to be able to position themselves according to what parts of state they want to keep, if any.

Improvements such as EIP #2465 fall into the general category of network propagation rules: New message types in the network protocol that provide more information about what information nodes have, and define how that information is passed to other nodes in potentially awkward or limited network topologies.

Data Delivery Model / DHT routing

If improvements like the message types described above are accepted and implemented, nodes will be able to easily tell what parts of state are held by connected peers. What if none of the connected peers have a needed piece of state?

Data delivery is a bit of an open-ended problem with many potential solutions. We could imagine turning to more ‘mainstream’ solutions, making some or all of the state available over HTTP request from a cloud server. A more ambitious solution would be to adopt features from related peer-to-peer data delivery schemes, allowing requests for pieces of state to be proxied through connected peers, finding their correct destinations through a Distributed Hash Table. The two extremes aren’t inherently incompatible; Porque no los dos?

State tiling

One approach to improving state distribution is to break the full state into more manageable pieces (tiles), stored in a networked cache that can provide state to nodes in the network, thus lightening the burden on the full nodes providing state. The idea is that even with relatively large tile sizes, it is likely that some of the tiles would remain un-changed from block to block.

The geth team has performed some experiments which suggest state tiling is feasible for improving the availability of state snapshots.

Chain pruning

Much has been written on chain pruning already, so a more detailed explanation is not necessary. It is worth explicitly stating, however, that full nodes can safely prune historical data such as transaction receipts, logs, and historical blocks only if historical state snapeshots can be made readily available to new full nodes, through something like state tiling and/or a DHT routing scheme.

Network Protocol Spec

At last, the complete picture of Stateless Ethereum is coming into focus. The three milestones of Witness Format, EVM Semantics, and State Availability together enable a complete description of a Network Protocol Specification: The well-defined upgrades that should be coded into every client implementation, and deployed during the next hard fork to bring the network into a stateless paradigm.

We’ve covered a lot of ground in this article, but there are still a few odd and ends from the diagram that should be explained:

Formal Stateless Specification

At the end of the day, it is not a requirement that the complete stateless protocol be formally defined. It is plausible that a reference implementation be coded out and used as the basis for all clients to re-implement. But there are undeniable benefits to creating a “formalized” specification for witnesses and stateless clients. This would be essentially an extension or appendix that would fit in the Ethereum Yellow Paper, detailing in precise language the expected behavior of an Ethereum stateless client implementation.

Beam Sync, Red Queen’s sync, and other state sync optimizations

Sync strategies are not primary to the network protocol, but instead are implementation details that affect how performant nodes are in enacting the protocol. Beam sync and Red Queen’s sync are related strategies for building up a local copy of state from witnesses. Some effort should be invested in improving these strategies and adapting them for the final ‘version’ of the network protocol, when that is decided and implemented.

For now, they are being left as ‘bonus’ items in the tech tree, because they can be developed in isolation of other issues, and because details of their implementation depend on more fundamental choices like witness format. Its worth noting that these extra-protocol topics are, by virtue of their independence from ‘core’ changes, a good vehicle for implementing and testing the more fundamental improvements on the left side of the tree.

Wrapping up

Well, that was quite a long journey! I hope that the topics and milestones, and general idea of the “tech tree” is helpful in organizing the scope of “Stateless Ethereum” research.

The structure of this tree is something I hope to keep updated as things progress. As I said before, it’s not an ‘official’ or ‘final’ scope of work, it’s just the most accurate sketch we have at the moment. Please do reach out if you have suggestions on how to improve or amend it.

As always, if you have questions, requests for new topics, or want to participate in stateless Ethereum research, come introduce yourself on ethresear.ch, and/or reach out to @gichiba or @JHancock on twitter.

The Updated Stateless Ethereum Tech Tree

Apologies for the delay in releasing this post; there have been some unavoidable distractions in my life recently, as I’m sure there have been in yours. I hope that you are making the best of your circumstances, whatever they may be, and implore you to turn your empathy up to eleven for the next few months, and to help your community’s at-risk people in whatever capacity you can :pray:.

With that said, let’s talk about Stateless Ethereum, and the changes to the Tech Tree!

Graphically, the tree has been completely re-worked, but if you were to compare it to the original, you’d notice that a lot of the content is the same. For the sake of completeness and avoidance of confusion, we’ll still go through everything in this post, though, so feel free to close that tab you just opened in the background. Without further ado, I present to you the updated Stateless Tech Tree:

Each major milestone in pink represents a roughly defined category that must be “solved” before more advanced ones. These are intentionally a little vague, and don’t represent anything like specific EIPs or unified features, although some of them could eventually be defined as such.

Smaller elements of the tree in purple are more specific dependencies that will lead to the major milestones being “unlocked”. The purple ones are required in the sense that they need to be fully understood before the milestone can be considered finished, but they don’t necessarily need to be implemented or accepted. For example, it is possible that after more research, we find that code merkleization doesn’t reduce witness sizes sufficiently to justify the time and effort it would take to implement it; we would then consider it ‘finished’, because it no longer needs to be investigated.

As you might have guessed already, items in green are the “side quests” that would theoretically be useful in Stateless Ethereum, but which might not be the best use of the researcher’s limited time and effort. There are likely more of these to be discovered along the way; I’ll add them as needed.

Additionally, we have elements in yellow that fall into the category of tools. These are yet-uncreated software tools that will help to validate assumptions, test implementations, and more generally make the work go faster. Ideally these tools will be of high enough quality and properly maintained– enough to be valuable to the larger developer ecosystem even outside of the Stateless Ethereum context.

Alternative Sync Protocol

One important takeaway from the summit in Paris was that sync is the first major milestone in Stateless Ethereum. Specifically, we must find a way for new nodes to fetch the current state trie without relying on the network primitive GetNodeData. Until we have a reliable alternative to this network primitive (beam sync and fast sync are both based on it), efforts to build Stateless Ethereum will be impeded, and potentially even counterproductive. It’s worth digging in here a bit to explain why this is such a problem. If you’re not familiar with the fundamentals of the Ethereum state, I recommend checking out my previous post in this series on the subject.

Let’s do some jargon-busting first. There isn’t really a special technical definition for the term “network primitive” in this context, it’s just a hip way of saying “the basic grammar of Ethereum network communication”. One client asks “hey, what’s the data for the node with hash 0xfoo? And a peer can respond “oh, it’s 0xbeef. For most cases, the response will contain additional hashes of child nodes in the trie, which can then be asked for in the same manner. This game of marco-polo continues until the requester is satisfied, usually after having asked for each of the ~400 million nodes in the current state trie individually.

Syncing this way can still be fast, because a client can of course multi-task, and ask many other full nodes for different pieces of the state at the same time. But there is a more fundamental problem here in the way the primitive works: the ‘leechers’ requesting state get to do it on their own terms, and they can only get what they need from the ‘seeders’, i.e. full nodes with the complete state. This asymmetric relationship is just the way things work right now, and it works well enough because of two related facts about the network: First, there are a sufficient number of full nodes actively serving state by request. Second, anyone requesting state will eventually turn into a full node, so the demand for state is self-limiting.

Now we can see why this is a problem for Stateless Ethereum: in a stateless paradigm, nodes that aren’t keeping the state data they request will need to just keep requesting data indefinitely. If running a stateless node is easier than running a full node (it is), we’d expect the number of stateless nodes to grow faster than the number of full nodes, until eventually the state is unable to propagate fast enough throughout the network. Uh oh.

We don’t have time to go into further detail here, so I’ll refer you to Piper’s write-up on the problem, and then we can move on to the emerging solutions, which are all different approaches to improving the state sync protocol, to either make the problem less pronounced, or solve it entirely. Here are the 3 most promising alternative sync protocols:

Ethereum Snapshot Protocol (SNAP). We’ve talked about this previously, but I referred to it as “state tiling”. Recently, it was more verbosely described by Peter in the devp2p repo. Snap breaks the state into a handful of large chunks and proofs (on the order of 10,000 trie nodes) that can be re-assembled into the full state. A syncing node would request a sub-section of the state from multiple nodes, and in a short amount of time have an almost valid picture of the state stitched together from ~100 different similar state roots. To finish, the client ‘patches up’ the chunk by switching back to getNodeData until it has a valid state.

Fire Queen’s Sync. Not much has changed since this was written about in the original tech tree article, except for the name, which is a combination of “firehose” and “Red Queen’s” sync. These are very similar proposals to replace getNodeData with an alternative set of primitives for various aspects of state.

Merry-go-round. This is a new idea for sync explained at a high level in ethresear.ch and more concretely described in notes. In merry-go-round sync, the whole state is passed around in a predetermined order, so that all participants gossip the same pieces of the state trie at the same time. To sync the whole state, one must complete a full “revolution” on the merry-go-round, covering all parts of the state. This design has some useful properties. First, it allows new nodes joining to contribute immediately to state propagation, rather than only becoming useful to the network after a completed sync. Second, it inverts the current model of ‘leecher-driven sync’ whereby those with no data may request pieces of state from full nodes at will. Rather, new syncing nodes in merry-go-round sync know what parts of state are being offered at a given time, and adjust accordingly.

The last sync method worth mentioning is beam sync, which is now supported by not one, but two alternative clients. Beam sync still relies on getNodeData, but it offers an ideal entry point for experimentation and data collection for these alternative sync methods. It’s important to note that there are many unknowns about sync still, and having these separate, independently developed approaches to solving sync is important. The next few months could be thought of as a sync hackathon of sorts, where ideas are prototyped and tested out. Ideally, the best aspects of each of these alternative sync protocols can be molded into one new standard for Stateless Ethereum.

Witness Spec Prototype

There is a draft specification in the Stateless Ethereum specs repo that describes at a high level the structure of a block witness, and the semantics of building and modifying one from the state trie. The purpose of this document is to define witnesses without ambiguity, so that implementers, regardless of client or programming language, may write their own implementation and have reasonable certainty that it is the same thing as another, different implementation.

As mentioned in the latest call digest, there doesn’t seem to be a downside to writing out a reference implementation for block witnesses and getting that into existing clients for testing. A witness prototype feature on a client would be something like an optional flag to enable, and having a handful of testers on the network producing and relaying witnesses could provide valuable insight for researchers to incorporate into subsequent improvements.

Two things need to be “solved” before witnesses are resilient enough to be considered ready for widespread use.

Witness Indexing. This one is relatively straightforward: we need a reliable way of determining which witness corresponds to which block and associated state. This could be as simple as putting a witnessHash field into the block header, or something else that serves the same purpose but in a different way.

Stateless Tx Validation. This is an interesting early problem thoroughly summarized on the ethresearch forums. In summary, clients need to quickly check if incoming transactions (waiting to be mined into a future block) are at least eligible to be included in a future block. This prevents attackers from spamming the network with bogus transactions. The current check, however, requires accessing data which is a part of the state, i.e. the sender’s nonce and account balance. If a client is stateless, it won’t be able to perform this check.

There is certainly more work than these two specific problems that needs to be done before we have a working prototype of witnesses, but these two things are what absolutely need to be ‘solved’ as part of bringing a viable prototype to a beam-syncing node near you.

EVM

As in the original version of the tech tree, some changes will need to happen inside the EVM abstraction. Specifically, witnesses need to be generated and propagated across the network, and that activity needs to be accounted for in EVM operations. The topics tied to this milestone have to do with what those costs and incentives are, how they are estimated, and how they will be implemented with minimal impact on higher layers.

Witness gas accounting. This remains unchanged from previous articles. Every transaction will be responsible for a small part of the full block’s witness. Generating a block’s witness involves some computation that will be performed by the block’s miner, and therefore will need to have an associated gas cost, paid for by the transaction’s sender.

Code Merkleization. One major component of a witness is accompanying code. Without this feature, a transaction that contained a contract call would require the full bytecode of that contract in order to verify its codeHash. That could be a lot of data, depending on the contract. Code ‘merkleization’ is a method of splitting up contract bytecode so that only the portion of the code called is required to generate and verify a witness for the transaction. This is one technique of dramatically reducing the average size of witnesses, but it has not been fully investigated yet.

The UNGAS / Versionless Ethereum changes have been removed from the ‘critical path’ of Stateless Ethereum. These are still potentially beneficial features for Ethereum, but it became clear during the summit that their merits and particularities can and should be discussed independently of the Stateless goals.

The Transition to Binary Trie

Switching Ethereum’s state to a Binary Trie structure is key to getting witness sizes small enough to be gossiped around the network without running into bandwidth/latency issues. Theoretically the reduction should be over 3-fold, but in practice that number is a little less dramatic (because of the size of contract code in witnesses, which is why code merkleization is potentially important).

The transition to a completely different data representation is a rather significant change, and enacting that transition through hard-fork will be a delicate process. Two strategies outlined in the previous article remain unchanged:

Progressive. The current hexary state trie woud be transformed piece-by-piece over a long period of time. Any transaction or EVM execution touching parts of state would by this strategy automatically encode changes to state into the new binary form. This implies the adoption of a ‘hybrid’ trie structure that will leave dormant parts of state in their current hexary representation. The process would effectively never complete, and would be complex for client developers to implement, but would for the most part insulate users and higher-layer developers from the changes happening under the hood in layer 0.

Clean-cut. This strategy would compute a fresh binary trie representation of the state at a predetermined time, then carry on in binary form once the new state has been computed. Although more straightforward from an implementation perspective, a clean-cut requires coordination from all node operators, and would almost certainly entail some (limited) disruption to the network, affecting developer and user experience during the transition.

There is, however, a new proposal for the transition, which offers a middle ground between the progressive and clean-cut strategies. It is outlined in full on the ethresearch forums.

Overlay. New values from transactions after a certain time are stored directly in a binary tree sitting “on top” of the hexary, while the “historical” hexary tree is converted in the background. When the base layer has been fully converted, the two can be merged.

One additional consideration for the transition to a binary trie is the database layouts of clients. Currently, all clients use the ‘naive’ approach to the state trie, storing each node in the trie as a [key, value] pair where the hash of the node is the key. It is possible that the transition strategy could be an opportunity for clients to switch to an alternative database structure, following the example of turbo-geth.

True Stateless Ethereum

The final pieces of the tree come together after the witness prototype has been tested and improved, the necessary changes to the EVM have been enacted, and the state trie has become binary. These are the more distant quests and side quests which we know must be completed eventually, but it’s likely best not to think too deeply about until more pressing matters have been attended to.

Compulsory Witnesses. Witnesses need to be generated by miners, and right now it’s not clear if spending that extra few milliseconds to generate a witness will be something miners will seek to avoid or not. Part of this can be offset by tweaking the fees that miners get to keep from the partial witnesses included with transactions, but a sure-fire way is to just make witnesses part of the core Ethereum protocol. This is a change that can only happen after we’re sure everything is working the way it’s supposed to be, so it’s one of the final changes in the tree.

Witness Chunking. Another more distant feature to be considered is the ability for a stateless network to pass around smaller chunks of witnesses, rather than entire blocks. This would be especially valuable for partial-state nodes, which might choose to ‘watch over’ the parts of state they’re interested in, and then rely on complementary witness chunks for other transactions.

Historical Accumulators. Originally conceived as some sort of magic moon math zero-knowledge scheme, a historical accumulator would make verifying a historical witness much easier. This would allow a stateless node to perform checks and queries on, for example, the historical balances of an account it was interested, without actually needing to fetch a specific piece of archived state.

DHT Chain Data. Although the idea of an Ethereum data delivery network for state has been more or less abandoned, it would still be quite useful and far easier to implement one for historical chain data such as transaction receipts. This might be another approach to enabling stateless clients to have on-demand access to historical data that might ordinarily be gotten from an archive node.

Stay Safe, and Stay Tuned

Thanks for reading, and thank you for the many warm positive comments I’ve gotten recently about these updates. I have something more… magical planned for subsequent posts about the Stateless Ethereum research, which I’ll be posting intermittently on the Fellowship of the Ethereum Magician’s forum, and on this blog when appropriate. Until next time, keep your social distance, and wash your hands often!

As always, if you have feedback, questions, or requests for topics, please @gichiba or @JHancock on twitter.

This week we’re revising the Tech Tree to reflect some new major milestones to Ethereum 1.x R&D that are not quite a complete realization of Stateless Ethereum, but much more reasonably attainable in the mid-term. The most significant addition to the tech tree is Alexey’s reGenesis proposal. This is far from a well-specified upgrade, but the general sentiment from R&D is that reGenesis offers a less dramatic yet much more attainable step towards the ultimate goal of the “fully stateless” vision. In many ways complimentary to reGenesis is a static state network that would help distribute state snapshots and historical chain data in a bittorrent-style DHT-based network. At the same time, more near-term improvements like code merkleization and a binary trie representation of state are getting closer and closer to being EIP-ready. Below, I’ll explain and clarify the changes that have been made, and link to the relevant discussions if you’d like to dive deeper on any particular feature.

Binary Trie

While Ethereum currently uses a hexary Merkle-Patricia Trie to encode state, there are substantial efficiency gains to be had by switching to a binary format, particularly in the anticipated size of witnesses. A complete re-encoding of Ethereum’s state requires the new format to be specified, and a clear strategy for transition. Finally, it needs to be decided whether or not smart contract code will also be merkleized, and if that should be incorporated into the binary trie transition or as a standalone change.

Binary Trie Format

The general idea of a binary trie is a bit simpler (pun intended :)) than Ethereum’s current hexary trie structure. Instead of having one of 16 possible paths to walk from the root of the trie down towards child nodes, a binary trie has 2. With a complete re-specification of the state trie comes additional opportunity to improve upon well-established inefficiencies that have made themselves known now that Ethereum has been in operation for more than 5 years. In particular, it might be an opportunity to make the state much more amenable to the real-world performance challenges of database encoding (outlined in a previous article on state growth).

The discussion on a formal binary trie specification and merkleization rules can be found on ethresearch.

Binary Trie Transition

It’s not just the destination (binary trie format) that’s important, but the journey itself! In an ideal transition there would be no interruption to transaction processing across the nework, which means that clients will need to build the new binary trie at the same time as handling new blocks rolling in every 15 seconds. The transition strategy that continues to look the most promising is dubbed the overlay method, which is based partially on geth’s new snapshotting sync protocol. In short summary, new state changes will be added to the existing (hexary) trie in a binary format, making a sort of binary/hexary hybrid during the transition. The un-touched state is converted as a background process. Once the conversion is complete, the two layers get flattened into a single binary trie.

It’s important to note that the binary transition is one context in which client diversity is very important. Every client will need to either implement their own version of the transition or rely on other clients to convert and wait for the new trie on the other side of conversion. This will definitely be a ‘measure twice, cut once’ sort of situation, with all client teams working together to implement test, and coordinate the switchover. It is possible that in the interest of safety and security, the network will need to briefly suspend service (e.g. mine a few empty blocks) over the course of the transition, but agreeing on any specific plan is too far out to predict at this time.

Code Merkleization

Smart Contract code makes up a significant portion of the Ethereum state trie (around 1 GB of the ~50GB of state). A witness for any smart contract interaction will necessarily have to provide the code it’s interacting with to calculate a codeHash, and that could be quite a lot of extra data. Code Merkleization is a means of splitting up contract code into smaller chunks, and replacing codeHash with the root of another merkle trie. Doing so would allow a witness to replace potentially large portions of smart contract code with reference hashes, shaving off crucial kilobytes of witness data.

There are a few approaches to code merkleization schemes, which range from chunking universally (for example, into 64 byte pieces) on the simple side to more complex methods like static analysis based on Solidity’s functionId or JUMPDEST instructions. The optimal strategy for code merkleization will ultimately rely on what seems to work best with real data collected from mainnet.

reGenesis

The best place to get a handle on the reGenesis proposal is this explanation by @mandrigin or the full proposal by @realLedgerwatch, but the TL;DR is that reGenesis is essentially “spring cleaning for the blockchain”. The full state would be conceptually divided into an ‘active’ and an ‘inactive’ state. Periodically, the entire ‘active’ state would be de-activated and new transactions would start to build an active state again from almost nothing (hence the name “reGenesis”). If a transaction needed an old part of state, it would provide a witness very similar to what would be required for Stateless Ethereum: a Merkle proof proving that the state change is consistent with some piece of inactive state. If a transaction touches an ‘inactive’ portion of the state, it automatically elevates it to ‘active’ (whether or not the transaction is successful) where it remains until the next reGenesis event. This has the nice property of creating some of the economic bounds on state usage that state rent had without actually deleting any state, and allowing transaction sender unable to generate a witness to just blindly keep trying a transaction until everything it touches is ‘active’ again.

The fun part about reGenesis is that it gets Ethereum much closer to the ultimate goal of Stateless, but sidesteps some of the largest challenges with Statelessness, i.e. how witness gas accounting works during EVM execution. It also gets some version of transaction witnesses moving around the network, allowing for leaner, lighter clients and more opportunity for dapp developers to get used to the stateless paradigm and witness production. “True” Statelessness after reGenesis would then be a matter of degree: Stateless Ethereum is really just reGenesis after each and every block.

State Network

A better network protocol has been a ‘side-quest’ on the tech tree from the beginning, but with the addition of reGenesis to the scope of Stateless Ethereum, finding alternative network primitives for sharing Ethereum chain data (including state) now seems to fit a lot better into the main quest. Ethereum’s current network protocol is a monolith, when in fact there are several distinct types of data that could be shared using different ‘sub-networks’ optimized for different things.

Previously, this has been talked about as the “Three Networks” on earlier Stateless calls, with a DHT-based network able to more effectively serve some of the data that doesn’t change from moment to moment. With the introduction of reGenesis, the ‘inactive’ state would fit into this category of unchanging data, and could be theoretically served by a bittorrent-style swarming network instead of piece-by-piece from a fully synced client as is currently done.

A network passing around the un-changing state since the last reGenesis event would be a static state network, and could be built by extending the new Discovery v5.1 spec in the devp2p library (Ethereum’s networking protocol). Previous proposals such as Merry-go-Round sync and the (more mature) SNAP protocol for syncing active state would still be valuable steps toward a fully distributed dynamic state network for clients trying to rapidly sync the full state.

Wrapping up

A more condensed and technical version of every leaf in the Stateless Tech Tree (not just the updated ones) is available on the Stateless Ethereum specs repo, and active discussions on all of the topics covered here are in the Eth1x/2 R&D Discord – please ask for an invite on ethresear.ch if you’d like to join. As always, tweet @gichiba or @JHancock for feedback, questions, and suggestions for new topics.

To my knowledge, when a new node joins a network, it downloads over 500 GB blockchain data used to verify the integrity of the blockchain.

Blockchains are difficult to rewrite but easy to check, so start by checking the headers from genesis blocks to chip blocks, regardless of whether the downloaded blockchain is corrupted or not.

Then repeat the body of the block from Genesis block to Chip block that takes days or weeks to build UTXO (the current balance of each address).

For all blocks in iteration:

• If it is the output (destination) of a transaction, add the address to the UTXO set.
• If it is the input (source) of a transaction, remove the address from the UTXO set.

So can we say that the blockchain itself is stateless? This is because it only stores transaction history, as additional operations allow only new blocks.

From that stateless data, all nodes can construct a UTXO set, where all nodes hold their state in internal memory (the same way as the way Mempool was saved). correct?

If correct, it may be that all nodes have different utxo.

Please clarify my understanding.