暗号メモリプールを理解する：MEVと検閲問題を解決するための新しいデザインスペース
暗号化メモリプールは魅力的な設計空間であり、これらのいくつかの実装方法を見てみましょう。原文标题：《Encrypted Mempools》
原文作者：Jon Charbonneau
编译：0x11，Foresight News
暗号化メモリプールは、MEVと検閲の問題を解決するための強力なツールであり、現在、単独で使用できるさまざまな関連ソリューションが存在し、それらを組み合わせて使用することも可能です。
この記事では、Justin Drakeがこのテーマに関して行った講演（Columbia、Amsterdam、およびFlashbots Roast）に基づいて構築された設計空間を概説します。多くの人は初めて見ると理解が難しいかもしれませんので、私はそれを簡単に分解し、拡張しようとしました。
基本的な考え方：ユーザーが暗号化された取引を提出し、ブロック生産者がその取引を提出して解読することを許可する：
- ユーザーが取引を暗号化してブロードキャスト
- 暗号化された取引が提出される
- 取引が解読される
- 取引が実行される（注意：提出、解読、実行は単一のスロット内で行われる可能性があります）
2つの問題が簡単に解決できるようです：
- MEV：見えなければ、先行取引を行うことはできません
- 検閲：すべての暗号化された取引を除外しない限り、取引を検閲することはできません（多くの取引が暗号化されている場合、コストは非常に高くなる可能性があります）
ここで確保すべき重要なポイントは、解読がユーザーに依存しないことを保証することです。これを実現する方法はいくつかあります：
1. インフライト
ある第三者を信頼し、彼にデータをプライベートに送信します。彼はデータを解読して見ることができますが、データがチェーンに提出される前に公開しないことを約束します。これがFlashbots Protectなどの製品の動作方法です。
2. 信頼できるハードウェア
信頼できるハードウェアを利用できます。平文は信頼できるハードウェア内で実行できますが、取引が提出される前に公開されて解読されることはありません。最も有名な例は、Flashbots SUAVEのSGXです。
3. 閾値暗号化 / 解読（TED）
委員会が共同で暗号文を解読することを強制できますが、署名者が閾値に達する必要があります。たとえば、あなたの「閾値」は、2/3の検証者の同意が必要です。TEDは、以下のいくつかの異なる分野で研究されています：
- イーサリアム L1------Shutterized Beacon Chain
- Shutter Network ------ イーサリアム L2s
- Arbitrum ------ ChainlinkのFSS
- Osmosis & Anoma ------ Ferveo
Shutterized Beacon Chain
Shutterized Beacon Chain提案を詳しく見てみると、検証者のサブセット（「keypers」）が分散型鍵生成器（DKG）を使用して公開鍵/秘密鍵のペアを生成します。誰でも公開鍵を見ることができますが、秘密鍵は委員会内で複数の部分に分割されて保管されます。秘密鍵を再構築し、解読するには、鍵のシェアが一定の閾値（たとえば、2/3）に達する必要があります。
ユーザーは取引を選択的に暗号化でき、これらの取引はその内容が解読され、実行される前にチェーンに含まれます。ブロック生産者は、平文の取引（即時実行）と暗号化された取引（将来のブロック高で予定されている）を使用してブロックを作成します。
ブロックn-1を生成し、証明した後、keypersはブロックnの解読鍵を生成し、公開する必要があります。この鍵は、ブロックn内の取引を解読できます。ブロックnは、有効と見なされるために解読鍵を含む必要があります。ブロックの後の状態は、ブロック内の平文の取引を実行する前に、ブロック内の暗号化された取引を実行することによって計算されます（それらの設定順序に従って）。
欠点
TEDにはいくつかの欠点があります：
責任の欠如：従来のセキュリティ仮定とは異なり、ここでの悪意のある行動は帰属できず、報告できません。Keypersは即座に解読できますが、あなたはそれに対して帰属を持つことができません。たとえ検証者の行動がインセンティブと整合していると仮定しても、検証者集団の外の三文字機関（訳注：CIA、FBIなどの機関の総称で、アメリカを守るが通常は神秘的に行動する）も彼らに影響を与える可能性があります。
誠実な多数の仮定：不誠実な委員会は、特定のメッセージを決して解読しないことを選択したり、秘密裏に解読してはならないメッセージを解読したりする問題を引き起こす可能性があります（たとえば、政府機関の要求に応じて、または自己中心的にMEVを抽出するために）。ほとんどの場合、ブロックチェーンは実際には経済的に合理的な多数に依存しています（すなわち、没収の罰則は通常、悪意のある二重支払いなどの行為の経済的インセンティブを上回ります）。閾値暗号化によって、この仮定は本当に誠実で無私の多数に移行します。
プロトコルの安定性を損なう：本質的には上記の2つのポイントの組み合わせであり、TEDは検証者が悪事を働く動機を高め、罰を受けにくくします。
アクティビティの減少：より高い解読閾値はプロトコルのセキュリティを強化します。しかし、これは直接的にアクティビティを減少させます。たとえば、大規模なネットワークの中断は、半分の検証者が中断することを引き起こし、現在ではプロトコルが停止する可能性があります。特に「第三次世界大戦」のアクティビティを非常に重視するイーサリアムにとっては、受け入れられないトレードオフです。
悪いユーザー体験：TEDは、実装の詳細に応じて異なる程度の遅延とコストを追加する可能性があります。
最適でない価値の分配：簡単なフロントランニングの例を見てみましょう：
- 1 ETHの価格は1000ドル
- もし私が取引をバニラメモリプールに送信した場合 ------私は990ドルを得ます（探索者がフロントランとバックランを行い、純利益は10ドル）
- もし私が取引をTEDメモリプールに送信した場合 ------私は995ドルを得ます（探索者はフロントランできませんが、私はローカルスポット価格を押し上げ、探索者に5ドルのアービトラージ機会を提供しました）
- 私が取引を最適な注文流オークションに送信した場合 ------私は1000ドルを得ます（私はフロントランやバックランを得ません。あるいは、同様に、私は実際にフロントランやバックランを得ますが、探索者は競争的なオークションで10ドルの入札を行わなければならず、その権利を得るための最終結果は同じです。）
この場合、あなたは他の人にお金をテーブルに置いておくことになります。経済的に合理的なユーザーは、注文の情報を公開して、注文の全価値に近い補償を得るべきです。彼らは自分の取引を閾値暗号化して、その提供する価値を隠すべきではありません（他の人がそれを捕らえることを許可する）。
これは非常に理想化された例ですが、問題を隠すことが常に問題を解決するわけではないことは理解できます。TEDは有用なツールになり得ますが、MEVの万能薬ではありません。特定の状況では、CRの方が良いと言えるかもしれません。
さらに、イーサリアムは追加の複雑さをもたらします。たとえば、即時の確定性が欠如している（これは、いつか単一スロットの確定性によって変わる可能性がありますが）ため、再編成に関する問題が発生します。私は、少なくともイーサリアムのL1においては、ここでのトレードオフが利点を上回ると信じています。イーサリアムの信頼仮定を増加させ、共謀の動機（発見されないように）を増加させ、アクティビティの低下による損害が利益を上回る可能性があります。
しかし、イーサリアムL1と比較して、これらのトレードオフのいくつかはL2や他のL1にとっては受け入れやすいかもしれません。
4. 遅延暗号化 / 解読（DED）
遅延暗号化を使用すると、暗号化された情報を一定の時間後に自動的に解読するように設定できます。これはVDFに関連する順序計算です。
実際にDEDを実装するには、VDF ASICが必要です。幸いなことに、イーサリアム財団とプロトコルラボはそれらの構築に取り組んでおり、最近GlobalFoundriesが構築したチップの最初のテストサンプルを取得しました。これらのVDF評価器は、非常に高速な順序計算を行うことができるはずです。これらのVDF ASICは、タイムロックパズルやDEDにも適用できます。
VDFはSNARKを生成する必要もあります。これはGPUを使用して行うことができますが、理想的にはイーサリアム財団もSNARK生成に関連するASICを希望しています。
全体として、あなたはもはや特定の委員会を信頼しないため、通常は安全な仮定が好まれます。しかし、専用のハードウェアが必要であることはそれほど理想的ではなく、必要な遅延はシステムの遅延を増加させる可能性があります。興味深いことに、TED + DEDの利点を組み合わせて使用することができます……
5. 証人暗号化 / 解読（WED）
WEDは強力ですが、あまり喜びすぎないでください。すぐには実現しません。これは非常に特異なものであり、実現にはまだ多くの年数が必要です。しかし、それはクールであり、理解を助けるので、簡単に紹介します。
WEDは、任意の証人が暗号文を強制的に解読することを許可します。たとえば、あなたのルールは「イーサリアムが暗号化されたペイロードを含むブロックを完成させた後にのみ解読できる」とし、これを証明する場合にのみ解読されます。基本的に、実現したい複雑な文をSNARKが必要とすることを想像できます。
WEDは実際にはTEDまたはDEDの概念をまとめたものです。たとえば、指定された証人が証明できるように構築できます：
- 幸せな結果：閾値委員会が解読に署名した、または
- 予備プラン：必要な時間が経過し、遅延解読に戻る
これは、閾値委員会が応答しない場合の予備を提供します。また、m/n閾値仮定をパラメータ化する際に、より保守的になることも可能です（すなわち、各委員会メンバーまたはほぼすべてのメンバーが署名することを要求できます）。
- 幸せな結果：最良のユーザー体験、全体の委員会が即座に確認
- 予備プラン：遅延とUXが一時的に影響を受けますが、アクティビティは保持されます
実際、WEDはあなたが望む任意の声明をSNARKで検証することができます。たとえば：
- TED：あなたは「私はnの署名のうちmの署名を持っている」と証明するSNARKを持つことができます。
- DED：あなたはVDFを使用し、順序計算を行います（これは非常に高価です）。その後、計算が終了したときに短い証明を得ます。それからその短い証明をSNARKで包み（短くする）、それを入力して解読を強制します。
同態性
ここでの各暗号化スキーム（閾値、遅延、証人）には同態性を持つことができます。つまり、閾値FHE、遅延FHE、証人FHEスキームを作成して、暗号文に対して任意の操作を実行できます。
インフライトおよび信頼できるハードウェア（たとえば、SGX）ソリューションも同じ機能を模倣できます------プライベートデータに対して操作を行うことができます。これは、これらの2つのケースでは、信頼できる第三者またはハードウェアが平文自体にアクセスして操作を行うことができるためです。しかし、理想的には、これらの信頼仮定を取り除き、強化された暗号学にのみ依存したいと考えています。
次の例を想像できます：
- m1 = 取引1
- m2 = 取引2
- f(x) = ブロックを構築する
その後、すべての5つのソリューションは以下の機能を複製できます：
取引メタデータを隠し、暗号化された入力を使用して最適なブロックを構築する方法を考えるとき、この能力を忘れないでください。理論的には、ここでの5つのオプションのそれぞれが、以下に必要な「同態」ソリューションに使用できます。
メタデータ
メタデータは、他のデータに関する情報を提供するデータですが、そのデータの内容（たとえば、メッセージのテキストや画像自体）を提供しません。私たちの目的のために、取引メタデータには、送信者のIPアドレス、乱数、Gas支払いなどが含まれる可能性があります。
理想的には、できるだけ多くのメタデータを隠したいと考えています。そうでなければ、それは情報を漏らし、外部の人々があなたの取引を推測できるようにする可能性があります（彼らに十分な情報を提供して、フロントランや検閲を試みることができるかもしれません）。しかし、取引が有効であるか、必要な手数料が支払われているか、スパムであるかを検証するためにメタデータが必要です。
さまざまなメタデータを隠すためのいくつかのソリューションを見てみましょう。
1. IPアドレス - Tor
非常に簡単です------人々はTorのようなサービスを使用してプライベートにブロードキャストし、IPアドレスを隠すことができます。
2. 署名 - SNARK
あなたはp2pレベルで暗号化された取引が有効であることを知る必要があります。特に、それが有効な署名を持っていることです。私たちはSNARKを使用して署名が有効であることを証明できます。SNARKには3つの重要な部分があります：
ユーザーは自分の取引暗号文が有効であることを証明したいと考えています。それは取引平文に対応し、その署名が有効であることを示します。任意の署名が有効であることを証明するには、アカウントに関連付けられた公開鍵が必要です。
- イーサリアムの状態ルートを見つける（公開）。
- この状態ルートに対応する送信者の公開鍵のMerkle証明を提供する（プライベート）。
- 署名を検証するには、状態ルートに基づいて送信者の公開鍵のMerkle証明を検証する必要があります。あなたの送信者の公開鍵のMerkle証明が有効であり、あなたの署名が有効であることをSNARKで証明します。
3. Gas支払い------SNARK
あなたは暗号化された取引の送信者がこの費用を支払うのに十分なETHを持っていることを証明する必要があります。私たちは再びSNARKを使用できます。
これは類似のプロセスですが、今度は状態ルートへのMerkleパスを提供し、送信者の残高を証明します（送信者の公開鍵ではなく）。あなたはMerkleパスを検証し、残高が必要なGasを支払うのに十分であるかどうかを確認します。
基本的な操作（取引の逆シリアル化、残高の確認、署名の確認など）を実行するために必要な最小限のGas。あなたは送信者が常にこの最小金額を支払わなければならないと規定できます。
しかし、実行時には、実際の取引自体のGas制限も必要であり、このGas制限も暗号化できます。したがって、実際に取引を実行する際には、送信者がその時点での取引の全Gasを支払うのに十分な残高を持っているかどうかを確認します：
- もしそうなら：取引を実行し、最後に返金を発行します
- もしそうでないなら：取引を中止し、送信者は21000Gasのみを支払います
4. 送信者と乱数 - SNARK
乱数は、あるアドレスから送信された取引の数（またはアカウントが作成した契約の数）に等しい値です。ユーザーの乱数は、彼らのアドレスから取引を開始するたびに1ずつ増加します。
今日、私たちが乱数を持っている理由の1つは、ユーザーが大量の取引をメモリプールに送信して（DoS攻撃）、彼らの取引が実行される可能性を高めることを防ぐためです。ノードはその乱数を持つ取引のみを確認し、他の取引を破棄します。
暗号化された取引の場合、あなたはSNARKを通じてその乱数が前の乱数+1であることを証明します。しかし、ノードがもはや多くの暗号化された取引が同じ乱数を持っていることを区別できなくなる場合、上記のDoS攻撃が悪影響を及ぼす可能性があります。
このDoS属性を保持するために、「リプレイタグ」を追加したいと考えています。これは取引にユニークなタグを付けるため、あなたはもはや1つのアドレスに大量の取引ゴミを送信することはできません。このタグを作成するには、単に（乱数、秘密鍵）をハッシュすることができます。乱数と秘密鍵は固定されているため、ユーザーが同じ乱数と秘密鍵を使用して2つの異なる取引を送信しようとすると、異なる取引が同じリプレイタグを持つことになります。
最後に、ある程度の柔軟性を保持したいと考えています。Gas価格が変動したと仮定すると、より高い価格で取引を再ブロードキャストしたい理由があります。この状況を緩和するために、（乱数、秘密鍵、スロット）をハッシュすることができます。これにより、各スロットで1回取引を調整でき、各スロットで各アドレスは1つの取引しか送信できません。
5. データサイズ - 同態
暗号化されたデータサイズnの平文は、サイズnの暗号文を生成します。このサイズでさえ、特定の取引を確率的に計算するのに十分です。私たちは「パディング」を通じてこの問題を緩和できます------暗号化の前に平文に0を追加し、ビット数を2の次の累乗に拡張します（たとえば、5ビットの暗号文に3つの0を追加します）。
次の例では：
- 白色 = パディングされた0
- 他の色 = 実際の取引データ
ブロックを構築する際に、これらの暗号文を接続できますが、2つの問題があります：
- 不完全なパッキング------追加の0は、追加のデータ可用性のために支払う必要があります
- 不完全なプライバシー - おそらく2の累乗は十分な情報を提供します。取引の規模分布は不明確であるため、特定の規模は確率的に十分な情報を明らかにする可能性があります。
より良い解決策は「パディング」を「カット」することを含みます：
- 各取引を最大サイズ（ここでは16）までパディングし、同態的に暗号化します
- 暗号文に関数を適用して平文を効果的にパッキングし、不必要なパディングを削除します
これで、最適なパッキングが得られます。
「最大」サイズにパディングすることで、実際のブロックサイズ制限に変換された値として最大値を設定できます（すなわち、30mm Gasが約x kBに変換される場合）。これは、各取引をx kBのサイズにパディングすることを意味します。あるいは、99.9%の取引が通常y kBの範囲内にある場合、より小さく、より実用的なy kBのサイズを設定できます。
同様に、前述のFHEの代わりに信頼できるハードウェアを使用してこの「カット」を模倣できます。たとえば、SGXを実行し、暗号化された取引を信頼できるエンクレーブに受け取ることができます。エンクレーブ内でデータに対して平文操作を行い、不必要なパディングをカットしてブロックを密にパッキングします。その後、データは暗号化されて戻され、続いて強制解読方法（閾値、遅延、証人）が行われます。
いずれの場合でも、出力は固定サイズであるべきであり、したがって少量のパディングが残る可能性があります。
取引パッケージの選択：同態と非交差状態アクセスリスト
上記のすべての問題を解決したと仮定すると、ブロック生産者はサイズに基づいてすべてを最適にパッキングできるようになります。しかし、もう1つの問題があります------ブロック生産者は経済的に最適にすべてをパッキングできるのでしょうか？私たちは、価値を失うことなく分散化してブロックを構築したいと考えています。さもなければ、中央集権的なエンティティと競争できません。
解決策1 - FHE EVM
直接的な答え：完全にFHE内でEVMを実行します。これにより、分散化された最適なブロックの構築が可能になり、ブロック生産者が最大の価値を得ることができます。彼らは価値を最大化する取引を選択し、並べ替えます。
残念ながら、これは簡単なことではありません。FHE回路の最大コストは「深さ」（すなわち、最長パス内のゲート数）です。特に、その乗算の深さは非常に重要です。たとえば、前述のパディングを削除する取引「カット」は、かなり「浅い」回路です（すなわち、非常に簡単です）。ハードウェアアクセラレーションを通じて、このようなユースケースは2-3年以内に計算上実行可能になるかもしれません。
しかし、FHE全体でEVMを実行するには、非常に深く、複雑な回路が必要です。私たちはついにzkEVM回路に関していくつかの意味のある進展を遂げ始めています（これは標準EVMを実行する計算集約度の数桁高いですが）、しかしFHE EVMはさらに遠いです。
再度注意してください。この機能を信頼できるハードウェアで模倣することも可能です（たとえば、SUAVE内のSGXがそれを行います）。
解決策2 - 状態アクセスリスト
または、FHEとアクセスリストをより制限的に使用できます。これは完全なFHE EVMを実行するよりも実装が容易です------それはより浅い回路です。この設定では、取引パッケージには暗号化された状態アクセスリストとその入札が含まれます。これにより、彼らのパッケージがどの部分の状態にアクセスするかが正確に指定されます。
現在、ブロック生産者の同態回路は、非交差状態アクセスリストを持つ取引パッケージから最高の入札を選択するだけで済みます。
これは厳密には最適ではありません。たとえば、あるブロック内の2番目に高い入札(T2)は、最高の入札(T1)と完全に同じ状態に達する可能性があります。このアクセスリストの例では、ブロック生産者は2番目の取引を破棄します。しかし、T1とT2の両方が有効である可能性があります。この場合、FHE EVM（または今日の中央集権的なブロック生産）はより多くの価値を得るでしょう。
完璧ではありませんが、私たちの今日の状況から見ると、この近道は十分に最適に近いはずです。大多数のMEVは、上記のような衝突の例が非常にまれであるため、非交差のアクセスリストを使用することになります。
6. タイムスタンプ - 同態
あなたは、検証者が「仮想」取引を行うことを許可することで、取引の存在の漏洩を隠そうとすることもできます。これにより、メモリプールは常に満たされます。検証者は、これらの仮想取引を作成することが許可された検証者であることを証明するためにSNARKも必要です。「真の」取引がピークに達したとき、検証者は少ない仮想取引をブロードキャストします。真の取引が減少すると、検証者はより多くの仮想取引を発信します。
すべてがFHE暗号化を使用していると仮定すると、あなたは対応する取引に追加された「仮想フラグ」を検出できるようになります。実際のブロックをパッキングする際に、これらの取引を無視することができます。
状態差異 - FHE EVM
背景の概要：ZK Rollupの利点の1つは、彼らがチェーン上に完全な取引データを公開する必要がないことです。彼らは状態更新間の「状態差異」を公開するだけで十分です。対照的に、Optimistic Rollupsは、詐欺証明の仲裁のためにチェーン上に完全なデータを公開する必要があります。この低いデータ要件は、ZK Rollupがデータ可用性層で消費するリソースを減らすため、コストを節約します。
この点を私たちの対話に持ち込むと------理想的には、暗号化メモリプールの状況でこの利点を失いたくありません。暗号化されたメモリプールを取得し、ZK Rollupが状態差異のみを公開する能力を保持したいと考えています。ここに答えがあります------FHE zkEVM。クールに聞こえますが、あなたはまた長い間待たなければならないかもしれません。
1つの欠点は、状態差異を単独で公開することがRollupの完全ノードの応答速度を低下させる可能性があることです。たとえば、純粋なフォーク選択ルールのRollupでは、完全ノードはデータ可用性層が完了し、有効性を確保したときに即座にRollupのビューを完了できます。状態差異のみを公開する場合（完全な取引データではなく）、完全なノードでさえ、Rollupのビューを確認するためにZK証明を提出する必要があります。今日の状況では------これらの証明は生成に時間がかかりますが、スケーラブルなデータ可用性層はすぐに非常に安価になることが期待されています。
結論
暗号化メモリプールは魅力的で有望な設計空間ですが、依然としていくつかの実際の課題があります。たとえば、あなたは単に特定の問題をスタックの他の場所に移動するだけかもしれません。ウォレットは、取引の暗号化/ルーティングを防ぐためにあなたを検閲することができ、彼らはあなたの取引の前後に有効負荷を提出することができます（または権利を販売するなど）。1つの可能な答えは、ユーザーがサービスプロバイダーに依存せずにローカルで取引を作成することです。
重要なのは、ここに万能薬はないということですが、適切に設計されれば、これらは異なる機能と信頼仮定を通じて現在の状況を改善するための解決策の重要な要素となる可能性があります。
