Multi-Proposers & The Future Of Ethereum

In this special early access episode we're joined by Paradigm's Georgios Konstantopoulos and Charlie Noyes, along with Max Resnick from Special Mechanisms Group to discuss a possible change in direction for one part of the Ethereum Roadmap. This is a deeply technical episode that covers the history of MEV and new innovations that plan to change it all from the comfort of David's apartment studio, enjoy. ------ 📣 BECOME A CITIZEN | GET 10% OFF WITH CODE: SPOTIFY10 https://www.bankless.com/join ------ BANKLESS SPONSOR TOOLS: 🐙KRAKEN | MOST-TRUSTED CRYPTO EXCHANGE https://k.xyz/bankless-pod-q2 ⁠ 🦄UNISWAP | BROWSER EXTENSION https://bankless.cc/uniswap ⚖️ ARBITRUM | SCALING ETHEREUM ⁠https://bankless.cc/Arbitrum https://%E2%81%A0https//bankless.cc/Arbitrum 🛞MANTLE | MODULAR LAYER 2 NETWORK https://bankless.cc/Mantle 🌐 OBOL | STAKE ON DVs, SCALE ETHEREUM https://bankless.cc/obol 🗣️TOKU | CRYPTO EMPLOYMENT https://bankless.cc/toku ------ TIMESTAMPS 00:00:00 Start 00:05:14 Intro To Our Guests 00:09:21 Proposer Builder Seperation 00:12:39 Stepping Forward vs Patching 00:19:35 Getting Rid Of MEV? 00:26:35 Inclusion Lists 00:40:14 What is Braid? 00:50:43 The Bear Case 01:06:37 Vitalik's Take 01:10:53 The Benefits of Braid 01:20:28 L2 Centric Roadmap Changes? 01:36:26 How's Rust Going? 01:44:49 Other Exciting Roadmap Updates 01:57:52 Call To Action ------ RESOURCES Georgios: https://x.com/gakonst Max: https://x.com/MaxResnick1 Charlie: https://x.com/_charlienoyes ------ Not financial or tax advice. See our investment disclosures here: https://www.bankless.com/disclosures⁠

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:04David Hoffman?

  Bankless Nation, we've got a treat for you today on the show. A pretty special episode, recorded all in person in my New York studio, with some of the three biggest brain researchers in the Ethereum space. Charlie Noyes and Georgios Konstantopoulos from Paradigm, and Max Resnick from Special Mechanisms Group, discuss a possible change in direction for one part of the Ethereum roadmap. Max has recently introduced Braid, which is a development framework for changing how execution works on the Ethereum Layer 1. Instead of there being a single person who proposes a block, multiple people come together using a clever mechanism to co-create a block together. This has properties that Max believes are far more fair and efficient when it comes to transaction ordering and MEV.

• 0:48David Hoffman?

  The part of the Ethereum roadmap that this relates to the most is the Scourge, where Ethereum attempts to deal with the scourge that is MEV and its centralizing and corrupting impact upon blockchains. Multiple concurrent proposers, or multi-proposers for short, Max believes is a better and more elegant way to achieve the goals that Ethereum is trying to achieve with its Scourge roadmap. While Max's Braid framework is not complete and more research is needed, it is nonetheless piqued the interests of many other mechanism designers and auction thinkers that are out there in the crypto space. So today on the show, you're going to hear a history of MEV on Ethereum, and how Ethereum researchers have dealt with the reoccurring monster that is MEV at different stages in Ethereum's timeline,

• 1:31David Hoffman?

  to where we are today with the current Ethereum research and direction. Charlie and Georgios, I would say, are cautiously optimistic about the idea of multi-proposers for Ethereum, whereas Max has stronger convictions about its level of effectiveness and its validity for eventual inclusion into the Ethereum roadmap. This, Bankless Nation, is a very technical episode. I'm going to have to go back and listen to this myself to really understand everything that was said here. I do my best to help some of the less technical listeners along, and nonetheless, I think you'll be able to catch a vibe even if you can't understand everything. But there are some technical terms and like deep esoteric Ethereum research knowledge that is brought forth. We often just didn't have the time to define and clarify everything.

• 2:12David Hoffman?

  We typically leave these technical research-driven podcast episodes for the Bankless Premium RSS feed. This is the feed that I go and cover more specialized content, things on the frontier that I want to go learn about. But since the idea of multi-proposers for Ethereum is so large and relevant, that this one needs to be made public, so that everyone interested who wants to can hear it. But if you want future episodes like this, and all other Bankless episodes as well, ad-free, maybe you could consider getting the Bankless Premium RSS feed. There is a link in the show notes for 10% off if you want to go get that right now. So go get it right now, and also, thank you for supporting independent media in crypto. And now, on to the episode. Bankless Nation, it's SBC week, which is why we have three brainiacs here on the couch today.

• 2:54David Hoffman?

  Just to my right, we got Georgios Konstantopoulos, CTO, and now partner, general partner at Paradigm. Georgios, welcome to my apartment. Good to see you. Likewise, likewise. Sandwiched in the middle, sandwiched by these fine gentlemen, is Max Resnick. What's your role at Special Mechanisms Group? How would you describe yourself?

• 3:11Speaker 01

  My official title at SMG is the Head of Research. So I work on basically market design, mechanism design, protocol research, and other things.

• 3:22David Hoffman?

  Beautiful. Welcome. Welcome to your first Bankless Podcast episode. It's great to have you.

• 3:27Speaker 01

  Thanks for having me.

• 3:27David Hoffman?

  And down the line, at the end of the couch, we've got Charlie Neuss, who has been on the Bankless Podcast before, like, four years ago or something. Very long time ago.

• 3:34Speaker 02

  Good to be back.

• 3:35David Hoffman?

  Yeah.

• 3:36Speaker 02

  Also talking about MEV.

• 3:37David Hoffman?

  Yeah, it was the first episode that we did on MEV on Bankless, right when MEV as a concept was very, very young. Charlie, it's good to have you back. Thank you. Good to be back. And it's great to have just some of the, I would call you guys auction nerds. I think like both SMG and Paradigm, you guys really like auctions. And I think that's kind of going to be the undercurrent of the entire episode today. Going around in the research space has been this idea of multi-proposers. And this isn't exclusive to the Ethereum research community. This has been, I think, blockchain research generally. I know Anatoly from Solana is very bullish on multi-proposers. There's been a recent proposal from Max here called Braid, which proposes to meaningfully change

• 4:20David Hoffman?

  How Ethereum works. And this is not set in stone. This is, there's no consensus on this on the direction, but it's something that we want to unpack here today. And it's highly related to MEV, to consensus, to execution of the Ethereum Layer One. And this is going to be the main thing that we want to focus on and all adjacent topics. But perhaps to even really just get started here, we want to kind of like illuminate the landscape of MEV because this is going to touch a lot of different subjects. Maybe Charlie, I'll throw it all the way down to you. Just about like, what do we need to know about MEV? What do we need to bring up to listeners' brains in order to prepare them for a more in-depth conversation as we go forward?

• 4:56Speaker 02

  I'll give the brief history. So way back in the day, in 2018, 2019, trading activity was starting to take off on Ethereum. It was getting more sophisticated. And some people started to notice that there were behaviors of traders on-chain that were kind of counterintuitive. And in particular, they noticed that when there were valuable opportunities on-chain, the way that people competed for them was getting much more complex. The way that they were bidding in, at the time, what were priority gas auctions. So that was like the original Flashboys 2.0 paper, made some observations about how arbitrage traders were bidding for arbitrage opportunities on Ethereum, and then made some projections, basically,

• 5:40Speaker 02

  about the fact that this behavior was fundamental and that you would also start to see miners get involved in the game. So the guy who wrote that paper, Phil, started a company called Flashbots, which we've been involved in for a while, since the early days. And they created the first MEV infrastructure for Ethereum. At the time, Ethereum was run by miners. And so what it was, was basically this auction where for part of the block, not the whole block, and some set of trusted miners, they allowed, they ran an auction where you could send them transactions and then... They would order them very profitably and give that to miners to put at the top of their block.

• 6:21Speaker 02

  And basically, the argument at the time was if someone didn't do this in like a transparent way, then miners would start to create internal arbitrage trading firms, or like miners themselves would turn into HFT firms. And that this would be bad because there'd be a lot of variation in how profitable miners were. And they would get really sophisticated, basically, and the market would become opaque. And it would be hard to participate in as a normal trader. And so it's better if there is sort of transparent infrastructure for this kind of sophisticated, complex behavior. And then that was arguably the first kind of PBS or proposer builder separation.

• 6:57David Hoffman?

  Right, external PBS. And I think this is when conversations about enshrining PBS also started, enshrining it into the protocol. We haven't actually got there yet, but now we have this idea of PBS proposer builder separation, which is strictly external to the protocol.

• 7:15Speaker 02

  Right.

• 7:15David Hoffman?

  And it's been of a loose social contract that we are going to enshrine PBS once we figure out how to do that. But that's kind of like the current state of things. We haven't figured out how to do that, nor have we actually enshrined it.

• 7:26Speaker 02

  Agree. And it's really quickly. So the type of PBS that we had in the proof of work mining days was actually a bit different. It only built part of the block. And this is important because basically we didn't see censorship the same way that we do now. So Ethereum moved to proof of stake and we moved from MEV GATH to what's called MEV Boost, which is the current out of protocol like dominant PBS solution, also made by Flashbots.

• 7:52Speaker 02

  And basically, the different, one of the big differences with it is that these people called block builders bid on full blocks. So they provide a full block to validators and validators don't have any part in the construction of that block.

• 8:05David Hoffman?

  There's no flexibility.

• 8:06Speaker 02

  There's no flexibility. And they introduced this party called a relay, which previously was just Flashbots, but now a bunch of people operate them, or at least a few people operate them, which basically sit in between the builders and the validators. And the two, the reason for the design decisions basically was as we moved to proof of stake. People didn't want to see a lot of variation in validator rewards. So the same way that we worried about miners becoming like HFT firms themselves. If you had really sophisticated validators that became HFT firms. And then you had like home solo stakers, which weren't or which couldn't participate in the PBS. Like couldn't accept blocks from builders, then they'd have much lower returns.

• 8:49Speaker 02

  And that would be like a centralizing effect on the network. So there's like a lot of complexity that that ignores, but like at a high level, I think that would be the sort of like where we are today in the justification. And then one of the primary downsides from that is censorship, basically. So we took the centralization that we were worried about happening at the validator level. And we basically moved it to the builder level. So today there's two dominant builders, basically. And they construct almost all Ethereum blocks. And they construct the full block. And so whether or not you can get a transaction on chain, not entirely, but more or less depends upon these two builders. So I do a lot of the talking.

• 9:29Speaker 01

  Yeah, I think I would just add one thing, which is that one key difference between MEV-GETH and MEV-BOOST, which is the difference between the proof of work implementation and the proof of stake implementation, is that the trusted intermediary of the relay actually allows you to have more participation. So in MEV-GETH, there was like three big mining pools. And because of the trust assumptions required, those were the only people who could participate. Because smaller miners couldn't necessarily be trusted to stick to the rules of the MEV-GETH protocol. But now with MEV-BOOST, anybody can participate. So even if you run a solo staker, you can participate. And that was one of the key design decisions behind doing it that way.

• 10:16David Hoffman?

  So it's a pretty good snapshot in time, almost up to this point. I do want to kind of zoom out and discuss a vibe of how the Ethereum research community has started to tackle some of these problems. We discover MEV, Flashbots is created, Flashbots creates MEV Boost, a out-of-protocol sidecar that solves some of the problems, and it creates this idea of proposer-builder separation, which is like something that we've considered to figure out how to actually enshrine into the Ethereum protocol. Now, there's also, as a result of that, like Charlie said, there's now relayers as well, and block builders as a separate party have also come up. And we're kind of like incrementally patching problems that are showing up in the MEV space. As we move forward in this lay of the MEV

• 11:00David Hoffman?

  landscape, we're also going to introduce inclusion lists as a censorship resistance patch. But how would you guys describe this like incremental step forward and then incremental patch towards kind of the problem space of MEV on the Ethereum layer one?

• 11:16Speaker 02

  One thing I might say is that a lot of people are not happy with PPS. So like, a starting point for the conversation might be, you know, I think we gave a, we explained the reasons that we pursued this path, which I think were good reasons, understandable reasons. But the state of play today is that we have a market structure that a lot of people, for various different reasons, are not happy with, basically. And I think everybody, regardless of like what improvement you want to see, basically wants to see some type of improvement and positive direction for the protocol, because it doesn't feel good to be like, like basically, the current market structure we find ourselves in just doesn't feel good to a lot of people. And I have like my

• 11:58Speaker 02

  takes on what about it could be better. I think Max, though, has been one of the primary, you know, provocateurs, or sort of...

• 12:07Speaker 01

  I prefer the term researcher.

• 12:09Speaker 02

  Yeah, no, but but seriously, people who have pointed out like real, real issues in the trade offs we've been making. I'm sorry. Yeah, be curious.

