See all Bell Curve transcripts on Youtube

All right, everyone. Welcome back to another episode of bell curve. Before we jump in quick disclaimer, the views expressed by my co-hosts today are their personal views, and they do not represent the views of any organization with which the co-hosts are associated with nothing in the episode is construed or relied upon as financial, technical, tax, legal, or other advice. You know the deal. Now let's jump into the episode.

Hey everyone. Before we get into it today, just want to give a quick shout out to this season's sponsor, Rook. Close to a billion dollars worth of MEV has been taken out of users' pockets, and that's just on Ethereum, and that number is only getting larger, unfortunately. Rook thinks that it's time for a change, and they've built a solution which is going to automatically redirect that MEV back to where it belongs into your, the user's pocket. So you're going to be hearing all about them later in the show.

I'm huge fan of this team and what they're building. So stay tuned to find out. All right, everyone. Welcome back to another episode of bell curve. This is a little bit of bonus content from the MEV season today.

I'm joined by Stefan Gosselin. Today, he is the founder of Frontier Research, which is putting out some of the best research in MEV. In a past life, he was a founder at Flashbots and the chief architect over there. You might know him as the Ghoststep on Twitter. I think that might be the best intro I've ever done.

So, Stefan, welcome. Welcome to the show, man.

That was amazing. Wow. Can you do my intro all the time?

Yeah, absolutely. Just buzz me in. I'm happy to.

Maybe I'll save the silent clip and just send it to people.

I think that's a good idea. This will be a little side hustle for myself going forward. But we've got a lot of ground to cover today. I want to give you a little shout out here. Frontier puts out, far and away, the best content in terms of MEV.

Whenever a new piece drops, all of our analysts are always talking about it. It sets off some lively debate for at least a week. And I kind of want to use this as a chance to kind of go through some of the topics that you've outlined. So maybe we can kind of start at a high level and talk about the transaction supply chain of MEV and just how it stands today, how it's changed over the past year since you were at Flashbots and wherever you want to take it.

All right. Yeah, let's do it. Well, first of all, thank you so much for having me on. I haven't done really media since I left Flashbots, and so I'm excited to sort of get back into the open and start talking about these ideas that I enjoy talking about a lot. So the MEV supply chain or the transaction supply chain, I published initially this post, it was in April of last year, around the time of the DevConnect conference in Amsterdam.

We hosted, or I should say, Flashbots hosted a conference there called Mev Day. And I sort of opened the conference with a presentation that was titled, you know, MEV Utopia or Dystopia? What is the future of this industry? And in this presentation, I outlined sort of these new sets of roles that I think are becoming very common in the vocabulary and the language that people use in blockchain protocols now, and especially on Ethereum, by the time warrants, you know, very popular at all. So the MED supply chain, I think a lot of people recognize now is there's users, they have intents, they communicate those intents to wallets or applications.

Those help them put them into transactions. Those transactions are put into some kind of transaction system, whether it's an order flow auction, a transaction pool. Searchers see these transactions and they augment them with their own transactions. Those make their way to block builders or sequencers, those put them into blocks and then propose them to the validators and to the consensus of the system on which they operate. So the last year, since I sort of published this article, I mean, we've seen a lot of excitement and innovation happen at every layer of the supply chain, which was really the goal of framing sort of blockchains in this way.

I think for me, it's also been sort of a personal journey, like going from trying to sort of define the way that these systems work in a fairly simple and linear way. And 1 of the things that I had in there was the question of how will value flow? Is the value going to flow sort of towards the inside, so towards the searchers and the block builders, and they'll sort of aggregate a lot of the value? Or is the value going to sort of flow towards the outsides, towards users and validators? I think for me, what I've sort of come to realize is that that was actually the wrong framing of the question.

Like this question of the MEV supply chain, how is value going to be redistributed amongst the supply chain? Is it going to tend towards utopia or dystopia? Was really sort of the wrong framing. And the correct 1 is actually like, what can we create using sort of this model of the industry, what is the additional value that this allows us to generate? And so it's sort of reframing it from a wealth redistribution, which is sort of more 0 sum.

And I would associate more with a lot of the questions that we have around MEV, to 1 of wealth creation, which is actually like, how do we deliver systems that are better for users, that allow us to generate sort of genuine value for the technology that is cryptocurrencies. And I would sort of frame that 1 more as transaction supply chains. So how are we sort of enabling these systems to settle the kinds of user activity that is most beneficial. So that's sort of my introduction of my journey and exploration of the supply chain over the last year. I'd love to sort of dive into any of the components of it and see sort of where has the energy been and where they're going.

Yeah, let's dive into that concept a little bit. The first thought that I had when I was hearing you describe that is sort of this trend in MEB of returning MEV to users, right? From the intents, which we'll get into, that they sort of create and preferences that they want to express onto a chain. Right now, the vast majority of that value flows all the way down the transaction supply chain to the validators. Right now, there's this big trend of returning that to users.

Is that kind of what you're talking about? Or expand on that concept a little bit of moving away from sort of this allocation mechanism to a wealth creation mechanism.

Yeah, Exactly. So there's sort of some very simple mechanisms that we can think about that like manipulate this value distribution, right? Like, oh, we're going to add in an order flow auction, which allows us to sort of claw back a lot of the fees that are being paid through transactions to validators and instead, like, send them back towards the user. So, you know, there's this whole area of research and I published an article about it, you know, the design of order flow auctions, how do you design them in a way that's incentive compatible and sort of helps return value to the users. I think the other place where a lot of this discussion is happening is for like Uniswap LPs, right?

Or, you know, you could say Dex design as a whole. How do we design better decentralized exchanges that don't leak as much value, either from users swapping and being targets of information leakage through sort of sandwich attack, or LPs being vulnerable to sort of slow price updates and uninformed liquidity provision, which leads to LVR and sort of large arbitrage opportunities between between the decentralized exchanges and centralized exchanges. And a lot of the conversation there again is how do we redistribute the value away from these arbitrage players who are bidding a lot on gas to be able to pay for the block space and more towards these liquidity providers. Maybe like a final 1 is the recent conversations around MEV burn, right? How do we sort of redistribute value away from these like large spikes that are sort of random to individual validators and more towards the network and sort of spread out the amount of that value.

