On The Brink with Castle Island - Jon Charbonneau (Delphi Digital) on Building for Censorship Resistance (EP.359)

Episode Date: October 10, 2022

In this episode, Ria sits down with Jon Charbonneau from Delphi Digital to discuss layers of potential censorship on Ethereum post merge and proposed solutions. We dive into: The supply chain of block production The importance of proposer builder separation Options for avoiding de facto censorship by builders The road to scaling Ethereum via danksharding Comparing approaches to data availability Further reading:  Jon on Substack, Censorship, What Do? Follow Jon on Substack and on Twitter Cover image meme credit: Jon on Twitter

Hello everyone. Welcome back to On the Brink. This is Ria from Castle Island Ventures, and today I'm excited to share this episode with John Charbonneau from Delphi Digital, who's quickly emerged as a leading voice in many important conversations, including in Ethereum, scaling, M-E-V, and more. I initially wanted to have John on the podcast to talk about scaling Ethereum, which we definitely touch on, but we actually ended up spending the bulk of the episode discussing censorship and the different tools at our disposal to prevent it, given the more imminent focus on maintaining censorship resistance on Ethereum. We talk about how John has managed to insert himself at the center of some of the most technical debates in the space, revisit the core properties Ethereum is optimizing for. We review the block building supply chain and talk about the

risk of censorship at each phase of the journey, and then discuss different approaches to address it, most important being proposer-builder separation. So without further delay, here's our conversation with John. Hi, everyone. This is Rhea from Castle Island Ventures, and today we're joined by John Charbonneau from Delphi Digital, who's written the Bible on Ethereum and on roll-ups, among many other excellent pieces of work. John, the only regret I have is that we're doing this as a podcast and not a video interview where we can project your memes to make all of this technical speak easier to understand, but you can't have it all. So I wanted to have you on to extend the discussion that I had with Christine from Galaxy a couple weeks ago and talk about

Ethereum's longer term roadmap as well as how it compares to some other L-1s and modular blockchain ecosystems. But before we get into that, tell us about you. What were you doing before crypto? When and how did you get into the space and join Delphi? Awesome. Thank you. Yeah, happy to be on, fan of the pod.

Yeah, so I am very new to crypto, honestly. I only started working at Delphine April this year. It's my first job in crypto. I started paying attention to crypto basically, I'd say the earlier part of last year, mostly because it was during COVID and I was kind of bored and it was starting to make headlines. But basically started paying attention to it. I had a traditional finance background, unfortunately. But I basically started to make attention at the point where you had a lot of the real, you know, big traditional.

investors who were starting to talk about this thing, Bitcoin, how it makes sense is the store of value and all that, started paying attention to it for that, was, oh, okay, this is interesting, this makes sense for macro, started to pay attention to it more throughout the year, just, you know, Defi was kind of a natural interest and fit for me. It was more of a side hobby in large part because Defi is, especially then, mostly just, like most of the stuff that was really popular was, you know, a lot of Ponzi game type stuff. It wasn't quite what I wanted to go to full-time yet, but it was fun on the side. And then I started really paying attention to the type of stuff that I focus primarily on now. So broadly infrastructure type stuff, like layer ones, layer twos, you know, what's MIV, all that

kind of stuff right at the end of last year. And then once I started reading about all that stuff, that's when I got really red-pilled on, you know, how this stuff could really be used. Like, this stuff is just super, super-interesting. Kind of combines a bunch of my interests. So basically just spent the next few months from there just going all the way down the rabbit hole reading whatever I could. And then a few months later, I was finally ready at the point where I was spending more time inside reading about crypto than doing my actual job in banking. I kind of figured at that point it was probably a good idea to finally make the jump and come on over and spend a ton of fun. Yeah, I can totally relate to that. I went through a similar process a few years ago, was also in Tradfi and just.

ended up procrastinating doing my actual work by reading about crypto. And yeah, it's really impressive how you've managed to insert yourself in the center of some of the most technical questions and challenges that the industry is grappling with today. How did you manage to get that understanding at such a deep level and be able to explain it and break it down in the way that you do. Like, talk about that a little bit because it's really impressive. Sure. So I'd say there's a few things to that.

I mean, one part of it is, like, the short answer is there's no easy shortcut. Like, quite frankly, I just spent a ton of time on this stuff. And I honestly, like, spent significantly more time on crypto now than I was working at my banking job before. Like, the reason you can do that, though, is if you are legitimately really, really, really interested in it. When I was working in banking, I wasn't exactly going to get excited and go read about asset back securities on the weekend.

But I will read about stuff that, like, I am really interested in now, and that gets to be my job. So definitely just focusing on the things that you find really, really interesting. That is always what's going to keep you just super, super motivated to be able to spend a lot of time on this stuff. And that, like, that is realistically what you need to do. And then I'd say to at least to some degree, try to specialize a bit in something, especially if you're trying to ramp up pretty quickly. Like, I certainly don't spend a lot of my time looking at gaming and NFTs and stuff like that.

Like, I think that there's cool stuff going on there, but it's just not the thing that gets me, you know, super excited to go read about this stuff all the time. And, like, it's just nearly impossible to cover everything today, especially if you're just starting out. So finding the thing that you think is really important and also just really interesting to you personally is the way that you're going to be able to get really, really good at that thing, as opposed to trying to just look at absolutely everything. There's just so much going on. As far as being able to like explain stuff, more simply, I think that's honestly where it helps that I have absolutely no technical background at all. Like I was a liberal arts major. I was working in finance before this. So when you read all the scary research papers with math and code and stuff in there, I cannot understand those when I read those, like, at first.

