a16z:なぜ暗号化メモリープールがMEVの万能解薬になりにくいのか?

著者 | プラナブ・ガリミディ、ジョセフ・ボノー、リオバ・ハイムバッハ、a16z

コンパイル | シアーシャ、先見の明のニュース

ブロックチェーンでは、どの取引をブロックにパッケージし、どの取引を除外するか、または取引の順序を調整することで利益を上げることができます。このように得られる最大の価値を「最大抽出可能価値」と呼び、略して MEV といいます。MEV はほとんどのブロックチェーンに普遍的に存在し、業界で広く関心と議論の対象となっています。

多くの研究者がMEV現象を観察する中で、明確な疑問を提起しています:暗号技術はこの問題を解決できるのでしょうか?その一つの解決策は暗号化されたメモリプールを使用することです:ユーザーは暗号化された取引を放送し、これらの取引は順序が完了した後にのみ復号化されて公開されます。こうすることで、コンセンサスプロトコルは「盲目的に」取引の順序を選択しなければならず、これにより順序付けの段階でMEVの機会を利用して利益を得ることを防ぐようです。

しかし残念ながら、実際のアプリケーションや理論的な観点から見ても、暗号メモリプールは MEV 問題に対する一般的な解決策を提供することができません。本稿では、その難しさについて説明し、暗号メモリプールの実現可能な設計方向を探ります。

暗号メモリプールの動作原理

暗号メモリプールに関する多くの提案がありますが、その一般的なフレームワークは次のとおりです:

  1. ユーザーは暗号化された取引をブロードキャストします。

  2. 暗号取引がチェーン上に提出されます(いくつかの提案では、取引は最初に検証可能なランダムシャッフルを経る必要があります)。

  3. これらの取引を含むブロックが最終的に確認されると、取引は復号化されます。

  4. 最後にこれらの取引を実行します。

注意すべき重要な点は、ステップ3(取引の復号化)において、誰が復号化を担当するのかという重要な問題があるということです。もし復号化が完了しなかった場合はどうすればよいのでしょうか?一つのシンプルな考え方は、ユーザー自身が自分の取引を復号化することです(この場合、暗号化すら必要なく、単にコミットメントを隠すだけで済みます)。しかし、この方法には欠陥があります:攻撃者が投機的MEVを実施する可能性があるのです。

投機的MEVにおいて、攻撃者はある暗号取引にMEVの機会が含まれていると推測し、その後、自分の取引を暗号化し、有利な位置(例えば、ターゲット取引の前または後)に挿入しようとします。取引が期待通りの順序で配置されると、攻撃者は解読し、自分の取引を通じてMEVを抽出します。期待通りにならなかった場合、彼らは解読を拒否し、その取引は最終的なブロックチェーンに組み込まれません。

解読に失敗したユーザーに対して罰則を適用することができるかもしれませんが、このメカニズムの実施は非常に困難です。その理由は、すべての暗号化された取引の罰則の強度を統一しなければならず(暗号化後は取引を区別できないため)、罰則は十分に厳しくなければならないからです。高価値の対象に対しても投機的なMEVを抑制できるようにする必要があります。これにより、多くの資金がロックされることになり、その資金は匿名性を保持しなければなりません(取引とユーザーの関連性が漏れないようにするため)。さらに厄介なのは、プログラムのバグやネットワークの障害によって実際のユーザーが正常に解読できなくなった場合、彼らも損失を被ることになる点です。

したがって、ほとんどの提案は、取引を暗号化する際に、将来的に必ず復号できることを保証する必要があることを示唆しています。たとえ取引を開始したユーザーがオフラインまたは協力を拒否した場合でもです。この目標は、以下のいくつかの方法で達成できます。

信頼できる実行環境(TEE):ユーザーは、取引を信頼できる実行環境(TEE)のセキュアエリアが保持する鍵に暗号化することができます。一部の基本バージョンでは、TEEは特定の時点以降に取引を復号化するためだけに使用されます(これは、TEE内部に時間認識能力が必要です)。より複雑なソリューションでは、TEEが取引を復号化し、ブロックを構築し、到着時間、手数料などの基準に基づいて取引の順序を決定します。他の暗号メモリプールソリューションと比較して、TEEの利点は、プレーンテキスト取引を直接処理でき、巻き戻される取引をフィルタリングすることによってオンチェーンの冗長情報を削減できることです。しかし、この方法の短所は、ハードウェアの信頼性に依存していることです。

