PBSの市場構造を再考し、ePBSの設計を改善する

原題:「PBS の市場構造を再考する」

執筆者:Barnabé Monnot、Robust Incentives Group 研究者

編集者:Tia、Techub News

現在の取引市場では、ブロック ジェネレーターはメモリ プール内のトランザクション、特に優先度の高い手数料を支払うトランザクションをレビューすることによって、どのトランザクションを次のブロックにパッケージ化するかを直接決定します。この実践により、ブロックプロデューサーはさまざまな戦略を使用して、パッケージ化するトランザクションを選択し、場合によっては独自のトランザクションを含めて、MEV を最大化して利益を得ることができます。

この問題を解決するために、提案者と構築者の分離 (PBS) によって、ブロックの構築と提案の役割が分離されます。このモデルでは、ビルダーは実行ブロック (つまり、順序付けされたトランザクション リスト) を構築して入札を送信する責任を負い、提案者のタスクは最高入札で実行ブロックを受け入れることです。このようにして、責任と機能が異なる役割間で明確に分割されるため、システムの効率とセキュリティが向上します。

PBS の話題に触れてからしばらく経ちましたが、ここ数カ月間の PBS に関する新たな展開を見て、今が PBS を再検討する良い機会だと思いました。まだ十分に整理されておらず、あまり明確ではありませんが、議論する価値のある考えをいくつか共有したいと思います。

ePBS が戻ってきました

ePBS に関する最近の提案 (Potuz,Terence) は MEV-Boost からのサポートを求めており、これが「PBS は何をするのか?」という議論を引き起こしました。

次の議論をより構造化するために、PBS のコンポーネントを 2 つの部分に分割します。

1. 市場構造: 現在の考え方は、役割を分割することです。バリデーターを提案者と構築者に分割し、Potuz 氏が記事「ePBS の設計制限」で満たそうとしているのと同じように、これら 2 つの分割された役割を交換します。

2. 配布メカニズム: PBS は、提案者と第三者が参加できるスペースを定義します。現在、MEV-Boost では、提案者はペイロードを実行する権利を放棄しています。

ePBS のような特別な配布メカニズムを使用するのは危険かもしれないと考えています。バリデーターにプログラム可能な公正なトランザクションを実行させ、可能な限りバリデーターが提案者の役割に参加できるようにする可能性があります。委員会、この記事ではこれを深く調査し、最近の Execution Tickets 提案など、提案者としてのバリデーターの市場構造について質問します。最近提案された ePBS は、MEV-Boost の特殊な市場構造と流通メカニズムを継承しています。市場構造は、可能な割り当てメカニズムのスペースを決定します。そして、「健全な」ビルダー市場の誘導など、MEV-Boost の制限の一部は、提案者としてのバリデーターの市場構造によって引き起こされる可能性があると思います。

次に、議論をペイロードの実行に限定するために、「ブロック」の代わりに「ペイロード」を使用します。この記事では、バリデーターの責任、つまりビーコン ブロックの送信については説明しません。

検証者としての提案者の苦痛

MEV-Boost の中核は、検証者にペイロードの実行を提案し、これらの権利から恩恵を受ける権利が与えられることです。ただし、バリデーターは建設権を契約し、他の人 (1 人以上の建設者) に自分たちに代わってブロックの内容を決定させたいと考えています。 MEV-Boost によりこれが可能になります。提案者はペイロード全体を販売しますが、構築者は入札時に有効なペイロード コンテンツを約束します。 これは特定の割り当てメカニズムであり、特定のビルダーからのペイロードを使用することを約束する スロットやハイブリッド オークション などの他の設計も存在します。

この時点で最も重要なことは、バリデーターはペイロードの提案者であり続けなければならないということです。バリデーターはその構築とは何の関係もないプロセスに署名する必要があり、これはプロトコルの制限のように感じられます。この意味で、提案者の署名はほとんど純粋に装飾的であり、技術的な必要性を感じます。同時に、このテクノロジーには MEV-Boost の中心となる公正な交換の複雑なメカニズムが依然として必要です。問題の交換は、建設者の約束された出力 (ブロック) であり、バリデーターの署名に対応し、バリデーターは自身の提案権を保持しながら建設権を割り当てます。

この交換の運用の複雑さを排除することはできないため、複雑さがプロトコルの外部に存在するか内部に存在するかによって、特定の信頼の仮定が変わります。ビルド権限を割り当てることが正しいと考えるのであれば、この複雑さに取り組む価値があるかもしれません。この交換を実装することにより、バリデーターはペイロードを実行する提案者となり、プロトコルは特定の配布メカニズムを使用して交換を実行するか、Potuz からの最近の提案である「ホールセール PBS」、別名スロット オークションを実行します。