Like, I just don't have any of that background. Literally the only way that I can't understand this stuff is if I understand it from just, like, the most basic understanding possible. Like, I think that actually helps a lot of people being able to explain it, like, pretty technical things in much simpler terms is when you lose. literally have to learn it from the ground up, which is how I have to learn all this stuff. Just for the benefit of the audience who, I mean, I hope everyone is familiar with your work, but for the ones that aren't, talk to us about what your focus has been since you joined Delphi.

Like what exactly are the rabbit holes that you've gone down? Sure. So the first report I did was this is one that they had just kind of assigned to me. like right after I joined, it was just a broader, like, and a good fit kind of for my background. And where I was, just how do you think about different layer ones and value capture? Is that important? Like, what are the differences across chains? That was really interesting to work on. After that, I've picked the topics that I've been working on.

So the next one I did was that a big Ethereum report after that. That is what I really, really wanted to do because it was just amazing to me as someone who just joined the space that. Okay, so clearly Ethereum is this big thing. You know, it's the biggest thing going on that, like, everyone's talking about, everyone's working on. And its roadmap has gotten to the point where there's just so much going on and it's so complicated that the large majority of people just, it's impossible to keep track of, like, all of it and have a really good

comprehensive view of it. And I was just, okay, so as important as this thing, obviously, it's just most people don't fully understand it. There was no big comprehensive report out there on, you know, putting all the pieces together of, you know, how does, you know, statelessness and dank sharding and proposal builder separation, like you can look at all them in isolation, but like why does this actually fit together into a cohesive kind of vision? So that was what I did for the Ethereum report was just trying to put basically everything together of just covering everything. It was a ton of fun doing that. was able to learn a lot, just going through that. And then the next one I did after that was, okay, so I have a reasonable understanding of

what the spatial area is, what are they building for? The obvious answer to that for a theory is they're building for roll-ups. That's the way that they're going to try to scale, and other chains are new and similarly. So from there, I want to understand, okay, well, roll-ups themselves aren't this one, like, simple thing that there's only one way to build it. is a million different ways to build them and different chains are approaching them differently, whether you have sovereign roll-ups or traditional smart contract roll-ups like you see on Ethereum, there's all-3s, there's all-2s, there's all these different things.

So just trying to understand what those differences are. And then the latest thing that I've been working on for the past, like, month or two, is I've mostly been looking at MV because that just plays such a central part in how all of this stuff has to be built. and that's just really, really fundamental to designing any of these systems. So I've been spending a ton of time on that lately. And I'm looking forward to finally putting out some reports on that soon. Yeah, your hitchhiker's guide to Ethereum touched on MEV, which was definitely helpful context. And, yeah, I think that's something that Christine mentioned, too, is just that there's so much going on in the Ethereum ecosystem.

It's impossible to keep a pulse on all of the moving pieces. And also, if you're new to it or just haven't been as plugged in, just figuring out what to prioritize learning about is really hard. So, yeah, I highly recommend people to check out the Ethereum report. It was really helpful to just think about, okay, what is the community thinking about near-term versus long-term? like what are all the interim steps? And yeah, I'm hoping we'll get into all of that in this discussion. One thing that listeners are probably super familiar with, but maybe is just helpful to establish a tone for the conversation

is talking about what core properties Ethereum is optimizing for, you know, across decentralization, censorship, resistance, composability, and so on. How do you think about that? So the biggest thing that everyone, obviously everyone wants is, you know, what's scalability. Like the stuff that we have today is obviously not even remotely capable of supporting, you know, this vision that everyone has of, okay, how are we going to onboard the billions of people onto this, you know, running finance and culture and all that kind of stuff on the blockchain? Like the stuff isn't ready to do that. So how do we get a lot of transactions? That's kind of the simple view of scalability is just like how do we get a bunch of transactions?

What I think is the more accurate view of scalability is how do you get a bunch of transactions while also actually keeping requirements for users and nodes very low so that you actually retain decentralization and like all the properties that come along with that in a blockchain? Because otherwise taken to the extreme, you just end up with, okay, we can run a million transactions on some chain, but if the way that you do that is just by increasing basically the hardware requirements of like what you need to be a node on that chain just so vastly high such that you know there's basically just one guy with a supercomputer who's running this and it's like Google or Apple or someone who's just running the whole chain. Taking to that extreme,

well then you've obviously just kind of lost everything that a blockchain mostly gives you at that point. So it's not really scalability. And that is like the big point of I'd say Ethereum and broadly the other chains that are approaching as somewhat like what you hear as a modular roadmap, which is in particular for Ethereum and for some others. Basically, it's the roll-up center of roadmap is what you'll always hear. That's the way that Ethereum is trying to scale. And the basic idea being you could have these roll-ups that can give you a bunch of transactions, but while also retaining those properties of, okay, it's really easy for me as a user to go use that chain.

and I can check that all the data is available, and I just get some proof that, hey, all the transactions are correct, so that now I don't have to run a full node for everything that's going on and run every transaction, which is just impossible to keep up with at a certain point. So that is broadly the direction that Ethereum is going. As far as the composability point you mentioned, I would say that there is probably a bit of a sacrifice there

compared to the way that some other chains are going to scale, at least to some degree. Like, obviously, composability just natively is going to be inherently the easiest when you just dump everything on one chain. You get all of those, like, cool things that you could do really easily, whether that's like flash loans, stuff like that, that just kind of requires stuff to be tightly coupled. You get that just native atomic composability synchronously between everything. So it does become a little bit harder as you introduce many chains to do stuff like that. So there is some tradeoff there. That being said, the large majority of use cases, I would say,

don't require that level of synchronous composability. And you still certainly can put those things together on some chains, like as it's needed. But you probably don't need to have all your NFTs on the same chain as, you know, where you have a Dex or something else like that. Like, they don't need synchronous composability. Really good asynchronous composability is perfectly good. The fact is that requires way better bridging than we have today.

