ヴィタリック・ブテリンの最新の考え: PoSコンセンサスメカニズムの下でMEV問題を解決する2つの方法

フィードバックと議論を提供してくれた Justin Drake 氏と Flashbots チームに特に感謝します。

コンセンサス ネットワークの継続的な分散化を脅かす大きなリスクは、マイナー抽出可能価値 (MEV) を取り巻く経済、つまり次のブロックに何を入れるかを選択する能力から利益を引き出す複雑な技術です。ここで、MEV の簡単な例を示します。最後のブロック以降の価格変動について、すべてのオンチェーン分散型取引所間で裁定取引を行います。一般的な PoS 報酬は、単一のバリデータが強力な検証プールと同じ収益率を受け取るという点でかなり平等ですが、複雑な MEV 抽出機会を見つけることには大きな規模の経済性があります。簡単に言えば、プールが 10 倍大きいと、MEV を抽出する機会が 10 倍になり、各利益機会からより多くの利益を抽出するために最適化に多くのエネルギーを費やすことができます。この問題に加えて、MEV は分散型プールを複雑にします。分散型プールでは、ブロックのパッケージ化と提案を担当するエンティティが必要であり、プール自体と収入を分割することなく、秘密裏に MEV を簡単に引き出すことができるためです。

最もよく知られている解決策は、提案者とブロックビルダーの分離です。ブロック提案者は、収益を最大化するブロックを自ら作成しようとするのではなく、ブロック ビルダーと呼ばれる外部のアクターが完全なブロック コンテンツと提案者手数料を含むバンドルを作成し、提案者が手数料が最も高いバンドルを選択する市場に依存します。提案者の選択は、手数料が最も高いバンドルを選択するという単純なアルゴリズムで、分散型プールでは詐欺を防ぐために MPC 内で実行することもできます。

この記事では、これを実現するためのいくつかの設計を提案します。

ここで紹介したアイデアと密接に関連する2018年のアイデアもご覧ください: 最適化された提案コミットメントスキーム

提案者/建設者分離ブロック提案設計の望ましい特性

私たちは、5 つの主な望ましい属性に焦点を当てます。

1. 信頼できない提案者の友好性: 提案者がブロックビルダーを欺くリスクはほとんどないかまったくないため、ブロックビルダーには、特定のオフチェーンの評判やビルダーとの個人的な関係を持つ提案者を選択するインセンティブがありません (これにより、大規模なプールが有利になるため)。

2. 信頼できないビルダーのフレンドリーさ: ブロックビルダーが提案者を欺くリスクはほとんどないかまったくないため、提案者には、オフチェーンでの評判や提案者との個人的な関係を持つビルダーを選択するインセンティブがありません (これにより、新しいビルダーが市場に参入することが難しくなるため)。これを達成するために預金が必要な場合は、しきい値を最小限に抑える必要があります。

3. 弱い提案者フレンドリーさ: このメカニズムでは、提案者に (i) 高い帯域幅やその他のコンピューティング リソース、または (ii) 高度な技術的複雑さを要求すべきではありません。

4. バンドルは盗まれない: 提案者は、ブロックビルダーによって提案されたバンドルを受け入れて、そこからトランザクションを抽出し、独自のバンドルを作成することはできません。これにより、ブロックビルダーが利益を得ること (およびブロックビルダーにさらなる損害を与える可能性) を防ぐことができます。

5. コンセンサス レイヤーのシンプルさとセキュリティ: コンセンサス レイヤーの観点から、メカニズムは引き続き安全である必要があり、既存のブロック提案メカニズムと同じ分析の対象となることが望ましいです。

アイデア 1

1. ブロック ビルダーはバンドルを生成し、作成したバンドルのヘッダーを公開します。バンドル ヘッダーには、バンドル本体へのコミットメント (予想されるブロック コンテンツ)、提案者への支払い、およびビルダーの署名が含まれます。

2. 提案者は、最も高い支払いを提示するバンドル ヘッダーを選択します (ビルダーが実際に支払うのに十分な残高を持っているバンドルのみが考慮されます)。バンドル ヘッダーを含む提案に署名して公開します。

3. 署名された提案を確認した後、バンドル ヘッダーを提供したブロック ビルダーが完全なバンドルを公開します。

