Ethereum has a famous (or infamous, depending on who you ask) roadmap that details its path to achieving its ultimate vision. This end state includes goals like creating a robust PoS consensus, scaling rollups to 100k transactions per second, eliminating centralization concerns, boosting censorship resistance, making running a node super easy, and clearing technical debt. This diagram often gets fairly critiqued for being complex and confusing if you don’t have a PhD in blockchain infrastructure. After reading this post, you'll be an expert on the impact of a major piece of the diagram: Verkle Trees.
At a high level, one of Ethereum's key goals is to make running a node that verifies blocks as lightweight as possible. When Ethereum switches its state database structure from a Merkle Patricia Tree to Verkle trees, it will enable a new type of node called a stateless client. These nodes are almost as lightweight as current light clients that only receive headers and can verify state proofs, but they also verify transactions in real-time and therefore are fully protected against invalid state transitions.
Currently, the number of nodes that protect the network against corruption (invalid state transitions) is in the thousands, but with the introduction of stateless clients, this number could potentially increase to millions. Additionally, Verkle trees enhance the efficiency of transaction verification, allowing for a safe increase in the gas limit by 3-10x.
In this post, I'll briefly touch on what Merkle and Verkle trees are, but the focus isn't on cryptography. Instead, it's for those interested in the bigger picture of what these data structures enable: stateless clients. You'll understand what they are, how they work, why they matter, how they fit into Ethereum's roadmap, and why Vitalik is so excited about them.
TLDR
What is a stateless client and how does it work?
Ethereum's state, the database of accounts, balances, and smart contract data, grows alongside the blockchain itself. Each node currently needs 2TB of storage (SSD) to store this state (and history 1.2TB), which is currently 245.5GB and growing. Stateless clients verify transactions without storing the state. They rely on execution witnesses included with each block, containing pre-state data and a cryptographic proof that this pre-state is part of the parent state root. For example, if Alice sends Bob 1 ETH, the witness confirms Alice and Bob's starting balance is part of the parent state root. You then execute the block to ensure that Alice has sufficient funds and verify Bob's updated balance. Ethereum's current state is stored in a Merkle Patricia Tree, which can generate state proofs. However, these proofs become excessively large as the state grows, making them impractical for efficient transmission and verification. Verkle trees are a new way to store Ethereum's state, enabling compact proofs that remain small even as the state grows. These compact proofs make stateless clients a practical reality.
What are some of the traits of stateless clients?
Near-Instantaneous Node Setup: New nodes can join the network and start validating immediately, receiving only the latest block and its state proof. This eliminates the process of downloading and verifying the entire blockchain history, which can take over a day.
Low-Powered Nodes: Stateless nodes eliminate the need for extensive storage and, when combined with eliminating the need to store history, will allow nodes to run on lower-power devices. They could run locally in your browser or possibly on very low-power devices like smartwatches and phones.
Cheaper Nodes: This reduction in storage requirements also makes verifying nodes much cheaper. Currently, a 2TB SSD, which is necessary to store the full state on a traditional node, costs around $100.
Wallet Integration: Wallets will be able to integrate these stateless clients into their products. Every time a user opens their wallet, it would locally spin up a new stateless client. This could increase the number of Ethereum nodes to the millions.
Verifying Light Clients: Currently, users trust centralized RPCs like Infura or Alchemy when interacting with or viewing the blockchain. Light clients today can already allow for trustless access to state information, and we need to push wallets to integrate them. However, stateless clients take this a step further by also protecting against invalid state transactions by verifying all the transactions in a block.
What do stateless clients unlock?
Unstoppable Decentralization: By potentially increasing the number of lightweight, full-verifying nodes to millions, stateless clients make Ethereum virtually uncorruptable.
Scalable Layer 1: As the blockchain's state grows, each node needs more storage space, leading to slower block verification due to increased database lookups and updates. This creates a compounding issue: more transactions mean faster state growth, further increasing verification time. This state growth is the primary obstacle to Ethereum's scalability. Stateless clients eliminate the need for extensive state storage and simplify database interactions, allowing it to happen almost entirely in RAM, ensuring block verification is not slowed by state growth. This could allow Ethereum to increase its gas limit by 3-10x without sacrificing verification speed.
Scalable Layer 2s: The way Ethereum plans to achieve throughput of 100k transactions or more for L2s is via a method called data availability sampling. How this works is beyond the scope of this post (maybe I’ll cover it soon
) but the key takeaway is the more Ethereum nodes there are, the more nodes that are sampling blob data, and the more nodes that are sampling blob data, the more blobs the Ethereum network can include per block. If there are enough sampling nodes, this will lead to data costs being virtually zero for L2s. Remember how stateless clients could lead to millions of nodes…
What does this set the stage for?
Fully SNARKed Ethereum: The ultimate goal is to move from receiving state proofs and verifying individual transactions to receiving a single SNARK proof that verifies the entire state transition is correct. This approach would essentially make Ethereum behave as a zkRollup, where a single proof can verify the block execution correctness, which includes a vast number of transactions, allowing Ethereum to scale 10-100x or more. In this world, compute is no longer a bottleneck for scaling Ethereum and running a node on the lowest power devices would be a given.
State Expiry: Users currently pay a one-time cost to store data on the blockchain, but nodes must store this data indefinitely. Stateless clients will allow anyone to verify the blockchain in real time with virtually no storage requirements. However, they are not the only nodes in the network. There will still be block builders and nodes that choose not to go stateless and prefer to keep the state. These nodes will require more and more storage as the state grows, leading to centralization risks. Adding Verkle trees for the state database sets the stage for state expiry. State expiry means that, except for nodes that choose to store everything (like archive nodes), all other nodes would remove state that has not been recently accessed (e.g., in the last year) and require Verkle state proofs to revive expired state. This would reduce the state that everyone needs to store to a flat ~20-50GB.
Wen?
The current roadmap suggests that Verkle trees (or a potential alternative) are more likely to be included in the Osaka-F star hardfork, tentatively scheduled for early 2026.
Before Stateless Nodes | After Stateless Nodes | |
Stores the Current State | Yes | No |
Storage Needed | 2TB and growing | Minimal (with history expiry) |
Verification | Slower due to DB lookups | At least 3x faster |
Set Up | Takes over a day | Near-instant |
Browser Compatibility | No | Yes |
Mobile Device Compatibility | No | Potentially |
Number of Verifying Nodes | Thousands | Potentially Millions |
That’s the high-level takeaway. If you want to stop reading here, you'll have a good understanding. However, if you want to dive deeper, the rest of the post will cover in detail some of the topics touched on above.
Light Weight Nodes, Instantaneous Set Up, and Unprecedented Decentralization
Ethereum's long-term vision has always been to create an unstoppable blockchain, resistant to manipulation by any central group or entity. This vision hinges on the ability of millions, if not someday billions, of users around the world to run nodes and independently verify the network.
Currently, running a node that verifies the chain in real-time is possible on standard consumer hardware for a few hundred dollars, and over ten thousand people are doing just that. This empowers them to directly validate transactions and rules, safeguarding their assets and preventing unauthorized changes to the network. As Vitalik explains in "The Limits to Blockchain Scalability," "The elites of your blockchain community, including pools, block explorers and hosted nodes, are probably quite well-coordinated; quite likely they're all in the same telegram channels and wechat groups. If they really want to organize a sudden change to the protocol rules to further their own interests, then they probably can." Jordan McKinney, in "Scaling Ethereum 101," echoes this sentiment, emphasizing that wider node participation by users makes it significantly harder for malicious actors, even those who are well-coordinated, to collude and hijack the chain.
In summary, the more nodes around the world running the chain, the more difficult it becomes for any central group to violate the rules of the blockchain and steal value from users.
Stateless nodes drastically lower the barrier to run a node. They will be so lightweight they could run in your browser or POSSIBLY on your phone. It would also be nearly instantaneous to spin up a stateless node. You’d receive the previous state root and the current proposed block along with the Verkle proof witness and immediately start validating the chain. Gone will be the days where it would take at least a day to sync to the tip of the chain.
Geth developer Marius van der Wijden expects that once Verkle trees make stateless nodes possible and wallets incorporate them into their products, Ethereum may grow from 10,000 nodes to millions of stateless nodes. "Everyone can run these nodes," he said. "They need a little bit of storage, they don’t need much memory, they need a little bit of bandwidth, but it could be that you can run these on your phone." Ethereum researcher Dankrad Feist also thinks running them on your phone might be possible. However, some Ethereum researchers don't think running it on a phone is practical quite yet.
Already today, the architecture exists for trustless interactions with Ethereum using light clients. Light clients allow users to verify state information by requesting proofs from RPCs, meaning they can trust the data they receive without storing the entire blockchain state. Wallets could embed light clients, like Helios, into their products, enabling users to verify parts of the state by asking an RPC for a witness proof to confirm accuracy. This approach allows users to interact with the blockchain trustlessly, ensuring the data they receive is accurate without having to rely on centralized services.
However, stateless clients take this one step further. Light clients currently trust that the block headers they receive are correct because they come from the sync committee. While this is a step in the right direction, it's not perfect. Stateless clients will be able to verify all transactions in a block, ensuring the headers are correct with certainty. This level of verification guards against invalid state transitions. By building stateless clients into wallets, users can protect themselves and the network from invalid state transactions, making Ethereum virtually impossible to collude against and attack.
While we work towards the full implementation of stateless clients, it's crucial to push for the integration of light clients into wallets today. This step will enhance trust and security in the short term. Once stateless clients are integrated, they will provide an even higher level of security by verifying every transaction, not just relying on headers.
A valid criticism is that people don't care about decentralization. However, Ethereum developers must remember its importance and prioritize it. By integrating stateless nodes into wallets, users can benefit from enhanced security and decentralization without added complexity or inconvenience. Another example of this is the potential integration of stateless nodes into development frameworks. This would allow app developers to enjoy a trustless RPC relationship without needing additional work. It's on us to resist the natural incentives and prioritize decentralization, even when it's the harder path.
The user experience remains the same, but it will be more trustless. This is how you build a protocol that can last for decades.
How to Safely Scale Layer 1
Historically, networks, like Ethereum, which have low hardware requirements are met with soaring fees when demand increases. We’ve seen this many times throughout Ethereum’s history. This has created a formidable challenge: how to scale the network to accommodate growing demand while not just preserving accessibility for everyday users but even making it easier to run a node.
To understand how stateless nodes fits into Ethereum's scaling puzzle, let's break down what happens within its 12-second block time. You can visualize this process in the screenshot from Jordan McKinney's "Scaling Ethereum 101" video below.
In the first 4 seconds, a new block is proposed and propagated across the network. Nodes receive this block sometime within those first 4 seconds and spend about 300-600 milliseconds processing its transactions and verifying the block's accuracy. The remaining 8 seconds are dedicated to validators confirming the block's validity through a voting process. At first glance, the short block processing time compared to the 8 second voting time that follows it might suggest an easy solution: pack more transactions into each block and make the processing time a little longer. However, this is not so simple. While the 8 second voting process itself is relatively quick, it doesn't tell the whole story.
Although nodes can quickly agree on the tip of a chain (within that 8 second window), the remaining "dead time" is crucial. If new blocks were constantly being added at the same rate nodes process them, nodes that have fallen out of sync or are joining the network for the first time would never be able to catch up.
Blockchain's State Growth Problem and the Need for Innovation
The growth of Ethereum's state also presents a major hurdle to scaling. Ethereum’s state is the database that stores contract bytecode, contract storage, account balances, and account nonces and is constantly getting bigger.
As of Mar 4th of this year it took up 274GB of storage and is growing by 2.5GB every month. This expansion directly impacts how quickly blocks can be processed. As the state grows, it takes longer to find and update the necessary information, slowing down the entire verification process. This means that over time, block verification naturally becomes slower. Therefore, the more transactions Ethereum handles, the faster the state grows, creating a snowball effect that further increases verification time.
Binance Smart Chain highlights the dangers of scaling solely by increasing the transaction capacity (raising the gas limit and speeding up the blocktime). This led to an explosion in state size, making it virtually impossible for new nodes to join the network or for nodes that fell out of sync to catch up, as the time required to verify new blocks continuously increased, even with powerful hardware and a limited number of validators. This illustrates the critical need to address state growth directly as part of any effective scaling solution. (If you're curious to learn more about this issue, the Uncommon Core podcast episode with Hasu and Jon Charbonneau offers a detailed discussion around the 32min mark.)
When you combine the state database with the history of the chain (all the blocks and transactions needed to sync a node from the very beginning), which currently sits at a 1.2TB and grows by roughly 19.3GB each month, you're looking at a lot of storage. In total, you need 2TB of storage to run a full node today. So, if you want to run a node on a budget-friendly device like a NanoPC T6, Radxa Rock 5B, or Orange Pi 5 Plus, you'll need to spend at a minimum $170-$220 for the computer itself, plus another $100 for at least 2TB of storage.
However, this is just the starting point. If the state and history continue to grow at the same rate, we'll hit the critical threshold of 1.8TB in just 2 to 3 years. This means that, sooner rather than later, you'd need to upgrade your storage to a pricier 4TB option, potentially costing around $300. And as the state and history keep expanding, you'd need to keep upgrading, eventually reaching a point where you'd need 8TB of storage, which can cost over $1,000! If this trend continues unchecked, running a node could eventually require a full-blown data center.
Ethereum's Current State Management (and Its Limitations)
Ethereum's current state is stored in a data structure called a Merkle Patricia Tree. This tree-like structure organizes all the account balances, contract code, and storage data. Each leaf represents an account's state. These leaf hashes are then combined in pairs and hashed, forming higher-level branches. This process continues, creating a cascade of hashes until a single root hash emerges, representing the entire state.
This structure offers several benefits. First, it ensures data integrity: any change to even a single account's state will result in a different root hash, making tampering immediately evident. Second, it enables efficient verification: instead of downloading the entire state, you can prove a specific piece of data's validity by presenting a Merkle Proof.
A Merkle proof is a set of hashes that can verify a specific piece of data belongs to a larger dataset. It leverages the tree structure, where data is hashed and combined hierarchically into a single root hash. The proof includes the data's hash and a path of sibling hashes that allows recalculation of the root hash, confirming the data's inclusion. In Ethereum, a Merkle proof allows you to verify specific information about an account or smart contract without downloading the entire blockchain's state.
When a new block arrives, it has a list of proposed transactions and a new state root. Nodes, each maintaining a copy of the current state in a Merkle tree, verify each transaction. They ensure senders have sufficient funds, execute smart contract logic, and update their local state tree accordingly. After processing all transactions, the node recalculates the state root by hashing the updated tree. This recalculated root is then compared to the one provided in the block header. A match confirms the block's validity, proving that the validator who proposed the block executed the transactions correctly and didn't attempt any fraudulent activity.
This process works well, but it needs to scale up. The current bottleneck is when the node needs to access and update the state. This requires reading and writing data to the hard drive, which has a limited input/output operations per second capacity. As the state grows, the number of required input/output operations increases, slowing down the entire verification process.
This creates a compounding issue – the more transactions Ethereum handles, the faster the state grows, further increasing verification time.
Even the fastest NVMe SSDs have a maximum capacity, which translates into a theoretical limit on the number of transactions Ethereum can process per second. Eventually, the growing state will exceed even the fastest drive's capacity, acting as a "brick wall" that limits Ethereum's transaction throughput.
In addition to their large hard drives, nodes also have a faster type of memory called RAM for storing temporary data. Think of RAM like a super fast scratchpad for the computer to jot down notes while it's working. Accessing and updating information in RAM is lightning fast compared to the hard drive. The catch is that RAM is much smaller, while most Ethereum nodes today have 2TB of storage space, their RAM is usually only 32GB or 64GB.
The Key to Unlocking Ethereum's Speed and Scalability
Verkle trees are a game-changer because they allow nodes to verify blocks primarily using this fast RAM, barely touching the slower hard drive. Now, you might be thinking, "Hold on, don't nodes need the entire Ethereum state stored on their hard drive to verify transactions?" With Verkle trees, the answer is surprisingly no. They make it possible for nodes to operate without storing the state, a concept known as "statelessness."
Stateless clients represent a future for Ethereum where nodes no longer need to store the blockchain's entire state. Instead, they rely on compact proofs (Merkle or Verkle, more on this later), delivered alongside each block as a "witness." These witnesses essentially vouch for the accuracy of the specific data needed to verify the block's transactions. This streamlined approach allows nodes to do their job using primarily their fast RAM, with minimal storage requirements.
For example, if Alice sends Bob some ETH, the witness would include proof of Alice's and Bob's account balances. A stateless client can independently validate this transaction by checking these proofs and simulating the transaction to ensure it matches the new state root in the block header. This process is estimated to be 3-10 times faster than the current method of verifying blocks, which requires retrieving and updating state data from a node's hard drive. This speedup opens the possibility of increasing the gas limit by a factor of 3 to 10, leading to a corresponding increase in the blockchain's throughput.
However, for stateless Ethereum to truly work, the current Merkle tree structure needs to be replaced with Verkle trees. Merkle proofs are simply too big when dealing with Ethereum's massive (and growing) state.
Unlike Merkle trees, which use multiple branches and hashes to represent each piece of data, Verkle trees use a more compact structure based on vector commitments. You can picture it like a wider, shorter tree, meaning there are fewer levels to traverse when creating a proof, and the proof size stays consistent even as the state grows. This results in dramatically smaller proofs, making the "stateless" client vision a practical reality.
Verkle trees achieve their magic through some seriously impressive cryptography. While the inner workings might seem like Jedi magic to most of us (myself included!), the key takeaway is that Verkle trees enable drastically smaller proofs compared to Merkle trees. While Merkle proofs for a block can easily exceed 10MB, and in the worst case, reach up to a whopping 400MB, Verkle proofs are mere kilobytes in size! A fun fact about Verkle Trees is that John Kuszmaul designed them in 2018 while still in high school.
While stateless nodes are theoretically possible with Merkle proofs, they're impractical in reality. For stateless operation to work efficiently, the witness size must be very small, on the order of kilobytes, aka the size of Verkle proofs. Merkle proofs can exceed the capacity of RAM and make it difficult to transmit them across the network quickly enough for validators to process within the 12 second block time.
Ethereum's Modular Future
If regular nodes aren't storing the state, who is? With PBS, the responsibility of building blocks is offloaded to specialized entities called builders. These builders run powerful machines designed to handle the heavy lifting of generating Verkle proofs and maintaining a full copy of the Ethereum state. This division of labor allows builders to focus solely on constructing blocks, including creating the Verkle proof witnesses. Meanwhile, validators can specialize on efficiently verifying the validity of these blocks using the compact Verkle proofs provided by the builders. This modular approach will rely on other entities like archive nodes, RPC services, and block explorers to play a role in holding and serving the state to users, always accompanied by a cryptographic proof to ensure the correctness of the information provided.
Potential Alternatives to Verkle Trees
While Verkle trees are a promising solution, Ethereum is not strictly bound to them. The ultimate goal is to develop the most efficient stateless clients by keeping the database simple, SNARK-friendly, and capable of creating small state proofs and the community is exploring other alternatives solutions including:
Binary trees: Potentially wrapped in a STARK to reduce proof sizes.
SHA256-based approaches: Known for safety but slower to prove.
Lattice-based hash functions: Arithmetically simple and prover-friendly, offering compact proofs.
Ethereum remains open to adopting the best available cryptographic structure to achieve efficient stateless clients and true scalability. For more specific details of each potential alternative check out this tweet from Vitalik.
Timeline and Transition
However, it's important to note that this future isn't imminent. While Verkle trees are a significant development, their integration into Ethereum mainnet will be a gradual process. They are not going to be included in the upcoming Prague-Electra hardfork, which is likely to be activated in early to mid 2025. Instead, the current roadmap suggests that Verkle trees (or a potential alternative) are more likely to be included in the Osaka-F star hardfork, tentatively scheduled for early 2026. This timeline, however, is subject to change as development progresses and the community aligns on priorities. There's still a lot of testing that needs to be done to ensure a smooth and secure transition. Switching to a new data structure like Verkle trees carries inherent risks, and the Ethereum community is committed to ensuring this change is implemented safely and responsibly. For more on the technical details of the transition see this document or this presentation.
Welcome to the endgame, wen stateless.