But that is the hope that we'll be able to get there. And so back to kind of that original point, it's like scaling while remaining decentralized. That is obviously a really, really important part. That second part for Ethereum is remaining decentralized. I tend to view decentralization not as this kind of inherently valuable thing, but more so a bit of a means to an end. It's the other properties that you get from decentralization that are really, really valuable. Things like what we are hearing right now, censorship resistance is obviously pretty front of mind for everyone in the Ethereum community.

And obviously, stuff like centralization can start to degrade that assurance of stuff like censorship resistance. Because if you're just all relying on one party and you know, you can't run a node and you don't know what anyone's doing and there's only one person who's making all the box, they start to be able to exert a lot of control over the network. So what you really want to do is find ways that you can get all of those transactions. But at the same time, not be incredibly reliant on centralized parties such that they could start to do stuff like censor transactions. And then you just have no recourse beyond that. Yeah, I agree. I think censorship resistance and permissionlessness are just core value propositions.

that gave rise to this whole industry in the first place. So it's really important to maintain those. And so I want to start the discussion with censorship given that. And specifically censorship by protocol actors or actors at the most primitive foundational level, I would say that's arguably the most imminent to address, given that, you know, apps and infrastructure are built on top of that. you want to have censorship at that level. Could you walk us through the different actors that exist at the protocol layer post merge

and then talk about how each of them could contribute to censorship at the protocol level? The timing of the merge definitely made the conversation trickier, just because everyone's trying to kind of catch up on, okay, who were all these new actors now that we need to pay attention to. And that kind of supply chain did change a lot after the merge. So the basic idea of what Ethereum has been driving towards as we move to proof of stake is something called Proposer Builder separation, which is the basic idea that any validator in a proof of stake chain by default, they're really doing two jobs when you think of it logically. They're both making, they're building the block. Like they're actually deciding, hey, I'm going to put all these transactions that I see into this order. And then they're going to take that block and they're going to propose it.

to the network. The thing that Ethereum has realized over the last couple of years is that those are actually two very distinct roles, and they can be separated. And it's actually really important to separate them. The main reason being because that building role has an inherently very centralizing force on it. And that comes up as a result of MEV.

The reason for that being is because when you're in that privileged position of I get to decide, all of the transactions that go in this block and they go in this order, you're able to extract a significant amount of value, likely beyond whatever is just the naive gas price ordering. So if I just take all the transactions at the MEP pool and, you know, I put them into this block and I just order them by gas price, I'm probably going to make a lot less money than the more sophisticated guy who can aggregate a bunch of bids from people who are trying to extract MEP and will say, hey, I'll pay you this much if you put my arbitrage transaction in that block.

I'll pay you this much if you know, you put my sandwich attack in this block and all that kind of stuff. So what you end up with is a centralizing force because now what you realize is the more sophisticated actors, the more sophisticated builders are able to extract a lot more value from that position. So if you just don't do anything about that, the end result of that is basically the validators set just becomes really centralized. because if you're unsophisticated and you're only earning, say, a 5% yield on your staking, but the really sophisticated guy is getting a 10% yield on his staking because he can extract all this extra MPUB. Well, then, one, just by the math, that person is going to compounds their share of the network because they're just earning more EF and staking it every year.

And also just I'm highly incentivized if I'm the unsophisticated person just to kind of say, screw it. I'm going to unstake, I'm going to, like, delegate to this person out of protocol all and just give it to them and say, hey, can you get that 10% for me, please? You know, you could take a little fee, but I'm going to earn a lot more if I let you do it for me than doing it myself. So what proposal builder separation does is it strips those two roles apart so that validators don't have to do that building role anymore. All they have to do is just see this block that's created by a builder, take the one

that likely has the highest bid, and then just pass that along to the network. And that gives you the property of you can remain really decentralized because now you could have any, you know, random dumb actor can be a validator and they've a really simple job. And they're able to get all that MEPs so that everyone should be able as a validator to earn basically the same rewards, which keeps the protocol very decentralized. So eventually, proposed to build a separation will be enshrined into the Ethereum protocol itself at some point, where there will be like an actual auction that is basically run in protocol where bill. builders are going to submit their bids and proposers just pick among them. The way that it works today is, I'm sure, as most people have heard, is we have what's called MEP Boost, which is a form of proposer builder separation. It's basically just an earlier version of what Ethereum will eventually implement

with proposed or builder separation, just in a more out-of-protecal-trusted kind of manner. the main difference being as opposed to the builders bidding directly to the proposers, there's now rather a different party that kind of sits in the middle of them called a relay. And that party kind of serves the role of trying to remove the trust that builders need to put in the validators. Because otherwise, like the reason all the MEV like auctions kind of worked in proof of work Ethereum is because flashbots would basically just send bundles to the handful of big mining pool operators that they trusted. And they would just trust them that if I send you these bundles of like, these are the bids I want to include, please don't steal these.

But they can see them and they could steal them. So that doesn't scale if you want to allow, you know, thousands and thousands of validators. You can't trust all of them. So what you need to do is implement what's called like a commit reveal scheme where basically that person, the relay in this case, needs to submit their bid and a block header to the proposers. And the proposer will just select the one that has the highest bid and say, okay, I commit to this block header without seeing the actual block body itself. And then after that, they will actually reveal the block body.

So that removes the trust because now if the proposer tries to see the full block body and then just go off and propose a different block, like let's say they see the block. and they realized, oh, as a bunch of MEP transactions, I could steal these for myself. I'm just going to swap in my own address with these and make all the money. If they tried to do that, they would be slashed because they already signed the initial blockader. So this kind of commit reveal scheme removes that trust that you need, so that allows you to keep all of these decentralized validators.

Eventually, that relay rule will go away once you have an in-proticle auction, because then you just have what will happen is the builder, can just do that bid directly. And there will be an unconditional payment in protocol. So basically what that will mean is the builder can submit their bid to the proposer and they will have an unconditional payment that's attached to that. So even if, let's say, they propose it and the proposal, sorry, the builder sends the block to the proposal and the proposal agrees, okay, I'll take this bid.