秘密分散と閾値暗号(Secret-sharing and threshold encryption):この方案では、ユーザーは取引を特定の鍵に暗号化します。この鍵は特定の委員会(通常は検証者のサブセット)によって共同で保持されます。復号には特定の閾値条件を満たす必要があります(例えば、委員会の三分の二のメンバーが同意すること)。

閾値暗号を使用する場合、信頼の媒介はハードウェアから委員会に変わります。支持者は、ほとんどのプロトコルが合意メカニズムにおいてデフォルトで検証者が「誠実な多数」を持つ特性を持っているので、私たちも似たような仮定を立てることができると考えています。つまり、ほとんどの検証者は誠実を保ち、取引を事前に解読しないでしょう。

しかし、ここで重要な違いに注意する必要があります:この2つの信頼仮定は同じ概念ではありません。ブロックチェーンのフォークなどのコンセンサスの失敗は公開可能性を持ち(「弱い信頼仮定」に属します)、悪意のある委員会が密かに取引を事前に解読しても公開証拠は残りません。このような攻撃は検出できず、罰することもできません(「強い信頼仮定」に属します)。したがって、一見すると、コンセンサスメカニズムと暗号委員会の安全仮定は一致しているように見えますが、実際の運用においては「委員会が共謀しない」という仮定の信頼性ははるかに低いのです。

タイムロックおよび遅延暗号化(Time-lock and delay encryption):閾値暗号の代替案として、遅延暗号の原理は以下の通りです:ユーザーは取引を特定の公開鍵に暗号化しますが、その公開鍵に対応する秘密鍵は時間ロックされたパズルの中に隠されています。時間ロックパズルは秘密を包み込む暗号学的パズルであり、その秘密の内容は事前に設定された時間を過ぎないと明らかにされません。より具体的には、復号プロセスには並行化できない一連の計算を繰り返し実行する必要があります。このメカニズムの下では、誰でもパズルを解いて鍵を取得し、取引を復号化できますが、その前提として、十分に長い時間を要する緩慢な(本質的には直列実行される)計算を完了する必要があります。これにより、取引が最終的に確認される前に復号化されないことが保証されます。この暗号原語の最強の形態は、遅延暗号技術を通じてこのようなパズルを公開生成することによって実現されます。また、信頼できる委員会を介して時間ロック暗号化を用いることでこのプロセスを近似的に実現することも可能ですが、この場合、相対的な閾値暗号に対する利点は疑問視されるべきです。

遅延暗号化を採用するか、信頼できる委員会が計算を実行するかにかかわらず、これらのソリューションは多くの実際的な課題に直面しています。第一に、遅延は本質的に計算プロセスに依存しているため、復号化時間の正確性を確保することが困難です。第二に、これらのソリューションは特定の実体が高性能ハードウェアを運用して効果的に問題を解決することに依存していますが、誰でもその役割を担うことができますが、その主体を参加させるためのインセンティブをどのように提供するかは不明です。最後に、このような設計では、すべての放送された取引が復号されますが、最終的にブロックに書き込まれたことのない取引も含まれます。一方、閾値(または証人暗号化)に基づくソリューションは、成功裏に含まれた取引のみを復号化する可能性があります。

ウィットネス暗号(Witness encryption):最も先進的な暗号学的手法の一つは「ウィットネス暗号」技術を採用しています。理論的には、ウィットネス暗号のメカニズムは、情報を暗号化した後、特定のNP関係に対応する「ウィットネス情報」を知っている人のみがそれを解読できるというものです。例えば、ある数独のパズルを解くことができる人、または特定の数値ハッシュの原像を提供できる人のみが解読を完了できるように情報を暗号化することができます。

(注:NP関係とは「問題」と「迅速に検証可能な答え」との対応関係のことです)

任意の NP 関係に対して、SNARKs を用いて類似の論理を実現することができます。証明の暗号化は、本質的にデータを暗号化し、特定の条件を満たすことができる主体のみが SNARK を通じて解読できる形式にすることができると言えます。暗号化メモリプールのシナリオにおいて、このような条件の典型的な例は、取引がブロックの最終確認後にのみ解読できるということです。