I think a lot of these conversations completely miss the point that we're trying to solve with all of these blockchains. We're trying to create systems not just that move money around between different actors, but rather are genuinely more useful and are going to be able to attract sort of the next billion users. And developing mechanisms that allow for those better user experiences isn't just about redistribution, it's much more about expressibility and like, what can you actually do with this infrastructure? And I really think that's where the limitations of our space is more so than any sort of, you know, protection or extraction or any other framing of it.

So can we, I would love to get your opinion, you know, on each of those things that you just mentioned, sort of in reverse order, love to just get your thoughts on MEB burn and you know, that sort of dichotomy between different stakeholders.

The way that I think of MevBurn and sort of value that it brings, well, I think it fits within like a fairly complicated question, which is like, what is the future of proposal builder separation on Ethereum? What is the future of roll up adoption and sort of MEV activity on layer 1 versus layer 2? MEV burn is kind of I think a desirable property when you have a system like we have today where all the activities on layer 1, all the economic activity is on layer 1, there's a significant amount of arbitrage and like sandwiching activity that is highly contested. So you have high contention rates, or you could call it contention rates between, at every block for having sort of a specific state update. And what that causes is basically all of those opportunities are being paid out to the validator through block builders and MEV boost.

That's somewhat destabilizing to the consensus of the chain and also centralizing to the sort of distribution of the nodes. The reasons are that you have a strong incentive to pool your stake to be able to have the yield that comes from all this MEV activity that is highly variable. So my chance of getting a hundred ETH block as a validator is very small because those don't come very often but I can have the same expected value if I join a validator pool that's able to spread it out. Exactly the same economics that we've seen on Proof-of-Work Ethereum and are sort of playing out here as well. Burning in this case sort of creates less of an incentive to join into larger pools because there isn't sort of this high variance value that you're missing out on as a solo staker.

It also means that, you know, now this MEV value is getting burned, which is, you know, great for, for, for ETH stakers. There's some, I should say ETH holders. There's some economics here that's sort of above my head and like understanding. I'm not going to, I'm not going to LARP as like knowing what the economics of Ethereum are. But anyways, that's the argument as I understand it.

There's a great, if you want to really nerd out on this and get super in the weeds on it, Justin Drake gave a good talk on this on Mevcanomics, which you can just look up on YouTube and sort of get his take on it. I also want to get your, before we move sort of up the stack, you mentioned sort of the future of rollups on Ethereum and how Mev's going to look up there. I want to get into that with you. But before we do, I want to talk about, because yeah, you've written about sort of DEX microstructure, you've talked about order flow auctions, and that's just pretty cool, interesting content. So maybe could you talk a little bit about sort of your thoughts on the evolution of DEX architecture, and maybe touch on, take something like Uni-V3 or something like that.

What are the sort of leakage points of MEV and how could we design DeXs in a way that will be better for users?

So This is an active area of research and exploration for us. I should say, I should give a shout out to my research collaborator here, Ankit, who's been doing a lot of the research on this particular vertical as well. He sort of helped classify a framing of MEV, which is called EV ordering and EV signal. And it tries to sort of provide the basis for analyzing how a lot of these MEV opportunities are being targeted in various different mechanisms. And so it's quite a useful framework for doing this kind of analysis.

Now, in the case of Uniswap, the way that we would think about this and the value leakage is, let's say you have a user that sends a transaction through the transaction pool, through the mempool, and they have sort of a slippage tolerance that allows them to get sandwiched. Well, EV ordering says, you know, any bot operator, any searcher can basically take the transaction, sandwich it, and extract some value internal only to the system that is Uniswap. Another example of this would be sort of doing arbitrage between Uniswap and some other exchange on-chain. So that's certainly 1 piece of the puzzle and where sort of the value comes from. There's a second piece of the puzzle, which is defined as EV signal, which is actually the value that comes from this activity happening on within the environment of Ethereum, but also taking into consideration the sort of external state to Ethereum and its mempool.

This looks at other transaction. It looks at the state of other chains. It looks at the state of centralized exchanges like finance. And so here you have a much more rich sort of field where you have arbitrage between these chains, you have arbitrage between the centralized exchanges and the decentralized exchange, and you can also measure as part of this sort of arbitrage between the LPs of Uniswap and Binance, which is the second biggest source of leakage for the protocol. It's what's sort of described when people talk about loss versus rebalancing.

It's the same sort of value that's being exploited here. So to your question about how do we do better than Uniswap v3, well to do better we need to solve those 2 things, those 2 leakage, the ordering that's based off the slippage and the leaked value through Signal. The design space for here is still being explored. I think 1 of the insights that's quite clear is that it's really difficult to have price discovery on a system that is not very fast and has high fees. And so we're sort of in this situation now where the price discovery for a lot of these assets is on Binance.

And this leaves all the LPs to be sort of targeted by toxic flow, basically arbitrage traders that are more informed and are able to get those price updates reflected on-chain. It's like, you could think of it as like a very inefficient decentralized oracle where you have a lot of LPs that just put money and like constantly get bad execution and offer this service of having a price on-chain to anyone else who wants to trade against it. There's been sort of a lot of innovation, a layer up the stack on like RFQ systems, right? So looking at, okay, well, clearly, the on-chain price isn't the best 1, right? It's a delayed price that can be up to 12 seconds stale depending on the situation.

Is there an opportunity to actually use this price as the best bid and offer, have it as sort of a backup price, but provide the opportunity for market makers to improve upon this price. And that's essentially how a lot of these aggregators work today, right? So they'll say, okay, well, we see that the current price of this swap on Uniswap is X, let's put it out there. And if anyone can provide a quote that sort of beats this execution, then we will settle with them and provide some level of price improvements to the users. And so moving up outside of sort of the chain execution into this environment has some benefits.

