Commitments and privacy in the MEV supply chain Robert Miller

Hi everybody. My name is Robert Miller. I lead product and I'm a steward at Flashbots. We're a research and development organization focused on ME. I'm going to be talking to you today about commitments and privacy in the ME supply chain, why they're important, and how Flashbots is using commitments and privacy to design protocols for trustless collaboration and to decentralize ME.

So for my talk today, we're going to start by looking at the ME supply chain first. We'll review this framework for how you can think about ME, how it affects users at different stages. We'll talk about what Utopia and Dystopia look like and how to get out of dystopia and to me utopia. And we'll look concretely at Mev Boost as a case study for how we can get to Utopia using privacy and commitments before introducing Mevshare, which is Flashbot's new protocol for collaboration. we'll talk a little bit more about in a moment.

So that's the high level treasure map for us today. But beginning with the ME supply chain, the MEV supply chain is this framework for how you can think about how a user's transaction progresses before it is included on chain. So you begin a user has some intent, something they want to do on chain. Like I want to perform a swap. A wallet will take this intent and use that to generate a signed transaction which a searcher which is a really sophisticated user in Ethereum that specializes in making money on chain will see this user's swap and find ways to bring prices back into line as an example after that swap has moved markets.

So the searcher creates a transaction of their own which arbitragees markets to capture some me and forms an ordered list of transactions with the user's transaction called a bundle. This is sent on to another specialized actor in the supply chain called a block builder. A block builder's job is to create the most profitable block possible. taking many bundles from many different searchers and many transactions from many users and composing them into a full block and they pass that finally onto a validator whose job it is to propose a block to the network and that's the end to end view of what it takes for a user's transaction to get included on chain on Ethereum today and how the ME supply chain works at different stages. Um there's some nuance in here.

There's some different entities, but but this generally is a good mental model that we'll use today to look at me utopia and dystopia. So, this is what utopia looks like. This is kind of the picture of what we want the future to be. Um, what we want are many specialized entities being able to play each of these roles in the supply chain. And you want every party to be able to play one role without having to play a different role as well.

So for example, you want a validator to be able to just be a validator and only know how to be a validator and not need the skills to have to be a block builder as well because building blocks is a super difficult job that requires a lot of infrastructure and specialized knowledge. So if you needed to be a builder to be a validator, it would raise the barriers to entry of being a validator much higher. Uh and it would lower the decentralization of the Ethereum protocol. So this is the way of why specialization in these roles is really important and why we want this highly specialized supply chain where different actors are playing different roles and you want many different parties at every step of the supply chain that are competing to provide the most value to uh other actors within the supply chain. Uh you can see the dollars flowing at the top.

Finally we we don't want any entrenched parties. We don't want any permission systems. That means not flashbots. That means not anyone else. no entrenchment.

And this is what uh an alternative could look like of me dis me dystopia where instead of having this highly modular supply chain that's flat with a lot of competition, you have a single party or a small group of of entities that are vertically integrated end to end. You know, they are the validator, they are the builder, they are the searcher, they are the wallet all in one. Uh you don't know what's going on on the inside. It's not a competitive system. And if you get to this place, it breaks down the core properties of why we care about blockchains.

Uh it it it destroys the decentralization of the protocol. It allows a single party to introduce things like censorship, which we're already seeing on Ethereum. It allows these parties to extract rent. And it's opaque uh and goes against sort of the core properties of of decentralization. And the reason why this happens is if there are efficiency gains from vertically integrating in the MEV supply chain um that you don't get if you have specialization.

And we'll show how we get to ME utopia by enabling this specialization in the ME supply chain. And you need to do that through creating these protocols for trustless collaboration that allow many different parties to compete and maximizing competition uh at each of these roles. But this is a very difficult thing to do because parties don't necessarily trust each other in the me supply chain. And we'll use MEV boost as a case study to show how you can enable trustless collaboration and competition by using privacy and commitments. Okay, so that was a mouthful, but we'll slow down and look uh at MEB boost specifically as a case study.

So, validators are the parties that are responsible for proposing blocks to the Ethereum network. And as a validator, you want to make as much money as possible uh for doing this job. A core part of that is choosing the most profitable ordering of transactions within a block. But this is very difficult because MEV is very complex. It's it's super non-trivial to find out what the most profitable ordering of a transaction is.

So a validator wants to outsource this job to a specialized entity called the builder. Well, this collaboration is quite difficult because if a validator can see the builder's block in the clear text, then the validator could uh frontr run the builder's block and steal their me for themselves, the cut that the builder would take, or they could even uh frontr run users. And the sort of consequence of this is that if a builder is sending clear text blocks to the validator, they will only want to send that to trusted and well-known entities. Your Lido, Rocketpool, Coinbase, Kraken, Bonances of the world. And this hurts decentralization because only trusted entities can get really profitable blocks that extract ME.

