Encrypted Mempool

What is an encrypted mempool, and how does it differ from the private transaction pool discussed earlier in this series?

When this series broke down the sandwich attack, it mentioned that private transaction pools (infrastructure like Flashbots) reduce attack risk by keeping transactions out of the public mempool everyone can see, communicating directly and privately with a specific block builder instead. But this approach has a structural limit: the transaction's contents are still visible to this specific block builder — you've only narrowed the range of who can see it from everyone down to a handful of builders, and the trust foundation shifts to "these builders won't abuse what they see," rather than eliminating the fact that someone can see the transaction's contents at all.

An encrypted mempool is designed to close exactly this remaining trust gap: through threshold encryption, a transaction's contents stay encrypted and unreadable to every participant — builders, validators, everyone — until its order has been determined; only after that order is irreversibly fixed does it get decrypted and actually executed. This means at no point during the entire ordering process can any party see in advance what this transaction is trying to do, structurally eliminating the information asymmetry that front-running and sandwich attacks depend on to exist.

Why is an encrypted mempool considered a more advanced solution than a private transaction pool, and what problem does it solve that private transaction pools can't?

While private transaction pools reduce the risk of ordinary users getting front-run by searchers in the public mempool, they simultaneously create a new form of trust concentration — if most transactions move to a handful of private transaction pools, those few builders effectively gain significant influence over ordering across the entire network. If those builders themselves choose to abuse what they see (using the transaction content for their own arbitrage, say), users find it even harder to notice, precisely because the transaction never appears in a publicly queryable mempool record in the first place. This is exactly why private transaction pools, while solving the "public exposure" problem, simultaneously introduce a new concern of "more concentrated ordering power."

An encrypted mempool's design goal is to solve both problems at once: keeping transaction content invisible to everyone (including builders) before ordering completes, without sacrificing the decentralized ordering mechanism a blockchain should inherently have. This theoretically means users can get protection similar to (or even more thorough than) a private transaction pool without needing to rely on the trust assumption of "believing a specific builder won't act maliciously."

暗号化メモリプールは実際どのように機能し、閾値暗号化というメカニズムの技術的な原理は何ですか？

閾値暗号化（threshold encryption）の基本的な考え方は次の通りである：あるメッセージが暗号化された後、それを復号するには一定数（例えばバリデーターグループの3分の2）の独立した鍵保有者が共同で参加する必要があり、この閾値に満たないサブセットは単独では内容を復号できない。これを暗号化メモリプールのシナリオに応用すると、ユーザーが取引を送信する際、取引内容はまずこの閾値暗号化方式で暗号化される。この暗号化された取引はネットワーク上で正常に伝播し、順序付けの検討対象に含めることができるが、どの単一のバリデーターも事前にそれを復号して実際に何が書かれているかを見ることはできない。

この取引がブロック内の位置と順序が確定し、もはや変更できなくなった後に初めて、復号プロセスがトリガーされる——十分な数のバリデーターがそれぞれ自分の保有する鍵の一部を提供し、共同で完全な復号鍵を組み立て、それによって初めて取引内容が実際に開示され実行される。この「先に順序を確定し、後で内容を復号する」という順序の逆転こそが、暗号化メモリプールが根本的にフロントランニングを阻止できる技術的な核心である：攻撃者はまだ内容を見ることすらできない取引をフロントランする方法がない。

暗号化メモリプールは一般ユーザーにどのような実際の影響を与えますか？この技術は現在どの発展段階にありますか？

もしあなたが使用しているDeFAI製品が将来的に暗号化メモリプールを基盤とした実行環境を採用すれば、サンドイッチ攻撃などのMEV搾取手法に対するあなたのエクスポージャーは、理論上現在プライベートトランザクションプールに依存している方式よりも低くなる。なぜなら攻撃者は「あなたが何を取引しようとしているかを知る」という最も基本的な前提すら得られないからだ。これは大口のswapを頻繁に実行するユーザーや、スリッページ許容度が緩めの戦略を使うユーザーにとって、比較的顕著な保護のアップグレードとなるだろう。

しかしこの技術は現在まだ比較的初期の発展・実験段階にあり、実務上注意すべき点がある：閾値暗号化メカニズム自体の実装が十分な監査を受けているか（暗号化と復号ロジックの複雑さ自体が新たな技術的リスクをもたらす可能性がある）、復号に必要なバリデーターの参加度合いが十分に分散化されているか（閾値の設計が不適切であれば、理論上依然として少数の結託したバリデーターによって事前に復号される可能性がある）、そしてこのメカニズムが実際のネットワーク混雑状況下で取引の遅延にどう影響するかである。暗号化メモリプールの使用を謳うどのDeFAI製品を評価する際も、「暗号化メモリプールがある」という言葉だけでリスクが完全に解決されたと想定すべきではなく、依然として本シリーズで前述した信頼最小化フレームワークを用いて、このメカニズムの実際の分散化度合いと監査状況を個別に確認する必要がある。