Bankless - Guide to the Ethereum Roadmap | Jon Charbonneau of Delphi Digital

Episode Date: June 1, 2022

Jon Charbonneau, Research Analyst at Delphi Digital joins David to talk about his recent essay titled, "The Hitchhiker's Guide to Ethereum." Proposer / Builder Separation (PBS) Danksharding and ProtoDanksharding (DS + PDS) Data Availability Sampling (DAS) What the absolute HELL are these things? What do they mean for Ethereum? What's the common theme behind all of them? And what do they mean for ETH? All of these questions answered and so much more in the livestream. ------ 📣 ALCHEMIX | Get a self-repaying loan today! https://bankless.cc/Alchemix ------ 🚀 SUBSCRIBE TO NEWSLETTER: https://newsletter.banklesshq.com/  🎙️ SUBSCRIBE TO PODCAST: http://podcast.banklesshq.com/  ------ BANKLESS SPONSOR TOOLS: ⚖️ ARBITRUM | SCALED ETHEREUM https://bankless.cc/Arbitrum  ❎ ACROSS | BRIDGE TO LAYER 2 https://bankless.cc/Across  🏦 ALTO IRA | TAX-FREE CRYPTO https://bankless.cc/AltoIRA  👻 AAVE V3 | LEND & BORROW CRYPTO https://bankless.cc/aave  ⚡️ LIDO | LIQUID ETH STAKING https://bankless.cc/lido  🔐 LEDGER | NANO S PLUS WALLET https://bankless.cc/Ledger  ------ Timestamps: 0:00 Intro 6:00 The Vibe of the Ethereum Roadmap 8:50 The Hitchhiker's Guide to Ethereum 17:06 The End State of Ethereum 23:05 Data Availability Sampling 34:49 Proto to Full Danksharding 48:15 Proposer Builder Separation 54:01 Checks & Balances 56:10 Incentives in Being a Builder 1:01:50 Centralization 1:03:50 Comparing Ethereum’s Scaling Strategies 1:05:54 Value Capture 1:07:20 How Jon Understands Everything ------ Resources: Jon Charbonneau https://twitter.com/jon_charb  Delphi Digital https://delphidigital.io/  The Hitchhiker's Guide to Ethereum https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum  Valuing Layer 1s - Memes, Money, or More? https://members.delphidigital.io/reports/valuing-layer-1s-memes-money-or-more  ----- Not financial or tax advice. This channel is strictly educational and is not investment advice or a solicitation to buy or sell any assets or to make any financial decisions. This video is not tax advice. Talk to your accountant. Do your own research. Disclosure. From time-to-time I may add links in this newsletter to products I use. I may receive commission if you make a purchase through one of these links. Additionally, the Bankless writers hold crypto assets. See our investment disclosures here: https://newsletter.banklesshq.com/p/bankless-disclosures 

Welcome Bankless Nation to a very special episode that I'm super excited to bring you on today's State of the Nation The 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. 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 when a research analyst out of Delphi Digital. We're talking about the Ethereum roadmap beyond the merge. In some ways the merge for 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 dank 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 these 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, 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 praised by some of the leading Ethereum researchers, Tim Bako, Polyniya, and even Vitalik himself, called the Hitchhiker's Guide to the Ethereum Roadmap.

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 eatholder. You guys might be aware that somebody is missing from this live stream. Ryan is in the middle of travel, got rugged by some travel plans. So I'm taking this one solo today, and our fearless leader will be back with us next week.

for the next week's state of the nation. But in the meantime, we have to talk about a message from one of our sponsors, Alchemics. Alchemics, you guys know Alchemics. It's the crypto-powered savings paradigm where you can save money, either in Eth or Die or your other stable coins. You can deposit it into the Alchemics DeFi yield farming account. And for all of the money that you deposit into Alchemics, you can withdraw up to 50% of your deposits while that deposit grows and grows and grows

from your yield farming in DeFi. which Alchemics does for you. So it allows you to save your money and spend it too. It allows you to get your interest payments paid to you up front through the Alchemips web app. And so you can check them out there is a link in the show notes. Bankless.c.c. slash Alchemics with a capital A.

You can see on screen all the assets that you can leverage, including staked eth from Lido and Rocket Pool, as well as your preferred stable coin. And if you are an Alchemics token holder, there is a coming tokenomics upgrade. And there's a link in the show notes for you to explore that as well. At this point in time, this is when Ryan would ask me what the state of the nation is. 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 ability sampling, all fits under the theme of checking and balancing. And we've heard the phrase checking and balancing before. This comes from your basic U.S. 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. The era of proof of stake is upon us, and Lido is bringing. bringing proof of stake to everyone. Lido is a decentralized staking protocol that allows users to stake their proof of stake assets using Lido's distributed network of nodes.

Don't choose between staking your assets or using them as collateral and DFI. With Lido, you can have both. Using Lido, you can stake any amount of your ETH to the Lido validating network and receive STEth in return. SCEs can be traded, use as collateral for lending and borrowing,

or leverage on your favorite DFI protocols, all this without giving up your ETH to centralized staking services or exchanges. Lido now supports Tara, Solana, Kusama and Polygon staking. Whatever your preferred proof of stake asset is, Lido is here to take away the complexities of staking while enabling you to get liquidity on your stake.

If you want to stake your ETH, Terra, soul, or Matic, and get liquidity on your stake, go to Lido.FI to get started. That's LIDO.FI to get started. The Layer 2 era is upon us. Ethereum's Layer 2 ecosystem is growing every day and we need bridges to be fast and efficient in order to live a Layer 2 life.

Across is the fastest, cheapest, and most secure cross-chain. bridge. With Across, you don't have to worry about the long wait times or high fees to get your assets to the chain of your choice. Assets are bridged and available for use almost instantaneously. Across Bridges are powered by Uma's optimistic Oracle to securely transfer tokens from layer two back to Ethereum. A token proposal is being deliberated as we speak in the Across Forum where community members will decide on the token distribution. You can have your part of Across's story by joining the Discord and becoming a co-founder and helping to design the fair, fair launch of a cross. If you want to bridge your assets quickly and securely, go to across.t.0 to bridge your assets between Ethereum, Optimism, Arbitrum, or Boba networks.

If you're trying to grow and preserve your crypto wealth, optimizing your taxes is just as lucrative as trying to find the next hidden gem. Also, IRA can help you invest in crypto in tax advantage ways to help you preserve your hard-earned money. Also, crypto IRA lets you invest in more than 150 coins and tokens with all the same tax advantages of an IRA. They make it easy to fund your alternative IRA or crypto IRA via your 401k or by contributing directly from your bank account. There is no setup or account fees and it's all you need to do to invest in crypto tax free. Let me repeat that again. You can invest in crypto tax free. Diversify like the pros and trade without tax headaches.