It does seem to provide better execution for users, but it also means that all this now it's sort of private market makers that have all of the liquidity and that's being kept off-chain as opposed to being placed on-chain. I think there's still a lot of innovation happening. The biggest question is, is it going to be sort of a decentralized exchange on layer 1 that's going to be the place where price discovery happens? Or is there some designs for exchanges on layer twos that will allow to actually have price discovery happen within the decentralized context and bring that liquidity back onto the chain and not necessarily have it out of the chain.

Yeah, I think it's all, you know, I think the point that you make about basically LPs overpaying the arbitrageurs is going to be a pretty interesting 1 in the coming years. In some sense, that's sort of a political argument as well. The other thing I would point listeners to as well is sort of FBA sort of designs for exchanges, like sort of the cow swaps of the world, where very similar to kind of an RFQ based system, There's sort of a baseline, right, of execution that traders are willing to pay. And then I forget, there's a, I think solvers is the word for this particular actor, but they sort of go out into the world and figure out a way if they can execute at a cheaper price and that surplus is actually measured for traders on the exchange. And that was we'll get into this later, but I think that's kind of 1 of the first experiments in terms of intents, you know, an exchange utilizing intents.

Yeah. I mean, there's there's so many interesting components that go into this. 1 of them is you don't necessarily need to only source liquidity from a single chain, right, once you have this. The intent is to source liquidity from everywhere. I think 1 parallel that's not explored enough is actually how frequent batch auctions at the transaction layer are fairly equivalent to payment forwarder flow systems.

They're doing very, very similar activity in terms of auctioning off the sort of ability to solve it or to settle a set of transactions, but it's looking at it from a different time perspective. And there's some sort of auction theory around this that means that you might actually have sort of more collusion in a system that does frequent batch auctions than a system that does payment for order flow. This is not by any means sort of a question that's fully settled. That's 1 of the questions that we look at when we analyze these systems.

Why is that, Stephan? Why does that maybe lead to collision?

So it all has to do with the type of mechanism that's used. So this is the same case for order flow auctions, that sort of auction off individual opportunities. You have, in the case of EV ordering or EV signal, a fixed amount of opportunity, but with some probabilistic payoff. So you're not actually sure if you're going to get the execution that you want. And so when you're providing a bid, you know that, okay, the max that you can make is x, but you have some risk factor on your execution.

And because it's a single winner auction, there's only the person that bids the most that actually gets settled. And they always end up like winning because they overpay for the opportunity that they have. The end results of this is that you have sort of an incentive for all the participants in this system to collude and underbid and say, like, we will all bid with like 20% discount to what like our real preferences as a way to make sure that we don't, you know, lose money. You know, 1 can argue it's not like a stable equilibrium and you'll have like bidders that overbid, but the thing is that those bidders will eventually run out of money. And so if you have infrastructure that you can run, and that your cost of capital is sort of within the range of your opportunity, the amount of opportunity that you capture, You can run sort of a discounted bidding profitably for a very long time.

Well, it will be interesting to explore, honestly. Very interested in the FBA sort of design space. And I think Calswap, which by the way stands for coincidence of wants, which I didn't understand, didn't know until recently. It's a funny little thing. We've also talked to Henry Devalens this season, and he is building Penumbra on Cosmos.

Similar FBA sort of design with privacy in mind first, which is super cool. I want to transition here to your thoughts on order flow auctions, because you put together a great piece sort of exploring the design space there. And you just started to say 1 of the highlighted 2 of the differences between payment for order flow and order flow auctions, which is sort of the time, the time component, and then basically the individual sort of transactions that's possible to do in an order flow auction. But maybe I'll just turn it over to you, Carte Blanche, here. And can you sort of explain what the design space looks like if you had to categorize the different types of order flow auctions and maybe highlight how it differs from payment for order flow?

Sure. I think, you know, the top line takeaway for that piece is a lot of these systems tried to solve 2 things at once. They tried to solve for price discovery and for settlement sort of together. And it sort of confuses 1 thing for the other. That ends up being expressed in like a lot of challenges and how these auctions are constructed around trading off value, like basically best price, you know, return for the user, best price, best execution for user and reliable inclusion.

And so based off of this insight, I sort of propose that there's actually 4 different types of OFA designs. And they can be sort of put on a 4x4 grid between if they're application specific, so only for sort of a swap use case or generic for any transaction. And if they settle based off of individual transactions or based off of a group of transactions. And we can put basically all the different designs of order flow auctions, whether it's an RFQ, sort of a cow swap, a PFOF model, a sort of a MEV blocker style system, or more of a MEV share type system inside of this, you know, 2x2 grid. Each of them have their trade-offs, each of them optimized for something slightly different.

And I think crucially, I don't necessarily think that any of them solve the problem that like users actually want to have solved, which is like, you know, being able to trade in a venue that, that is, they're gonna like high confidence is going to give them a good price and timely execution.

It's definitely an interesting debate. I would actually be that that 2 by 2 matrix is, I think, a really good way of thinking about it. I'd be curious just because if you have thoughts between sort of generalized order flow auctions versus maybe more specific, like maybe in the future, like Dapp run order flow auctions. If you imagine something like a Uniswap trying to run their own order flow auction, you can certainly see the incentives for them to do something like that. And I would just be sort of curious how you would assess sort of the pros and cons of those 2 different approaches.

I am a strong believer in application specific order flow auctions. I think that's likely the way that you optimize for user experience. I think there's like some arguments you can make that you can have like a specialized order flow auction built on top of a generalized 1, but I don't see a way to really do this that doesn't introduce a lot of trade-offs. And so My intuition says that certainly the ultimate best user experience for users who want to do the use case of swapping or providing liquidity trading in some kind of way, which is 1 of the few proven use cases, I guess, of Ethereum today, those will end up in a specialized order flow auction model. I guess a separate question is like, is there still demand and, you know, value added to long tail order flow auctions or generalized order flow auctions, maybe.

