a16z: Why Is Encrypted Mempool a Hard Fit as a Silver Bullet for MEV?
TechFlow Selected TechFlow Selected
a16z: Why Is Encrypted Mempool a Hard Fit as a Silver Bullet for MEV?
Technology, economy, efficiency: three unavoidable mountains.
Navigating Web3 tides with focused insightsAuthors: Pranav Garimidi, Joseph Bonneau, Lioba Heimbach, a16z
Translation: Saoirse, Foresight News
In blockchains, Maximum Extractable Value (MEV) refers to the maximum value that can be extracted by deciding which transactions are included in a block, which are excluded, or by reordering transactions. MEV is prevalent across most blockchains and has been a widely discussed topic within the industry.
Note: This article assumes readers have a basic understanding of MEV. Some readers may wish to first read our introductory article on MEV.
When observing the phenomenon of MEV, many researchers have posed a clear question: Can cryptography solve this problem? One proposed solution is encrypted mempools: users broadcast encrypted transactions that are only decrypted and revealed after ordering. This forces the consensus protocol to "blindly" select transaction order, seemingly preventing profiteering from MEV opportunities during the ordering phase.
Unfortunately, from both practical and theoretical perspectives, encrypted mempools cannot provide a general solution to the MEV problem. This article outlines the key difficulties and explores feasible design directions for encrypted mempools.
How Encrypted Mempools Work
There are numerous proposals for encrypted mempools, but they generally follow this framework:
-
Users broadcast encrypted transactions.
-
The encrypted transactions are submitted on-chain (in some proposals, transactions must first undergo verifiable random shuffling).
-
Once the block containing these transactions is finalized, the transactions are decrypted.
-
Finally, the transactions are executed.
A critical issue arises in step 3 (transaction decryption): Who is responsible for decryption? What happens if decryption fails? A simple idea is to let users decrypt their own transactions (in which case encryption might not even be necessary—only hiding commitments). However, this approach has vulnerabilities: attackers could engage in speculative MEV.
In speculative MEV, an attacker guesses that an encrypted transaction contains an MEV opportunity, then encrypts their own transaction and attempts to insert it in a favorable position (e.g., before or after the target transaction). If the transaction order matches expectations, the attacker decrypts and extracts MEV via their transaction; if not, they refuse to decrypt, and their transaction is not included in the final blockchain.
Punishing users who fail to decrypt might seem viable, but implementing such a mechanism is extremely difficult. All encrypted transactions must face identical penalties (since they are indistinguishable when encrypted), and penalties must be severe enough to deter speculative MEV even against high-value targets. This would require locking up large amounts of capital, which must remain anonymous (to avoid leaking associations between transactions and users). Worse, genuine users unable to decrypt due to bugs or network failures would also suffer losses.
Therefore, most schemes suggest encrypting transactions in a way that ensures they will eventually be decryptable, even if the initiating user goes offline or refuses to cooperate. This goal can be achieved through several methods:
Trusted Execution Environments (TEEs): Users encrypt transactions to a key held securely within a Trusted Execution Environment (TEE). In basic versions, the TEE only decrypts transactions after a certain point in time (requiring internal time awareness). More complex designs involve the TEE decrypting transactions and constructing blocks, ordering them based on arrival time, fees, etc. Compared to other encrypted mempool schemes, TEEs offer the advantage of handling plaintext transactions directly, reducing on-chain redundancy by filtering out transactions that would revert. However, this method relies heavily on hardware trustworthiness.
Secret-sharing and threshold encryption: Here, users encrypt transactions to a key jointly held by a committee (typically a subset of validators). Decryption requires meeting a threshold condition (e.g., two-thirds of the committee agree).
With threshold decryption, trust shifts from hardware to the committee. Proponents argue that since most protocols already assume honest-majority validators in consensus, we can similarly assume most validators will remain honest and not prematurely decrypt transactions.
However, there's a crucial distinction: these two trust assumptions are not equivalent. Consensus failures like chain forks are publicly visible ("weak trust assumption"), whereas a malicious committee privately decrypting early leaves no public evidence—such attacks are undetectable and unpunishable ("strong trust assumption"). Thus, although consensus mechanisms and encrypted committees may appear to share similar security assumptions, in practice, the assumption that "the committee won't collude" is far less credible.
Time-lock and delay encryption: As an alternative to threshold encryption, delay encryption works by having users encrypt transactions to a public key whose corresponding private key is hidden within a time-lock puzzle. A time-lock puzzle is a cryptographic construct that encapsulates a secret, only revealing it after a preset duration—specifically, through repeated, non-parallelizable computations. Under this mechanism, anyone can solve the puzzle to retrieve the key and decrypt the transaction, but only after completing a deliberately slow (essentially serial) computation long enough to ensure transactions cannot be decrypted before finalization. The strongest form of this primitive uses publicly generated puzzles via delay encryption techniques; alternatively, trusted committees can approximate this using time-lock encryption, though its advantages over threshold encryption become debatable.
Whether using delay encryption or relying on trusted committees to perform computations, these schemes face significant practical challenges: First, because delays depend on computation, precise decryption timing is hard to guarantee; Second, these schemes require specific entities to run high-performance hardware to efficiently solve puzzles—though anyone can take on this role, incentives for participation remain unclear; Third, in such designs, all broadcast transactions get decrypted, including those never included in final blocks. Threshold-based (or witness-encryption-based) schemes could potentially decrypt only successfully included transactions.
Witness encryption: The most advanced cryptographic approach is "witness encryption." Theoretically, witness encryption allows data to be encrypted such that only someone possessing a "witness" to a specific NP relation can decrypt it. For example, information could be encrypted so that only someone solving a particular Sudoku puzzle or providing a preimage to a hash value can decrypt it.
(Note: An NP relation defines a correspondence between a "problem" and a "solution" that can be quickly verified.)
For any NP relation, similar logic can be implemented via SNARKs. Essentially, witness encryption encrypts data so that only entities capable of generating a SNARK proof satisfying certain conditions can decrypt it. In the context of encrypted mempools, a typical condition would be: transactions can only be decrypted after block finalization.
This is a highly promising theoretical primitive. Indeed, it's a general-purpose scheme—threshold-based and delay-based approaches are merely special cases. Unfortunately, no practical witness-encryption schemes currently exist. Even if they did, it's questionable whether they'd offer advantages over committee-based approaches in proof-of-stake chains. Even if witness encryption is set so that decryption only occurs after finalization, a malicious committee could still privately simulate the consensus protocol to forge finality status and use this private chain as a "witness" to decrypt transactions. In such cases, using threshold decryption by the same committee achieves equivalent security with far simpler operations.
However, in proof-of-work consensus protocols, the advantages of witness encryption are more pronounced. Even if the entire committee is malicious, they cannot privately mine multiple new blocks off the current chain head to forge finality.
Technical Challenges Facing Encrypted Mempools
Multiple practical challenges limit the ability of encrypted mempools to prevent MEV. Overall, information confidentiality itself is difficult. Notably, while cryptography is not widely used in Web3, decades of deploying encryption in networks (like TLS/HTTPS) and private communications (from PGP to modern encrypted messaging platforms like Signal and WhatsApp) have clearly exposed its difficulties: encryption protects confidentiality, but cannot guarantee absolute security.
First, certain parties may directly access plaintext versions of user transactions. Typically, users do not encrypt transactions themselves but delegate this task to wallet providers. As a result, wallet providers gain access to transaction plaintexts and might exploit or sell this information to extract MEV. Encryption security always depends on all parties holding keys. The scope of key control defines the boundary of security.
Beyond this, the biggest issue lies in metadata—the unencrypted data surrounding encrypted payloads (transactions). Searchers can use metadata to infer transaction intent and conduct speculative MEV. Importantly, searchers don’t need full comprehension of transaction content or perfect accuracy—they only need reasonable probability. For instance, being able to guess with decent likelihood that a transaction is a buy order on a specific decentralized exchange (DEX) is sufficient to launch an attack.
We can categorize metadata into two types: classical problems inherent to cryptography, and issues unique to encrypted mempools.
-
Transaction size: Encryption cannot hide the size of the plaintext (note that formal definitions of semantic security explicitly exclude size concealment). This is a well-known attack vector in encrypted communications—for example, eavesdroppers can determine what’s playing on Netflix by analyzing packet sizes in an encrypted video stream. In encrypted mempools, specific transaction types may have distinctive sizes, leaking information.
-
Timing of broadcast: Encryption also cannot hide timing information (another classic attack vector). In Web3 scenarios, certain senders (e.g., structured sell-offs) may send transactions at fixed intervals. Timing may correlate with external events, such as activity on centralized exchanges or news. A subtler use of timing involves arbitrage between centralized exchanges (CEXs) and decentralized exchanges (DEXs): block proposers can insert transactions created as late as possible to leverage the latest CEX prices, while excluding all other (even encrypted) transactions broadcast after a certain time, ensuring their transaction enjoys exclusive access to the newest price.
-
Source IP address: Searchers can monitor peer-to-peer networks and trace source IP addresses to infer sender identities. This issue was identified in Bitcoin’s early days (over ten years ago). If a sender exhibits consistent behavior patterns, this is highly valuable to searchers—for example, knowing the sender enables linking encrypted transactions to previously decrypted historical ones.
-
Transaction sender and fee/gas information: Fee data represents a mempool-specific metadata type. On Ethereum, traditional transactions include the on-chain sender address (used to pay fees), maximum gas budget, and the per-unit gas fee the sender is willing to pay. Like source network addresses, sender addresses can link multiple transactions to real-world entities; gas budgets may hint at transaction intent. For instance, interacting with a specific DEX may require a recognizable, fixed amount of gas.
Sophisticated searchers may combine multiple types of such metadata to predict transaction content.
Theoretically, all this information can be hidden—but at the cost of performance and complexity. For example, padding transactions to standard lengths hides size but wastes bandwidth and on-chain space; adding delays before sending hides timing but increases latency; submitting transactions via anonymous networks like Tor hides IP addresses but introduces new challenges.
The hardest metadata to hide is fee information. Encrypting fee data creates several problems for block builders: First, the spam problem—anyone could broadcast malformed encrypted transactions that appear valid but cannot pay fees. These transactions would be ordered but fail upon decryption, with no accountability. This might be addressed via SNARKs proving correct formatting and sufficient funds, but at greatly increased overhead.
Second, efficiency in block construction and fee auctions. Builders rely on fee data to create profit-maximizing blocks and determine current market prices for on-chain resources. Encrypting fee data disrupts this process. One solution is setting fixed fees per block, but this is economically inefficient and could spawn secondary markets for transaction inclusion, undermining the purpose of encrypted mempools. Another option is conducting fee auctions via secure multi-party computation or trusted hardware—both extremely costly.
Finally, secure encrypted mempools increase system overhead in multiple ways: encryption adds latency, computational load, and bandwidth usage; integration with important future goals like sharding or parallel execution remains unclear; new liveness failure points may emerge (e.g., decryption committees in threshold schemes, solvers of delay functions); and design and implementation complexity rises significantly.
Many challenges faced by encrypted mempools mirror those encountered by privacy-focused blockchains like Zcash and Monero. If there's an upside, it's that overcoming all cryptographic challenges in MEV mitigation would simultaneously advance transaction privacy.
Economic Challenges Facing Encrypted Mempools
Finally, encrypted mempools face economic challenges. Unlike technical hurdles, which may be gradually mitigated with sufficient engineering effort, these economic constraints represent fundamental limitations that are extremely difficult to overcome.
The core issue of MEV stems from information asymmetry between transaction creators (users) and MEV extractors (searchers and block builders). Users typically don't know how much extractable value their transactions contain. Therefore, even with a perfect encrypted mempool, they could still be incentivized to reveal decryption keys in exchange for payments below the actual MEV value—a phenomenon called "incentivized decryption."
This scenario is not hard to imagine, as similar mechanisms like MEV Share already exist. MEV Share is an order flow auction mechanism allowing users to selectively submit transaction details to a pool, where searchers compete for the right to exploit MEV opportunities in those transactions. Winners extract MEV and return a portion of profits (the bid amount or a percentage) to the user.
This model could easily adapt to encrypted mempools: users would need to disclose decryption keys (or partial information) to participate. Yet most users fail to recognize the opportunity cost—seeing only immediate rewards, they readily leak information. Similar cases exist in traditional finance: zero-commission trading platforms like Robinhood profit precisely by selling user order flow to third parties through "payment for order flow."
Another possible scenario involves large builders forcing users to disclose transaction content (or related information) under threat of censorship. Censorship resistance is an important yet controversial topic in Web3. But if major validators or builders are legally required (e.g., by OFAC regulations) to enforce censorship lists, they may refuse to process any encrypted transactions. Technically, users might use zero-knowledge proofs to demonstrate their encrypted transactions comply with censorship rules, but this adds cost and complexity. Even if a blockchain ensures strong censorship resistance (guaranteeing encrypted transactions will be included), builders might still prioritize known plaintext transactions at the front of blocks, relegating encrypted ones to the end. Consequently, transactions requiring guaranteed execution priority may ultimately be forced to disclose content to builders.
Other Efficiency Challenges
Encrypted mempools increase system overhead in several obvious ways. Users must encrypt transactions, and the system must decrypt them somehow—adding computational costs and potentially increasing transaction size. As noted earlier, handling metadata further amplifies these overheads. Yet some efficiency costs are less apparent. In finance, markets are considered efficient when prices reflect all available information; delays and information asymmetries cause inefficiency. This is exactly the outcome encrypted mempools inevitably produce.
This inefficiency leads directly to increased price uncertainty—an inevitable consequence of added latency from encryption. As a result, more transactions may fail due to exceeding slippage tolerance, wasting on-chain space.
Likewise, this price uncertainty may fuel speculative MEV transactions attempting to profit from on-chain arbitrage. Notably, encrypted mempools may make such opportunities more common: execution delays make the current state of DEXs more ambiguous, likely reducing market efficiency and creating price discrepancies across platforms. Such speculative MEV transactions also waste block space, as they often abort execution when no arbitrage opportunity is found.
Conclusion
This article aims to outline the challenges facing encrypted mempools, encouraging focus on developing alternative solutions—though encrypted mempools may still play a role in MEV governance.
A viable approach could be hybrid designs: some transactions undergo "blind ordering" via encrypted mempools, while others use different ordering mechanisms. For certain transaction types (e.g., large market participants’ buy/sell orders, who can carefully encrypt or pad transactions and are willing to pay higher costs to avoid MEV), hybrid designs may be suitable. They also hold practical value for highly sensitive transactions (e.g., patching vulnerable smart contracts).
However, due to technical limitations, high engineering complexity, and performance overhead, encrypted mempools are unlikely to become the hoped-for "silver bullet" solution for MEV. The community needs to develop other approaches, including MEV auctions, application-layer defenses, and reducing finalization times. MEV will remain a challenge for the foreseeable future, requiring deep research to balance various solutions and mitigate its negative impacts.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
a16z