If after that, the builder just decides not to send a block or they send them an invalid block or whatever else, the proposal gets paid regardless. So that's how we can get rid of the relay rule when you move to the proposal builder separation. In the interim, you do have that relay rule that sits in the middle. And so they're kind of like they're the trust and counterparty that both sides have the trust and they just kind of sit in the middle. So when you set up Mev Boost, which is what validators will use today if they want to outsource block building, which roughly half of validators are doing right now and roughly half are just building the blocks and something. You're still perfectly allowed to do that.

So what you'll do is you'll decide, okay, I'm using that boost. I want to connect to relays X, Y, and Z. I will accept blocks from that. The result of that, which is why there's been more concern around censorship lately, what happens is if you are accepting blocks from a relay slash builder that is censoring, and they are the ones that are the highest bid, so you're choosing their blocks, well, then even if you as a validator don't feel that you're legal, obligated to censor, which is an open question with all of the OFAC and tornado cache stuff going on.

If you're accepting blocks from a relay slash builder that is censoring, well, then the block that you produce will be censoring regardless. And I just want to pause you there. And that's changed post the merge and post the adoption of MEV boost because before block builders would see. send proposers bundles and proposers could include transactions that the block builders might have censored from those bundles, but now they can't do that. Is that right? Yes, exactly. So in the previous one, because they just relied fully on trust, it was totally okay for Flashbots to just send

bundles alone to the miners. And then, so, yeah, so previous, Obviously, Flashbots had never been including OFAC transactions in the bundles that they were sending along. It just didn't matter because when they would send them to the miners, they were just sending them the bundles, not a full block that they had to pre-commit to because they just trusted them, that they won't steal this thing. So what happened is the miners could just take those bundles, they could stick them at the top of the block, but then they made the rest of the block after that. So as long as they weren't further deciding to censor on their own, all of those OFAC transactions or any other censor transactions, they made it into the block. You can't do that anymore in Meth Boost for that reason I was describing earlier of we can't just trust the proposer anymore because if you rely on needing to trust them, well, then the reality is that you're only going to trust the handful of really big guys. Like it's probably okay to trust Coinbase and, you know, some big exchanges that they won't steal your MEP. But you're not going to trust the little guy proposers.

So that effectively cuts them off from being able to earn these rewards and then you end up back in that situation. of now the little guy can't be competitive anymore. So that's the reason that now they send them full blocks. There's no ability for the validators to add any additional transactions after that. They have to commit to the full block without seeing anything in there first. And you just published a piece of writing last weekend outlining different ways to address this censorship post-merge by builders and relays. can you walk us through some of those potential solutions?

Yeah. So the basic idea is like now we have multiple places that you can get censorship from. Obviously validators can censor if they just want to censor themselves. And then the protocol can take actions against that. Like if the majority of validators censoring, you could just have a user activated soft fork. You could slash them. You could do stuff like that. It's a little bit clearer.

As far as relays and builders, the fact that we now have to, And that's really where the risk is at least today, because seemingly large validators and everyone have taken the stance that they're allowed to include O effect transactions. The main censorship today that we're seeing is due to the relays and the builders that most people are connecting to. So that is what you're seeing with the largest relay and builders are, of course, operated by flashbots. and as they were before, they aren't including O-Fact transactions. And the other part of that is also most relays and builders are actually centering today. It's not just them.

It's just that FlashBots has a much larger market share. So while it's unclear from a regulatory perspective what they have to do, that is whatever, what the majority are doing today. So then there's questions of, okay, if you obviously don't want to rely in the long term on just validator altruism. A validator can just say, I'm not going to run MEP boost, I'm just going to make my blocks myself,

and then you don't have to worry about the censorship, then they don't censor. But the problem is that's obviously not a long-term solution to just rely on complete altruism, especially as they're just going to continually lose market share. The reality is, like, you need to align economic incentives. So there's a few ways to go about that. I mean, some of them, which I was talking about, are steps that I think flashbots could take.

One of the big things is you obviously want to have a very decentralized relay and builder market, like, as much as possible. So trying to take steps that promote that. And in particular, promoting non-censoring relays that people can connect to and keeping a very big builder market such that you don't end up with a validator being in the spot of having to decide. do I accept a really high bid from the censoring relay, or do I have to accept a really low bid to use the non-censoring relay? So that is part of it. The reality is like the protocol is going to have to change to try to fix these things so that you don't have to try to rely on just this altruistic behavior.

And there's a number of things that Ethereum will do in the future. I mean, one of them is the fact that Ethereum will at some point implement proposal builder separation. So then the relay goes away. But then you are still in the spot of, okay, now the builder can just censor themselves. And if the builder who's consistently bidding the highest is censoring, well, then you still have that same choice of do I just, do I just have to lose money and not use that builder? So then there's additional ideas.

One of them are CR lists, which is short for a censorship resistance list or inclusion lists. the basic idea of which this is something that would also be planned to likely be implemented or possibly as one of the solutions along proposal of the separation, though a form of it could be implemented earlier, even with MAB Boost, where basically the proposer would get to say when it's their turn, they would get to tell all of the relays slash builders, hey, I see all of these transactions in the MEP pool. It looks like they're valid, you know, they're paying the fee. they all look good. I'm going to publish this list. For you to send me a block that I will accept, you have to include all of these transactions. If you don't include them in the block,

well, then your block is no good to me. So that would force Relays and Builders to include those transactions or just completely miss the slot, which does help. The problem is still with that to a degree if, let's say you have a really centralized builder market and the largest Relay slash builder, who's the most profitable is censoring. The problem ends up becoming, okay, now I as a proposer, the economically rational thing to do is just to publish an empty list because I know that if I publish that list, well, then I can't accept the bid from the highest builder because they're not going to include those transactions in there. So you're again kind of relying on some degree of altruism, which is why something like that, it would be