この時点で、フォーク選択ルールは、通常の 2 つの決定ではなく、次の 3 つの決定のうち 1 つを行うことができます。

1. ブロック提案が存在しない

2. ブロック提案は存在するが、バンドル本体は存在しない

3. ブロック提案が存在し、バンドル本体が存在する

2 番目のケースでは、提案は依然としてチェーンの一部となり、重要な点として、ブロック ビルダーから提案者への支払いは依然として処理されることに注意してください (ただし、ブロック ビルダー自体は手数料を受け取ったり、MEV を獲得したりすることはありません)。

分析する

5 つの特性のうち 3 つは簡単に満たされます。

1. 提案者は約束された支払いを無条件に受け入れるため、バンドルは提案者を騙すことはできません。

2. 3 つのステップはすべて非常に自動化されており、帯域幅も低いため、弱い提案者との親和性を満たしています。

3. 提案者は署名するバンドルの内容を見ることができないため、バンドルの盗用不可能性プロパティを満たします。

コンセンサス レイヤーの特性と、信頼できない提案者に対するフレンドリーさは、より複雑です。この設計により、フォークの選択方法が変わり、オプションが 2 つから 3 つに増えます。また、提案者がゲームの最後のプレーヤーではなくなることも意味します。理論的には、フォーク選択で決定を下すことができれば、これは良いことであると推測できますが、それでも結果は不明である可能性がある大きな変更です。

提案者はバンドルの内容を見ることはできず、バンドルを盗むことでブロックビルダーを欺くことはできませんが、ブロックビルダーに対してより巧妙な攻撃を仕掛けることはできます。スロットの最後に提案を公開することで、証明者が（おそらく）時間どおりに提案を確認できるようになりますが、ブロックビルダーに本文を公開するのに十分な時間を与えないため、証明者は時間どおりに本文を確認できない可能性が高くなります。これにより、ブロックビルダーにリスクが生じ、信頼できる提案者を優先するインセンティブが生まれます。さらに、悪意のある多数派が、気に入らないブロックビルダーに重いペナルティを課す機会が生まれます。

この問題を軽減するには 2 つの方法があると思います。

1. 証明者が提案を受け入れるのにかかる最大時間と、証明者が本文を受け入れるのにかかる最大時間の間には 2 秒の遅延があります。認証者を信頼すれば、問題はほぼ解決しますが、ブロックビルダーが資金を失うリスクがあるという根本的な問題は依然として残ります。さらに、認証者がこのように投票するインセンティブがあるかどうかは不明です (ただし、提案に対して 2 秒の VDF ソリューションを証明することを要求することで、認証者が強制的に待機させられる可能性があります)。

2. ボディが含まれていない場合、提案者は支払いの半分のみを受け取ります（ブロックビルダーは半分のみを支払います）。これにより、提案者が悪意のある損害を与えるにはコストがかかりますが、ブロック作成者が悪意のある損害を与えるにはコストがかかるままになります (どちらの場合も、コストは匿名の行為者でさえそれを望まないと思われるほど高くなります)。たとえば、バンドルの提案者手数料が 1 で、ブロック ビルダーの利益が 1.05 の場合:

（１）誠実な行動は（構築者、提案者）の報酬（０．０５、１）をもたらす。

（２）提案者または証明者が公開するのが遅すぎて、ヘッダーのみのブロックが受け入れられた場合、報酬は（-0.5、0.5）となる。

アイデア2

1. ブロック ビルダーはバンドルを作成し、作成したバンドル ヘッダーを公開します。バンドル ヘッダーには、コンテンツに関する約束、提案者への支払い、およびビルダーからの署名が含まれます。

2. 提案者は、確認したバンドル ヘッダーのリストで構成されるステートメントを選択して署名します。

3. アナウンスを確認した後、選択したブロック ビルダーは対応するバンドル本体を公開します。

4. 提案者は、事前に提出したリストからバンドル ヘッダーを選択し、それを使用して提案を公開します。

リストに載っていない提案を投稿した提案者を（同じスロット期間内に）排除し、罰則を科すという新しいスラッシング条件があります。

また、ステップ（2）で提案者によって提出されたバンドルヘッダーのリストは、ヘッダーの暗号ハッシュのリストになることもできることに注意してください。各ハッシュはバンドルのビルダーの公開鍵で暗号化されるため、ビルダーのみがハッシュが受け入れられたかどうかを知ることができます。これにより、DoS 攻撃のリスクが軽減されます。

