Hasu and Jon bring on Mike Neuder (Ethereum Foundation) and Chris Hager (Flashbots) to discuss the design philosophy of proposer-builder separation (PBS). They first dive into the past and present implementations of PBS, including MEV-Geth and MEV-Boost on Ethereum. Then they discuss the future of PBS - whether PBS should be enshrined, protocol-enforced proposer commitments (PEPC), PBS on L2s, how to prevent censorship, and more. 
__
Timestamps:
(00:00) Intro 
(01:12) What is PBS?
(05:37) The History of PBS
(08:43) MEV-Boost
(10:18) Block Production in Proof-of-Work 
(11:31) Benefits of PBS
(14:17) PBS Makes Based Rollups Viable
(16:21) PEPC & Proposer Complexity
(17:46) Other Builder Services
(19:49) PBS & Regulation
(22:48) Regulation & Encrypted Mempools
(24:38) Division of Labor is Inevitable
(26:15) Risks of PBS
(29:03) Development of COre Protocol Software
(33:31) PEPC, POB, & Alternatives to PBS
(41:53) Decentralization vs. Usefulness Tradeoff
(46:30) State of PBS in MEV-Boost
(50:51) Optimistic Relays
(52:09) Enshrined PBS (ePBS) 
(55:55) PBS on L2
(58:47) PEPC
(01:05:25) Proposer Commitments & User Intents 
(01:09:03) Concluding Remarks
(01:11:05) Recap
(01:12:06) PEPC, PEPC-Boost, & MEV-Boost+
(01:18:44) PBS From First Principles
(01:21:41) PBS is a Philosophy, Not an Implementation
(01:25:44) To Enshrine, Or Not to Enshrine?
(01:35:12) In-protocol vs. Out-of-protocol Development & Funding
(01:50:16) Censorship & Proposer Agency
(01:58:15) Outro & Disclaimer
__
Hasu - https://twitter.com/hasufl
Jon Charbonneau - https://twitter.com/jon_charb
Uncommon Core 2.0 - https://twitter.com/UCC2_xyz
Mike Neuder - https://twitter.com/mikeneuder
Chris Hager - https://twitter.com/metachris
__
Relays in a post-ePBS world - https://ethresear.ch/t/relays-in-a-post-epbs-world/16278
No free lunch – a new inclusion list design - https://ethresear.ch/t/no-free-lunch-a-new-inclusion-list-design/16389
Payload-timeliness committee (PTC) – an ePBS design - https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054
Notes on Proposer-Builder Separation (PBS) - https://barnabe.substack.com/p/pbs
PEPC FAQ - https://efdn.notion.site/PEPC-FAQ-0787ba2f77e14efba771ff2d903d67e4#41230925420345af84f31b50d806b8ed
PEPC Open Problems - https://docs.google.com/presentation/d/12kpwAXbZqUA0fu2HnZKSesVwO31ICbgIiacHd0EQ_fk/edit#slide=id.g2401d3821ec_1_0
PBS Guild Proposal [v3 WIP] - https://collective.flashbots.net/t/pbs-guild-proposal-v3-wip/2223
MEV-Boost+/++ - https://www.blog.eigenlayer.xyz/censorship-resistance-with-restaking/
__
Disclaimer: The material and information presented in this podcast is for general informational purposes only and should not be considered investment advice. The views, thoughts, and opinions expressed in this podcast are solely those of the speakers and are not the views of any entity or other person with whom the speaker is affiliated, including, without limitation, DBA Crypto, LLC. The “DBA Crypto” name and all forms thereof are the sole property of its owner, and its use does not imply endorsement of or opposition to any specific organization, product, or service.

Welcome to Uncommon Core, where we explore the big ideas in crypto from first principles.

This show is hosted by Jon Charbonneau, co founder and general partner of DBA, and me, Hasu, strategy lead at Flashbots and advisor to the Lido DAO.

Today, Hasu and I sat down with Mike Neuter from the Ethereum Foundation and Chris Hager from Flashbots.

We had a great time chatting through PBS, also known as Proposer-Builder Separation.

We talked about the history of PBS on Ethereum, talking about what it looked like on proof of work, and how that brought us to where we are today with MevBoost on Ethereum right now.

We also looked ahead, looking at the future of PBS, asking each other, should we be trying PBS or not?

That included talking about really fun new ideas like Pepsi.