important to have it alongside a very competitive builder and relay market. We don't want to just have one dominant builder because otherwise you are relying on a significant amount of altruism. If you're relying on a very minimal degree of altruism because all of the builders are they're bidding roughly the same amount, well then I'll just publish the list. And if I lose a couple of dollars, I don't really care. I'd rather just be honest and just lose a couple dollars. But if it's a significant amount, like that does end up being a problem. Say a validator does publish a list of transactions and not an empty list, right? And can't the builder just say, oh, like, the block is full with these transactions that are on your list,

but that are also all compliant in their eyes and then just be like the block is full? Yes. Yeah, that's an important point I should have mentioned. So yes, CR lists and inclusion lists, they would not apply in the circumstance where the block is full. But that's the normal state of things. If a block is completely full and you're using all 30 million gas, which is the limit for Ethereum blocks, well, then censorship is never guaranteed because there's no way to say, like, you know, your transaction paid less, so you shouldn't have been included in the block.

The really good thing about the way that Ethereum's fee mechanism, EIP-1559, works is that it effectively makes this impossible beyond a very, very short time period where you just shouldn't be guaranteed. Because the way that EIP-159 works is it targets a gas usage on average for each block of 15 million gas, but it's allowed to go up to 30 million gas. So the way that that works is basically if, you know, a block has above 15 million gas in it, then in subsequent blocks, the base fee starts to rise. If it's below 15 million gas, then the base fee starts to go down. So what you end up having is, let's say the block is completely full with 30 million gas. If you continue to do that, the price just increases exponentially. So if you wanted to just completely

stuff a block as like a sensor builder just to make sure that you don't have to include other transactions, it would basically just cost an infinite amount of money because the gas price just starts to increase exponentially, and then it's basically impossible to actually pay that cost. So the result of that is the vast, vast majority of blocks that are produced in Ethereum will always have extra room in them, such that this would be able to apply and that you would be able to basically force inclusion of those transactions if you wanted to. Okay, understood. Sorry to interrupt. No, no, right. That's a, yeah, that's an important point. I forgot to mention.

And then, so beyond that, there are other ideas, which are basically, ways to try to have tricks to get around the fact that today, the way that it works in the simple form of PBS, is that the builder slash relay, they are sending a full block, well, not necessarily using all 30 million gas, but that it is an entire block that this is exactly the block that the proposer has to pass along. So once it's revealed to them, they have no ability to alter the block to add additional transactions, stuff like that. There are some proposals that would try to change that and get around that, such that the builder could send a block of whatever they want to include in the block.

So it could use most of the block. They could put all their transactions in there, leave out a handful of, you know, say, there's a couple OFAC transactions that they didn't want to include, and that the proposal will be able to take everything that the builder sent them. and then they would be able to append additional transactions that they want. The risk of doing that in just the naive way, it goes back to what I had said before. If, let's say, you just reveal the whole block to them in the first place,

well, then they could just, the proposer could just kind of screw with the block that the builder sent them, and they could MEV steal, they could steal all the transactions for themselves, and they could propose whatever they want. So there are some interesting ways where you could try to get around that, such that you don't have to rely on proposer trust not to steal, but also still be able to append transactions. There's a couple of ways to do that. One of them, Vitalik actually just wrote about the other day,

is an idea where the proposer will be able to append some kind of suffix to the block after what the relay slash builder had sent them. It does start to get tricky. like that does require protocol changes to do this kind of stuff. There is another kind of similar-ish solution that eigenlayer has proposed before called Mev Boost Plus. The basic idea of that is eigenlayer is there are a protocol that will be launching on Ethereum

about a year from now, something like that next year, which allows validators to restake their Ethereum and kind of subject it to additional slashing conditions. So you could basically have them, do is you could have proposers opt into this Mev Boost Plus thing, restaked or stake. And they would, the basic idea of it is that the builders would be able to send them, the blocks like they had before, the same, you know, this is whatever I want to include in it. And then from there, the proposer would have the ability to append additional transactions.

Because if they did try to steal stuff from that block, then they would be slashed, not through Ethereum, but they would be slashed via eigen layer for the additional conditions that they opt into. So that would be not an in-proticle way of fixing this as opposed to the one that, like, Battalic had proposed, which would be an in-protical way of fixing this, but it's potentially

a quicker way to do it. But yeah, there's multiple ongoing, like, it's a very open question. Like, there's multiple people working on Sierra lists for in-proticle-proposal proposed approval of separation. Those people who have proposals for it in the boost. And similarly, for this ability to append transactions,

ideas to do it before, there's ideas to do it after, which is great to see. This should be kind of the number one thing in Ethereum's mind, in my view, is looking at all these routes right now to like what is the best way that we can mitigate the ownership both very quickly and also in the long term. That should be top of mind right now. But there are a lot of proposals right now, and it is very uncertain, like which ones are actually going to be implemented, you know, what's the timeline of that going to be? It feels like you face a lot of that going to be. It feels like you face a monster that threatens this core value proposition censorship, censorship resistance, and then some new bigger monster comes up, and then you have to figure out how you can use, like,

cryptography and, like, you know, protocol design to deal with it and protect against it. So one thing that I think would be helpful to get a better sense of is, you know, You mentioned flashbots a few times, but maybe talk through if you could name what the ecosystem of like searchers, builders, and relays looks like today. So searchers, people wouldn't really recognize the names of for the most part. there are some large ones who are doing particularly stuff like cross-domain MEV, which is actually really big. So market makers, for example, can do centralized to decentralized exchange arbitrage. That's a really, really big category of MEV,

