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.

Since a lot of us have a bit more time on our hands, I thought now might be a good opportunity to proceed with something perhaps a little bit boring and tedious, but nevertheless quite fundamental to the Stateless Ethereum effort: understanding the formal Witness Specification.

Like the captain of the Battleship in StarCraft, we’re going to take it slow. The witness spec is not a particularly complicated concept, but it is very deep. That depth is a little daunting, but is well worth exploring, because it’ll provide insights that, perhaps to your nerdy delight, extend well beyond the world of blockchains, or even software!

By the end of this primer, you should have at least minimum-viable-confidence in your ability to understand what the formal Stateless Ethereum Witness Specification is all about. I’ll try to make it a little more fun, too.

Recap: What you need to know about State

Stateless Ethereum is, of course, a bit of a misnomer, because the state is really what this whole effort is about. Specifically, finding a way to make keeping a copy of the whole Ethereum state an optional thing. If you haven’t been following this series, it might be worth having a look at my earlier primer on the state of stateless Ethereum. I’ll give a short TL;DR here though. Feel free to skim if you feel like you’ve already got a good handle on this topic.

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.

The Ethereum State is represented in silico as a Merkle-Patricia Trie: a hashed data structure that organizes each individual piece of information (e.g. an account balance) into one massive connected unit that can be verified for uniqueness. The complete state trie is too massive to visualize, but here’s a ‘toy version’ that will be helpful when we get to witnesses:

Like magical cryptographic caterpillars, the accounts and code of smart contracts live in the leaves and branches of this tree, which through successive hashing eventually leads to a single root hash. If you want to know that two copies of a state trie are the same, you can simply compare the root hashes. Maintaining relatively secure and indisputable consensus over one ‘canonical’ state is the essence of what a blockchain is designed to do.

In order to submit a transaction to be included in the next block, or to validate that a particular change is consistent with the last included block, Ethereum nodes must keep a complete copy of the state, and re-compute the root hash (over and over again). Stateless Ethereum is a set of changes that will remove this requirement, by adding what’s known as a ‘witness’.

A Witness Sketch

Before we dive into the witness specification, it’ll be helpful to have an intuitive sense of what a witness is. Again, there is a more thorough explanation in the post on the Ethereum state linked above.

A witness is a bit like a cheat sheet for an oblivious (stateless) student (client). It’s just the minimum amount of information need to pass the exam (submit a valid change of state for inclusion in the next block). Instead of reading the whole textbook (keeping a copy of the current state), the oblivious student (stateless client) asks a friend (full node) for a crib sheet to submit their answers.

In very abstract terms, a witness provides all of the needed 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 new transaction in its state, and to compute a new root hash locally – without requiring them to download an entire copy of the state trie.

Let’s move away from the cartoonish idea and towards a more concrete representation. Here is a “real” visualization of a witness:

I recommend opening this image in a new tab so that you can zoom in and really appreciate it. This witness was selected because it’s relatively small and easy to pick out features. Each little square in this image represents a single ‘nibble’, or half of a byte, and you can verify that yourself by counting the number of squares that you have to ‘pass through’, starting at the root and ending at an Ether balance (you should count 64). While we’re looking at this image, notice the huge chunk of code within one of the transactions that must be included for a contract call — code makes up a relatively large part of the witness, and could be reduced by code merkleization (which we’ll explore another day).

Some Formalities

One of the fundamental distinguishing features of Ethereum as a protocol is its independence from a particular implementation. This is why, rather than just one official client as we see in Bitcoin, Ethereum has several completely different versions of client. These clients, written in various programming languages, must adhere to The Ethereum Yellow Paper, which explains in much more formal terms how any client should behave in order to participate in the Ethereum protocol. That way, a developer writing a client for Ethereum doesn’t have to deal with any ambiguity in the system.

The Witness Specification has this exact goal: to provide an unambiguous description of what a witness is, which will make implementing it straightforward in any language, for all clients. If and when Stateless Ethereum becomes ‘a thing’, the witness specification can be inserted into the Yellow Paper as an appendix.

