Ethereum Roadmap: Will The Surge Enable Mass Adoption?

Ethereum coin with a green chart background

How can Ethereum transition from an emerging technology to become an easily accessible, affordable global computer that achieves mass adoption? With the Merge’s transition from proof of work to proof of stake complete, founder Vitalik Buterin’s attention has turned to planning the next phases of Ethereum’s progress.

The good news: What’s coming sounds amazing–and we should see some improvements before the end of ‘23.

At the same time, elements of what’s envisioned for improving Ethereum may take 10-20 years to build.

What’s coming down the pike soon? Here’s a look at Ethereum’s roadmap update–its goals, the methods that may accomplish those goals, and what it will mean for users.

A look at the updated Ethereum roadmap

Last year, Buterin posted an updated roadmap that shows The Surge’s process to implement full rollup scaling, as well as the proposed stages that follow.

The key goal of The Surge: scale Ethereum to enable it to handle 100,000 transactions per second, a rate that far exceeds the current processing capacity of all traditional credit-card providers. Achieving this requires mass implementation of speedier Layer 2 rollups for transactions.

Transactions done one at a time cannot scale; rollups that bundle them together for faster and cheaper processing will be essential to growing Ethereum.

But during peak usage times, even rollups can be slow and costly, resulting in low throughput capacity. This makes Ethereum unattractive for new users, a problem that has to be fixed to achieve mass adoption. Fortunately, there’s a plan for making rollups more efficient and therefore cheaper.

‘The Surge’ and its potential for growing Ethereum

The next stage of Ethereum’s development–known as The Surge–is intended to increase decentralization, increase throughput, and reduce user costs. In a recent paper, Buterin identified three improvements needed for mass adoption that need to happen more or less simultaneously:

  • L2 scaling with rollups becomes universal, making transactions faster and cheaper.
  • Smart contract wallets will hold both assets and data, improving security.
  • Privacy preservation while implementing the two initiatives above is key.

All three of these elements are needed because without any one of them, centralized options remain the default for many users. For instance, if transactions are too public in how they’re recorded on the blockchain, many users will stick with centralized solutions that offer at least some privacy.

Danksharding for faster rollups

Transactions are expensive, even in rollups, because they need to share all their data to the blockchain which is then permanently stored. That’s inefficient, because much of this data is only needed for a brief time.

One proposed solution to this issue is to program rollups so that not all their information need be shared to the blockchain. That’s the goal of danksharding. This process creates short-term “data blobs” that are used to execute the transaction, but aren’t readable by the blockchain and which expire shortly.

Ethereum developers are focused on launching a first step in this direction. With proto-danksharding, a single data blob is added to rollups to shrink their footprint on Ethereum. Proto- or mini-danksharding experiments are already happening that demonstrate this approach has promise, and the web3 community is watching the progress closely:

Eventually, the hope is to achieve full danksharding with up to 64 blobs per transaction, greatly reducing the amount of data that needs to interact with the blockchain. But that’s not seen as immediately achievable.

There’s also another direction besides danksharding that’s being explored for improving Ethereum’s throughput and affordability. Where danksharding reduces the amount of data in rollups, another path to optimizing Ethereum lies in lightening the workload for the blockchain’s nodes.

The trouble with nodes

Nodes are devices located all over the world that validate and store transactions. One major bottleneck that makes Ethereum transactions slow and costly lies in the way nodes are currently structured.

Right now, every node must retain the entire blockchain’s history, back to the launch of Ethereum in 2015. And the process of node operation grows ever more cumbersome as the blockchain accumulates more data, a problem known as ‘state bloat,’ as shown here:

The ballooning space requirements of maintaining a node make it an unaffordable role for many users. That’s a problem because if you’re not a node operator, you must trust third parties to supply you with data.

Currently, many node operators solve their storage problem by renting space on Amazon Web Services, as this chart of node-hosting solutions shows:

Source: Ethernode

With more than half of all Ethereum nodes stored on Amazon, Ethereum is less decentralized than it could be. If AWS were compromised, it could be harmful to the Ethereum blockchain. This is why making node operation simpler and more affordable is an urgent priority.

We may see some initial steps for reducing node storage requirements soon, but ideal solutions are further out. There are several possible approaches we’ll review below that have varying degrees of difficulty. But Buterin believes more efficient nodes are a realistic goal.