But I see them more as block space aggregation platforms and sort of discovery of contention on state access, then I see them about returning value to the users or providing better price. So I wouldn't see in those system, it to be very successful to build an order flow auction that returns value to users. I do think that it's likely that those systems are more used to minimize the block space fees paid by individuals trying to interact with the chain.

So speaking of fees, I would love to kind of get your thoughts on sort of moving up the stack, you know, to the rollup layer and how MEV works there today. You know, I'd be, I'd be curious right now, obviously not a secret, right? That the, all the rollups use 1 centralized sequencer, which has big implications for MEV. And a lot of these rollups today sort of view MEV as a source of revenue, right, for their rollup. Obviously, this isn't sustainable.

You know, Hasu's argued for something like PBS that exists on Ethereum main chain today in sort of the form of MEV boost. Eventually it's going to be enshrined, but something like that needs to exist on sort of layer 2. I'd be curious just to get your sense of how you're thinking about rollups these days. And I would love to sort of get your kind of high level thoughts on how MEV is going to work up there.

You said every rollup except for 1 uses centralized sequencing?

No, no, no, all of them. I think all of them use centralized sequencers. Yeah.

Yeah. I'm still not convinced that that's a bad thing. I still, like, I don't think it's a done deal to say that actually first in first out sequencers on a layer 2 are a bad thing. The argument that we often hear when this is mentioned is well, then it creates a latency game and causes centralization around like a specific region. And therefore the rollup is susceptible to the censorship rules and regulatory rules of that, of the region in which the sequencer is deployed.

And I think that's true. But still, the question is like, is that actually bad? So let's explore this together. Because I think it's like a bit of a controversial or like,

it's a spicy take, my friend. I'm very curious to see where you go with this.

This is something I've been trying to disprove. So so you know, if people want to add me on Twitter and argue with it, I would love to. The statement goes like this. So if you have like a maximally decentralized layer 1, that probably means like a layer 1 on which there is very little economic activity, like it only settles, you know, data, and there isn't sort of contention rates, right, there isn't this sort of demand for settling with a, you know, on a specific position, you only have congestion rates. That's sort of how we, we, we, we, Ethereum has been designed.

When you start to think about economic activity, then you have all the issues that comes with MEV and the latency games that are sort of ensued. If you have an architecture where the layer 1 is only settling sort of data blobs, and there isn't contention, and you have all the activity inside of layer twos, it reduces the the centralization pressure on the layer 1 significantly. Now, okay, how is it any better for the layer twos to sort of become centralized? Well, if you have some way to have cross-chain messaging between these layer twos that is quote-unquote censorship resistant, right, You have some way to like push messages out from the layer 2 back into the layer 1 or maybe for it to be interpreted by some other spin-up of that layer 2 somewhere else. You might be able to, when I say like interpreted by another layer, layer 2 somewhere else, I mean like a fork of that layer 2, then you might be able to be completely okay with having a centralized rollup that's targeted by regulations.

Because it remains censorship resistant, it remains, you could say, non-custodial. There's still a way for individual participants in that roll-up to exit their state and bridge it over to some other roll-up in some other jurisdiction if there is enough demand to sort of bootstrap this other rollup.

It's an interesting premise. Let me see if I could poke at it a little bit and see what you think there. So I hear what you're saying in that if there was maybe some sort of a messaging system, be that like an IBC or shared sequencer or whatever. And there are sort of guarantees, right, that the state or the TVL or whatever that you end up blocking on this rollup won't be necessarily disturbed. That said, you know, if the some sort of state intervention basically shut down that centralized sequencer, it would certainly be a marked disruption, right?

And there would be like a period of time where we'd have to migrate the assets and everything down into main chain and like back up onto another rollup. I don't know how seamless you see that process being not tactical enough to have an opinion about it. But I would imagine it's relatively disruptive. I feel like if there's the threat of that hanging over these roll ups, then it will prevent, you know, TVL and activity from migrating up to the roll ups as much as they otherwise would, if there's always kind of that threat of reorganization hanging over them? How would you respond to that?

Yeah, I think that's a valid. That's a valid argument. I think the other argument is like, well, if you have some way for like state to be able to exit back to the layer 1. If that does happen, then you have a lot of contention on the layer 1, and so you have all the same centralization pressure on the layer 1, and so I don't think by any means it's perfectly solved. I do think like this does generate an argument for more fragmentation between layer twos, which I would like consider to be a good thing.

I think like if there's a layer 2 that has all of the state on it and there's like a single winner in like the layer 2 world, that seems really bad for innovation. It seems really bad for robustness of this system. Whereas if you have multiple different layer twos with liquidity fragmented across all of them, Yes, it does create some challenges on cross-chain messaging and creates maybe perhaps worse price execution and some framing of it through there being more arbitrage opportunities. But I would treat that as a separate concern than 1 of, okay, how do we have like a robust and scalable ecosystem around selling transactions?

Okay. It's actually a very interesting point. It makes me think of, you know, we're recording this on May 26. So Vitalik just came out with his piece, don't overload Ethereum's consensus. And he actually listed, you know, 1 of the explicit risks of relying on Ethereum social consensus on let's say, 1 of the layer twos becomes really large, don't count on the fact that if there's not some sort of catastrophic hack that we're going to roll back the chain, because then you get the sort of favoritism that you see in trad fi, right between say, like a large, you know, bulge bracket bank versus a small regional bank, and that doesn't seem necessarily fair.

So, and actually, I don't know if I have a good response to you, but I have to think about the fragmentation of the L2 ecosystem, because I had been kind of thinking about it within the context of the optimism super chain, right? And we'll figure communication out if that's IBC or shared sequencers, but I hadn't really thought about fragmentation actually being good for the robustness of the ecosystem. That's an interesting take.

I'll, uh, you know, I'll caveat all this by saying I'm by no means a layer 2 expert. Um, I think I know 1 thing or 2 about how Ethereum works by now, but layer 2, I haven't built 1. I haven't like worked with closely with the team, so I'm building 1. So I'm sure that there's a bunch of content there and ideas that I'm just not exposed to. But it seems to me like, and this goes maybe into a bigger perspective on decentralization that I've sort of grown over time, which is you want the decentralized system to be as simple and dumb and uncontroversial as possible.