When we say unambiguous in this context, it means something stronger than what you might mean in ordinary speech. It’s not that the formal specification is just a really, really, really, detailed description of what a witness is and how it behaves. It means that, ideally, there is literally one and only one way describe a particular witness. That is to say, if you adhere to the formal specification, it’d be impossible for you to write an implementation for Stateless Ethereum that generates witnesses different than any other implementation also following the rules. This is key, because the witness is going to (hopefully) become a new cornerstone of the Ethereum protocol; It needs to be correct by construction.

A Matter of Semantics (and Syntax)

Although ‘blockchain development’ usually implies something new and exciting, it must be said that a lot of it is grounded in much older and wiser traditions of computer programming, cryptography, and formal logic. This really comes out in the Witness Specification! In order to understand how it works, we need to feel comfortable with some of the technical terms, and to do that we’re going to have to take a little detour into linguistics and formal language theory.

Read aloud the following two sentences, and pay particular attention to your intonation and cadence:

• furiously sleep ideas green colorless
• colorless green ideas sleep furiously

I bet the first sentence came out a bit robotic, with a flat emphasis and pause after each word. By contrast, the second sentence probably felt natural, if a bit silly. Even though it didn’t really mean anything, the second sentence made sense in a way that the first one didn’t. This is a little intuition pump to draw attention to the distinction between Syntax and Semantics. If you’re an English speaker you have an understanding of what the words represent (their semantic content), but that was largely irrelevant here; what you noticed was a difference between valid and invalid grammar (their syntax).

This example sentence is from a 1956 paper by one Noam Chomsky, which is a name you might recognize. Although he is now known as an influential political and social thinker, Chomsky’s first contributions as an academic were in the field of logic and linguistics, and in this paper, he created one of the most useful classification systems for formal languages.

Chomsky was concerned with the mathematical description of grammar, how one can categorize languages based on their grammar rules, and what properties those categories have. One such property that is relevant to us is syntactic ambiguity.

Ambiguous Buffalo

Consider the grammatically correct sentence “Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.” — this is a classic example that illustrates just how ambiguous English syntax rules can be. If you understand that, depending on the context, the word ‘buffalo’ can be used as a verb (to intimidate), an adjective (being from Buffalo, NY), or a noun (a bison), you can parse the sentence based on where each word belongs.

We could also use entirely different words, and multiple sentences: “You know those NY bison that other NY bison intimidate? Well, they intimidate, too. They intimidate NY bison, to be exact.”

But what if we want to remove the ambiguity, but still restrict our words to use only ‘buffalo’, and keep it all as a single sentence? It’s possible, but we need to modify the rules of English a bit. Our new “language” is going to be a little more exact. One way to do that would be to mark each word to indicate its part of speech, like so:

Buffalo{pn} buffalo{n} Buffalo{pn} buffalo{n} buffalo{v} buffalo{v} Buffalo{pn} buffalo{n}

Perhaps that’s still not super clear for a reader. To make it even more exact, let’s try using a bit of substitution to help us herd some of these “buffalo” into groups. Any bison from Buffalo, NY is really just one special version of what we would call a “noun phrase”, or . We can substitute into the sentence whenever we encounter the string Buffalo{pn} buffalo{n}. Since we’re getting a bit more formal, we might decide to use a shorthand notation for this and other future substitution rules, by writing:

::= Buffalo{pn} buffalo{n}

where ::= means “What’s on the left side can be replaced by what’s on the right side”. Importantly, we don’t want this relationship to go the other way; imagine how mad the Boulder buffalo would get!

Applying our substitution rule to the full sentence, it would change to:

buffalo{v} buffalo{v}

Now, this is still a bit confusing, because in this sentence there is a sneaky relative clause, which can be seen a lot more clearly by inserting the word ‘that’ into the first part our sentence, i.e. *that* buffalo{v}….

So let’s make a substitution rule that groups the relative clause into , and say:

::= buffalo{v}

Additionally, since a relative clause really just makes a clarification about a noun phrase, the two taken together are equivalent to just another noun phrase:

::=

With these rules defined and applied, we can write the sentence as:

buffalo{v}

That seems pretty good, and really gets at the core relationship this silly sentence expresses: One particular group of bison intimidating another group of bison.

We’ve taken it this far, so why not go all the way? Whenever ‘buffalo’ as a verb precedes a noun, we could call that a verb phrase, or , and define a rule:

::= buffalo{v}

