Defending Beamchain & the Ethereum Roadmap | Justin Drake

Bankless Nation, I just got off my flight back from Bangkok from DEV CON, where we all had a fantastic time throughout the week of DEV CON talking to all the nerds, learning about the future of Ethereum and about all the ways that Ethereum is changing the world. And on the last day of DEF CON, the day after DEF CON Saturday, we hosted the Bankless Summit, which had 10 speakers, all giving their most interesting, their most fascinating talks possible. That is what I charged them with, and all of the speakers rose to the occasion. We recorded all of those talks, and we are going to be releasing those talks on the Bankless podcast feed and on the YouTube slowly over the next few weeks. You are about to go hear Justin Drake's talk, which was a reflection of his talk at DEF CON, the Beam Chain talk, adding in some additional much-needed context that I think he wished he had introduced the first time when he introduced the Beam Chain at DEV CON, along with many other facets of the Ethereum roadmap. There's also Peter Van Valkenberg's talk, which is gonna come later, as well as Arjun Bapani's talk from Connect's, some of the most interesting, fascinating talks that I've listened to in this space. We got a ton of positive, amazing feedback from the Bankless Summit. So thank you to all the speakers who worked so hard putting their talk together. The audience loved it. We had a packed house. I'm looking forward to the next Bankless Summit whenever Dev Connect is announced. But meanwhile, while you wait, we'll serve you up all the talks from this year's Bankless Summit, the first ever Bankless Summit. So let's go ahead and get into that first talk from Justin Drake. Right now, but first, a moment to talk about some of these fantastic sponsors that make the show possible.

Justin Drake is gonna make you very bullish. Justin Drake!

Yeah, so I'm being sandwiched by uh Eric and Max, front run by Eric, um, and then back run by Max. Let's see how it goes. So I'd like to share some takes about the roadmap. Um and just as a point of disclaimer, these are my takes. These are not official EF or roadmap takes or anything like that.

So, one of the things that as a researcher is getting me really, really excited is that I think we can take what is possibly humanity's most ambitious distributed systems roadmap and complete the whole thing within the next five years. And this is kind of what I wanted to try and communicate

to an extent three days ago with the beam chain.

And basically, what I'm suggesting is that we take the hardest items in the roadmap, those that are very, very difficult to do incrementally in the short term, and kind of batch them in a single fork.

And there's been kind of different pieces of feedback. On the one hand, I've had amazingly positive feedback from the devs.

And many, many people emailed the email address, many people message me on Telegram and on Twitter and things like that. And today I'm kind of very pleased to share, kind of somewhat astonishingly, that we have five new teams that have signaled interest in building a beam client. And so from the perspective of devs, I think there's a lot of excitement to participate in this new journey.

But one of the things that have happened is that on crypto Twitter, the feedback was much more mixed. In particular, this is possibly like my most hated slide ever,

which is basically saying that it's gonna take roughly four years from 2025 to 2029 to ship this extremely ambitious fork, and people want things in the next four months, not the next four years.

And basically, I think the attitude of crypto trader is that we're gonna enter this period of darkness. We have light at the end of the tunnel, but we have a five-year tunnel,

and it's just gonna be full darkness during that period of time. And I kind of want to uh explain that this is not the case. There is not going to be a massive void here between today and five years. There's going to be a ton of stuff happening. A ton of stuff happening.

Now, Ethereum L1 is made out of three sub layers. So there's the execution layer in purple, the data layer in yellow, and the consensus layer in green.

And what I'm gonna do is kind of go through them one by one and try and share some of my takes.

But I think the key message that I want to share here.

Is that the performance of Ethereum over the next few years is going to increase incrementally and it's going to be night and day. We're going to improve all the performance metrics that are key to the layer one.

So, what are the performance metrics for each? For execution, the key performance metrics is gas per second. How much can we churn through the EVM? For data, it's bytes per second or blobs per second.

And one of the key performance metrics for consensus is latency. Like how fast does it take for a transaction to be confirmed? And over the next few years, we're going to improve these three performance metrics.

Now, for execution, the magical tool that we're going to use is ZK.

And one of the tweets that kind of reflects this bullishness that I have is from John Gibbas. John Gibbas is one of the co founders of Succinct behind the SP1 ZKVM. And what he tweets is that we're going to prove the entirety of Ethereum on these bad boys. And these bad boys are like four filio machines.

Like four basically big big server machines, and he believes that's enough to prove the entirety of Ethereum.

And on one piece of interesting metadata here is the number of retweets.

This tweet, which is extremely, extremely bullish, got two retweets. People don't realize what is coming here.

And so, what uh myself and various others at the Ethereum Foundation are doing is building a new website. It's not live yet, but it will be called eefproofs.org. And this is basically a block explorer for ZKVMs. So we're gonna invite every single ZKVM vendor

to prove L1 EVM blocks, and for each block to provide a proof and disclose how much time it took them to generate the proof and how many cents it cost to generate the proof. And then basically, the idea is to show the world that these ZKVMs are good enough for production.

And also create a little bit of a friendly competition between the ZK VMs with various leaderboards so that we uh we'll be able to see which ones are the best.

