Panelists
Mike Neuder - Ethereum Foundation (𝕏: @mikeneuder)
Alex Stokes - Ethereum Foundation (𝕏: @ralexstokes)
Sam Hart - Skip (𝕏: @hxrts)
Terence - Offchain Labs (𝕏: @terencechain)
Alex Watts - Fastlane Labs (𝕏: @ThogardPvP)

Moderator
Stephane Gosselin - Frontier Research (𝕏: @thegostep)

Okay, so I'm super excited about this panel.

about a year and a half of my life looking at it and trying to make it become a reality, It's sort of blown into something that was much bigger than I could have expected.

And now I'm lucky enough that we have some of the people that are working on sort of carrying it forward and bringing it to this next stage.

I will do a similar thing that we did in the previous panel.

I do want to have a lot of participation.

I think this is going to be sort of a forward-looking chat.

I've made sure that on this panel we have sort of representation not just from the Ethereum ecosystem, but also alternative approaches to how to handle MEV at the protocol layer, as well as in other ecosystems where the trade-offs that people are making in the designing of these systems is slightly different.

So I think a lot of the conversation will be focused on trade-offs and focused on what are the properties that we're trying to guarantee in the systems that we design, and how do we make sure that those properties are good for the users that we're designing them for.

So unlike the previous panel, I think it would be quite interesting to hear a TLDR on sort of your current role in the ecosystem, the part of protocol level MEV development that you're focused on, and then how it contrasts maybe in terms of the priorities that you have when you think about designing designing these systems Mike do I get us started sure?

Yeah, I'm Mike if I haven't met you guys working on Thinking about EPBS in terms of how we can bring it into the Ethereum consensus layer so I guess some of the main properties were paying attention to are giving guarantees to proposers that the block they commit to if they haven't seen it in time, is valid.

And they'll get paid for the right to produce that block, even if they aren't in control of the block contents necessarily.

We're thinking a lot about how we can give guarantees to the builder.

I think the low-carb Crusader kind of whole saga showed us how important builder privacy is in some contexts and making sure that they're not incentivized to go outside of the protocol to do something that gives them better guarantees.

And also caring a lot about censorship resistance, thinking a lot about how we can get strong guarantees about transactions getting included, even if the validators themselves aren't the ones building the blocks.

And basically, I'm just trying to make sure that all of you don't destroy Ethereum.

The short-term incentives are to just extract as much as you can from the system, but if we all do that at the same time, then it looks like we just have the 1 supernode that we're all battling, and now it's just a tradified stock exchange.

We lose all the nice properties that Mike was just talking about that make Ethereum really special.

And obviously by extension, like these ecosystems that we have represented today.

Like, you know, probably what you'll take away from this is just like seeing all these different perspectives and the fact that like, there's no like perfect or like, you know, ideal solution here, especially, you know, throwing back to Steph's talk a minute ago.

And again, a lot of people in this room are working towards adding to that picture.

And so you have this very rich diversity, which is really exciting, ton of innovation, stuff like that.

But then, yeah, we just have to make sure that we can keep playing the game rather than just play a few more rounds of it.

Although Prior to working at Skip, I worked at the Interchain Foundation, which is kind of Cosmos focused.

And I did kind of product development for the whole Cosmos stack.

So Tenement, Cosmos SDK, IBC, et cetera, et cetera, et cetera.

And more and more, we're developing UX solutions for users.

And I still am working on quite a bit of infrastructure throughout the stack.

So I think I'm on this panel to kind of represent the non-PBS view.

I mean, it's going to be very interesting talking with everybody else here.

But Cosmos just comes from a very different place and has different assumptions and is trying to optimize for different things.

with- How would you describe those things?

So maybe in contrast to how things are done on Ethereum, what are the trade-offs that you guys lean more towards on the solutions that you build?

Well, I guess to your point in your previous talk, the place that Cosmos starts from is that these systems are going to be inherently political.

And they're going to be kind of divided into very different application functions, user preferences.

That kind of natural sharding is going to occur.

So that means that the application is going to be able to express preferences over the application design all the way through the MEV supply chain.

And really, the thing that we should be, unlike the Ethereum Foundation, we are less concerned with a single chain going down.

That's actually, you know, there are kind of replaceable parts in the system.

And we're designing for kind of like aggregate robustness rather than any single chain.

So yeah, that communication standard's super important.

And actually just listing to user preferences, application preferences to understand what their needs are.

So like Mike and Alex said, so I turned their wonderful research idea into code.

So around like, so which typically means that if something goes wrong, like people will knock on our door first, and then we're the 1 that gets yelled at.