We also had some fun at the end, talking about what should PBS look like on other domains, especially layer twos on Ethereum, like other rollups,

where we chatted through why we think it could actually look very, very different on L2s compared to Ethereum itself.

What is Proposal Builder Separation or short as we know it PBS?

So the first thing that I'll pick out that we kind of used before, it's the quote from Barnaby is like still my favorite kind of 1 liner description of what it really is.

So PBS is first and foremost, a design philosophy recognizing that protocol actors may invoke services from third parties in the course of their consensus duties.

So I really like that it's just a kind of high-level setting of what it is.

Because it really, while we look at it in Ethereum as a very concrete implementation, The reality is it is just kind of a higher level design philosophy of we understand that we're going to have protocol actors that are responsible for certain things, and then there's going to be an economic incentive and for various other reasons for them to outsource certain actions to other actors that may not be actually in the protocol.

So concretely, the way that we're used to thinking about that is in the Ethereum world, where we have validators, 1 of which will be the active proposer at a given time, to propose a block to the rest of the network.

And the reason that we have concretely proposer-builder separation here is that we want that proposer to be relatively unsophisticated and yet be economically competitive, such that we can keep the validator set decentralized.

So they can outsource the very specialized task to this network of specialized block builders, which sit outside the protocol.

And those block builders are responsible for building, you know, what is the most optimized block that can extract the most value, such that they can pass the majority of value back.

Because otherwise, what you would have conversely, is if we don't have this ability for proposers to kind of interact with this out-of-protocol market in a relatively trust-minimized way, well then you would simply have a very clear return to sophistication where the only way to be a competitive proposer would be, okay, well now you need to be a builder in-house.

You need to be super sophisticated and know how to optimize everything.

So it's trying to get at the fact that you're going to have these different roles and we need to design, like, what is the right way to have an interface between these kinds of in-protocol and out-of-protocol roles?

And right now, the way that that works with MevBoost is kind of a strapped on way of doing that.

And like a lot of the research right now that like Mike has been doing over the F is like how do we kind of maybe bring that a little bit more in-house and like what should that look like to try to make that interface between the in-protocol and out-of-protocol actors even more trustless.

Yeah, and I always like to kind of circle back to Vitalik's endgame post.

The last sentence of his post is basically, the future of many iterations of these designs will probably end up in a world where there's centralized production, decentralized verification, and strong anti-censorship properties.

And he kind of talks about how some ecosystems might start more centralized in the block production world and evolve into something that has decentralized verification only.

And others could take different trade-offs in the initial state, but ultimately we might always end up in that state where we need to firewall off the heavy duty actions that the validators need to take from something that you know can be run on a local machine has like credible decentralization features.

So that's kind of how I like to think about it.

Yeah you spoke to a lot of things that I'm also thinking.

I think in particular it's also a case of there is either an implicit or an explicit auction.

And if the auction is implicit, it has a lot more negative externalities and incentives to centralization.

And PBS recognizes that not all protocol actors may be able to fulfill all the duties in a comparatively performant way, and need external support for that, to also keep the decentralization of the network stable.

Yeah, and what I particularly like and kind of why I picked out this quote is that it really hones in on PBS as philosophy, right?

And I think the PBS, the implementation on Ethereum faces a lot of criticism from different directions, all great arguments and concerns that we will also go into in this episode.

But really, I think that like general idea behind it is 1 that is extremely sound.

And I think that all of you laid out here really well.

So with this high level overview out of the way, I'd like to go a bit, you know, a couple of years back and hear from you.

How do we get from there to where we are today?

I think historically, the PBS marketplace was a little more explicit in the Mevgeth world before we had proof of stake merge.

So essentially in that scenario, there was a few large mining pools that controlled a huge portion of the hash rate.

Mevgeth was the ability, like provided the ability for searchers to send bundles to those miners.

The searchers were able to send bundles to the miner kind of without worry about the miner stealing them because since there were so few, the miner's reputation was worth more than stealing the contents of that bundle.

So in that regard, the interaction between the searchers and the block producers was simpler because there were so many fewer block producers.

And then I guess as the merge kind of approached, a lot of people were talking about PBS as a general approach.

And I think even we're considering like holding off on shipping the merge until we had some in-protocol version of PBS that could be accompanying, you know, the actual, the merge hard fork.

I think that that was discarded in general because the merge was already, you know, a huge lift and adding more complexity to the software and to the spec was kind of just going to slow things down more than necessary.