And for those rules to be sort of not changing very much if you want the system to remain decentralized. The concern is any system that is complex and requires sort of global consensus is likely always to lead to centralization and capture. And this is not even just like an economic or like MEV argument, it's actually an argument on how humans coordinate and like politics, where anything that requires vast groups of people to agree to the same thing will devolve into political communication games. And that will inherently cause the system to concentrate and centralize. Whereas if you have a system that doesn't require people to all agree on the same thing all the time, then you have a lot more fragmentation and diversity and by by proxy decentralization.

Yeah. Last Last question that I have for you on the centralized secret service. So, what would you say, I mean, if you look at how it's sort of played out with Arbitrum so far, which has taken a very different approach from optimism in terms of their MEV strategy, although optimism has changed as well. But if you look at Arbitrum, which was a sort of fair, they were the fair ordering sort of group. They've already changed the way they're doing it a little bit because they have the same problem that Solana has with just spam.

So I'd be curious to get your takes on what you think about when you introduce something like FIFO or fair ordering or whatever it is, you end up getting a whole bunch of spam. Be curious what you think about that.

So the spam is a proxy for latency. So the question is not FIFO is the wrong approach. The question is more like, how do you handle the fact that there's latency advantages? Like the trad5 solution to this is like you sell colocation spots around, you know, your matching engine. And you have, you know, you can boot people off of their co-location spot.

And so therefore, you don't have the same sort of incentive to spam or for them to like try to DDoS you in some way or another. So I think that there's other approaches. If you're sort of committed to this idea that there's going to be a single roll-up and a single sequencer and that it's going to be first in first out, certainly there's a lot of established ways that you can make sure that this, you know, this server stays online. And you can deal with all of the sort of economic side of it in a much more centralized way. So it's, you just have to sort of commit to go down the centralization path.

If that's the, if that's the design that is being targeted. The alternative is to try to go down this sort of encryption path, right? Okay, I will continue to use a first-in-first-out system, but it's going to be encrypted and distributed across a bunch of different sequencers that are sort of all around the world. You still have latency game, they just become sort of at the edges of the encryption, right? So before the packet gets encrypted, who has access to that information?

How is this sort of generating value and who can sort of capture that value, and then afterwards where does the information becomes available first, and that's where you have again sort of the latency games emerge.

Yeah, interesting. Before we move away from layer twos, I would love to just sort of get your thoughts on, you know, a big topic du jour is sort of this idea of shared sequencers, you know, for a whole bunch of different reasons. Part of it is the communication issue that you were alluding to before. But the other sort of honeypot that this opens up is cross-domain MEV, which has been a very sexy topic for a long time, although it's sort of yet to be realized, aside from StataRb. So I'd be curious sort of what your thoughts are on is, eventually, do we end up getting into this very rich ecosystem of cross-domain MEV on the rollup space?

Or is that a little bit of a pipe dream for now?

So I still don't understand what is shared sequencing. Do you have like a quick explanation for me?

Sure. I can explain it to you like you're 5 because I'm also secretly 5. But basically the idea is like I think about the 3 different models, right, for how rollups can sequence their transactions. There's 1 centralized sequencer, which is super easy to understand. Then there would be a decentralized sequencer set.

So multiple different sets of sequencers that only settle transactions for or order transactions for 1 rollup. And then you can imagine a world where there's a set of sequencers that see a sequence transactions for multiple different rollups. And in theory there, you could guarantee something like atomic inclusion.

Okay. I think I see this very similarly. Maybe, maybe this is like the other, the other take that I'm going to have on this, which is, I think everyone is building the same thing. Um, and I don't know if like everyone

is building the same thing. I agree with that.

So, so whether we call it shared sequencing, decentralized block building, oracles, all of these, to me all have sort of the same flavor. They're all sort of trying to solve this problem that you have a lot of information, you have a lot of messages that are like floating around into the world, and then you have some consensus system that asks you, hey, can you find some like way to put all these messages together into like my next update? And everyone is kind of trying to figure out, okay, how do we represent all this information that's out into the world into some reductionist view of what the state of this rollup, this chain is. And we're creating all kinds of games around this, right? I sort of put this cryptic tweet out the other day that said, it's all messages and solutions, bro.

Just saying, okay, all of these things just end up being exactly the same thing. So shared sequencing, yes. I think that there's like value to be able to do things on multiple chains at once. There's sort of this concept that I've been trying to push since 2020 of chain abstraction. If we want the crypto ecosystem to become useful, if we want it to be used like AWS is used to be able to deploy application, not only users should not care about which chain that they're interacting with, but application developers should not even care about which chain that they're interacting with.

This is just what's required if we want to be able to enable the types of applications that are like actually useful. We need to create an ecosystem where it really doesn't matter. And at the end of the day, like, yes, you're going to have tradeoffs in these different execution environments, but it shouldn't be up to the developer to sort of know exactly how does an Ethereum transaction format work, does like the layer 2 have shared sequencer or not shared sequencer, They just want to be presented with a set of features or an interface that they're able to connect to and automatically deploy to these systems. I do think that these shared sequencers or decentralized block builders, cross-chain bridges, are all in the same game of trying to build and provide those services. They're trying to say, okay, we have a good view of what each of these different execution environments are good for, you know, storing data, maybe it's more decentralized, maybe it's good for storing value, maybe it's like lower latency.

And they're trying to provide these services to applications that are trying to build on top of these different systems and expose them in a way that's the most intuitive and, you know, provides the best guarantees. So I think whoever is gonna be able to provide these best sort of user guarantees is really what the shared sequencing should be all about. And the mechanisms behind it for actually settling it, I mean, there's so many different ways to build these things and that's not clear to me where it's going to go.

