Ethereum is a protocol undergoing significant changes. In the medium term, we are pushing to upgrade the protocol so it can scale to meet global demand, while also improving security and decentralization. It’s a long and winding road to get there, but our bazaar of researchers and tinkerers is more active than it’s ever been.

Before starting, remember that this is not an “official” roadmap, and represents a limited, subjective view of where things stand.

👉 Note: If you need to get a better understanding of the technical terms used in this article, please reference the Consensys Blockchain Glossary.

The Names have changed

Timeline → Ongoing

Let’s talk about what we call things. While it may seem strange to start here, remember that naming frameworks are informed by roadmaps. Below are two examples of recent changes to popular terminology, as well as the reasons for the change.

Execution and Consensus

For all intents and purposes, the terms “Eth1” and “Eth2” are no longer used in core development—see Tim Beiko’s “Great Renaming” doc. 

The old naming scheme suggested two issues, namely that “Eth1 comes first, and Eth2 only after” and that “Eth1 will cease to exist once Eth2 exists.” Danny Ryan has previously pointed out the issue, starting in Oct. 2020. Even though the Beacon Chain has been running alongside mainnet since it launched, using Eth1 and Eth2 suggests that the earlier version goes away at some point. In reality, the chain-state will be seamlessly wedded to the Beacon Chain with the Merge.

No data will be lost, no migration is required.

Instead of Eth1 or Eth2, we’ve shifted to “execution” and “consensus.” I recommend you read Danny’s in-depth post here. In short, execution refers to all things at the user layer: applications, account balances, tokens, etc. This can also be referred to as the “state.”

Consensus is then the Proof of Stake mechanisms that bind everything together: finality, the fork choice rule, validators, and incentives.

In a post-merge environment, both of these layers coexist together.

Features, not Phases

Phases are another term we’ve moved beyond. In the past, they referred to a specific protocol change, e.g. “Phase 0 is the Beacon Chain.” 

Late last year, there was an informal, gradual reframing of “phases” to “features.” To start, using “features” is more flexible. When designs are updated or scope expanded/reduced, it’s harder to communicate that the shorthand “Phase X” has changed instead of just calling it by the name of the feature proposal.

Second, and in keeping with the “Execution and Consensus” section above, it indicated sequentiality: that “Phase X” must be followed by “Phase X+1.” A good example of this not working in the current timeline is with The Merge (previously “Phase 1.5”) being prioritized ahead of Data Sharding (previously “Phase 1”).

Biasing towards “features” means names are atomic, easily reordered when needed, and more clearly communicate their ultimate impact.

Epistemic Flexibility

More abstractly, I like to think that both of the changes above are grounded in an epistemic flexibility—epistemic means “related to knowledge or knowing.” In other words, it’s a flexible mode of knowledge formation that allows our community to better comprehend the unstructured creativity produced by the bazaar.

We are able to make adaptive decisions about a roadmap because we’re not locked into phases or sequentiality. There’s humility in acknowledging and internalizing that we don’t have complete maps of the territory. This is an important part of Ethereum philosophy, and I’m glad to see it put down stronger roots.

It may take a while for the broader community to adjust to new naming norms, but we’ll get there! Thanks in advance for helping us out with this important effort :)

The Merge

Timeline → 5-8 months

Now that we’ve addressed naming, let’s talk about the next exciting Ethereum feature: The Merge. This refers to Ethereum’s impending switch from Proof-of-Work (PoW) to Proof-of-Stake (PoS). 

It’s one of the most widely anticipated protocol changes for both Ethereum as well as the broader crypto space. For much of our industry’s existence, PoW and its negative perceptions around energy consumption have dominated popular media. Ethereum will be the largest protocol ever to hot swap its consensus mechanism, and in turn, hopefully change the narrative.

Benefits to the Protocol

The Merge includes many major improvements to the protocol:

• As soon as the upgrade goes live, the chain becomes more secure. Blocks become “finalized” after a certain point, introducing slashing disincentives for chain reorgs by validators—i.e. validators reorganizing blocks or their internal transactions. 
• Second, PoS removes the immense energy consumption and hardware waste  associated with PoW. Researchers estimate that Ethereum’s energy use will drop by up to 99.95%. A tiny fraction of regular commodity hardware will replace the current set of ASICs and GPUs that currently run Ethereum consensus. These two effects will lead to a more energy-efficient, diverse, geographically distributed, and antifragile set of consensus participants.
• Third, Ethereum PoS sets the stage for sharding, a similarly significant protocol change that will separate the chain into many concurrent threads. Sharding supercharges L2 scaling efforts by increasing the blockspace available for data availability and settlement.
• Fourth, ETH priority fees that currently go to miners will instead go to a validator-controlled address on the execution layer. This means the ETH is immediately liquid. Given that full withdrawals of staked ETH will only go live in the Shanghai upgrade later next year, this is a significant improvement for validators with locked-up capital.
• Finally, the upgrade will reduce annual ETH issuance from the current net-3.5% to roughly net-0%.