• 12:17Speaker 01

  What are those, Max? Yeah, so I think the the main thing that we've been focusing on recently is the idea of a particular type of censorship, which is short term censorship. And oftentimes you hear on Twitter about kind of censorship of OFAC transactions, tornado transactions in particular. At in 2016, Vitalik wrote a blog post and the OFAC of the time was Silk Road. So you kind of hear about that type of censorship resistance. But in that same 2016 blog post, Vitalik also said, actually, short term censorship is really important for the functioning of certain decentralized financial applications. So let me give a quick example. Suppose we have like $1,000

• 13:02Speaker 01

  for sale on chain. And we want to hold an auction within that block to sell the $1,000. Well, hopefully, we should clear for $1,000 and the person who put the money in the pot should get it. But what actually can happen is because of short term censorship resistance, you can submit a block in the PBS auction, which doesn't include anybody else's bid and only includes your own stink bid for like one cent. And then you can pay one cent for the item as long as you get on chain. So what does that do? It pushes all the profits from the auction to the proposer. And the idea of the kind of Flashbot style of roadmap,

• 13:43Speaker 01

  where we do MEV GATH, we do MEV Boost, was given that MEV is inevitable, we should do our best to make sure that it doesn't have other harmful effects. We should quarantine it and make sure it doesn't leak out and have other harmful externalities for the rest of the system. And my point has been. I don't know if MEV is inevitable. I think we can reduce it. And one of the ways we can reduce it is by increasing short-term censorship resistance. So that apps can have more flexibility and can hold these types of auctions.

• 14:15Speaker 02

  Is short-term defined in anything? Is it like one block is short-term? Or is there any like concrete parameter there?

• 14:21Speaker 01

  Uh, we have a formal definition, which is based on this abstract notion of a censorship resistant public bulletin board. And what really matters is, given how much you put in as your tip, which is kind of your protection from censorship, how much protection do you get out? How hard is it for the adversary to censor you? And the more blocks you allow, the more you get naturally, right? If there's five blocks where you can get in, then it should be five times as censorship resistance. Right? As censorship resistant, sorry. And we see that in our definition. But what we're really trying to do, if we're trying to do decentralized finance, is get real-time, strong censorship resistance.

• 15:05Speaker 02

  Meaning to get in, ideally in a single block?

• 15:07Speaker 01

  Meaning to get in in the next block.

• 15:08Speaker 02

  Yeah, or to make it as costly as possible to prevent you from getting into that block.

• 15:12Speaker 01

  Solana cannot comprehend this.

• 15:15Speaker 02

  So I, I want to add one thing that which is, I think that is, that definition of censorship resistance is very useful. I think that some of the conversation, some of the issues that like generated the feelings about the current market structure also relates to like, we have issues with, you know, sanctioned entities by various different countries. Like certain actors in the MEV pipeline, like builders, relays,

• 15:44Speaker 02

  aren't willing to process transactions from those entities. And as like a credibly neutral platform, that doesn't feel like great for Ethereum, basically. There's also this issue of like, even for transactions that don't have value to censoring. Like if I just want to send you some USDC, um, like block build, there's only two block builders today and they might just not pick that transaction up at like a reasonable fee level because they're like, it's not worth it for us to include in the building algorithm. Not worth it for us to add latency to it. And I would say these are not the type of valuable transactions that Macus is addressing. It's not like we're trying to run an auction, but that like is a bad UX for users, basically. And it makes people feel bad because it's sort of just like these actors are just choosing not to include me, basically.

• 16:29Speaker 02

  When it seems like they could.

• 16:31Speaker 01

  And it's absolutely, that's absolutely something we've noticed and have been tracking very closely for MetaMask users for inclusion. So it's definitely an annoying part and it comes back to that idea of like, can we quarantine MEV? If that's all we can do, it'd be great to do it, but right now it seems like it's starting to leak out into stuff like the inclusion of basic transactions that are just kind of low prior fee that aren't on contentious state and are not being included because there's some latency game going on in the block.

• 17:02Speaker 02

  And maybe, George, I mean, Max and I are sort of pseudo core researchers, but as someone who actually spends a lot of time in the sausage making process, I guess I'm curious like what other parts of the conversation we maybe didn't cover. You know, you see in Ethereum.

• 17:15Speaker 03

  I'm generally a fan of the notion that it's really hard to get rid of MEV. When you introduce a mechanism, the MEV is like a little animal that moves around and is trying to avoid your like your measure. So I think one nuance I would add to the conversation, the anytime you introduce a mechanism, that MEV might move to a different part of the, of the system that your mechanism didn't prevent. And you end up in this kind of patch on top of patch on top of patch situation. And the classic thing, which I'm sure we'll touch on, at some point it moves to the network level and other sites can do things that maybe your protocol did not prevent. And you might get stuck in another bad situation.

• 17:57Speaker 03

  So we should apply extreme nuance and deep analysis.

• 18:02Speaker 01

  I think this is a reasonable point and it's kind of the, I would call it the tenderloin cleanup or the mission cleanup point, which is that you go into Gavin Newsom goes into, you know, the mission and cleans it out and cleans it up. And then all of a sudden in the surrounding neighborhoods, it isn't so clean anymore because of the spillover effects. But I would say that the goal of reducing the proposer monopoly is to introduce competition. And so if a lot of MEV is actually a result of the monopoly, when you introduce competition, you're not just chopping up the MEV and giving it to several proposers. You're actually reducing it because there's actually competition that erodes the monopoly rents.

• 18:45Speaker 01

  You have a five-person oligopoly that actually have lower monopoly rent than the one individual. And that's the goal here. But I think it's still important to consider whether it might go somewhere else than this inclusion monopoly.

• 19:00David Hoffman?

  I want to put a pin in that point that you brought up where we have been patching the Ethereum MEV space with improvements. And I would say we have made qualitative improvements to the MEV landscape as the years have gone on, but we just discovered troubles elsewhere as the arc has progressed. And the point that you're saying is that there are strict improvements that can be made at times via research and innovation to the MEV landscape via stronger mechanisms, stronger and stronger mechanisms. And so it's not just about moving it elsewhere and then all of a sudden we rediscover the problems. We are creating better mechanisms, but maybe over the years, the Ethereum research arc around MEV has made soft mechanisms that have been patched on.

• 19:41David Hoffman?

  And I think what we have discovered is that censorship is perma. It's always somewhere. There's always censorship somewhere. But with stronger mechanisms, maybe we could be a little bit more hopeful about having stronger outcomes. Is that a fair summary?

• 19:56Speaker 01

  Yeah, I just personally believe that it's actually possible to get rid of it because that's the dynamics of competition.

• 20:03Speaker 02

  Give the proposer monopoly pitch. Use the term. I would say just, I think you could go into like, make the case for the proposer monopoly is what drives censorship and you can break it.

• 20:13Speaker 01

  Yeah.

• 20:14Speaker 03

  Maybe what is the proposer monopoly?

• 20:15Speaker 01

  What is the, so on Ethereum, the way that your transaction gets on to the chain is that it has to be included by someone called the proposer. The proposer is selected from among the validator set and their job is to propose a block. And so if you want to get in, they need to put you in their block. And they have a 12 second slot. So within that 12 second period, there's only one place that you can go to get on chain. If you want to wait 24 seconds, you can go to the next guy. If you want to wait 36 seconds, you can go to the guy after that. But if you really want to land within 12 seconds, if you're time sensitive, you have to go to that person. So that's why I call it the proposer monopoly.

• 20:57Speaker 01

  It's a temporary 12 second monopoly on inclusion. And 12 seconds might not sound like a lot. But if you went to somebody who works at Jane Street and said, there's 12 seconds where only one person gets to decide which trades are executed. They would be very, very surprised. And they would be like, how do I become that person? Uh, so I can make some money because that is an extremely powerful thing for financial activity. For just transferring stuff around, maybe it doesn't matter too much. But if we're really trying to build a chain, which is my goal in terms of crypto research, which is make the chain good for finance, we really need to address that problem because that's not conducive to decentralized finance.

• 21:39Speaker 02

  The only thing I might add to that is that, yeah, they um choose to sell monopoly into the builder market currently. So the proposer has monopoly on the inclusion and they're basically going to hold an auction and saying, who can pay me the most for this and.

• 21:52Speaker 01

  Which doesn't eliminate it, it just passes it on to the highest bidder, which is almost, you know, whoever can extract the most value from the monopoly.

• 22:01Speaker 03

  Yeah, and that's the problem statement. I think it's also important to define the goals. Like, you can design very different mechanism for, a very different mechanism for achieving just, I think, censorship resistance on its own. So transaction gets in and I think there's a plus plus version of that, which is the, can you actually remove MEV? In the process of doing that. And I think, depending on how much you scope it, the hammer that you have changes. And there are different mechanisms for achieving that. And Max has an idea for a mechanism. Ethereum research has another idea for a mechanism. Maybe the truth is somewhere in between.

• 22:39Speaker 03

  And we need to seriously value trade offs, especially when you want to amend such a mechanism on top of the Ethereum protocol. And what does it mean about things that need to change backwards compatibility?

• 22:53Speaker 01

  Maybe can I just say one more thing on why I think it's possible to end MEV? Basically, there are two parts of MEV. If you look at the original

• 23:04Speaker 01

  Diana Del paper, which is there's censorship and there's reordering. We actually know how to solve the reordering part because we can change the ordering rule. So assuming there's some good ordering rule, we could reorder. The problem is we have censorship. So even if we come up with the perfect reordering rule and that reordering rule says that George's transaction should be first, mine should be second, and Charlie should be third. If Charlie really wants to and he knows the proposer well, he can slip him 100 bucks. And he can be the only person to block and then he's first because we're not even there. And I think basically if you figure out how to do the ordering, which is certainly an open question that we'll get into.

• 23:50Speaker 01

  You push everything to the censorship layer. And then you have one thing to solve.

• 23:57David Hoffman?

  Right.

• 23:57Speaker 01

  And if you can solve that, you actually can significantly reduce MEV, in my opinion.

• 24:02David Hoffman?

  So you're kind of making the argument that since you're solving censorship resistance is proximate to solving MEV.

• 24:08Speaker 01

  I think it is necessary for sure. Maybe not sufficient, but absolutely necessary.

• 24:13David Hoffman?

  Okay. I think we're about to drop the multi proposer punchline. But before we get there, I want to open up inclusion lists in Fossil as context to to open up that door. Maybe Charlie, you can help us with this one.

• 24:27Speaker 02

  Yeah, I would say the editorialized history on this is basically like we had or we have proposer monopoly PBS. And for the last like year to two years, as people started to notice the censorship problem, Max and others. You know, one of some of the main proposals to improve things have been the idea of giving proposers back more agency. For for example, so in the construction plot process, block construction process, people observed, okay, well, you know, the builder gets to Build the whole block and the proposer doesn't get to say anything. So even if they want, you know, this auctions bid to be included, or even if they want this disenfranchised person's transaction to make it in, if the builder says no, they don't have any way to express that.

• 25:12Speaker 02

  Or any participation in the block construction. So the first ideas were kind of like, okay, give proposers the ability to participate in the block construction process. You know, not just give it entirely away to builders. And then there were some derivative ideas of that. I would say like preconfirmation stuff is kind of in this camp or like proposer commitment stuff where, you know, proposers are promising to say or do certain things about their blocks and the builders have to follow those rules in theory.

• 25:41Speaker 02

  And then I think more recently, Max, I think had these ideas earlier, but more recently, some of the research community came to the idea of like, okay, maybe we should have many people contributing to the construction of a block in some form. And one vein of those ideas is basically the, what you mentioned, FOSSIL, which is an inclusion list design that has many parties contributing to it. An inclusion list is basically a list that the builder has to follow. So it says, when you build the block, this set of transactions, or if it's full, some subset of it, have to be included from this inclusion list.

• 26:18David Hoffman?

  The proposer says to the builder, here's a list of transactions that must be included.

• 26:22Speaker 02

  Yeah, well, the original idea was the proposer would say that. And then sort of the, the follow-up idea improvement on that was a bunch of proposers.

• 26:29David Hoffman?

  Bunch of proposers.

• 26:29Speaker 02

  So we sample the validator set and we get a bunch of people to contribute to this list and then the builder has to follow it.

• 26:36Speaker 02

  And then I would say a somewhat, like a related line of research, which Max has been championing, is the concept of multi-proposer. And this says, rather than putting this part in the inclusion list, which makes it less useful for MEV-relevant transactions, it's sort of, and we can get into why, probably only useful for like the USDC send or like the disenfranchised person that the builder doesn't want to include, as opposed to say the Uniswap trade. Max has been pursuing this alternative line of research. Which attempts to address the MEV transactions as well. And that's called multi proposer. That would be my framing of it, but I'll, you know, you should.

• 27:16Speaker 03

  Yeah. One, again, just to add some extra context on this. The way to think about it is that you're trying to solve this censorship problem. There were two schools of thought. One was the execution tickets, the confirmations.

• 27:29Speaker 02

  Right.

