Key Takeaways

The Verge’s primary goal is to make light clients as easy as possible to run and increase their role in the security of Ethereum, while the Purge’s primary goal is to simplify the protocol by stripping down the storage requirements of nodes.
Verkle Trees are an efficiency improvement on Merkle-Patricia Trees for light client verification of transaction inclusion and state transitions.
SNARKs, a version of zk proofs, will be included in many different areas of Ethereum for immense efficiency improvement. This includes SNARK-based light clients, SNARKs for consensus state transitions, and a SNARK-based enshrined rollup.
The two largest bottlenecks to operate a full node are history and state. History expiry, weak statelessness, and state expiry should heavily reduce the amount of data full nodes need to store, leading to a more decentralized and robust network.

While the other elements of Ethereum’s roadmap have received more attention, such as Shanghai for withdrawals and rollup scaling through EIP-4844 and Danksharding, the next two portions of Ethereum’s roadmap are often overlooked but are extremely important for the efficiency, decentralization, and robustness of the Ethereum protocol.

The first of these portions, the Verge, refers to the goal of having the verification of blocks be as easy and as light as possible.

This includes replacing the use of Merkle-Patricia trees for holding and verifying state with more efficient Verkle trees and the inclusion of SNARKs in many different areas of the protocol, both of which will lead to greater efficiency and quicker block verification for nodes.

Another important element of Ethereum is the storage requirements of nodes, since they currently need to hold both the history (all data from previous blocks) as well as state (the current snapshot of the network’s balances).

The Purge refers to the goal of simplifying the protocol, meaning lowering the requirements to participate in validating the network via history and state, and eliminating any technical debt.

This means the inclusion of history expiry, where nodes can prune data after a given time period; state expiry, where the system stops keeping track of inactive state balances after a given time period; and weak statelessness, where nodes do not need the state to verify blocks. Together, these two elements of the roadmap help foster better decentralization and efficiency for the Ethereum network.

The Verge

This section on Ethereum’s roadmap is essentially defined by one thing: making light clients as easy to run as possible and increasing their impact on the security guarantees of the protocol. Running full nodes can be extremely hard, so increasing the viability and importance of light clients is very important for the resilience and decentralization of Ethereum.

So far, there have only been two upgrades that have been implemented with respect to the Verge. The first is the increasing of gas costs for state access opcodes in the Berlin upgrade, as they were the largest vector of DoS attacks on the network. The second is the inclusion of sync committees for consensus layer light clients in the Altair beacon chain upgrade, as they allowed the easy building of light clients that tracked the consensus layer. The rest of the Verge improvements center around the use of Verkle trees and SNARKs.

Verkle trees

Merkle-Patricia trees, a modified version of Merkle trees, are a fundamental piece of Ethereum as they allow for the secure verification of a large number of transactions in a block. Ethereum is in the process of exploring a more efficient alternative to Merkle trees specifically for state, called Verkle trees.

In order to gauge why Verkle trees are an upgrade in efficiency, we must first explain how Merkle trees and Merkle proofs work. At a high level, Merkle trees are a data structure that allows for proving the inclusion of a transaction without requiring someone to download all of the data. Merkle trees look like this:

At the bottom of the trees you have your transactions, each of which are hashed. The hashes that correspond directly with a transaction are called “leaves,” whereas all hashes (including leaves) are referred to as “nodes.” Then as you work your way up, nodes are created by hashing two children nodes below them. The final hash that results at the top is called the “root.” The root is then included in a block header, which enables easy verification from light clients, due to it being the result of all the transaction hashes beneath it.

Once you have this structure in place, you can generate proofs for a specific transaction without needing all the data. For example, if we wanted to prove that T1 was included, you would check for its hash H1. Since the Merkle Root is given in the block header (which is H12345678), you only need to show H2, H34, and H5678 to prove that H1 is there. This is due to the fact that you have H12345678, so you only need to show hashes that correspond to every single other transaction number (2345678) to prove the one left out (1) is included.

Another way to look at this is that the proof must contain all nodes on the tree that share the same parent with any of the nodes in the path going from the Merkle Root to the hash you are trying to prove. In the example above, you start from the Merkle Root and need to go down through H1234, which means you need to check H5678 as it shares the same parent (the Merkle Root). As you make your way down further, since you pass through H12 you need to check H34 as it shares the same parent (H1234). The same applies for H2, as it shares the same parent in H12. These nodes that share the same parent are called sister nodes.

While this example only passes through three sister nodes, this gets extremely resource intensive when you see trees with exponentially more nodes.

Enter Verkle trees. They look similar to Merkle trees, but rather than needing to provide every sister node on the way down to the node of choice, you instead just provide the path itself as part of the proof.

You’re able to do this through the use of vector commitments, a special type of hash function which allows for multiple children nodes to be under one single node, as opposed to Merkle trees where there is a fixed pair of children nodes under each node. You can then generate a proof as a commitment to each child node all at once, meaning each step in the path is done by looking at all children nodes at once as opposed to going one-by-one through all sister nodes. Pretty cool right?