これは非常に潜在能力の高い理論的原語です。実際には、委員会のアプローチと遅延に基づくアプローチに基づく汎用的なスキームの具体的な適用形態にすぎません。残念ながら、現在は実際に適用可能な証人に基づく暗号スキームは存在しません。さらに、もしそのようなスキームが存在しても、プルーフ・オブ・ステークチェーンにおいて委員会のアプローチよりも優位性があるとは言い難いです。たとえ取引が最終確定されたブロック内で並べ替えられた後にのみ解読できるように証人暗号を設定したとしても、悪意のある委員会はプライベートにコンセンサスプロトコルを模倣して取引の最終確認状態を偽造し、プライベートチェーンを「証人」として使用して取引を解読することができます。この場合、同じ委員会による閾値解読は同等の安全性を達成し、操作もはるかに簡単です。

しかし、プルーフ・オブ・ワークのコンセンサスプロトコルでは、証明暗号の利点がより明確です。なぜなら、委員会が完全に悪意を持っていても、現在のブロックチェーンのヘッドで複数の新しいブロックを秘密裏に掘り出して最終確認状態を偽造することはできないからです。

暗号メモリプールが直面している技術的課題

暗号メモリプールがMEVを防ぐ能力を制約する実際的な課題が多くあります。全体的に見て、情報の秘密保持自体が難題です。注目すべきは、Web3分野での暗号技術の適用が広く行われていないことですが、私たちはネットワーク(例えばTLS/HTTPS)やプライベート通信(PGPからSignal、WhatsAppなどの現代の暗号メッセージプラットフォームまで)の中で、数十年にわたって暗号技術を展開してきた実践が、そこに潜む難しさを十分に明らかにしています。暗号は機密性を保護するためのツールですが、絶対的な保障を提供することはできません。

まず、一部の主体はユーザーの取引の平文情報を直接取得する可能性があります。典型的なシナリオでは、ユーザーは通常、自ら取引を暗号化することはなく、その作業をウォレットサービスプロバイダーに委託します。そうすることで、ウォレットサービスプロバイダーは取引の平文にアクセスでき、これらの情報を利用したり販売したりしてMEVを抽出する可能性があります。暗号の安全性は常に、鍵にアクセスできるすべての主体に依存しています。鍵の管理範囲が安全性の境界です。

それに加えて、最大の問題はメタデータ、つまり暗号ペイロード(取引)周辺の未暗号化データです。サーチャーはこれらのメタデータを利用して取引の意図を推測し、投機的なMEVを実施することができます。サーチャーは取引内容を完全に理解する必要はなく、毎回正確に当てる必要もありません。たとえば、彼らが特定の分散型取引所(DEX)からの買い注文であると合理的な確率で判断できれば、攻撃を開始するのに十分です。

メタデータは次のいくつかのカテゴリに分けることができます:1つは暗号技術に固有の古典的な問題であり、もう1つは暗号メモリプールに特有の問題です。

取引サイズ:暗号化自体は平文のサイズを隠すことができません(注目すべきは、意味論的な安全性の正式な定義では平文サイズの隠蔽が明示的に除外されていることです)。これは暗号通信における一般的な攻撃ベクトルであり、典型的なケースは、暗号化されていても、傍受者がビデオストリーム内の各データパケットのサイズを通じて、Netflixで再生されている内容をリアルタイムで判断できることです。暗号化されたメモリプール内では、特定のタイプの取引が独特のサイズを持つ可能性があり、それによって情報が漏洩することがあります。

放送時間:暗号もまた時間情報を隠すことはできません(これは別の古典的な攻撃ベクトルです)。Web3のシーンでは、特定の送信者(構造化された売却シーンなど)が固定の間隔で取引を開始する可能性があります。取引時間は、外部取引所の活動やニュースイベントなどの他の情報と関連付けられることもあります。より巧妙な時間情報の利用方法は、中央集権型取引所(CEX)と分散型取引所(DEX)のアービトラージです:順序付け者は、できるだけ遅く作成された取引を挿入することで、最新のCEX価格情報を利用します。同時に、順序付け者は特定の時間点以降に放送された他のすべての取引(暗号化されていても)を排除し、自分の取引だけが最新の価格優位を享受できるようにします。

ソースIPアドレス:検索者はピアツーピアネットワークを監視し、ソースIPアドレスを追跡することで取引送信者の身元を推測できます。この問題はビットコインの初期に発見されました(すでに10年以上が経過しています)。特定の送信者に固定された行動パターンがある場合、これは検索者にとって非常に価値があります。例えば、送信者の身元を知ることで、暗号取引を既に解読された過去の取引と関連付けることができます。