• 27:30Speaker 03

  School of thought and everything that happened there, which I think all three of us probably think we don't like as a general direction.

• 27:38Speaker 01

  Say that they're even trying to solve censorship resistance for that, in my opinion. I don't even think that they would claim to be trying to solve censorship resistance with APS and tickets. I think like they think that they're going to do APS tickets and then have inclusion lists as the censorship resistance candidate.

• 27:54Speaker 03

  Gotcha. Well, that was the one direction. The other one was this whole thing where multiple people help the builder or multiple proposers decide on what should go in. And they kind of are trying to achieve the same thing. And it kind of like the the main area where they differ is like how much of the scope are they trying to address? And the wider the scope, the harder the problem, the bigger the changes that you need to do.

• 28:20Speaker 01

  I think, yeah, let me, I think people are quite confused about the difference between Braid and Fossil. They're actually both ancestors of the same idea. So in like January of 2023, myself, Elijah Fox and Molesh Pie, who works with us at SMG and is a professor at Rice. We released a paper called censorship resistance in on-chain auctions, which basically made the point that if you want to hold an auction, you need censorship resistance to do it. And Ethereum and other leader-based chains don't have strong short-term censorship resistance. And out of that, Elijah, who started a company called Duality.

• 29:03Speaker 01

  Was like, hey, maybe we should try to implement some of these ideas so we can reduce MEV on this chain that we're building. And he came up with this idea, which I helped him with, which was multiplicity. And multiplicity is very similar to what FOSSIL looks like, which is FOSSIL's fork choice enforced inclusion lists, which is basically the testers send some extra transactions to the execution proposer and the execution proposer is supposed to include a bunch of those in his block. So it's constraining the censorship power of the execution proposer in that way, but it still has a privileged position for the execution proposer. Now fork choice enforced inclusion lists are a modification of that which works with

• 29:48Speaker 01

  LMD ghost. So that is a pretty similar design and in fact, it's like from the same line of reasoning and the same disiderata. Now Braid is a attempt to make a version of that design that doesn't have a privileged execution proposer. And so each one of the proposers in Braid is treated exactly the same way. And so I think that's very thematic of the Ethereum vision, which is try not to give anybody any outsized power. Try to make as frictionless a system as possible and treat everybody the same. Whereas the FOSSIL and multiplicity version, which I think is also like a reasonable direction

• 30:33Speaker 01

  and is trying to achieve the same goals, has that one downside. And so that's exactly like the, the very specific technical difference, but ultimately thematically, they're very similar.

• 30:43Speaker 02

  And so in particular, correct me when you disagree with me. Basically, the way that I would view it is the FOSSIL slash multiplicity approach, which you could call like the inclusion list approach, meaning we got a group of people who construct a list of things that have to be included and then a builder is responsible for building a block that includes them. Basically, this probably is only useful for censorship resistance for

• 31:12Speaker 02

  Like MetaMask transactions, disenfranchised individuals, and maybe increasing the cost of censorship for like a, the auction example you gave a bit. Because ultimately, that execution proposer at the end, the person who's building the ultimate block that's constrained by those lists, it still has a lot of advantages. One advantage that, sorry, one advantage that they have is a timing advantage. So they have the ability to see all of the transactions in the inclusion list prior to constructing the block. And we can get more into exactly how that advantage expresses itself. Another that they have is that they could look at the transactions that are in the inclusion list,

• 31:56Speaker 02

  and they could decide to like stuff the block. So they could say, you know, I'm no longer able to exclude these freely, but what I can do is pay to exclude them, basically. Like, I can fill the block with, you know, useless transactions, basically, and I'm gonna have to pay the base fee to do that, to kick out the ones that I want to. But if I'm willing to pay, or if I'm in a time of very high congestion, then I can still do that. And so ultimately, like, with the Fossil and Multiplicity approaches, it's probably, it doesn't really address the MEV issue. It mostly addresses like the censorship of transactions that are disenfranchised

• 32:38Speaker 02

  or that are just not like builders just don't include because like they're lazy and don't care to today and it feels bad. It doesn't address like the Uniswap trade or issue. And the reason for this basically is, you know, if I'm a really sophisticated trader and I send, I see that Binance and Uniswap are out of line. And I send a trade closing that arbitrage to the Fossil Committee or the Multiplicity Committee, to the inclusion list constructors, right? Okay, it gets into the inclusion list. Now, the builder of the block later sees that trade. And it's gonna look at the Binance price and say, since I sent that trade to the inclusion list committee, has it moved, has Binance moved?

• 33:22Speaker 02

  In favor of the trade or away from it. And if it moves away from the trade, they're gonna beat me for it. Or if it moves away from the trade, basically, then they'll let it execute at an unfavorable price to me. But if it's a profitable trade, they'll beat me for it instead. And so as a trader, or you know, when I'm making MEV relevant transactions, I'm basically never gonna use the inclusion list because I know that it's gonna mean that I get adversely selected against. And I'm less profitable. So all the MEV still flows through the builder. And the inclusion list is really only useful as like a sort of.

• 34:01David Hoffman?

  Last line of defense for the disenfranchised.

• 34:04Speaker 02

  Right. It's a side door for transactions that aren't inherently relevant to the MEV game. Now, in fairness, a lot of folks think that this is still useful. It feels bad if you're a MetaMask user and one of the big builders is just like, you know, this this trade is this transaction, which I don't care about it. It's not that I want to censor you, but like it's gonna increase the latency of my block. So like, I'm just not gonna include it. Or if you're disenfranchised, you know, user, et cetera. I think ultimately, like, it's a good design property of Ethereum for like USDC sends to get on chain as fast as possible. And I think that there is like a really strong case for the fossil multiplicity approach, that it helps with all of that stuff.

• 34:47Speaker 02

  But what it doesn't, what it explicitly doesn't address is removing the builder. And basically.

• 34:53David Hoffman?

  The monopoly that the builder has.

• 34:54Speaker 02

  Yes, removing the builder and the builder's monopoly on MEV relevant transactions.

• 34:59Speaker 01

  Yeah, just maybe the just tile of the things you just said into about like, there is no way, no matter how many Math Olympiad and Putnam medals you have, that you are gonna beat me at trading if I'm two seconds ahead of you. If I have two seconds more finance information. And that means that if you're two seconds behind, meaning you're submitting on the inclusion list with a design that has a view canonicalizer like multiplicity or fossil, you don't even wanna play because you know that somebody else is gonna come in. Either it's gonna be the execution proposer themselves or somebody else who bribes the execution proposer to do this.

• 35:43Speaker 01

  And they're gonna have a two second advantage because they're gonna have two seconds extra finance movement against you. And if you would try to make a trade. All of your good trades, when you make a trade and the price moves favorably or stays steady, you're gonna get outbid on. And all of your bad trades, you're gonna keep. So you, you only get losers. And this basically spirals and make it so you don't wanna trade at all in the multiplicity inclusion list uh way.

• 36:17Speaker 03

  So isn't this maybe a shorter way of saying this, isn't that the inclusion list is really an inclusion set that doesn't enforce any ordering? The builder just needs to include them and doesn't matter what order, they can do whatever they want. This means that yes, indeed, the inclusion set, it's not a good fit for MEV-bearing transactions. Open question, I think, whether that is desired or not. But what do you think about the world where the inclusion list has an ordering rule baked into it? And I guess like my broader point being, is this a question about the multi-propos- uh is this a question about having multiple proposers or multiple people doing the thing?

• 36:57Speaker 03

  Or is it the question about whether there exists a sound way to do some kind of ordering rule that allows the MEV to be more proper?

• 37:07Speaker 02

  Well, I think it's a really good question. I think um before we get into the ordering rule stuff, I would say that Max's pitch for a braid and pure multiple proposer, which is the alternative path from the inclusion list plus builder approach, the fossil slash multiplicity plus builder approach.

• 37:29Speaker 02

  Basically, it intends to delete the builder uh and to replace the builder with an ordering rule. And I think before we discuss the ordering rule, it probably would be helpful to, for Max to explain how um his approach, like the pitch for we can delete the builder.

• 37:49Speaker 03

  And maybe Max, why don't you sketch out the Braid, like step by step?

• 37:53Speaker 01

  Yeah.

• 37:54David Hoffman?

  And that's exactly what I want to go next. I want to put a stamp in this conversation. Because this is an arc of the Ethereum research that is now kind of taking a very meaningfully different path. If this is the way that we go, whereas blockchains Ethereum have always been in this like leader based system where somebody has a monopoly, even if it's as short as 12 seconds, somebody's always had a monopoly. And all the things that we've talked about, inclusion, list builders, proposer builder separation, and trying to propose a builder separation has all been addendums, additions, patches onto the system because of the leader based system. And now, as you're about to introduce Braid, this multi-proposal set, we're kind of going back very far backwards in Ethereum Mav research

• 38:39David Hoffman?

  to propose an entirely new construction of going forward. That's kind of how I interpret this moment in time of Ethereum research.

• 38:46Speaker 03

  That sounds right to me. And David, just to be very clear, I think we're very early in the research phase in all of these things. Max has yet, has more work to do, I think, like on publishing, being more explicit on like, go what we are achieving, the protocol, the proofs and everything around that. Same thing like for Fossil, we need to do a lot more work. We might come up with a third new thing. So I think the way to approach the conversation is that we haven't added an item on the roadmap.

• 39:12David Hoffman?

  Right.

• 39:12Speaker 03

  We are very early.

• 39:14David Hoffman?

  This is a concept. This is a trail of research that we're going down.

• 39:16Speaker 03

  Yeah, yeah, yeah. Because we have, there are so many things that we haven't figured out yet, as we will find out in this conversation, that it's very early for us to say, hey, this is like where we're going. Because just nobody has done that before. This is like very blue ocean, uncharted waters. And actually, the Ethereum ecosystem is way ahead in terms of facing this very hard problem.

• 39:38David Hoffman?

  Right.

• 39:39Speaker 03

  Which is why you don't hear this discussed in many other places, except maybe Anatoly Solana, who was probably way ahead of everyone else on this train.

• 39:48David Hoffman?

  Okay, so Max, introduce to us multi-proposers.

• 39:50Speaker 01

  Yeah, so I say that this design is kind of suspiciously simple because if you ask, I asked a bunch of consensus experts, like, these are my disiderata, I want multi-proposer. Can you give me something that does this? They said, oh, that sounds like it would be super complicated. But then I had a few more discussions. I was like,

• 40:12Speaker 01

  Talking and and Molesh, who again works at SMG as well, kind of said, hey, why don't we just do like the stupidest possible thing, which is just take LMD Ghost and copy paste it four times or eight times. And then we just try to interpret the four parallel chains as one. And at the time, the consensus experts were kind of looking at him like he was crazy. And then we just kind of thought about it a little more and a little more and nobody could really find an immediate break. And then we kind of convinced ourselves that actually this does work. In fact,

• 40:53Speaker 01

  if you have a single threaded, single leader blockchain that has eventual consistency, then the multi-threaded version of that, like Braid, inherits that eventual consistency. If it has liveliness, it's trivial to show that it inherits liveliness. And you can modify the finality gadget in LMD Ghost to give good finality prof- properties for like, it's a very similar finality gadget as well. So we basically said, okay, let's, you know, start circulating this idea. And that's where we are now, a few weeks later after that realization. So.

• 41:37David Hoffman?

  Max, when you gave, I watched your talk that got circulated on Twitter and you you presented it in the same way where it's like so stupidly simple. Uh, and then here it is. And then you explained it. And then I was waiting for further explanation, but then the explanation ended. And so that's kind of what just happened to me just now. So like my interpretation is that these builder, the proposers, the validators, uh, are going to make four blockchains if we're doing a for a four multi-proposer system. We're going to make four blockchains and then via some mechanism, they just get interpolated together, they get combined together. And then that becomes the blockchain, that becomes the block that gets added to the blockchain. And so. And that was it? And that's what a multi-proposer is?

• 42:18Speaker 01

  Yeah, it's suspicious.

• 42:20Speaker 03

  It's like, you know, it's like the owl and then draw the rest of the owl. So how, how, how does that? You know, the collapsing, actually, I think is like quite important here. So yes, okay, like it's like the four of us friends are here. Like, so we have a block each.

• 42:36David Hoffman?

  Yeah, I've got a block. George has got a block.

• 42:38Speaker 03

  We all got a block.

• 42:39David Hoffman?

  We all got a block. How does it? Four blocks needs to become one block. How does that happen?

• 42:43Speaker 03

  Yeah.

• 42:44Speaker 01

  Right, so the way this works is what I call execution consensus separation. So the execution layer, so Georgios is gonna have to implement this. It's gonna be basically becoming the view canonicalizer in the system. They're gonna be looking at the chain, interpreting which blocks arrived on time and which didn't, which are confirmed, which are valid, which are not. And in real time, on the unfinished head of the chain, they're gonna be looking at the chain and seeing which blocks arrived. If there's four blocks that arrive and we all think that they're valid, we're gonna zip up each of the transactions. So all of David's transactions, all of Georgios's transactions, all of my transactions,

