Guide to the Ethereum Roadmap | Jon Charbonneau of Delphi Digital

Welcome, Bankless Nation, to a very special episode. I'm super excited to bring you on today's State of the Nation. State of the Nation is where it comes out every Tuesday on the Bankless Live stream and then every Wednesday morning on the RSS feed, where we relate it to big picture action items. We drop some insights and action items, and I'm happy to bring you some awesome, awesome alpha coming out of a research analyst out of Delphi Digital. We're talking about the Ethereum roadmap beyond the merge. In some ways, the merge feels like the finish line for much of Ethereum's history, but there is still so much left to do. You might have heard of things like bank sharding or data availability sampling or proposer builder separation. And you might have thought, wow, that's really complex. I might not ever understand that. And you might be right about that. And that's, and I'm sure that we are not totally we are not going into the full math about some of these things, but we are going into some of the shared themes and shared strategies that each of these complex mechanisms have for the future of Ethereum beyond the merge. There's this common structure to all of these things, uh, and it has to do with harnessing complexity and the separation of powers to make Ethereum scale computation while remaining decentralized. So today on the show, we're bringing John from Delphi Digital, who wrote a fantastic research report phrased by some of the uh uh leading Ethereum researchers, Tim Bako, Paulinaya, and even Vitalik himself, uh called the Hitchhiker's Guide to the Ethereum Roadmap. Uh and so we're bringing him on the show to talk about not the math, but the meaning behind all of these things and what it means for Ethereum, what it means for you as a potential Ethereum validator, and what it means for you as a potential ETH holder. Uh, you guys might uh be aware that somebody is missing from this live stream. Ryan is in the middle of travel, uh, got rugged by some travel plans. Uh, so I'm taking this one solo today. Uh, and our fearless leader will be back with us uh next week for the next week's state of the nation. But in the meantime, we're gonna have to talk about uh a message from one of our sponsors, Alchemix. Uh at this point in time, this is when Ryan would ask me what the state of the nation is. And so I just have to ask myself what the state of the nation is. And today, the state of the nation is checking and balancing, and that I think is going to be a theme of the episode.

All of these very complex things, like I mentioned earlier, dank sharding, proposer builder separation, data availability sampling all fits under the theme of checking and balancing. And we've heard the phrase checking and balancing before. This comes from like your basic US history class. And why it's so powerful is it allows for not one part of the power structures around Ethereum to outsize the others. And so today, the state of the nation is we are checking and balancing the state of Ethereum. So we're going ahead and get right into the show with John from Delphi Digital to talk about all the different ways that Ethereum checks and balances itself right after we get to some of these fantastic sponsors that make the show possible.

Alright, Bankless Nation, we are here with John Charbonneau from Delphi Digital. John, welcome to the show, man.

What's up? Happy to be on. First podcast for me.

Yeah, congratulations. And uh we were talking a little bit backstage. You have a very recent history with Ethereum and crypto, which is a pretty impressive that you wrote a way an article praised by Vitalik himself as being extremely accurate and extremely well researched. Uh and so, like I mentioned, I teased in the in the intro, some of these things are extremely complicated. There is like crazy math, like you gotta go back to algebra and polynomials to understand some of these things. But that's not here what I what I want to talk about today, because I kind of want to talk more about just the vibes of all of these things, uh, how all of these things have a shared structure, a shared pattern. So before we get into some of the more complicated stuff, can you just summarize the vibe of the Ethereum roadmap post merge? Like what what should we expect?

Yeah. So the big thing obviously is the merge is not going to be scaling Ethereum. So the priority after the merge is going to be all of these different steps that we need

to scale all of the computation on Ethereum through the roll-up centric roadmap. So basically trying to make Ethereum a really good scalable base layer for rollups while at the same time scaling that throughput, keeping it really, really decentralized and easy to validate.

Um, because that's what keeps everything in check ultimately. Like true true scaling isn't just what's your TPS.

It's throughput relative to what is the cost to validate. And that second part is what a lot of other typical monolithic L1s that just try to like

jam through and put through on beefier hardware, they ignore that second part. So that's not true scalability to my mind. It's keeping that second part in mind at the exact same time that you need to do.