Speaking in early September ‘23 at Korean Blockchain Week, Buterin envisioned a future where nodes could be run on simple devices rather than requiring high-powered, advanced computing:

“In the longer term,” he told Cointelegraph, “there’s a plan to maintain fully verified Ethereum nodes where you could literally [run] it on your phone.”

If node storage needs could be reduced to where they could run on affordable, small devices, it would enable many more users to operate nodes. This would allow more node operators to share the workload, helping to speed up Ethereum transactions. But lightening the node workload to make this possible is a major technical challenge.

There are several ways to simplify node operations and reduce their space requirements. Those options and their pros and cons are described in’s documentation. Let’s walk through the different strategies under consideration:

Let older data expire (history expiry)

Historical data on the blockchain serves two purposes: it’s used for syncing, and serves as an archive for anyone who wants to review past data. Originally, all nodes needed to sync back to the very beginning of the blockchain. Now, nodes can rely on “weak subjectivity checkpoints” to sync to a more recent trusted starting point instead.

This means nodes could theoretically drop all the historical data prior to that checkpoint. But what if a client wants to review it? Currently, node operators can use a local database to grab the historical info. If older data is allowed to expire to free up node space, though, it creates a challenge–the local database may no longer have this historical data.

One possible workaround for this that’s in development is creating a Portal Network in which each node operator stores a different part of the history, distributing the complete history across the entire network. Node operators would then ping the node that has the piece of history needed to retrieve it.

With the Portal Network and other possible solutions still being built, history expiry is not something Ethereum could use immediately. But it’s an approach that could work in future.

Let unused data expire (state expiry)

Some information on the blockchain gets used often, but other blocks are rarely accessed by anyone. With state expiry, little-used blocks would be removed from individual nodes where they’re not getting any access requests. This would happen whether the data is very old or more recent, just based on lack of use.

This inactive data wouldn’t be deleted but archived elsewhere, off the node. If needed, an inactive block could be reactivated. There are several ways state expiry could be organized, including using a similar Portal Network setup to the history-expiry scheme. However, Buterin ranks it as an initiative that may happen later than sooner, as other solutions may alleviate the need to retire inactive blocks.

Pursuing statelessness

In Ethereum, “state” refers to the constantly expanding ledger recording all transactions, including everything that interacts with this blockchain, such as external owned accounts (EOAs). A move to statelessness would mean not all nodes would have to preserve a complete record of everything that’s ever happened on Ethereum.

There are two initiatives around achieving statelessness, known as weak and strong statelessness.

Weak statelessness

This proposal seeks to reduce node workload by splitting the role of block proposer from that of block builder or verifier. Block proposers’ nodes would need to maintain state storage, while all other nodes would not. This separation would allow block proposers to operate high-powered, specialized nodes, while all other nodes would have much lower storage needs.

Instead of maintaining state, other nodes would rely on small ‘witnesses’ to the full data created through a data structure known as Verkle trees. These witnesses take up far less space. The upshot is that proposing a block remains expensive, while verifying blocks becomes cheap and can be done from a smaller node.

Weak statelessness is in an “advanced state of research,” according to the Ethereum community. Nevertheless, due to the needed underlying changes–separating the block proposer-builder roles and the implementation of Verkle trees–they estimate that achieving weak statelessness is still a few years away.

Strong statelessness

With strong statelessness, no nodes would need to store state data. All transactions would be sent with witnesses that are aggregated by block producers, who would then store only the data needed for generating witnesses to their accounts.

In this scheme, the responsibility for maintaining state would move to users, who would each document the accounts and storage keys they use.

Ethereum documentation indicates that while full statelessness has been researched, it’s unlikely this initiative will become part of the Ethereum roadmap, because it’s anticipated that weak statelessness will be adequate to meet the goals of accelerating transaction speed and lowering costs.

Forecast: Big changes ahead on the Ethereum roadmap

With developer teams at work exploring ways to achieve The Surge, one thing is for sure: There are exciting changes ahead that have the potential to create a more decentralized and accessible blockchain for Ethereum. The prospect of a more secure and more widely used Ethereum excites us, and we can’t wait to see what happens next.

Subscribe to updates from the Dragonscale Newsletter

Don't miss out on the latest posts. Sign up now to get new posts sent directly to your inbox.