• 43:27Speaker 01

  and all of Charlie's transactions are gonna be zipped up into an unordered set. And then we can apply some deterministic ordering rule to order them afterwards and execute them.

• 43:35David Hoffman?

  And the deterministic ordering rule might have been previously known as a builder. That's like the thing that we are replacing the builder with. Because it's the mechanism, it's the software, it's the code that is determining the output of the order.

• 43:47Speaker 01

  Well, yeah, except I would say that a builder isn't a deterministic ordering rule. It's a, it's an attempt to solve this very hard NP-hard knapsack packing problem.

• 43:57David Hoffman?

  Okay, so four sets of transactions, four different orders, and then there's a rule that all of these things go through. And then the output of the optimization rule, the ordering rule, becomes the one block. What happens if like, we're all looking at the same mempool. I'm pulling in your guys' transactions, you guys are pulling in my transactions, right? Like, that's how I understand blocks to be made. What about this contingency?

• 44:20Speaker 01

  Yeah, so if you send to multiple leaders, you have to pay the base fee for multiple leaders. So you're actually gonna, it's gonna cost more. You do it if you want censorship resistance. If you don't, you can just send to one leader. So that's like one point is that not everything is gonna be sent to everybody.

• 44:38David Hoffman?

  Okay.

• 44:39Speaker 03

  I would say. Okay, so could we go over an example, just to be precise here? I. I am looking at the peer-to-peer network, you're sending a block around, all of you guys are sending a block around. Can I not act as the leader almost by just waiting for all of you guys to send me the block and then at the very end I will send it out? How does that work? Is this latency games? Are you asking about latency games? Yeah, it seems hard to... Yeah, maybe let's talk about the, you know, the set of things that we're trying to, we're dealing with here. Because yes, of course, there's a VU canonical alizer. Yeah, you take N things and you reduce them down to one. But like, how should that work?

• 45:24Speaker 02

  Well, I think the giga bull case for Braid and multiple concurrent proposers is that it is a design which tries to achieve, I think what Max calls simultaneous release. And that means if all four of us are building blocks at the same time, they're going to get zipped up after we all release them by everyone else watching the chain. And all the transactions in them are going to get added together and then ordered by some rule. Now, if there's simultaneous release, which you can kind of think of as, I don't know what's going to be in your guys' blocks before I release my own, then there's a strong argument, and I think this is the core argument in your original paper, that I should just add all the transactions I'm aware of to my own block.

• 46:09Speaker 02

  Because if I don't, you guys may have added them. I don't know what's in your blocks, basically. And so that my dominant strategy is just to add all the transactions that I'm aware of. Right? And if everybody, if all the leaders follow that same strategy, if that is the dominant strategy for all the leaders, then we have extremely strong short-term censorship resistance. And there's no builder.

• 46:33Speaker 03

  Does that simultaneous release exist?

• 46:36Speaker 01

  So let me step in there. There's two versions. There's a weak simultaneous release, which is...

• 46:43Speaker 01

  So it depends on what information you consider. In game theory, we have this idea. We write out the game in a game tree. And we have two types of things. We have things that happen after each other and things that happen at the same time. And the formalization of that are if actions happen at the same time in game theory, we say that they're part of the same information set. So that means when I release my block, I have the same exact information about the world as George's. So what you consider to be that information is important. If if what we care about is only that I don't know the context tense of George's block that he's proposing.

• 47:24Speaker 01

  I think that's absolutely possible as long as some cryptography implementations exist that we think probably exist or will exist in the next few years. Uh, something like a time lock puzzle would help us do that. So I could release my block. And I could put a time lock puzzle that says this will decrypt in one second. And we can absolutely get the timing games down to within one second. So that would work, but the challenging part, the strong version of this synchronous release. Or simultaneous release is can we make it so that we all have the same Binance info? And that's the one that I'm still not sure if we can get to, but I'm working really hard on it and

• 48:07Speaker 01

  um, I hope we can solve it. I think it's pretty important to get that strong version as well, but I know we can get the weak version, at least if time lock encryption works.

• 48:15Speaker 02

  I will now paint the bear case as well. Uh, I think there's two bear cases. So the first is this. On the weak case, I would say we don't currently have good cryptography for what we're trying to achieve. Uh, basically, um, I think that you would need farther out there cryptographic uh schemes like strong VDS or something to get what you were talking about. And the best that we could do today would be some type of threshold encryption scheme, probably. And like, there's the possibility of unaccountable collusion. There's also probably in whatever, like this is not specified, but when we did specify it, there probably are going to be a lot of issues with like free option problems.

• 48:57Speaker 02

  Meaning if some subset of the participants decide not to decrypt or to decrypt um selectively, like I think.

• 49:05Speaker 03

  Hmm.

• 49:06Speaker 01

  I think. Should we like unpack this for the audience? So, so there's threshold encryption, which means I take my information. And then I encrypt it and I give the key to, you know, Georgios and Charlie. And like, if they both have the key, they can open it. So you need both keys to open it.

• 49:27Speaker 03

  Mm hmm.

• 49:27Speaker 01

  That's threshold encryption. Strong VDF. VDF means verifiable delay function, just so we're not using too many acronyms. And that's important for these time lock encryption schemes that I'm talking about.

• 49:39Speaker 03

  The issue is that like threshold decryption in general usually is implemented as another layer of consensus. So you end up running on the same problems that you were trying to solve in the first place.

• 49:51Speaker 01

  Mm hmm.

• 49:51Speaker 03

  And that's why it doesn't feel like a credible tool that we could use here. And on the, there was an old school around where I will delay function, which also was a dead end. So that also felt like a dead end. There was some recent research on doing time lock decryption with a very recent line of work that I cannot remember to explain right now. That might be promising, but I guess, yes, maybe, but even that seems hard. And even then, the moment that you introduce encryption, that means that you're incentivized spam. And it goes back to my original point around the Mev moving around. Because you end up in this probabilistic games where I will just try to flood the network with transactions. It's because I just cannot see what's going on. It seemed rough.

• 50:37Speaker 01

  I think, well, first of all, let me just say that there is commit reveal. We do know how to do commit reveal. We just commit to the hash, sign the hash, and then you reveal it later. And if you don't reveal, you get slashed. It has some issues. You might, uh, really not want to reveal. And then the amount you don't want to reveal is like more than the amount you've put up. And so you're, you're not going to reveal and, and lose that stake that you put up. But at least we do know that that works. And if we put sufficient stake behind it, uh, we already have 32 ETH stake, which is quite a bit for each halogator.

• 51:08Speaker 03

  But did the low carb crusader fiasco last year disprove that almost that in the face of an uncapped amount of MEV at risk and flight? Um, no cap bond can, can secure you against that attack capital efficiently?

• 51:25Speaker 01

  Uh, well, I, I think, yeah, and actually Tarun and Mateus have a paper about this, which is like credible decentralized auctions, I think is the title that actually looks at, based on the, the weight of the tail of the distribution of MEB opportunities. So how, how likely it is to have these big uncapped opportunities, you, you lose the credibility with these commit reveal schemes. So this is certainly a reasonable point. I think that's why I'm saying.

• 51:55Speaker 03

  I'm thinking of not seeing the goal as a lab in my mind and talking about.

• 51:58Speaker 02

  Yeah, maybe zooming out on it for a second. I think there's a bunch of stuff in the cryptographic rabbit hole about how if all four of us are proposers, we can try and encrypt our blocks in a way that's reasonable. I think what Max was getting at though, and you know, if you were to zoom all the way out on it, the attack case that I think most people are considering right now when thinking about this is basically like, let's say that rather than all four of us releasing our blocks at the same time. In fact, David is a really sophisticated HFT trading firm. And he's maximizing his connectivity to the network and latency to other validators and to all the important exchanges, et cetera, and all the source, important source of order flow maximally.

• 52:44Speaker 02

  And let's say that David even has like a consistent 50 to 100 millisecond latency advantage. Right? So the issue that we were talking about adverse selection earlier in Fossil, I think still applies here, which basically is as a sophisticated trader, I would argue, I'm probably never going to send my order flow to any of the three of us. I'm only going to send it to David because I know that he's going to have the best, latest available information. Basically, and then I'll get adversely selected against if I were to send to anyone else.

• 53:17Speaker 02

  And so you're going to end up potentially in a situation where rather than,

• 53:22Speaker 02

  you know, sort of traders sending to all of us and getting censorship censorship resistance from all of us potentially, including it, that basically all sources of order flow are going to collapse onto the most sophisticated proposer and they're going to emerge as like a builder. Basically, like, we're going to rediscover the builder role through the most sophisticated proposer, having like a natural monopoly on order flow would be how I would.

• 53:50Speaker 03

  David, almost by virtue of his privilege, though, sorry, we're giving you.

• 53:53David Hoffman?

  I love it. I'm loving it. I'm loving my privilege.

• 53:54Speaker 03

  I don't know if you're an HFT firm, but if you are, don't tell us.

• 53:57David Hoffman?

  I keep that part hidden.

• 53:58Speaker 03

  Yeah. And David almost like emulates the role of the proposer via his privileged network positioning, even though you're in a leaderless system.

• 54:07Speaker 01

  David has co-located with East Bushwick, so.

• 54:10David Hoffman?

  Right, yeah.

• 54:11Speaker 01

  Fast connection.

• 54:13David Hoffman?

  Okay, so Charlie, I think what you're saying is that like, we'll just, we'll just kind of rebuild the same system that already exists. And now we have like, it just doesn't in a separate paradigm. It's inside of the multi, multi-proposer paradigm.

• 54:23Speaker 01

  But can I just defending ends this critique because if the argument is, hey, we shouldn't do this, we should do fossil instead because there might be a 100 millisecond last look in braid. There's a two, two second last look in fossil, like.

• 54:40David Hoffman?

  Right.

• 54:40Speaker 01

  Or longer, so.

• 54:42David Hoffman?

  I think it makes sense that the same emergent properties comes out of the system, no matter what. And it's more about a question like, is it nonetheless a strict improvement in the mechanism? And I think.

• 54:54Speaker 01

  Also, let me say that, sorry, sorry, David, to cut you off, but I don't want to let this FUD go unchallenged here. There's a, a model that we think of, that we look at, often we look at models, all models are wrong, some are useful. And usually one model is right for the task that you're looking at, but isn't exactly right for the other task. And I think what Charlie's doing is referencing a model that we had in one of our papers. It was actually based on something that Julian Ma, who's at EF originally proposed, which is basically the price is fluctuating, you have somebody who acts later and somebody who acts earlier. And you have this complete unraveling effect that Charlie was talking about. But it doesn't quite work that way in this system because if everybody goes through

• 55:38Speaker 01

  the one facet through David, who has his latency advantage set up.

• 55:44Speaker 01

  Then you don't expect them to bid very high in the auction.

• 55:50Speaker 01

  That's not run by David. They'll bid for to get to be David's favorite to get to submit their trades to David. But you shouldn't expect an equilibrium to arise where there's no bids from the other. Uh, proposers because there's two stages of the auction. There's the auction for who gets to be David's favorite. But he's gonna choose one. And then that one person is gonna win the auction for basically free. So they're they're gonna not have to pay. Uh, too much money for the right to do the arbitrage.

• 56:21Speaker 02

  So. I think I I think I would say a couple of things. Number one. Um, the 50 millisecond versus two second latency delay in the fossil versus like whatever timing advantage we can garner. Um, I think there's some centralization trade off there, basically. Um, the second thing that I would say is that timing advantages are probably one of the most obvious, like first order advantages that you can garner. But I certainly don't think that it's um, like the only advantage in the meta game, basically like I think. The sophistication of the most sophisticated proposer or what advantage they have. Um, there are gonna be a number of different ones. Um.

• 57:02Speaker 02

  And in the Binance sex decks are, although it's like one of the easiest examples to use, I think that it's like. You know, even if you go look at the order flow distribution today, it's not like the only one that matters, right? Um, so we said there's gonna be some consistent advantage on that one and we can talk about, we can talk about some others too. Um, so in the multi proposer case, again, let's say there's like one sophisticated proposer. Um, that can see other people that we can see other people's blocks um, and potentially listen to bribery oracles and other types of things. Um. You know, longer than than other people can. Um, I also think that you run into a lot of issues um, with like the deterministic ordering rule that we were talking about earlier.

• 57:43Speaker 02

  Um, where basically like that proposer is also going to be able to um. In a maximally advantageous way, interact with the ordering rule and any applications that rely on it compared to the other proposers. So like one of the most common, or like one of the probably best ordering rules proposed, or most reasonable, is priority gas auctions, right? Like what we had in the Ethereum mining days. And another thing that I wonder about with with the multi proposer version of this that tries to achieve like no builder, and we're going to have a deterministic way of merging the blocks, is like in addition to David being able to see Binance last, David also very plausibly is going to be able to see what all of the Uniswap trades in the three of our blocks are,

