イーサリアムブロック構築: すべてのトランザクションの背後にある隠れた経済

ブロック構築は、さまざまな可動部分で構成される Ethereum のライフサイクルの重要な側面です。ブロックに含まれるトランザクションとその順序を決定し、ネットワークの効率、分散化、公平性に直接影響します。時間の経過とともに、Ethereum のブロック生成プロセスは進化してきました。特に、MEV の役割が拡大し、バリデーター主導の選択から専門ビルダーへの移行が進みました。

この投稿では、Proposer Builder Separation の導入と今後の研究とともに、Ethereum ブロック構築がどのように進化してきたかについて説明します。

イーサリアムブロック構築コンポーネントの入門

スロットとエポック

Ethereum は時間を個別の単位に整理します。

• スロット:スロットは、1 つのブロックを提案できる 12 秒間の期間です。スロット内にバリデーターがブロックを送信しない場合は、スキップされます。
• エポック:エポックは 32 スロットで構成され、合計6.4 分になります。

各エポックの終わりに、バリデータの役割はシャッフルされ、分散化とセキュリティが確保されます。Ethereum は2 エポック (約 12.8 分)後に経済的に最終決定し、その後はブロックを元に戻すことはほぼ不可能になります。

委員会

Ethereumのネットワークには膨大な数のバリデーターが存在します。執筆時点では、 beaconcha.inによるとアクティブなバリデーターは 1,051,349 です。これだけの数のバリデーターが 12 秒ごとに各ブロックを検証しなければならないとしたら、それは不可能です。そのため、バリデーターは委員会に分割され、トランザクションを効率的に検証し、ブロックの有効性を保証します。

各委員会：

• RANDAO を使用してエポックの開始時にランダムに割り当てられたバリデータのサブセットで構成されます。
• 単一のバリデーターが不均衡な影響力を持たないようにします。
• ブロックの投票（証明）とその有効性の確認に参加します。

委員会の規模は、ネットワーク内のアクティブなバリデーターの総数によって異なりますが、通常、各委員会には少なくとも 128 人のバリデーターがいます。

各スロット:

• たとえば、スロットごとにNの委員会が割り当てられ、各委員会にMバリデーター ( M >128) がいるとします。つまり、各スロットにNxM証明があることになります。ご存じのとおり、ネットワークがこれほど多くの証明をゴシップすると、すぐに手に負えなくなる可能性があります。

• 各委員会のアグリゲータは、それぞれの委員会の証明書を集約する役割を担っています。つまり、 Mのバリデーターの委員会のうち、最終的なAggregated Attestation Mではなく 1 個だけになります。

• したがって、各スロットでは、最終的にN個の証明 (そのスロットの各委員会に 1 つ) がグローバル トピックにゴシップされます。次のスロットの提案者は、これらのNの証明を取得します。

  
  

留意すべき点

• エポック中、すべてのアクティブなバリデータは 1 つの委員会のメンバーであるため、すべてのエポックの委員会は分離されています。

• プロトコルは、アクティブなバリデーターの数に応じて、各エポックの委員会の総数を調整します。

• 現在の設計では、スロットごとに64委員会、つまりN=64になります。

  
  

提案者の先読み

ビーコン チェーンのシャッフルは、シャッフルとスロットによって指示された証明のために、バリデーターの今後の委員会割り当てについて、最低1 エポック (32 スロット)先読みを提供するように設計されています。この先読みは提案には適用されないことに注意してください。提案は、問題のエポック中に確認する必要があります。

get_committee_assignment各エポックの開始時に呼び出され、次のエポック ( current_epoch + 1 ) の割り当てを取得できます。これにより、バリデーターはサブネット ID を計算し、それぞれの委員会に参加し、職務に備えることもできます。

さらに、バリデーターは特定の委員会のAggregatorとして割り当てられる場合があります。その場合、バリデーターもそれぞれのトピックをサブスクライブする必要があります。

提案者の責任

各スロット内では、それぞれの委員会から 1 人のバリデータが提案者として選択され、ブロックを作成して送信します。

提案者の役割は、次の点で非常に重要です。

• 保留中のトランザクションと証明を含めてブロックを構築します。
• SignedBeaconBlockに署名し、ネットワークにブロードキャストします。
• 有効なブロックを正常に提案すると報酬を獲得できます。

MEV の簡単な説明