Open an alto crypto IRA to invest in crypto tax free. Just go to alto IRA.com slash bankless. That's A-L-T-O-I-R-A.com.com. slash Bankless and start investing in crypto today. All right, 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 we were talking a little bit backstage. You have a very recent history with Ethereum and Crypto, which is pretty impressive that you wrote an article praised by Vitalik himself as being extremely accurate and extremely well researched. And so like I mentioned, I teased in the intro, some of these things. are extremely complicated.

There is like crazy math. Like you got to go back to algebra and polynomial so I understand some of these things. That's not here what I want to talk about today because I kind of want to talk more about just the vibes of all of these things, how all of these things have a shared structure,

a shared pattern. Before we get into some of the more complicated stuff, can you just summarize the vibe of the Ethereum roadmap post-merge? Like 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 roll-ups, while at the same time scaling that throughput, keeping it really, really decentralized and easy to validate. Because that's what keeps everything in check ultimately. Like 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 L ones that just try to like jam through and put through on BF your hardware, they ignore that second part.

So that's not true scalability of 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'd lose all of that trustlessness. So to summarize what you're saying, post-merge, posts once we get to proof of stake,

it's all about finding these different ways to scale computation, to scale throughput, without losing all of the cool properties that make a trustless blockchain, it's all right? Yep. So in the intro to your piece, and just to dive into this a little bit more,

you wrote scaling computation without sacrificing decentralized validation. Let's dive into the validation aspect of this. What does it mean to scale computation without sacrificing validation? From the user who might be thinking about staking Ethereum or ether in the future to become part of the network, that validation aspect 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 roll-up level, is that there's probably going to be some specialization and 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 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 high-throughput L-1s 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 like client of a monolithic L1, because it just has too high a hardware requirement to run a full node, they can pretty much do whatever they want to 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 rollout, then you're hiding behind. the safety of fraud proofs or ZK proofs.

So keeping that validation for regular users is what really, really matters a lot. And so I mentioned three components in the intro, data availability sampling, proposer builder separation and dank 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 parts of Ethereum, but ultimately produce that scaled Ethereum with decent. centralized validation. Is that all correct? Yeah, that's right. Because the overall vision of Ethereum right now is obviously the roll-up

centric roadmap. The problem with Ethereum right now is it's not built to actually host roll-ups. 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 roll-ups right now that they need to post their data to the L1. And the layer ones is 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, we talked about sharding as a way to scale computation on the Ethereum at layer one. But we've shifted away from that where computation scaling has been thought to now move into the roll-ups.

And computation scaling, we're really talking about like transaction throughput, like how fast transactions can go. And so once we, now that we have this roll-up-centric roadmap of Ethereum, a lot of that computation is happening on the roll-ups. That's what roll-ups are due. 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 to make data available to them because the resource that roll-ups 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. 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. So that is what the old sharding design was doing. the previous one after execution shards, it shifted to the previous data charting design where there was going to be these 64 different data charts, and you just post data to them as the roll-ups,

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 roll-ups. 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 a 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 post the proofs to the L-1, 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 correct me if I'm wrong. And again, listeners, we are going to go into the three things in detail, data availability sampling,

Proposer Builder separation, and dank charting. But, John, before we get there, just again, correct me if I'm wrong, but it's data availability sampling and dang sharding that do scale up 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 simpling 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. Well, 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. it. 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 under 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 and costs without increasing the resource requirements of these tricks, 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 get the right vibe. What does this end state look like?

Post the post inclusion of all of these different mechanisms, again, data availability sampling, Proposer builder separation, and dank sharding slash proto-dank sharding. What's the end state of Ethereum look like? Can you kind of just walk? is through a holistic visualization or interpretation of Ethereum in this end state? Yeah. 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. block, they just take it and they have to say, okay, is this 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 proposal-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 checking the data was available. Okay, and the last subject I want to get to is the interactions between all these components.

And so I want to put my devil's advocate hat on, my Ethereum critiquer hat on and say, well, Ethereum's complicated. And it's just like solving its problems with more complication, right? It's just adding complication on top of complication. And then eventually, like once all these three things that David keeps on listing off by name, once those get included, then we're going to have like eight more things to solve. the complexity there and then we're going to have like 18 more things to solve the complexity there. So 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. What side of the take would you say that you're on? It's all a mess. No, every, every, Everything does fit together really well. Even beyond just these three components, when you zoom out and look at almost every major component of Ethereum's future roadmap, almost everything does boil down to those two points of scaling computation while making it really, really easy to validate.

I mean, taking these as an example and how they are necessary and kind of interweave with each other, dank sharding, which is what we're going for, proposal builder separation is necessary to do that, helps it scale easily, and it makes it easier for us to validate it because you make the proposer job really easy. All of these different pieces are kind of just running in parallel, and they're all chipping away at different things. Whether you look at even looking at a bunch of stuff

on the Ethereum roadmap, but so much of it is just, how do we lower the resource requirements to validate? Whether you look at things like history, like history X free, that's okay, you don't need to have as big a hard drive to run a full node. If you look at statelessness, that helps, like, reduce your SSD requirements that you don't have to hold your state on hand.

Like, they're all chipping away at different pieces. I mean, like data availability sampling, which is one that will go into more, like, it helps you lower your bandwidth requirements and that you don't have to download all this data. All of these things ultimately do really come into this very cohesive view when you zoom out and you, like, start to understand how they all work with each other. So I think with one of these components, like take data availability sampling, for example, like we get a bandwidth reduction, which is nice because, then blocks propagate faster. We can have more throughput that way. That might be like one single, like a sized upgrade. I don't know how you want to side this thing,

like maybe one order of magnitude. But then when we layer on like the next thing, like Proposer Builder separation, like we actually get another order of magnitude. But then these things interact, right? These orders of magnitude compound on each other. And then we throw in the third thing. And we have like three different ways.

We are decreasing resources requirements. and they're not, they don't, they're not linear. It's exponentially scaling. It's exponential reduction of resource requirement, which turns into an exponential scaling of the actual throughput of the holistic Ethereum ecosystem. Is that a fair take? Yeah, yeah, that's generally not right.

And that's why you see, like, people will have heard of and we'll go into this in more depth proto-dank charting, which is a halfway step to dank sharding. And that's exactly what you see, where you have a certain amount of data availability throughput, But today, if you go to proto-dank charting, which implements part of the steps of dang sharding, you get some orders of magnitude scaling. And then dank sharding layers on even more of the exciting changes that are coming, and