where there'll be market making on the centralized exchange, and then as prices change there, prices on decentralized exchanges on chain are potentially stale. so that they are kind of arbing that difference between that is one form of searching. There's also just many random bots who are out there who they're running, you know, they could be running very specific things. Like there could be an MEV bot that's only doing liquidations on one protocol or only doing sandwich attacks on, you know, one decentralized exchange. So there's a long tale of actors there.

And they can send their bids to the builder that they choose to send to. And then that builder can aggregate those bids from the searchers and try to build what is to them an optimal block. The builder themselves could also perform searching functions themselves in-house if they want to. They could also just actively look at these things and just try to incorporate stuff that they see as opposed to waiting for searches to send it to them. Some of them can do that. But yeah, the builder and relay market right now is unfortunately rather small, which is kind of part of the problem. like it is very early days. I want to say that there's

six or seven relays that are operating live right now. A bit more builders than that, but it's pretty top-heavy. So FlashBots is by far the biggest relay. And so they operate one relay and then they have,

I believe it's four builders that all connect to that single relay. So they all send their blocks through the FlashBots relay. They, of course, don't include to affect transactions, and they are by far the largest. They have the majority of the market share for their relays and their builders. I'd call it ballpark probably 60% plus, something like that.

Though they have announced, Robert actually just tweeted, I believe it was last night, that their builder in the future would start to submit to other relays, which is a positive step that because their builder is particularly profitable, that I would start to help bootstrap other relays because now those other relays are getting more profitable blocks. So you incentivize more validators to connect to other relays other than just the flashbots relay, which is a good step. Beyond them, blocks route is by far the second biggest relay and builder operator. They currently run three relays. So one of them is the one that they call their regulated relay. So that one is similar to flashpots in that it doesn't include Offect transactions. But other than

that, anything is good to go. They run what they call their max profit relay, which is literally anything is good to go. No oafact filtering, and you could bib whatever you want to them. And then their last one is what they call their ethical one. And so that one is, it doesn't filter O effect transactions, but it does try to filter, well, it attempts to not include OFAC transactions, I should say, at least they have accidentally let a couple through. And then their last one is their ethical relay is what they call it, and that one attempts to filter out sandwiching and front running, but does allow O-Fect transactions to go through. After them, there's a pretty big drop-off. There's a mix of a few others. It's manifold, block-native,

Eden, and maybe there's one more. But they all have pretty low market share at our mix of non-censoring slash censoring, manifolds non-censoring, and then Block Native and Eden, they both do censor O-Fact transactions. But the really important thing from here is going to be seeing can these other relays and builders start to be

competitive and start to increase their market share? In particular, the non-censoring runs is what we would like to see increase their market share and not the censoring ones continue to increase market share. But yeah, that's currently the way of the land today. So I think in your piece, your Hitchhiker's Guide to Ethereum, like one thing you said was, you know, we're moving towards this paradigm where building is centralized, but validation becomes decentralized using proposer builder separation. But it's becoming increasingly clear that we need building to be. decentralized too. How do you, because this is such a specialized function that requires

participation from sophisticated players that have the ability and capacity to build, how do you decentralize that function? So it's going to be very, very difficult. That is probably the biggest question that like people like flashbots and others are. are working on is how can we make decentralized building feasible? It is going to be tricky. And the question is, like, what is enough decentralization slash what is considered centralized? Like, obviously, you do not want one builder. Like, that's very, very clear.

If you have literally one builder who's building everything, then they have a very significant amount of power to either censor, to extract rent, to do all kind of bad stuff. But is it enough to have five really competitive ones that are all bidding competitively? They have a reasonable amount of order flow. Is that enough to give us all the assurances we want? It might be. Obviously, we should strive to keep it as decentralized as possible. And that means, obviously, making the barriers to entry on that as easy as possible.

Like one thing I've mentioned before that, like, I would like to see flashbots and others do, is open source their builder, such that, like, it makes it easier for others to see, okay, this is how I run a builder. I can run a really good one now. That makes it easy just from that side of things. The other part of it is, I'd say the biggest threat probably to having a really centralized builder comes from exclusive order flow. Because basically, if, say, Builder A has transactions,

has access to only the transactions in the public mempool, they can bid whatever amount for that block, say, $100. But if the other builder has access to all those public mempool transactions, but they also have a bunch of exclusive order flow that is only sent to them, then they will be able to build a strictly more profitable block every single time. Because they just have more stuff that they can extract value from. They will bid more, and they will compound those returns. being able to say, hey, I'm winning all these blocks.

You should only send me your orders. You should only send me your bundles because I'm going to get them all included anyway. And there's a lot of reasons why people would do that. Like these builders, they can and do offer services, like saying, hey, you know, if you send your trade to the public mempool, you're just going to get front run and sandwiched. So if you send it to me, I'll keep it private. I promise I'll get it executed. I won't let anyone front run you. and I can give you, say, a rebate because I get to back run you and I can give you some of that money back.

So that's a nice service that people can offer. There's other reasons to do it. The problem ends up being, obviously, as I mentioned, like, that starts to just kind of become a feedback loop where you end up with like one builder. So finding and working on ways for users to get that kind of benefit of best execution and price discovery of like what is my order worth. without having to send it to just one person and hiding it is really, really important. So there's a lot of work on the mechanism design there. That's probably the most important, like, high-level thing.

To try to keep builders very competitive, such that they're bidding, basically that the only, if they have access to all the same order flow, well, then the only difference in their bids is really based on, like, kind of marginal stuff, like having, you know, maybe one guy has a slightly better algorithm or a little bit better view of the M-Pool, and there's just randomly distributed, like what orders they see. But all the bids would be reasonably competitive at that point.