Solo stakers wouldn't have access to the most profitable blocks. Uh and right now me boost and and sort of the gains from me as a validator give you an increase in returns of about 100% APY. So this is a really big threat to decentralization and we need validators to have open access to builder blocks. But to do that builders can't have their blocks seen by validators. So the the the takeaway from this slide is that you need privacy in the MEV supply chain for collaboration between builders and validators.

Um but if you imagine that you have privacy, if for example builders are only sharing block headers with validators, you have another problem which is that validators don't know if they can trust builders. And there are ways for builders to uh to hurt validators in this process. So a block header doesn't tell you anything about the profit of a block or if it's valid. So a builder could propose a block header to a validator and lie about the money that the validator will get or propose something that is not correct on the network. And uh just because a validator signs a block header doesn't mean that the builder will reveal the block body.

Right? You can't just have privacy. You need more than that the builder to commit to certain blocks and be able to make sort of strong economic or or otherwise commitments about the blocks that they're proposing to validators. You need these dual things. And so how did we manage this with me boost uh and in our protocol for validators to interact with builders?

It's sort of this three-step process which is fairly simple. You start first with um and we're introducing this new entity that you see on the screen now which is called a relay. It's used as a a privacy and commitment device by both builders and validators. And first, the builder sends their block to a relay who simulates the block to make sure that it is valid and profitable and reports out to the validator, hey, here's a block header with a certain profit if you're interested in signing this. The validator will see a bunch of block headers and sign the one that is most profitable, returning that to the relay.

The relay then knows that the validator has committed to including this this block because they signed the header and they can reveal the block body safely. Uh and this is one part of this me supply chain you see in the bottom left. So it's a simple kind of two-phase commit reveal scheme. And this helps builders and validators permissionlessly collaborate together. But why does it do that?

Um there's there's a couple things that you get from this scheme and and using this new entity called a relay. Uh, first privacy helps unbundle this because builder blocks are hidden until block headers are signed. And at that point, builders know that validators have committed to a certain block. And uh, because of this, builders are happy to share their block headers with any validator that um, any validator that is willing to listen because you're only sharing a selective amount of data. Enough for validators to perform their job, but not enough for builders to be frontr run or users to be sandwiched.

And validators know they have this data revealing guarantee that if they sign a header, they're going to have the block body behind it. They're not going to be um attacked with with the builder withdrawing a body because they know that the relay will reveal the body of a block uh if they sign a header. Like I said, we're sharing selective amounts of data. It's not absolute privacy. It's programmable privacy.

You share enough data to let people do their job, but not enough to frontr run. And finally, you have the relay acting as this commitment device between validators and builders. Both of them committing and and using this third party to certain blocks. The net result is that you unbundle the MEV supply chain and you let builders and validators permissionlessly collaborate where neither party has to trust each other. They have to trust this third party, the relay.

Um, this isn't the endgame of what we want. We want to create a decentralized system where you know there's no trusted party the relay uh in the middle of these these entities but in the interim we think this is important to allow open access to me to any validator on the network and keep the validator set of Ethereum decentralized. So we want to remove the relay and use cryptoeconomics to do that. Uh and that is the next step in this process. So okay what is the next step in me utopia?

What are we doing with the ME supply chain after this? And how are we applying these concepts to other parts of the MEV supply chain? At Flashbots, we asked this question and the answer that we came up with was to focus on users and order flow instead. And this comes from a pretty simple premise. So users are creating ME with their transactions.

They're leaking value into the memp pool right now that is being captured by these super sophisticated entities, searchers, builders, oftentimes validators, and we want to create a permissionless system that lets users and searchers collaborate together for users to internalize that value instead. Um, so this is the premise that we started with. But as you'll see, this is quite difficult to do because a user interacting with a searcher uh directly introduces them to all kinds of risks. You send your transaction to a searcher and they might frontr run you. You're not going to get money kicked back to you.

You're going to get worse execution by directly interacting with a searcher. There's a risk that you get frontr run. And even if you're sending your transaction to someone you trust, there's no guarantee that you can internalize your MEV, that you actually get paid for it. Uh because you don't have bargaining power in this relationship, just sending your transaction to them. And there's no way even if you are getting paid by a searcher uh to enforce that payment downstream in the MEV supply chain.

So say a searcher is willing to pay you, but a builder fronts them and takes your payment. You need some some payment enforcement here. So at Flashbots, we've designed uh another protocol for collaboration in the MEV supply chain. It's called MEV share and it introduces uh another third party which we call the matchmaker. It works pretty similar to MEV boost.