And so, yeah, maybe I'll pass it over to Chris here as FlashBot stepped in and implemented MevBoost and that was like the real first PBS instantiation out of protocol that we saw post-merge?

Yeah, I think about 1 year before the merge, Stefan from FlashBots posted the OG MEV Boost specification outlining how proposers could interact with an external block building network.

And then work started in the background in the DevConnect meeting on METH day in Amsterdam in 22, that was April 22.

There was a finalization of all the APIs that were needed.

And from then on, it was clear that everybody is shooting for the merge with PBS, with Mavboost PBS enabled.

I think at this point, it was fully unclear how permissioned or permissionless this whole thing will be and how this plays out.

But it seemed inevitable that some form of this is going to ship.

And yeah, we worked them through the summer to deliver a permissionless relay and open-source software that also other relay operators can run and had everything ready in time, just in time for the merge, that included permissionless builder access.

Paul Matzkoff Yeah, and it might be worth just kind of running through MevBoost as a software for people who aren't familiar.

So the idea of MevBoost is there's a third party actor here that facilitates the auction between the proposer and the builder.

And the reason for that is the proposer needs to trust that the block that the builder produces is both valid and accurately pays them the amount that the builder promised.

And the builders can't simply send those blocks to the proposer for them to verify that themselves, because the proposer could just steal the MEV from the block and in that way, like take away all the earning from the builder themselves.

It facilitates this auction in so far as the builders send a bunch of blocks to the relay, and the proposer commits to the highest paying of those blocks before they actually see the block contents.

So that's an important feature here, and that kind of comes up as, I think it'll probably come up as we think more broadly about EPBS designs, which is that proposers need to commit without seeing the contents of their block in order to protect the builders from the MEV being stolen.

So the current status quo, I guess post-merge, there was maybe like 3 or 4 relays running immediately and now I think we're up to like 8 that facilitate most of the MevBoost blocks.

A bunch of builders are sending blocks to those relays and about 95% of validators are hooked up to 1 of those relays and using their connection to that relay to source their block production.

Yeah, I mean, I guess I'm really a sucker for proof of work and kind of the history of it.

So I would add that in some ways, there was even a form of proposal builder separation before MEBGEF existed in the division of labor that existed between a mining pool operator and the workers.

Because the way that it works is the mining pool operator would construct the block body and then they would hash the block header once and they would send it to the workers to hash it further.

And that hash would then have the golden answer or not.

So you find a bunch of things, you find block construction because there was only 1 party that had to do like all of the peering and the validation and the block construction and so on.

And also had to invest into latency infrastructure, right?

Being like having good propagation to other mining pools and to big exchanges and so on.

And then you had the workers who did the actual work on the encrypted block body, right?

So you also had this idea of the commit-reveal scheme even back then.

So it's funny how far back some of these ideas trace.

We established PBS as a design philosophy, right?

And I think you already touched on it a little bit, John, when you said, we want to protect validators from having kind of to do these duties that are so complicated, so difficult, that it leads to an unevenness in how much money they make or how well they execute these services.

So tell us a bit more about what are the benefits of PBS as we try to, you know, unpack this idea of, you know, let's create a healthy decentralized market structure.

So the high level benefit is kind of what Mike was talking about before as well, how in large part, decentralization of the validator set is a means to an end primarily.

That's to get certain properties out of them, out of the protocol such as censorship resistance, liveness in extreme scenarios, stuff like that.

So to get that, we want a decentralized validator set.

And then to get the decentralized validator set, we want to make sure to offload all the complexity to these other builders to the extent possible.

So that is like the simplest 1 is just to keep them decentralized.

And then the other realization kind of on top of that is, hey, if we have these more specialized, more sophisticated actors that kind of sit next to the protocol that we can like rely on to be economically incentivized to keep building these blocks, we can kind of lean into that and take advantage of it, as long as their power is sufficiently constrained.

So the simple things like that is like, OK, we can have builders do these more complex tasks going forward.

The clearest example of that being for scaling, so something like the Dank sharding design, where instead of having all of these different subcommittees where you're building all the, you effectively will now have 1 gigantic block with all the data in it.

And that is a relatively more complex task to do for 1 single person to make this larger block, make all the KZG commitments for it, et cetera.

But that helps and produces a more efficient scaling design and keeps the load on the proposers very light.