• 58:29Speaker 02

  and sandwich all of them, and penny the auction, the priority auction on behalf of anyone else who wants to participate in any protocol on chain, right? So I think that there's like a bunch of different kinds of advantages that that that flow down. And like the resulting meta game, I think in many different ways, like power will concentrate onto the sophisticated proposer.

• 58:53Speaker 01

  But then revenue will concentrate to the sophisticated proposers, and then everybody will try to get sophisticated, which is already happening.

• 59:00Speaker 03

  But the centralization point.

• 59:02Speaker 01

  But it's already centralizing. I mean, we have, we have all these kinds of timing games. We have games that are not being played right now, which is.

• 59:08Speaker 03

  It's kind of exacerbating the issue, right?

• 59:10Speaker 01

  No, I think it's actually not, it's making the issue better because right now, if you're faster, you get a extra 100 milliseconds or a second of proposer monopoly, and that's incredibly valuable. And in this system, you can get an extra 100 milliseconds of being one of N proposers. So you'll get a 100 milliseconds of last look. It's not as valuable as extra 100 milliseconds of proposer monopoly, because proposer monopoly is incredibly valuable.

• 59:36Speaker 02

  Okay, here's a basic mental model that I that I use for it, right?

• 59:41Speaker 02

  In the multi-proposer case, right? We have basically this deterministic ordering rule that's sitting in between multiple proposers. And we, and we're going to say that there's some difference in sophistication between them now, right? And then the other side of this, we have people bidding for inclusion with also obviously like a variety of sophistication. Right? And I think that like, something that worries me a lot about this, if I had to boil down my concern with it, is that like, again, if we go back to the proof of work days, like the original MEV paper was like, how only the bidder side of this market, the people who wanted transaction inclusion, how their behavior was like unintuitive and unintended,

• 1:00:25Speaker 02

  even while miners were trying to run honest PGAs or honest priority auctions. And I think basically like the MEV metagame that would develop on top of Braid is going to be the result of bidders and the proposers with varying degrees of sophistication, like trying maximally to manipulate the system to their own benefit. And I'm personally like pretty unconvinced at this point that we can avoid a situation where the metagame is A, going to be a lot different than we intend. Meaning it's not going to be people bidding their like true value in this priority auction or something, or other ordering rule, interacting with it like quote unquote honestly in the way that we intend.

• 1:01:10Speaker 02

  And with like comparable levels of sophistication or revenue on the part of the validators. I think probably what's going to happen is power is going to, both sides of the market are going to try to manipulate this mechanism to their benefit. And then the most sophisticated of them are going to garner an outsized amount of power. And I think the delta between the least sophisticated participant in that market and the most is going to be significantly greater than the least sophisticated proposer on Ethereum today and the most sophisticated proposer. And if this were all true, then I think at the end of it, you end up with PBS, just in like a more opaque way.

• 1:01:43Speaker 01

  Okay. Well, first of all, that's wrong. Actually not going to be a bigger delta between the most sophisticated and least sophisticated. I think your reasoning by analogy. Typical VC.

• 1:01:55Speaker 02

  But, but, no, no, but today.

• 1:01:56Speaker 01

  Let me finish, let me finish the point. You just went on for five minutes. That, that, you're reasoning by analogy from a model that we wrote about, about a different context. And when we actually solve out the model, the adverse selection isn't going to look as bad as you think it is. So let's go, we'll solve, we'll solve out the model. I understand the propensity for, oh, we don't know what's going to happen. But let me tell you, Max Resnick is here. SMG is here. We don't do things the same way. And we're going to prove the, the properties that we say the mechanism has. And we are going to show formally what the equilibrium is. This is not going to be a situation where we come in, we ship reams and reams

• 1:02:38Speaker 01

  of unsubstantiated claims so much that you can't read them all, like a, like a, a legal battle where they send you all the file cabinets and they don't digitize it for you. So you can't look through it. And that's what we're going to do. And if you don't agree with the proofs, then we can argue about the proofs. But like, I'll just say, you know, hey, you may have some skepticism now. Okay. That's, that's on us. That's, that's our prerogative. We're going to prove the results, which is how things should work. And then we don't have to go into this saying, oh, there might be something that we're not considering. No, we proved it. Q E D. It's done.

• 1:03:14Speaker 02

  I'm super excited for that. And I'm super, I'm super, super open minded to it. I also don't like the research DOS. I, I think we're very aligned on this. I'll make one, address just one thing you said, which is to me, the difference today in validator sophistication would be how late in the slot you're going to call the PBS block or how late you're going to call MavBoost to get the block. That delta, if you're going to play the timing game, is not that great. I don't recall the number offhand what it is. But I think the difference between a proposer who's not, in a multi-proposer scheme, who's not sophisticated and one who is, if the one who is, is getting all of the Binance flow and the one who's not is getting functionally none of it. I think that delta is going to be a lot different than, um, you know, if you call the MavBoost auction

• 1:03:59Speaker 02

  300 milliseconds later or something like, I think, because in that case, like the proposer is, is, uh, the builder is still like getting all the same order flow, just not the one in the last 300 milliseconds. My claim is.

• 1:04:11Speaker 01

  It's going to be a great, uh.

• 1:04:13Speaker 03

  Point to debunk or prove in the work, I think.

• 1:04:15Speaker 02

  Yeah, now I do think that Vitalik, as usual, had the best tweet on the subject recently, which is basically you could boil, I think, a lot of the research conversation about this down today with like, can we remove or at least prove some things definitively about this last look? Like, can we get rid of the last look in multiple concurrent proposers that would lead to this like breakdown that I'm articulating? Or, I think to your point, can we definitively prove some things about how bad or how not bad that last look is?

• 1:04:50Speaker 01

  I think if you know how to quantify the latency game, then you describe it and you describe exactly the issue with it. If you don't, you write something on Twitter that says, oh, there might be latency game here, there might be adverse selection here. So I think what we need to do, it's on us to demonstrate, that's like if we say, hey, we should do braid, that's our prerogative to demonstrate it, we're gonna demonstrate it. And if we can't, then we'll probably show it's impossible and then we can all move on.

• 1:05:18Speaker 03

  Right, I was gonna say exactly that. I think even in both cases, I think we're all truth seeking here. In both cases, if it can be done, the proof is gonna be great. If we find out an impossibility proof, that's also gonna be amazing because it's gonna save us from all the DOS and the Twitter situations, which maybe there's a meta point here around all of us maybe doing upfront a lot more work before we try to like garner excitement or criticism around an idea.

• 1:05:53Speaker 02

  Speaking of garnering excitement, since we've been poking holes in braid since its introduction in this conversation, I do wanna give Max the floor of how my braid benefit everything upstream of it or downstream of it. I know there's a conversation around DeFi here. We started with like poking holes, but I wanna give Max the chance to just like talk about how braid is the best thing ever. What are the big benefits that you see of this like multi proposer paradigm? Granted that we are able to figure out the research questions around it and figure out that that problem.

• 1:06:23Speaker 01

  Yeah, and ultimately, like, we're not just, we're not trying to push anything for any personal gain. Like, we're just all here trying to make Ethereum as good as it can be. And if You know, I happen to believe that we can demonstrate that Braid has certain properties. We're working very hard. There's a bunch of people working on the paper who are, you know, working on proofs, probably as we speak right now, to try and show those properties. And if we can't demonstrate them, oftentimes when you try to prove something, you either find that it's possible and prove it, or find that it's impossible and then show it. And we'll, we'll release either way. We're not going to be like a medical study where we, we don't release the negative results. We're going to release either way.

• 1:07:07Speaker 01

  I think it's really important. I think there's a lot of complexity on the roadmap as well that introduces a bunch of problems that Braid and execution consensus separation is an alternative to. I'll give one example.

• 1:07:22Speaker 01

  EPBS, there's a design out from Terrence and Potos right now, which is, I think, originally based on this proposer timeliness committee, which I'm not sure if it was Mike's idea. He did write a post about it a while ago.

• 1:07:37Speaker 03

  From Pepsi, back from Pepsi.

• 1:07:39Speaker 01

  The proposer timeliness?

• 1:07:41Speaker 03

  Yeah.

• 1:07:41Speaker 01

  Okay, so yeah, but, but sorry if I'm not giving credit where it's due. I'm just not recalling exactly the thread of research.

• 1:07:47Speaker 03

  Mike was also into that. Mike was in all of that.

• 1:07:49Speaker 01

  Okay, yeah. So, so this proposer timeliness committee idea is basically you commit to the block as the builder. You send your block commitment to the proposer and the proposer selects the highest commitment. And then afterwards, as the builder, you have some time to reveal your block. And that is basically this alternative design for EPBS. And we know we want to do EPBS and protocol somehow. So Braid is a way to do EPBS. And this is an alternative, the most kind of developed, longest chain on the alternative fork of doing just EPBS. So one attack on that, which is an issue, is you could place some large trades.

• 1:08:32Speaker 01

  And then if the trade goes against you, you choose not to release. And so you say, oh, well, then we have to have a huge bond available to slash you with. But, you know, what's the size of that bond? Again, we have this uncapped bond problem. So my argument would be, yes, there's a lot of complexity here. But in the words of italic, if we just eat the complexity, if we can figure it out, if we can show the results are true, which we're working on. Then we can eliminate execution tickets. We can achieve Medburn. We can get rid of EPBS. We get inclusion lists as a byproduct. All this stuff that's on the scourge part of the roadmap, we get with one stone. And it might be a big stone, and it might be a hard stone, and it might be a new stone.

• 1:09:16Speaker 01

  But if we could do that all with one fell swoop, I think that would be good for making Ethereum look more like the V3 version of the Falcon Engine than the V1 version of Falcon Engine.

• 1:09:30David Hoffman?

  I think that's what really attracts me to this conversation. This phrase eating complexity has been thrown around a lot when it comes to this idea of of multi proposer architecture. We kind of like set up this MEV landscape part of this discussion, talking about all this incremental discoveries about MEV, and then the next incremental patch about that MEV, kind of not addressing the root core of the issue, which could be the fact that everything is a leader-based system. And in multi proposers, you at least are leaderless-ish. When we started this multi proposer conversation, we talked about my super sophisticated, highly bandwidth connected proposer. And so there's still a leader-ish part of a multi proposer that we need to kind of figure out.

• 1:10:12David Hoffman?

  But the idea here is like, call it four, eight, some square number that we'll probably select. If there's eight proposers, all of a sudden it becomes much less leader, much less of a leader-based system. And you're saying that this is an elegant solution to eat a lot of the complexity of all these patchwork incremental additions to the Ethereum research roadmap, which feels elegant. And I know that we, in the Ethereum research space, we like elegant solutions. It just feels good. Everything kind of snaps into place a little bit better. And it's kind of like one of the reasons why we're talking about this in the first place.

• 1:10:47Speaker 01

  Yeah, exactly. I would just say, like, the other designs are not necessarily bad, but I would say there's not a lot proven about them. And that's kind of, if you want to talk about, Charlie, if you want to talk about unintended consequences, latency games, pushing the MEV elsewhere, George. Take a look at these proposals, catch up on what the latest research is and you'll find quite a few issues, I think, if you really, if you read them seriously and that's not to take a shot at anybody, it's just how, how these problems are really gnarly and tough and, and like George just said, when you do something, you move it somewhere else and.

• 1:11:25Speaker 02

  I completely agree. I completely agree with everything you said, actually. And to be clear, I'm actually very bullish on like multi-proposer or multiple part, multi-party block production, as we talked about. I guess like, my two cents would just be, I think that we should be basically very cautious about the existence of sophistication and exactly how that will express itself in whatever market structure we kind of, we try to create. And I think that to the extent that we're ever imagining that parties are going to be on a level playing field, that we should have like really strong reasons for believing that. And I think that is where like a lot of the research

• 1:12:09Speaker 02

  around Braid is focused.

• 1:12:11Speaker 01

  Can I, can I just say, I think like, if you are being intellectually honest, our strand of the research, our original paper has been some of the most tackling head-on that sophistication and rationality of the actors. And we understand it and we talk to the rational actors, just, just like you. And I think like, we're very aware of that and we're economists. So the way that we model things is through rational actors participating in games and we beat the complexity of that to try and get good proofs. So I think if you actually compare what we've done in terms of tackling incentives and rational actors and latency

• 1:12:55Speaker 01

  versus what some of these other proposals have done, I think we're actually far ahead in terms of analyzing the ultimate outcomes.

• 1:13:02Speaker 02

  Yeah, I, I agree. And I'm pretty sure that whatever. I don't have like a decided opinion on what Ethereum should do yet, but I'm fairly sure that wherever my opinion lands is probably gonna be, like almost certainly gonna be derivative of the work that you guys started, whether it is multiplicity or braid or, you know, whatever the most efficient implementation path is. Again, I would say, and not to belabor the point, my like narrow qualm would be, can we remove the existence of a last look? I think that's probably one of the biggest outstanding research questions. And then to the conversation we were having earlier, even if we net it out to that we can't, I'm very open minded to the idea that we can, or we can have really good arguments that