Right, one version of scalability is we just do away with the whole blockchain thing and we just go back to a database and then we have just the most scalable system on the planet, but then we lose all of that trustlessness. So uh to summarize what you're saying, uh post merge, post once we get to proof of stake, it's all about finding these different ways to scale computation, to scale uh throughput without losing all of the cool properties that make a trustless blockchain a trustless blockchain. Is it all right?

Yep.

And so in the intro to your piece, and just to dive into this a little bit more, you wrote uh um uh scaling computation without de uh sacrificing decentralized validation. Can you let's dive into the validation aspect of this? Well, what does it mean to uh scale computation without sacrificing validation? Uh from the user who might be like thinking about staking Ethereum or Ether in the future to become part of the network, that validation aspect uh I think is really important. Can you talk about and elaborate on that part?

Yeah. So the big theme with a lot of what Ethereum is going to be doing going forward, both at the L1 level and the rollup level, is that there's probably going to be some specialization in centralization and tasks, primarily block production.

The realization of that is that

you just need to really focus the most on decentralizing the validation of that, because that's what keeps everything in check.

Like Vitalik's Endgame Post is what put it the best that most roads tend to lead to that end scenario.

Whether it's in roll-ups, you see that you're probably going to have somewhat specialized block production if you want to have the highest throughput on them. What's important is to keep

regular users behind essentially full node security without the resource requirements of what typical

like high throughput L1s would require you to need today. So you want to give people that level of security by fully validating the chain. So if you have a malicious block producer,

you just reject the transaction. You could just see right away. If you're just running a light client of a monolithic L1,

Um, that because it just has too high a hardware requirement to run a full node,

they can pretty much do whatever they want to you, and you're just not going to notice it because you're trusting the honest majority. That's not the case with a full node. A full node

won't be accepting invalid transactions. And if you're working on a rollup,

then you're hiding behind the safety of fraud proofs or ZQ proofs. Um, so keeping that validation for regular users is what really, really matters a lot.

And so we I mentioned three components in the intro. Data availability sampling, proposer builder separation, and denk sharding slash proto dank sharding. These are all different strategies to get to the same end result, correct? And so different ways to scale Ethereum that scale different comp parts of Ethereum, but ultimately produce that scaled Ethereum with decentralized validation. Is that all correct?

Yeah, that's right. Because the overall vision of Ethereum right now is obviously the rollup centric roadmap. The problem with Ethereum right now is it's not built to actually host rollups. It's kind of just makeshift right now, and we're making do with what the L1 can handle.

So a lot of these are primarily geared towards scaling the data availability throughput

because that is a big bottleneck for the rollups right now, that they need to post their data to the L1.

And the layer one's just not optimized for that today. So it's being able to scale that while at the same time making it really, really easy for regular people to validate that.

So people who were familiar with the older Ethereum roadmap, uh, we talked about sharding as a way to like scale computation on the Ethereum at layer one, but w we've shifted away from that, where um computation scaling uh hasn't is uh

Been thought to now move into the roll-ups and computation scaling, that's we're really talking about like transaction throughput, like how fast transactions can go. And so uh once we now that we have this roll-up-centric roadmap of Ethereum, a lot of that computation is happening on the roll-ups. Uh, that's what roll-ups are due. And but in order to allow those roll-ups to really become unleashed and go up to their maximum throughput potential, we need to enable data uh to have make data available to them because uh the the resource that rollups need the most is data. Can you talk about this transition from like this older version of the Ethereum roadmap where we were going to actually scale the Ethereum layer one in terms of transactional throughput to what we've kind of pivoted to now, which we've actually focused on scaling the data availability.

Yeah, sure. So the old roadmap was, yeah, just jammed through the execution on the L1 through execution sharding.

Um, we've since realized essentially that it's better in nearly all respects to probably put that on roll-ups and then just optimize the base layer for data availability. Um, so that is what the old sharding design was doing, the previous one after execution shards, it shifted to the previous data sharding design where there was going to be these 64 different data shards, and you just post data to them as the rollups, and there are committees that are checking all of them.

And so as a validator, you're testing that all the data was made available because the data availability is important for the security of those rollups.

For example, in the case of an optimistic roll up, you need the data available

to successfully be able to arbitrate a fraud proof. You also need it in the case of a ZK proof

for ZK rollups to be able to recompute the state and be able to exit it safely.

So the key thing that we've realized is okay, we can shift that

block production and execution off-chain to roll-ups while now just focusing really on making it a really scalable data layer