したがって、ここでの問題は、提案者としてのバリデーターと構築者が相互に拘束力のある契約に署名するための合意メカニズムを確立するかどうかを決定することです。つまり、提案者としてのバリデーターは構築物を販売する権利を持っています。 最近の (e)PBS ブレイクアウトコール で行われた議論の 1 つは、このメカニズムがこの市場の供給側、つまりリレーとビルダーを浄化するだろうということでした。中継に関しては、プロトコル承認メカニズムが存在するので、持続可能な中継の経済性を理解する責任を自分の肩から負うことができる、という主張です。ビルダーにとって、トラストレスでプロトコル内のビルド方法があるため、サービスに参加するための平等な競争の場が得られるという考えです。

私の質問は、どちらの仮説も、私たちが過度に集中している市場と考えるものを生み出しているのが配分メカニズムなのか、それとも市場構造自体なのかについて疑問を投げかけているわけではないということです。リレーの存在は、検証者と提案者としての建設者との間の公平な交換を可能にするためにありますが、同じ経済メカニズムを持つ異なる構造の下では、リレーがまだ存在する兆候はありません。建設業者はまた、流通メカニズムの卸売およびスポット的な性質により、中央集権的な勢力の影響を受ける可能性があります。したがって、ePBS を実装すると、私たちが解決したい問題が解決されます。それでは、ePBS はすべての市場参加者の行動セットを増やすことで MEV-Boost の現状を改善しますが、まだ適応していない市場を永続させるのでしょうか?これらの改善は開発コストと比較してそれだけの価値がありますか?彼らは合意に適切な境界線を設定しましたか?

バリデーターは優れた提案者ですか?

まず市場構造に疑問を持ちます。そもそも、なぜペイロードの実行を提案する権利がデフォルトで検証者 に付与される必要があるのでしょうか?

バリデーターがデフォルトのペイロード プロポーザーであるべき理由を考えてみましょう。検閲への抵抗は、ペイロードを実行するビルドでバリデーターをアクティブにしておく理由になる可能性があります。ビルド プロセス中にペイロードを使用できるように、バリデータ セットを分散化することが重要です。ただし、バリデーターは、MEV-Boost を使用するときに今日この機能を完全に放棄するか、明日 ePBS を使用するときにこの機能を完全に放棄する可能性があります。 Inclusion lists や派生型 (例 Multiplicity) などの提案は、この状況に対処でき、バリデーターが制約の効率を低下させることなくペイロード構築にバインディング制約を課すことができるようになります。ただし、これらの提案は、別のバリデータであろうと他の当事者であろうと、たまたまその権利を保持している人を拘束するという点で、提案の権利を割り当てる問題とは多少直交しています。

なぜデフォルトでバリデーターにプロポーザル権限を与えることにこだわるのでしょうか? 答えは、次のようにも考えられます: 私たちは、ペイロード コンテンツを自分の好みの順序で、または希望どおりに構築する自己構築型バリデーターを重視しています。つまり、提案する権利だけでなく構築する権利も留保してもらいたいのです。分散された参加者グループ (バリデーター) が順番に自分たちに適したペイロードを構築するという事実が特徴と言えます。アリスはペイロードが公平にソートされることを望んでいるかもしれませんが、ここでの公平性はアリスに相対的なものであり、ボブが考える公平性とは完全に異なる可能性があります。この場合、構築された実行ペイロードをバリデーターから削除することが問題になります。バリデーターが実行ペイロードを自由に構築できるという保証はなくなります。 個人的には、これは大きな問題ではないと思います。まず、市場は、ほとんどのバリデーターが建設権を自ら行使することを好まず、代わりに建設を他の当事者に委託することを望んでいることを示しています。第二に、バリデーターが独自のペイロードコンテンツを構築してペイロードコンテンツを処理するのは良いことかもしれませんが、私の意見では、バリデーターには「順序付けられたペイロード」を構築する理由は他にありません（検閲耐性の問題を分離するために前の章ですでに取り上げられています） ）。 MEV-Burn などの初期のデザインでは、バリデーターの提案権限のデフォルトの割り当てが保持されている一方で、バリデーターにビルド権限の放棄を強制していたことに注意してください。

検証者と提案者の分離 (別名証明者と提案者の分離、別名実行チケット)