• 1:13:44Speaker 02

  it's not as bad as we are nervous that it could be. Then, yeah, I think the implementation route that Ethereum takes to something like this, some method of improving censorship is probably either going to be like multiplicity or braid or, you know, or whatever else is in this line of research.

• 1:14:03Speaker 01

  Yeah, I mean, how awesome and that in the spirit of the Vitalik tweet that we went from two years ago, doing these vast, you know, MEV taxonomy, shout out to Tina, and trying to figure out what was even going on. And now we're down to, can we get rid of last look?

• 1:14:21Speaker 02

  Yeah.

• 1:14:21Speaker 01

  That's so much more tight of a problem.

• 1:14:24Speaker 02

  I agree.

• 1:14:24Speaker 01

  And I think we're getting That is a good one.

• 1:14:26Speaker 02

  Yeah.

• 1:14:28David Hoffman?

  I do also want to talk about the improvements that multi-proposers might bring to DeFi specifically. I think we all would might agree that DeFi is like the first primary big use case of blockchains past just simple money. What's the relationship between a multi-proposal architecture and the DeFi vertical?

• 1:14:45Speaker 01

  So my, like I said, my goal, I said this on Twitter, my goal is to make the blockchain so awesome that the majority of Euro USD volume trades on chain. And that might be a pipe dream. I currently think that the probability of that happening is greater than 1%, which is why I'm still working in crypto. I really am excited about financial possibilities on chain. But I think

• 1:15:16Speaker 01

  This is, we have turn and complete smart contracts. If we add on censorship resistance, they're going to be even more powerful. Some smart contracts are what got me into the space, by the way. It's like really cool, primitive. And you can do anything with them. That's what turn and complete kind of means. And then you add on censorship resistance, you can do so much more. So like, what are games going to look like? When you can't censor the opponent's bet? You know, that's going to be sick when you can play poker on chain. And all these other things that I think it will enable as well.

• 1:15:48David Hoffman?

  And then there's also a conversation around the layer two to layer one relations that I think this brings. And this might open up the door into like a much broader subject. I'll pose this idea and maybe you guys can reject it or not. If we are, say, say we get past the hurdle of a multi-proposer architecture being a strict improvement. Max here has done all the proofs that he needs to write in order for us to all agree that multi-proposers are a strict improvement. So we're in that, we're in that universe now. And now, and then we also merge it into the Ethereum layer one. So Ethereum layer one is running this multiple concurrent proposer paradigm. This in the bending of the priority of execution on layer twos versus execution on layer ones

• 1:16:30David Hoffman?

  bends back the priority of the Ethereum layer one being a place where really good execution happens. Whereas Ethereum previously has always been about pushing execution to layer twos. And all of a sudden, layer twos have this single centralized sequencer doing this one role. But on the Ethereum layer one, we have this multi-party, multiple concurrent proposer execution environment, which is better than it previously was. Does this change anything? Do you guys think? How does this impact Ethereum's previous and current roadmap of the rollup centric roadmap? Does it at all? If we are prioritizing execution on the layer one at a higher level than we were previously?

• 1:17:08Speaker 03

  Not sure it does.

• 1:17:09David Hoffman?

  Okay, rejection rejection of the idea.

• 1:17:12Speaker 03

  Yeah, why would it, right? Like, there are two separate things almost. Because doing more on L1 means that you have more space to do things with. And this is not creating more space. This is just saying, how do we utilize or who who writes to that same space, the block? So don't think there is a there is a change.

• 1:17:38David Hoffman?

  Okay.

• 1:17:39Speaker 03

  No, I don't think.

• 1:17:40David Hoffman?

  Maybe this conversation.

• 1:17:41Speaker 03

  Naturally, one thing to address is that you said the central is sequencer L2s. I think the whole layer two space in this is in the infant or adolescent phase, where it is in that world where it has like one sequencer, has upgrade keys, all of that. I think zoom out and apply the same maturity that Ethereum has, where Ethereum, we said, you know, it's like facing the hardest MEV problems. So we got it down to the last look and we have fault proofs. And when you have a sequencer that is not one person, that is an actual consensus network, similar techniques may apply. And actually, because you're not in this eventually consistent world, because I would think that layer twos apply standard BFT algorithms. I would think that the multi proposer BFT world would become much more exciting.

• 1:18:26Speaker 03

  So I think the ideas apply on layer two, whether it is fossil this or something else.

• 1:18:33Speaker 03

  Yeah, but I don't think it affects really how to think about how much, you know, activity happens on L1 or L2.

• 1:18:40David Hoffman?

  Maybe if I was to ask that question again, I would need to introduce this also other potential idea of increasing the Ethereum layer one block speeds. Uh, because then then we are increasing space at the layer one.

• 1:18:51Speaker 03

  How much?

• 1:18:51David Hoffman?

  But that but now that's a that's a meaningfully differentiated conversation for multi proposers.

• 1:18:55Speaker 03

  Yeah, but like, how much are you gonna increase it, right? Like 10X it, like, that's not enough.

• 1:19:01Speaker 01

  I think I agree with George is that compression is incredibly important. And so like, we just probably can't get everything we need from the L1. I think multi proposer enables some new ways that base rollups can work as well. So base rollups right now, the only thing you can do is basically make the block that maximizes the payout to the L1 proposer. Because again, the L1 proposer is a monopolist. But what if you have like a base rollup? You can define an arbitrary objective function, which is like, I want to make the user welfare the best. Or I want. The user welfare to be the best subject to these constraints. Anyway, you can kind of make a base roll up based on that.

• 1:19:44Speaker 01

  On a censorship resistant version of the L one. And then to the point that George was saying, like, uh, these are problems that are going to need to be tackled somewhere. Like if the L twos are where execution happens, and we want decentralized L twos, then they're going to have to deal with this multi proposer problem as well, because censorship is just a universal constant. And that there, I hope, going to look, a lot of people ask me why I'm trying to work on, you know, maybe getting this into the Ethereum research circles and maybe even into the protocol. And they're like, oh, why are you doing this? Especially a lot of people ask me this. Why are you doing this? Because Ethereum is so ossified.

• 1:20:26Speaker 01

  They don't do many changes, but I think that's actually just not true. Like we shipped the merge. That's a huge change. And we can do more huge changes if it's the right thing to do.

• 1:20:36David Hoffman?

  That's not even the most recent big

• 1:20:37Speaker 01

  Right. We did, uh, for four recently too. It's like we've, we've been doing tons of big changes and we've been doing it safely with minimal disruption. And so,

• 1:20:50Speaker 01

  that's in contrast to other ecosystems that are doing big changes very frequently with frequent disruption. So.

• 1:20:55David Hoffman?

  Right.

• 1:20:56Speaker 03

  Oh yeah, like the, you know, the daily Solana hard fork, you know, uh, but also even on layer two, like there's like sometimes like a new upgrade might be announced like a week out or like a few weeks out. So the iteration cycles are much different there. Uh, what two points to add is like, one, it's actually interesting that like maybe on the layer two, you don't need as much of the, you know, sequencer being censorship resistant just by virtue of the fact that you can use the L one slow path to prevent the censorship. That granted, that doesn't address the MEV, uh, part of it.

• 1:21:32Speaker 03

  And what was the other part? Oh, the other part was that in the spirit of talking about large changes, Ethereum has their.

• 1:21:39Speaker 03

  We'll see how much out it is, but like the upcoming statelessness upgrade. And that's actually, I think, elephant in the room, the biggest actually braiding change that we're making. And I would put, I would think of the mergers here, I would braid and statelessness like on the equivalent level of like breaking or like big, big meaty change that we need to think really hard about. And yeah, we should evaluate it like with a similar level of scrutiny.

• 1:22:07David Hoffman?

  What other parts of the Ethereum ecosystem might upbraid implementation impact? We just brought up base rollups. I believe preconfirmations just get completely eliminated.

• 1:22:16Speaker 01

  So you can still have inclusion pre-comps. You can't have execution pre-comps because what that is, an execution pre-comp is basically the monopolist telling you, I will use my monopoly to make sure that you get this particular piece of state early.

• 1:22:31Speaker 02

  I mean, I think there's very good arguments that you can't have execution pre-comps anyway.

• 1:22:34Speaker 03

  Anyway, yeah.

• 1:22:36Speaker 02

  So I don't know how much we're actually giving up on that. And then, yeah, I also think it's not directly related to braid. But I think probably something everyone can, at least a lot of folks have now started to agree on, is that lowering the block time is a really admirable goal that would improve base layer UX, would improve base layer censorship regardless of what else we choose to do.

• 1:23:00Speaker 02

  Would potentially improve, like make base rollups like work in a more reasonable way.

• 1:23:06Speaker 03

  Or a less crazy alternative.

• 1:23:07Speaker 02

  Yeah. And frankly, I think that a bunch of the downstream research questions of how do we get faster block times without compromising on decentralization are just like way better research questions than like a lot of, you know, like where a lot of energy has been going. There's a lot of other stuff I'm interested in too, but I think like if we, yeah, if we can get lower block times without compromising too much on decentralization slash in a reasonable way, that would be like,

• 1:23:35Speaker 02

  yeah, I would love to spend like a lot more time on that. I think that would be awesome for Ethereum.

• 1:23:38David Hoffman?

  Before we formally close the door on the braid multiproposer conversation, because I feel like we're coming to an end on it. I want to make sure that we've covered all the bases here. Is there any part of the braid multiproposer conversation that we, that we didn't touch on that I'm skipping over?

• 1:23:53Speaker 01

  Well, I guess since we're about to shift into, maybe I can just segue us in with braid. One of the things that is really difficult in terms of getting shorter block time, and we see it on Solana as a symptom of this, is basically the leader rotation. And so Solana has 400 millisecond blocks, but they actually have 1.6 second leader rotation. So the leader has four blocks in a row. This isn't great when the leader has a proposer monopoly. But if they don't have a proposer monopoly, we can be more accepting of them proposing four blocks in a row.

• 1:24:27Speaker 01

  So I think Braid could actually potentially help us get to shorter block times. Through this vector of not having to rotate the leaders as much.

• 1:24:34Speaker 02

  I think.

• 1:24:37Speaker 02

  I think that there's a lot of weight on what Vitalik tweeted about in Can We Remove the Last Look? I think that I probably sit closer to there's possibly an impossibility result somewhere in here that I'm nervous about. And I am very excited to see what future work comes out of it.

• 1:24:55Speaker 01

  I think you also will change your mind tomorrow as you're wants to Charlie, but I will show you some evidence that the last look isn't quite as bad as you think it is. Like, I know the model that you're thinking of in your head, because I wrote about it in the paper. And I think that there are a lot of arguments for why it's not quite as bad as you're thinking it is. It doesn't unravel completely the way that you think it is. So we can chat about that another time, but I think last look is obviously not good. I think 50 milliseconds of last look is a lot better than two seconds of last look, just to be clear. And I think that 50 milliseconds of last look isn't the end of the world.

• 1:25:34Speaker 03

  I would contend that though, right? Like, because the 50 millisecond advantage is accessible to, you know, two people, whereas the two second advantage might be accessible to a broader audience. So I think like when I think about.

• 1:25:45Speaker 01

  It's accessible by definition to one person in the fossil design.

• 1:25:50Speaker 02

  No, he's making a point about centralizing effects, actually.

• 1:25:55Speaker 02

  Yeah, I mean, I think everyone's super excited to hear the arguments, I guess, like my sort of epistemic humility about it is just like, you know, so far we've never really seen like a trustless mechanism where power in a lot of different forms doesn't concentrate. And so I think like. Probably I'm most excited about a roadmap where we pursue some form of Braid or Multiplicity and continue quarantining the last look.

• 1:26:25Speaker 02

  And I worry quite a bit that if we don't do that, I mean, we don't acknowledge the last look's existence and quarantine it, then the meta-game that we end up with is going to be not what we intend, but in really subtle ways that are actually like much more destructive. And the the simple analogy I would give is like, there was a point in which Solana had no mempool. And then Gito created a mempool. And then you started to see sandwiching because Gito created the mempool, right? And then everyone gets mad and says Gito caused sandwiching. And then Gito gets rid of its mempool on Solana. And we fast forward like a few months and it turns out there's a bunch of sandwiching still. And why is this? Well, it turns out it's really interesting. There's a bunch of different reasons.

• 1:27:06Speaker 02

  One is like, I think like a Russian or like some weird country like sourced validator has accumulated a bunch of stake in order to be able to see transactions. There's a bunch of backroom deals between different validators and different people with views into the mempool from RPC providers and that kind of thing. And I guess like I'm, yeah, I'm super interested to see the future research, but I guess where I land on it today is just like,

• 1:27:31Speaker 02

  we've so far never been able to create a mechanism where power doesn't concentrate that way. And rather than sort of pretending that it won't or closing our eyes to it, I generally prefer the direction of like acknowledging it and quarantining it. And I think we still got a much better system on a bunch of dimensions if we do implement Braid or Multiplicity for the weaker form of censorship resistance that that enables.

