イーサリアムの将来 II - 検閲耐性

イーサリアムの将来に関するこの記事では、検閲耐性に向けた進行中の戦いについて探り、規制圧力の影響、提案者と構築者の分離 (PBS) の役割、ネットワークの中立性と分散性を維持するための暗号化されたメモリプールなどの潜在的なソリューションを検証します。 Ethereum は、MEV 利益の集中化リスクを軽減するために PBS 構造を採用しています。このシステムでは、ブロック提案者 (通常の検証ノード) がブロック構築を専門のビルダーに委任し、ビルダーはトランザクションの順序を最適化して MEV 抽出を最大化します。次に、提案者は最も収益性の高いブロックを選択して署名し、ネットワークにブロードキャストします。 オフチェーン ブロック オークション メカニズムである MEV-Boost は、このプロセスを容易にするために、現在 Ethereum で広く使用されています。MEV-Boost を使用すると、専門のビルダーが提案者に入札し、自分のブロックが組み込まれるように競争することができます。Ethereum のバリデータ セットは高度に分散化されたままですが、ブロックの構築 (特に MEV に最適化されたブロックの構築) は複雑で、多くのリソースを必要とします。この高い計算およびインフラストラクチャの負荷を考えると、ブロック構築を集中化し、ブロック認証を分散化したままにしておく方が効率的です。 これは PBS の核となる原則です。ブロックごとに行われるオークションによって MEV の利益の一部をバリデーターに公平に分配し、一般のバリデーター (ホーム ステーカーを含む) がブロック構築の複雑さに悩まされないようにします。この特殊な役割を分離することで、PBS はブロック生成の効率を最適化しながら、イーサリアム ネットワーク全体の分散化を維持します。 しかし、成功するビルダーには膨大なリソースと特権的なトランザクションフローが必要なため、オークションで一貫して勝てるビルダーはほんの一握りです。一部のビルダーは、特定のウォレット、dApp、注文フロープロバイダーと独占契約を結び、ブロックオークションで競争上の優位性をもたらす高 MEV トランザクションへのアクセスを確保することで優位性を維持しています。その結果、ビルダー間の競争は時間の経過とともに減少し、寡占構造につながります。 現在、イーサリアム ブロックの約 90% は MEV-Boost を通じて構築されており、Beaverbuild と Titan Builder の 2 つの組織がこれらのブロックの 95% を構築しています。この集中により、検閲耐性、トランザクションの公平性、およびイーサリアムのブロック生成の長期的な分散化に関する懸念が生じています。 これらのビルダーによる妨害や悪意のある行為は、イーサリアム ネットワークの安全性に重大な影響を与えることはありませんが、検閲耐性に重大な脅威をもたらします。すべての MEV-Boost ビルダーが特定のユーザーのトランザクションを検閲することにした場合、それらのユーザーは、MEV-Boost を使用しないバリデーターによって生成されたブロックを通じてのみトランザクションを送信できます。これは全体の約 10% です。その結果、このようなトランザクションの処理には平均 10 ブロック (約 2 分) かかります。 この状況により、2 つの大きな問題が発生します。 規制上の脆弱性 まず、イーサリアムが規制に対してより脆弱になる可能性があります。たとえば、 が課したTornado Cash制裁により、多数のビルダーとバリデータがOFACの制裁対象アカウントに関連するトランザクションを検閲することになりました。 2022年にOFAC オークションのようなプロトコルにおける不公平な競争 第二に、検閲はオンチェーンオークションの結果を歪める可能性があります。たとえば、ブロックごとに 1 つの NFT が最高入札者に販売されるオークションを考えてみましょう。ブロックビルダーは、非常に低い入札を行いながら他のすべての入札を検閲し、大幅に値下げした価格で NFT を取得できます。 これらの問題に対処するために、さまざまなソリューションが登場しています。この記事では、これらのソリューションを 2 つの主なカテゴリに分けて検討し、Ethereum の将来において検閲耐性がどのような形をとる可能性があるかについて説明します。 考えられる解決策 1: 包含リスト 背景: 初期包含リスト提案、EIP-7547 インクルージョン リストは、特定のトランザクションがブロックに含まれるようにする検閲耐性ソリューションです。通常は次のように実装できます。 簡単なメンタルモデルは次のとおりです。ビルダーがブロックを構築する前に、提案者は「これらのトランザクションをブロックに含める」という「包含リスト」を含む命令を送信します。ビルダーは、作成するブロックにこれらのトランザクションを含める必要があり、包含リストのトランザクションなしでブロックが構築された場合、そのブロックは無効とみなされます。 PBS 以前の Ethereum では、ブロックに入力される前にトランザクションが保持されるメモリプールは、非コンセンサス コンポーネントとして Ethereum に含まれていました。そのため、Ethereum コンセンサス レイヤーの観点からは、ブロックに含まれるトランザクションがどこから来たのかは不明でした。 MEV が検閲につながった主な理由の 1 つは、mempool が非コンセンサス コンポーネントであるため、ブロックを作成したビルダーが、どのトランザクションを検閲するか、またはブロックに含めるかに関して完全な権限を持っていたことです。 インクルージョン リストは、複数のバリデーターを使用してコンセンサス レイヤー上の「オンチェーン メモリプール」として機能するメカニズムを導入します。このようにして、コンセンサス レイヤーは、検閲耐性を提供するために、ビルダーのトランザクション選択権限を十分に制限します。 インクルージョン リストを実装するための最も有名な提案の 1 つは、 (フォワード インクルージョン リスト) でした。この提案により、提案者は最大 16 個のトランザクションをインクルージョン リストに含めることができました。「転送」メカニズムにより、ブロック N に提案されたインクルージョン リストがブロック N+1 に適用されることが保証されました。 EIP-7547 この提案は当初、Ethereum の Pectra アップグレードの一部となる予定でしたが、最終的には除外されました。その理由の 1 つは、転送メカニズムと 間の互換性の問題でした。 EIP-3074 EIP-3074 は、AUTHCALL と呼ばれるオペコードを使用するネイティブ アカウント抽象化の形式を導入し、1 つのアカウントで複数の EOA (外部所有アカウント) の残高を調整できるようにします。このメカニズムにより、インクルージョン リストが簡単に損なわれる可能性があります。 たとえば、アリスが EOA からボブに ETH を送信するトランザクション (A) をインクルージョン リストに含めるとします。同時に、アリスは EIP-3074 の AUTHCALL を使用して別のトランザクション (B) を作成し、EOA の残高をすべて別のアカウントに転送します。トランザクション B はブロック N に含まれ、トランザクション A はブロック N+1 のインクルージョン リストに含まれていると仮定します。 ここで重要な問題があります。提案者が包含リストを作成するとき、提案者はビルダーが現在のブロックにどのトランザクションを含めるか知りません。このシナリオでは、ブロック N のトランザクション B によってトランザクション A が無効になります。その結果、ブロック N+1 のビルダーは、包含リストのトランザクション A が無効であるため、有効なブロックを構築できなくなります。 この問題は、包含リスト内の追加の制約を通じて解決する試みがなされてきました。しかし、根本的な問題は残っています。EIP-3074 は本質的に他の EOA の残高を操作することを許可しています。「送信元」アドレスの確認などの単純なチェックでは、包含リストのトランザクションと他のトランザクション間の干渉を検出できません。これは、記事 「No Free Lunch - a new including list design」で言及されている、フリー データ可用性問題と呼ばれます。 EIP-3074 は Pectra アップグレードから除外されましたが、同様の機能である EIP-7702 は含まれていました。そのため、EIP-7547 を Ethereum メインネットに実装する前に、これらの問題を解決する必要があります。 さらに、EIP-7547 は、ブロックごとに 1 人の提案者しか Inclusion List を作成できないという制限など、追加の課題に直面していました。これらの要因により、EIP-7547 をそのまま Ethereum メインネットに適用することは困難でした。その結果、EIP-7547 は Pectra アップグレードから除外されました。 フォシル これらの問題に対する解決策はないのでしょうか? 最近、FOCIL (Fork-choice forced Inclusion Lists) と呼ばれるソリューションがイーサリアム エコシステム内で大きな注目を集めており、イーサリアム メインネットに実装される可能性が最も高いソリューションの 1 つと考えられています。EIP として提案された FOCIL は、1 つのエンティティだけでなく複数のエンティティが Inclusion Lists を提案するメカニズムを導入します。その詳細と特徴は次のとおりです。 -7805 FOCIL は基本的に、インクルージョン リストの概念を採用しています。つまり、誰かがすべてのブロックに含める必要があるトランザクションのリストを作成し、提案者はそれを組み込む必要があります。ただし、FOCIL は EIP-7547 と 2 つの重要な点で異なります。 1 人の提案者ではなく、16 人のメンバーからなる IL 委員会が独立して包含リストを提案します。 ブロック N に提案された包含リストは、ブロック N+1 ではなく、ブロック N 自体に含まれます。 メカニズムの詳細 ブロック N の包含リストの構築は、ブロック N-1 のスロットが開始すると開始されます。ランダムに選択された 16 のバリデーターの IL 委員会がブロック N-1 を受け取り、それをヘッドとして設定し、それぞれの包含リストを構築して、ピアツーピアを通じて伝播します。 構築プロセスは 12 秒の N-1 スロットの 9 秒後に終了し、それ以降は委員会はリストに追加できなくなります。P2P ネットワーク経由でこれらのリストを受け取ったブロック N のビルダーは、ブロックの構築時にそれらを含める必要があります。N スロットの開始直後に、ブロックは提案者に配信されます。 ブロック N を検証するバリデーターは、以前に受け取った包含リスト内のトランザクションをブロック N に含まれるトランザクションと比較して、コンプライアンスを確認します。 EIP-7547 と比較した FOCIL の利点 以前提案された EIP-7547 と比較して、FOCIL には次の利点があります。 検閲に対する抵抗力の向上 各スロットには、包含リストを作成する 16 人のバリデーターからなる IL 委員会が関与します。これにより、単一のバリデーターのみが責任を負っていた EIP-7547 よりも検閲に対する耐性が強化されます。 シームレスな実装 コンセンサス クライアントが使用する標準 API forkChoiceUpdate を利用することで、インクルージョン リストをプロトコルにより簡単かつシームレスに統合できます。 「リアルタイム」検閲抵抗 ブロック N+1 に提案された包含リストが遅延を引き起こす EIP-7547 とは異なり、FOCIL は N 自体に提案されたブロックに IL を含めるため、トランザクションを遅延なく組み込むことができます。 ブロックと包含リストを同時に構築することで、EIP-3074 や EIP-7702 などの以前に提案されたアカウント抽象化メカニズムとの互換性が確保されます。以前のブロックは、包含リスト内のトランザクションを無効にすることはできません。 ビルダーはブロック構築を完了する前に IL を受け取り、IL を無効にするトランザクションを除外することができます。このプロセスは簡単です。ビルダーは IL に関係するすべての EOA の nonce と残高を記録し、変更が発生するたびにこれらの値を更新します。この単純な方法により、ビルダーは IL トランザクションの有効性を検証し、ブロック構築を正常に完了できます。 ブロックにおけるFOCILの役割 FOCIL では、ブロックごとに最大 16 個の包含リストが許可され、各リストの最大サイズは 8KB (8192 バイト) に制限されます。16 個の包含リストによって提案されたトランザクションに重複がない場合、1 つのブロック内の IL トランザクションの最大サイズは 128KB に達する可能性があります。この制限は、包含リストが P2P ネットワークを通じて伝播する際に、バリデーターのリソース使用量を最小限に抑えるように設計されています。 では、FOCIL の下で IL を使用して Ethereum ブロックをどの程度構築できるでしょうか? 歴史的に、Ethereum ブロックの平均サイズは約 80～100 KB で、最大で約 300 KB です。16 の包含リストによって提案されたトランザクションに重複がない場合、理論的には IL トランザクションのみを使用して Ethereum ブロック全体を構築することが可能です。 ただし、このシナリオは起こりそうにありません。インクルージョン リスト内のトランザクションは通常、パブリック メモリ プールから取得されるため、16 人の IL 委員会メンバーがまったく異なる構成を使用しない限り、重複する可能性が高くなります。 要約すると、FOCIL の包含リスト内のトランザクションは、イーサリアム ブロックの 6 ～ 10% から最大 100% を占めると予想されますが、IL 委員会のメンバーが同じパブリック メモリ プールを参照している場合は、6 ～ 10% の範囲に近づくケースもあります。 FOCILを超えて: APSとFOCILの融合 APSの背景 FOCIL が主要なソリューションとなった理由の 1 つは、 などの Attester-Proposer Separation (APS) 提案との潜在的な相乗効果です。APS とは何ですか。また、FOCIL をどのように補完するのでしょうか。 実行チケット APS は、ブロックの提案者と証明者の役割を分離することを提案します。 イーサリアムでは、PBS によるブロック構築では、ブロックを提案する提案者とブロックの内容を構築するビルダーの役割を分割します。これにより、提案者とビルダーの同盟によって形成された中央集権型ステーキング プールが MEV の利益を独占し、通常のバリデータよりもはるかに高い APR を記録してバリデータ操作を集中化することが防止されます。 この問題は MEV-Boost によって解決され、残された集中化の懸念に対処するために、インプロトコル リレー システム (ePBS) が提案されました。しかし、PBS は本当に最適な構造なのでしょうか? Ethereum のコンセンサス レイヤーの重要な役割の 1 つは、バリデーターに報酬を分配し、ペナルティを課すことです。このプロセスが集中化されると、バリデーターの投票に関係なく、チェーンは集中化されたエンティティの影響を受けることになります。そのため、コンセンサス レイヤーは高度に分散化されたままである必要があります。 ただし、実行レイヤーには同じ制約はありません。MEV 抽出やトランザクションの順序付けなどのタスクは本質的に複雑かつ戦略的であり、集中化されたエンティティを必要とします。これらのタスクがすべてのバリデーターに課せられると、チェーンは集中化に向かうことになります。 この点に関して、イーサリアムの哲学は、「コンセンサス参加者は、個人の利益のために複雑なタスクを追求するようにインセンティブを与えられるべきではない」というものです。 PBS を通じて、Ethereum はバリデーターと MEV アクター (ビルダー、検索者) を分離し、MEV の利益をネットワーク全体に均等に分配します。 それでも、提案者は追加の利益を得るために型破りな戦略を採用することができます。 提案者と建設業者の共謀 ビルダーはすでに集中化されていますが、提案者もある程度集中化しています。たとえば、Coinbase はステークされた ETH 全体の約 10% を保有しています。Coinbase が特定のビルダーと共謀してそのビルダーのブロックのみを受け入れると、エコシステムに重大な集中化ベクトルが導入されることになります。 提案者タイミングゲーム イーサリアムの比較的長い 12 秒のブロック時間は、タイミング ゲームと呼ばれる興味深いダイナミクスを導入します。タイミング ゲームでは、提案者がブロックの公開を遅らせて MEV の利益を最大化します。 ブロックで利用可能な MEV は、通常、時間の経過とともに直線的に増加します。提案者は、次の提案者によって拒否されるリスクがある直前に公開することで、ブロックの伝播を遅らせて MEV を最大化できます。 では、提案者は 1 つのスロット (12 秒) 内でブロックの公開をどれだけ遅らせることができるのでしょうか。Ethereum のプロトコル仕様によると、次の提案者が前のブロックを有効と見なすには、そのブロックが前のスロットの委員会に割り当てられたバリデータ (検証者) の 40% から投票を受ける必要があります。 現在の Ethereum メインネットでは、バリデーター投票の 40% が受信されるポイントは、スロットの開始から約 3.8 秒後に発生します。 タイミングゲームをしようとする提案者は、次の提案者による拒否を回避するのに十分な投票数 (40% 以上) が得られるまで待機し、ブロックの公開を可能な限り遅らせる戦略を採用します。 ただし、結果は必ずしも提案者の意図と一致するとは限りません。ブロックが 40% の投票を得られなかった場合、次の提案者がそれを拒否します。このような場合、拒否されたブロックに投票したバリデータは、正規のチェーンの一部ではないブロックに投票したことになり、スラッシング ペナルティが発生します。 この状況が続く場合、バリデーターはネットワークの状態を観察し、投票が正確であることを確認するために投票を遅らせる可能性があります。この動作により、チェーン内の再編成の回数が増加する可能性があります。 要約すると、提案者のタイミングゲームは、Ethereum のコンセンサス結果に悪影響を及ぼす可能性があるため、防止する必要があります。 APSの役割 APS は、この問題に対処するために設計されたソリューションです。APS は、実行層に別のプロポーザを作成し、コンセンサス層を MEV から完全に分離することを提案しています。 例えば、代表的な APS 提案の 1 つである Execution Ticket では、ビーコン チェーン プロポーザーとは別の「実行プロポーザー」を導入しています。このシステムでは、プロトコルが実行チケットを生成して販売し、チケットの所有者に各ブロックの実行プロポーザーとしてランダムに選択される権利が付与されます。これらの実行プロポーザーは、現在 MEV-Boost でビーコン チェーン プロポーザーが担っている役割の一部を引き継ぎ、実行ペイロードを受信して提案します。 この設計の根拠は、実行提案者の集中化は問題ではなく、実際、コンセンサス層から分離することでシステム全体が改善されるということです。 では、ビーコンチェーン提案者は APS 下でどのようなタスクを処理するのでしょうか? バリデーターのデポジット、報酬、ペナルティ（ビーコン チェーン内の状態遷移）の管理とは別に、コンセンサス レイヤー プロポーザーには、APS における重要な追加の役割があります。それは、インクルージョン リストを構築し、それを実行レイヤーに渡すことです。 包含リストは、比較的集中化された実行提案者ではなく、コンセンサス レイヤーの分散化されたバリデータ セットに依存する方が望ましいです。これにより、検閲攻撃者が提案者と共謀してトランザクションを検閲する可能性が減ります。 したがって、実行チケットなどの APS 提案は、コンセンサス レイヤー バリデーターがビーコン ブロックの一部として包含リストを構築するメカニズムを提案しています。これらのリストは、実行提案者が完全なブロックを構築して提案するための基盤として機能します。 要約すると、インクルージョン リスト ベースの検閲耐性ソリューションは、Ethereum の APS ビジョンとシームレスに一致しています。その結果、FOCIL は検閲耐性の最も有望なソリューションの 1 つと考えられています。 FOCILの利点 FOCIL は、各 IL を 8 KB に制限し、16 のバリデーター (1 つの BLOB のサイズと同じ) からなる IL 委員会を設けることで、ネットワーク リソースの使用を適切なレベルに維持しながら、効果的な検閲耐性を保証します。 以下のグラフは、IL 委員会の正直なバリデーターの割合に応じて、トランザクションがチェーンに含まれるまでにかかる時間を示しています。委員会のバリデーターの 15% だけが非検閲であっても、トランザクションはすぐに含まれる可能性があります。これは、16 人のバリデーターからなる小規模な委員会が、いかにして効率的な検閲耐性を実現できるかを示しています。 考えられる解決策2: 複数の同時提案者/ビルダー 複数の参加者がブロック全体を同時に提案できるようにするのはどうでしょうか? この概念は「複数同時提案者」として知られています。 一度に 1 つのエンティティがブロックを提案するのではなく、複数のエンティティが同じスロットに対して同時にブロックを提案します。 特定の条件下では、このようなソリューションを採用すると、検閲のコストが大幅に増加する可能性があります。Ethereum には、各エポックの 32 ブロックの提案者が同時に公開されるメカニズムがあります。この設定により、誰かが提案者に「賄賂」を贈って特定のトランザクションを検閲しようとするシナリオが可能になります。しかし、ブロックが 1 人の提案者ではなく、N 人の提案者によって同時に提案されたらどうなるでしょうか。このシナリオでは、条件付きヒントのようなメカニズムを採用すると、N 人の提案者の間に「囚人のジレンマ」を導入することが可能になり、検閲のコストが大幅に増加します。 たとえば、N 人の提案者がブロックを作成するタスクを負い、アリスが提案者に自分のトランザクションを含めるように要求し、ボブがアリスのトランザクションを検閲しようとしている状況を想像してください。アリスは提案者に自分のトランザクションを含めるように賄賂を渡すことができ、ボブも提案者に賄賂を渡して検閲させることができます。この状況では、アリスは次のように、ボブの検閲コストを効果的に増やす賄賂戦略を採用できます。 2 人以上の提案者がトランザクションを含める場合、アリスは各提案者に t の小さなチップを渡します。 トランザクションを含める提案者が 1 人だけの場合、アリスはその提案者に T という大きなチップを渡します。 この場合、提案者は「囚人のジレンマ」のような状況に陥ります。このゲームでの各提案者にとっての最適な戦略は、トランザクションを検閲するのではなく、トランザクションを含めることです。ボブがアリスのトランザクションを検閲するには、N 人の提案者全員に賄賂を贈る必要があり、NT の費用がかかります。一方、アリスは、トランザクションが確実に含まれるようにするために、最大でも Nt しか支払う必要がありません。これにより、検閲のコストが大幅に増加します。 このコンセプトは、いくつかの方法で PBS 上に実装できます。たとえば、複数の提案者が同時にブロックを構築したり、複数のビルダーが同時にブロックを構築したりできます。 このセクションでは、PBS 構造内でこれを実現するための 2 つのメカニズムを紹介します。 BRAID - 複数の同時提案者 BuilderNet - 複数の同時ビルダー 編み込み BRAIDの概要 BRAID は、Special Mechanism Group の一員であった Max Resnick によって提案された、Ethereum の検閲耐性ソリューションです。 このメカニズムは、シンプルでありながら強力な概念に基づいています。現在の Ethereum のように単一のチェーンを実行するのではなく、k 個の同期された LMD-GHOST チェーンが並列に実行されます。言い換えると、BRAID では、k 個の提案者が各スロットに対して同時に独自のブロックを生成します。 BRAIDの仕組み 当然の疑問が浮かびます。k 個のブロックはどのように処理されるのでしょうか? 単一のブロックチェーンを維持するためにブロックは最終的に 1 つに統合される必要があるため、BRAID は定義済みの順序付けルールを使用してブロックを結合します。 たとえば、重複を削除し、手数料の降順でトランザクションを並べ替えることで、ブロックを統合できます。最終的なブロックには、統合され、順序付けられたトランザクションが含まれます。 利点と制限 BRAID にはいくつかの利点があります: 強力な検閲耐性 BRAID では、複数の提案者が同時に作業できるようにすることで、複数のエンティティに賄賂を贈る必要があるため、検閲のコストが大幅に増加します。 強制的なトランザクション順序付け このメカニズムはトランザクションの順序を明示的に定義するため、トランザクションの順序に敏感なリアルタイムのオンチェーン オークションなどのアプリケーションに適しています。 ただし、特定のアプリケーションがアプリ固有のシーケンス ルールを実装できなくなるため、必ずしもこれが利点となるわけではないことに注意してください。 ただし、BRAID にも制限があります。すべての k チェーンを同期させる必要があるため、バリデーターには追加のネットワーク リソースが必要です。これは、バリデーター要件を削減するという Ethereum の目標に反します。 ビルダーネット BuilderNetの概要 BuilderNet は、複数のエンティティが同時にブロックビルダーとして動作できるようにすることで検閲耐性を高めるために Flashbots によって提案されたソリューションです。 BuilderNet の初期バージョンでは、複数のエンティティがさまざまな規制ガイドラインに従って単一のビルダーを操作するマルチオペレーター モデルを実装しています。これにより、単一オペレーター ビルダーと比較して、より高い検閲耐性が確保されます。BuilderNet は、複数の同時ビルダー ソリューションの構築に向けた一歩です。 BuilderNet の最初のリリースは、Flashbots、Beaverbuild、Nethermind によって共同で運営されており、将来的にはさらに多くのビルダーを参加させる予定です。 BuilderNetの今後の分散化計画 現在のマルチオペレータ モデルは、外部の観察者には依然として単一のビルダーとして表示されるため、達成できる検閲耐性のレベルが制限されます。BuilderNet の今後のリリースでは、次の変更を通じてネットワークをさらに分散化し、検閲耐性を強化することを目指しています。 ビルダー間の注文フローの共有 BuilderNet の将来のバージョンでは、ブロック構築プロセスが分散化され、あるビルダーが別のビルダーによって検閲されたトランザクションを取得できるようになります。理論上は、少なくとも 1 つの非検閲ビルダーが存在する限り、すべてのユーザー トランザクションをブロックに含めることができます。このアプローチにより、BuilderNet は真の複数同時ビルダー モデルに進化することが期待されます。 分散型インフラストラクチャ 現在のバージョンの BuilderNet は、トランザクションの入力とデータの保存に中央インフラストラクチャに依存しており、参加には許可が必要です。将来のバージョンでは、BuilderNet を許可なしにすることでこの問題に対処することを目指しています。 より良いUXとDXのためのTEE BuilderNet は、信頼できる実行環境を活用して、アプリ、ウォレット、検索者、ユーザーにとってより使いやすい環境も構築します。 TEE は、ハードウェアの信頼に基づいてソフトウェアが仕様どおりに動作することを保証し、ビルダーがデータを恣意的に省略したりコードを変更したりすることを防ぎます。BuilderNet を使用すると、TEE がブロック構築に貢献する検索者への報酬分配ロジックの実行を強制するため、検索者はビルダーにバンドルを送信するときに高い保証を得ることができます。報酬分配ロジックが十分に公平であれば、検索者はビルダーとの正式な契約に匹敵する経済的な保証を得ることができます。 検索者に加えて、MEV の獲得を目指すアプリやウォレットも BuilderNet のアーキテクチャから恩恵を受けることができます。 L2のBuilderNet BuilderNet の注目すべき点は、レイヤー 2 ソリューションへの潜在的な適用性です。 Ethereum L2 は、Ethereum のセキュリティを継承するために、証明システムと分散型バリデータ アーキテクチャを積極的に開発しています。これらのシステムはブリッジ内のユーザー資金の安全性を保証しますが、Ethereum の検閲耐性は継承しません。 L1 から L2 へのトランザクションの強制トランザクション メカニズムでは、現在、トランザクションを L2 に含めるのに最大 12 ～ 24 時間 (設計によって異なります) かかるため、リアルタイムの検閲耐性を提供できません。 ブロック構築を BuilderNet にアウトソーシングすることで、L2 は単一シーケンサーよりも高い検閲耐性を実現できると同時に、Unichain などのアーキテクチャと同様に、TEE による強制的なトランザクション順序付けを通じて MEV の再配布が可能になります。 結論 理想的には、ブロックチェーンは検閲に抵抗する必要があり、Ethereum コミュニティはビルダーの集中化によって引き起こされる検閲耐性の問題に対処するためにさまざまなソリューションを提案してきました。最も有望なソリューションの 1 つが FOCIL です。これは、16 のバリデーターが各ブロックの包含リストを提案し、効率的な検閲耐性と APS との互換性を提供するものです。FOCIL は、2025 年後半または 2026 年初頭に予定されている Fusaka アップグレードに組み込むために議論される予定です。 同時に、Flashbots が主導する複数の同時ビルダー モデルに関する議論が進行中です。ビルダーを分散化することで、Ethereum の検閲耐性が大幅に向上し、コア Ethereum 開発とは独立して実装できるため、より迅速な導入が可能になります。 これらの取り組みを通じて、イーサリアムは、トランザクションの包含に対して過度の影響力を持つ単一のエンティティがない、信頼できる中立的な実行レイヤーに向けて着実に前進しています。FOCIL のバリデーター主導の包含リストとブロックビルダーの潜在的な分散化を組み合わせることで、イーサリアムは MEV 配布の効率性と公平性を維持しながら、検閲に対する耐性を高めることができます。これらのソリューションが進化するにつれて、ネットワークは分散化、許可のないアクセス、中立性というコア原則を維持し続け、イーサリアムが将来にわたって堅牢で検閲に強い決済レイヤーであり続けることを保証します。 この記事は元々 。 ここ