Given that you only need to provide the path, Verkle trees are much wider than Merkle Trees, as it allows more transactions to be included while minimizing the steps in each potential path. Then, instead of normal vector commitments, Ethereum plans on replacing them with KZG commitments which are much more efficient.

So, where does this fit into light clients? Since the Verkle tree proofs are much easier to verify than Merkle-Patricia trees, utilizing them for state means light clients can more easily and quickly verify balances using only the block header. Verkle trees alone are 3x more space efficient, but you also now have the ability to merge all possible Verkle proofs together for exponentially greater performance.

To see this actually implemented, Ethereum still needs further exploration for the exact specification, better understanding of EVM gas cost effects, and the removal of SELFDESTRUCT from the EVM opcodes which is expected in the Cancun upgrade this year.

Fully SNARKed Ethereum

The easy verification of blocks is heavily related to the implementation of SNARKs, also known as zk-SNARKs, which stand for “Succinct Non-Interactive Argument of Knowledge.” These are a version of zk proofs that allow one party to prove to another that something is true without revealing any information beyond the validity itself, while allowing the verification to be as quick as possible and requiring little resources. There are many elements of Ethereum that would be upgraded by either the addition of SNARKs for verification or by replacing old proof systems with SNARKs for better efficiency.

The first transition is in using SNARK-based light clients. Light clients have gone through a lot of advancements already, beginning with “sync committees,” which allow light clients to easily sync up with the header chain with very low computational and data costs. Sync committees are a randomly selected subset of 512 validators that serve for 256 epochs (~27 hours) and sign every beacon chain block header they see. If more than two-thirds of the committee sign a given block header, it is highly likely that the block is included in the canonical beacon chain. SNARK-based light clients will use SNARKs in the transitions between these committees as a way to quickly prove which validators form the current sync committee and verify BLS aggregated signatures from that committee, making the client even “lighter.” Gnosis DAO has been researching an implementation of a SNARK-based light client as a good concrete example, but there is still much research to be done.

Once this has been achieved, the next step will be the use of SNARKs for consensus state transition. Basically, as the chain goes from one beacon chain block to the next and the state requires a change, it would be better to incorporate SNARKs to verify these changes. One way is to transition away from using sync committees, and instead verify all things happening on the consensus layer through SNARKs. This includes using SNARKs in the Verkle trees explained above, where you can actually merge all potential Verkle proofs of one tree into a single SNARK. This allows for quick verification of any possible hash all at once, and means that it won’t be necessary to verify the whole state of the previous block to confirm that the current block was modified correctly. By combining some processes and removing others, you end up with extreme efficiency across the board.

In addition, this includes using SNARKs for the Ethereum execution layer, essentially creating an enshrined rollup. As a reminder, an enshrined rollup looks like any other rollup except it has consensus integrations directly at the L1 level and therefore isn’t deployed as a smart contract. The vision for this means changing the single-instance EVM we have today and upgrading it to a state root equivalent zkEVM, using a SNARK each block to prove that the state root is valid. This leads to many benefits for Ethereum as a whole, including simpler consensus as you can replace complex execution code for simple SNARK verification code, as well as the implementations regarding state transitions and improved light clients mentioned above. Ethereum can also choose to increase the gas limits for a block, currently set at 30M gas, increasing the block size alongside Danksharding’s implementation. After this initial upgrade of the single-instance EVM, we could likely see 64 enshrined rollups running in parallel.

All of these changes would not be possible without improvements in the technology that generates these proofs, such as SNARK and STARK ASICs. Once we have completely SNARKified Ethereum, the final transition will be to a quantum-safe version of SNARKs, such as STARKs, which is in line with Ethereum’s vision to be completely quantum resistant.

The Purge

This section mostly refers to the simplifying of the protocol so that you can have more participation in the network through full nodes. This comes primarily through the expiration and management of history and state.

As a reminder, history and state are two separate things. History, as its name suggests, accounts for the entire history of the chain and everything that’s ever happened on it. State is simply a snapshot of all the data needed to validate the chain at the current block, such as the balances of EOAs and smart contracts.

EIP-4444 (History Expiry)

Historical data takes up a significant amount of hardware space for nodes. Currently, Ethereum’s history accounts for around 2.5 TB in storage per year, with Danksharding potentially bringing that number to 40TB per year. As the network continues to grow, it becomes unsustainable to require nodes to hold on to the data for a long period of time, and getting rid of that data after a certain time does not negatively impact the network’s security, as long as only one person holds onto it. The Ethereum community feels confident that there are enough entities that require storing the entire history of Ethereum that it is safe for a vast majority of full nodes to regularly prune the data.

By allowing the network to clear out old history, you reduce the storage requirements of all clients and reduce overall code complexity. EIP-4444 (sometimes called EIP “all fours”) is the realization of this vision, which allows clients to prune historical data that is older than one year and stop serving it on the P2P level.