then you get even more orders of magnitude scaling for data availability on top of that. So just to answer a question, which I think might have popped up in some listeners' minds, dank sharding slash proto-dank sharding. Can you talk about how these names came to be? Yes. So dank sharding, which is a great name. Play on took the old just sharding design, and Dom Crot is the one who came up with that. And then the halfway one Proto Dank sharding is a play on taking that, and then also Proto Lambda

pitched in to add that halfway measure. Right. Okay. So Proto Lambda, he's with the, he can't remember where he was, but he was working maybe at the EF before this. Yes, he was working at the EF. Then he joined the optimism team. He's called Proto Lambda.

I'm sure it's not his actual name, but that's what we call. column. And then there's Dank Red Feist, also at the EF. And so these things are fondly named after them. And so Ethereum sticking true to its name of kind of picking weird names for its upgrades. So, okay, so here's where I get a little bit confused, John, and I kind of want you to pick the next path forward. We have three different things to talk about, data availability sampling, proposer builder separation, dank charting slash proto-dank charting. Since they're all interrelated, Like, is there a starting place? Is there one that we should pick out first to talk about first?

Or is it kind of a chicken and an egg problem? Since they're all interrelated, there is no starting point for this whole entire conversation. Yeah, they're all pretty interweaved. Like, you're going to see data availability sampling, proposer builder separation, and dank sharding all come together. And then proto-dank sharding is the halfway step that implements, like, some of the transaction formatting. So they all do very much interlock those three.

So we're just going to have to pick one. Yes. All right. Let's go with data availability sampling. Can you explain data availability sampling and how it scales computation while keeping Ethereum decentralized? Yeah. So back to that message of we're trying to scale the data availability throughput of the L1.

And just to remember, there's a difference between data availability and data retrievability. What we need for the security guarantees of the consensus layer isn't that this data is retrievable forever. What we need to know is, was this data published? Did we attest that it was available such that it's available for some period of time, that any interested party could have downloaded it and could have reasonably submitted or fraud proof or done anything like that? Like, that's what we need for our safety. The history, like, retrievability of it is a separate, much weaker assumption that is dealt with separately. So that's what the data availability is.

And then- Well, let's actually dive into that a little bit more. So data availability, if I'm recalling my Ethereum knowledge, it makes it availability for an amount of time. And that amounts of time is just assumed to be long enough to know that the whole world could have downloaded and had that data available to them. But the Ethereum Protocol does not commit

to embedding that into the blockchain perpetually. So it will not be saved inside of the Ethereum blockchain forever. But the Ethereum Protocol generates assurances is that there was enough time for the whole world to have downloaded that data at some point in time. Can you just let's elaborate and unpack the difference between these two things and why we wouldn't just save it in the Ethereum protocol forever? And how do we know that it was actually available to the whole world for a sufficient amount of time?

And why do we feel secure pruning it from the blockchain at all? Exactly. Yeah. So the problem with if you require it, stay on chain forever, that every likeful mode has to hold onto this data forever. You just can't feasibly keep this thing decentralized. That's just way too high of a resource requirement to ask all of these nodes that you want to be validating to be able to hold onto this like ever-growing, massively growing thing that's going to have terabytes of data that are running through it when we like implement sharding in these things.

So right off the bat, we know that that just can't keep it like decentralized validation if we do that. And the resource bandwidth that we're talking about here is hard dry space, right? Like if we let it get out of hand all Ethereum nodes that all of us that plan on staking our eth and running our nodes, we would have like a normal size computer except for this massive, massive, just like rack of hard dry space. And so that that's the resource requirement that we are minimizing here with this data availability sampling. Is that correct? So that would be minimized by the fact that we are going to start pruning these data blobs when we introduce the new transaction format with protodank sharding.

This history issue is going to be exacerbated by the fact that we start posting a bunch of data to the L1, but it's already an issue, which is why, apart from all of this, there is separately another EIP, like called EIP 4-4s, that is going to start allowing nodes to prune all historical data after a year and stop serving that to the network. The difference today is that call data, which is what rollups use today, it just persists on chain. It just stays there. But that's not the security guarantee that we really need for rollups. So what protodang sharding is going to do, one of its big halfway steps to going to full dang sharding is it introduces the new transaction format that rollups will use.

So today they post call data. Once protodank sharding is enabled, they'll start posting data blobs. And the thing with data blobs is they can get pruned after about a month. month. So that's more than enough time that we guarantee that it's available that people could have posted fraud proofs or done whatever. Anyone could have downloaded it in a reasonable period of time. But then full notes just don't have to hang on to it. It's not their problem because history is just a one of an like trust assumption. As long as someone out there is holding the history, it's fine. I could just go ask them for it. You don't need everyone to be holding that on

hands. It's just not necessary. So one of an assumption as in if there's one Ethereum node that's out there that has this data or like what is the actual process of why why would I would want to go retrieve very old data and then how do I actually do go about finding that data? So yeah, I like it could be anyone. I mean like the easiest example is block explores. If you have some guy to business that depends on I need to be able to serve this history whenever like anyone asks for it, they're a perfect example of as long as they're storing

it. you're fine. There are other decentralized and more innovative options to make sure that we are better incentivizing history retrieval as it starts to become more of an issue. It's not like a big issue today. Like another thing is it's really not an issue for the Ethereum protocol. It's only an issue for apps basically if they use if they lose like their old history and they're like, oh, I can't prove that this thing happens. So one thing that for example, roll-ups could do is they could just mandate that they have to hold onto their own, like, relevant parts of their history. There's lots of innovative solutions where as long as someone is holding on to it and I could

just ask them, I can always prove that what they gave me is valid. So as long as someone still has it, it's not lost forever. Okay. So if a roll-up makes a layer one transaction with a specific amount of interactions with a part of the Ethereum layer one, like it talked to these tokens and talk to those tokens, the roll-up can make sure that the data for those relevant transactions are always stored by the roll-up providers, right? The roll-up nodes. And so that would make that that part of Ethereum persistently and perpetually available for that particular roll-up.

And so that part of Ethereum is secured. And then we could probably repeat this process like 50, 100,000 times. And then eventually we'll get to the full entire, full archive state of Ethereum. But it's no one single node is responsible for storing all of it. Is this correct? Yeah. It's never going to be mandated. in protocol that Ethereum needs it.

