原文
A Criticism of LUCID and Encryption-Scheme-Agnostic Encrypted Mempool Designs — GottfriedHerold (2026-06-16)
LUCIDと暗号スキーム非依存の暗号化メムプール設計に対する批判
本文書の目的と免責事項
EIP（Ethereum 改善提案）-8184 (LUCID) は、最近提案された暗号化メムプール設計です。暗号化メムプールは、ユーザーをMEV（最大抽出可能価値）の悪質な形態（例えば、フロントランニング (frontrunning) やサンドウィッチ攻撃 (sandwiching)）から保護し、ユーザーが直面する非常に現実的な問題を解決することを目的としています。残念ながら、安全な暗号化メムプールを設計することは困難な問題であり、「理想的なバージョン」には、十分な閾値暗号 (threshold encryption) のような、我々が（まだ？）持っていない暗号ツールが必要です。 LUCIDは、この十分な閾値暗号の欠如を考慮し、可能な限り最良のスキームを提供することを明確な目的として書かれましたが、これには深刻な欠点と限界が伴います。
この投稿では、これらの欠点と限界、およびLUCIDがそれらを軽減するために使用する対策の落とし穴を含め、それらを収集し文書化します。目標は、LUCIDの負の側面を一箇所に集め、アクセスしやすく、理解しやすい参照文書とすることです。対象読者は以下の通りです。
- 暗号化メムプールについてさらに研究を進め、ここで提示された欠点を軽減しようとしている人々。
- 最終的にEIPプロセスの一部としてLUCIDを含めるかどうかを決定する必要があるコア開発者。
- LUCIDの「詳細」を知りたい潜在的なユーザー。
以下に述べるLUCIDの最も重要な限界は、最終的には十分な暗号技術の欠如に起因しており、LUCID EIP自体でも認められていることを強調したいと思います。特に、最大の弱点は、トランザクション送信者による開示の任意性です。我々は、十分な暗号ツールが不足している限り、いかなる暗号化メムプール設計もこの問題を抱えるだろうと信じています[1]。
免責事項
著者は、ここに集められた批判点が新しいものであるとは主張しません。前述の通り、いくつかの問題はEIP自体でも認められています。
また、ここで提起された批判は（意図的に）非常に否定的に聞こえますが、著者はLUCID EIPを含めることについて（簡単なバグ修正/明確化の後であれば）強い賛成または反対の意見を持っていません。暗号技術の現状を考えると、LUCIDスタイルの設計は今のところ最善の策である可能性があり、暗号化メムプールのユースケースは非常に強力です。しかし、このような困難な決定を下す際には、欠点について十分に情報を持っていることが重要であると信じています。現実的には、今のところ（何らかのLUCIDの変種か）何もないかのどちらかです。
LUCIDとは何か？
LUCIDは、暗号化メムプール設計のためのEIPです。ユーザーがトランザクション tx（例えば、ETH → USDCのスワップ）を公開メムプール (Mempool)に送信し、それが含まれるまで他の誰もそのトランザクションの内容を見ることができないようにすることを目指しています[2]。これにより、スワップのフロントランニングのような、特定の有害なMEVの形態が排除されます。
LUCIDがどのように機能するかについて、簡潔で高レベルな（そしていくぶん単純化された — 特に、バンドルはほとんど省略します）概要を説明します。詳細についてはEIPを参照してください。ここでの説明は、焦点が異なるため、EIPで与えられているものとはかなり異なります。
LUCIDでは、ユーザーはまず tx へのコミットメントのみをメムプール (Mempool)に送信し、スロットnに含まれるトランザクションチケットを購入します。トランザクションチケットを購入するということは、ユーザーがプロトコルルールを遵守する限り、コミットされたトランザクションが所定の時点に含まれるという保証を得ることを意味します。スロットnのブロックペイロードが確定し、トランザクションチケットが含まれた後、ユーザーはコミットメントを開示し、tx を公開します。その後、公開されたすべてのLUCIDトランザクションは、スロットnとスロットn+1の間で事前定義された順序で実行されます。正式には、LUCIDは次のスロットn+1のビルダーに対し、正しく公開されたすべてのトランザクションをブロックの先頭に含めることを強制します。しかし、我々の議論では、公開されたLUCIDトランザクションがスロット間で実行されると考える方がより役立ちます。
ここでの暗号化はどこにあるのか？
上記の記述では、コミットメントのみで暗号化については言及されていないことに、鋭い読者は気づいたかもしれません。これは、LUCIDが実際には暗号化メムプールではないためです。少なくとも文献で一般的に理解されている意味ではそうではありません。むしろ、コミット・アンド・リビールスキーム (commit-and-reveal scheme) を介してそれらの目標を達成しようとします。LUCIDは、以下の方法でのみ暗号化を使用します。
txにコミットして後で公開する代わりに、LUCIDはtxの暗号化を公開し、それを復号する短い鍵にコミットし（そして後で公開し）ます。これには、通信の大部分を早い時点に移動させ、レイテンシが重要な公開のために小さなメッセージだけを残すという大きな利点があります。これは、メッセージ長のメタデータが早く漏洩するという小さなコストを伴います。しかし、この最適化は本投稿の議論には影響しないため、より単純なバージョンを考えます。- プロトコルは、公開メッセージがどこから来るかを実際には気にせず、LUCIDは公開を委任するための初歩的なサポートを追加します。これは、ユーザーが外部の当事者を指定し、その対価を支払うというものです。ユーザーがこの外部の当事者に実際にそうさせる方法はプロトコル外です。それは両方向での何らかの信頼関係を伴うか、または実際の暗号化を伴う可能性があります。例えば、ユーザーは委員会に対して閾値暗号化 (threshold encryption) を行うかもしれません。
トランザクション送信者による開示の任意性
コミット・アンド・リビールスキーム (commit-and-reveal scheme) に内在する大きな問題（そして、前述の通り、まだ持っていない暗号ツールなしではいかなる解決策にも内在する可能性が高い問題）は、送信者が単に開示しないことを選択できることです。さらに悪いことに、他の当事者の開示を見た後で開示するかどうかを選択できる可能性があります。具体的には、いくつかの攻撃シナリオがこの問題を例示しています。
確率的フロントランニング
正直なユーザーのコミットされたトランザクション tx について確かな推測を持っている（例えば、DEXでの一般的なペア間の取引）が、確信がない攻撃者は、tx の直前にフロントランニングトランザクション tx_attack を挿入するかもしれません。この際、tx と tx_attack の両方がLUCIDを使用します。tx が公開された後、攻撃者は推測が正しければ tx_attack を公開し、そうでなければ公開しません。攻撃者は、2^k通りの公開または非公開の組み合わせに対応するk個の先行トランザクションを挿入することも可能です。
レイテンシに敏感なトランザクション
LUCIDは、スロットnとスロットn+1の間にトランザクションが実行される新しいフェーズを効果的に作成するため、レイテンシに敏感なユースケースがLUCIDを使用し、その任意性を悪用する強いインセンティブがあります。CEX-DEX裁定取引 (CEX-DEX arbitrage) を考えてみましょう。裁定取引者は、時刻t_1でCEX-DEX裁定取引を実行するLUCIDトランザクションにコミットし、その後、t_1とt_2の間の価格変動に応じて、時刻t_2でそれを公開するかどうかを決定するかもしれません。ここでt_1は、スロットn-1中にスロットnのためにトランザクションを送信できる最新の時刻であり、t_2は公開が可能な最新の時刻です（トランザクションがスロットnとスロットn+1の間で実行されるため）。LUCIDは、t_2にCEX-DEXの価格差を解消する機会を実質的に追加します（LUCID以前は、次のタイムスタンプはスロットn+1のウィンドウが閉じる時でした）。裁定取引者は、このタイムスタンプを使用し、複数の潜在的な価格変動を考慮するために任意性を使用する経済的インセンティブがあります。この種の任意性は、経済的な観点からは実際には悪いことではありません。より速い価格シグナルがチェーンに入力されることを可能にし、非公開に対する手数料はMEVを燃焼させます。問題は、意図されたルールを遵守しない（公開しない）方法でLUCIDを使用するインセンティブがあり、それが他のユースケースと競合し、価格を押し上げることです。
対策
LUCIDはいくつかの対策を提供していますが、これらは任意性に関連する問題を完全に防ぐものではなく、任意性を悪用するコストを高くするだけです。特に、LUCIDは非公開に対してペナルティを適用し、各トランザクション（またはバンドル）が先行するLUCIDトランザクション（またはバンドル）の数を制限することを許可します。問題は、これらの対策が攻撃を防ぐものではなく、単に攻撃を困難にするだけであり、それが不十分である可能性があることです。確率的フロントランニングの場合、問題の一つは、正当な送信者が攻撃者を阻止するために十分に高いトップオブブロック手数料を支払い（そして、短期間その128倍の金額をエスクローする）、それを望まない可能性があることです。また、必要な抑止力は、攻撃者の視点から見た攻撃対象トランザクションのプレーンテキストに関する不確実性に依存しますが、これは正当なユーザーが推定するのが困難です。先行トランザクションの制限は、スワップのような通常のユースケースでLUCIDが多用される場合にはうまくスケールしません。特に、前述のレイテンシに敏感なトランザクションがLUCIDトランザクションリストのトップスポットを競合するためです。バンドル（わずかに優れた通信効率のために複数のトランザクションを収集する機能）は抑止力を集約しますが、それはあまり役立たないかもしれません。バンドルは攻撃する価値が高い可能性があります。なぜなら、特定の取引ペアがその中に存在する可能性が高いため、確率的攻撃の成功確率も高くなるからです。さらに、バンドルの構成トランザクションが異なる送信者に属する場合、バンドルの集約されたトップオブブロック手数料を設定する際にフリーローディングの問題が発生する可能性があります。
ビルダーの任意性
LUCIDの設計は、スロットn+1のビルダーに対し、スロットn中に公開されたトランザクションをブロックの先頭に含めることを強制することを意図しています。これは、ペイロード適時性委員会 (PTC)を介して強制されます。PTCはこれらの公開の利用可能性について投票します。大まかに言えば、委員会の50%以上が公開を時間内に見たと投票した場合、ビルダーはそれを含めなければならず、50%以上が見なかったと投票した場合、ビルダーはそれを含めてはなりません。問題は、遅れて到着する公開や、二重署名（equivocation）された投票に対して、ある程度の裁量があることです。実際、攻撃者が投票を45%/45%に分割し、残りの10%を二重署名した場合、次のビルダーは含めるか含めないかを選択でき、それによって（別のインスタンスの）任意性を獲得します。これは、後で選択を行うことでCEX-DEX裁定取引 (CEX-DEX arbitrage) からの利益を増幅するために使用できます。実際、裁定取引者は可能な限り遅く決定するインセンティブがあるため、これらの公開はとにかく50%に近い分割になる可能性が高いです。その結果、次のスロットのビルダーになる可能性のあるPTC委員は、手数料のために二重署名（equivocation）し、裁定取引者と協力するインセンティブを実際に持ちます。これは、トランザクションを遅れて公開しても、確率的フロントランニング攻撃から保護されない可能性があることも意味します。
注：二重署名（equivocation）はペナルティの対象ではありません。この設計部分はFOCIL (強制オンチェーンインクルージョンリスト)から採用されたものであり、FOCILのセキュリティ目標は、同じ方法で二重署名（equivocation）によって脅かされることはありません。検閲耐性を強化することを目的とするFOCILでは、広く利用可能になったトランザクションが実際に含まれることを保証するだけで十分です。そこでは、その逆（つまり、広く利用可能にならなかったトランザクションが含まれないこと）についてはあまり気にしません。LUCIDの場合、ビルダーの任意性に関連するため、この逆の方向についても気にする必要があります。
UXの問題
送信者メタデータ
LUCIDにおけるコミットされたトランザクションは、実際のトランザクションを実行するアドレスと同じアドレスから来る必要はありません。実際、送信者メタデータの漏洩を防ぐために、コミットされたトランザクションがリンク不可能なアドレスから来ることを望んでいます。確率的フロントランニングの問題を考えると、特定のLUCIDトランザクションがどのユーザーに属するかを漏洩することは致命的です。なぜなら、それはフロントランナーにトランザクションの内容が何であるか、そして攻撃する価値があるかどうかについて非常に良いアイデアを与えるからです。これにより、LUCIDを正しく使用することが困難になります。ユーザーは、プライバシープールを介して、十分な時間遅延を伴って、ガス代のための資金を使い捨てのアドレスに送るか、またはオフチェーンで支払う第三者リレーを介してトランザクションを入力させる必要があります。後者の典型的なシナリオは、CEX上の残高を使用して、CEXにコミットされたトランザクションを代理で送信させることです。第三者はトランザクションのプレーンテキストを知る必要はありませんが、これは他の当事者を必要とせず、公開メムプール (Mempool)を持つという目標とは多少矛盾します。第三者はあなたのトランザクションをあなたにリンクすることで、あなたを売り渡すことができることに注意してください。 理想的な解決策は、本質的に、十分に強力なアカウント抽象化の何らかの形式を使用して、プライバシープールから直接支払うことを可能にすることです。これにより、各トランザクションごとに新しいアドレスを作成する必要がなくなります。
オプションが多すぎる – ウォレットに任せるべきか？
LUCIDを正しく使用するには、ユーザーは何らかのリンク不可能なアドレスを必要とします。確率的フロントランニングに対する対策として、ユーザーはそれに応じて優先手数料を設定し（LUCIDトランザクションのトップになるため）、および/または先行トランザクションの数を制限する必要があります。ユーザーはまた、公開を委任するか、自分で実行するかを選択する必要があります。通常のユーザーがこれらすべてを実行できるとは到底思えません。
その結果、ウォレットが良くも悪くもユーザーのためにこれらの決定を下すことになるでしょう。公開の委任の場合、ウォレットがユーザーに最善の選択肢をデフォルト設定するのではなく、それ自体を資金調達の機会として扱う深刻なリスクがあります。ウォレット開発者は、自身で公開サービスを運営する（または誰かから報酬を受け取る）可能性があり、ユーザーにとって最善の選択肢ではない場合でも、それを使用することをデフォルト設定し、手数料を徴収するかもしれません。優先手数料と先行トランザクションの制限については、ウォレットが努力したとしてもこれらを正しく設定できるかは疑問です。
暗号学的不可知論 / 柔軟性
LUCIDのセールスポイントの一つは、特定の種類の暗号化メカニズムに依存しないこと、そしてこれがオフチェーンで行われることです。これは、具体的な暗号学的（閾値）暗号化スキームを実装する必要がないという意味では確かに良いことですが、いくつかの理由から悪いアイデアのように感じられます。
なぜそもそも委任するのか？
ユーザーがなぜ公開を委任したいのかは不明です。唯一の本当の利点は、公開が多少レイテンシに敏感であり、第三者がそれをより良く処理できるかもしれないということですが、これは追加の信頼仮定を正当化するものではなく、我々は信頼できるリレーを排除したいと考えています。さらに、その当事者が閾値暗号化 (threshold encryption) を実行し、委員会を介して復号する場合、これはかなりのレイテンシを追加し、目的をある程度損ないます。委任が実際に良い選択肢である説得力のあるユースケースがなければ（そして「ウォレットへの資金提供」は説得力のあるものではありません）、これはあまり説得力がありません。UX（ユーザーエクスペリエンス）の観点からは、委任はファイア・アンド・フォーゲット型のトランザクション送信を可能にしますが、ほとんどのユーザーはとにかく含まれるまでチェーンを監視したいと考えています。そして、これは第三者を信頼することなく、ウォレットによる後からの公開も可能にします。
悪意のある者にとっての暗号学的俊敏性
一般的に言えば、暗号学的柔軟性は、情報に通じたユーザーが自分のユースケースと必要なセキュリティにとって最善の選択をすることを可能にするならば良いことです。しかし、敵対者がスキームを選択する場合、それは悪いことです。我々はここで後者のケースにいます。敵対者（例えば、確率的フロントランニングトランザクションを送信する者）は、単に暗号化を全く使用せず、自己公開する（またはしない）ことを選択するでしょう。
設計はどの程度将来性があるか？
一つの希望は、LUCIDを今デプロイし、後で特定の閾値スキームを組み込み、ユーザーに自己公開ではなくそれを使用することを強制すること（それによって任意性を排除すること）かもしれません。これにはいくつかの問題があります。
- 既存の委任オプションを非推奨にする必要があり、それらはその時までに既得権益 (vested economic interests) となっているでしょう。
- LUCIDはそのような設計にはうまく適合しない可能性があります。LUCIDが期待する公開メッセージは、個々のプレーンテキスト（または、以前に送信された特定の暗号文をプレーンテキストトランザクションに復号するトランザクション固有の鍵）です。これは、単一の鍵kが複数の暗号文を復号する可能性のある将来の閾値暗号化スキームとはうまく適合しません。これをLUCIDに組み込んだ場合、kを配布することはできず、代わりに各暗号文にkを個別に適用した結果を配布する必要があり、これは無駄です。
- 暗号化メムプール (Mempool)の設計を基盤となる暗号メカニズムに適応させる必要があるかもしれません。例えば、著者は現在、LUCIDのアイデアの一部を使用して、いわゆるバッチ処理なしで閾値IDベース暗号 (IBE) から優れた暗号化メムプール設計を構築できるかどうかを調査しています。（これは進行中の作業であり、いずれにせよ、すぐに良い代替スキームが得られるわけではありませんが、暗号側の要件を少し減らすだけです。）このような設計は、暗号化スキームの制限に適合させるために暗号化メムプールに変更を必要とし、LUCIDに単純に組み込むことはできません。
最後の点についてもう少し詳しく説明すると、LUCID内で指定された組み込み閾値スキームをユーザーに強制するだけでは、トランザクション送信者による任意性しか解決できません。前述のビルダーの任意性問題には役立ちません。実際、LUCIDに強く触発された著者の進行中の設計では、ビルダーの任意性を防ぐために、どの公開（または暗号化）が広く利用可能になったかについて合意に達するために、コンセンサスプロトコルの追加ラウンドを実行する必要があります。さらに、追加ラウンドは、リオーグ（reorg）や欠落したスロットをまたぐリプレイ攻撃に関して、より慎重な検討が必要であることを意味します。 LUCIDの場合、このような追加ラウンドを実行することは、複雑さとUX（ユーザーエクスペリエンス）の観点から見て、正当化するにはコストが高すぎる可能性が高いことを明確にしたいと思います。ビルダーの任意性問題は、送信者の任意性問題と比較してわずかな追加に過ぎません。しかし、送信者の任意性問題を取り除くことができれば、この状況は変わります。
誤解を招く情報
最後に、LUCID（または暗号化メムプール全般）がどのように伝えられるかについても、非常に注意する必要があります。前述の通り、LUCIDを正しく使用することは困難であり、フロントランニングを防ぐものではありません。単にそれを困難にするだけであり、その困難さの度合いは、平均的なユーザーに説明するには現実的に難しすぎるいくつかの要因に依存します。
ユーザーに届く情報が「イーサリアムに暗号化メムプールが導入されました。もうフロントランニングを気にする必要はありません。」となる非常に深刻なリスクがあります。もしユーザーがLUCIDを使用しているにもかかわらずフロントランニングされた場合、彼らはイーサリアムが自分たちを保護できなかったと非難し、X/Twitterに非常に、非常に怒りの投稿をするでしょう。
ある意味で、何かを約束してそれを完全に守れないことは、最初から約束しないよりも悪い結果を招く可能性があります。そして、我々はユーザーにどのような情報が届くかを完全に制御できるわけではありません。
[編集：EIPにおける誤解/曖昧さのみに起因する「協調問題」の項目を削除しました。EIPでこれを明確にしようとしています。 編集(2)：Andersからの返信を受けて、「対策」のガスに関する記述の誤りを修正しました。また、バンドルが思ったほど役立たない可能性がある理由も明確にしました。]
-
トランザクション送信者による開示の任意性を回避するには、送信者の参加なしに後でメッセージを復号する方法が必要です。暗号学的な観点からの主要な選択肢は以下の通りです。 (i) 何らかの形式の時刻ベース暗号を使用する方法。強力な敵対者であっても復号に最低時間t_1を要するが、誰でもt_1 < t_2の許容時間t_2内に復号できることを保証しようとします。我々のユースケースでは、t_1とt_2の間のギャップが非常に小さく、このアプローチは実質的に排除されます。 (ii) 何らかの形式のトラステッド実行環境 (TEE)を使用する方法。復号のための鍵が安全に保存され、何らかの正しい方法でのみ使用されます（例えば、バリデータの過半数によって署名されたタイムスタンプが提示されない限り、TEEは復号を拒否します）。これらのアプローチは、セキュリティの実績に疑問があります。 (iii) 閾値暗号 (threshold encryption) を使用する方法。バリデータの委員会（正直な過半数を仮定）に対して暗号化し、各バリデータが復号鍵の一部を保持し、共同でのみ復号できます。これにより、単一の当事者を信頼する必要性が、より受け入れやすい「バリデータの過半数が正直である」という仮定に置き換えられます。残念ながら、このような閾値暗号スキームに求められる要件（十分なセキュリティ、ポスト量子セキュリティ、適切な機能、様々な効率と低通信量）が多すぎて、現在利用可能なスキームでこれらすべてを満たすものはありません。 ↩︎
-
より正確なセキュリティ特性は、他の誰もトランザクション
txの内容を知り、この知識を使ってtxの前にトランザクションを挿入できないことです。実際、LUCIDではトランザクションの内容は「公式に」実行される前に知られるようになりますが、内容が知られる時点では、txの公式実行までのすべてのトランザクションはすでに確定しています。 ↩︎
3件の投稿 - 2人の参加者