And with that, we have our single complete valid sentence, which we could call S:

S ::=

What we’ve done here might be better represented visually:

That structure looks curiously familiar, doesn’t it?

The buffalo example is a bit silly and not very rigorous, but it’s close enough to demonstrate what’s going on with the weird mathematical language of the Witness Specification, which I have very sneakily introduced in my rant about buffalo. It’s called Backus-Naur form notation, and it’s often used in formal specifications like this, in a variety of real-world scenarios.

The ‘substitution rules’ we defined for our restricted English language helped to make sure that, given a herd of “buffalo”, we could construct a ‘valid’ sentence without needing to know anything about what the word buffalo means in the real world. In the classification first elucidated by Chomsky, a language that has exact enough rules of grammar that allow you to do this is called a context-free language.

More importantly, the rules ensure that for every possible sentence comprised of the word(s) buffalo{np|n|v}, there is one and only one way to construct the data structure illustrated in the tree diagram above. Un-ambiguity FTW!

Go Forth and Read the Spec

Witnesses are at their core just a single large object, encoded into a byte array. From the (anthropomorphic) perspective of a stateless client, that array of bytes might look a bit like a long sentence comprised of very similar looking words. So long as all clients follow the same set of rules, the array of bytes should convert into one and only one hashed data structure, regardless of how the implementation chooses to represent it in memory or on disk.

The production rules, written out in section 3.2, are a bit more complex and far less intuitive than the ones we used for our toy example, but the spirit is very much the same: To be unambiguous guidelines for a stateless client (or a developer writing a client) to follow and be certain they’re getting it right.

I’ve glossed over quite a lot in this exposition, and the rabbit hole of formal languages goes far deeper, to be sure. My aim here was to just provide enough of an introduction and foundation to overcome that first hurdle of understanding. Now that you have cleared that hurdle, it’s time pop open wikipedia and tackle the rest yourself!

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

I’ve been thinking recently about post-apocalyptic wastelands. Specifically, about this scene from Mad Max: Fury Road, when the main characters have just escaped the first wave of pursuit, and are staying ahead of their would-be captors. They need to keep moving, but still need to do maintenance on the centerpiece of the movie: a gigantic “war rig” truck driving them to safety. So Charlize Theron climbs out under the cab to make some repairs en-route:

The idea of conducting repairs on a big complicated truck while it’s still moving is just so appropriate for the film’s high-octane drama. It occurred to me while I was watching that this situation is an apt metaphor for the EIP process and the work of the core devs.

Changes to the Ethereum protocol happen LIVE, and a lot of careful, complex engineering goes into crafting upgrades so that everything, and everyone (if possible) keeps rolling along. There are still bumps on the road out in the blockchain badlands, but by and large Ethereum remains well ahead of any other marauding vehicles (technical debt) — so long as the rig keeps pace and doesn’t stop moving toward the horizon. New proposals have the potential to be a little disruptive in the short term to the status quo, but are usually valuable improvements overall to the protocol.

The upgrade I want to discuss today fits into the category of “Ethereum 1.x”, but it’s not part of the Stateless Ethereum effort: A new gas fee market / block size mechanism. The proposal has become a really interesting case study in community and developer feedback for Ethereum improvement. By looking at how this EIP has changed over time with more developer discussion, I think we can learn a lot about constructive discussion in Ethereum development, and hopefully have some clear insights (or at the very least, vague aphorisms) to help guide the discussion on significant changes further out from the Stateless Ethereum initiative.

Ordinarily in this series I try to be very methodical and ‘into the weeds’, but in this instance I want to put more emphasis on the content and character of the discussion surrounding the proposals, rather than the technical minutia contained within. But we have to have some idea of what we’re talking about here, so let’s look very briefly at what EIP-1559 and ‘Escalator’ propose before going “meta” and considering how the discussion has progressed and where it’s at today.

EIP 1559

The motivations for the original EIP 1559 are a good place to start, and they’re fairly straightforward:

The current “first price auction” fee model in Ethereum is inefficient and needlessly costly to users. This EIP proposes a way to replace this with a mechanism that adjusts a base network fee based on network demand, creating better fee price efficiency and reducing the complexity of client software needed to avoid paying unnecessarily high fees.