分析する

ここでも、5 つの特性のうち 3 つは簡単に満たされます。

1. 提案者は、既存のバンドル ヘッダーの限定されたセットに制限されている場合にのみバンドル本体を表示できるため、バンドルを盗むことはできません。

2. 完全な本文を含めなければ、ビルダーから提案者への支払いは行われず、提案者はビルダーを金銭的に欺くことはできません。

3. システムは依然として提案者と最終参加者のゲームであるため、コンセンサス プロパティは以前と同じであり、コンセンサス ルールによって決定される内容に変更はありません。

このコンテキストで確保するのが難しい 2 つの特性は、弱い提案者フレンドリー性と信頼されていないブロック ビルダー フレンドリー性です。懸念されるのは、悪意のあるブロックビルダーが、非常に高い手数料を提示する提案を大量に作成し、その本文を一切公開しないことで提案者を攻撃する可能性があることです。提案者が受け入れるバンドルの数に上限を設定している場合、この攻撃によりすべての正当なバンドルの価格が引き上げられ、提案者のブロックに合法的に含めることができるバンドルがなくなる可能性があります。プロポーザーが受け入れることができるバンドルの数に上限がない場合、完全なバンドル本体 (それぞれ 500 KB 程度) が無制限にプロポーザーに送信されることになり、膨大な帯域幅が必要になります。

このジレンマを解決する 1 つの方法は、バンドル ヘッダーの送信を、ハード リミットではない何らかの方法でレート制限することです。

1. バンドルを送信するコスト。これは、EIP-1559 に類似したメカニズムを通じて、一定のレート (たとえば、スロットあたり 8 バンドル) に調整されます。

2. ブロック ビルダーとしてのデポジット要件、およびより低価格のバンドルが含まれていて、公開したバンドルが含まれていない場合、次の N スロットにバンドルを送信できないというルール。

バンドルに料金が含まれていないが、より低価格のバンドルには料金が含まれている場合にのみ料金が請求される場合もあります。これは、悪意のある行為を行っている可能性がある特定のケース (提案者が悪意を持っているか、その時点でネットワークが壊れているかのいずれか) であるためです。

ENS オークションでは、明らかに勝てない入札を阻止するために 0.5% の敗者手数料を課すなど、これに類する前例があります (勝者が支払う金額を増やすためだけです)。

ただし、これらの手法では提案者に信頼要件を導入するリスクがあるため、慎重に行う必要があり、バンドルを含めなかった場合のペナルティは高すぎないようにする必要があります。

もう 1 つの解決策は、バンドル プリンシパルの配布を自由かつ無制限に許可しながら、ネットワーク レベルでのプリンシパルの配布を制限することです。簡単なアルゴリズムは次のとおりです。

1. バンドル本体が伝播できる最小時間にわずかな遅延を追加します。最も高い支払いのバンドルの遅延は 0 秒、2 番目に高い支払いのバンドルの遅延は 0.2 秒、3 番目に高い支払いのバンドルの遅延は 0.38 秒、K 番目に高い支払いのバンドルの遅延は 0 秒です。

2番。

1. ノードがすでに高次のバンドル ボディをブロードキャストしている場合は、バンドル ボディをブロードキャストしないというルールを追加します。

これら 2 つの手法は組み合わせることができます。少額の料金を請求して、予想されるバンドル数をスロットあたり (たとえば) 50 に減らし、次にこのようなネットワーク層メカニズムを使用して帯域幅要件をさらに減らすことができます。

結論は

現時点では、上記の 2 つの方法が問題を解決する唯一の方法であるかどうかはわかりません。他の方法があるかもしれません。 2つのアプローチのうち、アイデア（1）は概念的には単純ですが、ブロックビルダーにリスクをもたらし、より複雑なフォーク選択ルールを必要とします。

アイデア（2）はフォークの選択とコンセンサスの観点からは単純ですが、悪意のあるブロックビルダーからのDoS攻撃に対処することが課題であり、その問題の解決策は他の問題も引き起こす可能性があります（ただし、これは最小限に抑えられると考えられます）。今のところ、どちらの解決策が優れているかはまだわかりません。