イーサリアムプロトコルのその先へ：プロポーザー・ビルダー分離

このプレゼンテーションでは、イーサリアムのブロック生成が、シンプルなモデルから、バリデータ、ビルダー、サーチャー、リレイが関与する洗練されたサプライチェーンへとどのように進化してきたかを説明します。イーサリアム財団のBarnabé Monnot氏が、プロポーザー・ビルダー分離が存在する理由、MEV-Boostリレイがプロポーザーとビルダーの関係をどのように仲介するか、そして信頼への依存を減らし、検閲耐性、MEVの分配、バリデータの分散化を向上させるために、プロトコル内でどのような解決策が模索されているかについて解説します。

このトランスクリプトは、CBERフォーラムによって公開された元のビデオのトランスクリプト (opens in a new tab)のアクセシブルなコピーです。読みやすさを考慮して軽く編集されています。

はじめに (0:00)

私の名前はBarnabé Monnotです。プロトコルの外側で何が起きているか、特にプロポーザー・ビルダー分離 (PBS) の概念と、それがリレイや多くのオフチェーンインフラストラクチャを用いてどのように運用されているかについて少しお話しします。

私はプロトコルを、特定の力を持つ抽象的なオブジェクトとして考えるのが好きです。プロトコルが持つ力の一つは、特定の参加者に権利を与えることができるという点です。前のセッションで、プロトコルがバリデータにコンセンサスの義務を果たす権限を与えることを見ましたが、彼らが行うのはそれだけではありません。トランザクションをブロックに詰め込む必要もあります。私たちはこれを実行の義務と呼んでおり、このトークではそこに焦点を当てたいと思います。

なぜバリデータはビルダーを利用するのか (0:46)

興味深いのは、プロトコルがこれらの権利を生み出し、バリデータに与えているにもかかわらず、実際には多くのバリデータがその権利を自ら行使しないことを選択しているという点です。彼らは、自分の代わりにその権利を行使する役割を他の誰かに委ねることを選んでいます。そして、イーサリアムにおいてその「他の誰か」はビルダーとして知られています。

つまり私たちが目にしているのは、バリデータがコンセンサスの義務を自ら果たし続ける一方で、実行の義務はビルダーに引き継ぐことを決定しているという状況です。これは実際、非常に大きな市場です。現在、ブロックの約90%が外部のビルダーによって構築されており、これはマージの3ヶ月後である2022年12月頃から続いています。ビルダーからバリデータへの支払いの中央値は、1ブロックあたり約120ドルです。毎日100万ドルが支払われており、12秒ごとに、この市場で1人のプロポーザーと1人のビルダーの間で何らかの合意に達する可能性があります。

本日は、なぜバリデータがビルダーを利用するのか、その関係がどこから来ているのかについて議論したいと思います。その過程でMEVとサーチャーについても少し紹介します。その後、この関係がどのように仲介されているかを説明し、現在存在するリレイや、私たちが検討しているプロトコル内の解決策についてお話しします。また、少し視点を広げてみたいと思います。なぜなら、こうした状況を見ると「これは非常に恐ろしい、分散化はどうなるのか？」と考えがちだからです。これらはトレードオフとして行われているものの、私の意見では正しい方向に向かっているということをお伝えしたいと思います。

単純なモデルとMEV (3:04)

ブロック生成の単純なモデルを考えてみましょう。このモデルでは、リーダー選出プロセスに従ってバリデータが選ばれ、メンプールからのトランザクションのリストを含むブロックを作成する必要があります。最も単純なモデルでは、関係者は実質的に2者しかいません。メンプールを監視しているバリデータが、ブロックを作成する順番が来たときに、最も高い手数料を支払うトランザクションを取り出して追加します。通常、あまり洗練されていないパッキングアルゴリズムが使用されます。

過去5年間で非常に劇的に観察されたのは、これがプロデューサーに多大な権力を与えるということです。特に「ラストルック（最後に見る権利）」の力です。彼らはユーザーが何をしたいのかを見ることができます。例えば、ユーザーが何かをスワップしたいと考えているのを見て、その情報を利用して自分自身の利益を抽出することができます。

最良のケースでは、この利益はアービトラージのような自然な市場機能から生まれます。最悪のケースでは、サンドイッチ攻撃のように、ユーザーのポケットから直接利益を奪うことになります。例えば、ユーザーがユニスワップのような市場でトークンAとトークンBのスワップ注文を出したとします。そのトランザクションは、同じチェーン上に展開されている別の市場との間に価格の不均衡を生み出します。プロデューサーは保留中のトランザクションを見て、別の市場で逆方向のスワップを行う自分自身のトランザクションを挿入し、その過程でアービトラージの利益を懐に入れることができます。