while also keeping the regular execution part for settlement of roll-ups, like they posted proofs to the L1, they can bridge through it, keeping all of those trust assumptions together, but focusing on now scaling okay, how do we put a bunch of data through the L1 without jacking up resource requirements?

And uh correct me if I'm wrong. And again, listeners, we are going to go into the th the three things in in uh detail. Data availability sampling, proposer builder separation, and thank sharding. Um but uh John, before we get there, just again correct me if I'm wrong, but it's data availability sampling and dank sharding that do scale up uh the effective data of the Ethereum layer one, effectively increasing throughput on the roll ups. And proposer builder separation is something different. Is this all correct?

Yeah, so proposer builder separation is one of the really important, pretty much necessary things to enable dank sharding compared to the previous sharding design. So you could do data sharding without proposer builder separation, but proposer builder separation makes the new sharding design possible, which wasn't previously,

because otherwise it would have been too high of a resource requirement for regular validators.

Data availability sampling is part of that, making it really easy for validators part, that I can very securely check that all of the data was made available and know with 100% certainty or near 100% certainty that it was all available.

And that means that okay, if it was all available and I'm working on a roll up, if the data was available and no fraud proof has been posted, I can safely assume if there was one person who would have posted

that fraud proof, that I'm good to go. Or if a ZK proof was posted and I know all the data was available, then I know I'm good to go.

And what that does is that allows effectively more data to become useful to the Ethereum validators, while because we only have to verify a subset of that data, we get to prove that all of the data is available without having to check all of the data. And so we effectively get a data throughput increase because our validators only have to check a minority subset of the data, but as a whole entire ecosystem, we get to leverage the full expression of all of the data. And this is what we mean by scaling Ethereum without scaling computational requirements. Am I tracking here?

Yeah, exactly. Today is the opposite of that, where it's not built as a data availability layer. So when you post call data, the L1, it's just every node has to fully download it and then you hold on to it. That's a very resource-intensive way that you can't scale that up to massive throughput.

Okay, and then overall I would say resource intensive. I would say that these three things, again, which we're going to go into all fit into that vibe of how do we scale computation without scaling resource requirement? As like literally using cool cryptography, using cool math tricks, how do we scale computation, i.e., throughput, i.e. transaction speed uh and and and costs without without increasing the resource requirements of these tricks, uh, because that is what preserves Ethereum and keeps it decentralized.

Yep. Yeah, that's right.

Okay, and one last question as we stay high level, because again, super complicated subject, so I want to make sure all the listeners and all the viewers uh get the right vibe. Uh, what does this end state look like? Uh post the uh post inclusion of all of these different uh mechanisms, again, data availability sampling, proposer builder separation, and thank sharding slash proto think sharding. What's the end state of Ethereum look like? Can you kind of just walk us through a holistic uh visualization or or interpretation of Ethereum in this end state?

Yeah.

So yeah, the really high level of it will be that you basically introduce this new entity who's going to be a specialized builder.

So they're going to be responsible for making this really big block together that has all the data, the beacon chain block, everything put together.

And then you have this very decentralized, very low resource requirement set of validators

who don't have to build the whole block. They just take it and they have to say, okay, is this a block good to go? And was all the data made available? And you can pretty easily do that data check with data availability sampling, which is very different from today. Today you would need to download all of that data. So that's why we can't scale it up.

When you introduce the PBS proposer builder separation as that new role.

You get rid of the high resource requirement parts and then you add data availability sampling to make it really easy to do that proposer job of just checking the data was available.

Okay, and the the last subject I want want to get to is the interactions between all these components. And so I want I want to put my devil's advocate hat on, my my Ethereum crit critiquer hat on, and say, well, Ethereum's complicated, and it's just like solving its problems with more complication, right? It's just uh adding complication on top of complication. Uh, and then eventually, like once all these three things that David keeps on listing off by name, once those get included, then we're gonna have like eight more things to solve the complexity there, and then we're gonna have like 18 more things to solve the complexity there. So that that's the that's the devil's advocate version of Ethereum, where like it's already complicated, and we're just making it more complicated to do all these things. And then there's the opposite interpretation where actually these three things fit together really, really well and have this sort of like elegance between the interactions between these three components. Uh, what what side, what what side of uh that that take would you say that you're on?