MEV は、ブロック内のトランザクションを並べ替え、含める、または検閲することによってバリデーター (旧マイナー) が抽出する追加利益です。

一般的な MEV 戦略は次のとおりです。

• フロントランニング: 利益が見込める取引の直前に取引を行うこと。フロントランニングは、ユーザーにマイナスの影響で驚かせるため、有害な MEV ともみなされます。
• バックランニング: 特定のイベントの直後にトランザクションを実行します (例: アービトラージ ボット)。
• サンドイッチ攻撃: 特に DeFi 取引におけるフロントランニングとバックランニングの組み合わせ。

MEV を抽出するのは誰ですか?

• バリデーター (PBS 以前) : バリデータがブロック生成を制御していたときは、トランザクションの順序付けに関して完全な裁量権を持ち、MEV を直接抽出できました。
• サーチャー: メモリプールをスキャンして MEV の機会を探し、それに応じてトランザクションを送信する独立したアクター。
• ビルダー (PBS 後) : PBS 後、ブロック ビルダーは MEV に最適化されたブロックを構築する役割を担い、バリデータは最高入札者からブロックを選択するだけです。

ブロック構築Pre-PBS: バリデータ中心のMEV

Ethereum が PBS に移行する前は、提案者 (以前の PoW のマイナー) がトランザクションの順序を完全に制御していました。これにより、MEV がバリデーターによって直接抽出されるか、専門の検索者にアウトソーシングされるエコシステムが構築されました。

PBS 以前の仕組み:

1. トランザクション プール: トランザクションは通常どおりブロードキャストされ、メモリ プールに入ります。
2. バリデーターは、メモリプールからトランザクションを厳選しました。これらは、ユーザーが最初に含められるために支払う意思のある料金であるpriority_feeと呼ばれるものによって順序付けできます。また、バリデーターがより多くの収益を得る方法 (サンドイッチ/フロントランニングを通じて) で順序付けすることもできます。
3. バリデーターは、選択したトランザクションに基づいてブロックを構築します。
4. ブロックの伝播: 署名されたブロックがネットワークにブロードキャストされます。

これは単純化するために多少抽象化されていますが、これが一般的な流れです。これはバニラブロックビルディングと呼ぶことができます

PBS以前のブロック構築の問題

• MEV パワーの集中化: 大規模なバリデーターは、MEV をより効率的に抽出できるため、小規模なバリデーターよりも経済的に有利でした。
• 検閲リスクの増大: バリデーターは、金銭的インセンティブに一致しないトランザクションを除外することを選択できます。
• ネットワークの混雑とガス料金の高騰: MEV トランザクションの入札戦争により、ブロック スペースの利用が非効率になり、一般ユーザーのコストが増加しました。

PBS後のブロック構築: 提案者と構築者の分離

バリデーターによるブロック構築の集中化リスクと非効率性に対処するために、提案者とビルダーの分離 (PBS)が導入されました。PBS は、ブロック生成の責任を 2 つの別個のエンティティに分割します。

1. ブロック ビルダー: 多くの場合 MEV 戦略を組み込んで、最適化されたブロックの構築を専門とするエンティティ。
2. ブロック提案者 (バリデーター) : バリデータはブロックを自分で構築することはなくなり、ビルダーが提供する最も収益性の高いブロックを選択するだけです。

PBS 後の仕組み:

1. ビルダーがブロックを構築: ブロック ビルダーは、MEV 抽出機会を考慮して、最も収益性の高いブロックを構築するために競争します。
2. ブロック組み込みの入札: ビルダーはバリデーターにブロックを提案するために入札し、バリデーターが最も収益性の高いオプションを受け取るようにします。
3. バリデータは最高入札額を選択: バリデータは個々のトランザクションを選択する代わりに、最高入札額のビルダー ブロックを選択するだけで、報酬を最大化します。

イーサリアムのブロック構築の仕組み

1. ユーザーは、JSON-RPC 接続ウォレットを介してトランザクションを送信します。
2. このトランザクションはパブリック メモリプールに送信されます。すべてのトランザクションは、ピックアップされて検証される前にここにダンプされます。最近、プライベート オーダーフローが注目を集めており、ほとんどの大手プレーヤーがこれを採用しています。これは、許可された/プライベート チャネルを使用してトランザクションをパブリックにブロードキャストする回避策であるためです。詳細については、 Duneのダッシュボードをご覧ください。