You could also try to do decentralized different, like, incentivization where you can have, like, different networks, where you are paying people to, like, hold your data. But it's just fundamentally not the Ethereum L1, like, consensus layer's problem, because it's not like breaking anything if you can't, like, resurrect your history. It's a problem for that app, like, hey, I can't do this transaction or whatever now.

I can't prove this thing. But that fundamentally is just a different task. That's much easier to outsource and it makes sense too to keep everything very decentralized. Okay, it's not breaking anything if you can't. I can't remember how you exactly said it. But I think it led into my next question where if I put on my Bitcoiner hat and they're like, you guys are pruning the data from your chain, like I would get triggered, right?

Like, Bitcoiners are extremely hyper-focused on backwards compatibility and making sure that if somebody mined a block in 2010 and then they didn't move those coins from 2010 on words into 2050, like the emphasis from Bitcoin is that you will always be able to retrieve your coins and the data. And you also get the self-sovereignty from always being able to run a node and spin up a node from Genesis and verify every single transaction. So we're not violating that principle by doing this. Yeah, because the reality is, is you won't yourself have the data, but as long as you can get from one single person out there, like it's really, really just not an issue. And it fundamentally isn't a big concern because there are always going to

be these things. And you can incentivize them in different ways. You can use like they're like third party like indexing things. Like you'd have like the graph. Like there's work with like all of these different things that like as long as someone's holding on to it like it's not a major concern. And the, and the idea is that even if one person, again, putting on my Bitcoin or hat, okay, but you're asking me to trust one single person to serve me the data? Like what if they start? me incorrect data that serves their needs instead of mine. What's the response to that? So you only need one out of all of these different candidates who should be storing it,

whether it's roll-ups storing theirs, their own data, whether it's individuals, block explorers, if people start using like the graph for all these different solutions. You just need one of them to provide it to you. But how do I know that they're giving me the correct data? Exactly. Like they can't give you fraudulent data. You could always still prove. that, hey, this thing happened.

Like, you can't just serve you invalid data and then you'll take it. You can always prove on chain that you can go back and look that, hey, does this match? Like, they can't trick you into doing something. The worst thing that could happen is just, they don't give you the data. And then you just can't retrieve what happens.

OK. Now, is this still, this is where some of these interaction between these things get a little hairy. Is this what we're discussing now about the ultimate pruning of the blockchain? Is this data availability sampling or is this dang sharding or proto-dank sharding? Or is it both? This will be implemented with proto-dank sharding.

And then the other steps will be implemented with full dank sharding. So this is the main reason that proto-dank sharding is able to scale is because it introduces the new transaction format that are going to be carrying these data blogs. And these data blobs will be pruned after about a month or so once we know that they've safely been available. Anyone could have downloaded them. anyone could have checked them. You can prune them.

And then because of that, we can send through orders of magnitude more data throughput because we're not requiring people to hold on to these things forever. So we don't have to worry about blowing up the history with them. Okay. So with dank charting and proto-dank sharding, we can juice up the throughput of Ethereum because we are only requiring the nodes to really store the more recent parts of Ethereum and not the long-term parts of Ethereum.

Therefore, we're more okay with. juicing up the data requirements because it's all in the short term, not in the long term, correct? Yeah. And the reason that we could then take another step up from proto-dank charting to full-dang charting is because in proto-dank charting, we're not going to have data availability sampling or any of that. We are still going to require the validating nodes to fully download the data. That's how they'll have to check that the data is available, is they will have to fully download everything and say, hey, was this data available? When we go to full-dank sharding, after that, you'll only be checking a subset of the data, so then the data will be sharded.

So then that gives you the extra orders of magnitude scalability. Okay, and then the going from proto-dank sharding to full dank sharding, that's when that crazy like polynomial math comes into play, where like we can allow for more data to come in because the validators only have to check parts of it. And because of crazy polynomial math, we have the assurances that to like the 99.999% likelihood that all of that data is there. And so we can, do you know, like, the order of magnitude increase in data from going from Proto-Dinksharding to Deng-Sharding?

Do you know what that is? From, sorry, from Proto to a full-dank-sharding, you said? Like, what's the scalability increase on that one? I want to say it's about a 30-X, if I remember correctly. Oh, wow. Yeah, yeah, yeah. Okay, so we take Proto-Dank-Sharding and then we add this, like, polynomial math, to get to full dank charting, and that gives us a 30x increase in data availability?

Yes, or I want to say 16. I don't remember the multiple on it, but it's, yeah, it's in the low orders of magnitude number. The target block size is going to be around a megabyte for data availability for pro-dank sharding, and then it'll go up another couple orders of magnitude or so from proto to full. Because we have data availability. availability sampling because you don't have to download everything anymore. Okay, so data availability sampling, is that the polynomial math thing that I was just talking about? That is part of it. You, yeah, the KZG commitments are like how you commit to the data and that like includes

that that's the like polynomial part of it. That's where like some of the trickier math comes in. That would be the KZG commitments would be partially introduced. by proto-dank sharding, but not the full, like, 2D KZG scheme with data availability sampling, like some of the, like, the, like, nitty-gritty stuff. Okay. So what components of data availability sampling have we not already discussed that we need to dive into?

And, or maybe we should start from scratch, because I'm literally, I think the listeners can, like, figure this out by now. I'm literally learning as we go. Okay, let's go back to data availability sampling. What is the resource requirement that that is trying to mitigate and how does that work? Yeah. So yeah, first I'll explain how it works. So the basic idea is like I said, with Proto Dengs charting, it's not super scalable to just download all the data. So what we want to do is make it such that you only have to download a piece of the data, a really small portion of it. But how do you, like, the naive way to do that is just to like take this data that was posted. I check a bunch of little pieces. And if they're all there, I'd say it's good. The problem with that is, is you could have missed the one transaction that like prints a million eath or like whatever. And then you're screwed. And like all your money's gone or whatever. So that doesn't give you any guarantee. We have to verify every single transaction. Exactly. So that would be the naive way to do it.

The better way to do it is what you do what's called erasure coding. So that initial data, the original like actual data gets extended. So you have this like parody data. And this is like used in like error correction. It's the same like type of technology that's used in like CDs that if they gets scratched, you can reconstruct it with only like part of the data. It's the same like concept as that. Where now you have this original data and you have the extension data and you only actually need 50% of that data and then you could reconstruct the whole thing. And it could be any 50% of the data. It could be a little bit of this, a little bit of this, like it could be anywhere. So then it makes it really easy to do that sampling math because as long as I have 50% of the data, I could recreate the whole thing. So that