• 1:27:55Speaker 01

  I would just say, I don't think that what we're doing, if you look at our research, I think Milesh and I, in particular at SMG, have actually done the most work on latency games and of anybody in the space, actually. Like we, from a research perspective, in terms of the microstructure of Ethereum and quantification of latency games, understanding these centralizing effects. Half our papers are titled "Centralizing Effects of X." We have a new one coming out, "Centralizing Effects of A Tester-Proposer Separation."

• 1:28:28Speaker 01

  Like you're preaching to the choir here. We absolutely acknowledge those things. We're not gonna, you know, try and push ahead with something that we believe is inherently flawed on those dimensions, because those are the dimensions that we spend a lot of our time thinking about. Um, and I would just say like, we shouldn't try to paint braid as like, oh, we're gonna ignore last look, absolutely not. Like, in fact, we have a specific desiderata on how much last look there's gonna be, and we wanna prove properties about that.

• 1:28:56Speaker 03

  Quantification, you mean?

• 1:28:57Speaker 01

  Yeah, I think, I think in some sense, like, there's almost no quantification of what that looks like in the fossil design right now.

• 1:29:04Speaker 02

  There definitely, there definitely isn't.

• 1:29:07Speaker 03

  But it's also not a goal.

• 1:29:10Speaker 03

  Because we agreed earlier on that the goal is just for, you know, not the traders.

• 1:29:18Speaker 01

  I don't think that's the only goal, at least the early versions of multiplicity, that wasn't just.

• 1:29:24Speaker 03

  No, totally, totally. I'm just telling you that reasonable people might disagree on what you can achieve with a simple, easy to implement da-da-da mechanism.

• 1:29:34Speaker 03

  And maybe the point is that this is like as far as we can get with a simple enough mechanism, and then maybe, okay, if you can do beyond that, might require a bigger change, that's much more.

• 1:29:44Speaker 01

  And just to clarify, like, I am really, like I said, focused on the traders and, and making, that's what my research is about, that's what I care about, that's what my goal in doing research in crypto is, is basically make sure the trading experience works and make sure markets work and make sure spreads are tight. And I don't care about as much about the other stuff that, uh, these other things are trying to get. I think they're much, much, much less important for us to do. And if the complexity overhead is similar and we get a very nerfed version, as Dan Robinson, your colleague, says, a nerfed version of inclusionless that isn't for MEV, what's the point? We're gonna do almost all the same work for this thing, and that's just.

• 1:30:29Speaker 03

  My, my contention would be that, you know, I kind of like, I never really related to like a 3M L1 as a place where we're gonna like, play all the, you know, long-term, like the high value trading. I always thought that like we would move it out to the layer twos and we can actually quarantine and solve the problem in like more tailored ways. So that might also be part of like my embedded assumption here that actually for me, the L1 is like for the synergy resistance. And again, transitory phase, layer two ends up having all the activity. And that's where you can like play more, play more with the parameters of the system, whereas the layer one is a bit more sensitive to me to like start to try to do too many things.

• 1:31:08Speaker 01

  Yeah, I think if the L2s end up being the ones who use Braid, because that's where it's relevant and that's where the trading's happening. I'm not gonna be, uh, not gonna be miffed about it. I think that's a fine. But I like the L1. I want to make the L1 great, too.

• 1:31:25David Hoffman?

  George, how's rest going?

• 1:31:27Speaker 03

  Pardon?

• 1:31:28David Hoffman?

  How's rest going?

• 1:31:29Speaker 03

  Amazing. Um, we've been doing a lot of work, uh, over the last year. Uh, we cut the first 1.0 release of the RETH project, uh, a few months ago, a couple of months ago. After we did a security audit with Sigma Prime, who are the authors of the Lighthouse project, big shout out. Amazing team and we love working with them. Um, actually, like, we have been, we have contemplated in the past implementing consensus implementations, not necessarily for L1. So I don't, we are not interested in doing an L1 consensus implementation, but for decentralizing sequencers on the layer two or for facilitating communication among off-chain services like Aginlayer, AVSs, or symbiotic restake networks.

• 1:32:14Speaker 03

  So generally, really excited. Um, we employ almost 20 people right now working on open source. Um, I think most of the trading that happens on the entire EVM ecosystem uses our infrastructure, whether it is Dragon Rakitas, our EVM implementation, or Foundry for developing smart contracts, or even builders using, uh, our code to build blocks. And notably Flashbots, a couple of months ago, released their R Builder, which is an MEV builder, open source, written Rust, to level the playing field between things. So yeah, I've never been more thrilled. And next week, we're actually throwing a conference in San Francisco,

• 1:32:56Speaker 03

  where we'll showcase for two days what we've done and hopefully get people excited about building more with it.

• 1:33:02Speaker 01

  I've heard rumors that Flashbots isn't the only builder using, uh, some parts of RETH for their stack as well.

• 1:33:09Speaker 03

  Totally.

• 1:33:09Speaker 01

  Might not be open source.

• 1:33:11Speaker 03

  Totally, yeah.

• 1:33:13David Hoffman?

  What are your goals for RETH over the next year or so? What do you want to see happen in the RETH ecosystem in 12 months?

• 1:33:18Speaker 03

  Yeah. So how I relate to the RETH project is that... It becomes this SDK that everybody uses to build nodes and other EVM and beyond EVM centric infra. And, you know, people want change for a long time. That's why we had the substrate, the Cosmos SDK. And I think REST's final form is that it actually becomes an evolved version of such projects. You would use REST to build Ethereum L1 nodes, you would use REST to build OP REST, Arbitrum REST, you know, Polygon REST, whatever. You can name a lot of things in that direction. Actually, this morning, we were talking about how we

• 1:33:59Speaker 03

  could implement a Starkware-flavored version of REST that would use Cairo as its runtime. It would be a great stress test of the flexibility of the, as I've been calling it, the REST SDK. So how I think about the REST project is, A, stability for Ethereum L1, and we hope to push forward the research from there. That's why this conversation is particularly interesting to me. It's been really humbling to be a part of the core dev process. It gives you new appreciation for being sometimes more conservative about what decisions to make on the protocol, because you have to be really precise, really careful, but also it has given us great appreciation for how we can bring our more, you know, aggressive

• 1:34:42Speaker 03

  shipping to Ethereum while respecting this constraint of being very principled. And we think we strike a fine middle ground right now. So that's on the Ethereum L1 stability. On the Layer 2 world, I'm really excited about breaking through what we've been talking about, the gigagas barrier, which is this, if you think of a median Ethereum transaction being 100k gas, 1 gigagas means 10,000 transactions per second, and we think that we can give every Layer 2 in the world that for free. And I think it's very important to get the ecosystem to stop talking about performance, almost. I don't think it's, you know, it's

• 1:35:26Speaker 03

  kind of like funny, because we think a lot about performance, but I kind of think it's really unexciting to talk about. I think it's Stable stakes. And in the cloud world, you know, if you want more performance, you just pay for it. And and that's it, you know, you up your bill a little, you don't raise a hundred million.

• 1:35:42David Hoffman?

  Right.

• 1:35:42Speaker 03

  Uh huh to to to to go do it. So uh, super excited for breaking through the performance barriers. Um, with the rest projects, uh, next steps and we'll have some exciting, uh, we're gonna cut a new release in two weeks where we hope to have like a very exciting benchmark for that. Um, and the third thing is I just want the rest project to facilitate the experimentation. Uh, I think it's very important for nodes to stop being thought of as this scary, huge like monolith that people care. And, you know, we talk about modular blockchains. I I don't really relate to that term. I relate to a modular code base.

• 1:36:23Speaker 03

  Uh, by having very modular code base, you can onboard new people very easily, can iterate very fast. The last thirty days, the rest project had five hundred pull requests and fifty contributors. And the people that we work on rest are like ten. So you can see how by being very intentional about having clear testing process, a clear documentation, very clear separation of concerns can move very fast without actually breaking things. And I actually find that really inspiring. Uh, and it's been just an absolute privilege working with the people from the core devs, from layer twos and our own team to make that a reality.

• 1:37:00David Hoffman?

  Yeah, I do think like every single corner of Ethereum has at least one eye on the rest project and the progress. So I think everyone's rooting for you.

• 1:37:07Speaker 03

  Yeah, um, we actually have been working also on uh, you know, like the retro project is not just like for nodes, it's for building additional infrastructure. So recently we've been collaborating with succinct. Uh, who's building SP one, which is a ZK uh VM uh to basically just import rest code into an SP one program and just run it. And that's really impactful because it means that now, okay, the red, you can do a ZK EVM with no code changes.

• 1:37:37David Hoffman?

  Right.

• 1:37:37Speaker 03

  Reusing layer one Ethereum code. And that's again, very important because instead of doing cowboy modifications that come from custom code that again, somebody raised a hundred million dollars to build or something, you're just gonna reuse like production code that's used and secured. And is trusted ultimately by a very wide set of production operators. So all that is to say, very pumped, it's been almost two and a half years doing this. Um, and yeah, I'm excited for everyone to go and run Reth in production.

• 1:38:08Speaker 01

  Cool. Can I just say, I feel like there's kind of a conspiracy theory among the paradigm skeptics who say, oh, Reth is kind of a design to take over a core devs and have influence, but I think if you just listen, just listen replay the last five minutes of George's, you know, very excitedly talking about the tech. Like, it's clearly not that, right? Like, it's clearly just like people who want to like make the system better and fix things.

• 1:38:37Speaker 03

  And this. We like the tech.

• 1:38:39Speaker 01

  Yeah, it's, it's just like so not that. Nobody here, we, we work, I work at consensus. We have obviously interests, but like the goal is not that. It's just to make Ethereum awesome. And if we make Ethereum awesome, then everybody is going to be better off. And we're going to grow the pie a hundred X and everybody's going to be a hundred X.

• 1:38:59Speaker 03

  And don't get me wrong, we have views, right? And the views might not always align with everyone. But the views, and yeah, we have a portfolio and there might be actual interests, you know, but it is important that you surface the interests and you can have a real conversation about them. Versus um being, you know, um, kind of like sus about them and saying, oh, I want this EIP to go in. No, you have to show proper motivation. And for example, recently there in the core dev conversation, there's been a large uh push on uh EOF, uh, which is an EIP for improving the EVM. Uh, and we think it's important to push that forward to make the EVM better. It's not like there is some Ethereum motive because maybe it would make someone else better. You just need to make the system better. You need to bring sufficient motivation on the table.

• 1:39:44Speaker 03

  And that's how high the bar for the core dev process is.

• 1:39:49David Hoffman?

  Charlie, are there any other paths of the Ethereum roadmap, Ethereum research efforts that are floating around your brain that really excite you or interest you that we haven't yet talked about today?

• 1:39:58Speaker 02

  That's a good question.

• 1:40:01Speaker 02

  Honestly, I'm excited. I'm excited for us to make real progress on the MEV issue. Although I think you've heard, I think like the debate that you probably heard today is actually really positive because we're finally making progress towards like a shared understanding of like reality and what's achievable, basically. And I think for the last, I think it's probably one of the most controversial parts of the protocol roadmap, like, you know, more or less, people like the blobs, people like the gas, we like, you know.

• 1:40:33Speaker 03

  He doesn't like blobs.

• 1:40:34Speaker 02

  I know, but more or less, whatever. Like, I think that there's, and I tweeted about this recently, I think there's a number of like freebie or just like super positive protocol improvements that's like when it happens, everyone's going to be stoked, that I'm excited about.

• 1:40:49Speaker 02

  But I'm probably honestly most excited about us having gone from, I would kind of describe, characterize it as a situation where like, there wasn't even that much agreement on like what the important questions in the sort of MEV block production research space were, to there being like really focused conversation. And like the set of things that we could pursue, having gone from this like really wide map to more of like, okay, like we have some general agreement on like, we're going to do something in this direction. And I think that's like incredibly, incredibly bullish.

• 1:41:23Speaker 01

  Yeah, we're arguing about whether we're going to have 100 milliseconds of last look or two, two seconds of last look. It's a pretty, pretty good place to be at. Yeah. One thing I want to say, I think we as, because it's an attention game in crypto and attention is a currency, and the more attention you get, the more everything you get, there's a tendency for the excitement around Ethereum to be on the biggest possible proposals. And Braid is a big proposal, like you said, George, I would agree, it's maybe even more of a lift than the merge itself. But I'm also working on a few other things and I encourage everybody within the ecosystem to work on these kind of like parameter tuning things and maybe it's more suited for kind

• 1:42:07Speaker 01

  of an economist type of, of thing. Let me just mention two of them. I think one of them I've, I've been harping on is the lack of a Uh, reserve price for blobs and it's not just that blobs are being sold for seven way, which is zero dollars. So like in, in, in a whole month in June, I believe there was all of the blobs sold. The price of them was five dollars total in thirty two days.

• 1:42:38Speaker 03

  Right. And similar for other DA networks, right?

• 1:42:41Speaker 01

  Right. Similar for other DA networks. So I think the, the argument is, oh, maybe we should price that at the marginal cost of the network. That's an important point. Um, I'm doing the work right now to try and figure out what that marginal cost should look like. Another reason you want to do this is because seven way is so small. It's like oftentimes twelve orders of magnitude smaller.