3. サーチャー→ メモリプールを継続的にスキャンして MEV の機会を見つける外部エンティティです (詳細は後述)。サーチャーはそれぞれのトランザクションを取得し、利益を上げるために必要に応じて独自のトランザクションを挿入します。次に、これらのトランザクションのバンドルを作成します。サーチャーが利益を上げるためには、バンドルの順序が全体にわたって維持される必要があります。バンドルは順序付けされたトランザクションであり、アトミックに実行する必要があります。このバンドルとともに、バンドルの最後にビルダーへの「賄賂」を示すトランザクションを追加する場合があります。このバンドルは、 eth_sendBundle呼び出しを通じてビルダーに送信されます。

   注: 検索者は外部エンティティであり、トランザクションの順序付けに影響を与えますが、ブロックの検証やコンセンサスの決定には参加しません。

   

   
   

4. ビルダー→次のエンティティは、実際にブロックを構築するビルダーです。ビルダーは、手数料収入と MEV 収入の両方を最大化しようとします。ビルダーは、サーチャーが送信したバンドルされたトランザクションを（できれば順番に）含め、サーチャーが送信した支払い（賄賂）を受け取ります。ビルダーは、受信したトランザクションを使用して実行ペイロードを構築します。

   ブロックに次の内容を入力します。

   1. 捜索者から送られたバンドル。

   2. 優先度の高いトランザクション。

   3. 収益を最大化することを念頭に置いて一般的な取引を注文します。

      
      

   また、フィールドfeeRecipientを自分のアドレスに設定し、サーチャーの賄賂と、送信したブロック内のトランザクションからのすべての手数料の両方を受け取ることを示します。ビルダーは、ブロックの最後にトランザクションを送信します。これは、サーチャーがビルダーに対して行ったのと同様に、提案者への賄賂として機能します。

   
   

5. リレー→ ビルダー市場は、さまざまなビルダーがペイロードを確定させて手数料を稼ぐ競争市場です。ただし、ほとんどのブロックは、 BeaverBuildやTitan などの有名なブロック ビルダーによって構築されています。実際の提案者にとってこのプロセスを簡素化するために、リレーはさまざまなビルダーによって送信されたペイロードを検証し、最大の利益/入札額を持つものを選択する仲介エンティティです。リレーと提案者の通信では、コミットと公開に似た巧妙なトリックを使用して、提案者がこの時点まですべてのエンティティをだまさないようにします。詳細はこちら。

まとめると

リレー提案者コミュニケーション

ブロック ペイロードを受信すると、提案者がブロックをアンラップし、トランザクションを挿入し、順序を自分の好みに変更し、 feeRecipientを自分のアドレスに設定する可能性は十分にあります。これは、これまでブロック構築プロセスに取り組んだすべてのエンティティ (検索者 → ビルダー → リレー) が不正行為をしたり、「MEV 窃盗」を行ったりすることを意味します。これを防ぐために、リレーは選択されたブロック ペイロードのヘッダーのみを送信します。これは、提案者がeth_getPaylaodHeader呼び出しを行うときに発生します。リレーは、ボディのハッシュ、入札、ビルダーの署名を含むPayloadHeaderを送信します。

この時点で提案者には次の 2 つの選択肢があります。

• リレーによって提供されるPayloadHeader ( Blinded Blockとも呼ばれる) を選択します。その場合、提案者はヘッダーを自分のキーで署名し、それをリレーに送り返して、 eth_returnSignedHeader呼び出しを使用してPayloadBody要求する必要があります。次に、リレーはeth_sendPayload呼び出しを実行し、 ExecutionPayload全体を提案者に返します。次に、提案者はこのブロックを Ethereum Validator ネットワーク、より具体的には割り当てられた委員会に提案します。

  
  

• プロポーザーはリレーから送信されたPayloadHeaderを受け入れないことを選択できます。その場合、プロポーザー自身でブロックを構築する必要があります。これには、MEV の機会を見つけて、それに応じてトランザクションを順序付ける作業が含まれます。もちろん、この場合、プロポーザーは手数料 + MEV からの収益をすべて保持できます。ただし、これは見た目ほど簡単ではありません。MEV を見つけて収益を最適化することは、かなり計算量の多いタスクであり、プロポーザーが時間内にブロックを構築できない可能性があり (12 秒)、スロットが失われます。このシナリオでは、プロポーザーはネットワークから排除される可能性があります。