That makes it really easy now because I could do the samples and for you to trick me into like a testing to this block, you have to be hiding more than 50% of the block, not just like one transaction. You have to be hiding more than 50% of like this data that was given to me. So now let's say you were trying to do that and I checked once and I was successful. I got the data. So I still have a 50-50 shot that like the block isn't fully available. But if I check it again, now I have a 75% chance.

then you have an 87.5% chance. Like you keep doing that. And if you do that like a fixed number of times where you have a 50% chance of being tricked each time and you do that like 30 times or so, your odds of being successfully tricked like 30 times in a row at 50% odds is like essentially zero. So that's what we do is we extend the data using erasure coding such that you only need 50% of it to be available, and then you could safely sample the different pieces. And then if those were successful, you can say with pretty much statistical certainty that the block is available to me. Okay.

So I'm going to repeat this back to you to hope that I got it. So there's this amount of data. There's this data that I got to download and verify. And I need to make sure that 100% of all transactions in this bit of data is completely valid. It's not enough to do all transactions, but one, we can't cut that shortcut because if one single transaction gets in, if this is coming from an attacker, they might do something like print a billion ether and give it to themselves. And all of a sudden we have like a huge problem with Ethereum security if somebody is able to print a billion ether because now they probably

control the network. They definitely do control the network. So we need to make sure that 100% of all transactions are completely valid. But we do what we want to do. We don't have to make sure that they're valid. That's one point that is really important is the layer one says nothing about the validity of those transactions that are posted to the L1 from roll-ups. It just says that they're available. And then you rely on proofs to tell you, was it valid or not? But the L-1 guy who's just checking the data doesn't say it's valid. It just says it was available and someone else will check it.

Okay, okay, cool. Again, leaning into the whole separation of checks and balances, this one person says this data, available somebody else go check if it's valid but right now we're talking about okay all transactions are available to be checked by somebody else and so this one person's job is to say all of this data every single transaction that is uh exists can be checked by someone and again we need to make sure that every single transaction can be checked so we have this amount of this thing of data and we do this thing this weird thing this complex math thing called erasure erasure data uh razor it extends the data and my version of that is it makes my interpretation of that it's like it makes like a

kind of like a like a square root of negative one version of it I don't know it takes this data and it makes this like random manipulation to it to extend the data and so and what that does again with crazy math is that it takes the same blob of data but then it makes this like clone of it that is in a particular out of a particular derivation and then this person as a result of that I might be skipping us up here. As a result of that, I need to check that this is when we get into the 50% odds thing, right? Because of this particular way of this expression of this creation of extra data and also with polynomial math? Yes?

Yeah. Yeah. So the way the polynomial. Yeah. So there's two parts of it. You basically need to know that one, the data was made available. So that's what data availability sampling gives you. you could check all these random pieces, say it was available and I'm good to go.

The other part of it is you need to make sure that the data was extended properly. Yes. Because if that extra 50% they gave you was just like dummy data, then I can't actually reconstruct it because that was just like useless data. So that's where the like polynomial math comes in. These things called KZG commitments, those will prove to you that the data was extended correctly. So then you have the KZG commitments telling you proving that the data was extended correctly.

and then I could data availability sample saying it was extended correctly and it was also available. Okay. So once we get to that point, we have those assurances and then we just start taking actual samples, right? So the first step is to prove that all of the data is extended correctly and that extending correctly, once we get to that point of extending the data correctly, that's when we get to sample it with the increase, increase assurances that there's nothing hidden. So the extension allows us to have more effective sampling. And then once we get to the extension, then we start sampling this thing. And sampling is like flipping a coin, except once we get to like 30 coin flips, like you will never ever anyone in anyone's life flip a coin 30 times and have it be heads every single time. That will never ever happen in your life.

And so that's how we get to the assurances that we feel secure about. like there is literally impossible to hide a malicious transaction in this like fake bit of data. And so the first step is to extend the data to allow for more efficient and more effective sampling. And then we sample it about 30 times because that's where like the level that we deem safely safe to assume that all the rest of the data is also valid or not valid but available. Is this all correct? Yeah. In the real number, it's going to be 75 for some like complicated 2D KZG scheme stuff, but it's probably not like necessary to go into the details of that.

Okay. Okay. So as you can see, my brain is starting to break. John, can you just walk us through one more time now that we've gone through this? Can you just walk us through the data availability process one more time from the high level? Yeah. So in proto-dang charting, it's going to be simple. You still just fully download the data and then that's it. If you fully downloaded it, you got it, then you're good to go.

You sign off on it. The reason that you could do more throughput for the data in folding charting is because now you're only going to be, the validators will only be downloading parts of the data. They'll be doing data availability sampling. They'll be downloading like certain rows and columns. And then they'll attest you if theirs were available, then maybe. collectively you're good to go as long as there's enough people who are sampling it. So that like easier requirement allow, because you don't have to download the full thing, makes it easier for you to like kind of like juice up the data availability through but another

level. Fantastic. Okay. So this is where we're about to get into a very fun part of this whole entire story, which is Proposer builder separation. And this is where we start to talk about getting paid in ether. And so this is where the ether economics of being an eth validator come into play. and overall where we'll actually start to be able to differentiate

Ethereum scaling strategy from the rest of the Altlayer 1s. And so, John, I'm going to pick your brain on that because I know you've also written another article comparing the overall the different strategies of Altlayer 1s and the relations to their L1 assets. So definitely a very fun part of the conversation, which I definitely understand a little bit more than the first part of the conversation.

So we're going to get there right after we talk about some of these fantastic sponsors that make the show possible. AVE is the leading decentralized liquidity protocol. And now AVEV3 is here. AVEV3 has powerful new features to enable you to get the most out of D5, including isolation mode, which allows for many more markets to be launched with more exotic collateral types. And also efficiency mode, which allows for a higher loan to value ratios. And of course, portals, allowing users to port their AVE position across all of the networks that AVEA operates on,

like Polygon, Phantom, Avalanche, Arbitrum, Optim, Optim, Optim, Optimism, and Harmony. The beautiful thing about AVE is that it's completely open source, decentralized, and governed by its community, enabling a truly bankless future for us all. To get your first crypto-collateralized loan, get started at AVE.com. That's A-A-A-B-E.com. And also check out the AVE protocol governance forums to see what more than 100,000 Dow members are all robbing about at governance.com. Arbitrum is an Ethereum layer 2 scaling solution that's going to completely change how we use D-A-V-I-N-FTs. Over 300 projects have already deployed to Arbitrum, and the Defy and NFT ecosystems are growing rapidly.

