イーサリアムの研究者とa16zの研究者が共著：ブロックスペースの割り当てメカニズム
TechFlow厳選深潮セレクト
イーサリアムの研究者とa16zの研究者が共著：ブロックスペースの割り当てメカニズム
ブロック空間の割当メカニズムはMEVにどのように影響するか？
Web3業界の深掘り報道に専念し潮流を洞察執筆：mike、イーサリアム研究者；Pranav Garimidi、Tim Roughgarden、a16z 研究者
翻訳：0XNATALIE
イーサリアム研究者の mike と a16z 研究者の Pranav Garimidi、Tim Roughgarden が共同で執筆した『On block-space distribution mechanisms』は、ブロックスペースの分配メカニズムが MEV に与える影響を体系的に考察しています。まず、プロトコル内メカニズムによるブロックスペース分配の必要性を説明し、「誰が、何を、いつ、どこで、どのように」（W^4H）という枠組みを使って既存の分配スキームを評価・比較します。さらに、実行チケットモデル（execution tickets）が MEV 認知度と分配の公平性の間でいかにバランスを取るかについて深く分析します。以下がこの論文の翻訳です。
TL;DR： ブロックスペース、すなわち取引の包含容量は、ブロックチェーンが生成する主要なリソースです。暗号エコシステムの拡大と専門化に伴い、ブロックスペースの効率的な利用から生じる価値（MEV）は、許可不要コンセンサスメカニズムの経済学において重要な役割を果たすようになっています。研究コミュニティは「プロトコルは MEV をどう扱うべきか」について多くの議論を行ってきました（関連研究参照）。ここ数年の議論は「盲人象を撫でる」ような状況であり、さまざまな視点、解決策、理論が提示されていますが、それぞれ断片的で相互に比較することが困難でした。本稿の前半では、一連の中核的な問題を抽出し、既存の提案がそれらにどう対応しているかを探ることで、「MEV という象」の全体像を提示することを目指しています。後半では実行チケットによって可能になる分配メカニズムに焦点を当て、重要な新たな洞察——すなわち、プロトコル内 MEV オラクルの品質とメカニズムの公平性の間にトレードオフがあること——を示します。
構成： 第1節では、Proof-of-Stake の「最終形態（endgame）」の一環として、なぜプロトコル内メカニズムによるブロックスペース分配が必要なのかを説明します。第2節では、ブロックスペース分配メカニズムを評価するための5つの次元——「誰が、何を、いつ、どこで、どのように」（W^4H）——を提示します。第3節では、ブロックビルダーの選定方法、特に実行チケットモデルに注目して探ります。第4節では、まとめとともに今後のオープンな問題を提起します。
注意： 本稿は長めで技術的内容を含んでいます。読者は最も興味のある部分に集中することをお勧めします。第1、2、4節では、既存の提案および我々が提示する分析手法の広範な概観を提供しています。第3節（本文全体の約44%を占め、数学的内容は100%含まれる）では、実行チケット設計によって可能になる分配メカニズムの詳細な分析を行っています。この部分は順を追って読んでも、独立して読んでも、あるいは完全にスキップしても構いません——選択はあなた次第です！
(1) 動機
この複雑な話題に入る前に、まずブロックスペース分配メカニズムの必要性について簡単に説明しましょう。Proof-of-Stake において、バリデータの役割はブロックの生成と投票です。以下の図は Barnabé の記事『More pictures about proposers and builders』からの引用で、これらを「提案（proposing）」と「証言（attesting）」権として表現しています。
1）何を
ブロックスペース分配メカニズムとは、プロトコルが「提案」または「ブロック構築」権の所有者を決定するプロセスのことです。Proof-of-Stake プロトコルは通常、以下のいずれかのルールを使用します：
-
ブロックスペース（提案）権 — バリデータをランダムに選出し、リーダーとして次のブロックを作成できるようにする。
-
投票（証言）権 — すべてのバリデータが特定の時間窓内で、正規のヘッダーであると考えるブロックに対して投票する。
バリデータはこれらのタスクを遂行することで報酬を得ます。報酬の出所に応じて、コンセンサス層（プロトコル発行、例：新しく鋳造されたETH）または実行層（取引手数料とMEV）に分類できます：
コンセンサス層
a. 証言報酬 — （attestation deltas 参照）。
b. ブロック報酬 — （get_proposer_reward 参照）。
実行層
a. 取引手数料 — （gas tracker 参照）。
b. MEV（取引の並べ替え）— （mevboost.pics 参照）。
報酬 1a、1b、2a はよく知られており、「プロトコルの視野内」にあります。一方、MEV 報酬はより難しく、取引の並べ替えを通じて実現される価値を完全に捉えるのは困難だからです。他の報酬とは異なり、ブロック内の MEV 量は事実上不可知です（許可不要かつ匿名のシステムであるため、各アカウントの所有者や、それに協力して利益を得る可能性のあるオンチェーン外活動を追跡することは不可能です）。また、MEV は時間とともに激しく変動します（例：価格変動など）ため、実行層の報酬はコンセンサス層の報酬よりも分散が大きくなります。さらに、イーサリアムプロトコルは、実装時に取引から生じる MEV の発生や抽出に関して一切の洞察を持っていません。プロトコルの MEV に対する可視性を高めるために、多くのメカニズムが特定のブロック内の MEV を推定しようとしており、これを「MEV オラクル」と呼びます。ブロックスペース分配メカニズムは通常、このようなオラクルを生成する能力を持ち、プロトコルに「MEV 感知」をもたらします。
ここで疑問が生じます。なぜプロトコルは MEV 感知を気にするのでしょうか？ 一つの答えは：MEV 感知により、バリデータの複雑さに差がある場合でも、プロトコルが報酬の均等性を保つ能力が高まる可能性があるからです。たとえば、プロトコルがすべての MEV を正確に燃やすことができれば、バリデータのインセンティブは完全にプロトコルの視野内に収まります（前述の 1a、1b、2a のように）。あるいは、バリデータの複雑さに関係なくすべての MEV を共有するメカニズム（例：mev-smoothing）があれば、より大きく多様で分散化されたバリデータ集合を促進しつつ、MEV 報酬を追加のステーキングインセンティブとして維持できそうです。MEV 感知がない場合、MEV を最も効率よく抽出または平準化できるバリデータ（例：ブロックビルダーとの関係、独自アルゴリズム／ソフトウェア、独占的な注文流へのアクセス、規模の経済など）が不釣り合いに高い報酬を得てしまい、プロトコルに大きな集中化圧力をかける可能性があります。
イーサリアムプロトコルの設計はあらゆる犠牲を払ってでも、分散化されたバリデータ集合を維持しようと努めています。言うまでもありませんが、プロトコルの信頼できる中立性、検閲耐性、許可不要性は、分散化されたバリデータ集合に直接依存しています。
現在のブロックスペース分配
今日のイーサリアムでは、mev-boost が約90％のブロックを占めています。mev-boost を使用すると、プロポーザー（ランダムに選ばれたバリデータリーダー）は、自分のブロック構築権を最高入札者にオークションで販売します。下図はその流れを示しています（リレーは実質的にビルダーの延長であるため、除外しています）。
プロポーザーは、ビルダー（MEV 抽出のために取引の並べ替えを専門とするエージェント）が彼ら自身でブロックを構築するよりも高い報酬を支払ってくれるため、ブロック構築を外部委託することにインセンティブを持っています。ここで「MEV 存在下でのバリデータ報酬の均等性」を維持するという目標に戻ると、mev-boost はすべてのバリデータがビルダーマーケットに参加できるようにしており、個人ステーキング者と専門のステーキングサービスプロバイダー間の MEV 報酬をほぼ同等に保っている——良い！ しかし…
もちろん、mev-boost にはいくつかの問題があり、これらは依然としてイーサリアムコミュニティの一部にとって懸念材料となっています。簡潔に言えば、mev-boost には以下のような副作用があります：
-
リレー — プロポーザーとビルダーの間に存在する、信頼された第三者。リレーへの巨大な依存は、プロトコル全体の脆弱性を高めます。繰り返し、イベント、関与、リレーによって示されている通りです。さらに、リレーには固有の収益源がないため、利益獲得のためのさらなる（そしてクローズドソースの）方法（例：サービスタイミングゲーム、入札調整）が実装されつつあります。
-
プロトコル外ソフトウェアの脆弱性 — リレーに加えて、mev-boost マーケットに参加するにはバリデータが追加のソフトウェアを実行する必要があります。個人ステーキングの標準的なセットアップは現在、4つのバイナリを実行することを含みます：（i）コンセンサスビーコンノード、（ii）コンセンサスバリデータクライアント、（iii）実行クライアント、（iv）mev-boost。これは個人ステーキング者にとって著しいオーバーヘッドを増やすだけでなく、ハードフォーク期間中の依存性も別の潜在的な障害点を提供します。Shapella イベントや Dencun アップグレードを参照すると、プロトコル外ソフトウェアの増加がもたらす複雑さがわかります。
-
ビルダーの集中化と検閲 — これは避けられないかもしれませんが、mev-boost の大規模な採用はビルダーの集中化を加速させました。3つのビルダーが mev-boost ブロックの約95％（すべてのイーサリアムブロックの85％）を占めています。mev-boost は公開入札、第一価格、勝者がすべてを得るオークションを実装しており、高度なビルダー集中化と戦略的入札を招いています。包含リストやその他の検閲防止ツールはまだ導入されておらず、ビルダーは取引の包含・排除に対して極めて大きな影響力を持っています——（censorship.pics 参照）。
-
タイミングゲーム — タイミングゲームは Proof-of-Stake プロトコルの根本的な問題と見なされていますが、mev-boost はステーキングサービスプロバイダーを薄利競争に駆り立てます。さらに、リレー（プロポーザーに代わって mev-boost オークションを行う）は複雑な仲介者として、タイミングゲームを促進します。そのため、特定のプロバイダーとステーキングすることで収益を高められると謳うマーケティングが見られます。
(2) 列挙
必要な「舞台設定」が終わったので、ブロックスペース分配メカニズムの本質にもう少し詳しく迫りましょう。
ブロックスペース分配の要素
ブロックスペースの取得を巡るゲームを考えてみましょう。MEV がエージェントの参加を促し、プロトコル内およびプロトコル外のソフトウェアの組み合わせがルールを定義します。このゲームを設計する際、どのような要素を考慮すべきでしょうか？ この問いに答えるため、私たちは「誰が、何を、いつ、どこで、どのように」という馴染み深い修辞形式（第1節で「なぜ」には十分に答えたはずですが）を使い、これを W^4H 問題と呼びます。
-
誰がゲームの結果を支配するか？
-
プレイヤーが争う商品は何か？
-
ゲームはいつ起こるか？
-
MEV オラクルはどこから来るか？
-
ブロックビルダーはどのように選ばれるか？
これらの質問は単純すぎるようですが、個別に考えると、それぞれがメカニズム設計空間を測る軸となることができます。これを証明するために、過去に探求されたブロックスペース分配メカニズムの異なる種類を強調します。一見無関係に見えるものも、W^4H 問題に対する回答の仕方を理解すれば、それらの関係が明確になります。
実行チケットとその他のアプローチ
多くの異なる提案メカニズムの概要を提示します。ただし、これは周辺文献のごく一部にすぎません——（infinite buffet 参照）。以下については、主なアイデアのみを要約します（詳細は関連研究参照）。
実行チケット
主なアイデア：ブロック構築と提案の権利が、プロトコルが発行する「チケット」を通じて直接販売される。チケット保有者はランダムにサンプリングされ、ブロックビルダーとなり、事前に通知される。チケット保有者は、割り当てられた期間中にブロックを生成する権利を持つ。
ブロックスペースの分離（PBS：Proposer-Builder Separation）
主なアイデア：プロトコルはランダムリーダー選出プロセスを通じてブロック生成権を付与する。選ばれたバリデータは、自分のブロックをビルダーマーケットに直接販売するか、ローカルで構築することができる。ビルダーはオークションで特定のブロックをコミットしなければならない。mev-boost は PBS のプロトコル外実装例であり、当初提案された ePBS はプロトコル内同等物である。
MEV 燃焼／MEV 平準化
主なアイデア：委員会が、プロポーザーがオークションで選んだ入札額に最低値を設定する。プロポーザーに「十分大きい」入札を選ばせることで、MEV オラクルが作られる。MEV は委員会メンバー間で平準化されるか、燃焼される（すべてのETH保有者に平準化される）。
スロット（slot）オークション PBS
主なアイデア：ブロックオークションPBSに似ているが、特定のブロックをコミットせずに、ビルダーマーケットにスロットを販売する——時としてブロックスペース先物とも呼ばれる。ビルダーに特定のブロックをコミットさせないことで、将来のスロットをスロット自体を待たずに前もってオークションにかけることができる。
部分ブロックオークション
主なアイデア：ブロックスペースのより柔軟な単位の販売を許可する。ブロック全体やスロットではなく、プロポーザーが自分のブロックの一部（例えば、アービトラージャーにとって最も価値のあるトップ部分）を販売し、残りのブロック構築は自分で保持できる。Jito のブロックエンジンや Skip MEV lane など、他の Proof-of-Stake ネットワークで稼働している。
APS 燃焼即実行オークション
主なアイデア：Barnabé による新しい提案で、プロポーザーにブロック構築と提案の権利を早期にオークションで販売させる。スロットは早期に（固定時間前に）販売され、特定のブロックのコミットは不要。委員会（MEV 燃焼／平準化と同じ）が入札額が十分に大きいことを保証する。
これらの提案が W^4H 問題にどう答えるかを比較することで、同じ設計空間内の異なる部分であることがわかります。
W^4H の適用：比較分析
各 W^4H 問題について、上記の提案における異なるトレードオフを説明します。簡潔にするため、各提案ごとにすべての問題を分析するのではなく、各問題の線に沿った主要な相違点に重点を置きます。
誰がゲームの結果を支配するか？
-
実行チケット方式では、プロトコルがチケット保有者をランダムに選ぶことでゲームの勝者を決定する。
-
ブロックオークション PBS では、プロポーザー（プロトコルが選んだリーダー）が単独でゲームの勝者を選ぶ。
-
MEV 燃焼メカニズムでは、プロポーザーが依然として勝者を選ぶが、勝利入札額は委員会によって制約され、プロポーザーの裁量が減る。
争われるのは何か？
-
ブロックオークション PBS では、ブロック全体が販売されるが、入札額はブロック内容をコミットしなければならない。
-
スロットオークション PBS では、ブロック全体が販売されるが、特定のブロック内容のコミットは不要。
-
部分ブロック PBS では、ブロックの一部が販売される。
ゲームはいつ行われるか？
-
ブロックオークション PBS では、オークションはスロット期間中に開催される。
-
スロットオークション PBS では、ブロック内容のコミットがないため、多数のスロット（例：32スロット）前からオークションが可能。
-
実行チケット方式では、チケットが固定された事前期間でスロットに割り当てられる。
MEV オラクルはどこから来るか？
-
MEV 燃焼／平準化メカニズムでは、委員会が選ばれた入札額を十分に大きく強制することで、それがオラクルとなる。
-
実行チケット方式では、チケットの総支出額がオラクルとなる。
ブロックビルダーはどのように選ばれるか？
-
ブロックオークション PBS では、外部委託されたブロック生成はすべて「勝者がすべてを得る」分配であり、最高入札者がブロック構築権を得る。
-
実行チケット方式では、多くの異なる分配メカニズムが可能。例えば、オリジナル提案では、チケットがランダムに選ばれ、メカニズムは「チケット数に比例した分配」である。この場合、最高入札者（最も多くのチケットを持つ者）は選ばれる確率が最も高いが、ブロック構築権を保証されるわけではない。
以上が難解に感じられても心配しないでください。次のセクションで、これらの異なる分配メカニズムについてさらに深く掘り下げます。
動機の再確認
続ける前に、最初の動機を再確認しましょう：
ブロックスペース分配メカニズムは、MEV が存在する中でバリデータ報酬の均質性を維持することを目指しています。
これは良い基盤ですが、これが唯一の目標なら、なぜ mev-boost を続けないのでしょうか？ mev-boost にはいくつかのネガティブな側面があり、最終的なプロトコル設計がそれらに耐性を持つ必要があるかもしれません。そこで、ブロックスペース分配メカニズムの他の4つの潜在的な設計目標を強調します：
-
より広範なビルダー間の競争を促進する。
-
バリデータとビルダーの間に信頼できるインタラクションを可能にする。
-
基礎層プロトコルに MEV 認識を組み込む。
-
バリデータ報酬から MEV を完全に除去する。
なお、(1,2,3) は比較的無争ではないものの、(4) はより論争的です（また (3) を前提としています）。プロトコルは MEV 報酬を排除することで、コンセンサス層報酬（プロトコルが制御する部分）がシステム全体のインセンティブをより正確に反映することを確保したいかもしれません。これにはステーキングのマクロ経済学やプロトコル発行などの問題も関わってきます——より政治的な議論です。一方で、MEV 報酬はネットワーク利用の副産物でもあり、MEV はネイティブトークンの価値捕捉メカニズムと見なされることもあります。ここではこれらの問題を解決しようとはせず、異なる答えがメカニズム設計にどう影響するかを探求します。
こうした期待に合致するように、プロトコル設計レベルで何ができるでしょうか？ 上述のように、考慮すべき多くのトレードオフがありますが、次のセクションでは「ブロックビルダーをどう選ぶか？」に焦点を当て、ある面での改善を探ります。
(3) 質問
編集者注： 先ほど述べた通り、このセクションは他の部分より長く、より技術的です——時間（または興味）が限られている場合は、そのまま第4節にジャンプしてください。
部分的目標： 「比例全額払い（Proportional-all-pay）」と「勝者がすべてを得る（Winner-take-all）」という、ブロック提案権を割り当てる最もよく知られた2つの方法の間にある、MEV オラクルの品質とメカニズムの公平性の定量的トレードオフを示すこと。
この目標を達成するために、以下のサブセクションを予定しています：
基礎知識
実行チケットが可能にする分配メカニズムを深く探る前に、まずモデルを構築しなければなりません。以下のようなルールで実行チケットを販売するプロトコルを考えます：
-
価格は1WEIに固定され、
-
チケットは無制限に購入・販売可能。
注意： このバージョンの実行チケットは、実質的に「証明」と「提案」のための2つの独立したステーキングメカニズムを作り出すことに相当します。チケットをプロトコルに再販売できないようにするといった設計上の小さな変更は、市場の運営に大きな影響を与える可能性がありますが、それが本稿の焦点ではありません。ここでは、既存のチケット保有者セットにおけるブロックスペース分配の問題に狭く焦点を当てます。
注目に値するのは、プロトコルの視点から見ると、ブロック生成者と証明者は独立した個体であること——個人はステーキングするかチケットを購入するかを決めることで、プロトコルのどの部分に参加するかを選択しなければなりません。二次チケット市場が、オークション時に構築権をタイムリーに販売する場として発展する可能性があります（今の mev-boost のように）。
さらに、ビルダーはプロトコルと直接やり取りして実行チケットを購入することも選べますが、彼らの資本はアクティブな流動性として、取引所間の裁定機会を捉えるのに適しているかもしれません。そのため、彼らは二次市場でオークション時にブロックスペースを購入することを好むかもしれません。
なぜ私たちはこのような無制限供給・固定価格のメカニズムに限定するのでしょうか？ 二つの理由があります：
1. 複雑な市場がコンセンサス層で実現可能かどうか不明です。クライアントの最適化により、コンシューマ級ハードウェアを持つバリデータでもネットワークに参加できます。この要求は、高速オークション、バインディングカーブ、その他の可能なチケット販売メカニズムと互換性がないかもしれません。販売されたチケットの数、チェーン上でのチケット販売に含まれる MEV（メタMEV？！）、チケット販売のタイミング（とタイミングゲーム）に関する問題は、実行層の関心事に近いように思え、イーサリアムコンセンサスがハードウェア要件を限定しつつ合理的に実現できる問題とは言いにくいでしょう。
「ET関連取引の包含が、それがビーコンブロック内に含まれるか実行ペイロード内に含まれるかに関わらずMEVを引き起こす可能性を想像できる。」——Barnabé『More pictures about proposers and builders』より。
2. 仮に（大きな仮定ですが）プロトコルがより厳格なチケット販売市場を実装できたとしても、そのメカニズムの設計空間は膨大です。バインディングカーブ、1559スタイルの動的価格設定、オークションなど、多くの潜在的な価格設定メカニズムが議論されていますが、これらについて一般論を述べることは本稿の範囲を超えます。
したがって、コンセンサス層での複雑性が最小限の「無制限、1WEI固定価格」の実行チケットバージョンに焦点を当てます。この枠組みの中で、おそらくあなたが気になっているであろう問題を投げかけられます。「一組の実行チケット保有者が与えられたとき、勝者はどうやって選ばれるのか？」……とてもシンプルに聞こえますよね？ 実際、この一見シンプルな問題についても、私たちが語れることは多くあります。いくつかの異なる選択肢を探ってみましょう。
x:b→[0,1]n ∑ixi(b)=1 p:b→Rn≥0
モデル
実行チケットの購入を通じて MEV 報酬を得る反復ゲームを想定します：
-
各サイクルで、各プレイヤーは購入するチケット数を示す入札を行います。入札をベクトル b で表し、bi は i番目のプレイヤーの入札額です。
-
各プレイヤーはブロック生成権の獲得に対して評価値を持っています。評価値をベクトル v で表し、vi は i番目のプレイヤーの評価値です。
-
各タイムステップで、分配メカニズムが入札ベクトルに基づいて各プレイヤーへの割当を決定します。リスク中立的なプレイヤーを仮定すると、それぞれが「ブロックの一部」を割り当てられると同等に言えます。これは「特定のブロックを獲得する確率」とも解釈できます。n人のプレイヤーのゲームでは、x: b → [0,1]^n で割当メカニズムを表し、xi(b) は i番目のプレイヤーの割当で、∑ixi(b)=1 の制約（つまりメカニズムが完全に分配する）のもとで定義されます。
-
各プレイヤーの支払いは毎ラウンド徴収されます。p: b → Rn≥0 で入札セットに基づく支払いルールを表し、pi(b) は i番目のプレイヤーの支払い額です。
-
各プレイヤーのゲーム効用関数は Ui(b) = vi xi(b) - pi(b) で定義され、プレイヤーの効用はブロック獲得価値に割当率を掛けたものから支払い額を引いたものとなります。
馴染みのある分配メカニズム
2つの（まったく異なる）可能性のあるメカニズムを考えてみましょう。
比例全額払い（オリジナルの実行チケット提案のわずかな修正）
-
各ラウンドで、すべてのプレイヤーが入札を行う。入札をベクトル b で表す。
-
入札額がゲームに勝つ確率は、その入札額をすべての入札額の合計で割った値になる。
各プレイヤーはゲームの結果に関係なく入札額を支払う（したがって「全額払い」）pi(b) = bi。
勝者がすべてを得る（現在の PBS の実装）
-
各ラウンドで、すべてのプレイヤーが入札を行う。入札をベクトル b で表す。
-
最高入札者がゲームに勝ち、xi(b) = 1（max(b) = biの場合）、xi(b) = 0（同点の場合は入札額が低いプレイヤーを優先）。
-
勝利したプレイヤーのみが入札額を支払い、pi(b) = bi（max(b) = biの場合）、pi(b) = 0（同点処理同様）。
結果の比較
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
a16z