しかし、ケース 1 では、提案者がリレーによって送信されたブロックを送信しない場合はどうなるでしょうか?

まさにこの理由から、提案者はPayloadHeaderに署名する必要があります。ヘッダーを送信する前に、リレーはPayloadBodyを保管のためにEscrowに送信します。リレーは提案者から署名されたPayloadHeaderを受信すると、署名を検証し、エスクローに保存されているPayloadBody提案者に送信します。ここで、提案者がこのブロックを含めないとします。提案者は、これまでの順序を無視して独自のブロックを構築します。この場合、ヘッダーが変更されているため、署名は一致しません。

ビルダーはこれらの競合する署名済みヘッダーをネットワークにブロードキャストできるようになり、プロポーザーはネットワークから排除される可能性があります。

ビルダーによるトランザクションの検閲を阻止するものは何ですか?

まあ、何もありません。ビルダーが取引を検閲する最も一般的な理由は、取引がOFAC アドレスとやり取りするためです。簡単に言えば、OFAC アドレスは、法的影響を及ぼす可能性のある取引をやり取りしており、当然ながら誰もそれを望まないでしょう。

Censorship.picsによると、ビルダーによって構築されたブロックには、OFAC 認可取引が 0 ～ 7% しか含まれません。

これをどうやって解決すればいいでしょうか?

この記事の執筆時点で、トランザクション検閲に対する最もよく知られたソリューションの 1 つは、 Inclusion Listsです。

インクルージョン リストは、スロット N のブロックを提案する際にスロット N の提案者によって投稿されるトランザクションのリストです (サマリーと呼ばれるものも含む)。

包含リストは、リスト内のトランザクションがブロック N またはブロック N+1 のいずれかに含まれる必要があることを強制します。そうでない場合、N+1 ブロックは無効になります。これらは、前方包含リストと呼ばれます。

もちろん、この IL の設計では 100% の検閲耐性は実現できませんが、これらの提案を強化するための活発な研究が進行中であり、インセンティブ構造を改善するために適用できる多くの優れた最適化が行われています。

フォシル

Fork Choice 強制包含リスト (FOCIL) は、 2024 年に提案された新しい設計であり、包含リストを構築および改善して、信頼できる中立性を高めます。

FOCIL では、複数のバリデータが特定のスロットの包含リストに関する提案を行うことができます。より正確には、各スロットで 16 のバリデータがランダムに選択され、包含リスト委員会を形成します。これらのメンバーはそれぞれ独自のローカル IL を形成し、それをネットワークに伝えます。提案者は、利用可能なローカル包含リストを収集して最終的な IL に集約します。これらのトランザクションを含めるためにブロックを再構築する必要がないため、IL 設計は軽量です。ブロックに追加するだけで済みます。ブロックが IL 検証要件を満たすための条件は、 「ブロックがいっぱいになるまで、すべての IL のすべてのトランザクションが含まれている場合、ブロックは有効です。」です。

MEV管理におけるPBSの利点

• MEV 抽出の分散化: 少数の大規模なバリデーターではなくブロック ビルダーが MEV 抽出を処理するため、バリデーターの集中化のリスクが軽減されます。ただし、バリデーターの集中化を緩和する過程で、少数のビルダーがブロックの大部分を構築するビルダー集中化を導入したため、これは諸刃の剣です。
• より公平な収益分配: バリデーターは抽出に直接関与することなく MEV から利益を得ることができるため、ブロック生成がより公平になります。
• より効率的なブロック スペースの利用: ビルダー間の競争により、ガス効率が向上した最適化されたブロックが実現します。

PBSの課題

• ビルダー間の集中化リスク: バリデーターは分散化されていますが、少数の支配的なビルダーが MEV 抽出を集中化する可能性があります。
• オフチェーン MEV リレーの信頼: PBS は現在、オフチェーンで動作する MEV-Boost リレーに依存しており、障害点として潜在的なセキュリティリスクが生じます。

参考文献:

イーサリアムのプロポーザーとビルダーの分離：約束と現実

研究の現状: PBS における検閲抵抗

ビルダー検閲: イーサリアムの腐ったコア

EPF ウィキ - PBS

PBSに関するメモ

前方包含リスト

イーサリアムのブロック構築オークションで誰が勝つのか、そしてその理由は?

フォシル

謝辞