So in terms of EPBS, I'm mostly looking at what Mike and Alex are looking at, basically.

And we deal with a lot of users, a lot of stakers.

About, I think, 35% of the stake is running through Prism right now.

And so about 35% of the block is proposed through Prism.

So from our end, we look at, for example, at Reorg, right?

We want to make sure there's not enough reward.

We want to make sure that every block is successful.

That's why ePBS is very important to me, because I think that's basically the next step to better chain security.

Curious, do you have a lens on the Arbitrum block space preference?

I'm kind of in this weird position that I work on layer 1, but I also know a little bit of layer 2, because of option labs pay for my salary as well.

Let me know what I should be worrying about.

From my end, I'm mostly commenting on layer 1.

But I'm happy to answer layer 2 questions.

My name is Alex, and I am with Fastlane Labs.

We are a MEV protocol that focuses on Polygon.

Our focus is primarily on building smart contracts that are aware of the infrastructure, an infrastructure that is aware of the smart contracts.

And by combining those 2 and having them interact in an interesting way, we've been able to pull off a few things that we're very proud of.

On Polygon, we've built a MEV system that is, users just don't get sandwiched.

We've been able to really build a system that's robust, that helps users, and that at this point right now, if you're looking at the layer ones, polygon of the EVM ones is going to give you the best execution, because it's going to be the 1 where you're least likely to get sandwiched.

We also have the unique distinction, if I may brag a little bit.

I believe, and I could be wrong, and I think Skip, you guys are like this too, We could turn off our relay and our protocol would continue to still work.

And I think we're also very proud of that.

We've designed a system where through the smart contracts we've been able to make it so that there's not a reliance.

Like we get benefit out of some centralized infrastructure like a lot of the other systems, because it does help things speed up a little bit.

But we could still function even if we turn it off.

But there are some trade-offs, to your point.

Like, yeah, it's decentralized in the sandwiches, never lands on infrastructure.

But there's a massive trade-off that we make.

And that's based on something that's unique to Polygon, which is the amazing social there.

What we've found is that validators on Polygon will not run sandwich bots.

There's not a single 1 of them running a sandwich bot.

And because of that, we're able to build a system that assumes and that trusts that validators won't run sandwich bots.

Now, if 1 of them ever turns 1 on, that might change things for us, because then we would have to start worrying about the fact that that validator might be accumulating stake faster than the others.

And that might, over time, trend towards centralization, which is a serious problem.

I think the EF guys would probably be more suited to answer that question than I.

But what we found is that Polygon is a proof of stake network and It's been proof of stake for a long time.

The validators have been going out, raising stake, predominantly from institutional investors for a long time.

And because of that, there is a strong sense of social responsibility.

If a validator starts running their own sandwich pot, you can look up all of the major validator operations on LinkedIn.

You can email your senator about, hey, there's this guy who's stealing money from us.

There's a sense of accountability that is Really a result of the way that the polygon validator set was set up.

That is not necessarily the case for a theory That's actually like definitely not the case for aetherium where there is a permission list validator set But that being said we're very happy happy of like what we've been able to accomplish in the environment where our trade-off prioritization is different.

Maybe 1 question here is, on the 1 hand, you say, okay, you can just message all the validators on LinkedIn.

You're like, wow, this is the most centralized thing in the world.

I can just get everyone into a room and make decisions about protocol changes whenever I want.

There's sort of this assumption that Ethereum works differently, that Ethereum doesn't have sort of this set of like, you know, operators that control a vast majority of the network.

But my understanding is there are still very few staking operators and node operators on Ethereum today.

And the proportion of solo stakers is well below 10%, if not below

Is that the correct understanding of how the distribution works?

What I would say is that on Polygon, the stake is, to use another term, it's relatively sticky.

Like once you stake with a validator, you tend to stay with them.

So if 1 validator starts having slightly higher yield than another, the sense that an institutional investor would do an entire set of due diligence, bring in their legal team, and go through that process again, it's an extremely high friction.

Validators are retailers of trust, and that trust is negotiated through sort of contracts and long-term agreements.

And so whether you're on Polygon or on Ethereum, that looks very similar.

I want to agree with you, but I feel like I might aggro a lot of the Ethereum people.

But yeah, I'm not entirely convinced that Ethereum validators would necessarily sandwich.

I mean, we've found that on Polygon they don't.

And it would be amazing if Ethereum is the same way.

Because right now, if I'm being honest, Ethereum is the worst chain for users.

It's the only chain where validators are strongly incentivized, and perhaps even will be forced to be maximally extractive for users.

A lot of the other chains have focused on avoiding that.