Some of the coolest and newest NFT collections have chosen Arbitrum as their home, all the while DeFi protocols continue to see increased usage and liquidity. Using Arbitrum has never been easier, especially with the ability to deposit directly into Arbitrum through all the exchanges, including Binance, FTX, Quibi, and Crypto.com. Once inside, you'll notice Arbitrum increases Ethereum speed by orders of magnitude for a fraction of the cost of the average gas fee. If you're a developer who wants low gas fees and instant transaction, for your users, visit arbitrum.io slash developer to start building your dapp on Arbitrum.

If you're a Dgen, many of your favorite daps on Ethereum are already on Arbitrum, with many moving over every day. Go to bridge.arbitrum.io now to start bridging over your ETH and other tokens in order to experience defy and empties in the way it was always meant to be. Fast, cheap, secure, and friction-free. Living a bankless life requires taking control over your own private keys. And that's why so many in the bankless nation already have their ledger hardware wallet. And brand-new to the ledger lineup of hardware wallets is the Ledger NanoS Plus, a huge upgrade to the world's most popular hardware wallet. With more memory and a larger screen, the NanoSplus makes it easy to navigate and verify your transactions. And the paired Ledger Live desktop app gets you increased

transparency as to what is about to happen with your NFT. What you see is what you sign. The NanoS Plus gives you the smoothest possible user experience while you're doing all of your crypto things. So go to the Ledger website to check out the features of the new Ledger NanoS Plus and join the waitlist to get yours. And don't forget about the Crypto Life card, also powered by Ledger. The CL card is a crypto debit card that hooks right into the Ledger Live app, right next to all the Defy apps and services that you're already used to doing, like swapping tokens and staking. So if you don't have a Ledger hardware wallet, go to Ledger.com, grab a ledger and take control over your crypto. All right, Banking Station, we are back with John from Delphi. We're going to talk about the last

of the three strategies to get Ethereum scaled computation without scaling trustlessness and permissionlessness. And that comes to proposer builder separation, which thankfully, it's actually baked into the title about what this is. But John, what's a proposer, what's a builder, and what are we separating? Yeah. So this is one of the key things that makes dang sharding possible from what the old sharding design was. But it was actually initially designed as like an MEV fighting strategy that like fights the centralizing forces of it. So the way that it works, generally is today you have, if you're like a validator, like after the merge or a miner today, you have to do two things. You have to like actually build the block. And you also have to say

that like this thing was valid and sign off on it. The realization is that like those don't have to be like the same person who's doing those. And like it makes a lot of sense to split those out because that person who builds the block today, it's like a mining pool operator. But like the point is it's a very difficult role to do that effectively. Because one of the biggest, like, advantages of being the block producer is MEV, like a maximum extractable value. So ordering these transactions in a certain way that I can extract the most, like, whether it's sandwich attacks or like whatever. The problem is, is that like, I don't know how to do that on my computer. Like, I'm not going to be able to effectively, like, get MEV out of this block. So I'm

just going to say, screw it, like, give my money to someone else, like, you validate for me, and then just like, it's fine. We don't want that to happen. We want it to be really easy that, like, a validator doesn't have to worry about MEV. So we need to just, like, outsource that building task. Then just to put listener, the mind of the listener in the right spot. I think there's a lot of listeners here, a lot of views on the YouTube, we're playing on staking their ETH, and hopefully they plan on staking their ETH from the comfort of their own home with their own computer. And then they're probably hearing about, like, how lucrative, MEV is and they're probably really excited to get some of that MEV when it comes to the merch.

The problem is like, yo, listener, yo YouTube viewer, do you actually know how to get MEV? Like, are you technical? Or, and because if you're not, then you're just going to leak MEV in favor of those who do know how to capture it. And so if you are thinking about like, oh, I can't wait to get my hands on some of those juicy MEV rewards, what you need is proposer builder separation. So, John, I'll throw it back to you. Yeah, and exactly.

So this won't be implemented until dang sharding, which is why at the merge, FlashBots is going to come to the rescue again. And basically create this thing, which is effectively out of protocol, proposal builder separation, they're going to introduce something called MEV boost, which is like a plug into your consensus client, which basically replaces like your execution aspects of your client. and like they will take the bids from searchers and builders who are like they want to bid, it will like build this optimal block and it will just hand it to your consensus client. The problem with this is you now have trust in that like relayer, like through MVP Boost who's sending you this thing that like all this is valid and like all of it checks out. And like obviously you don't want to like have that trust and like all these different things. So PBS will then actually bring all of that like building and auction like fully in protocol.

And that's what allows for dank charting as opposed to the old design. Because in the old design, we had these 64 like individual separate shard blocks. So it wasn't like that hard to produce a single shard block. The big advantage of dank sharding like the big difference between then and now is that we just put everything in one big block. It's not sharded in the sense that like we normally think of sharding where it's like these different blockchains that all have different data. Everything is put into one big block. The problem is that's really resource intensive. Like you can't do that on like a consumer laptop or anything.

So we realize that like, hey, we have this specialized role now that we designed because of MEV. Let's just take advantage of that and make the blocks bigger because like they're the ones who are building the blocks anyway. We don't need it to be like super easy to build the blocks. We just need to validate them. So that's what it takes advantage of is now we have this high resource builder who's going to build the block. The whole thing with like the beacon chain block, all of the shard data, like put it all together. And there all the builders are going to send like their block headers along with their bids. And all the proposer has to do is just take the block that has the highest bid, propose it to the network.

And people can take that block. And they'll be able to do data availability sampling and say, hey, if my part was available, like and the execution on like the execution chain was valid to sign off on it. So it makes that proposer role like super super easy where that builder role is going to be a very high resource like relatively special as well. Okay. And so going back to the theme of this particular episode, which is checks and balances. This is separating Ethereum block production into two separate groups of people. You have the consumer consumer people, people that plan on staking their ETH don't know how to capture. They probably have like a Mac laptop or some like home-built PC that they just want to stake their

ethon. But they want to capture MEV. And so the proposer, the proposer builder separation is it separates this consumer group into the proposers. And then it can separate the builder group into the builders. And the builders take all the transactions and bundle it up into a block that's ready to go. And they already did all that computation. And that block is ready to go.

it just needs to be approved by the proposer who is taking their eath. And then the proposer says, like, okay, I will take this block and embed it into the blockchain. How does the proposer choose to select which builders block to include? So they should take the one with the highest bid is what they should do. Um, the what you, you obviously want to make sure that they are like acting honestly. Um, one of the issues, um, one of the issues. with this is now you give the builder more power because they can censor transactions. Like maybe they bid the highest. But they keep bidding the highest for every block, but like they want to censor me because

