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.

After reaching multi-year lows in 2024, Dollar General (DG 0.18%) and Dollar Tree (DLTR 1.17%) are staging epic recoveries in 2025.

Year to date (YTD) at the time of this writing, Dollar General has surged a staggering 49.5% and Dollar Tree is up 25.2%, compared to a mere 2.1% gain in the S&P 500 (SNPINDEX: ^GSPC).

Even with those gains, both stocks have drastically underperformed the S&P 500 and larger retailers like Walmart (WMT -1.68%) and Costco Wholesale (COST -1.12%) over the last few years.

Here’s what’s driving the rebound in discount retailers, and whether investors are better off with a 50/50 split of Dollar General and Dollar Tree or Walmart and Costco.

Image source: Getty Images.

Signs of improvement

The rebound in Dollar General and Dollar Tree provides a good lesson on the importance of expectations and valuation.

Going into this year, expectations for the discount retailers were as low as they could be. Both companies were struggling to offset inflationary pressures with price increases.

In 2021, Dollar Tree upped the base price of its products to $1.25, which cushioned profits but strained demand. It’s also worth mentioning that Dollar Tree is selling Family Dollar in the second quarter of 2025 for about $1 billion — a significant loss compared to the roughly $9 billion purchase price in 2015.

Frequent customers of Dollar General and Dollar Tree can be more sensitive to inflation and overall higher living costs than retail outlets that aren’t so value-focused. As a result, both companies rely on sales volume to offset their razor-thin margins. The business model can work well when consumer spending is strong, but it can backfire when people tighten their purse strings.

As you can see in the following chart, Dollar General continued boosting sales, but margins are near a 10-year low, reflecting pricing pressure. Dollar Tree’s margins are holding up, but its revenue is down significantly due to store closures and demand pressures.

DG Operating Margin (TTM) data by YCharts.

Despite lackluster results, recent financials for both companies show signs of improvement. Dollar General grew sales and earnings in its recent quarter. Dollar Tree got a jolt from improving results and potential cost savings from the Family Dollar spin-off.

Results for Dollar General and Dollar Tree weren’t great, but because expectations were so low and both stocks were so beaten down, the stage was set for an epic rebound, even if results were mediocre. However, some investors may prefer to go with higher-quality names like Walmart and Costco.

Delivering value and driving customer loyalty

Walmart and Costco have ultra-razor-thin margins, often lower than those of Dollar General and Dollar Tree. But the key difference is that Walmart and Costco deliver masterfully on their value propositions to customers.

Walmart caters to value-focused customers, just like dollar stores. Yet, it has grown sales steadily and sustained decent margins despite pullbacks in consumer spending, because it can go toe-to-toe on price with just about any brick-and-mortar retailer or e-commerce platform. Additionally, Walmart has built out other shopping options, like pickup, delivery through Walmart+, and more.

Similarly, Costco can afford to pass along value to customers on merchandise sales because it generates steady cash flow from annual membership rates. Costco makes the majority of its net income from membership fees, and profits very little from merchandise sales. Customers are incentivized to shop at Costco as much as possible to justify the membership, and Costco gives them good deals in return. Costco could charge more and boost near-term profits, but management is laser-focused on the brand’s strength and long-term customer loyalty.

Priced to perfection

Walmart and Costco are undeniably better businesses than Dollar General and Dollar Tree, but their valuations have reached sky-high levels. Even on a forward price-to-earnings (P/E) ratio basis, Costco and Walmart sport more expensive valuations than all of the “Magnificent Seven” stocks (except Tesla), whereas Dollar General and Dollar Tree have forward P/E ratios under 20.

COST PE Ratio (Forward) data by YCharts.

Over the long term, quality is more important than present-day valuation, because a company that consistently improves earnings can grow into its valuation. But if a company’s stock price keeps increasing faster than its earnings rise, its valuation will remain inflated. This dynamic has been at play with Walmart and Costco, which have seen their P/E ratios balloon far above their historical averages due to their stock prices outpacing earnings growth.

