Decrypting Encrypted Mempools: State of the Art, Convergent Designs, and Future Directions

Transcript

Hello everyone, and thank you for interrupting your lunch to come and talk to me. So today we're talking about encrypted mempools, and you might have seen that there's been a proposal for the latest headliners to propose encrypted mempools. So it was interesting, I think to look into what was in these proposals, what had been done before in the academic literature as well, and see what was the role of MEV in all of these concepts. So as you probably know, in Ethereum today and most blockchains, we have this notion of MEV.

And MEV is often pictured as like profit extraction, but it's a bit more complex than that. It's really about handling incentives. [music] And in permissionless networks, we have to handle incentives in one way or another. The way we depict that at Flashbots usually is that you have a choice between three options as to how your MEV is being handled. You can make the choice or not make a choice, I think. If you don't make a choice, usually what happens is that MEV translates into spamming your networks.

Or it can translate into latency races, which leads to centralization. So in general, the option we favor is to run auctions. You might have heard the term of like order flow auctions that needs to that needs to happen in order to control the MEV in a better way. And if we try to project that into what exists in the different forms of mempool and and transaction ingress that we have today, in a way, the the trilemma depicts as like if you want fast and decentralized, usually that's the what the the public mempool gives you.

If you're more interested in having private transactions, but still fast inclusion, that's the role of centralized builders usually. And in a way, the the role that encrypted mempools hope to fill is to give steer this this trilemma towards more of the [music] private but decentralized. And we'll see if we can do a bit better than that. So as I said, the current workarounds is usually to use private transaction lanes, where instead of going for the public mempool, you send directly to a block builder, for example.

And [music] in that case, of course you reduce the options for front-running, but you do add some trust in a specific builder. Um which, you know, can have some impact in in in the way you're making your choices. You might not be happy, for example, with the geolocation constraints of a builder. Some builders have to sanctions because of the the region from which they operate. Interestingly, we see a different form of of these transaction lanes now >> [music] >> in what we call BuilderNet, which tries to, in a way, give you the best of both worlds with private, fast, but also decentralized because it's run by different operators.

The magic here is like instead of trusting a given builder, you put your trust in T, so in in the whole MEV supply chain, in a way. And turns out that not everyone is happy with these guarantees, so emerged another option. What can you do? Well, potentially you can encrypt everything, right? That's the fundamental idea of encrypted mempools. [music] You hide the content of the transactions all the way down until the order of this transaction in the block is actually committed.

So it removes the options for front-running. You cannot observe the intents. And of course, sandwiching becomes impossible or very risky for searchers. And so the way to encrypt, in a way, is pick your own choice, right? It's it's about what you want to do with it. So you can have regular encryption, but you can also have like some more fancy primitives that allow you to execute or not. In this talk, we'll focus more on the threshold encrypted mempool variant, which is the one that's has received the most attention, as far as we're aware, [music] presumably because of like its native compatibility with how the validator set is structured.

So let's have a quick look at what the academic literature gave us. And I want to first give credit to Shutter, who, as far as I know, is like the one of the first production deployments to offer a fresh running encrypted mempool. There is one notion we need to be aware of in these deployments. It's the idea that in at least in the initial setting, you had like this committee of keepers that were controlling the the decryption keys, right? [music] And these keys were released based on a certain epoch.

So this construction has been studied in this USENIX security paper from 2014. And you know, a few vulnerabilities were identified, but the main one we want to keep in mind [music] is this notion of like epochs leaking transaction. So if you decrypt all transactions based on a given epoch, whether or not the transaction is included in the block, it will be revealed. So if unfortunately your transaction was not revealed, was not included, it is still revealed at the end of the epoch, which is not what you want at the end of the day.

So to address this issue, we moved to like a new proposal, which is called batched threshold encryption. And here the idea is to say we want to be able to select a batch of transactions to decrypt in order to amortize the cost. The other naive option would have been to try and like decrypt every single transaction separately, but you pay in terms of communications if you do that. So it seems that it's a good compromise to go for a batch of decryption of a batch to reduce the the communication that you need to >> [music] >> to have.

So we solve by doing that this this notion of like pending transaction privacy, which is great. And we have the guarantee that, you know, transactions cannot be decrypted when they don't need to. The only issue that was remaining with with the batch was that you needed to run a new DKG setup on every epoch. So one proposal called BitMEX which came slightly afterwards, had this idea of like having a single one-time setup, which is even better, in a way.

