この文書は、私たちの仕事から着想を得て作成されました。FOCILコンセンサススペック23, ここで、プロトコルが特定の詳細が明示的に指定されていないため、リソース制約に関するより慎重な考慮が必要であることに気付きました。FOCIL Ethereumリサーチ投稿14.

前提条件

始める前に、次のセットアップを想定して、私たちの考慮のためのクリーンなベースラインを確立すると仮定します:

• セットアップはElectraハードフォークに基づいています。比較のためにEIP-7732（ePBS）の上でこれを見直すことも意味があります
• 私たちは、提案者がMEV-Boostを実行していないソロブロックの構築とリリースを想定しています。これは、Builder APIが二次的な考慮事項である中で、正しく取得する最初の重要なコンポーネントです。
• typical compute, memory requirements, and bandwidth that you can easily follow on the Ethereum chain today

俳優

進行する前に、次のアクターがプロトコルの一部であると仮定し、彼らの責任を分析します。

• インクルージョンリスト（IL）委員会のメンバーは、インクルージョンリストトランザクションのセットによって次のスロットプロポーザーを制限する責任があります。
• 次のスロット提案の責任を負う提案者
• チェーンのヘッドの次のスロットに対して証明を行う証明者
• ノードは、チェーンを検証し、フォローしています。提案者と証人は、Etherをステーキングしたノードの一部です。

タイムライン

IL委員会、提案者、および証人が正直な行動を行うと仮定した以下のタイムラインを想定します:

• スロットn-1、t=6：IL委員会は、ブロックn-1の内容を学んだ後、グローバルトピックに関するローカルインクルージョンリスト（IL）を公開します
• スロットn-1、t=9：証明者と正直な検証ノードは、ローカルILのビューをロックします
• Slot n、t=0: Slot nのブロック提案者がブロックBをリリースし、IL要件を満たすべきペイロードを含めます
• Slot n、t=4: スロットnの検証者は、ブロックBに投票し、それをローカルILビューと比較してIL集約を検証し、ブロックBが「有効」であるかどうかを確認します
  • ブロックを指す際に「有効」という言葉を過剰に使用しますが、「取り込み可能」、「正準」、またはその他の意味になる可能性があります。詳細な説明についてはオープンな質問を参照してください。

インターバル1: IL委員会がローカルILをリリース

アクター：インクルージョンリスト委員会

IL委員会のメンバーは、ヘッド（CL → EL呼び出し）からILトランザクションのリストをELクライアントから取得し、それからローカルIL（トランザクション+サマリ）に署名し、ゴシップネットワークにリリースします。

リソースの考慮事項

• ELメンプールからILトランザクションを取得 → CPU/MEM
• インクルージョンリストへの署名 → CPU
• 含めるリストをゴシップネットワークにアップロードする→帯域幅（アップロード）

アクター：ノード（アテスターを含む）

チェーンをたどるノードは、ILをダウンロードし、アンチDOSを検証し(まだELにインポートしていません)、他のピアに転送します。また、ノードは IL を fork choice にインポートし、aggreGate キャッシュを使用してどの IL が確認されたかを追跡します。チェーンをフォローするアテスターとノードは、チェーンの同じビューを持つ必要があります。

リソースの考慮事項

• ILのダウンロード→帯域幅（ダウンロード）
• IL → バンド幅 (アップロード) の転送
• anti-DOSのILを検証中です → CPU/MEM
• Caching seen and aggreGate ILs → MEM

アクター：提案者

次のスロットの提案者はILゴシップネットワークを積極的に監視し、ローカルのILを収集および集約し、IL集約のカットオフ（インターバル＃2）で、提案者は自分のブロックに含まれるILトランザクションのリストでブロック構築プロセスを更新します。これにはCLからELへの呼び出しが必要です。

リソースの考慮

• チェーンに従うノードと同じコストを継承します

提案者のエッジケース

次のスロットの提案者が親ハッシュに基づいた十分な含有リストを観察した場合、提案者は不足しているビーコンブロックを手動でリクエストし、ブロックをインポートし、そのブロックの上に構築する必要があります。

結論

上記に基づいて、リソースを多く消費する可能性のある領域を特定し、それらに絞り込むことができます。

• IL委員会のCPU影響：ELからのILトランザクションの取得&署名：ここにはリソースの需要がありますが、これは比較的安価であり、重大な懸念ではないと見なされています。
• ノードの帯域幅への影響：ノードがILをダウンロードおよびアップロードすると、特に研究ポストが現在、ILのサイズが柔軟/無制限であると述べているため、大量の帯域幅を使用する可能性があります。これにより、悪意のあるIL委員会メンバーが大量のトランザクションをネットワークに洪水をかける可能性があり、それが無効であっても、ノードはILについてまだゴシップを行うでしょう。Anti-DoS対策は慎重に検討する必要があります。

間隔2：ノードはビューをロックし、提案者はILトランザクションをインポートします

アクター：提案者

提案者は、インクルージョンリストトランザクションのリストを使用してブロック構築プロセスを更新します。これはCL → ELコールです。

リソースの考慮事項

• リストに含まれるトランザクションのブロックビルディングプロセスを更新します → CPU/MEM

アクター：ノード（アテスターを含む）

ロックインクルージョンリストビュー。この地点からローカルインクルージョンリストの受け入れを停止します。

リソースの考慮事項

• ローカルインクルージョンリストビュー→なし

結論

