イーサリアムのコンセンサスとMEVの駆け引きは、PoWからPoSへの移行が開始されたあの日から始まった……
TechFlow厳選深潮セレクト
イーサリアムのコンセンサスとMEVの駆け引きは、PoWからPoSへの移行が開始されたあの日から始まった……
MEVの再分配市場メカニズムを設計するだけでなく、バリデータのより一層の分散化をどう実現するか、また検閲耐性をどう高めるかについても考慮する必要がある。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Tia、Techub News
MEV問題の解決プロセスは、実質的にブロックスペースの分配ルールを再設計することに他ならない。MEVについてはもはや皆様も見慣れた存在となったかもしれないが、イーサリアムにおけるMEVガバナンス提案が何を論じているのかを理解するには、依然としてある程度の背景知識が必要となるだろう。そこで本稿では、イーサリアムがPoSへ移行した後に登場した一連のMEVガバナンス提案（PBS、ePBS、PEPCなど）を整理し、読者の皆様に背景情報を提供したい。
PBS（Proposer-Builder Separation）
イーサリアムのマージ以前において、MEVへの対処方法の一つとしてFlashbotsが開発したMEV-Gethが用いられていた。MEV-Gethとは、go-ethereumクライアントを改変したものであり、その核心的な考え方は、マイナーが自らの本来業務である採掘に集中し、MEV争奪に直接関与しないようにすることで、潜在的なチェーン再編問題を回避することにある。MEV-Gethの仕組み自体は非常にシンプルで、市場ベースの解決策と言える。すなわち、マイナーがブロック生成を行う際、Searcherが提出したトランザクションバンドルの利益額に基づいて選択を行うというものだ。この巧妙な市場メカニズムを通じて、関係者全員が利益を得る一方で一定の制約も受け入れることになる。確かにSearcherはその利益の一部をマイナーに支払わなければならないが、その代わりに自身の成果がマイナーによって盗まれないというより高い安全性を確保できる。Searcherという利益の主要源が囲い込まれることで、マイナーもまた受動的にMEV-Gethを利用し始め、さらにMEV-Gethの仕組みによる制約下に置かれることになる。MEV-Gethはマイナーのホワイトリストを管理しており、このリストに載っているマイナーのみがSearcherからのバンドルを受け取ることができる。そして、Searcherの成果を盗むようなマイナーをホワイトリストから除外することで、MEV利益の横取りを防ぐのである。
しかし、マージ以降は、ブロック生成者が検証者の中からランダムに選ばれる「proposer」となるため、信用による制約手段（＝proposerによるMEV横取り防止）はもはや機能しなくなる。
そこで考えられる解決策の一つは、ブロック内容を検証者に対して非可視化することである。このアイデアをさらに洗練させたものがPBS（Proposer-Builder Separation：提示者と構築者の分離）である。PBSでは、proposerとしての検証者の責務をさらに分解し、「ブロック構築」と「ブロック提案」に分け、複雑かつ利害関係が絡みやすい構築作業を外部のbuilderに委託する。これにより、proposerの仕事は単純になり、builderが提出したブロックの利益額に応じてどれを選ぶかを判断するだけとなる。
当初、イーサリアムはマージ時にPBSをプロトコルに内蔵しようとしたが、潜在的な複雑さからその計画は一旦棚上げされた。そのため、Flashbotsが開発したMEV-BoostがPBSの実現手段として登場する余地が生まれた。現在、PBSはMEV-Boostを通じて実装されている。この仕組みにはbuilderやproposerに加え、重要なもう一つの役割——relay（中継者）が存在する。builderはブロックをproposerに直接送信せず、第三者のrelayを介して伝達するのである。
その他にも解決すべき課題がある。例えば、builderがproposerに報酬を確実に支払う仕組み、あるいは最終的にproposerにブロック内容を開示することで、proposerが空ブロックを提出して罰則を受けることを防ぐ仕組み。また、builderが提出したブロックが実際にビーコンチェーンに取り込まれることを保証する仕組みなども必要となる。こうしたbuilderとproposer双方の権益を守る仕組みは、主にrelayによって実現される。
builderはブロックをrelayに送信し、relayは各ブロックがもたらす利益に基づいて順位付けを行い、最も利益の高いブロックのヘッダーをproposerに送信することで、proposerがブロック内容を事前に知ることができないようにする。proposerがそのブロックヘッダーに署名してコミットメントを行った後、初めてrelayは完全なブロック内容をproposerに開示する。builderからproposerへの報酬支払いも、relayの仲介があってこそ確実に実行可能となる。報酬支払いのトランザクションはブロック内に含まれるが、proposerはブロック内容を見ることができないため、relayが事前に確認を代行する必要があるのだ。
In-protocol と out-of-protocol
MEV-Boostが構築する市場に参加するためには、検証者はイーサリアムのコンセンサスクライアントと実行クライアントに加えて、イーサリアム公式ではない第三者のMEV-Boostプログラムを別途実行する必要がある。これが現在のPBSの奇妙な点であり、プロトコル外の第三者がイーサリアムのコンセンサス形成ルールに実質的に関与しているということだ。所有権の観点から見れば、これは極めて異常な状況である。
これはまた、プロトコルの「信頼性」に関する考察を促す。信頼性とはどのように強化され、あるいは他のメカニズムによっていかにして侵食されるのか。MEV-Boostはまさにその好例であり、外部のプロトコルが既存の仕組みを変更する可能性を示している。プロトコル自体が遅れを取るようになると、こうした変更は外部から自然に発生する。外部のメカニズムは必ずしも現在の市場ニーズに合致しているが、それが本当に信頼できるのか、潜在的な問題を防ぐために厳密に設計されているのか、あるいはむしろプロトコルを破壊するリスクすらあるのか、これらはすべて未解決の問いである。
中央集権化されたRelay
MEV-Boostが最も批判されている点は、中央集権化されたrelay市場の存在である。このような構造は信頼の問題を引き起こす。builderはrelayが自分のMEVを盗まないと信じなければならず、proposerもまたrelayから受信して署名するブロックヘッダーが有効なものだと信じなければならない。しかし、極めて重要な役割を果たしているにもかかわらず、relayには経済的インセンティブがほとんどなく、運営には相当なコストがかかる。昨年にはまだ11のrelayがイーサリアムネットワークを支えていたが、現在では9つにまで減少している。
注目に値するのは、relayがノンパーミッション型ではないことだ。Edenのようなrelayは自社のbuilderのみを中継する。一方、bloXrouteなどのrelayはフロントランニングやサンドウィッチ攻撃に関連するトランザクションをフィルタリングすると公言している。ある意味で、relayは一定のルール制定権を持っているとも言える。
データ出典：Rated Network
また、Liveness（活性）の観点から言えば、relayの存在により、builderとproposer間で原子的な確定性を保証できない。仮にproposerがブロックヘッダーにコミットメントを署名し、builderもペイロード内容を提供したにもかかわらず、relayのミス（悪意の有無を問わず）によってその内容が timely に提出されなかった場合、builderとproposerの両方が損失を被ることになる。
ePBS：PBSをイーサリアムプロトコル内に統合する
relayの中央集権化問題を解決する目的でも、あるいは外部の仕組みをプロトコル内に取り込む目的でも、PBSをイーサリアム内部に封入するePBS（execution-layer PBS）は必然の選択肢となりつつある。現在、ePBSはもはや議論上の提案ではなく、イーサリアムEIPエディターにより正式にEIP番号（EIP-7732）が割り当てられている。
ePBSは、proposerとbuilderがブロック構築権の委託を信頼なしで行えるインフラを提供する。もともとプロトコル外に存在していたbuilderの役割がプロトコル内に組み込まれ、検証者のうち新たにbuilderという役割が分離される。プロトコル内に組み込まれたbuilderも、他の検証者と同様にイーサリアムにステークする必要がある。元々のコンセンサス層におけるproposerの責任を分割するため、ePBSの実現にはコンセンサス層の改修が必要となる。ここで、builderは実行ペイロード（そのブロックで実行されるべきトランザクションの最終リスト）の構築を担当する。proposerの責務はビーコンブロックの提案である。具体的な流れは以下の通り：
-
Proposerに選ばれたことを確認後、Inclusion List（IL：そのスロット内で必ず含めるべきトランザクションのリスト）を作成し、ブロードキャストする。
-
builderたちは、execution payloadを含むブロックハッシュと、proposerへの報酬支払いの約束を含む「SignedExecutionPayloadHeader」をproposerに送信する（execution payloadはILを満たしていなければならない）。
-
proposerは、複数のbuilderから送られてきた「SignedExecutionPayloadHeader」の中から一つを選択し（通常はproposerへの支払い額が最も高いもの）、それを含んだビーコンブロック「SignedBeaconBlock」をブロードキャストする。
-
witness（検証者）が検証の義務を果たす。
-
Aggregatorsがattestation aggregatesを提出する一方で、builderがexecution payloadをブロードキャストする。
-
PTC（Payload Timeliness Committee：各スロットにおいて512人の検証者が選ばれて構成される）が、builderが timely にexecution payloadを開示したかどうかを確認し、その結果をブロードキャストする。
ePBSは、提唱から最終的にEIP番号を取得するまでに何度も議論を重ねてきた。当初、Vitalikが2021年6月にPBSを提唱し、4か月後にTwo-slot方式を完成させ、さらに3か月後にSingle-slot PBSを発表。そして2023年7月になって、ようやくPTCのアイデアが正式に提唱された。
PEPC（Protocol-Enforced Proposer Commitments）
もちろん、ePBSに反対し、別の代替案を支持する立場もある。PEPCがまさにそれである。ePBSは特定のルールをプロトコルに固定化するのに対し、PEPCではproposerが「プログラマブルなブロック構築権」を販売する。
PEPCはbarnabeが2022年10月に提唱したものである。barnabeは、もしPBSの仕組みをプロトコル内に実装するならば、「自分がブロックを構築したらxxETHを返す」といった特定の信頼信号を実装するのではなく、信頼できる信号の伝達を可能にする汎用的なメカニズムを設計すべきだと主張する。
PEPC（Protocol-Enforced Proposer Commitments）という名前が示す通り、builderおよびproposerの権益を守る仕組みは、proposerがプロトコル内で提出するコミットメントによって実現される。これらのコミットメントはオンチェーンで検証可能であり、主に「BEACONROOT」オペコードによって実現される。これはより汎用的な仕組みであり、コミットメントの内容はブロック構築権の全面的委託でも、一部のブロック領域の販売でもよい。つまりproposerは、プログラマブルな形でブロック構築権を販売するのである。
まとめ
以上が、PBS、ePBS、PEPCについての簡単な紹介である。プロトコル設計の観点からは、MEVの再分配市場を設計するだけでなく、検証者の分散化の促進や、検閲耐性の向上も同時に考慮しなければならない。また、設計上には多くのトレードオフが存在する。すでにEIP番号を取得したePBSを例に挙げても、中央集権化したrelayという課題は解決できたものの、プロトコル外のrelayという重要な第三者の存在は本当にネガティブな側面だけだったのだろうか？ 例えばbuilderの支払いメカニズムに関して言えば、relayを用いる方式の方がePBSよりも優れている可能性がある。なぜならePBSは事前支払い（pre-payment）方式であり、builderが極めて高利益のブロックを構築した場合、その恩恵をproposerに十分に還元できない可能性があるからだ。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@News_Techub
