The Ethereum Roadmap 2025

January 5, 2025

In the last article, we covered a brief history of the Ethereum blockchain, but we’re looking at the road ahead this time. During the DeFi summer of 2020, amidst the yield farming hype, Ethereum became virtually unusable because of insane gas prices. For a while, transacting on Ethereum was only realistic for “whales” who could afford the fees.

However, it was all the network congestion and high transaction fees that inspired Ethereum’s Rollup phase. Now, Ethereum is moving forward from the Beacon chain towards the Beam fork, and Ethereum researcher Justin Drake has some strong recommendations on what needs to be included.

The Beam Chain Upgrade

During podcast interviews on Bankless and The Defiant, Drake discussed some items described in Vitalik Buterin's Roadmap diagram. However, Vitalik’s Roadmap is for researchers and thus highly complicated. So, Drake simplified this Roadmap into a more digestible format for those outside the research and development community.

Some of Drake’s suggested upgrades could be accomplished incrementally within the next few years, which leaves four big-ticket items that need to be brought on the mainnet on the Beam fork. This article will cover these proposals as they pertain to Ethereum’s Consensus, Execution, and Data Availability layers.

Upgrades to Ethereum’s Consensus Layer

First, there are the upgrades specific to the Consensus layer. This is where Validators vote and agree on the tip of the chain. The Consensus layer is all about health and maximizing robustness; it's not about performance.

Two incremental change proposals are censorship resistance and isolating validators. To better understand these proposals, let’s first look at the basics of Ethereum block production.

The Ethereum network produces a block of transactions every 12 seconds in periods called “slots.” The block in each slot has a single Validator that serves as the Proposer, while many Validators serve as attesters to all the information in the block. So, a block proposer is an individual Validator who is pseudo-randomly chosen for each slot to propose the corresponding block.

Furthermore, Ethereum block rewards serve as a mechanism to incentivize the Validators who propose blocks to engage in proper behavior. When a Validator proposes a valid block that other Validators subsequently attest to, they receive a block reward.

Proposals for Ethereum’s Consensus Layer

1. Censorship Resistance
Drake recommends that even if the current Proposer, winning Builder, and Relay decide to censor, Ethereum can still get transactions on the chain. The best proposal for this is called Fork-Choice Enforced Inclusion Lists or "FOCIL".

Ethereum will have 16 different Validators in any given slot that propose inclusion lists. These lists contain transactions that have to be included in the next slot by the next Proposer and Builder. So, even with high centralization at the Builder layer, Validators could still force transaction inclusion on chain.

2. Isolating Validators
Isolating Validators from the centralizing forces of the Maximal Extractable Value (MEV) pipeline would eliminate the timing games They play when they try to delay signing the top bid to squeeze out a little more MEV.

Even blindly signing this top bid can lead to sophistication. So, isolating Validators reduces the sophistication required for them and should improve the health of the network.

Smarter Issuance and Overpaying for Security

Two more suggested improvements have to do with smarter issuance and overpaying for security.

1. Smarter Issuance
The issuance curve is forcing rational ETH holders to stake, leading to a very high percentage of ETH staked. Unfortunately, too much staked ETH presents potential negative externalities.

One problem is that ETH may lose its dominance as a unit of account. In other words, we might see wrappers around staked ETH (like stETH from Lido) dominating raw ETH. These wrappers dramatically weaken the credible neutrality of the underlying asset because they add new security assumptions that could be contract bugs. There's also a branding issue when these staking protocols become brands like stETH.

2. Overpaying for Security
Another problem is that Ethereum is currently overpaying for security. Ethereum pays for security through issuance, which has a real-world cost. With a constant APR that incentivizes more people to stake, a Tragedy of the Commons scenario results. Imagine if holders staked all the ETH—everyone would be equally diluted by the rewards they get. Since no one would profit, it would not be a desirable end game.

The way that issuance works is with a curve that describes its amount for a given amount of ETH staked. Right now, the issuance curve is always above 2% APR. So even if 100% of all ETH is staked, there would still be a 2% APR in effect.

It's even worse because some user rewards must be sold to pay taxes on the interest earned. Taxation on issuance leads to billions of dollars per year of sell pressure on ETH. Changing the issuance curve to cap the amount of ETH staked to a percentage between 25% and 50% could mitigate such a risk.

