The Merge is Done! Now What?

The Surge

The first of the upgrade categories also happens to be the most far along. The Surge refers to a surge in Ethereum’s computing capacity using Sharding technology.

Sharding is not a new idea. It’s commonly used to scale databases for resource-intensive webapps, or for the same infrastructure to be used across many different applications more efficiently.

Say you have a database with 1,000,000 rows of information that needs to be processed. There are two ways you could speed the process up. You could increase the computing power available to process those 1,000,000 rows, a process called “scaling up.” Or you could split that database horizontally into five shards, each with 200,000 rows, so you can process the information using five separate machines. That’s called “scaling out.”

The latter strategy of splitting the data into shards so multiple machines can process it at once is often easier technically than continuing to speed up a single machine.

If Ethereum tried to scale up by increasing the processing power of the machines validating the network, then it would become harder and more expensive for members of the community to contribute to the security of the network. It would be a return to the same problem that arises with mining; you’d have to continually upgrade your machine to keep up with the demands of the network if you want to be a staker.

By scaling out through sharding, Ethereum can increase its computing power without increasing the computational demands on stakers. Instead of quadrupling the processing power needed to validate the network, they can start by splitting the network into four shards. Then in the future, they could theoretically increase that shard count to any number, giving dedicated shards to major rollups like Optimism and Arbitrum.

The challenge is how to do this while maintaining Ethereum’s security and composability. The best strategies for achieving that are still being debated, but you’ll likely see pieces of it come together in future EIPs like 4844 that are going to start moving the network in this direction.

Further Reading on Sharding and The Surge:

The Verge

As the steps in The Surge are completed, the size of the historical record for Ethereum will start to swell at an increasing rate. If the processing power is increased 100x through shards, then the rate at which data is recorded to the blockchain will also increase 100x without additional changes.

To run a validator, you must maintain access to the full Ethereum “state,” the historical record of everything that’s happened on the chain. With a full sharding implementation, that state could start growing at 10s of Terabytes per year, which would soon make it prohibitively expensive to maintain a record of it on every validator. You’d need hundreds of terabytes of storage instead of being able to run your validator on a normal laptop easily.

So the solution is to figure out how to move toward stateless network validation so that the processing power can increase and the size of the historical record can swell without bogging down every validator connected to the network. And by moving towards stateless validation, the hardware requirements to validate the network would drop even further, allowing you to run a validator on a simple Raspberry Pi device or a mobile phone.

The core step for achieving this is to shift from the current Merkle-tree-based validation to a newer concept called “Verkle Trees.” Verkle trees dramatically compress the amount of data required to prove the validity of a block based on historical data, which makes them perfect for scaling up efficient validation as the size of the blockchain grows:

The key property that Verkle trees provide, however, is that they are much more efficient in proof size. If a tree contains a billion pieces of data, making a proof in a traditional binary Merkle tree would require about 1 kilobyte, but in a Verkle tree the proof would be less than 150 bytes - a reduction sufficient to make stateless clients finally viable in practice. - Vitalik Buterin, Verkle Trees, emphasis mine

Once the Merkle tree proof system is replaced with Verkle trees, that should be a ~10x improvement in processing power for Ethereum. But that alone doesn’t fully solve the statelessness problem; it only lays the foundation for it. With the Verkle tree system introduced, there can be a new “root” or start for the Verkle trees established, and any state from before that point wouldn’t be necessary to maintain to prove the integrity of the network.

With that done, the network can start to focus on “The Purge.”

For more reading on Verkle Trees and The Verge:

State Expiry EIP
Ethereum Statelessness Roadmap
Verkle Trie for ETH1 State
Verkle Trees
Why it’s Important to Go Stateless
Verkle Trees MIT Presentation (with helpful pictures!)
Verkle Tree Structure
Verkle Trees Paper

The Purge

Once Ethereum has been upgraded to run stateless or near stateless, they can start purging the old state data and reduce the amount of information people need to store to run validators.

The first version of this is to cut down the length of historical data that needs to be maintained by execution clients to one year instead of needing the full history. That has been outlined in EIP-4444 and seems to be a popular first step that’s likely to be implemented.

From there, the current plan is to replace the single state tree with separate trees that each last for one year. So in the vast majority of cases, you never need to work through data older than a year, but it’s still available when needed.

Then the network can implement further changes to prune the state and remove additional features that currently exist in the EVM but aren’t often used or aren’t used properly, like SELFDESTRUCT. The main goal of this portion of the future roadmap, though will depend on getting Ethereum to operate statelessly so this bloat can be removed, and other opportunities to trim the fat will likely arise once it’s started.

Further Reading on The Purge

The Splurge

Finally, we have the splurge, which is just a grab bag of everything else the Ethereum community wants to build into the blockchain that doesn’t fit in one of the three other major buckets. Most of these are also very technical focused and will increase the performance of the chain but won’t likely be noticed by the users of the network.

Some of the improvements in this category include:

Proposer / Builder Separation: Reduce MEV (Maximum Extractable Value) by separating the proposer and builder roles when constructing blocks. Learn more here.

Data Availability Sampling: A method for improving access to data across shards and improving the efficiency of validation proofs. Learn more here.

EIP-3074: An improvement to the EVM that would let externally owned accounts delegate control over the account to a smart contract. Learn more here.

EIP-4337: Another popular EIP, this one focused on account abstraction to remove the need for consensus-layer agreement on protocol changes. Learn more here.

There will likely be many more that end up in this category, and they might be completed ad-hoc as we wait on other major changes to the network from the first three categories.

You probably noticed, though, that none of these changes are as exciting as the huge Merge change. The network is maturing, and with the major shift to Proof of Stake done, Ethereum can now focus on making incremental improvements to its processing power, enabling all of the user experience and application layer innovation to start happening on the Layer 2s that rely on it.

If you’re looking for exciting new projects that are launching, they likely will be on Layer 2s moving forward. Ethereum is getting closer to fulfilling its goal of being the ideal settlement layer for those execution blockchains. As the current Optimistic Rollups and ZK-Rollups improve, we should see significantly more new and interesting tools and apps to try launching there.

The Merge went off without a hitch. Hopefully, the rest of these improvements go just as smoothly.