• 提案者のCPUへの影響: ILトランザクションをブロック構築プロセスに取り込むことは、ブロック構築プロセスを妨害する可能性があり、トランザクションのシミュレーション中に実行レイヤークライアントのCPUを過負荷にする可能性があります。これはアカウントの抽象化では複雑になるかもしれません。これについてさらに分析する必要があります。

間隔3：提案者がブロックをリリース

アクター：提案者

提案者はELクライアントから実行ペイロードを取得し（CL→EL呼び出し）、ビーコンブロックのゴシップネットワークにリリースします。その後、他の全員がブロックを検証します。

リソースの考慮

• ELクライアントからペイロードを取得→CPU/MEM

俳優: ノード

ノードはビーコンブロックを受信し、検証します。新しい検証手順には、インクルージョンリストの集合構築のチェックと、評価関数を満たすかどうかを確認する手順が含まれます。これはCL上で完了することになります。IL条件のチェック（衝突のためスキップできるかどうか）はEL上で実行されます。

リソースの考慮

• CL → CPUでインクルージョンリストが満たされていることを確認します
• EL → CPUに含まれる条件を確認しています

結論

提案者の追加業務は重大な懸念ではないようです。ノードの新しい検証手順は、収容リストが満足のいく条件を満たしていることを確認することですが、追加のCPU負荷を導入する可能性がありますが、それは重大な問題ではないようです。

インターバル4：アテスターコミティ

Actor: Attester

アテスターは、LMD GHOSTフォーク選択ルールを使用してビーコンブロックに投票します。アテスターは、インターバル1からの観測に基づいてインクルージョンリスト評価関数を満たすビーコンブロックにのみ投票します。

リソースの考慮

• インクルージョンリスト評価関数を満たすブロックに対してアテスターが投票する→追加費用なし

結論

今日と違いはありません。

リソース考慮の概要

上記のように、最も重要なリソースに関する懸念事項は、含意リストのアップロード、ダウンロード、およびノードの視点からのスパムの可能性についてです。 もう一つの重要な懸念事項は、含意リストの検証とインポートに対するノードへのオーバーヘッド、および提案者が含意リストを満たすためにそのブロック構築プロセスを更新する必要があります。 これらの側面には、効率とセキュリティを確保するために慎重な考慮と設計が必要です。

オープンな質問

上記を基に、仕様書の記載方法に影響を与えるいくつかの未解決の問題を概説します。

1. 評価関数を満たさないブロック：包含リスト評価関数に合格しないブロックはどのように扱うべきであり、そのような状況に対する設計上の考慮事項は何ですか？
   • それはblobと同様に扱われ、インポートできませんか？
   • フォークの選択によってフィルタリングされないべきではありませんか？
   • 状態遷移関数で有効でない場合はどうなりますか？
2. インクルージョンリストの言い逃れ：インクルージョンリスト委員会のメンバーが異なるバージョンのインクルージョンリストを異なるノードに送信し、すべてのノードがネットワーク全体に伝播した場合、この行動の結果は何ですか？どのようにして、このような行動が次のブロックを提案するプロポーザーに悪影響を与える可能性がありますか？
3. プロポーザーはすでに異なるヘッドで構築中です: プロポーザーが収容リスト委員会から送信されたものとは異なるヘッドで構築し、そのためにヘッドビューを変更する必要がある場合、この行動のブロックの有効性とプロポーザーの振る舞いにはどのような影響がありますか？
4. Inclusion List Transactions Invalidations: ローカルのインクルージョンリストトランザクションはいくつかの方法で無効になる可能性があります。これらのトランザクションが無効になったとしても、ブロックは評価関数を満たす必要があります。トランザクションは、複数のインクルージョンリストがお互いにマージしたり、ブロック内のトランザクションとマージしたりすることで無効になる可能性があります。典型的なノンスのチェックに加えて、アカウントの抽象化により、トランザクションが無効になる新しい方法が導入されます。静的なノンスで残高を排出することができるためです。トランザクションの無効化により、ブロックビルダーが実行する追加のシミュレーションと、これがCPU演算にどの程度影響を与えるかは、MEV-Boostアクターやローカルのビルダーの両方にとってまだ見えていません。
5. 提案者によるIL委員会サブネットの観察: 提案者は、包含リスト委員会のサブネットを監視して、aggreGateを構築する準備が整ったタイミングを把握します。ここには 2 つの設計アプローチがあり、それらをさらに検討する価値があります。最初のアプローチは貪欲な提案者で、提案者は t=9 まで待機し、できるだけ多くの IL を収集して EL に送信し、EL はブロックを更新します。2 番目のアプローチは選択的提案者で、提案者は eval 関数を満たすのに十分な包含リストが得られるまで待機し、それらを EL に送信し、これを t=9 秒未満またはそれ以前に行うことができます。問題は、2番目のアプローチが、提案者が包含リストaggreGateを早期にリリースできるように最適化を正当化するかどうかです。2番目のアプローチは、専用のガスリミットを持つILにのみ適している可能性があります。

免責事項：

1. この記事は[から転載されましたethresear]. All copyrights belong to the original author [terence]. この転載に異議がある場合は、お問い合わせください。Gate Learnチームが迅速に対応します。
2. 免責事項：本文に表現されている意見はすべて著者個人のものであり、投資アドバイスを構成するものではありません。
3. 記事の翻訳は、Gate Learn チームによって他の言語に翻訳されます。特に記載されていない限り、翻訳された記事のコピー、配布、または盗作は禁止されています。