It's just a realization that, hey, we're going to have these specialized actors anyway because there's clearly an economic incentive for MEV capture reasons for them to exist, like they will need to.

So we can take advantage of that, lean into it and have them do these other tasks that we can kind of push off to them that someone needs to do in a more efficient manner.

Schmeichel And this is a new idea that you're now introducing, right?

Because so far we kind of kept it to MEV and kind of just ordering of transactions.

I mean, we touched on some things like a mining pool needs latency infrastructure and good peering and stuff like that.

But now you're really opening almost like an entirely new, much wider design space, right?

And even kind of more extreme scenarios, I would say, or pushing the same idea to different layers, it's the same kind of thing where, depends on how viable they are, but based rollups, as the simple example.

When Vitalik at first had a post probably a few years ago on rollups of like what are the different ways that you could do sequencing designs, like 1 of the ideas was something that he called total anarchy at the time.

And you basically, instead of having a sequencer for the rollup, it would just be like, what's the first 1 that lands on chain, basically?

And the reason that didn't work is because that would just be an absolute mess.

Like you have Spanham on chain, like no 1 would know who's going to win.

It would just be a lot of wasted effort, incredibly inefficient.

The reason that that kind of becomes a more viable design, and this is something that Justin's post kind of touched on earlier this year called base rollup, It's like, hey, we can lean into the fact that we now have these more sophisticated and economically rational actors who have this proposer interface where the builder for the layer 1 can effectively be slash the searchers feeding into that can effectively be the sequencers for the rollup and say, hey, I'm not going to include these 10 failed attempts to get a rollup block in here.

I'm just going to include the blob that is going to be the most efficient 1 for this rollup, and I'm going to land that 1 on chain, and I'll pass that to the proposer and make sure only that gets in.

So you can lean into it, realizing that there were going to be these economically incentivized parties who were kind of sitting next to the protocol and have them do this kind of additional work, acknowledging that, like, hey, they're going to be sitting there anyway.

We might as well, like, lean into them and use them for these different things.

Other things, stuff like for statelessness, having them create proofs to make that a viable design, because otherwise, like you'll need to give the witnesses to the validators for them to be able to be stateless, like leaning into them for all these kinds of different tasks, you realize like there's a lot of stuff that we could lean into the builders and like have them kind of outsource those kind of complexities to them.

Yeah, complexity can then also increase on the proposal side of PBS, for instance, in Pepsi, the protocol enforced proposal commitments, which are also a form of PBS where there's more arbitrary commitments a proposal can enter into.

So this whole design space provides a lot of more opportunities to build interesting things.

So it doesn't necessarily, I would say, have to increase the complexity on the proposer a lot.

Because even if they are entering into these arbitrary commitments, they don't have to be the ones who fulfill them.

And this is something that Barnaby touched on a bit in his last FAQ, where he's talking about Pepsi Boosts and stuff like that.

Where outsourcing a full block is just 1 thing you can outsource.

Like they can outsource any of these commitments where a proposer can just be opted into like, hey, here are the commitments that I'm opted into specifically.

And the builder, as long as they're aware of those, like they can build a block that's in recognition of those and like, they will send them a block that fulfills those conditions because if they don't fulfill those conditions, like they know that, you know, they're not going to get their block on chain.

It's the same kind of incentive is, builders for the full block auction.

As long as there is an interface and awareness of the builders know that the commitments that they're opted into, they can build them for them.

So if designed well, I would say it doesn't have to increase complexity for the proposers necessarily.

ProtoCollectors.com Builders can also, I would add, or a lot of protocollectors can in general do things that in protocollectors can't.

So in MEV in particular, I think there's 2 very clear things.

They can keep transactions private, they can have like a build, I can run a sealed bid auction instead of an open bid auction.

They can do simulation on the transaction so they can have, you know, like, instead of an all pay auction.

And these are some things that were valid that I could do, but it's, it's like really difficult and it's not possible really to establish this trust, right?

And so ultimately out of protocol, kind of the design space is much bigger and it then leads to a better market structure.

2 other features that just kind of jumped to mind when you were describing that, Hazu, is cancellations.

So like builders can offer bundle cancellations.

This is especially important for the centralized exchange arbitrageurs who need, you know, if the centralized exchange price moves against them, they need to be able to cancel a bundle.

And also, oh yeah, like instant confirmations, like builders could, I mean, it kind of depends exactly what type of confirmation the searcher is looking for, but they could give some guarantee on the post-state route after a bundle, you know, conditioned on their block winning the bid.