In the current system, newly submitted transactions must wait to be included in the next block by a miner, but they can incentivize miners to include their transaction by increasing the gasPrice parameter higher than the network average. Miners, if they are being rational, will always be looking to fill new blocks with transactions that maximize their payout, and thus the transactions included first in the next block can be always expected to be the ones with the highest gas price.

The trouble with this first price auction model is that things can get out of hand quickly in times of high demand. When blocks are close to full, the cost of getting a transaction included in the next block can spike dramatically as users try to out-bid each other for inclusion. Even though currently miners have some ability to increase the number of transactions included in a single block, that limit can’t change very quickly and realistically miners are happy to capitalize on small full blocks rather than push the block gas limit up higher (larger blocks are, because of Uncle rates, a more risky proposition for a miner). Especially if your wallet is using pricing algorithms to target inclusion within a specified time frame (read: provide a good ordinary user experience), you might end up paying pretty ridiculous fees to get your transaction into a (nearly) full next block.

EIP 1559 introduces the concept of a ‘base fee’ in gas that is set to dynamically adjust so that the overall gas usage in a block moves toward the current limit of 10 million gas. Rather than going into the pockets of miners, the base fee is burned. To provide incentive for inclusion, users specify a ‘tip’ parameter, together with the maximum amount they are willing to pay for the transaction to be included in a block, and miners keep the tip.

Because the base fee does not fluctuate wildly at the whim of instantaneous network demand, users are somewhat insulated from the inefficiencies of a first price auction model (the ‘tip’ remains first-price), and because the base fee is burned rather than given to the miners, there is no incentive for miners to try and manipulate the fee. Importantly, the mechanism also attempts to solve a big problem for wallet developers automatically trying to estimate network fees by making them much more predictable.

There are several places to read more about EIP 1559; I would recommend Vitalik’s EIP1559 FAQ and Barnabe’s Jupyter notebook if you want to go deeper.

A new challenger approaches: Escalator

Inefficiency of the current first price auction system for Ethereum fees is not controversial, and it’s important to point this out explicitly: No one disputes that the current fee mechanism could be better, and finding an alternative to the first price auction would be indisputably good for Ethereum as a whole — at the end of the day it’ll make things better for both developers and end users alike. We all can and should agree on this.

The new mechanism proposed in EIP 1559 is, however, just different from the way it’s done right now, and changing it will cause some problems, in particular with any software that builds and submits Ethereum transactions for users. Wallets in particular will need to make significant changes to accommodate the new mechanism. Even if things eventually become better for everyone in the long run, in the short term it puts a big burden on the developers working to adjust to the change and prevent their software from breaking.

After EIP 1559 had been floating out in the primordial soup for a while, the community started to weigh in, including wallet developers who would be most affected by the changes proposed. Rather than resist the EIP, wallet developers took an interesting route of discussion. They reconsidered the core motivations for the EIP (improving the UX of Ethereum transactions), and put the EIP into that context, essentially saying “If we’re going to be doing all this work anyways we should from the very beginning have an idea of what it’s going to look like to a user, and we should use that to help guide what’s being proposed”.

This is the over-simplified story behind Dan Finlay’s counter-proposal to EIP 1559: The Escalator Algorithm. It’s similar in a lot of ways to the mechanism of 1559, and has nearly identical motivations and goals. Escalator is presented to stand in as an alternative improvement proposal which allows for a much more nuanced discussion of either mechanism presented in isolation.

To facilitate a more productive and concrete discussion about the gas fee market, I felt it was important to present an alternative that is clearly superior to the status quo, so that any claimed properties of EIP-1559 can be compared to a plausible alternative improvement.

The Escalator mechanism is similar to the current single price auction model, with a few important changes:

• Rather than submitting a transaction with a fixed bid, users submit aptly-named ‘escalating’ bids and specify a maximum amount they are willing to pay to get the transaction included. All bids are put into a queue of ‘escalators’ that gradually and predictably increase all bids in queue at the same rate. This provides a good mechanism for price discovery that still allows users to tweak their settings based on how urgently they want a transaction included, and how much they are willing to pay for it.

