本文へ移動
Financial Context Wiki

提案者とビルダーの分離（PBS）

提案者とビルダーの分離は、ブロック構築とコンセンサス上の提案を分けます。Ethereum の MEV-Boost 市場、プロトコル内 PBS との違い、中継、検閲、集中、スロット逸失のリスクを解説します。

更新日

教育目的に限られ、投資またはバリデータ運用の助言ではありません。PBS は MEV、検閲、スロット逸失、中継、ビルダー集中、プロトコル設計のリスクをなくしません。

直接的な回答

提案者とビルダーの分離（PBS）は、ブロック生成の2つの仕事を分ける設計です。ビルダーはトランザクションを選択・順序付けし、実行ペイロードを構築します。コンセンサスによってそのスロットに選ばれた提案者は、ペイロードのコミットメントを選び、ブロック提案に署名し、完全なブロックを配信するか配信させます。提案者は引き続きコンセンサス上の義務を負うバリデータです。ビルダーは別の市場上の役割であり、現在の外部市場ではそのスロットのバリデータである必要はありません。

Ethereum では、現在使われている仕組みと提案中のプロトコル変更を区別する必要があります。MEV-Boost はプロトコル外 PBS です。バリデータのミドルウェアが、ビルダーと提案者のオークションを仲介するリレーに問い合わせます。プロトコル内 PBS（ePBS）では、交換と執行を Ethereum のコンセンサス規則に組み込みます。事実確認日現在、Ethereum はプロトコル内 PBS を最終仕様のない研究段階と説明しており、EIP-7732 もドラフト提案です。

PBS の目的は、各バリデータが高度な MEV 探索・ブロック構築基盤を運用しなくても、競争的なブロック価値にアクセスできるようにすることです。提案者間の集中化優位を弱め得ますが、MEV はなくなりません。専門的な構築をビルダー市場へ移す一方、中継への信頼、ビルダーと注文フローの集中、検閲、タイミング、ペイロード可用性という課題が生じます。

仕組み

  1. ビルダーが構築し入札します。ビルダーは公開トランザクションに加え、多くの場合は非公開の注文フローやサーチャーのバンドルも受け取ります。候補ブロックをシミュレーションし、トランザクションを並べ、有効な実行ペイロードを作り、提案者への支払額を示す入札を添えます。
  2. 現在の市場はリレーが仲介します。MEV-Boost 方式では、リレーがビルダーから完全なペイロードを受け取り、独自方針で提出物を検査し、最初はトランザクション本文を提案者に見せず、署名済みヘッダーと入札を提示します。MEV-Boost は設定された複数のリレーに問い合わせ、利用可能な応答を比較できます。
  3. 提案者がコミットメントを選びます。提案者は外部入札とローカル構築ペイロードを比較し、最低入札額などの設定を適用できます。外部入札を受け入れると、選択したペイロードヘッダーにコミットするブラインド化ビーコンブロックへ署名し、その後は別のトランザクションに差し替えられません。
  4. ペイロードが公開・検証されます。署名済みブラインドブロックを受け取ったリレーは、完全な実行ペイロードを返すか公開します。コンセンサスクライアントと実行クライアントがブロックを検証します。遅延、利用不能、無効なペイロードは公開を妨げ、スロット逸失を招く場合があります。
  5. 支払いとコンセンサスは別です。ビルダー入札は、提案者が設定した手数料受取先への実行レイヤー上の支払い約束です。コンセンサスレイヤーの提案報酬と罰則は別のプロトコル規則に従います。ビルダーを選んでも、ファイナリティやフォーク選択の権限は移りません。

Builder API は、バリデータ登録、ヘッダー取得、署名済みブラインドブロック送信などのインターフェースを標準化します。API 仕様自体は信頼保証ではなく、リレーの参加許可、検証、データ処理、障害時の挙動は実装と配置に依存します。

例

あるバリデータのローカル実行クライアントが 0.03 ETH 相当のペイロードを構築でき、利用可能なリレー入札が 0.05 ETH、0.08 ETH、0.07 ETH だとします。遅延と障害コストを無視すると、最高の外部入札はローカル構築より 0.05 ETH の粗利益増を提示します。

粗利益増 = ビルダー入札 - ローカルペイロード価値 = 0.08 ETH - 0.03 ETH = 0.05 ETH

提案者は 0.08 ETH のヘッダーを選び、完全なトランザクション一覧を見ずにブラインドブロックへ署名します。その後リレーがコミット済みペイロードを提供または公開します。ブロックが有効かつ期限内ならネットワークが処理し、設定された手数料受取先がビルダー支払いを受け取ります。提案者はコンセンサス上の役割を引き続き担い、ブロックが正規化または確定するかをビルダーが決めるわけではありません。

この比較は純収益を保証しません。リレー遅延、公開失敗、ソフトウェアの挙動、支払い検証、スロット逸失の確率と費用が影響します。提案者の方針を満たす外部入札が期限内にない場合、適切に設定されたクライアントはローカルペイロードへ切り替えられます。

リスク

  • リレーへの信頼と可用性：現在の MEV-Boost リレーは公正交換を仲介し、完全なビルダーペイロードを見て、参加・検証方針を適用し、時間制約の厳しい経路に位置します。リレーの多様化は単一エンドポイントへの依存を減らしますが、すべてのリレーの誠実性や可用性を保証しません。
  • ビルダーと注文フローの集中：優れた非公開注文フロー、低遅延、資本、シミュレーション基盤を持つビルダーほど多くのブロックを獲得し得ます。提案者収益を競うオークションだけでは、分散した構築や中立的な取引収録は保証されません。
  • 検閲とプライバシー：ビルダーやリレーは取引を除外でき、非公開注文フローが仲介者に見える場合があります。提案中の包含リストは別のプロトコル設計であり、現在の PBS がすべての有効な取引の収録を自動的に強制するわけではありません。
  • タイミング、非公開、スロット逸失：高い入札も、コミット済みペイロードが有効で期限内に届かなければ価値がありません。ビルダーの非公開、リレー障害、ネットワーク遅延、誤設定は報酬を減らし、提案者のスロット逸失につながります。
  • 変化するプロトコル前提：EIP-7732 などの ePBS 提案は支払い、公開、検証、フォーク選択の仕組みを変えます。まだドラフトなので、運用者と研究者はロードマップの表現を現行保証とせず、導入済みフォークの仕様を使う必要があります。

よくある誤解

誤解 1：PBS は MEV をなくす

PBS はブロックを構築する者と提案する者を分けます。ビルダーは引き続き MEV 抽出を競い、設計は MEV がバリデータを集中させる影響を抑え、入札を通じてブロック価値を分配しようとします。

誤解 2：ビルダーがブロックを提案または確定する

ビルダーが作るのは実行ペイロードです。スロット提案者がブロック提案に署名し、他のバリデータがアテストし、Ethereum のフォーク選択とファイナリティ規則が正規チェーンを決めます。

誤解 3：MEV-Boost はすでにトラストレスでプロトコル強制の PBS である

MEV-Boost はリレーを使う外部ミドルウェアです。Ethereum のコンセンサスを変えずに PBS を近似するため、信頼と障害の前提は将来のプロトコル内設計と異なります。

誤解 4：表示された最高入札が常に最善である

入札額は1つの要素にすぎません。有効性、配信時刻、リレーの挙動、ローカル代替、手数料受取先の設定、スロット逸失リスクが実際の結果を左右します。

関連トピック

出典

ナビゲーション

Wiki を検索...