ブロック構築は、さまざまな可動部分で構成される Ethereum のライフサイクルの重要な側面です。ブロックに含まれるトランザクションとその順序を決定し、ネットワークの効率、分散化、公平性に直接影響します。時間の経過とともに、Ethereum のブロック生成プロセスは進化してきました。特に、MEV の役割が拡大し、バリデーター主導の選択から専門ビルダーへの移行が進みました。 この投稿では、Proposer Builder Separation の導入と今後の研究とともに、Ethereum ブロック構築がどのように進化してきたかについて説明します。 イーサリアムブロック構築コンポーネントの入門 スロットとエポック Ethereum は時間を個別の単位に整理します。 スロットは、1 つのブロックを提案できる 12 秒間の期間です。スロット内にバリデーターがブロックを送信しない場合は、スキップされます。 スロット: エポックは 32 スロットで構成され、合計 なります。 エポック: 6.4 分に 各エポックの終わりに、バリデータの役割はシャッフルされ、分散化とセキュリティが確保されます。Ethereum は 後に経済的に最終決定し、その後はブロックを元に戻すことはほぼ不可能になります。 2 エポック (約 12.8 分) 委員会 のネットワークには膨大な数のバリデーターが存在します。執筆時点では、 によるとアクティブなバリデーターは 1,051,349 です。これだけの数のバリデーターが 12 秒ごとに各ブロックを検証しなければならないとしたら、それは不可能です。そのため、バリデーターは 会に分割され、トランザクションを効率的に検証し、ブロックの有効性を保証します。 Ethereum beaconcha.in 委員 各委員会： RANDAO を使用してエポックの開始時にランダムに割り当てられたバリデータのサブセットで構成されます。 単一のバリデーターが不均衡な影響力を持たないようにします。 ブロックの投票（証明）とその有効性の確認に参加します。 委員会の規模は、ネットワーク内のアクティブなバリデーターの総数によって異なりますが、通常、各委員会には少なくとも 128 人のバリデーターがいます。 各スロット: たとえば、スロットごとに の委員会が割り当てられ、各委員会に バリデーター ( >128) がいるとします。つまり、各スロットに 証明があることになります。ご存じのとおり、ネットワークがこれほど多くの証明をゴシップすると、すぐに手に負えなくなる可能性があります。 N M M NxM 各委員会のアグリゲータは、それぞれの委員会の証明書を集約する役割を担っています。つまり、 のバリデーターの委員会のうち、最終的な ではなく 1 個だけになります。 M Aggregated Attestation M したがって、各スロットでは、最終的に 個の証明 (そのスロットの各委員会に 1 つ) がグローバル トピックにゴシップされます。次のスロットの提案者は、これらの の証明を取得します。 N N 留意すべき点 エポック中、すべてのアクティブなバリデータは 1 つの委員会のメンバーであるため、すべてのエポックの委員会は分離されています。 プロトコルは、アクティブなバリデーターの数に応じて、各エポックの委員会の総数を調整します。 現在の設計では、スロットごとに 委員会、つまり になります。 64 N=64 提案者の先読み ビーコン チェーンのシャッフルは、シャッフルとスロットによって指示された証明のために、バリデーターの今後の委員会割り当てについて、最低 先読みを提供するように設計されています。この先読みは提案には適用されないことに 。提案は、問題のエポック中に確認する必要があります。 1 エポック (32 スロット) 注意してください 各エポックの開始時に呼び出され、次のエポック ( ) の割り当てを取得できます。これにより、バリデーターはサブネット ID を計算し、それぞれの委員会に参加し、職務に備えることもできます。 get_committee_assignment current_epoch + 1 さらに、バリデーターは特定の委員会の として割り当てられる場合があります。その場合、バリデーターもそれぞれのトピックをサブスクライブする必要があります。 Aggregator 提案者の責任 各スロット内では、 が として選択され、ブロックを作成して送信します。 それぞれの委員会から 1 人のバリデータ 提案者 提案者の役割は、次の点で非常に重要です。 保留中のトランザクションと証明を含めてブロックを構築します。 に署名し、ネットワークにブロードキャストします。 SignedBeaconBlock 有効なブロックを正常に提案すると報酬を獲得できます。 MEV の簡単な説明 MEV は、ブロック内のトランザクションを並べ替え、含める、または検閲することによってバリデーター (旧マイナー) が抽出する追加利益です。 一般的な MEV 戦略は次のとおりです。 : 利益が見込める取引の直前に取引を行うこと。フロントランニングは、ユーザーにマイナスの影響で驚かせるため、有害な MEV ともみなされます。 フロントランニング : 特定のイベントの直後にトランザクションを実行します (例: アービトラージ ボット)。 バックランニング : 特に DeFi 取引におけるフロントランニングとバックランニングの組み合わせ。 サンドイッチ攻撃 MEV を抽出するのは誰ですか? : バリデータがブロック生成を制御していたときは、トランザクションの順序付けに関して完全な裁量権を持ち、MEV を直接抽出できました。 バリデーター (PBS 以前) : メモリプールをスキャンして MEV の機会を探し、それに応じてトランザクションを送信する独立したアクター。 サーチャー : PBS 後、ブロック ビルダーは MEV に最適化されたブロックを構築する役割を担い、バリデータは最高入札者からブロックを選択するだけです。 ビルダー (PBS 後) ブロック構築Pre-PBS: バリデータ中心のMEV Ethereum が PBS に移行する前は、提案者 (以前の PoW のマイナー) が ていました。これにより、MEV がバリデーターによって直接抽出されるか、専門の検索者にアウトソーシングされるエコシステムが構築されました。 トランザクションの順序を完全に制御し PBS 以前の仕組み: : トランザクションは通常どおりブロードキャストされ、メモリ プールに入ります。 トランザクション プール バリデーターは、メモリプールからトランザクションを厳選しました。これらは、ユーザーが最初に含められるために支払う意思のある料金である と呼ばれるものによって順序付けできます。また、バリデーターがより多くの収益を得る方法 (サンドイッチ/フロントランニングを通じて) で順序付けすることもできます。 priority_fee バリデーターは、選択したトランザクションに基づいてブロックを構築します。 : 署名されたブロックがネットワークにブロードキャストされます。 ブロックの伝播 これは単純化するために多少抽象化されていますが、これが一般的な流れです。これは と呼ぶことができます バニラブロックビルディング PBS以前のブロック構築の問題 : 大規模なバリデーターは、MEV をより効率的に抽出できるため、小規模なバリデーターよりも経済的に有利でした。 MEV パワーの集中化 : バリデーターは、金銭的インセンティブに一致しないトランザクションを除外することを選択できます。 検閲リスクの増大 : MEV トランザクションの入札戦争により、ブロック スペースの利用が非効率になり、一般ユーザーのコストが増加しました。 ネットワークの混雑とガス料金の高騰 PBS後のブロック構築: 提案者と構築者の分離 バリデーターによるブロック構築の集中化リスクと非効率性に対処するために、 が導入されました。PBS は、ブロック生成の責任を 2 つの別個のエンティティに分割します。 提案者とビルダーの分離 (PBS) : 多くの場合 MEV 戦略を組み込んで、最適化されたブロックの構築を専門とするエンティティ。 ブロック ビルダー : バリデータはブロックを自分で構築することはなくなり、ビルダーが提供する最も収益性の高いブロックを選択するだけです。 ブロック提案者 (バリデーター) PBS 後の仕組み: : ブロック ビルダーは、MEV 抽出機会を考慮して、最も収益性の高いブロックを構築するために競争します。 ビルダーがブロックを構築 : ビルダーはバリデーターにブロックを提案するために入札し、バリデーターが最も収益性の高いオプションを受け取るようにします。 ブロック組み込みの入札 : バリデータは個々のトランザクションを選択する代わりに、最高入札額のビルダー ブロックを選択するだけで、報酬を最大化します。 バリデータは最高入札額を選択 イーサリアムのブロック構築の仕組み ユーザーは、JSON-RPC 接続ウォレットを介してトランザクションを送信します。 このトランザクションはパブリック メモリプールに送信されます。すべてのトランザクションは、ピックアップされて検証される前にここにダンプされます。最近、 が注目を集めており、ほとんどの大手プレーヤーがこれを採用しています。これは、許可された/プライベート チャネルを使用してトランザクションをパブリックにブロードキャストする回避策であるためです。詳細については、 のダッシュボードをご覧ください。 プライベート オーダーフロー Dune → メモリプールを継続的にスキャンして MEV の機会を見つける外部エンティティです ( )。サーチャーはそれぞれのトランザクションを取得し、利益を上げるために必要に応じて独自のトランザクションを挿入します。次に、これらのトランザクションのバンドルを作成します。サーチャーが利益を上げるためには、バンドルの順序が全体にわたって維持される必要があります。バンドルは順序付けされたトランザクションであり、アトミックに実行する必要があります。このバンドルとともに、バンドルの最後にビルダーへの「賄賂」を示すトランザクションを追加する場合があります。このバンドルは、 呼び出しを通じてビルダーに送信されます。 サーチャー 詳細は後述 eth_sendBundle : 検索者は外部エンティティであり、トランザクションの順序付けに影響を与えますが、ブロックの検証やコンセンサスの決定には参加しません。 注 →次のエンティティは、実際にブロックを構築するビルダーです。ビルダーは、手数料収入と MEV 収入の両方を最大化しようとします。ビルダーは、サーチャーが送信したバンドルされたトランザクションを（できれば順番に）含め、サーチャーが送信した支払い（賄賂）を受け取ります。ビルダーは、受信したトランザクションを使用して実行ペイロードを構築します。 ビルダー ブロックに次の内容を入力します。 捜索者から送られたバンドル。 優先度の高いトランザクション。 収益を最大化することを念頭に置いて一般的な取引を注文します。 また、フィールド を自分のアドレスに設定し、サーチャーの賄賂と、送信したブロック内のトランザクションからのすべての手数料の両方を受け取ることを示します。ビルダーは、ブロックの最後にトランザクションを送信します。これは、サーチャーがビルダーに対して行ったのと同様に、提案者への賄賂として機能します。 feeRecipient : ビルダーは外部エンティティであり、ブロックチェーンと直接やり取りしません。 注 → ビルダー市場は、さまざまなビルダーがペイロードを確定させて手数料を稼ぐ競争市場です。ただし、ほとんどのブロックは、 や 実際の提案者にとってこのプロセスを簡素化するために、リレーはさまざまなビルダーによって送信されたペイロードを検証し、最大の利益/入札額を持つものを選択する仲介エンティティです。リレーと提案者の通信では、コミットと公開に似た巧妙なトリックを使用して、提案者がこの時点まですべてのエンティティをだまさないようにします。詳細は 。 リレー BeaverBuild Titan などの有名なブロック ビルダーによって構築されています。 こちら まとめると リレー提案者コミュニケーション ブロック ペイロードを受信すると、提案者がブロックをアンラップし、トランザクションを挿入し、順序を自分の好みに変更し、 を自分のアドレスに設定する可能性は十分にあります。これは、これまでブロック構築プロセスに取り組んだすべてのエンティティ (検索者 → ビルダー → リレー) が不正行為をしたり、「MEV 窃盗」を行ったりすることを意味します。これを防ぐために、リレーは選択されたブロック ペイロードのヘッダーのみを送信します。これは、提案者が 呼び出しを行うときに発生します。リレーは、ボディのハッシュ、入札、ビルダーの署名を含む を送信します。 feeRecipient eth_getPaylaodHeader PayloadHeader この時点で提案者には次の 2 つの選択肢があります。 リレーによって提供される ( とも呼ばれる) を選択します。その場合、提案者はヘッダーを自分のキーで署名し、それをリレーに送り返して、 呼び出しを使用して 要求する必要があります。次に、リレーは 呼び出しを実行し、 全体を提案者に返します。次に、提案者はこのブロックを Ethereum Validator ネットワーク、より具体的には割り当てられた委員会に提案します。 PayloadHeader Blinded Block eth_returnSignedHeader PayloadBody eth_sendPayload ExecutionPayload プロポーザーはリレーから送信された を受け入れないことを選択できます。その場合、プロポーザー自身でブロックを構築する必要があります。これには、MEV の機会を見つけて、それに応じてトランザクションを順序付ける作業が含まれます。もちろん、この場合、プロポーザーは手数料 + MEV からの収益をすべて保持できます。ただし、これは見た目ほど簡単ではありません。MEV を見つけて収益を最適化することは、かなり計算量の多いタスクであり、プロポーザーが時間内にブロックを構築できない可能性があり (12 秒)、スロットが失われます。このシナリオでは、プロポーザーはネットワークから排除される可能性があります。 PayloadHeader しかし、ケース 1 では、提案者がリレーによって送信されたブロックを送信しない場合はどうなるでしょうか? まさにこの理由から、提案者は に署名する必要があります。ヘッダーを送信する前に、リレーは を保管のために に送信します。リレーは提案者から署名された を受信すると、署名を検証し、エスクローに保存されている 提案者に送信します。ここで、提案者がこのブロックを含めないとします。提案者は、これまでの順序を無視して独自のブロックを構築します。この場合、ヘッダーが変更されているため、署名は一致しません。 PayloadHeader PayloadBody Escrow PayloadHeader PayloadBody : 注意 同じ提案スロットに 2 つの異なるヘッダーを署名することは、スラッシュ可能な違反です。 ビルダーはこれらの競合する署名済みヘッダーをネットワークにブロードキャストできるようになり、プロポーザーはネットワークから排除される可能性があります。 ビルダーによるトランザクションの検閲を阻止するものは何ですか? まあ、何もありません。ビルダーが取引を検閲する最も一般的な理由は、取引が とやり取りするためです。 OFAC アドレス 簡単に言えば、OFAC アドレスは、法的影響を及ぼす可能性のある取引をやり取りしており、当然ながら誰もそれを望まないでしょう。 によると、ビルダーによって構築されたブロックには、OFAC 認可取引が 0 ～ 7% しか含まれません。 Censorship.pics これをどうやって解決すればいいでしょうか? この記事の執筆時点で、トランザクション検閲に対する最もよく知られたソリューションの 1 つは、 です。 Inclusion Lists 、スロット N のブロックを提案する際にスロット N の提案者によって投稿されるトランザクションのリストです (サマリーと呼ばれるものも含む)。 インクルージョン リストは 包含リストは、リスト内のトランザクションがブロック N またはブロック N+1 のいずれかに含まれる必要があることを強制します。そうでない場合、N+1 ブロックは無効になります。これらは、 前方包含リストと呼ばれます。 : 現在のブロック N 自体に対して IL を実行する の概念もあります。ただし、この設計には経済的な欠陥があり、 注 スポット包含リスト フォワード包含リストにつながりました。 もちろん、この IL の設計では 100% の検閲耐性は実現できませんが、これらの提案を強化するための活発な研究が進行中であり、インセンティブ構造を改善するために適用できる多くの優れた最適化が行われています。 フォシル 2024 年に提案された新しい設計であり、包含リストを構築および改善して、信頼できる中立性を高めます。 Fork Choice 強制包含リスト (FOCIL) は、 FOCIL では、複数のバリデータが特定のスロットの包含リストに関する提案を行うことができます。より正確には、各スロットで 16 のバリデータがランダムに選択され、包含リスト委員会を形成します。これらのメンバーはそれぞれ独自のローカル IL を形成し、それをネットワークに伝えます。提案者は、利用可能なローカル包含リストを収集して最終的な IL に集約します。これらのトランザクションを含めるためにブロックを再構築する必要がないため、IL 設計は軽量です。ブロックに追加するだけで済みます。ブロックが IL 検証要件を満たすための条件は、 です。 「 ブロックがいっぱいになるまで、すべての IL のすべてのトランザクションが含まれている場合、ブロックは有効です。」 : IL トランザクションは任意の順序で含められる可能性があるため、IL 委員会のメンバーはトランザクションの順序付けを保証することはできません。トランザクションの含められることのみを保証します。 注 MEV管理におけるPBSの利点 : 少数の大規模なバリデーターではなくブロック ビルダーが MEV 抽出を処理するため、バリデーターの集中化のリスクが軽減されます。ただし、バリデーターの集中化を緩和する過程で、少数のビルダーがブロックの大部分を構築するビルダー集中化を導入したため、これは諸刃の剣です。 MEV 抽出の分散化 : バリデーターは抽出に直接関与することなく MEV から利益を得ることができるため、ブロック生成がより公平になります。 より公平な収益分配 : ビルダー間の競争により、ガス効率が向上した最適化されたブロックが実現します。 より効率的なブロック スペースの利用 PBSの課題 : バリデーターは分散化されていますが、少数の支配的なビルダーが MEV 抽出を集中化する可能性があります。 ビルダー間の集中化リスク : PBS は現在、オフチェーンで動作する MEV-Boost リレーに依存しており、障害点として潜在的なセキュリティリスクが生じます。 オフチェーン MEV リレーの信頼 参考文献: イーサリアムのプロポーザーとビルダーの分離：約束と現実 研究の現状: PBS における検閲抵抗 ビルダー検閲: イーサリアムの腐ったコア EPF ウィキ - PBS PBSに関するメモ 前方包含リスト イーサリアムのブロック構築オークションで誰が勝つのか、そしてその理由は? フォシル 謝辞 レビューと提案をしてくださった 、 、 に感謝します。 @mteam @Gajpower @unnawut