The main advantage for escalator is that it enables highly efficient price discovery, while at the same time protecting users from over-paying by charging the second price in queue. It has some of the same strengths as 1559 as well, making it easier for users to choose the right fee, even in times of network congestion. Notably, the escalator by itself would not make any changes to the mechanisms that determine block size.

The “Escalator Algorithm” proposal is interesting in its own right, and I highly recommend reading the ‘user strategy’ section to get a good high-level comparison of the 3 different models of transaction processing. If you like this kind of thing, the paper that introduces the escalator algorithm is also well worth digging into, but I digress…

On an EIP1559 implementer’s call, Dan presented mock-ups showing how the various parameters in an wallet would look to a user, highlighting how they can be hidden or exposed depending on the desired level of user intervention.

The designs were intended to be a reference for community discussion, and help us imagine both 1559 and the escalator algorithm from the perspective of a user.

By introducing a reasonable alternative proposal and re-framing developer criticism to prioritize the challenges of users, the EIP 1559 / Escalator discussion has very deftly created new space of exploration toward the end goal of improving the fee market. It’s far from teed up for the next hardfork, but like the big rig in Mad Max, it’s still moving forward.

The future of Ethereum: All shiny and chrome

I believe EIP1559 / Escalator is an important issue for the Ethereum community to watch and learn from, particularly because it has many of the same characteristics as another more distant (and more dramatic) improvement on the Stateless Ethereum horizon: Oil/Karma EVM semantic changes. Just as in the fee market, some of the proposed modifications are going to have significant second-order effects on developers and users. Also as in the case of 1559, there is a clear user experience aspect to rally behind, and thus an opportunity for coordination with developers who understand that experience to help proposals keep momentum toward an eventual successful upgrade.

Improving Ethereum (1.x) and any other public blockchain is an arduous journey. The right route of discussion should be one that keeps meaningful improvements still on the horizon, and moreover ensures that the developers and users most impacted are heard and their concerns incorporated. Because at the end of the day, we’re all riding the same big rig toward the gates of Valhalla… er, Serenity. Staying ahead of the state bloat problem means continuously and constructively proposing, criticizing, and amending changes without losing momentum— our survival depends on it!

Ethereum can be simple enough to understand from a bird’s-eye view: Decentralized applications powered by the same sort of crypto-economic guarantees that underpin Bitcoin. But once you’ve zoomed in to, say, a street-level view, things get complicated rapidly.

Even assuming one has a strong grasp on proof-of-work, it’s not immediately clear how that translates to a blockchain doing more than keeping track of everyone’s unspent transaction outputs. Bitcoin uses computational work to decentralize money. Ethereum uses computational work to decentralize abstract computation. Wut? That abstraction is called the Ethereum Virtual Machine, and it’s the centerpiece of the Ethereum protocol, because “inside” the EVM is the special domain of smart contracts, and it’s the smart contracts that are ultimately to blame for all those ridiculous #defi tweets.

Upgrading the EVM is one of the major milestones of the Stateless Ethereum Tech Tree, and before we can dig in to the interesting work there, I think it’s prudent to first tackle the obvious question: “WTF is the EVM?”. In the first of this two-part series, we’ll get back to basics and try to understand the EVM from the ground up, so that later we can really engage with current discussion about things like Code Merklization and UNGAS— even stuff from the exciting world of Eth2 like Execution Environments!

WTF is the EVM?

When first year Algebra students get taught about that familiar function f(x), an analogy of “the function machine” is often used. The concept of deterministic input/output, it seems, is a lot easier for kids to think about as a literal physical machine chugging along. I like this analogy because it cuts both ways: The EVM, which in a way actually is a literal machine chugging along, can be thought about as a function which accepts as inputs some state and outputs a new one based on some arbitrary set of rules.

Setting aside the specifics of those rules for now, say that the only valid state transitions are the ones that come from valid transactions (that follow the rules). The abstract machine that will determine a new state (S’) given an old valid state (S) and a new set of valid transactions (T) is the Ethereum state transition function:
Y(S, T)= S’

The first thing that’s very important to understand about this function is that, as an abstraction, it’s sort of a mathematical placeholder: arguably not a real thing, and definitely not the EVM. The Ethereum state transition function is written all fancy in Greek in the yellow paper because thinking about the EVM as a black box function really helps with imagining the whole blockchain system (of which the EVM is just one part). The two-way connection between functions and machines is determinism: Given any valid input, both should produce one and only one output.