So, yeah, there's a lot that a builder can do out of the protocol, as you mentioned.

In general, I think we say PBS allows validators to stay simple and affordable and connecting that back to what you said, John, why do we want that?

It's because we want to maximize the censorship resistance of the network, right?

Because a lot of that in particular in Ethereum, so when you talk about layer twos, for example, they all have assumptions built into their own security model that basically says, you know, the layer 1 chain can't be censored for, you know, x period of time or something, right?

So this is actually kind of the property that we're trying to protect.

I've seen another argument discussed, and this is really kind of a double-edged sword, but it's nonetheless interesting to point out, which is the regulatory argument.

So the argument goes roughly like this, right, So the less discretion validators have over the kind of blocks that they build, the less they have to be regulated as any kind of financial intermediary.

And you would really kind of draw the line on the far end, like on 1 side of kind of the extreme spectrum, you would have a validator as a like money transmitter that basically has to KYC every single person that transacts to them, right?

And so it would be like an extremely kind of censored and regulated Ethereum.

And on the other end, you have the validator as an ISP or like a fiber cable.

So it's just like what it transports is just data packages and inspecting all of them would be completely infeasible.

And so it really has no discretion over what passes through its pipes.

And so I think we kind of like a big idea behind keeping proposing simple and affordable is really to also, I think, boost this argument, right?

That really proposing is, yeah, it should be kind of, you know, have the least amount discretion as possible, but when you get there, you introduce new problems, right, that we're talking about, because, yeah, like, because we are talking about really also like difficult jobs that the builders do.

There tends to be power law outcomes in this market.

And so now all of a sudden, it takes a lot fewer things to go wrong to kind of censor that market in turn.

And so yeah, ultimately you're not really solving the problem easily, you're just shifting it in some way.

Paul Stauffer Yeah, and it's probably worth just calling back to immediately post-merge the issues around OFAC compliance and censorship were largely there because the relays had to commit to censoring those transactions in some way.

So even though you allow the burden of the validators to be shifted to the relay, that still opens up like new regulatory surface that might be smaller than the regulatory surface of the entire validator set.

And also, in terms of censorship resistance, I think inclusion lists and their relationship here is also very interesting.

And this is something John and I have discussed a lot, which is if you bring back the censorship resistance properties and place them back on the shoulders of the validators, now the validator has to opt in to getting these OFAC or these sensor transactions on chain.

So it's kind of like, okay, the responsibility is still somewhere, it's just like, who shoulders it at the end of the day?

Yeah, And that's 1 of the interesting things with these designs.

It is hard to say, when you're designing inclusion lists or something like that, are you designing for a specific regulatory environment in mind where there actually aren't clear regulations, like it's pretty hard to actually do that.

But yeah, like some of the designs like that, you know, if there is a regulatory burden, this is also probably where I say like not legal advice type thing, I don't actually know.

But like some of the designs like that would seem to put more agency kind of on a particular actor where like we're saying 1 person is enforcing censorship resistance, like they're explicitly saying like you must include this transaction in a block.

That maybe looks a little more gray as compared to something like, and this is 1 of the reasons that I think that like designs like Suave and other types of encrypted mempools are like, they're very often talked about as an MEV solution.

I think that they're like very interesting from the censorship side of things.

And like, that is like a very underrated property of them is that like, they seem to be in the best direction of ensuring these properties for people while also giving everyone plausible deniability of note.

Of completely removing that agency from anyone throughout, it's just that I see a bunch of white noise and I run my algorithm over it, and here's what I get at the end of the day.

And like, that is what starts to really look like at the end of the day is like, I'm an ISP, I'm sending data packets around, I don't know what the hell any of them are.

And you're just you're like, you really are a dumb pipe at every point in the supply chain.

So like, that is like a very interesting dynamic of them that I think does get underrated at times, is that they are very much a censorship tool and making everyone a dumb infrastructure provider, as opposed to just being this MVP solution.

They are very helpful for short-term privacy, for things like making auctions incentive compatible, et cetera.

But the censorship side of things is like very interesting to me for that reason as well.

I rounded off with 1 more point and then we can move on.

But I think what I in particularly like about PBS is that it's basically acknowledging that a division of labor between different parties will happen no matter what.

And I think this becomes very clear when you contrast it to other ordering algorithms, for example, or other forms, how our blocks can be constructed, like time-based ordering, right?

