Context
As part of our current effort to develop better encrypted mempools and explore programmable cryptography, we have developed a series of prototypes that implement a simple scenario where a searcher attempts to backrun a user transaction for profit.
This setting closely resembles that of the MEV-share product offered by Flashbots, with the distinction that we provide concrete security guarantees in the present setting.
Most encrypted mempool solutions building on software cryptography aim to completely prevent MEV extraction, which is sub-optimal from an economic standpoint. On the other end of the spectrum, Flashbots has proposed TEE-based solutions to offer confidentiality guarantees while enabling extraction and redistribution to its users.
While acknowledging software cryptography cannot meet the same level of performance as TEEs today, this line of work explores the different ways to narrow the gap between hardware and software alternatives, by exploring the possibilities of today's technology when applied to MEV applications, and ideally propose new protocols. The goal of this project is to produce carefully evaluated protocols along with the elements that a production deployment would require (threshold decryption, ...) to evaluate how practical it is to introduce pure software alternatives to TEEs as part of our offerings.
Current workflow
We operate under the following assumptions: transactions are hidden, via encryption or secret sharing, but the individual fields should remain processable.
There are three main types of actors in this scenario:
- Searchers, who have the ability to locally process encrypted transactions (can assume complex setups and access to advanced hardware acceleration)
- Users, who have the ability to generate and encrypt valid transactions via a dedicated piece of software or directly from their wallet, and transmit these encrypted transactions to the searchers directly or via an encrypted mempool
- Block builders, who are assumed honest as services operated from within a TEE, and have the ability to decrypt the resulting bundles received from searchers
Requirements
MEV backruns are latency-sensitive, thus optimising for speed is critical to reach realistic proposals likely to be adopted.
Security is surprisingly more flexible, since the worst-case scenario for user transactions is to revert back to the public mempool. We do not need to maintain a hidden state secure over a long period.
Open problems
Verifiable FHE
One of FHE's main downside is that it doesn't natively defend against malicious adversaries who would not run the expected circuit. This problem boils down to producing a proof of correct execution of an FHE circuit. It has received a lot of attention recently [ABPS24, CCCF+25], with proposals leveraging lattice-based SNARKs, for instance, but the performance overhead remains very significant.
We are currently exploring this direction in FRP #45
Faster prototypes
Now that we have baselines, we can iterate on these implementations to push the limits of the technology as far as possible. There remain multiple low-hanging fruits under both FHE and MPC settings before we can more accurately estimate the potential of existing methods without having to innovate on the cryptography itself.
For the MPC setting, a bespoke re-implementation outside of MP-SPDZ could unlock another level of performance. Similarly, the FHE prototype is based on TFHE, which is not ideal for arithmetic computations due to its heavy reliance on bootstrapping to perform any non-linear operation. Evaluating schemes such as BFV or CKKS would almost certainly improve the performance of the arithmetic phase, but would need to be connected to the transaction parsing logic relying on encrypted comparisons.
Searcher programmability and side channels
The MPC prototype showcases a minimal programming language enabling searchers to customise strategies to execute against private input transactions.
FHE could also be enhanced with programmability using approaches such as an 8-bit processor, which are very promising designs for being translated to physical hardware.
Current implementations disclose which fields of the transactions are accessed by the FHE/MPC circuit since indices are not encrypted. There is evidence in the literature that memory access patterns can be leveraged as side channels to leak some information about a task otherwise computed under FHE guarantees. Studying mitigations to this current challenge will prove relevant in the context of offering more programmability to searchers without breaking users' privacy expectations.
