The Ethereum community is increasingly turning its attention to encrypted mempools as concerns about censorship and malicious MEV extraction grow. By hiding transaction contents until the transaction is guaranteed to be included, encrypted mempools can mitigate malicious forms of MEV like front-running and sandwich attacks.
Apart from malicious MEV protection, encrypted mempools are a valuable building block for several other infrastructure components: for instance, Vitalik mentions that encrypted mempools are an important foundation for designs such as FOCIL, multiple concurrent proposer schemes like BRAID, or attester-proposer separation.
A promising approach to establish an encrypted mempool is the use of threshold encryption, as implemented by the Shutter Network. It allows transactions to be encrypted by users and only decrypted collectively by a set of designated parties (Keypers) once it's safe to do so. That is, decryption is performed in a decentralized way, aligning closely with the ethos of web3, and current deployments such as the Shutter encrypted mempool on Gnosis Chain demonstrate the practical feasibility.
There’s Still Significant Room for Improvement
As cryptographic research evolves, more advanced cryptographic primitives are gaining increased attention, with the long-term vision for encrypted mempools often centered around powerful primitives like threshold fully homomorphic encryption (FHE) or secure multi-party computation (MPC). These primitives allow for computation on encrypted transactions, essentially allowing to capture “good” MEV opportunities on encrypted transactions. While an intriguing long-term vision, these primitives are not yet efficient enough for large-scale use in Web3 applications and there are more immediate challenges that threshold FHE and MPC cannot solve:
- Concerns about collusion: the security of any threshold encryption scheme is based on the assumption that a certain fraction of the Keypers (typically a majority) behaves honestly. If this assumption does not hold, transactions can be decrypted prematurely and front-run.
- Expensive setup and fixed Keyper set: the initial setup of the Keyper set, i.e., the set of parties that hold a share of the decryption key, requires the execution of a communication-heavy distributed key generation (DKG) protocol, which also makes it hard to reconfigure the set (e.g., add or remove Keypers) in the future.
- Increased latency: the decryption of transactions naturally adds latency which should be as minimal as possible for many DeFi applications.
Advanced Cryptography to Overcome These Limitations
The good news is that academic research has made significant progress on addressing those challenges in recent years. In this post, we highlight a selection of three advanced cryptographic primitives that, while less spoken about than threshold FHE or general-purpose MPC, offer immense value to encrypted mempools in the short to medium term. By focusing on deployable, targeted cryptographic tools, we aim to provide a realistic path forward for enhancing censorship resistance and MEV protection in decentralized systems.
1. Accountability in Threshold Encryption: Deterring Collusion through Advanced Cryptographic Primitives
A central criticism of threshold encryption in the context of encrypted mempools is its reliance on the threshold trust assumption. That is, the security of any threshold scheme hinges on the expectation that a sufficient fraction of Keypers behaves honestly. If this assumption is violated, colluding Keypers could prematurely decrypt transactions and front-run them.
To address this trust assumption, several recent academic works have come up with advanced primitives that allow to add some form of accountability to threshold schemes such that malicious collusion can be detected and punished.
Secret Sharing with Snitching (SSS): SSS is a primitive that was recently introduced by Dziembowski et al., which disincentivizes collusion in a set of parties that jointly hold the sharing of a secret value - as is the case for threshold encryption. Essentially, SSS provides a mechanism that, upon reconstruction of the shared secret, each involved party receives a proof of reconstruction. This proof can be used to prove to a third party that the secret was indeed reconstructed so that involved parties can get punished if reconstruction was performed illegally. This effectively disincentivizes collusion. For more details, see also our blog post on SSS.
A follow-up work by Bormet et al. introduces the notion of strong secret sharing with snitching, where colluding parties hedge their risk of being punished in case of an illegal reconstruction using insurance contracts that pay out if they are punished.
SSS is a promising direction to overcome the problem of collusion in threshold schemes. However, to date the existing constructions are not yet efficient enough and not designed for the case of threshold encryption.
Threshold Encryption via Self-Incriminating Proofs: Another direction is the notion of threshold encryption via self-incriminating proofs as introduced by Chiang et al. This approach is similar in spirit to SSS but focuses on the specific case of threshold encryption. That is, this notion guarantees that if a committee of parties in a threshold encryption scheme decrypts a ciphertext, at least one of the parties learns a self-incriminating proof, which can be used to publicly identify and punish the colluding parties.
Traceable Threshold Encryption: A third direction is traceable threshold encryption as introduced by Boneh et al. Here, a designated tracing key can be used to identify parties involved in an unauthorized decryption process with the limitation, however, that the tracing key must remain private to a trusted party (i.e., malicious parties must not know the tracing key). This initial work by Boneh et al. sparked several follow-up works (e.g., 1,2,3), most notably the recent paper by Canard et al., which overcomes the private tracing key limitation by allowing for public tracing, enabling scenarios where accountability is enforced automatically via smart contracts. For example, a smart contract could perform the tracing and penalize colluding Keypers on-chain when unauthorized decryption is detected.
2. Overcoming Fixed Keyper Sets and Costly Setups
A significant limitation of current threshold encrypted mempools is their static nature. When such a mempool is initially established, the participating Keypers must run a distributed key generation (DKG) - a communication-heavy protocol - to jointly generate an encryption key and decryption key shares. While this setup is performed only once, the drawback is that the resulting Keyper set is effectively fixed: adding or removing participants later requires running a similarly costly protocol.
A recent work by Garg et al. proposes an elegant solution to these issues through threshold encryption with silent setup. In this model, each Keyper independently generates its own encryption and decryption key pair and publishes a short piece of public metadata, called a hint. These hints can then be combined by anyone, without coordination, to derive a shared encryption public key for any subset of Keypers.
This approach has several compelling advantages:
- Keypers can join or leave without requiring a global re-run of the DKG.
- Encrypting users can flexibly choose the subset of Keypers they trust most. This can actually help with the issue of collusion, because the encrypting user can exclude Keypers that it does not trust or that are known to act maliciously.
- The encryption key is derived non-interactively, reducing setup complexity and network overhead.
A follow-up work by Hall-Andersen et al. presents a generic construction of threshold encryption with silent setup and proves the security of the construction in a stronger model than the one of Garg et al.
The above advantages make threshold encryption with silent setup particularly well-suited for use by Ethereum validators. Instead of participating in a costly DKG protocol, validators can simply use their existing keys and generate the corresponding hint. Users can then flexibly select any subset of validators (up to a certain size) as Keypers based on their own trust assumptions. This not only reduces setup complexity and overhead but also enhances decentralization and accountability by enabling users to exclude validators they consider untrustworthy or misbehaving.
3. Reducing Latency
DeFi applications are highly latency-sensitive, trading opportunities emerge and vanish in milliseconds. In such environments, minimizing latency is critical, and a significant portion of that latency stems from networking bottlenecks. One way to reduce latency is by minimizing the amount of data exchanged across the network. However, in traditional threshold encrypted mempools, each transaction must be decrypted individually. As a result, the volume of decryption data grows linearly with the number of encrypted transactions, which increases both bandwidth usage and latency.
An interesting alternative approach, used by Shutter, leverages identity-based threshold encryption, where Keypers can non-interactively derive one encryption and decryption key pair for each block. This allows the Keypers to publish a single decryption key per block, regardless of how many transactions it contains, making the decryption data size constant per block. The trade-off, however, is that even transactions that were encrypted for a specific block but ultimately not included in it can be decrypted once the block’s decryption key is published.
To address this limitation, Choudhuri et al. proposed the concept of batched threshold encryption. This approach allows all transactions included in a block to be decrypted with a single, compact piece of decryption information, while ensuring that transactions not included in the block remain encrypted. In essence, it captures the best of both worlds: constant-sized decryption data and confidentiality for excluded transactions. This significantly reduces bandwidth requirements and thereby improves latency.
Although current constructions of batched threshold encryption are not yet ready for production, the initial work by Choudhuri et al. has sparked several promising follow-ups (e.g., 1,2,3) and more practical and efficient constructions may be just around the corner.
A Promising Road Ahead for Threshold Encrypted Mempools
These recent cryptographic advances suggest a bright future for threshold encrypted mempools. While many of the discussed primitives, such as secret sharing with snitching, traceable threshold encryption, and batched threshold encryption, are still maturing and not yet production-ready, the rapid pace of research is encouraging.
What’s even more exciting is the potential to combine multiple of the above primitives. An example is the recent work by Bormet et al., which combines batched threshold encryption with a silent setup to reduce both communication overhead and setup complexity. This scheme provides a compelling medium-term vision for threshold encrypted mempools in Ethereum. Once efficient enough for practical use, the scheme by Bormet et al. could be deployed directly by Ethereum validators: essentially the validators could act as Keypers using their existing keys and publishing the corresponding hint. Users can then flexibly choose any subset of validators as their Keyper set, tailoring trust assumptions to their needs. At the same time, the batched decryption mechanism ensures that all encrypted transactions in a block (targeted to the same Keyper set) can be decrypted using a single, constant-sized decryption message, minimizing bandwidth and making the approach highly efficient for real-world deployment. Adding mechanisms to actively prevent or punish collusion, through mechanisms like secret sharing with snitching or traceable threshold encryption, is likely still a long way off and a rather long-term vision. However, the ability for users to freely select their Keyper set already provides a meaningful step toward mitigating trust issues.
So there’s plenty of reason for excitement: While FHE and MPC have received the most attention so far, they are just two among a variety of powerful cryptographic primitives worth paying attention to. With continued progress on accountability mechanisms, bandwidth optimizations, and composable protocols, threshold encryption is shaping up to be one of the most promising and practical building blocks for censorship-resistant, MEV-safe blockchain infrastructure.