And ultimately, what I think will happen is that this is going to kick start um

a process where the whole Ethereum chain is going to be ZK proven by many, many different ZK vendors.

Now, one of the things I'm excited about snockifying the entire uh chain, EVM chain, is that I won't have to run Gef.

So I run a validator at home

and I have to run Gef, and I only have two terabytes of storage, and it's a massive pain when I have to resync and it uses too much space and it might use too much RAM or CPU. Well, very, very soon, I won't have to run Gef at home. I can run basically the ZK version of my execution client, for example, ZKGEF instead.

And what that means is that it will consume zero gigabytes of storage. And it will use 0% of my CPU and 0% of my RAM. It's going to be free to basically run an execution client.

And so I think in a couple of years' time, we're gonna be in a position, as I said, where the exit running an execution client is gonna be optional as a validator.

And in order to achieve that, we need the SNORC proving to be fast enough. We need the SNORK proofs to arrive to the attesters soon enough that the attesters can confidently vote and know that the chain is indeed valid. And so for that, we're gonna need sub slot ZKVMs. We're gonna need ZKVMs where the proof comes within one slot, and that means within 12 seconds.

And I think that's going to happen by the end of next year.

By the way, all of the dates that I say take it with a grain of salt, all of this is just a tentative Strowman timeline.

And then another thing that is gonna make this uh state of affairs really good is actually a proposal by uh the next speaker

and Dan Robinson to delay the state routes by one slot. So if we delay state routes by one slot, then now we have the full slot in order to be able to prove the validity of these state routes.

Okay, that's all great. Now, another thing that snarks are gonna do in the in the roadmap.

Is kind of reshuffle and maybe pivot the stateless approach. So right now we're on a vertical approach. And basically, I think what's going to happen is that we're going to move towards SNARK-based statelessness.

And so one of the cool things that have happened in the last few weeks is basically the devs coming together and saying, hey, maybe we can skip verkle and go all the way to the end game in one go, which is to use binary Merkle trees. And that has two advantages. Advantage number one is that it's it's much more snark friendly. And two is that it's post quantum secure.

And so all of this is just basically accelerating the um the roadmap around SNOC efication.

Now, I promise that I that uh you know we're going to see massive, massive upgrades to the performance metric. And the one of the key performance metrics that we have today is the gas limits. 30 mega gas per block. And I think we're gonna grow that 100x.

Within the next few years to three gigatts per block. Now, how can we do that safely?

One of the key things to realize is that we would need all of the execution clients to be able to keep up with the three gigagatz. And there's kind of two strategies. Strategy number one is that you're a home validator and you no longer run GEF. You know, you run the ZK version of your execution client, and verifying a block that consumes three megagas or three gigagas doesn't matter because it always takes one millisecond to verify the proof.

Or the other approach is that if you want to naively re-execute everything, then you're going to need a very beefy computer. And that's something that maybe the big operators can do. The big um safety feature that we need to chip first before doing these big 10x gas limit increases is to have something like multidimensional EIP 1559. And the reason is that.

The only thing that we can increase is the gas limit for execution, but we can't have blocks be too big. So we need to have a separate limit for core data. And we can't have the state grow too fast. So we need also a separate limit for state growth. So once we have these three different limits, we can have the first two stay relatively small and reasonable, and then basically pump the raw execution gas limits. And by raw execution, I mean just things like arithmetic operations, like additions and multiplications and things like that.

Now, not only can we scale the EVM horizontally and grow the gas limit by orders of magnitude, we can also scale the EVM horizontally. And

the idea here is what I call programmable execution sharding, or another way to say it is programmable native rollup.

So once we snarkify the L1 EVM, we can expose within the EVM a ZK EVM precompile. And this is something that any developer can use to spawn a new instance of the EVM.

And I think this is something that can be done, you know, maybe four years down the line, before the five year deadline comes.

Okay, so that was execution. We can essentially have unlimited uh gas per second, right? Because we have an unlimited number of EVM instances, and even individual EVM instances will grow dramatically in throughput. Now, what about data? The story with data is actually fairly straightforward.

Um, we have roughly one fork per year. Um, so the fork items are the one with the little red circles.

And every time there's a fork, I imagine that we're gonna see an increase in the number of blobs. And that we're going to see an exponential increase more or less. So it's a 2x thing every single time. One of the big unlocks is going to be PDAS,

where we start doing data availability sampling, where the validators don't have to download all of the blobs, but they only have to download these small challenges.

And then the way that we do sampling is also going to improve with the 2D sampling here. But overall, the story is that we're going to have exponential growth over the next few years of the data, and that's going to allow for many, many more transactions on chain.

And not only are we going to go to 128 blobs per block, but we can go way beyond that. And the reason is that we have Nielsen's law, which is basically the increase of the natural increase of bandwidth over time, rough on the order of roughly 50% per year.

Now,

here in the in the in the data section, I want to correct or I want to share at least my opinion.

On various things that people say that I I strongly disagree with. So a bunch of people say DA is abundant. I don't think DA is abundant. I think DA, and by DA I mean like the highest quality kind of Ethereum grade DA is not abundant. And the reason is that Ethereum limits itself to home internet connections. And