Unlike other Ethereum roadmap items, this doesn’t require some deeply technical change to the protocol but rather just changes the guarantees the protocol provides to its users and developers. The only network change is the process in which clients sync with the network, where rather than using a ”full sync” of the entire chain’s history, they instead point to some “checkpoint” within the time range established by EIP-4444 and work their way backwards from the current block. The notion of using some checkpoint and not the entire history comes from an assumption called “weak subjectivity,” which was already introduced through the transition to PoS. This is due to the possibility of long-range attacks, where the churn of new validators means there could be an alternative version of the chain that conflicts with the real chain, and any new validator would have a tough time knowing which is correct. EIP-4844 can therefore fit perfectly under the protocol’s current assumptions, only changing that the checkpoint must be within the time allotted under EIP-4444. It will also introduce a “shim client”: a stripped down version of a full node that can verify the entire chain from genesis.

However, there are likely many actors, including dApp developers, that will want access to historical data that extends beyond a year. This is where external parties come in, who will keep the entire history in order to extend it to those who wish to access it or for their own benefit. This includes altruistic actors, like the Ethereum Foundation and Internet Archive; private organizations, like Etherscan and Infura; and even torrenting services. Again, all it takes is one single entity holding onto the history for things to be completely secure.

Weak Statelessness and State Expiry

Along with needing to download the entire history of the chain, full nodes also need to keep track of the state to know whether transactions have been valid. As more wallets and smart contracts use Ethereum, the state that full nodes need to track grows exponentially larger. Alongside history, state growth is one of the largest bottlenecks to more participation in verifying the network.

There are two major goals when it comes to dealing with state growth, weak statelessness and state expiry. Weak statelessness refers to the goal of only using state to build the block but not verify it, and state expiry refers to removing state that has not been accessed for a defined period of time. These are both compromises to full statelessness, which would either be weak statelessness where block builders don’t store any state or state expiry with a zero time-to-expiry, a feat that is much more challenging to incorporate.

To achieve weak statelessness and state expiry, Ethereum will need to use witnesses: short proofs that show a value (or group of values) is at some position within the Verkle tree, where the verifier only needs to have the root. These will be included in every block to show and prove to the proposer the specific pieces of state that are altered in their block. This allows validators to keep track of state changes and verify them without needing to download all of the state themselves.

While lowering the storage requirements, weak statelessness will increase the bandwidth requirements as nodes now need to download the witnesses. It will also allow for the increasing of gas limits since it becomes easier to utilize bigger blocks, and fits in nicely with Danksharding and PBS, where block builders will already be entities with large resource loads.

For state expiry, the current proposed implementation looks like this:

There is a state Verkle tree with a defined time period for utilization (currently set at one year).
When a new period begins, an empty state tree is initialized, and any updates to state will be recorded in that newly created tree.
Only the current tree can be modified, and full nodes will be expected to hold onto the two most recent trees so at least one year of state can be read without needing a witness.
To revive expired state, a user must submit a witness to have it reactivated.

State expiry should reduce the state that nodes need to store by 20-50 GB in total.

However, in order to actually implement state expiry there are a few requirements. First, the spec hasn’t been fully figured out yet, but a potential roadmap has been highlighted by Vitalik. Within this is the need to update the size of addresses from 20 bytes to 32 bytes and a new address format that includes “address periods.” This is done to avoid collisions, add data about the state’s time period, and fill new storage slots without needing to provide witnesses. There also needs to be further exploration into how expiring states will affect certain applications and working with teams to show them how they can adapt.

Serial Harmonization

One important element of computer science is called serialization: the format in which complex data is stored and transmitted. Ethereum’s execution uses a serialization called Recursive-Length Prefix (RLP), which encodes the data in a way that's then easy to reconstruct after the fact. The consensus layer, on the other hand, uses Simple Serialize (SSZ) which is a different serialization that is meant to be Merkleized (i.e. turned into a Merkle Tree). RLP was deemed unsuitable for the consensus layer due to its complexity, and the idea behind serial harmonization is to have both the execution layer and consensus layer using SSV serialization. Even Vitalik, the creator of RLP, said that RLP is not very good and was very much in favor of using SSV instead for execution. This upgrade is currently scheduled to be a part of the Cancun upgrade later this year,

Final Thoughts

Ethereum’s goal to become the most decentralized and robust network cannot be achieved without hitting these roadmap milestones. Giving light clients greater efficiency and power via Verkle trees and SNARKS, while reducing the requirements of full nodes via history and state expiry should make participating in the network as easy and as cheap as possible while removing technical debt. In addition, including SNARKs across many different areas of the protocol will help exponentially increase the efficiency and capabilities of the network, including swapping the current execution layer for one or many enshrined rollups.

Ethereum Roadmap Part 3: The Verge and The Purge

Active Subscription Needed