But the EVM, as I said before, is in some sense a literal machine chugging along out there in the world. The EVM’s physical instantiation can’t be described in the same way that one might point to a cloud or an ocean wave, but it does exist inside thousands of connected computers running Ethereum clients. And at any given time, there is one and only one canonical Ethereum state, and that’s what we care about. All of the other components inside an Ethereum client are there just to keep consensus over which state is the right one.

The term ‘canonical’ is used because ‘valid’ isn’t quite appropriate; a state transition computed correctly is ‘valid’, but it still might not end up “on chain” as part of the canon. Deciding which states are canonical and which states are not is the sole responsibility of miners doing proof-of-work on the chain. Anyone using Ethereum mainnet has, either literally or just figuratively, “bought in” to one particular state history, namely the one with the most computational work put behind it, as determined by Ethereum’s Greedy Heaviest Observed Subtree (GHOST) protocol. Along with each new block on the network comes a new set of transactions, a state transition, and a freshly determined output state ready to be passed forward into the next canonical block, determined by miners. And so on and so forth; that is how the Ethereum blockchain do.

We’ve so far ‘black-boxed’ the EVM as the state transition function (machine) that takes previous valid blocks and a handful of fresh transactions (as input), does some computation on it, and spits out a new valid state (as output). The other pieces of the Ethereum protocol (such as miners choosing canonical blocks) are necessary context, but now it’s time for some inside-the-box thinking. What about those specific rules we set aside earlier? How does the EVM compute a new state? How can a single machine compute everything from simple balance transfers to elliptic curve algebra?

The Steampunk Stack Machine

The best I can do to introduce the notion of a stack machine is this cartoon image of Babbage’s Analytical Engine (credit: Sydney Padua), which was designed in 1837 but never built:

With most people carrying around fantastically powerful electric computers in their pockets these days, it’s easy to forget that computers don’t necessarily need to be electronic, nor all that powerful. Babbage’s Analytical Engine is a very (hypothetically) real example of a Turing-complete (!) computer that if it had been built, would’ve run on steam and punch cards. The EVM is in important ways much closer kin to the Analytical Engine of two centuries ago than to the CPU inside the device you’re using to read this article.

The EVM is a stack machine, and although in reality it’s a virtualized machine running inside many Ethereum clients simultaneously, I find helpful to imagine the EVM as a real, more advanced (but of course still steam-powered) version of the Analytical Engine. This metaphor might seem a little far-fetched, but I implore you to stick with it for a little bit because it’s quite illustrative when we get to the subject of gas and a shared execution environment.

The steampunk EVM would be a mechanical computer that functions by manipulating physical punch cards. Each card would have 256 places for hole punches, and therefore each card could represent any number between 0 and 2^256. To perform a calculation, one could imagine this computer, through some fancy system of compressed air, putting the cards representing numbers and operations into a stack, and following a simple principle of “first in, last out”, one-by-one it would PUSH new cards to the top of the stack, or POP cards from the top of the stack to read them for next steps. These might be new numbers to calculate with, or arithmetic operations like ADD or MULTIPLY, but they could also be special instructions such as to STORE a card or set of cards for later. Because the cards are simple binary, the operations also have to be ‘encoded’ into a binary number; so we call them operational codes, or just opcodes for short.

If the stack machine were calculating 4 * 5 + 12, it would go about it like so:

_POP value 4 from the stack, keep it in memory. POP the value 5 off the stack, keep it in memory. POP the value _ from the stack; send everything in memory to the multiplication module; PUSH the returned result (20) the stack. POP the value 20 from the stack; keep it in memory. POP the value 12 from the stack; keep it in memory. POP the value + from the stack; send everything in memory to the addition module; PUSH the returned result (32) the stack. (Source: The EVM Runtime Environment)

We can imagine opcodes like ADD or MULTIPLY as special modules built into the machine, near enough to the stack so as to be accessible quickly. When the computer must multiply 4 and 5, it would send both cards to the “multiplication engine”, which might click and hiss before spitting back out the number 20 punched into a new card to PUSH back to the top of the stack.