これはプロデューサーに多大な権力を与え、ブロックプロデューサーという立場を非常に価値のあるものにします。このプロデューサーの特権は、現在私たちが**最大抽出可能価値 (MEV)**と呼んでいるものです。

サーチャーの役割 (5:43)

実際には、プロデューサーはどこに価値があるのかを知らないかもしれません。前述の通り、十分な資本がありノードを運用できれば誰でもバリデータになれるため、やや洗練されていないブロックプロデューサーが存在する可能性があります。実際、私はアービトラージのやり方や金融市場について何も知らないかもしれません。私が望むのは、これらの機会がどこにあるのかを誰かに教えてもらうことです。つまり、ブロックプロデューサーとして何をすべきか、最善の行動を競って教えてくれる人々の市場です。

機会を見つけることに非常に長けたこれらのエンティティを、私たちはサーチャーと呼んでいます。彼らはブロックプロデューサーに機会を提示します。サーチャーは、公開されたメンプール、あるいはダークプールやプライベートチャネルを通じて、ユーザーがスワップを行っているのを観察し、バリデータに次のように伝えます。「スワップが発生しています。このスワップとこのアービトラージをアトミックなトランザクションのバンドルにまとめて含めれば、アービトラージから利益を得ることができます。」多くのサーチャーがブロックプロデューサーを説得しようと競争することになります。

このモデルは、サーチャーがプロデューサーを信頼し、バンドルのアトミック性を維持してくれると信じている場合には、実際によく機能します。最近、イーサリアムでサンドイッチ攻撃者たちに2,500万ドルの損害を与えた攻撃について聞いたことがあるかもしれません。その根本的な原因は、攻撃者がバンドルのアトミック性を破り、コンテンツを受け取って再編成や変更を試みたことでした。これは非常に重要な特性であり、プロデューサーがこのアトミック性を破らないと信頼できる場合にのみ成り立ちます。

なぜビルダーが必要なのか (8:16)

プロデューサーが信頼できない場合はどうすればよいでしょうか？マージ後のイーサリアムには、ネットワークの約6%を占める、素性の知れないソロステーカーが存在します。サーチャーは、少し危険すぎるため、これらのブロックプロポーザーにバンドルを送信したがりません。

そこで到達した設計は、サーチャーがバンドルを伝え、プロデューサーがそれをブロックに含めるのではなく、ブロック全体を代わりに作成するというものです。そうすれば、プロデューサーはブロックに盲目的に署名するだけで済みます。中に何が入っているかを知る必要はなく、ビルダーが良いブロックを提供してくれていると信頼するのです。

現在では、さらに深いチェーンが存在しています。一方の端にバリデータ、もう一方の端にユーザーがおり、その間には時間の経過とともに密度を増し続ける仲介者のチェーン全体が存在します。ビルダーが実行部分を担い、バリデータがコンセンサスを担います。

MEV-Boostリレイの仕組み (13:01)

あなたがプロポーザーであり、この市場に参入したいとしましょう。このブロック生成サービスは、古典的な公平交換問題です。2つの当事者が合意に達しようとしていますが、互いを信頼していません。古典的な文献によれば、信頼できる第三者なしに公平な交換を行うことはできません。

今日、私たちが信頼できる第三者として使用しているのが、リレイと呼ばれるものです。つまりMEV-Boostリレイです。MEV-Boostは、ビルダーとバリデータ間のやり取りを仲介するプロトコルの名前です。リレイは中間に位置し、双方から合意が成立することを保証します。

リレイにはいくつかの役割があります。第一に、ビルダーのペイロードを検証する必要があります。リレイはビルダーが作成しているブロックを平文で確認し、それが有効であり、ネットワークに提案できることをチェックできます。オプティミスティック・リレイと呼ばれるバリエーションもあり、この場合、リレイは即座に有効性をチェックするのではなく、ブロックが最終的に無効であった場合に備えてビルダーに担保を要求します。

第二に、ビルダーはバリデータに選ばれるビルダーになるために競争し、入札を行います。リレイは入札の転送者として機能し、入札をバリデータに送信します。そして最後のステップで、バリデータがリレイからの入札の1つを選択すると（バリデータは好きなだけ多くのリレイに接続できます）、ブロックの内容を知らないまま署名し、署名された入札をリレイに送り返します。この署名された入札を受け取ると、リレイはブロックをネットワークにリリースできます。

リレイの経済学は複雑です。公共財のように無料のものもあります。一方で、収益モデルを開発したものもあります。例えばUltrasoundリレイには「入札調整」があり、最高入札額と2番目に高い入札額の差額を収益として受け取ります。