I completely agree with you on the point about abstracting away a lot of the complexity for developers. And maybe that's a decent segue into something that is a very sexy topic within MEV, which is account abstraction and how 4337 is going to impact MEV in general and sort of the creation of this new interop mempool. And that kind of, you know, that intersects with intense as well. There's a lot of questions about what is an intent, what is not an intent. So can you kind of just delve headfirst here into this whole thorny topic and sort of explain what 4337 is, who are the new actors that it sort of introduces, and how is this going to impact MBV?

The Intents language I think is a really interesting 1. I think it goes to the core of this question, which is like, we're not building systems that allow people to like update the state on a global computer, like we're not trying to provide these services, we're trying to fulfill user needs. And that's really how I started to use the language of intent and the concept of like trying to provide better services to users. I think it's being now used as a way to sort of escape from the limitations of the Ethereum transaction format, saying, okay, like, it's very rigid to be able to say that this intent has to be programmed as I'm interfacing with this function on this contract and it's like yielding X result when you have sort of a design space of interacting with multiple different chains. Unfortunately I don't think that account abstraction today is really nudging us that much in that direction of being able to achieve intents.

And so I sort of have this quote which is 4337 is the future, but not really. So 4337 is trying to develop this new mechanism that allows for account abstraction, that allows for signing basically call data and have that call data be routed through some distributed peer-to-peer mempool and be eventually included on chain. It introduces the concept of a user op, which is a new message format. Again, it's all messages, bro. It introduces a new entity, which is a bundler.

Again, it's all solutions, bro. It tries to say, okay, with this new message format and this new solver format, we're going to be able to enable sort of, you know, account abstraction and unlock some latent value and like build new kinds of applications. I think it's true, it's correct in the way that escaping from the current format of how Ethereum fees work and sort of the requirement to have ETH in your account when you're submitting a transaction to the chain is going to unlock a lot of value. I'm not convinced though that the standard itself, the 4337 standard, is going to be robust enough to be able to express all that intents have to offer. And I'll give a very simple example of this.

So 1 of the limitations of 4337 is that you have to be constrained in the state that you're simulating against. So there's sort of this attempt and this assumption that you want to create these messages in a way that is DOS resistant. And the only way to do this is to fix the state that you're going to be simulating the transactions against. So you're saying, here's a subset of the state on chain. This transaction is only valid if it only interfaces with this subset of the state.

And that's incredibly limiting from a perspective of expressing intents. Because my intent maybe isn't just about this limited state, maybe it's about some other contract that's like outside of this state that might change or maybe it's based off of the state of some layer 2 or some you know the state of Binance as a chain and none of those preferences can be expressed within a sort of

4337

user operation. So I think it's a step in the right direction. I think it's sort of, it's going to be adopted and I do expect sort of it to be the new way that users interface with Ethereum, but it's not going to be the future and it's gonna be superseded by some superior transaction formats.

The simplest way that I've heard how to describe intents is you're hard coding the output instead of hard coding the input. So, you know, what you just mentioned is like, we're not, 4337 doesn't perfectly allow that, right? But it definitely does solve some big problems, I think, that have been holding adoption back from Ethereum. So, 1, there is another entity that I think 437 introduces, which is a paymaster, right? And the 1 of the results of this new format of each wallet being a smart contract, well, instead of an end-owned account is that you can actually have another entity pay on your behalf.

So you can imagine a paymaster, a DAP acting as a paymaster to subsidize gas fees for users. So you don't have that weird problem when users first open their MetaMask that they can't do anything because they don't have any ETH in there, which is a very difficult onboarding problem for new users. The other question that I have for you on that is, what are the implications for MEV when you think about this? So Intents, it does something there, but not quite everything that we would want from Intents. But it does create kind of this, what's being dubbed as an alternative mempool.

And I would love to get your thoughts on who the bundlers of these user op transactions are ultimately going to be. Does this sort of, I guess, is that the IP builders or builder searchers? And does this sort of raise the, you know, now you've got the Ethereum public mempool, you've got the user op mempool, you maybe in the future have application specific, basically application specific mempools if they implement some sort of RFQ type system, just seems like now to be a successful builder searcher, you have to draw on all of these different sources of order flow, right, to build the most efficient blocks. So I guess my question to you here is like, what are the implications for MEV? And does this sort of raise the barrier to entry for builder searchers?

Does it raise the barriers to entry? I think 1 of the places where people go to when they hear this is Exclusive order flow is sort of a danger and I Used to believe so and then sort of stopped believing that that's the case and the reason is that I don't genuinely think that like block building is a profitable activity. And the argument is this way. So to be a block builder, you have to have some, you have to have 2 things, like 1, block space access, and then 2, enough trust to have order flow be sent to you. And the only way that you can sort of bootstrap this is if you make no profit and spend all of your profit subsidizing either the block space or the order flow that you receive.

And so block building I actually see as sort of a race to the bottom to maintain a certain position on the leaderboard to justify, hey, you can send your transaction flow to me and I'm like providing all these different features. I have to sort of be willing to pay for that transaction flow that's being sent. And so as soon as there is sort of a mechanism for block builders to be able to pay for various different types of transaction flows, they are going to be in a race to 0 to be able to sort of outbid other block builders for those transaction flows. And so under this framing, block building actually becomes much more of a public good, not dissimilarly to how relays on the MevBoost context are being operated today. There just isn't like a natural way for these systems, I think, to capture value.

And they will be sort of competing in this closed game for being able to access. Barriers to entry, I'm not sure. I think it may be that it creates some barriers to entry. There's some integration costs to be able to support all the different transaction types. This is like, maybe the barriers to entry here is actually that there isn't a good way to make a case that you can bootstrap like a new 1 of these things because it requires, you know, subsidizing And not everyone has infinite access to capital to be able to do this.

So I'm not sure where that piece of it is going to go.

Yeah, you might be absolutely right. I guess you sort of answered my next question, but maybe just to just to poke at the builder question 1 more time is There definitely have been, you know, builders that have made a lot of money, right, without naming any names, but sort of these, you know, shadowy, you know, not super public builder search firms that have done quite well in recent years. So is your contention there that basically those profits are going to get armed away as more builders come into the space. And yeah, it's sort of a race to 0 in the same way that transaction fees are a race to 0 in the brokerage world. Is that kind of the idea?