The “real” EVM has many different opcodes for doing various things. A certain minimum-viable set of these opcodes are needed to do generalized computation, and the EVM has all of them (along with some special ones for crypto, e.g. the SHA-3 hash function). For better or worse, the idea that the EVM is (or is not) Turing-complete has long been under discussion— it’s this stack-based architecture which has the property of Turing-completeness: The EVM’s rules of execution can in principle, given a long enough time and big enough memory, run any conceivable computer program so long as it’s compiled down to the correct 256-bit words and executed in the stack.

Compiling a program in our alternate universe would entail the creation of a booklet of punch cards containing the appropriate data and opcodes. This is literally (er, figurative-literally, whatever) the process going on under the hood when you write a smart contract in a high-level language like Solidity and compile it to bytecode. You can get a pretty good sense of how a programming language gets converted into machine code by reading this humerously annotated output of a Solidity compiler.

So far, the state has not been mentioned, but recall that we set out to understand the rules by which a state transition can be calculated. Now we can summarize it a bit more clearly: The EVM is the physical instantiation (read: instance) of the state transition function. A valid state in Ethereum is one that was calculated by the EVM, and the canonical state is the valid state with the most computational work done on it (as determined by the GHOST protocol).

(Ideal) Gas

We might imagine Babbage completing the fictitious Ethereum Stack Engine and thereafter announcing that all mathematical tabulations and solutions for impossibly difficult problems were now within reach. He’d invite mathematicians and engineers to package up their problems as ‘transactions’ and deliver them to be compiled by Lady Lovelace into punch cards to run through the world computer. (Incidentally, Lovelace was the first person to ever write a computer program, making her the original compiler). Since the machine is meant to be an implementation of the EVM and part of a larger Ethereum steampunk universe, we’d have to imagine the state as being some sort of massive Merkleized library catalog which would be updated once per day according to a pre-selected set and order of transactions chosen as ‘canonical’, and committed to archive.

The trouble with this vision is that a real, mechanical EVM would be extraordinarily expensive to run. The turning of gears, winding of springs, and pumping of various pneumatic chambers collating punch cards would use tonnes of coal every day. Who would bear the expense of running the engine constantly? Say that five mathematicians wanted to run their programs on a particular day, but there was only time enough for three. How would these and related problems of resource management be solved? The solution that Ethereum employs seems, paradoxically, a lot more intuitive when we think about a large and inefficient mechanical computer: Charge money for computation and memory storage!

Imagining the the operations of the stack machine to be powered by compressed air, one could measure the exact amount of gas needed to perform an ADD operation, and compare it to the (much larger) amount of gas needed for SHA3. The table of gas costs for each opcode could be made publicly available, and anyone submitting a program required to provide at least enough money for their computation and storage space according to the cost of gas (which might be related to the price of coal or the demand for computation). The final stroke of genius is to make the machine state itself a ledger for accounts and balances, allowing a user to include payment for their computation inside the transaction itself.

As you might know, gas in an Ethereum transaction accounts for computation and memory costs of the EVM. Gas costs for a transaction must be paid for in ETH, and cannot be recovered once the execution takes place, whether the operation succeeds or not. If a contract call runs out of gas at any point during an operation, it throws an out-of-gas error.

The gas mechanic cleverly does two jobs: Gas efficiently allocates the common-pool computational resources of the EVM according to demand, and provides reasonable protection against infinitely looping programs (a problem that arises from Turing-completeness).

In the next installment of “The 1.X Files”

I hope this fanciful mechanical explanation of a stack machine has been helpful. If you enjoyed thinking about the steampunk EVM as much as I have, and you like historically plausible alt-reality comic books, do investigate “The Thrilling Adventures of Babbage and Lovelace” linked earlier; you won’t be disappointed.

Getting a handle on something so abstract isn’t easy, but there are topics in the Stateless Tech Tree that will be much easier to approach with a relatively complete (even if it’s a bit cartoonish) mental image of an EVM implementation.

One such topic is the introduction of Code Merkleization to the EVM, which would greatly reduce the size of witnesses by breaking up compiled contract code into smaller chunks. Next time we’ll be able to dig in to these immediately.

As always, if you have any questions, comments, requests for new topics or steampunk Ethereum fanfictions, please @gichiba or @JHancock on twitter.