First, a user sends a transaction to the matchmaker and the matchmaker shares a little bit of information about the user's transaction with searchers. So not the whole transaction, but enough for the searcher to do their job. For example, if a user wants to make a swap, the matchmaker might tell searchers, hey, this user is making a swap on ETHUSDC, but not telling them how much they're swapping for. And that's enough for the searcher to to construct a partial bundle in step two and tell the matchmaker, you know, I'm interested in this swap on ETHUSDC. I want to try and arbitrage it with this transaction, Mr.

Matchmaker. Could you introduce could you insert their transaction in front of mine so I can back run it with my partial bundle which is what the matchmaker does in in the third step which is create a full bundle with the user's transaction the searchers partial bundle and send it on to the builder with a new thing called a validity condition uh which enforces that the user gets paid back me. So, it's this three-step process again. Um, first, selective data sharing. Second, partial bundles.

Third, full bundle to a builder with enforcing the user gets paid. So, why does this work? Again, it's it's pretty similar concepts to why Mev Boost works. First, you introduce me into this supply chain where users transactions are hidden from searchers. So, they're comfortable sharing their information with any searcher um because searchers don't get the full information set.

But we are sharing some information. It's it's not absolute privacy. It's programmable. You share enough for searchers to do their job, but not enough for users to get frontr run. And finally, we have the matchmaker playing this role of of a commitment device for both searchers uh as well as enforcing payments with bundle validity conditions from builders.

The net result again is that we give this permissionless way for users and searchers to interact together. um where users can get paid for their MAV, searchers can extract MEV. This is what the MV supply chain looks like after MEV share. You have MEV boost between builders and validators and you have MEV share between uh the searcher, wallet and user. But there are obvious gaps in this MEV supply chain.

Um where we need new protocols for permissionless collaboration. So perhaps the the biggest one and and the most important here is this place between searchers and builders. Right now searchers, if you construct an MEV bundle and send it to a builder, uh you need to trust that the builder isn't going to unbundle your transactions, they're not going to screw you over in many different ways. And this limits the number of entities that can uh build blocks with your bundles. Um it also this sort of trust assumption limits the number of places that me share can share bundles with also uh because we need to trust builders not to to mess around with those bundles and to actually pay back me to users.

Uh so there's some sort of permissionless protocol here uh in this space between searchers and builders. Maybe we call it ME build and alpha leak. We just uh released our code for running a builder inside of an SGX earlier today. So, we're producing blocks on a test net, Solia test net inside of an actual SGX. Uh, which means that our builder can't tamper with or see bundles before that is proposed to the network, which is pretty cool.

And there may be also cryptoeconomic ways to enforce this too. But this is an area for future collaboration in a place where Flashbots is going to be looking a lot more deeply uh in the future. And there's perhaps some other protocol between the user and wallet, but but this seems less salient and less immediately relevant. And then um permissionless interaction between searchers, builders or builders and wallets. Um so sort of wrapping this up, we looked at the ME supply chain.

We looked at how without trust and privacy, you have these incentives for vertical integration that would lead to ME dystopia. And we looked at how by using privacy and commitment devices, we can remove the need for trust between parties, we can introduce collaboration, we can introduce efficiency and get us to ME utopia with that really flat specialized competitive decentralized supply chain that we looked at in the mi in in the beginning. And we saw how Mev Boost and Mev Share specifically use these two ideas of privacy and commitment devices. And to wrap it all up, this is what we're building at Flashbots. We're not uh sort of we're not okay just building these trusted parties in Mevshare and Mev Boost, but we want to build an actual decentralized platform for privacy for credible commitments in the MV supply chain and that is what we're building with SWAF.

Um so thank you so much for listening. Really appreciate you all being here and listening and I look forward to decentralizing MV supply chain with you. Cheers. I don't know if I have time for a question or anything. I'm taking that as a yes.

I don't know SGX early today. So I don't know how much you think you're going to extend the whole SGX in this um supply chain experience like I think private orderflow you can also use SGX like just how much you think is necessary and I think do you see Intel SGX as the only I guess choice for TE Yeah. So it's a good question where do we extend trusted hardware in this supply chain? Um, I think at the limit you probably want to put everything in trusted hardware and not because it's a silver bullet, but because trusted hardware adds another layer of defense, uh, because it makes it more difficult for the players in this system to tamper with it, to remove privacy because it costs money to attack. So, our philosophy at Flash Pots is defense and depth.

You want to layer these technologies on top of each other. Um, so we're interested in putting literally everything inside of an SGX at the limit for that reason. it just raises cost to attack basically. Um, we're looking at other types of trusted hardware too, but they give you different guarantees. So, it's very nuance like what works in in what capacity.

Yeah. Thank you so much.