I don't think that trading activity is going to go away and like arbitrage opportunity. I think that's going to remain. I think the paradigm of. Like you have to be a builder to be able to like land your arbitrage transactions isn't a correct 1. Um, I think that, uh, actually neutral block builders are going to compete basically on merging systems and who can subsidize the most the order flow that they receive from searchers.

Yeah, and searchers will continue to sort of send to every block builder that they trust, so long as they can sort of believe that the block builder isn't also sort of using their flow and trading with it.

Super interesting. That just kind of clicked. Yeah, I do think that neutrality, that point just clicked. That's super interesting. I would love to, maybe we could, before I want to, you know, give you the chance to talk to the audience about, you know, sort of leaving flashbots and you know what you're doing at Frontier Research.

But before we go, maybe we could close on, you know, this idea of latency as, you know, just really getting into the weeds of MEV for these past couple of months, it seems like that's sort of the topic that folks are super interested in. And we kind of talk, I kind of think about latency now in terms of 2 buckets. There's sort of latency as a geographical centralization kind of risk for the health of the network. And we talked to that a little bit about, a bit about that on rollups. And you kind of have that contrasting against like a strong user preference for fast confirmations.

So That is kind of that bucket when you talk about latency. And then there's this idea of latency, you know, expanding time around, you know, the around the block. So you have more time as a right now, I guess, as a builder or searcher to get more transaction order flow, and therefore you can build more profitable blocks. And shout out to your team. You guys wrote a great post on optimistic relays, which I think you really got deep into the weeds of how this works today.

So I would just love to get your thoughts on latency, whether or not you view it as this sort of inevitable force that's going to shape the network in good or bad ways. If you want to get into the technicalities of how optimistic relays work and unconditional payments from builders, I think That's a good nerd snipe. I think we get that people would like to hear your thoughts on that. However you want to take it. Maybe we can just close on the subject of latency.

I sort of mentioned my thinking around the MEV supply chain and recalling it to transaction supply chain evolved. I think my thinking about latency also evolved. And the benefits and inevitability, wow that's a hard word to say, of latency in the systems that we design is sort of something that blockchain systems are going to struggle. I can take this from so many different directions. We can talk about sort of MevBoost and how it came to be and how optimistic relays are sort of inevitable as the next steps in the progression towards enshrined PBS.

We can also talk about how latency means that for as long as there's economic activity on the layer 1, even in an enshrined PBS context, there's going to be centralization pressures due to the latency. And we can also talk about how like in distributed systems that have global consensus, because of general relativity, it's inevitable that we have these latency games that sort of emerge when you have information propagation across the network.

All right, let's start with optimistic relays. Let's go, cause you wrote a great piece on that. So let's get sort of your thoughts on there. And then maybe if we could segue into MEV Boost, why that was originally created, and then talk about that roadmap for enshrined PBS. Your thoughts there.

Optimistic Relays is sort of this new relay type that allows for the faster propagation of blocks from block builders to validators in the MevBoost context. So the state of the art right now and when MevBoost launched was a block builder sends a block to a relay, the relay simulates it, validates that it's a correct block, and then forwards it over to the validators for inclusion in the chain for the proposal and inclusion. Optimistic relays basically just say, well, instead of simulating the block, we can have a trusted relationship with the block builder where they're bonded for some amount of capital, and we can optimistically just pass the block over to the validators for execution. And we save, you know, call it 100, 200 milliseconds on the simulation of the block inside of the relay. This means that you can incorporate 100 milliseconds to 200 milliseconds of additional value into the block.

And by value here, I sort of mean equivalent to information, right? Because time is money, as we are all taught. And so in this additional 100 to 200 milliseconds, the block builder is able to sort of incorporate a lot of new information that's being propagated in the world about maybe the price of different assets on different chains and update the arbitrage trades that they're sort of including in their block. Which means that the blocks that come from these optimistic relays land on chain and win sort of the block auction at the validator level. So this is like a very clear example of, okay, well, every millisecond, you can incorporate additional value into sort of the proposal that is being made to the validators.

And so there's going to be sort of a race for more efficient relay infrastructure to be able to carry these blocks over.

Interesting. So let's segue the discussion of optimistic relays because relays are not a permanent state of affairs, right? Eventually, there's sort of a stop on the road into enshrined PBS. And I would love to... I feel like that's a pretty good place to close.

This week, Mike Neutter actually came out with his updated thoughts on what the roadmap was going to look like and how we should all be thinking about that. I would love to get your thoughts on enshrined PBS. What you think about the decision. Ethereum is very selective about what it actually decides to take into the protocol. PBS was kind of 1 of those very select decisions.

So maybe if you could just weigh in on that and then how you see Ethereum consensus sort of changing with Intron PBS.

OK, this is exciting. So I started looking at PBS in the summer of 2021. So I'm like 2 years into, into PBS research, I guess you could say.

I was just looking at it and I was like, Hey, it's 2023. That could be 5 years ago. I have no idea. The lines are cold.

And it was all in the context of, okay, the merge is coming. Right now Flashbots is sort of working on proof of work Ethereum. What is the solution that we're going to bring to proof of stake Ethereum or on MEV? Is it going to be the same thing or is it going to be different? Had some discussions with the EF team with Vitalik around like what does a better system look like?

And that's where sort of initial designs and ideas around PBS came into play, separating out the builder role from the from the proposer role. And the question at the time was, okay, do we wait until PBS, Enshrined PBS is ready before doing the merge? Or do we proceed with some other solution at the merge that doesn't, you know, require consensus changes and therefore isn't going to delay the timeline of when the merge happens. And the decision at the end of the day was, okay, well, we don't think that we can convince protocol developers and development teams to delay the merge and to do the research that's required for PBS to be a thing. We think that there's just too much research there.