And then I would say there's the little bit crazier, but really cool, more open research ideas of can you make the winning builder itself an actual decentralized protocol? And that is Vitalica. Yeah. So Vitalica talked about that at his like speech recently at SBC. And like I had written an article about it after that.

But the basic idea is, can you make the actual single winning builder, like split among many participants where many participants are contributing and trying to build like a little piece of the block? And then putting all that together in a trustless manner. There's a lot of questions that obviously come along with that, as you can imagine, that are also very open. But, yeah, like there's multiple directions of open research. but yeah, having a decentralized builder market is clearly going to be like one of the most important areas of research going forward. So it's, again, great to see people working on it, but it's also still very open. Like, what is that going to look like?

It's funny. When I reached out initially to record this podcast, my intention was to talk about healing and not this whole conversation around censorship. but it just seems like it was, it's so much more top of mind and so much more important to talk about. But yeah. And I feel like, you know, we just, there's so much more we could still talk about. But I do, we do have limited time and I do want to touch on scaling. So I want to spend the last few minutes talking about that.

And maybe if you could start off and talk about, you know, initially proposer builder separation was a way to, combat censorship or yeah combat censorship and encourage the decentralization of validators. But then I think it was dank rad who realized that you could leverage this new paradigm and apply it to scaling via dank sharding. So could you talk about why proposer builder separation or what dang sharding is and then why proposer builder separation is necessary to unlock dank sharding. I was very happy with the change of focus, by the way.

I'm perfectly good with that. Like, even in that last article I wrote, like I said right from the start, like, developers should be much more focused on censorship resistance than scaling right now. Yeah. But yeah. So dank sharding is the basic idea of like this is what Ethereum is going to do as its long-term roadmap of making Ethereum a really good data availability layer. So basically, you know, we have to have a really good data availability layer so that roll-ups can post a ton of data to Ethereum.

While at the same time, keeping requirements really, really low for validators. That is like something that Ethereum cares about a lot is keeping the validator requirements really low. And so dank sharding is different from the old sharding proposals in that it's not really sharded in the traditional sense of like how we think of sharding really at all. The traditional older sense of sharding was that you basically had a bunch of distinct little chains within Ethereum. And validators would just be operating on their own little shard and they would have that little piece. And then different validators would be operating on their own little piece. And then altogether we would have a bunch of data. Dank sharding is no longer sharded in that way.

Everything is built in one big block together. And the result of that is it is harder to build the block. It does just take higher requirements to like take that amount of data, build the whole block, calculate all the KZG commitments for everything in there. That is a more difficult role. So if you are going to go down that route, you would want to separate the builder from the proposer so that you don't place high requirements on the validators themselves to have to build this gigantic block. They don't have to do that role. They just have to be able to validate and propose it. which is much easier for them to do in the way that it's constructed.

That being said, it's also possible, as I was like kind of mentioning before with like what Vitalik had said, it is also possible to do it a bit differently than what he had initially proposed where you could even have the building of the individual block still split among many participants, which is possibly something that they actually could do in the future if they decided to. Just based on like the KZG scheme that they have, it is possible to do that. even if everything is a moment of block to have distributed building, which is interesting. So the reason that it's still just called sharding at this point, which is a bit confusing, isn't that you have shard chains anymore.

It's considered sharded just because each validator themselves is only responsible for checking a small portion of the data within that block. So when validators are up and they're looking at blocks, they only have to check, say, a couple, basically the data is laid out in this kind of 2D square, and validators will be assigned to only check a couple of rows and columns within that square, such that collectively they check the whole block together. But each individual validator is tasked with just checking a very small portion of that. So that's kept very easy. And that allows you to retain the very decentralized validators that Ethereum has today,

because it's a very minimal data requirement, just to check that a little bit. Got it. So sharding has just taken on a whole new meaning. Yes. Yeah, I remember being very confused when I read that for the first. I'm saying, why is this even still called sharding? Because it's, yeah, it's kind of not really anymore.

It means a very different thing than what sharding used to mean. So that's all well and good. But dank sharding is still a ways away, right? So in the interim, we have EIP 4844 or Protodang charting. Talk about protodank charting. What's that going to deliver? And then when can we expect that to be implemented? Protodank sharding is what we would ideally do.

I would say as the way to scale the data availability layer prior to the full bank sharding being rolled out. The basic idea of it is, and why it would be a very good first step is because it's entirely forward compatible with bank charting. So it achieves a lot of the steps that you would eventually need to implement anyway for full bank charting itself. So it gets a lot of stuff out of the way. It gives you significantly more data availability than you have today.

Still like an order of magnitude less than what full banked sharding would give you. But the main thing that it would do to give a significant degree of scalability is it implements the new transaction type that roll-ups would use to post data to Ethereum. Today, they use what's called call data. In the future, what they would do under protodank charting and then foldank charting is they would have what are called data blobs. So that is the new transaction format that would be used for this. And part of the reason that you can scale it is because those data blobs, they get pruned after some short period of time. So you're not just increasing the node requirements indefinitely. And they will also get their own fee market.

So you would have what's called a multidimensional EIP-1559 alongside this. We're basically the traditional execution layer that we're used to using, you know, go use uniswap on L1. on, all that kind of stuff, that gets a completely distinct fee market that is separate from data blobs, which is different than what it is today. Today, if you submit call data to Ethereum as a rollup, that gets priced right alongside all the other stuff. So if gas fees are really expensive on L1, because, you know, there's an NFT going on or whatever, then the roll-up fees get more expensive to post-call data.

That would not be the case for proto-dank sharding and then full-dank sharding. They would have a completely isolated fee market that's not affected by this at all. And then the reason the big step that you would go from proto-dank sharding to dank sharding where you get even more scalability is because in proto-dank sharding, each validator is still responsible for downloading the full amount of the data blobs that are being posted. Even though they eventually get to prune it, they do have to download and check everything as it comes in. Whereas in dank sharding, that is when you get sharding, at least in the sense that it's meant here.