取引送信者と手数料 / ガス情報:取引手数料は暗号メモリプール特有のメタデータタイプです。イーサリアムでは、従来の取引はオンチェーン送信者アドレス(手数料支払い用)、最大ガス予算、そして送信者が支払う意志のある単位ガス費用を含みます。ソースネットワークアドレスに似て、送信者アドレスは複数の取引や実体との関連に使用できます;ガス予算は取引の意図を示唆することができます。例えば、特定のDEXと相互作用するためには、認識可能な固定ガス量が必要な場合があります。

複雑な検索者は、上記のさまざまなメタデータタイプを組み合わせて取引内容を予測することができます。

理論的には、これらの情報はすべて隠すことができますが、パフォーマンスと複雑さの代償が必要です。たとえば、取引を標準の長さまで埋めることでサイズを隠すことができますが、帯域幅とオンチェーンのスペースを浪費します。送信前に遅延を追加することで時間を隠すことができますが、遅延が増加します。Torなどの匿名ネットワークを使用して取引を提出することでIPアドレスを隠すことができますが、これには新たな課題が伴います。

最も隠しにくいメタデータは取引手数料情報です。暗号手数料データはブロック構築者に一連の問題をもたらします。まず、ゴミ情報の問題です。取引手数料データが暗号化されている場合、誰でもフォーマットエラーのある暗号取引を放送することができ、これらの取引は並べ替えられますが、手数料を支払うことはできず、復号化後に実行できず、責任を問われる者はいません。これは、SNARKsを通じて解決できるかもしれません。つまり、取引フォーマットが正しく、資金が十分であることを証明しますが、コストが大幅に増加します。

次に、ブロック構築と手数料オークションの効率の問題です。構築者は利益最大化のブロックを作成し、チェーン上のリソースの現在の市場価格を特定するために手数料情報に依存しています。暗号手数料データはこのプロセスを損なう可能性があります。一つの解決策は、各ブロックに固定手数料を設定することですが、これは経済的に非効率的であり、取引パッケージの二次市場を生む可能性があり、暗号メモリプールの設計意図に反します。もう一つの解決策は、安全なマルチパーティ計算または信頼できるハードウェアを通じて手数料オークションを行うことですが、これらの方法は非常にコストが高いです。

最後に、安全な暗号メモリプールは、システムのオーバーヘッドを多くの面で増加させます:暗号化はチェーンの遅延、計算量、帯域幅の消費を増加させるでしょう;分割や並行実行などの重要な将来の目標との統合方法は、現時点では明確ではありません;また、アクティビティ(liveness)に新しい故障点(しきい値スキームにおける復号委員会、遅延関数ソルバーなど)をもたらす可能性があります;同時に、設計と実装の複雑さも大幅に増加します。

暗号メモリプールの多くの問題は、取引のプライバシーを保護することを目的としたブロックチェーン(ZcashやMoneroなど)が直面する課題と関連しています。もし何かポジティブな意味があるとすれば、それは暗号技術がMEV緩和におけるすべての課題を解決すれば、取引のプライバシーをクリアにする手助けになるということです。

暗号メモリプールが直面する経済的課題

最後に、暗号メモリプールは経済的な課題にも直面しています。技術的な課題とは異なり、後者は十分なエンジニアリングの投入によって段階的に緩和することができます。これらの経済的な課題は根本的な制約に属し、解決が非常に困難です。

MEVの核心的な問題は、取引作成者(ユーザー)とMEV機会の採掘者(サーチャーとブロックビルダー)との間の情報の非対称性に起因します。ユーザーは通常、自身の取引にどれだけの抽出可能な価値が含まれているかを明確には理解していないため、完璧な暗号メモリプールが存在しても、実際のMEV価値よりも低い報酬と引き換えに解読キーを漏らすよう誘導される可能性があります。この現象を「インセンティブ解読」と呼ぶことができます。

このようなシーンは想像しやすいです。なぜなら、MEV Shareのような類似のメカニズムが実際に存在するからです。MEV Shareは、ユーザーが選択的に取引情報をプールに提出することを許可するオーダーフローオークションメカニズムです。サーチャーは競争を通じて、その取引を利用したMEV機会の権利を獲得します。落札者はMEVを取得した後、一部の利益(すなわち入札額またはその一定の割合)をユーザーに返還します。