What’s more, both stocks no longer have serviceable dividend yields because their stock prices have outpaced their dividend growth rates. Walmart yields just 0.9% and Costco yields 0.5%. Dollar General sports a decent yield of 2.1%, and Dollar Tree has never paid a dividend. Granted, Costco occasionally pays special dividends when its cash on the balance sheet reaches a comfortable level. But even during special dividend years, like in 2024 and 2020, Costco still only yields around 2% to 3%.

The better buy now

If I had to pick, I’d go with a 50/50 split of Dollar General and Dollar Tree over Walmart and Costco simply because their valuations are so much lower, and Walmart and Costco aren’t growing quickly enough to justify their high valuations. At that valuation level, investors are arguably better off buying a top growth stock like Microsoft, which is expanding margins and consistently generating strong revenue growth.

Walmart and Costco are phenomenal companies, but a great company isn’t always worth investing in if its valuation is at nose-bleed levels — especially when faster-growing alternatives are available at reasonable multiples.

A Verkle tree is a commitment scheme that works similar to a Merkle tree, but has much smaller witnesses. It works by replacing the hashes in a Merkle tree with a vector commitment, which makes wider branching factors more efficient.

Thanks to Kevaundray Wedderburn for feedback on the post.

Overview

For details on how verkle trees work, see:

The aim of this post is to explain the concrete layout of the draft verkle tree EIP. It is aimed at client developers who want to implement verkle trees and are looking for an introduction before delving deeper into the EIP.

Verkle trees introduce a number of changes to the tree structure. The most significant changes are:

• a switch from 20 byte keys to 32 byte keys (not to be confused with 32 byte addresses, which is a separate change);
• the merge of the account and storage tries; and finally
• The introduction of the verkle trie itself, which uses vector commitments instead of hashes.

As the vector commitment scheme for the verkle tree, we use Pedersen commitments. Pedersen commitments are based on elliptic curves. For an introduction to Pedersen commitments and how to use them as polynomial or vector commitments using Inner Product Argumentss, see here.

The curve we are using is Bandersnatch. This curve was chosen because it is performant, and also because it will allow efficient SNARKs in BLS12_381 to reason about the verkle tree in the future. This can be useful for rollups as well as allowing an upgrade where all witnesses can be compressed into one SNARK once that becomes practical, without needing a further commitment update.

The curve order/scalar field size of bandersnatch is p = 13108968793781547619861935127046491459309155893440570251786403306729687672801, which is a 253 bit prime. As a result of this, we can only safely commit to bit strings of at most 252 bits, otherwise the field overflows. We chose a branching factor (width) of 256 for the verkle tree, which means each commitment can commit to up to 256 values of 252 bits each (or to be precise, integers up to p – 1). We write this as Commit(v₀, v₁, …, v₂₅₅) to commit to the list v of length 256.

Layout of the verkle tree

One of the design goals with the verkle tree EIP is to make accesses to neighbouring positions (e.g. storage with almost the same address or neighbouring code chunks) cheap to access. In order to do this, a key consists of a stem of 31 bytes and a suffix of one byte for a total of 32 bytes. The key scheme is designed so that “close” storage locations are mapped to the same stem and a different suffix. For details please look at the EIP draft.

The verkle tree itself is then composed of two types of nodes:

• Extension nodes, that represent 256 values with the same stem but different suffixes
• Inner nodes, that have up to 256 children, which can be either other inner nodes or extension nodes.

The commitment to an extension node is a commitment to a 4 element vector; the remaining positions will be 0. It is:

C₁ and C₂ are two further commitments that commit to all the values with stem equal to stem. The reason we need two commitments is that values have 32 bytes, but we can only store 252 bits per field element. A single commitment would thus not be enough to store 256 values. So instead C₁ stores the values for suffix 0 to 127, and C₂ stores 128 to 255, where the values are split in two in order to fit into the field size (we’ll come to that later.)

The extension together with the commitments C₁ and C₂ are referred to as “extension-and-suffix tree” (EaS for short).

Figure 1 Representation of a walk through a verkle tree for the key 0xfe0002abcd..ff04: the path goes through 3 internal nodes with 256 children each (254, 0, 2), one extension node representing abcd..ff and the two suffix tree commitments, including the value for 04, v₄. Note that stem is actually the first 31 bytes of the key, including the path through the internal nodes.

