Encrypted Mempools: a path to Ethereum L1

Hello, my name is Mark and I work as an Ethereum core developer for Nethermind. Recently, I've been working on implementing the Shutter encrypted mempool in the Nethermind client. Today, I'll be giving a whirlwind tour of the encrypted mempool design space and sketching a path towards enshrinement on Ethereum L1. Let's start with how a transaction normally ends up on chain without an encrypted mempool. So the user gossips their transaction, in this case a swap from ETH to donut tokens, and eventually it reaches the proposer or builder for this slot.

You can decide to include it in their block. What's the problem with this? The first one is front running. So the proposer or someone else is able to insert their own transactions ahead of the users, front running them. They know that the swap will increase the price of donut tokens, so they can buy up those tokens first and make a profit, while the user gets worse execution on their trade.

They can then sell off the token afterwards to make this a sandwich attack. This can also be a problem in other applications, such as in an on-chain strategy game. Imagine you can see your opponent's moves and front-run them with your own. The other problem is censorship. This is when the proposer doesn't include the user's transaction at all.

Encrypted mempools are a solution to this. So the user posts their transaction encrypted in a public constraint, and the proposer is required to include all transactions from the public constraint in a predefined order at the top of their block. We need one extra component for this, known as the keeper, whose job is to publish the public key and release the secret keys just in time for the proposer to decrypt and include the transactions. There's a spectrum of possible keeper designs, ranging from trusted to trustless. In my opinion, only the most trustless of these will be suitable for the high standards of L1.

On one end, we could have a trusted party with access to the secret keys. To improve on this, we could have the secret keys be stored inside a secure enclave, such as Intel SGX. This is what Suave does. With a threshold encrypted mempool, such as Shutter, we fragment the master secret key between a decentralized committee of keepers, requiring a threshold of two-thirds of them to come together to reconstruct the secret keys. Finally, we have delay encryption, where to reveal the secret keys, you have to evaluate a sequential function, which will take a certain amount of time.

This is a relatively weak security assumption that everyone is able to evaluate this function at a similar speed, which can be achieved when specialized hardware is widely available. And I think this approach will be suitable for L1 enshrinement in the future. Now let's consider the design of this public constraint. So this constraint should be available to everyone to download, and its construction should be as permissionless as possible, so any user can add encrypted transactions to this public constraint. One approach is users posting their encrypted transactions to cool data.

This is quite permissionless, but cool data can be expensive. Another approach is users sending their encrypted transactions to the proposer, who then constructs the constraint and posts it to blobs but this is more permissioned and there are other approaches here so we could imagine a random subset of validators constructing this public commitment and there's quite a lot of overlap here with inclusion this designs unfortunately in the worst case we can never be completely permissionless. Whoever has power to decide which transactions go into this public constraint could, for example, demand proof of OFAT compliance. However, assuming there is some legal protection for using encryption and encrypted mempools become the default, it's unlikely this would be a problem. So there are different approaches to ordering.

I think priority fee ordering seems like a reasonable solution. In the future, once the cryptography is more matured, we might be able to do more advanced block building strategies using homomorphic encryption. Using this, we can perform encryption, sorry, perform ordering on the transactions while they are still encrypted, replicating the functionality of secure enclave designs. So how are we going to enforce proposals to include a transaction? We want to make them choose between including all of the transactions in the correct order at the top of the block, or all of them being invalidated so that the proposal would lose out on all of those tips.

There are two different approaches here. We could enshrine into the protocol, so we tie the block validity to correct inclusion, or we could have an out-of-protocol solution, so we check for correct inclusion with a smart contract. In the long term, enshrinement would be preferable, but until then, we'll have out-of-protocol solutions. We've proposed EIP-7793, which is a relatively minimal change that will support these outer protocol memples to check for correct inclusion. And this allows a smart contract to tell where in the block is being executed.

The final thing to consider is hiding transaction metadata. So when the user broadcasts their transaction, they can leak information such as timestamp, IP address, and size. We don't have time to cover this, but there are various approaches that can be used to hide this information. Thank you for listening. Thank you, Mark.

Thank you for the session. Do you have questions for... Oh, wow. Interesting. Okay, I saw your hand first.

I have one question. Do your approach go into as the overhead to the process to include the transaction into the block? Actually, you have to do everything in the rank of the block time to make sure that, yeah. I think there's relatively minimal overhead. So the user encrypts their transactions, and I guess it would add one slot of latency.

So with Shutter, when we use cool data, we're going to have one transaction where we post, and there can also be an overhead in terms of gas fees for this post. And then after that, then we just have to decrypt and include that transaction. You mentioned the MEVs, it's all about an deterministic order of transaction. But then do you think the encrypt mempool is something very overkill for this problem? I don't think it's overkill really.

I mean, yeah, we can't necessarily eliminate MEV entirely, but this does give us some front-running protection. Next question? Okay, here. Are there situations where an out-of-protocol mempool cannot protect against front-running? For example, if there's a chain reorganization, you have the old block, then you could front-run at the next block for the next block, right?

So, I mean, yeah, so these... Yeah, I think there are some situations. I mean, with our protocol solutions such as Shutter, like, the validators have to register beforehand so you know, like, which proposers are signed up to use the out-of-protocol solution. And the keys would only be released in these cases. If the proposer doesn't include the transactions at all, then there's a chance they could be front run in the next one.

But that's why we need this. We tie the block validity of the transactions to that slot, so no one could then later include these transactions. But you have potentially leaked some information about your transactions. With Shutter, currently, currently proposes trusted, right? Yeah, at the moment.

But I'd say this is like just a step towards improving so you can remove these trust assumptions. Do you have one more question? Last question? Okay. Last question?

Okay. Go here. Yeah, so from the user experience, front-end user experience point of view, how is this encrypted mempool superior to the flashbots in terms of, say, avoiding the sandwich attacks? Yeah. I'd say from the user experience perspective there's not really a difference it just depends on your own personal like trust model so they said sort of flashbots protect for example is like um i don't have the slides okay so it was like the most trusted approach on my thing whereas whereas we can progressively move to more trusted solutions so that you don't have to trust Flashbots to do this.

All right. Thanks so much, Mark, for this session. If you have more questions, please come meet Mark and then get to deep dive. Thank you so much. Let's give a hands-off applause for Mark.

Thank you.