このモデルは暗号メモリプールに直接適応できる:ユーザーは参加するために復号鍵(または部分情報)を開示する必要がある。しかし、多くのユーザーはこのようなメカニズムに参加する際の機会コストを認識していない。彼らは目の前のリターンしか見ておらず、情報を漏らすことを喜んでいる。従来の金融にも類似のケースがある:例えば、手数料ゼロの取引プラットフォームRobinhoodは、収益モデルとして「注文フローの支払い」(payment-for-order-flow)を通じて第三者にユーザーの注文フローを販売している。

別の可能性のあるシナリオは、大規模なビルダーが検閲を理由にユーザーに取引内容(または関連情報)を開示させることです。検閲耐性はWeb3分野において重要かつ議論の余地のあるトピックですが、大規模な検証者やビルダーが法律の制約(例えば、米国の外国資産管理局OFACの規則)に従って検閲リストを実行する必要がある場合、彼らはあらゆる暗号取引の処理を拒否する可能性があります。技術的には、ユーザーはゼロ知識証明を使用してその暗号取引が検閲要件を満たすことを証明できるかもしれませんが、これには追加のコストと複雑さが伴います。たとえブロックチェーンが強力な検閲耐性を持っているとしても(暗号取引が必ず含まれることを保証する)、ビルダーは依然として知られた平文の取引をブロックの前面に優先的に配置し、暗号取引を末尾に置く可能性があります。したがって、優先順位の実行を確保する必要がある取引は、最終的にはビルダーに内容を開示せざるを得なくなるかもしれません。

その他の効率に関する課題

暗号メモリプールは、さまざまな明らかな方法でシステムコストを増加させます。ユーザーは取引を暗号化する必要があり、システムは何らかの方法で復号化する必要があり、これが計算コストを増加させ、取引サイズを大きくする可能性があります。前述のように、メタデータの処理はこれらのコストをさらに悪化させます。しかし、いくつかの効率コストはそれほど明白ではありません。金融分野では、価格が利用可能なすべての情報を反映できる場合、市場は効率的であると見なされますが、遅延と情報の非対称性は市場を非効率的にします。これはまさに暗号メモリプールがもたらす必然的な結果です。

このような非効率は、直接的な結果をもたらします:価格の不確実性が増加し、これは暗号メモリプールに追加の遅延を引き起こす直接的な産物です。したがって、価格スリッページの許容範囲を超えるために失敗する取引が増える可能性があり、結果としてオンチェーンのスペースが無駄になることがあります。

同様に、この価格の不確実性は投機的なMEV取引を生み出す可能性があります。この種の取引は、オンチェーンのアービトラージから利益を得ようとします。注目すべきは、暗号のメモリプールがこのような機会をより一般的にする可能性があることです:実行の遅延により、分散型取引所(DEX)の現在の状態がより曖昧になり、これが市場の効率の低下を引き起こし、異なる取引プラットフォーム間で価格差が生じる可能性が高いです。このような投機的なMEV取引は、未発見のアービトラージ機会が存在する場合、実行を中止することが多いため、ブロックスペースを浪費することにもなります。

まとめ

この記事の目的は、暗号メモリプールが直面している課題を整理し、人々が他の解決策の開発に注力できるようにすることですが、暗号メモリプールは依然としてMEVガバナンスの一部となる可能性があります。

実行可能なアプローチの一つは、混合設計です:一部の取引は暗号メモリプールを通じて「ブラインドソート」を実現し、他の一部は別のソートスキームを採用します。特定のタイプの取引(例えば、大規模な市場参加者の売買注文で、取引を慎重に暗号化したり埋め込んだりする能力があり、MEVを回避するために高いコストを支払う意欲がある場合)に対して、混合設計は適切な選択肢となる可能性があります。高度に敏感な取引(例えば、脆弱性のあるセキュリティコントラクトに対する修正取引)にとっても、この設計は実際的な意味を持ちます。

しかし、技術的な制約、高額なエンジニアリングの複雑さ、パフォーマンスオーバーヘッドのため、暗号メモリプールは人々が期待する「MEV万能解決策」となる可能性は低い。コミュニティは、MEVオークション、アプリケーション層の防御メカニズム、最終確認時間の短縮など、他のソリューションを開発する必要がある。MEVは今後しばらくの間、依然として課題であり、その負の影響に対処するために、さまざまな解決策のバランスを見つけるための綿密な研究が必要である。

IP-1.27%
原文表示
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • コメント
  • リポスト
  • 共有
コメント
0/400
コメントなし
いつでもどこでも暗号資産取引
qrCode
スキャンしてGateアプリをダウンロード
コミュニティ
日本語
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)