Commitment to the values leaf nodes

Each extension and suffix tree node contains 256 values. Because a value is 256 bits wide, and we can only store 252 bits safely in one field element, four bits would be lost if we simply tried so store one value in one field element.

To circumvent this problem, we chose to partition the group of 256 values into two groups of 128 values each. Each 32-byte value in a group is split into two 16-byte values. So a value vᵢ∈ 𝔹₃₂ is turned into v⁽ˡᵒʷᵉʳ⁾ᵢ ∈ 𝔹₁₆ and v⁽ᵘᵖᵖᵉʳ⁾ᵢ∈ 𝔹₁₆ such that v⁽ˡᵒʷᵉʳ⁾ᵢ ++ v⁽ᵘᵖᵖᵉʳ⁾ᵢ= vᵢ.

A “leaf marker” is added to the v⁽ˡᵒʷᵉʳ⁾ᵢ, to differentiate between a leaf that has never been accessed and a leaf that has been overwritten with 0s. No value ever gets deleted from a verkle tree. This is needed for upcoming state expiry schemes. That marker is set at the 129th bit, i.e. v⁽ˡᵒʷᵉʳ ᵐᵒᵈⁱᶠⁱᵉᵈ⁾ᵢ = v⁽ˡᵒʷᵉʳ⁾ᵢ + 2¹²⁸ if vᵢ has been accessed before, and v⁽ˡᵒʷᵉʳ ᵐᵒᵈⁱᶠⁱᵉᵈ⁾ᵢ = 0 if vᵢ has never been accessed.

The two commitments C₁ and C₂ are then defined as

Commitment of extension nodes

The commitment to an extension node is composed of an “extension marker”, which is just the number 1, the two subtree commitments C₁ and C₂, and the stem of the key leading to this extension node.

Unlike extension nodes in the Merkle-Patricia tree, which only contain the section of the key that bridges the parent internal node to the child internal node, the stem covers the whole key up to that point. This is because verkle trees are designed with stateless proofs in mind: if a new key is inserted that “splits” the extension in two, the older sibling need not be updated, which allows for a smaller proof.

Commitment of Internal nodes

Internal nodes have the simpler calculation method for their commitments: the node is seen as a vector of 256 values, that are the (field representation of the) root commitment of each of their 256 subtrees. The commitment for an empty subtree is 0. If the subtree is not empty, then the commitment for the internal node is

where the Cᵢ are the children of the internal node, and 0 if a child is empty.

Insertion into the tree

Figure 2 is an illustration of the process of inserting a new value into the tree, which gets interesting when the stems collide on several initial bytes.

Figure 2 Value v₁₉₂ is inserted at location 0000010000…0000 in a verkle tree containing only value v₁₂₇ at location 0000000000…0000. Because the stems differ at the third byte, two internal nodes are added until the differing byte. Then another “extension-and-suffix” tree is inserted, with a full 31-byte stem. The initial node is untouched, and C²₀ has the same value as C⁰₀ before the insertion.

Shallower trees, smaller proofs

The verkle tree structure makes for shallower trees, which reduces the amount of stored data. Its real power, however, comes from the ability to produce smaller proofs, i.e. witnesses. This will be explained in the next article.

The witness’s commitments in one output of a Coinbase transaction include:
OP_RETURN commitment_prefix|witness_commitment

where commitment_prefix=0xaa21a9ed and
witness_commitment=sha256(sha256(witness_merkle_root|witness_reserved_value)).

witness_merkle_root The root of the Merkle tree, which includes all transactions, takes witness data into account. For Coinbase transactions, you cannot use the actual hash of the transaction due to recursive dependencies. To resolve using all 0:

                             sha256(sha256(E | F))
                                        │
                     ┌──────────────────┴───────────────────┐
                     │                                      │
        E = sha256(sha256(A | B))               F = sha256(sha256(C | D))
     ┌───────────────┴───────────────┐      ┌───────────────┴───────────────┐
     │                               │      │                               │
     A (CoinbaseTx)                  B      C                               D
  000...                         txid_2  txid_3                         txid_4

Why use a TX ID set for all 0s rather than ignoring Coinbase transactions and creating a Merkle route?