of validators are only checking portions of the block. So protodang sharding is even more confusing because it's not even the minimal form of sharding. There's absolutely no sharding in there. So the names are quite confusing. But yeah, that would be the main reason why. As far as when it will be implemented, I mean, we'll see, slash if it is.

I would have said before, the hope was to get it done for the Shanghai Hard Fork, which would be the next upgrade after the merge, so at least six months away, I would say. I don't know that that will or should happen anymore, in part because of the reasons I was describing before, I do not honestly think that this should be Ethereum's priority right now. If you have a finite amount of mind share and time between developers right now,

I honestly don't think that this should be the priority. I think that the priority should be for them to be working on inclusion lists and all that kind of stuff, like, what is the best way to get censorship much quicker, like a quicker form of PBS, all of that kind of stuff. I think that should take priority. It's possible to do other simple forms of roll-up scaling before then. An older proposal that's much quicker to implement, that if you needed it, I think, works perfectly fine.

It's EIP-4488, which is basically just reducing the price of call data. And you would need to do some other stuff alongside that. but the basic idea would be it's kind of a quick and dirty way to get cheaper data. It wouldn't, you know, be like protodank sharding and that you get a bunch of forward compatible steps that then makes it easier to get dank sharding done. It's not as ideal. But if you decided that there's a fee emergency and, like, you wanted to help reduce roll-up fees, I honestly think that's probably the better route to go possibly if doing protodank sharding would otherwise divert attention kind of away from the censorship discussion.

We need to get you back on to do a whole another episode on scaling. But since we're nearing our time, I do want to kind of ask a bigger picture question around Ethereum's approach to. So, you know, Ethereum kind of shifted from is shifting from being this like monolithic chain that does. execution, consensus, settlement, data availability to a more modular system where execution takes place on higher layers, but then you have, at least for Ethereum, consensus, settlement, data availability on the base layer. From your perspective, you know, studying Ethereum's approach versus approaches that some other ecosystem, like Celesteia or Polygon Aveil or others are taking, what would you say are kind of,

and this might be really hard to answer in a few minutes, but like some of the tradeoffs of the different approaches. I'll try to go quick then. So I'd say there's two main ones. One is just the roles that they perform. So Celestia and Polygon Avale and some other data availability later they are trying to do just that. They are providing consensus and data availability. There's no native execution environment, settlement, anything like that going on, the layer one. You're not going to be able to have defy living on the L1,

that kind of stuff the way that Ethereum does today. There's benefits and there's tradeoffs to that. Like you have specialization, you don't have to worry about all this extra complexity, stuff like that. Ethereum will retain its settlement layer. And so that gives you certain benefits. Part of it being just a, it's a different roll-up construct, basically.

In what's called like a sovereign roll-up, which I think you will see on Celestia, you just use that base layer for data availability consensus, but you don't rely on it for settlement in the way that traditional roll-ups today have a smart contract sitting on Ethereum L1. And that acts as a trust-minimized two-way bridge between Ethereum and the roll-up. And that is what dictates kind of the rules of the roll-up is that contract. So the straight-offs to that, but that is the primary difference, I would say, between them, is that. Is that Ethereum retains that settlement and execution layer, whereas those others do not?

The other thing, I would say, compared to Celestia is there are different kinds of scalability. Very briefly, I would say. One way to think of it as verification scalability. So how many transactions can you do relative to how easy is it for me as a user to verify that things are okay? So if I'm a roll-up user, I can do data availability sampling of Celestia or Ethereum, and I could have some proof that says, hey, everything's good, the data's available, so I'm good to go. Both of them, I would say broadly do that. Ethereum and others, along with like Igen, I and DA and some others, and some others, also try to prioritize what's called consensus scalability.

So what are the amount of transactions you could do relative to what are the node requirements of consensus nodes? So the actual validators who are working in the protocol. So Ethereum places a heavy emphasis on, you know, we want to have like a million different validators who are all participating in this thing. So it's not enough just that role of users get really easy verification scalability.

We also want validators to have a really easy responsibility, only downloading a portion. of the blocks. So as I mentioned in Deng sharding, validators only have to download a portion of the blocks whenever that's implemented. And something like Celestia, at least as they initially launch, the validators in Celestia, it will be a smaller validator set. They'll use tendermint, and they will be required based on the fraud-proof scheme that they use for their data availability, that all validators would have to fully download all of the data. So it would be a higher requirement to be all-o-s-equal, a validator on Celestia compared to something like Ethereum.

That being said, I was also tweeting back and forth with Nick this morning, and he was saying, like, Celestia can and likely even will adopt the KZG commitment scheme that, you know, others like Ethereum are using, just whenever the tech is, you know, more scalable, more practical, that it's actually ready, because even thanks, charting is years away. And once you adopt that kind of KZG scheme, then you could also make consensus scalability even easier, where even consensus nodes now don't even have to download all of the data themselves. So I would say those are the primary differences, at least at their initial phase, Ethereum will retain that settlement and execution layer, which these other pure data availability

layers will not. And then some have different kinds of scalability, just how you think of it, of verification scalability of users versus consensus scalability of like the nodes themselves. Unfortunately, that's all we have to. time for today. But like I said, we definitely need to get you backs to talk through scaling and data availability and the pros and cons of all these ecosystems in more depth. But John, thank you so much for your time that I'm excited to share this episode. As expected, you did a really great job just breaking everything down. So what is the best way for people to stay on top of all the incredible research you publish and, yeah, connect with you.

Just go on Twitter, I guess. John Charbonneau on Twitter. I think it's J-O-N-U-S-H-R-B, I think is my name. But, yeah, I put pretty much everything on there. Awesome. But yeah, this was a lot of fun. Covered a lot. Yeah, this is great.

Thank you.