# Encrypted Mempools: a path to Ethereum L1 by Marc Harvey-Hill | Devcon SEA

- Speakers: [Marc Harvey-Hill](https://streameth.org/speakers/marc-harvey-hill)
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-07
- Duration: 09:26
- Watch: https://streameth.org/watch/yt-mUoWwRoHrvk
- YouTube: https://www.youtube.com/watch?v=mUoWwRoHrvk

## Description

This talk will explore the future of encrypted mempools, paving the way to enshrinement on Ethereum L1. Starting from current designs such as Shutter and SUAVE, security assumptions and out-of-protocol infrastructure can be stripped away with cryptography including homomorphic encryption, VDFs, and delay encryption. These approaches would trustlessly bring front running protection and censorship resistance to the protocol.

Speaker(s): Marc Harvey-Hill
Skill level: Intermediate
Track: Core Protocol
Keywords: encryption, mempool, Censorship Resistance, Core Protocol, Cryptography

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] uh hello my name is Mark and I work as an ethereum core developer for nethermind uh recently I've been working on implementing the shutter encrypted mle in the nethermind client uh today I'll be giving a worldwind tour of the encrypted mle design space and sketching a path towards enshrinement on ethereum L1 uh let's start with transaction normally ends up on chain without an encrypted mle so the user gossips their transaction in this case a swap from eth to Donut tokens uh and eventually it reaches the proposer or builder for this slot who can decide to include it in their block um what's the problem with this uh the first one is front running so the proposer or someone else is able to uh insert their own transactions ahead of the users front running them um they know that the swap will increase the price of donut token so they can buy up those tokens first and make a profit while the user gets worse execution on their trade um they can then sell off the token afterwards uh to make this a sandwich attack Um this can also be a problem in other applications such as in an onchain strategy game imagine you can see your opponent's moves um and front run them with your own uh the other problem is censorship uh this is when the proposer doesn't include the user's transaction at all uh encrypted mles are a solution to this so the user posts their uh transaction encrypted in a public constraint and the proposer is required to include all transactions from the public constraint in the in a predefined order at the top of their block um we need one extra component for this known as The Keeper whose job is to publish the public key um and release the secret Keys just in time for the proposer to decrypt and include the transactions um there's a spectrum of possible keeper designs ranging from trusted to tress um in my opinion only the most trustless of these will be suitable for the high standards of L1 um on one end we could have a trusted party with access to the secret Keys um to improve on this we could have the secret Keys be stored inside a secure Enclave uh such as Intel sgx uh this is what Suave does um with a threshold encrypted mempo such as shutter uh we fragment the master secret key between a decentralized committee of Keepers requiring a threshold of two-thirds of them to come to together to reconstruct the secret Keys um 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 uh this is a relatively weak security assumption that everyone is able to evaluate this function at a similar speed uh which can be achieved when specialized Hardware is widely available um and I think this approach will be suitable for L1 enshrinement in the future um now let's consider the design of this public constraint so this constraint should be available to everyone to download and its uh construction should be as permissionless as possible so any user can add encrypted transactions to this public constraint uh one approach is users uh posting their encrypted transactions to cool data uh this is quite permissionless but cool data can be expensive uh another approach is users sending their encrypted transactions to the proposer who then constructs the constraint and posts it to blobs uh but this is more permissioned uh and there other approaches here so we could imagine a a random subset of validators constructing this public commitment um and there's quite a lot of overlap here with um inclusion lless designs unfortunately in the worst case we can never be completely permissionless uh whoever has power to decide which transactions go into this public constraint um could for example demand demand proof of ofac compliance um however assuming there is some legal protection for using encryption and encrypted mles become the default it's unlikely this would be a problem um so there are different approaches to ordering I think priority fee ordering seems like a reasonable solution um in the future once the cryptography is more matured we might be able to do more advanced block building strategies using homomorphic encryption uh using this we can perform encryption sorry perform ordering on the transactions while they are still encrypted replicating the functionality of secure Enclave designs um so how are we going to enforce proposes to include a transaction we 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 the proposer would lose out on all of those tips um there are two different approaches here we could enshrine into the protocol so we tie the block validity uh to correct inclusion or we could have an out of protocol solution so we check for correct inclusion with a smart contract uh in the long-term uh enshrinement would be preferable but until then we'll have out of partical solutions um we proposed EIP 7793 uh which is a relatively minimal change that will support these outer protocol mles um to check for correct inclusion uh and this allows a smart contract to tell where and the block is being executed uh the final thing to consider is hiding transaction uh metadata so when the user broadcasts their transaction um 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 um thank you for listening thank you Mark um thank you for the session U do you have questions for oh wow interesting okay I saw your hand first uh um I have one question like um do your approach going to add the overhead to the process to include the transaction into the block actually like you have to do everything in the rank of the block time to make sure that yeah um I think there's there's relatively minimal overhead so the user encrypts their transactions um and I guess it would add one slot of latency so with shutter when we use cool data uh 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 um then we just have to decrypt and include that transaction um and you mention like we uh the the MS it's all about about uh aneristic order of transaction uh but then do you think like you the encryp PO is something like very overkill for this problem um I I don't think it's Overkill really um I mean yeah we can't necessarily uh eliminate meev entirely but this does give us some uh front running protection next question who okay here hey uh are there situations where an out of protocol mol cannot protect against front Runing for example if there's a CH organization you have the old block then you could front run in the next block for the next block right um so I mean yeah so these uh I yeah I think um there are some situations I me with our protocol Solutions such a shutter like you 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 in these cases um if the proposer doesn't include the uh transactions at all then there's a chance they could be front run um in the next one but that's why we need this um we tie the block valid uh the validity of the transactions to that slot so no one can then later include these transactions but you have potentially leag some information um about your transactions with with shter currently proposals are trusted right yeah yeah at the moment but um I'd say this is like just a step towards um improving so you can like remove these trust assumptions do you have one more question last question okay last question okay go here yeah so around like the user experience front frontend user experience point of view like how is um this encrypted mol superior to the flash BS like in terms of say avoiding the sandwich attacks yeah um 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 flash BS protect for example is like um I don't have the okay so it was like the most trusted approach on on my thing where it's like we can progressively move to more trusted Solutions so that you don't have to trust FL uh flash Bots to uh do this all right thanks so much Mark for this session you if you have more questions please you can meet Mark and then get to Deep dive um thank you so much let's give a hand of Applause Fork [Applause]