More importantly, it makes sense to cap the rewards at the level where Ethereum needs security, nothing more. With stake capping, once a certain threshold is passed, the issuance curve would drop to zero, resulting in no new stakers onboarding.

Fish Staking vs. Whale Staking

Presently, only “whale staking” exists, where a participant needs 32 ETH to become a validator. This pricey requirement is the main roadblock preventing smaller ETH holders from joining the Validator ranks. But what if only 1 ETH was the minimum deposit?

The goal is twofold: reduce the amount of ETH staked while also reducing the amount of ETH required to stake. These two agendas appear to contradict each other. However, one is related to quantity, and the other is related to quality.

Stake capping changes the issuance, but the hope is that those who choose to stake will be the smaller, more decentralized, and diverse solo Validators. If Ethereum gets many solo Validators joining, they would push out some of the bigger Validators because the value proposition of staking would become less attractive for the whales.

To improve decentralization, a smaller Validator staking requirement could be incrementally implemented. Additionally, reducing the issuance lower than the burn would bring down the total supply of ETH, making it ultra-sound money.

Issuance Changes and Liquid Stakers

The next question is, how would the issuance cap affect the liquid stakers’ business model? Stake capping would definitely impact liquid staking tokens (LSTs) like Lido by reducing their revenues. Right now, Lido takes a 10% cut of all of the rewards that stakers get. If there are fewer rewards for everyone, then their revenues drop.

So, although a change to issuance would be healthy, it would also be controversial because it would affect the economics of LSTs.

Big Four Upgrades

Moving on to the four significant upgrades relevant to the Beam Chain:

1. Chain Snarkification
2. Quantum Security
3. Single Slot Finality
4. Faster Slots

I. Chain Snarkification

The idea is that for every Consensus block, Ethereum will have cryptographic proof that the block is valid. Snarkification will allow Validators to only need a Snark proof of the chain.

Take a wallet like Metamask, for example. When users transact with it, they trust an intermediary to tell them the valid chain. Thus, it's a fully trusted relationship. Instead, we could have wallets that verify the Snark directly.

However, to achieve real-time snarkification, Ethereum needs to change many of the internals of the consensus layer to make them snark-friendly. Devs will also need to change technical stuff like the hash function, the signature scheme, and the way Merkelize data is serialized. It would all need to be done, and it would be a big fork.

Trustless Bridge

Another interesting use case is trustless bridges between Layer 1s. We could use Snark proofs to build a trustless bridge between Solana and Ethereum or Bitcoin and Ethereum.

Let's say that a user wants to bridge their BTC on the Bitcoin blockchain to Ethereum. Today, this is done using a trusted bridge like BitGo, which creates Wrapped Bitcoin (WBTC). However, all the funds could disappear one day because BitGo could theoretically steal them.

Ideally, users need a bridge where they don’t need to trust any entity. In order to do that, we need Ethereum to be aware of Bitcoin and Bitcoin to be aware of Ethereum. Because blockchains are resource-constrained, they can't just run a full node of Ethereum on Bitcoin. However, a node could potentially verify a Snark proof on Bitcoin that proves the state of Ethereum.

So that's Snarkification, and the next upgrade is Quantum Security.

II. Quantum Security

This is the second significant upgrade to ensure that advancements in quantum computing don’t break Ethereum. In 2024, we saw massive breakthroughs in Quantum Computing. One of the leading experts in the field, Scott Aaronson, who was skeptical that quantum computing would come to fruition in his lifetime, now says that because of some breakthroughs this year, we could likely get practical Quantum Computers within the next 10 years.

Future quantum computers will eventually crack much of the cryptography we use today. Since upgrading Ethereum’s cryptography will take many years, now is a good time to start working on it.

III. Single Slot Finality

The third big ticket item is Single-Slot Finality, which means that a new block is finalized at every slot. So, the throughput is one block per slot. But the latency is three slots, meaning that the slot where the block gets finalized is actually three slots old.

There is also the matter of "chain reorgs." Reorgs happen when blocks posted on-chain are rolled back, and a new history is written.