Now the question is like what's the catch? Why do we stop here or not? Well, we don't stop here because even with one single DKG, you still have a lot of communications to do when you do the setup in the first place, right? And it's in it scales with the amount of parties that you have to run. But more importantly, if you want to rotate committees, so those who hold the shares, that becomes really complex. If you imagine that these committees are mapped, for example, on the validator set or a subset of the validator set, this is a very asynchronous network, right? People come on online and offline.

So it it becomes very tricky to map that to the to the Ethereum set. And so a new primitive emerged, which is called silent threshold encryption from a crypto paper in 2024. And the idea here was to let the validators generate independently their keepers and just publish a hint that would allow everyone to then non-interactively combine these hints to produce a joint public key. It is based like a flavor a weak flavor of witness encryption. It's not very important here, but this is a very nice construction.

As usual in academia, when like two good ideas emerge, what do we do? We put them together. So the next paper, and I think one is the one that is probably like state of the art for this construction, is called Beast MEV with an S this time. And it's basically unifying the two things we've seen that we found >> [music] >> appealing in terms of properties. So combining together batch and silent to have this epochless batch decryption from BitMEX and the silent setup from the crypto 2024 paper.

The only caveat here is that it's pairing based, so it's not post-quantum. And as you're all aware, we probably want post-quantum these days. There is like a follow-up to that from a different team from, you know, both the EF and Flashbots that do propose a post-quantum version, but we not really covering here. I'm happy to share the slides afterwards. In terms of what the community has to say, right? Now we know kind of like what is the state of the art from an academic standpoint.

It's interesting to see how it could be adopted for the protocol. There is like a very interesting blog post on on EF research where two EF researchers tried to, in a way, survey as we did these these all these primitives and and try to come up with a set of requirements, in a way. And what idea they had was to say, well, we can't just rely on committees, right? Because like if the committee goes offline, we lose liveness in in the protocol. So instead, why don't we give the user also the option to self-decrypt?

So you have like that's why they call it a hybrid encrypted mempool, where you, in a way, keep in check the two actors by having the option for either the user to decrypt or this committee. And the security boils down to the user not being able to predict the committee availability in that case. Interestingly, they also covered a set of requirements of what they want for a threshold encrypted mempool to viable at the protocol level. And we we find again like all the properties that we covered in the literature review. So this idea of silent setup, but also non-interactive decryption, and of course small keys and small ciphertext, right? The problem, the realization is that

none of the primitives that we've seen are actually matching all of these requirements, right? So that that's an issue. And as a result, we kind of really enshrine at least the cryptographic part of encrypted men pool. And if we want to use them, it makes the design even more complex cuz we need to accommodate for like more flexibility in the cryptography we're using cuz we don't really know yet which one is going to be ideal. So it's kind of like the idea I think of like this lucid proposal to give a lot of flexibility and like try to address all of these issues.

I'm not going to do it justice here. It's way more complex and thorough than what is depicted here. The only um idea that I want to convey based on it is that execution is delayed in the next block. So one thing to keep in mind, we're acting here on stale information. The other thing that I want you to keep in mind, and that's a limitation in my opinion, is that ordering in the block is blind. We're ordering the transactions while they're still encrypted, right? That's that's a property. And the goal is to suppress MEV, at least the toxic part of MEV, and still enable the non-toxic part [music] of MEV.

So let's let's summarize what we've seen so far. Um we, at least the community agrees on on a few different properties. This idea of like liveness that must survive. We can't really enshrine a given encryption. But I think there's like a few blind spots that are common to all these properties, and in particular I want to stress on like this idea of blind ordering. And really boils down to we want to address MEV, but is it enough with [music] the constructions we've seen? So the MEV perspective is, of course it's not enough, otherwise I wouldn't be here talking to you about these things.

And the MEV blind spot in particular boils down to the fact that decryption is binary. You either have fully encrypted or fully revealed transactions. You don't have anything in between where you can act on on like an encrypted state, for example. And so you suppress all the MEV mechanisms that we know, all the auctions that we know, indiscriminately. At the same time you can introduce new MEV games without even wanting to do so, like the free option problem that has been covered for EPBS, for example, can re-emerge in this setting. And more importantly, this notion of like blind spam that comes from like a lot of like blind arbitrage submissions. We'll see how these three things translate from the impact at the