And I think 1 of the 1 downsides of PBS is that, while, yes, it does really help decentralization, it also enshrines this terrible user experience.

And the only way around that terrible user experience at present is to rely on like centralized third-party off-chain infrastructure to have privacy through your transactions and if you're correct about what you're saying about Ethereum validators I think that would be amazing because I think that would solve a lot of issues.

So I don't necessarily know that the answer is just to ask all the validators, not the sandwich.

But I think there are some like intermediary solutions that are going to help provide sort of better guarantees.

I'm sort of curious from the guys working at the EF, what do you sort of see coming around the curve in the next 6 months to a year in terms of protocol changes at the MEV-boost sort of PBS level?

What are the main areas that need to be improved upon?

Big thing people talk about is censorship resistance.

So that became quite a hot topic around the merge with various sanctions and whatnot.

And I think everyone agrees is a sort of soft spot of the protocol today.

So to the extent that we can improve that over the next 6 or 12 months, like you said, that would be great.

It's kind of this thing where it's like, we were talking about this last night, like, MevBoost works just barely.

Like, it's good, and it works enough for now.

And then if anything, it kind of buys us time to focus on ePBS solutions that might resolve a lot of the downsides that we see with Medboost today.

That's really the bar that I try to hit whenever I design anything.

Just good enough to be passable and allow people to focus on everything.

Because you could imagine we put a bunch of resources into making that boost and the off-chain PBS really good.

And we could, but we could almost get to a point where it's so good we don't even need EPBS.

Like before the merge, I spent like a couple months trying to convince the EF that they should like delay the merge and go straight to like, and try and PBS, and that like doing MevBoost was just a terrible idea.

No 1 wanted to do it and so everyone was like, no, we want the merge, it's gonna be the next upgrade, we're not delaying this and so MevBoost was designed exactly for that, it's like an intermediate solution that is sort of good enough to keep us going.

I think the insane thing about it is without that 1 decision having been made, you wouldn't have all the block builders that are in the room today.

I think we'll have in the next panel a block builder panel.

They just wouldn't be you know, we wouldn't have as much transparency into the system, right?

So that's the thing where it's like good to have that boost like it gives us like again Like insight into what's happening some and you know to the extent that exist It doesn't form a lot of experiments around Or like the ways we think about EPBS.

Just having all this data from like relays and things.

So like it's good and Yeah, it's good enough right now.

Yeah, so I was like I'm personally As much as like I don't like MDE-Boost.

I thought it was a very required step in the middle, because without it, we wouldn't understand all these different type of attacks that has happened in the few months.

If we just go straight into InShine PBS, I think that would have been a bigger problem.

That we would have to do some crazy hard work in the middle.

So yeah, personally I'm very grateful of MadBooz and because it basically allows us to learn so much.

Yeah, I also wanted to add, you asked about what's coming down the pipeline in the next few months.

1 thing that I've been working a lot on and thinking a lot about is, as we do this blue sky research around and try and PBS and think about the top down approach of really fixing this at the protocol layer.

We also have the advantage of having the relays already running.

And we have kind of this whole ecosystem in place.

So we've been working on this thing called optimistic relaying, where we can kind of mold the behavior of the relays to look, to kind of both de-risk some of the EPBS design aspects, but also to make the relays perhaps more sustainable and just better at servicing the builders and the validators.

So, I guess the overall theme of the optimistic relay roadmap is to remove some of the roles from the relay and replace those roles with, like, a collateral that kind of enforces the builder behavior at the relay level.

So I think in the short term, that's the easiest path to both making relays more sustainable and de-risking some of the ePBS stuff.

But longer term, I still hope that we go the ePBS route, but I'm biased.

So there's a few other like approaches to designing systems aside from PBS, right?

Like there's a Pepsi that's sort of discussed quite a bit, And then there's also slot auctions that are sort of another design category.

I'd love to hear a bit of a discussion or debate around these different approaches and which ones are the ones that are worth exploring more than others.

1 thing I would say about the slot versus block auctions, Most of the EPBS designs we've been kind of toying around with would probably work with both.

So, this payload timeliness committee thing which we published recently, like, it's not necessarily binding the, we don't necessarily need to bind the builder to a specific block, we could bind them to a specific slot and have that design space open up.

So I guess I don't see it so much as an either or.

But I'll have Barnaby talk about Pepsi a little bit.

Yeah, so I've been probably doing the most work studying PBS at the EF because I've had some concerns, notably around the questions that are discussed now, like this idea of enshrining the market structure of having proposals and builders.

I thought the whole block auction was too coarse and we have results from Quintus, from the special mechanisms groups guys who tell us that it might be the case.