More concerning is the notion of “deep reorgs.” Imagine the potential damage if an attacker was able to rewrite a large chunk of Ethereum’s history. To prevent such rewrites, Ethereum has "economic finality." It ensures that if an attacker tries to do these deep reorgs, they will lose a lot of money. It is a massive defense against deep reorgs.

Unfortunately, the tip of the chain (meaning the most recent part of the chain) is still subject to reorgs. So, the fastest finality limits the opportunity to reorg to just a few slots at the tip of the chain. Faster finality shrinks the part of the chain (that is subject to these reorgs) to three slots. Hence, lowering slot time is about reducing the depth of the reorgs.

Today, finality takes more than 10 minutes. However, this time lag affects the UX, especially when depositing funds into exchanges. If a user deposits funds into an exchange, they may have to wait until the chain finalizes, which can take a long time.

Finality also affects Layer 2s, which have a mechanism to force-include transactions. They can only safely force-include those transactions after the chain is stable, which means waiting for finality.

IV. Faster Slots

This fourth item is the idea of having faster slots. Today’s Beacon Chain wasn't designed with a “performance first” mindset. Twelve-second slot times were chosen when designing the Beacon Chain. This chosen number was conservative because researchers didn't know the exact number of Validators they would have, nor could they predict how the network would behave with a large number of Validators.

Currently, Ethereum has a million Validators, and 12 seconds is more than adequate to comfortably handle all of them. The good news is that over the last five years, researchers have discovered more optimizations that allow Ethereum to reduce this slot duration while still allowing Validators to work from slower internet connections with high latency.

Ethereum’s strategy is to keep the slot durations relatively high, between 4 and 8 seconds (or even the current 12 seconds), and focus instead on Pre-confirmations.

Picking up the Slack with Pre-Confirmations

A Pre-confirmation is when a user sends their transaction ahead of the slot boundary to the next Proposer and asks them to promise to include it at the slot boundary.

Adding Pre-confirmations as part of this next upgrade would confirm users’ transactions in the time it takes to ping a Validator. So, if the user is 100 milliseconds away from the Sequencer, the total roundtrip latency would be 2 * 100 milliseconds or 200 milliseconds.

Solana’s Short Slot Times

Chains like Solana compete for extremely short slot times. This leads to faster confirmations and better UX. However, the downside is that it’s harder for a Validator to join in—especially for those working from a slower home Internet connection. Thus, short slot times ultimately weaken decentralization.

However, Pre-confirmations allow Ethereum to have better UX than Solana because slot durations can be reduced to milliseconds while maintaining the decentralization that keeps Ethereum unique. So, even a Validator in a rural area with high ping times could still participate.

Regarding the proposal to reduce slot times to four seconds, that reduction is just picking off the low-hanging fruit that the devs didn't get when designing the Beacon chain.

Pre-confirmations - No Upgrade Required

One thing to stress about Pre-confirmations is that no upgrade is required to make them operational. The Ethereum team can do it on the network as it exists today. It has been a massive effort all of this year to get these Pre-confirmations operational, and on November 15th, the very first Pre-confirmation landed on Mainnet.

Furthermore, they’re already implemented for almost all Rollups. Arbitrum has 250-millisecond Pre-confirmations. The Superchain, which consists of OP mainnet and Base, has 2-second Pre-confirmation times. What will happen is that most transactions will move to Layer 2s, and all of the Layer 2s will have Pre-confirmations.

One challenge is that a centralized Sequencer promises to include a user's transaction in the next batch that goes on-chain. In the context of decentralized sequencing, these promises don't work very well. What is being proposed instead are Pre-confirmations based on crypto-economics. The idea is that the Sequencer would put up collateral that gets slashed if they don't honor their promises.

Layer 2s, Pre-confirmations, and Sequencers

The idea is for the Sequencer to pledge some collateral. So when they make promises, they're backed by collateral like ETH. And if the promise gets reneged, then the Sequencer’s collateral gets slashed.

Pre-confirmations and Faux Centralization

There's a common misconception that Pre-confirmations are a centralizing force. However, they're actually the opposite. A user who requires a Pre-confirmation only needs to communicate directly with the Sequencer, thereby cutting out the middlemen.