like they don't like me or whatever. So the builders just never include my thing. That's where something called CR list comes in, censorship resistance list. So the proposal will put out like this list of these are all of the transactions I see in the MMPL. And so when the builder is like submitting their block and like it goes through, they have to either prove that the block was full, so I just couldn't include everyone. So you obviously don't have a guarantee in that scenario or that I included everyone in there. So it helps to like offset that power. But yeah, I mean, like all the proposer really has to do is just take the one with the highest bid.

And so it's outsourced all of the responsibility of collect capturing as much MEV as possible. to this other group of people who have to compete with each other to bid the highest. What's the incentive for the builders to be builders? Can you just walk us through at the basic level? Like, why would a builder, what's the value in being a builder for the builder types of, for the builder role? Yeah. So they're the ones who will directly get the MEV and the transaction fees out of this block. So that gets paid to them. Like searchers will bid to the builders like, hey, I'll pay you this much to include my bundle. Another search will bid to them, I'll pay you this much to include my bundle.

And the builder will get the transaction fees out of that block. And then that's why we want to have at minimum enough builders such that there's an efficient market. Because if there's an efficient market, every builder should bid up to like the maximum value of whatever they can get out of that block. And then so indirectly, all of the value of that block then flows over to the validators. because obviously if you have an inefficient market and there's just like one super builder, well, then I could just take all the money and then I could just bid whatever.

But as long as you have an efficient market with like enough builders, then they should be able to bid up to the full value of what like that block is. So that all the value flows indirectly to the validators, which keeps like super decentralized. So once we get to this point in Ethereum's history where we have these builders who are building blocks, what group of people today does that correlate to? Who are the people in the Ethereum ecosystem that will be likely candidates for being builders later on? So that is going to be like actually a new role because the person who's playing that role today is the mining pool operators. The actual miners themselves don't actually build the blocks or do anything.

The mining pool operator basically, they're the one who does it. And then they send it to like the winning miner and they put their proof of work and like prove that the block. and like prove that the block is good. What's going to happen with this MEV boost, which is what will happen like initially after the merge, which is like this flashbots program, flashbots is going to run the builder and the relayer to start. So they'll be the ones taking on that specialized role.

And then the searchers are the ones who just submit bundles. So they run a specific strategy and just say include these transactions, like a little piece. The building is like a separate process because it's not, just figuring out like specific strategies. It's how to take all of the bids that you were given and like optimize like with some algorithm, like what's the best way to put them together. So that's going to be actually like a pretty new role.

FlashBots is going to be taking that initially. Okay. And then looking to like kind of progressively decentralize that and allow like other builders in. And then when you get to full PBS, it'll be like totally permissionless like anyone can do it. And like hopefully by then especially because it may be boost will it decentralized. Like enough people know how to do this. is like there should be parties we're doing at that point. Okay.

So the people that are running MEV bots today, are they the likely candidates to become searchers in the future? The people who are running MEV bots today, yeah. Like pretty much nothing's going to change for them. If you're running, if you're like an MEV searcher today, right now you're just submitting like to miners. Like after the merge,

you'll be submitting through MEV boost like to their builders. And then like after a proposed or builder separation, like you'll just be submitting your bundles to, like the builders and that. But all like MEV searchers, like they for the most part run like a single or like a couple optimized strategies of like I'm just doing like arbitrage on this or I'm just doing sandwich attacks here. Like they're not able to build like what is all of the MEV out there most efficiently. They're running like two or three strategies. So the builder is going to be that new role of taking all of those things and like putting in them like into a block,

which the operator is doing today. Cool. So it's like a meta searcher. Right. And so we have like some searchers are doing are making sure like there's a balance between balancer uniswop and sushi swap and so they are having they're taking the best arbitrage opportunities there and that is a highly competitive market that will be many many searchers for and then there's like the liquidation searchers so the people that liquidate people on compound and ave and other borrowing money markets and those people have a highly complex highly refined strategy and they compete in that realm and then there's like 17 other different sources of of MEV in the ecosystem. And every single source likely has its own searcher. And the searchers produces bundles, which bundles up all the MEV that they can capture out of the MEV opportunities in Ethereum. And then the builders take all the searchers bundles,

and they bundle it up into one single block. And then they propose that to the proposers. And the proposers accept the highest bid, which likely comes from the most efficient collection of MEV from all the searchers coming from the most competitive builder going to the people that are just staking ether. And so all of this work that goes on behind the scenes from all the searchers collecting all the MEV and all the block builders competing to build the best blocks ultimately

gets captured by the single solo staker who's just staking Eith on their Ethereum node and they didn't have to worry about any of it. That's pretty cool. That's pretty cool. Yeah. There's a lot of like steps to all these specialized parties, but like that's the beauty of all this is it just completely abstracts all of that away. I as a proposer need to say that's the highest bid. Like good.

Simple. Like that's pretty much it. Simple. And something that Vitalik said in his endgame, which you cited in your article, is some centralization is needed to scale, which is like, you know, centralization. That's like a bad word in this industry. And additionally, with this whole proposal builder separation, we're going to have people on their tiny little consumer laptops. And then we're going to have other people with their supercomputers that are competing against other people with supercomputers. And so we do have this stratification of like, we do kind of have this alt layer one super node type setup in Ethereum.

But it's okay in this version because of the checks and balances by this proposal builder separation. Would you say that's a fair take? Yeah. You still want the builder to not be like literally one guy at like Google who needs like this ridiculous computer to do it. Like you want it to be enough that it's decentralized enough that like you have an efficient market and that you don't have to worry about like liveliness concerns that like, oh, it's five builders in the same place and like some regulators just going to go shut them down. And the hardware requirements that we're talking about for these builders like it's like running a GPU and like having like I think it's like two and a half of gigabits like at least bang. end with like those are like those are like high resource requirements for a regular person but like like just on your consumer laptop you can't do but like they're not like these crazy requirements that

like it's decentralized enough that like we shouldn't have to worry about with all these checks in place about like censorship or like liveness from them and then we're just relying on the decentralized validators at the end of the day who like they're the ones who are like ultimately still going to like sign off on everything would you say that it goes from a proposer you can do on your regular like consumer laptop and then a builder you kind of need a high-powered gaming computer. Is that a fair take? Yeah.

You would need like a GPU or like a really high-end like CPU and like a very good internet connection. Okay. And to be a proposer, like I could do it at my laptop. Like it won't be crazy. Okay. So those are the three things that finishes off proposer builder separation, which I do think is like the most fun and interesting part of this conversation because