• 1:43:04Speaker 03

  It's not worth the bandwidth.

• 1:43:06Speaker 01

  It's, it's not worth the bandwidth, but, but more importantly, when we want the fee to kick in, in times of congestion, it takes a long time to kick in because of the way fifteen fifty nine works.

• 1:43:16Speaker 03

  Start so low.

• 1:43:17Speaker 01

  You can only adjust so much. And when it's, when it's nine orders of magnitude, twelve orders of magnitude that you need to increase, it takes a long time. And in that time, the fee mark is not operating properly. So my argument is let's, let's bump it up, put it up somewhere near, you know, ten to the ninth or something rather than, uh, ten to the one. Uh, so like a way instead of a way. And it will take many fewer cycles to get up to speed. And I think that would stop a lot of the spikiness that we see going on and it would make the market slightly more healthy. And so I'm gonna be working on that. Another thing I'm gonna be working on, I'm giving a talk tomorrow at SBC about, which is some slight adjustments to the way we set parameters for execution gas

• 1:44:02Speaker 01

  uh, in fifteen fifty nine. And I just say like, we need to also, we can think about big things and they're awesome and they're fun to think about and they're nerds nipes, but we should also just like do the little things and get the little things right. And I think we probably should have put the reserve place, price floor in when we did four eight four four in the first place, but now let's put it in, uh, in the next hard fork. It's a very small change. The, the code for implementing it is already there. You just need to set the parameter. And I think we should do more stuff like that as well. Um, cause those little one percent improvements are gonna add up a lot as well.

• 1:44:36Speaker 03

  I think there is agreement. I think there is not an unpopular take, basically, that there probably should be made some adjustment to how blobs are priced.

• 1:44:44Speaker 01

  Right.

• 1:44:45Speaker 02

  Max convinced me that the 4844, uh, no, sorry, not 4844, the gas fee update rule is too fast. That'd be a good change. Um, I think everyone wants max EB. I have like a running list.

• 1:44:57Speaker 01

  Oh yeah, max EB. Can we talk about max EB?

• 1:44:59Speaker 02

  Yeah.

• 1:44:59Speaker 01

  Uh, this is a really important change that's coming in the next hard fork in Pectra, which is basically, we're, right now, we have 800,000 individual validators. There's a 32 ETH cap on how much you can put in your validator. And we have 800,000 of them right now, or even more, maybe, that's the last time I checked. It's probably more now, because everybody wants to be staking on Ethereum. And the problem with that is places like ConsenSys, we run about 15,000 nodes. And we are running 15,000 nodes on many fewer boxes than 15,000. And so we sign a signature for each of our attestations, especially during finality, which requires everybody to attest. And we have to aggregate all of those signatures.

• 1:45:41Speaker 01

  So we have 800,000 signatures for less than 10,000 boxes. And max EB allows you to stake much more in a single validator. And so we'll be able to reduce the number of signatures that we're sending for the same information. And that will in turn reduce message overhead in the system. And

• 1:46:01Speaker 03

  Strict upgrade.

• 1:46:02Speaker 01

  It's a, it's a big bottleneck for a lot of stuff.

• 1:46:04Speaker 03

  And less CPU.

• 1:46:05Speaker 01

  Yeah.

• 1:46:06Speaker 03

  Less CPU. Which is an even bigger issue right now, because the network, let's say you can make it faster, but the aggregation is CPU bound, so you're kind of like hitting a, hitting a limit.

• 1:46:15Speaker 01

  And we can change the way the signatures work, because right now they're kind of tailored so that the signature aggregation libraries work really well. And if, if we don't need to do that as much, because we have 15,000 signatures instead of 800,000, then

• 1:46:26Speaker 03

  And that might actually be like a Basically, why we cannot lower the block time, you know, as is, um, you know, say you cut the gas limit in half and you double, sorry, you, yeah, you cut the blo- the gas limit in half and you halve also the block time so to keep the throughput constant. Um, is because of how many signatures we're aggregating.

• 1:46:47Speaker 02

  There was a original hypothesis that the 32 ETH limit stemmed from, which is largely related to the idea that we were not going to have stake pools. Um, like we were not going to have a lot of people pooling stake. And I think that we're just kind of at a place where like the trade off to the amount of signatures we have to aggregate that are really just the same party. Um, like it, clearly there is a lot of pooling and we're bearing like a huge cost for it. Um, and this is not like an anti-solo staking take, but it's just like, it really is just like a strict upgrade, I think. Like it, it turns out the hypothesis was not right and we should like recognize that and like lower the number of signatures we have to collect massively, uh, which gives an avenue to lower block times, higher gas limits, et cetera.

• 1:47:31Speaker 02

  Um, I think it's, yeah.

• 1:47:33Speaker 03

  And it's, it's kind of nice because you can still have 32. Or if you have more, just have more. There is, there, there has been, uh, and I'm not a CL dev, so I cannot opine specifically on like if, if this is true or not. But I believe, uh, you know, Terrence and friends, but basically implementation complexity wise, there are reasons. Because right now, the 32 ETH is like a constant in your code. It's like, or a parameter, whereas now you have to make it a range of parameters. And that complicates the code actually. So pushback around it that you might have seen relates a lot to, no, it's not like, oh, I changed 32 to 24, 8, uh, to 2048.

• 1:48:18Speaker 03

  I changed it from a single value to a vector and that is all around the code base.

• 1:48:23David Hoffman?

  Ah, that's where the complexity comes from.

• 1:48:25Speaker 03

  Yeah.

• 1:48:25David Hoffman?

  Yeah, because to my understanding, Maxi B is more or less has consensus

• 1:48:30Speaker 03

  Yeah.

• 1:48:30David Hoffman?

  about inclusion.

• 1:48:31Speaker 03

  It's like, can we ship it in time and all of that? Yeah.

• 1:48:34Speaker 01

  Yeah, what, what exactly is the implementation? Well, the cleanest way to do it, so we don't introduce tech debt, but.

• 1:48:40Speaker 03

  Yeah, which says something about thinking more about things upfront. And, you know, this is a classic software engineering thing. How much time do you spend designing versus implementing? And, you know, how do you post more time and then go back and redo the thing, right?

• 1:48:51Speaker 02

  Also, super bullish that ETH has a spec, actually.

• 1:48:55Speaker 03

  Yeah, actually, it's like the CL side is like so much better done than the EL side. The CL spec is amazing. And on the EL, we're still, I think it's like universally accepted that like basically Gath is like the the the truth. And you adjust to it, which not a problem at all, but just, you know, it makes the development of things different. Whereas the CL has a very crisp development process, which the EL code of process should aspire to.

• 1:49:24Speaker 01

  This is especially nice for, you know, think boys like myself, who just, we don't want to necessarily dig into the rust or anything. We just want to see the spec and see what's going on.

• 1:49:33Speaker 03

  And many times the code that you read is like optimized and like it might not like be obvious.

• 1:49:39Speaker 01

  It's like some random bytecode like thing that does it faster, but you have no idea what's going on. So the the spec is very useful and we definitely, we we did a recent paper on executes. And I looked, spent a lot of time looking at the consensus layer spec.

• 1:49:51David Hoffman?

  Right. Charlie, why why did you bring that up about the Ethereum spec?

• 1:49:56Speaker 02

  Um, just because with these kinds of software projects, even as far back as Bitcoin, um, and Bitcoin or Consistency, like, you know, a lot of stuff, to George Joe's point about like Gath being the reference implementation, um, you run into this issue where like the original implementation, in a sense, is the spec. It has like, you know, lots of implementation nuances or choices that weren't, it wasn't necessarily like anyone thought of them or thought about the decision, like it's just the way that it ended up getting implemented. Um, and like, I think Ethereum on this spectrum like is doing quite well, which is like most stuff is pretty formally specified. The consensus layer is great because it was almost, we realized the problem and tried to solve for it from the beginning.

• 1:50:40Speaker 02

  But even the EL, like, you you know, you have a pretty good sense of how the protocol is supposed to work, like what the intended behavior of it is. Um, and I just think that's like very, uh, great. I mean, like, I think, you know, Ethereum as like a super decentralized, uh, like credibly neutral censorship resistant computer, like knowing how it's actually supposed to operate is like extremely.

• 1:51:04David Hoffman?

  Useful.

• 1:51:04Speaker 03

  Yeah, and you know, you know, like, people like to, there's these two schools of thought, should there be one client or many clients? Um, there's many protocol security reasons that David you might have talked that knows him on the podcast, so I will not repeat. But basically, the most important reason for me is that more people knowing how the thing works is just good.

• 1:51:22David Hoffman?

  Right. I remember Vitalik actually brought up this line, it's like, there's no real point of having these decentralized systems if only like 10 people knows how they know how they work.

• 1:51:30Speaker 01

  I would, I would like to reason by analogy a bit, uh, like, I would say it's almost like having a checkpoint so that the node can, you don't have to run the node from Genesis. Because I, I'm like relatively new to the research, like, med research, even client research is even more new to me. And being able to go read this back versus having to read the code means that I can catch up faster and like, we're, we're always producing new stuff and changing stuff. And so, like, I, I look at the speed at which Solana changes and I'm not looking at Solana full time, but I try to keep up a little bit and then I'll go in and I'll talk to like some of the G2 guys and like, they're like, oh yeah, by the way, like, we changed the way that everything works since the last time we talked.

• 1:52:12Speaker 03

  Two days ago.

• 1:52:12Speaker 01

  Yeah. And it's, and then another change is going in in two weeks. By the way, do you have any feedback about it? It's like, you know, and then I'll, I'll try to give feedback, but it's so much harder than the way it is working on Ethereum, because we all know and we all agree and our, our models are lined up. We all agree on what the model of, of the thing is and it works like that. And on Solana, sometimes they agree on what the thing is supposed to work like and it doesn't work like that, or the other way around. So I think that's a definitely a good thing about developing on Ethereum.

• 1:52:40Speaker 03

  And then you go to mainnet validators and you ask what's going on?

• 1:52:43Speaker 01

  Yeah. And then they actually don't run what's in the codebase that you looked at, so.

• 1:52:48David Hoffman?

  Well, guys, this has been a fun little tracutery board of Ethereum protocol topics at the very end of this, but I want to bring it back to, to you, Max and, and Braid. Uh, Braid, work in progress. Who do you want to hear from? Who can support you? Uh, what are next steps? Um, any callouts to the listeners in the audience of this?

• 1:53:04Speaker 03

  And who can roast you?

• 1:53:05David Hoffman?

  And who can roast you?

• 1:53:06Speaker 01

  Well, I would just say, like, we're welcome to hear roasts. I would say it's, it's often easier to get people to engage deeply with an idea when they first hear it. And almost I wish we had waited a couple of months. We, we kind of, I gave an early talk at this Paradigm Research Day and it kind of. There's a lot of excitement about it and it got out, which is awesome. And that's why I'm here talking right now.

• 1:53:30David Hoffman?

  Yeah, I got excited specifically.

• 1:53:31Speaker 01

  But I just want to urge everybody to uh, keep your minds open, even if you're skeptical today. Um, read with an open mind. Do not you, you know, immediately shut your mind off to these things. If we, I'm spending a lot of my day thinking about this stuff, thinking about new ideas every day. And I think we can probably get there. I'm very optimistic, knowing the awesome people that we have working on it. And what I do know about MEV and I think just keep an open mind. We're gonna do the work. If we can't demonstrate, it's not going in, obviously. And there's many different sides of the argument, but I'm really excited

• 1:54:14Speaker 01

  for basically the first time about the direction that we're going. Um, for a long time I've been like, oh, we're kind of trending in the wrong direction. PBS has become very centralized in the time that I kind of started working at the maximization point of the decentralization of PBS. And I wrote a paper that said PBS is going to centralize and then it centralized in a year. And so I was like, oh, what are we doing here? I was like, oh, I'm going to go back to grad school because like, nobody's listening to my ideas. So I'm gonna go like write some more papers in grad school that nobody's gonna read there. Um, but now I'm like, hey, like people are listening. Um, you know, there's ideas. We're discussing

• 1:54:55Speaker 01

  the difference between a hundred milliseconds and two seconds of last look. And that's just so much better than where we were a year ago. And even where we were two years ago, and we're just starting to talk about these MEV topics in, in detail.

• 1:55:08David Hoffman?

  Well, Georgios, Charlie, Max, I feel like I have gained like at least a couple IQ points from just listening to you guys today. So thank you guys for making your way over here from SBC and, and joining me in, in the studio today. It's been really fun doing a podcast in person. Thank you, David. Thank you, David.

• 1:55:24Speaker 01

  Cheers. Thank you. Love these boys.

• 1:55:27David Hoffman?

  Bankers Station, you guys know the deal. Crypto is risky. All that good stuff. You can lose what you put in. We're headed west. Uh, this is Frontier. It's not for everyone, but we're glad you're with us on the Bankers journey. Thanks a lot.