Who are these middlemen? The Builders and the Relays. In a world with Pre-confirmations, we no longer need Builders and Relays. This is important because the vast majority of centralized choke points come from these Builders and Relays. Drake believes that Pre-confirmations are less centralizing than having these two middlemen between the user and the Sequencer.

There is much infrastructure that needs building. For example, there needs to be a registration contract where the Sequencers can deposit collateral. There needs to be a fraud proof so if a user gets cheated by a Sequencer, they can provide cryptographic proof verifying that it happened. And there needs to be a slashing mechanism. All of this is doable and there has been proof of concepts on Mainnet. Drake sees decentralized Sequencers as the future.

That’s what's proposed for the Consensus layer, but the Data and Execution layers also need to gradually evolve.

Proposals for the Data Availability Layer

For the data layer, it's about increasing the bytes per second that can be pushed through Ethereum. And there’s this notion of big data Blobs. Today, the target is three blobs per slot, with the goal of growing that 40x to 128 Blobs per slot within the next five years.

This is known as Danksharding and is not going to happen in one upgrade where Ethereum suddenly increases things by 40X. Instead, think of it as doubling roughly by a factor of two each year until reaching 128 Blobs per slot.

Proposals for the Execution Layer

On the Execution side of things, there is Snarkifying the EVM. The industry is making a lot of progress with ZKVMs. A ZKVM is a piece of technology that allows any developer worldwide to use the power of Snarks without having to be a cryptography expert. So developers can compile their code bases down to ZKVMs, and they will do all the heavy lifting.

Move Slowly, and DON’T Break Things

A myriad of applications depend on the EVM, so it must have forward compatibility. This means that any changes to the EVM must proceed slowly and cautiously so that no one breaks the existing applications.

Once Ethereum devs have Snarkified the EVM, they’ll be positioned to increase the gas limit. The gas limit is there to protect the Validators. But if the Validators only have to verify these uber-cheap Snark proofs, they won't be exposed to the vector whereby an attacker overwhelms them with a very big block requiring a lot of work to validate it.

One of the EVM's big performance metrics is “gas per second.” The question is, how much execution can be pushed through the EVM? The main bottleneck right now is on the Validator side of things.

They have to verify that the EVM blocks are valid. Today, they do this via brute force, which means re-downloading and re-executing the entire block. Thus, the slowest Validator on the network becomes the bottleneck.

However, ZK tech creates a massive asymmetry between the Builders who produce the blocks and the Validators who verify their validity. Things will speed up when they only have to verify a Snark.

Increasing the Gas Limit

By simply removing the possibility of a DOS attack coming through these big blocks, Ethereum can grow the gas limit by 10x or 100x. Again, the reason is that the Validators would only have to verify a Snark, which takes roughly 1 millisecond, regardless of how much computation is involved.

So, there can be Snarkification of the chain and Snarkification of the EVM with interesting implications.

Native Rollups

Once the EVM is Snarkified, devs can expose a precompile within it, which would allow anyone to deploy an exact copy of the EVM as a Layer-2 Rollup, thus allowing the EVM to scale horizontally. Each copy will have its own gas limit. So if we're able to have a gas limit 100x larger than today, that would be 3 gigs of gas per block.

With Native Rollups, the community can have as many EVM copies as it wants. Furthermore, each copy can be customized to have its own fee token, governance mechanism, and its own Sequencer.

The important thing to stress here is that these Native Rollups are programmable. They are not the top-down, centrally controlled type of Rollups. Ethereum is all about programmability, and with Native Rollups, developers get it.

Ethereum Roadmap - Conclusion

Changing the architecture of the Beacon Chain to complete the entire Roadmap to the Beam fork will take four to five years, encompassing from 2025 to 2029. However, even this time frame is ambitious for the developers for such a big fork.

Since one of the main criticisms from the Ethereum community is how long these changes will take, it’s important to note that not all of these changes will require five years. For the Consensus layer, there would be four gradual upgrades before the Beam fork.

These changes are ambitious, and at this point, Justin Drake’s proposals are receiving acceptance from the developers and researchers. But next comes the challenge of winning the hearts and minds of the wider Ethereum community.