したがって、プロトコルがペイロードバリデーターを提案および構築する権利をデフォルトではなく、代わりに割り当てることを決定した場合、バリデータとは異なる可能性のある何らかのメカニズムを介して他の当事者にそれを送信しますか?バリデーターが、ペイロードを構築する一連のサードパーティエンティティの単純な「パススルー」仲介者である場合、プロトコルが提案権限の分配のみを考慮するのは理にかなっていませんか?

これが実行チケット (ET) のポイントです。実行チケット (ET) は、購入者が実行ペイロードを提案する権利を購入できる許可のないマーケットプレイスです。これらの権利は、チケット所有者にランダムに割り当てられた権利を与え、チケット所有者は、いつペイロードの実行を提案する機会がチケットによって許可されるかを事前に（パラメータを決定する特定の時点で）知ることができます。

その場合、プロトコルは、提案者としてのプロトコルの正当なバリデータと、プロトコルの非合法な構築者との間の構築権の公平な交換をもはや気にしなくなる可能性があります。 ベアラーはステークされていない可能性がありますが、プロトコルにとってベアラーが提案者であることは依然として明らかです。特に、プロトコルは、チケット所有者と提案者 (存在する場合) としての作成者との間の公正な交換にもはや責任を負わない可能性があります。プロトコルは、チケットを販売するときに配布機能を実行しました。

バリデーターとプロポーザーを分離する市場構造の配布メカニズムとしての実行チケットの実現可能性に関しては、多くの疑問が残っています。私の個人的な見解は、ET が実際に正しいメカニズムではない場合、市場構造の正しさに自信を与えることで、ET であるかどうかに関係なく、配分を正しく実行する何らかのメカニズムがあると信じることになるでしょう。

私がこれまでに見た中で、バリデーターと提案者と分離された市場構造に疑問を投げかける最も強力な議論は、クインタス・キルボーンとコナー・マクメナミンの記事「

When to Sell Your Blocks」から来ています。ここでは、受動的独占者と積極的独占者を区別しています。 Validator-as-Proposer モデルでは、バリデーターは、ペイロードを構築する権利を求めるビルダーの入札を単に聞く受動的独占者として考えることができます。 ET によって実装されたような 検証者と提案者が分離された モデルでは、チケット所有者は アクティブな独占者 になり、クインタスとコナーによれば、「ブロックに含めるにはいくらかの料金を支払う必要があります (独占価格 )。リソースが限られている場合に有利なスタートを切るには。」

クインタスとコナーはさらに次のように指摘しました:

アクティブ独占とパッシブ独占の違いについての合理的なモデルはありません。この違いは、検証者が観察した動作に由来するものです。長期的には、バリデーターは積極的な独占者として機能し、合理的に行動する可能性があります。一方で、外部の評判の問題により、これが実現できない可能性があります。

言い換えれば、長期的にはバリデーターが合理的である傾向がある場合、提案者としてのバリデーターと提案者としてのチケット所有者の違いはそれほど大きくない可能性があります。合理的傾向に関するこの加速主義的な議論は実際に十分に確立されていますが、バリデーターが持つ基本的な特性は、バリデーターが積極的な独占になることを完全に妨げるのでしょうか?これは私の意見ではまだ未解決の質問であり、私は最近、レインボーステーキングフレームワークの下でのバリデーターの役割をさらに細分化することを試みることによって、この問題に対処しました。バリデーターが体現する可能性のあるさまざまな役割 (証明者として、検閲抵抗プロデューサーとして、ペイロードプロデューサーとして) の間に補完性がない場合、なぜバリデーターが本質的に何者でもないのかについてのより強力な議論が存在します。積極的な独占に向けて、そしてなぜこれらの役割を分離することが良い考えなのかを説明します。 結論

バリデータと提案者が分離されている世界では、プロトコルによって採用された提案者は、ビルドの役割を別のエンティティであるビルダーに再び委任できます (提案者が部分ブロックオークション

)

などの異なる割り当てメカニズムの場合のフラクタル構造。要約すると、市場構造や割り当てメカニズムについて話すとき、どの市場に関心があるのか​​を明確にする必要があります。提案 の権利を割り当てる市場、それとも建設権を割り当てる 市場でしょうか。

私は、ePBS の実装は、より広範な施行チケットや検証者と提案者の分離などの他のオプションと比較して、全面的に検討されるべきだと考えています。 ePBS は、トラストレス パスへのアクセスの提供や、さまざまなメカニズム (スロット オークションなど) の採用を可能にするなど、現在の MEV-Boost 市場のいくつかの側面を改善します。ただし、ePBS は主に建築権の分配に関係しており、おそらくこれはプロトコルが考慮すべきことではありません。提案権を割り当てるだけで十分な場合があります。

以上がPBSの市場構造を再考し、ePBSの設計を改善するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。