信頼とリレイ (17:01)

リレイはシステムにおける信頼できる第三者です。仮にリレイが無効なブロックを提供したとしましょう。署名されているため、人々はすぐにそれに気づき、非常に迅速にそのリレイから切断します。何らかのフォールト証明をゴシップ（伝播）することさえ可能です。5ブロック以内に、リレイが適切に機能しなければ、人々はそれを信頼するのをやめ、単に切断するでしょう。

したがって、これは信頼に基づきつつも、ある程度迅速に置き換え可能であるという前提に立っています。リレイはバリデータではありません。必ずしもステークを持っているわけではなく、イーサリアムと何の関係も持つ必要はありません。今日私たちが知っていて愛着のある人々かもしれませんが、明日は誰になるかわかりません。

プロトコルへのPBSの組み込み (20:01)

私たちは、リレイの信頼できる第三者としての地位を排除しようとしています。イーサリアムには私たちが好む信頼できる第三者が存在します。それはイーサリアム自体です。リレイの役割を本質的に組み込み、それへの依存をオプションにするような、プロトコル内の解決策を設計することができます。

現在、イーサリアムプロトコルはバリデータが行っていることの一部を認識していますが、ビルダーのネットワークについては完全に盲目です。私たちは、プロポーザーとビルダーのやり取りにおいて、イーサリアムプロトコルが信頼できる第三者となるように推進しようとしています。その意味で、もはやリレイに依存する必要はなくなります。

ビルダーの制約と分散化の増幅 (22:05)

全体像を把握することは重要です。すべてのレイヤーで異なるゲームが展開され、異なるプレイヤーが互いにお金を奪い合っているように見えます。これは伝統的な金融の繰り返しなのでしょうか？私は、これらのトレードオフが悪いところから来ているわけではないと主張したいです。これらは、システムをスケーリングし、より有用にするために役立つと私たちが考える特性に寄り添おうとしているのです。

ヴィタリックは、ブロックチェーンが提供する可能性のあるサービスの根本的な非対称性について語りました。コンセンサスには、チェックを維持する非常に大規模で分散化された人々の集団が必要です。しかし、一部のサービスでは、1人が仕事をうまくこなし、他の全員がその仕事がうまく行われたことを検証するだけで十分です。ブロックを作成するビルダーは1人だけでよく、その後、全員がそれが有効であることを検証できます。

現在、明らかに3つの支配的なビルダーが存在します。Beaver Build、Titan、そしてrsync Builderです。これは良い状態でしょうか？そうとは言えません。私たちはもっとうまくやれるはずです。しかし、バリデータと同じ数のビルダーが存在すると想像するのは現実的でしょうか？おそらくそうではありません。

私たちが本当に望んでいるのは、誠実な多数派の仮定を必要としないタスクを実行できる強力な当事者が中間に存在するという事実を、バリデータの薄いレイヤーが制約し、活用することです。

ビルダーを制約するためのいくつかのアイデア：

• インクルージョンリスト — バリデータがビルダーに対して「これらのトランザクションをブロックに含めなければならない」と指示するもの
• 部分的なブロック構築 — ビルダーがすべてのスペースを独占しないように、完全なブロックを分割するもの
• サードパーティへの依存の削減 — リレイの役割をプロトコルに組み込むこと

バリデータの分散化を増幅するために：

• アテスター・プロポーザー分離 — デフォルトでバリデータをブロックプロデューサーにするのではなく、異なる人々のグループを選んでブロックプロデューサーにし、役割を分離すること
• 改善されたステーキングメカニズム — 現在のイーサリアムのステーキングは少し初歩的であり、改善の余地がある

質疑応答と締めくくり (27:03)

聴衆からの質問：伝統的な金融の世界では、セトルメントの時間が2日から1日に短縮されています。セトルメントの時間を12秒からさらに短い間隔に短縮することで、フロントランニングの問題のいくつかに対応できるでしょうか？

人々はこれについて議論しており、それを**事前確認 (pre-confirmations)**と呼んでいます。アイデアとしては、トランザクションを送信すると、誰かが「あなたはこの価格で、この状態で含まれています」と教えてくれるというものです。問題は、プロトコルが実行されている速度よりも早くセトルメントを行うことはできないということです。12分よりも早いファイナリティのセトルメントを得ることはできません。ブロックタイムよりも早く動くことはできないのです。

ブロックタイムを短縮することは困難です。なぜなら、バリデータレイヤーを可能な限り分散型に保ちたいと考えており、短縮することは単にハードウェア要件を増加させるだけだからです。