The road ahead for Ethereum

During Devcon, naturally, devs talked a lot about the future of Ethereum, and how they saw the roadmap. If you’ve never seen the Ethereum roadmap, you can find it here. 

All larger phases are grouped under names like The Merge, The Purge, The Splurge.. Until they run out of names that rhyme. If you’ve been around for a while, you’ll remember the Merge where Ethereum went from PoW to PoS. 

However, the road ahead isn’t as agreed upon as you would assume. 

Instead there are largely two different camps outlining different visions for Ethereum. Outsiders just see that the price hasn’t performed as well as Bitcoin, but the developers are more concerned with Ethereum’s technical performance.

During Devcon, one of the Ethereum researchers, Justin Drake, proposed his vision for Ethereum, which people were quick to dub Ethereum 3.0 

So what’s Ethereum 3.0, and why care? 

First of all, it is currently just a proposal. It will only be established if there’s broad consensus. If anyone is trying to sell you Ethereum 3.0 tokens, you’re setting yourself up for losing money. 

As Vitalik said, the ticker is ETH. 

Ethereum 3.0 aka the Beam chain 

With thousands of dApps and countless Layer-2s already running on Ethereum, it’s execution and data layer are well-used. Therefore, the best layer to make updates to is the consensus layer. 

Remember how in advance of the Merge, Ethereum was running the beaconchain in parallel for nearly a year before making the switch? 

Justin suggests following this playbook by creating a new chain - the beam chain full of all the hard fixes necessary. 

Why now? 

Ethereum ships new updates at a speed of roughly one fork a year. Whenever these occur, they tend to focus on marginal improvements, ticking off low-hanging fruits. Justin believes that’s not enough, as we now have a much better understanding of mechanisms like MEV. At the same time, tech such as SNRAKs and ZKVMs improved significantly. 

It’s not wise to carry along all the technical debt forever.

Instead, let’s put all the latest and greatest items in the consensus layer roadmap that are harder to achieve into the Beamchain and get on with it, so the idea. 

Interestingly, this doesn’t signify a departure from the initial roadmap; it just accelerates it. 

“A quantum leap forward to upgrade the consensus layer in one go.” 

Five years ago, when the Merge was decided, the focus of Ethereum was to guarantee security. Now, it’s possible to design a chain to offer strong security guarantees while providing enhanced performance. Enter the Zk Era of Ethereum. 

What’s in it? 

For the beam chain, Justin suggests: 

• Staking: lowering validator requirements from 32 to 1 ETH 
• Faster slots: shrinking the time in which validators can propose blocks from the current 12 seconds to less 
• Snarkification: everything goes through proving in real time, basically turning Ethereum into a zkVM
• Aggregatable signatures: hash functions guarantee Ethereum becomes quantum-secure 

All of this seems rather exciting without breaking out of the bounds of what’s planned already—accelerationism. It doesn’t quite fit to call it Ethereum 3.0. 

“We're very excited about this proposal. After being in a divergence phase that brought us scalability, but also fragmentation, this convergence phase towards the principle carried by zkEVMs will allow our ecosystem to look like a coherent ensemble, for software developers and users. " - Joe Lubin

What would change for builders? 

One reason Justin suggests making changes on the consensus layer first is not to make breaking changes in the layers dApps heavily rely on at the moment. 

Faster finality might have the added benefit of providing a better transaction experience. Knowing your transaction is final faster is good for users and devs. At the same time, it doesn’t make much difference in the speed at which the blockchain state grows. That is governed by gas limits per block and storage costs. 

However, if your dApp requires staying on top of the latest chain state, reducing slots and finality time will probably lead to a need to query more frequently. 

But not everyone agrees with this vision for Ethereum 

Martin Köppleman, gnosis Founder and Ethereum builder with over 10 years of experience, also took the stage to outline why he thinks the beam chain isn’t enough. 

After going over the shortcomings of the current L2 landscape, namely that they are indeed parasitic to Ethereum in that they capture value and don’t contribute much. 

His suggestion is the development of native L2s zk-proven EVM equivalent rollups. These are much closer to mainchain and would offer benefits that current L2s can’t, such as: 

• Completely remove the possibility of being governed by bad multi-sig setups 
• Independent proof systems 
• Rigorous testing, and scrutiny applied to all the changes made to Ethereum 
• Actually, be Ethereum-secured

While it sounds similar to sharding, it’s not quite that, but with 128 instances of such zk-Rollups on Ethereum, it would get as close to the sharding roadmap as possible while staying within the current constraints. All of this is possible without making any changes to the underlying L1. All it takes is the community to come to consent.

Why does Ethereum need native rollups? 

For one, it’s become something of a meme that all these L2s claim to onboard people to Ethereum when, in fact, they do onboard them to their L2s. 

One example highlighted in the talk is that of Base. Currently, it’s spearheaded by high-integrity individuals. But it’s still run by a company, and they are employees….

There’s no guarantee that the status quo persists. There’s a universe in which, eventually, for the sake of shareholder value, fees are implemented once sufficient projects are locked in. Since they have a centralized sequencer, they control what happens on their Layer. 

That’s not to say it’ll happen, but it’s not impossible. One way or another, the biggest argument for native Rollups is maintaining the relevance of the Ethereum L1. It would provide a more Ethereum-aligned path to rollups, without hindering the success of others. 

It’s about optionality and ensuring that rollups secured by ethereum don’t turn into more of a meme than they already are. 

What would change for builders? 

In the case of native EVM rollups, you’d have plenty more options to build on, and chances are this would benefit the user experience while increasing security guarantees. It’s also EVM so not many changes if you know your way around Solidity. 

Composability within such a system of native rollups would be very strong, allowing synchronous reads of the L1 from an L2; for example, you could use a data point from the L1 as input in your contract on L2. Across these rollups, write operations would be synchronous, creating great opportunities for cross-rollup interactions. 

Now what? 

Now you know the two different standpoints that people in the Ethereum camp hold for the future of Ethereum. Some believe we should just continue with business as usual, while L2s capture most of the value - others argue that it’s time for more drastic measures. 

Modern problems, modern solutions. 

As it stands, both are just proposals out in the open for the community to voice their opinion on. Considering the rigorous testing and long discussions surrounding any change in Ethereum, there’s no immediate conclusion. 

It’s business as usual. But if you find either of these proposals enticing and are building on Ethereum, might be a good time to get involved. 

You can find the talks here: 

• Beam chain 
• Ethereum needs native L2s 

If all you care about is ensuring you still get all the onchain data you need, SQD is able to support whatever direction thenetwork goes in. 

To discuss all that and more, join our telegram.