that's where we start to talk about who gets paid ether. But I do want to like kind of compare and contrast this to other L1. scaling strategies. And so at the highest of levels, how does Ethereum's like roadmap with all this stuff differ from the strategies of like the generalized alternative layer one? How would you classify that? Yeah. So there's a few different approaches. One approach is like simplified as like the Sala approach, which is for the most part like you make some optimizations to the execution environment like parallelism, et cetera. But mostly you get like a lot of your scaling out of like entire hardware requirements. Like you need higher hardware requirements to run

a full node and that like lets you like process more transactions. Downside of that obviously like I can't like check. Like I can't like run like a validating node or like be a full node of Salana like on my laptop. Like it's like it's not a reasonable constraint for me. So that's trying to like, all right, let's jam everything through one chain. The other vision would be more along the lines of like avalanche or Cosmos, which use like subnets and zones respectively saying, okay, one chain is not enough. We'll split up a boss cross a bunch of chains.

problem with that obviously is a fragment security and you probably end up with like pretty small like not super secure like validator sets for a lot of these things and you're still just like trusting the honest majority of them like you're not going to have people like running full nodes and validating like all these different subnets and zones like you're trusting the honest majority of them and you're fragmented security across all of them and then there's like the modular vision approach um which is like Ethereum, Celestia polygon of veil where hey we're going to be this base layer. then we're just going to let roll up slow on top of us.

And they can inherit our security and run at like really low resource requirements for users who like just need to be like checking proofs basically. And from that, like they will have like the full security and like the higher throughput all in this like interconnected network. And talking about a line from one of your other reports and you alluded to this, but with the component that I want to lean into, you say many monolithic ecosystems such as avalanche and Cosmos. can achieve meaningful scale. However, this fragmented security approach inherits far less value capture back to the base asset. It will instead disproportionately accrue

to subnets and zones respectively. Can you talk about the value capture part of this thing and how that fits into this conversation? Yeah, yeah. So that's a big difference of this. It's like effectively when you look at either Avalanche or Cosmos, they're not inheriting security

from like the primary network or like the hub or anything. So there's no reason to like pay like that main network. And so you don't. Like they run like each zone and each subnet. Like they run their own validators and they get paid the fees for that chain. Like anything that gets paid or burnt or anything like that goes to them. That's obviously not the case with rollups.

And that's where you get like a real staking yield and all of these things. Like out of them not just like a made up like staking yield that like it's inflationary and you're giving out money. like roll-ups will continue to pay back to the L-1 like fees and at the same time like Ethereum will continue to have like its native execution environment that also has like that is ultra-secure and that you're getting like settlement to the L-1 like everything gets paid back to it still. Okay. John, this is a lot.

This is super complicated. How long did it take you to actually go through and like understand all these things? So I started working at Delphi two months ago. And prior, so these were my first two reports. Prior to that, I got interested in crypto last year, like beginning of last year. Basically it started like buying Bitcoin when it was going up because I was like this is going up. It got really interested in D5 around like April, May, like just in time to get wrecked by the crash there. And then over like summer, it's like end of the year was,

actually when I found like you guys. And like that's when I started to get like red pulled on like the whole like modular like vision. Like the first time that I ever first like understood like, okay, what is the modular approach? Like how do these roll ups like actually scale? Was the like ultra scalable Ethereum article that you put out like end of October? And like that's when I like had the like, oh shit moment when I remember when I got to the part of that where like you start to realize like how these modular things scale is they actually scale by getting more decent. which is like a crazy realization because as you have more of these like decentralized validators saying the data is available, you can safely increase throughput even more. And then like you just keep adding more and then you can add more data availability throughput,

which means more roll-ups, which means more transactions. And it's just like this virtuous cycle. So yeah, I mean like I first got into like looking at modular like six months ago and started full-time like two months ago. So it's all out there on the internet. Yeah. Can you just explain for the listeners, what it's like to people talk some people go down the rabbit hole pretty damn fast but i would say you've gone down the rabbit hole faster than i've ever seen anyone go down the rabbit hole can you just talk a little bit about like what that's been like for the last few months for people who are like perhaps sitting on the edge of the rabbit hole thinking about like do i dive in or not and like do i get a job in crypto like how much do i commit myself to this can you talk a little bit about

just like how you got versed in these things that are like like super super niche, like polynomials are one thing, but then we can get into like erasure coding and all that stuff. Like, I don't even understand this. And from what I've gathered from you, you didn't understand it either more than like a couple months ago. So like, can you explain for the listeners, like what that's been like? Yeah. Like, I would definitely encourage people to like, if you are really interested, like dive in. Like, I was like slow on that for a while. Like the first like eight months or whatever the longer that I was in crypto. Like I was spending like a little bit of time on it on the side, but I was like, like, I wasn't thinking like, I was probably going to go do this as a job

kind of thing. Once I got into like the whole modular, like from like from you guys, I then found Polynia. And that's when I just like, I went through like all of his stuff over like end of last year, like beginning of this year. And that's when I hit the point of like, okay, I'm going to go do this as a job like full time. Like I enjoy doing this like after my job in banking like way too much. Like I need to just like spend a couple of months like really learn all this stuff. and then just like immediately start like go interviewing. So like that's what I ended up doing was like, if you just like bust your ass on it, like like literally everything is out there.

And like that's what I did. Like I like basically read like a ton of Polyneaya for like a couple months. And then like I put out like a modular related post and then like started interviewing from there. And like it moves really quickly. Like that is one of the really cool things about like crypto that is like very, very different. Like no one really cares what your background is. Like if you're smart and like you know your shit like you'll get hired.

Like all of it is out there. on the internet. Like it's, it, like, it was a lot of fun. Amazing. Amazing. Well, John, fantastic work on this report. I'm going to have to go listen back to this podcast again. I'm going to have to read your report again to fully understand it. But again, for the listeners who brains feel a little bit broken, I'm with you, but all you have to understand is that there's a separation of powers that puts power and keeps power in the hands of the individual, the people that hold and stake ether at home. And so the cool thing about Ethereum is if you are just doing that, that is enough. John, thank you so much for

diving into the very technical parts of the Ethereum of roadmaping, explaining that to us here on the Bankless State of the Nation. It's fun. Awesome, Bankless Nation. You guys know what to do next. There's a link, going to be links in the show notes, linking to John's report, both the one that we were talking about the majority of this podcast, as well as his other report comparing Ethereum to other layer ones. As you all know, ETH is risky, crypto is risky, defense. is risky. You can lose what you put in, but we are headed west. We're on the frontier. It's not for everyone, but we are glad you are with us on the bankless journey. Thanks a lot.