The Path to the Merge

The first major event laying the foundation for the Merge was Rayonism, a month-long hackathon earlier this year. This effort simulated what the chain would look like after the Merge happens as well as how consensus / execution clients will talk to each other.

More recently, we had the Amphora interop. This week-long event continued to build on the success of Rayonism, but adding the crucial moment of transition from PoW to PoS. 10 client teams contributed, and by the end of the week, a devnet modeling the transition had been successfully run!

If you’d like to learn more about both events, check out Tim Beiko’s post “Amphora: A Major Merge Milestone.”

The learnings from that event have been incorporated into the latest release of the Merge specs, called “Kintsugi.” Concurrently, there is a long-lived devnet called Pithos. This will restart a number of times throughout Q4’21-Q1’22 to retest the moment of transition from PoW to PoS with the updated spec. Once this transition is reasonably stable, existing testnets like Goerli can be upgraded to match the spec.

Interested community members can follow along with "The Merge Mainnet Readiness Checklist, a comprehensive overview of the remaining tasks.

Shanghai Upgrade

Timeline → 10-12 months

One of the interesting things about Ethereum post-Merge is that though the chain ends up merged, the clients remain independent. This includes how they are architected, as well the teams that work on them. For validators, this means an abundance of choice. Each execution client can be combined with each consensus client, and vice versa, in every permutation. For fun, I put together a list of possible names for these combo clients here.

Independent execution and consensus layers also allow for uncoupled upgrade processes when needed. This nicely slots into the Ethereum philosophy of separation of concerns. In other words, several smaller changes are usually more manageable than one monolithic one.

However, the Shanghai upgrade will couple changes to both layers in order to make validator withdrawals possible. This allows validators to exit their ETH from the consensus to the execution layer, binding them together even more closely. Once the ETH is exited from the Beacon Chain, then it can be used just how people use it today: as a store of value, to pay for NFTs, or pay transaction fees. There are many other proposals being considered for the execution layer, but nothing has been formally accepted into Shanghai.

We won’t know the acceptable scope until we get much closer to the Merge actually going live.

Ethereum Research

Timeline → Ongoing

While the above is being specified, implemented, and tested, there are other parallel research efforts pushing Ethereum forward.

Data Sharding

After the switch to Proof of Stake, sharding is probably the most significant upcoming change to Ethereum. Note that current proposals are focused on data sharding, and not execution. This feature gives L2s much more blockspace to store data, but it wouldn’t support native user transaction execution like we’re familiar with on mainnet. Rollups today currently use Ethereum for this type of settlement operation. Foundational research for this type of sharding is less complex, meaning it can get to mainnet and supercharge L2s even faster.

Prioritizing data availability is in line with where scalability research and applications have already been moving over the past 18 months. A good crystallization of this possible future is spelled out in Vitalik’s Oct 2020 post “A rollup centric ethereum roadmap”. This is a nice example of epistemic flexibility in the wild!

At some point in the future, the community may decide to add sharded execution.

This remains an open research question.

State Expiry & Weak Statelessness

This area of research will reform how the protocol handles state. State refers to all user records, including contracts, tokens, NFTs, and addresses. In Ethereum today, users incur a one-time cost per transaction to remain in the state indefinitely. Long term, this is not sustainable.

Several proposals with different tradeoffs have been explored over the years, including things like state rent and ReGenesis.

One leading proposal is called “Weak Statelessness.” This changes the way Ethereum nodes hold and process state. Specifically, only block proposers would be required to store state, while all other nodes can verify blocks statelessly. Here’s how it would affect different user profiles:

• Users: Can discard state, but need to submit a “witness” along with their transaction. Witnesses are proofs that are sent alongside a transaction to prove that it is valid
• Non-Validator nodes: Can discard state
• Validators / block proposers: Can discard state if relying on a third party for block production
• Block Producers: No change, still need all state. Uses witnesses from users to craft blocks that contain valid state changes

The companion proposal is called “State Expiry.” Here, state can become inactive, or ‘expire’ from the active state, if not accessed within a set period. This could be ETH in cold storage or abandoned ERC20s a community migrated away from. If a user wants to reactivate their state, any sent transaction needs to be accompanied by a witness. One benefit of limiting the active state size is that nodes should be more manageable to sync and maintain.

Both of these concepts are being actively researched, benchmarked, and implemented with Proof of Concepts. Dive deeper into current progress:

• Link roundup from Guillame Ballet
• Links from the EthR&D Discord Guidebook

… and so much more

There’s so much more that I could write about, like EVM improvements and ways to harden consensus mechanisms, but we’ll save them for another post.

If you’re interested in working on these important problems, DM me for an invite to the Ethereum R&D Discord.

Or, you can dive into the long-form EthResearch forum.

🙏 Thanks for reading, and to Danny Ryan, Tim Beiko and Mario Havel for reviewing.