And So while I was thinking about it, actually funny story, I read this Atom 2.0 paper that Sam was the lead of on.

It kind of blew open my mind that there was a lot of things, a lot of like a much bigger design space than I thought to design this mechanism.

And yeah, coming from this discussion, there was this idea of Pepsi, which is enshrining this idea that validators can enter into commitments, but not enshrining the specific shape of these commitments, or not enshrining that It has to be the whole block, it has to be the way that the Ethereum protocol dictates it.

You can enter into any kind of contract that you want.

It's a much more opinionated version of the market, let's say.

But I feel Cosmos is heading towards and with this idea of, yeah, it's more adaptable, like you can really have these activist solutions of designing yourself what your chain looks like.

I don't know that it's fitting for Ethereum, but it really came from this place of saying, yeah, maybe the shape of Pepsi is just too coarse, and we need something that's a little more flexible.

There are some, there is a latent structure to Ethereum block space that's starting to form.

So the CR effort is in some ways a kind of modification or like retraction of part of PBS and then the The whole kind of roll up repricing is another kind of acknowledgement that okay We're we have this class of transactions and and we want them to behave in a certain way.

So If you were to go down a Pepsi route, you might just say the block space is going to be reserved or delineated in a specific way instead of doing everything via market pricing.

And I'm not an Ethereum person, so I have no opinion about whether that's good or bad, but just kind of hypothetically, that's what might happen.

If I'm being honest, When I hear Pepsi, I just think of the drink.

Just for the people who might not be on Ethereum all the time, what does Pepsi stand for?

It's a way to, yeah, I mean, it is what it says it is, but it's basically a way to kind of resegment block space, and that's done on the validator level.

I guess from my end, I'm mostly looking at implementation.

So for me, I want something that's implementable, shippable within the next few months.

Just like I'm personally looking at the mainnet, and then I see very slow block.

I get really worried, and it's going to get worse with more validators in the queue.

And for short term, it's definitely ePBS.

don't know the design mechanism, but do you guys have sort of an outlook on whether Stefan's more complex picture becomes simpler with ePBS or becomes even more interconnected with more actors?

Just like abstractly, like a good ePBS will probably like not touch most of those things.

Like, it will just actually have the 1 abstraction.

And I would kind of consider it to be a worse PPS, I suppose, if it touches more stuff, if that makes sense.

But I mean, in sort of the same breath, it's like ePBS, whatever that looks like, should take this reality into account.

The picture we saw is happening, and it will only get more elaborate.

And anything that we put in the protocol, And this is part of why we are so careful with shipping something that's actually enshrined.

It could be the case that we just copy-paste my boost, and then 6 months from now, everyone's trying to sell gas futures, and no 1 wants what we have.

So it's something you have to do very carefully.

In general, when you enshrine something, people can depend on it and build businesses on it, build additional layers.

So I would presume it could catalyze some increase in complexity there.

I would also say, if anything, I feel like Steph's picture kind of implies Pepsi's solution might be better, because proposers could commit to much more flexible things than necessarily just a full block or even a full slot.

I kind of like to think of Pepsi as sort of an enshrined eigenlayer.

So they could commit to only including a price if an Oracle has some value less than

And that sounds kind of like more like the intent structure than the actual like full transaction structure.

So I think if we need that level of flexibility at the protocol level, then Pepsi might be the right way.

That being said, I also like thinking of ePBS as kind of trying to firewall off most of the complexity from the protocol.

We mostly care about stability, liveness, safety of the L1.

And to the extent that we can kind of firewall off the complexity of solvers, builders, searchers, and all their interactions, and just have kind of the simplest way to get all of that on chain, like a dumb pipe, essentially.

Is it still the plan to have validators be able to add a couple of transactions at the end of the block?

That's my understanding of the censorship-resistance solution, which is a form of Pepsi in a way.

Yeah, so I guess the design space isn't either ePBS or Pepsi, right?

Like the kind of inclusion list idea is a specific case of the constraining of the builder's actions in some way.

So you can specify something about your block or about the next proposer's block that the builder who builds that block has to conform to.

In the inclusion list world, that's enforced at the testing committee versus Pepsi, it would be kind of enforced at the validation, like the block validation level.

But that feels more like an implementation detail.

I know you tried to duck your representation of Arbitrum in your introduction.

But yeah, I mean, 1 of the things that have been discussed is, OK, what are Layer 2s going to do with sequencing?

Is PBS model some way that Layer 2s can achieve some level of sequencer decentralization?

What do you think the future holds there, both maybe from the arbitrary perspective or more from roll-ups generally?

See all Frontier Research transcripts on Youtube

MEVday Paris: PBS and Beyond