Because with PBS, you really basically acknowledge that there is a market for doing these transactions with the goal of maximizing validator revenue.

And so that is the most valuable thing for them to do.

And if you don't allow validators to kind of compete on that, you know, to maximize kind of the revenue that way, then what you will get is you will get, you know, other forms, basically, of extraction that are kind of ultimately much more destructive for the chain.

And so you basically say, well, if there's MEV to be extracted, I want it to be an explicit auction.

I don't want it to be an implicit auction that's harder to monitor, that like leads to spam, that leads to late and like an entrenchment of latency advantage players and all of these things.

So it's really about saying, you know, acknowledging that the market will find a way and designing around that.

And I think, yeah, this is some like a line of thinking that I think you find in all of Barnaby's articles.

I was just going to call back to this idea that we mentioned before, which is the regulatory surface kind of changes in terms of centralization.

And I guess not even from a regulatory perspective, but just the fact that in the current status quo, there's essentially like 8 to 10 relays that are responsible for 95% of Ethereum blocks and 8 to 10 builders that are responsible for producing those blocks.

That has some definite risks in terms of, those are the, the builders especially are the ones in a position to like capitalize most from the PBS market.

They can continue to like make the most money.

The relays are in this weird position where they're kind of a public good, but still the fact that there's so few of them controlling such a huge part of the market is kind of anti the ethos, I guess, generally.

And 1 way this actually manifests, not from a economic perspective, but more from just a fragility perspective, has showed up in a few different issues around relay operators and their relationship with consensus clients.

So immediately after the Chappella fork, there was a bug in the relationship with how Prism interacted with MepBoost.

And that resulted in huge network instability immediately post the hard fork.

It took a few epochs for the chain to finalize, there was a lot of missed slots, it was full-blown firefighting mode.

And that comes from the fact that there's these 10 relays and all of the software that is running on the validator machines is decoupled from this MevBoost external software.

So there is like consensus stability implications around the centralization found in particular in out-of-protocol PBS systems.

I would add to that there is the overall technical complexity of enshrined PBS.

The merge is now basically just a year ago and the whole year we've been like thinking about moving PBS more in protocol, how to get rid and move beyond the relays as trust detectors.

And it's super hard challenges where you may need a lot of additional responsibilities.

You may need to increase the consensus protocol complexity, which is already pretty hard to reason about.

And it could introduce new nuanced reorg risks or vulnerabilities.

And this is just the thing that is very hard, a very hard problem to get right.

So I would say there is a lot of overall technical risk to on the path to improtocol PVS.

Yeah, I mean, I have like a bit more kind of arcane point, but I mean, clearly we are seeing that proposal builder separation can exist outside the protocol.

And that's where it does so far, most of the time.

And not all of this stuff is actually maintained by Ethereum core developers.

And so I guess as someone who's working for the Ethereum Foundation, Mike, what do you think this does to kind of the power dynamics in like the Ethereum ecosystem?

Is it on the 1 hand more that like, we have to change the definition of what it means to be a core developer?

Or is it that, you know, Ethereum should eventually like try to pull everything into the protocol, like what do you think it does to the invisible kind of power in the ecosystem?

Yeah, I would say Barnaby has a really nice post on this, we keep calling him out, but he has a post called Seeing Like a Protocol and he defines kind of what it could look like to enshrine different things and when to draw the line and say, okay, this is out of protocol versus in protocol.

And I think part of ePBS and the work that I've been focusing on is kind of figuring out not only what to enshrine, like what design works for ePBS, whatever, technically speaking, but also on a more meta level, should we actually do the enshrinement?

And 1 of our recent pieces that we wrote with us 4, actually, and a few others, was kind of talking about the role of PBS and enshrined PBS in the world in which a relay market exists outside of the protocol still.

So we'll probably touch on that later, but I guess in the current meta where MevBoost essentially is core protocol software, I think there's a bit of an ownership mismatch.

You know, like the Flashbots org wrote this code and it's been like working really well for the year that's been running post-merge.

But I think everyone would agree that the testing and tooling and specification around that code is not at the same level of the core consensus clients.

And part of that is because it's sort of a public good, but it's also, you know, originally written by Flashbots.

So I'm not sure exactly how the ownership should evolve and the politics there.

See all Uncommon Core 2.0 transcripts on Youtube

An Incomplete Guide to PBS - with Mike Neuder and Chris Hager