user standpoint from something that should benefit the user into how does that impact it in the in the in the scenario. [music] For spam, for example, the blind ordering in a way resembles what we've seen with the MEV share product at Flashbots, where you have the option to selectively disclose some of the fields of your transaction. And in the graph that we have here, credits to Thomas for the very nice graph, you can see how bundles land when submitted to MEV share based on the amount of information that have been revealed from the transaction.

When you can act on the full information, we have a super strong landing rate close to 90%. When no information is available, you go down to blind ordering, and nothing almost can land. At the same time, you generate a lot of spam. Searchers will still submit bundles. These bundles can either be filtered if you can simulate transactions beforehand, and if they revert, you don't include them on chain. The problem is if you cannot simulate while you're ordering, these bundles, these transactions that will revert, will land in the blocks. So you have spam at the ingress and spam in the chain.

Not good. If you If you remove MEV, what happens is that basically you kill all subsidies for validator decentralization. So you're trying to offer and to guarantee decentralization, but at the same time you introduce a mechanism that will reduce the amount of decentralization. Because basically, if you can't do these like more sophisticated ordering, you revert to being able to spam as fast as you can and being as close as possible to the source of information.

It's a race to propagate faster. And so removing these subsidies will prevent validators in remote geographies to be viable. So not good. And finally, one thing I want to highlight is this idea of like execution quality. When you don't have fresh information to execute upon, and when you're not able to order transaction in a smart way, what we've observed in in this experiment, for example, is that the execution quality changes. So it's quantified. >> [music] >> If you have all the information you want for the same swap, for example, you can see that the deviation from the price is close to zero bits, right? But the further along we go in the block, when

moving to the right, we add more bits, so the the the the price becomes worse for the user. And clearly that's a signal that the market is moving towards reducing time to information instead of like increasing it by delaying execution. I will skip maybe the concrete example, but I will let's say go very quickly through it. Imagine you're trying to submit an encrypted swap, 10,000 ETH, on Uniswap. If, on the other hand, you're in a private men pool or a men pool on which you can execute, let's say in Bedrock net, for example, then arbitrage bots will operate effectively, and you can be back

running in the same block. You get a better price, you get rebates. On the encrypted men pool, you can only have that after 12 seconds in the next slot. Even if you could have that in the same slot, you would still act on stale information. And you would still act on non-sophisticated routing, which is not great, as we've seen. And so as a result, what happens is that users get worse prices, but also poor UX. There's a higher chance that your transaction reverts if you're just submitting a swap.

And on top of that, as we've seen, price gets worse. So really what we want to say here is that there is a case, a strong case for what we call programmable privacy. We've seen that execution post-ordering is too late. And the core problem in these things is when can you run the auctions? Because we know that auctions are the best way to handle the MEV incentives. And so if you do that after decryption, when content becomes visible, it's going to be too late.

You don't have to choose between either fully encrypted and fully decrypted. You have something in between, and that's really what programmable privacy gives you. Today that can be true with TEEs. In the future you can replace that with other things if you want and if you think that programmable cryptography is going to become fast enough. So inject FHE or whatever fancy crypto you want, and I'm be very happy to talk about that as well. But today really, what constructions like TEE based on TEEs enable is MEV solving based on fresh information, better transaction ordering in the block. So you regain this ability to put transactions in the order you want.

Same sort of execution, and most importantly, filtering all these reverts. So you reduce the spam on chain. Okay. So let's summarize what we've just said. As of today, sadly, we don't think encrypted men pools are economically viable. Execution quality really matters for users, and and UX in general is super important. So I think we should really consider this idea of programmable privacy. But really what it means is that it might be a bit too early to enshrine encrypted men pools as is.

There is, on the other hand, a lot of demands, and I think a lot of appetite both in these rooms at Flashbots and other organizations, to keep experimenting off protocol with these constructions. We can build better things, and we can reach these goals, but we still need to go further and to propose better constructions. With this presentation, I hope that I give you the facts that can help you to decide for yourself whether it's a good idea or not to enshrine encrypted men pools. Should we keep experimenting, or should we do it now?

My takeaway is to say privacy cannot exist without economic incentives. Controlling one without the other is not the right way. So let's try to go back to the drawing board, and let's design viable encrypted men pool on which we can execute. Thank you. >> [applause] >> We have 1 minute. If there is a quick question from the assistants. Don't be shy.

I'll be here a little bit longer if you want afterwards too. Okay, thanks a lot. >> [applause]