And so we need to find a solution for having out of protocol PBS. And that's where I started designing MEV Boost and over the course of sort of the following year, sort of brought it to to the market. Now, there was some like very conscious decision in the in the design of of MEV Boost. 1 of the main goals with it, from my perspective, was to be able to put a clear price on the value of a block, which was not a thing that existed in the past. This concept of there being a public value of a block, and say this block is worth X, did not exist, because all you had before was a bunch of transactions being routed to a miner, a miner constructing that block, and it would sort of obscure how much value they were capturing out of it.

And you had this issue where the mining pools would be able to capture some of the value and not distribute it back to their miners. So they would capture the MEV value and not distribute the rest of the value back to their miners. MEV Boost sort of solved this by saying, okay, we have this block auction, the value of the block is public, and this allows us to have sort of transparent price discovery on block space value. It also sets us up nicely if sort of this continues and gets put into the protocol for being able to burn this value. So if you can have some consensus on what is the highest value of a block, because you have this open price discovery, then you can do whatever you want with the value of that block.

That's sort of where the inception of why MVBoost is good, why it's sort of a good precursor for Entryne PBS and for eventually MevBurn sort of came from. I think there's still a few upgrades to sort of MevBoost that are possible before we get to Entryne PBS. 1 of them you mentioned a few times, which is unconditional bids. So this just means that now block builders have to sort of commit to a payment, regardless of the validity of the block. There's some technical difficulty to implement this outside of a protocol.

You need basically some Oracle that's able to say after the fact, if a block was valid or not. But certainly when it comes time to try in PBS, That's sort of 1 of the main things. You don't longer need to have an Oracle or some external source of trust to validate a block. You just have sort of within the protocol, the attestation committees be able to determine if a block was valid or not.

Kind of land the plane here on like when we eventually like, so move past all of this, and this is all put in protocol, how is it going to look? How's it going to look different from today? Obviously, we're not going to have relays and then walk me through like, what are the big implications of this? Is this going to be like a huge boon for the network and, you know, really lead to a more decentralized sort of validator set? Or is there kind of another side or take to it?

1 of the things I found most beautiful about the merge is that you completely changed everything from like the RPC down And the app to application developers and to users, they like didn't notice a thing, right? They just went from 1 transaction, transacting with like miners and like mining pools in China to like the next day transacting with like stakers and staking pools are mostly concentrated in the US. And like to their, to their perspective, they didn't, you know, have any UX, UX difference. And that was, that was just like crazy to even think that you could do that. I think Entryne PBS is going to be pretty similar, right?

So it maintains the role of block builders and all the features that sort of block builders can develop. It changes the role of the relays and sort of gets rid of the relays and allows block builders to interface directly with proposers. The question is then, OK, well, what's the next step after that? Is MevBurn going to come around? I think that might have a bit more impact.

So if MevBurn does get shipped, then there should be less incentive for concentration of stake inside of staking pools. And so maybe you'll have sort of more of a noticeable difference there. But EnshrinedPBS on its own, I don't think is going to have much noticeable difference to the way that the system works.

All right, Stephan, we could, I'm sure, go on for hours more here, but I want to give you a chance to talk a little bit about frontier research and what your plans are and what you're kind of doing over there.

Yeah, so I sort of opened up the conversation here by talking about, you know, going from thinking about MEV supply chain to transaction supply chain. And frontier research is really sort of based off of this idea, an idea that thinking of sort of MEV as a 0 sum wealth redistribution problem is not the right framing. It causes teams to think of it much more in a closed mindset, like not wanting to share information and a lot less experimentation and innovation across the board. And instead reframing things as a positive sum with wealth creation game and allows us to think more about, okay, how can this infrastructure, how can this supply chain be used to generate real value for the users and really prove that crypto and these systems that a lot of us have spent so much time building on have some true value to create for the world. And so it was based around this idea and wanting to explore these concepts a lot more.

And so we have a few different initiatives. We have a publication that you kindly mentioned and said nice things about. And this publication is not just the content that we at Frontier Research create, but we invite any actor that's building on the transaction supply chain to submit articles for review. We basically provide editorial services, we review it, and then we curate the content to make sure that the publication remains a place with super useful mental models and high quality signals. And so, yeah, anyone who's interested in submitting articles for publication there.

We'd love to hear from you. We're also offering sort of advisory services. So part of the vision is for this transaction supply chain to deliver value to the world, We need a lot of different teams building different things and like really going out there and trying new things that you wouldn't have if you just have sort of a single approach or a single way to view this supply chain. And so we work with parties sort of across the entire industry to help them bring some of their products and ideas to market. And then the final initiative that we're sort of getting kickstarted is what we call Frontier Adventures.

And maybe you could call it a bit of a play on Frontier Ventures, but it's Adventures because what we're looking to do here is really sort of target some of the components that are very core to this transaction supply chain and incubate and sort of build some experiments in-house as well. And so there's, we've sort of started collaborating on a builder, on a block builder there, that's called the Faith Builder. And we're helping the team there sort of bring this, bring this to market and provide sort of some of the more interesting transaction types that I think are going to become really useful for providing these better user experiences. And then we're also looking at, OK, what does it look like to to provide services at the at the messages layer, at the at the networking layer? We are considering sort of launching some additional efforts on on that side.

Super interesting, man. Well, honestly, Stefan, this has been so great. I'm so glad we were able to do this. This was like, just honestly, just filled with gems. And we got to basically everything that I wanted to ask you about.

So I don't know. Guys, listeners of the podcast, I mean, you just heard from Stefan for the last hour and change, but I highly recommend that you go check out the site. I can link it in the show notes, but yeah, it's Frontier Research, and I think the site is frontier.tech. So definitely go check that out. And yeah, man, I'll be super excited to see, particularly on the adventurous, the adventurous or adventurous front, I'm excited to see what you got cooking over there.

So maybe we can do this again in, you know, 6 months or something like that and just see how things have progressed.

Amazing. Thank you so much, Mike. It was a pleasure to speak with you. And yeah, I hope it was some interesting content for everyone.

Absolutely. I have my faith. You