イーサリアム EIP-8411 は 1 秒未満のペイロード伝播をテストします

イーサリアムの研究者らは、ペイロードを 1 つのメッセージとして送信する場合の約 5 秒と比較して、EIP-8411 のセグメント化されたブロードキャスト設計を使用してシミュレートされた 1 MiB 実行ペイロードの伝播速度の中央値が 1 秒未満であると報告しました。

Ethereum Researchは9月17日に最新のテスト結果を発表し、実行ペイロードをより小さな部分に分割し、ノードが完全なペイロードを受信する前に各セグメントを検証して転送できるようにするプロトタイプを詳述した。この結果は、イーサリアムのメインネットの測定ではなく、シミュレーションとプロトタイプのクライアントコードから得られたものです。

この提案は、イーサリアム EIP リポジトリにドラフトネットワーキング EIP として残されています。現在の設計では、EIP-7732 を通じて導入された単一のexecution_payload ゴシップトピックがexecution_payload_chunks トピックに置き換えられ、ビルダーの実行入札に含まれるマークルルートを通じてピースがコミットされます。

イーサリアム EIP-8411 はペイロード全体の待機を削除します

イーサリアムの既存のゴシップモデルでは、ノードが大きなメッセージをピアに転送する前に受信して検証する必要がある場合があります。 EIP-8411 の背後にある研究者は、完全なペイロードが次のネットワークホップを開始する前に 1 つのネットワークホップを通過する必要があるため、結果として生じる遅延をストアアンドフォワードの問題と説明しています。

セグメント化された伝播では、ビルダーはペイロードを固定部分に分割します。各セグメントには、約定入札でコミットされたルートに関連付けられたマークル包含証明が含まれています。受信ノードは 1 つのセグメントをチェックし、残りの部分がまだ到着している間にそのセグメントの送信を開始できます。

さらに、Ethereum Magicians に関する EIP の議論では、計画されている変更は、EIP-7732 の単一ペイロードメッセージを独立して検証可能なチャンクに置き換えることであると説明されています。現在、ドラフトでは 64 個のチャンクと、すべての部分を元のペイロードコミットメントにバインドするマークル証明構造が提案されています。研究者らは、マークルのコミットメントは、基本的なセグメンテーションに必要な主要なコンセンサスレベルの追加を表していると述べた。最新の研究プロトタイプは、既存の gossipsub ワイヤ形式、ネットワークメッシュ構造、ピアディグリー、スコアリングシステムをそのまま維持しながら、ペイロード部分の公開および転送方法を変更します。

イーサリアムのドキュメントでは現在、実行ペイロードを、実行クライアントによって生成され、コンセンサスプロセスを通じて伝達されるトランザクションおよび状態関連のデータとして説明しています。バリデーターは、検証のために実行データを実行クライアントに送信する前に、コンセンサスゴシップネットワークを通じて提案されたブロックを受け取ります。

シミュレーションでは 5 秒から 1 MiB の中央値を削減

9 月 17 日のレポートで最も強力なパフォーマンスの数値は、制御されたシミュレーションから得られたものです。研究者らは、地理的なネットワーク遅延、50 Mbps のアップロード容量と 100 Mbps のダウンロード容量を使用し、住宅建設業者から発信される 1 MiB ペイロードと高帯域幅を持たない 500 ノードをモデル化しました。>より高度な階層により、重複したネットワークトラフィックが削減されます

2 番目に提案されている層は、重複データに取り組みます。すべてのセグメントを適格なすべてのメッシュピアにプッシュする代わりに、ノードは他のグループに可用性をアナウンスしながら、一部を限定されたグループにプッシュできます。ピアは、必要な場合にのみ欠落セグメントを要求します。

このプロトタイプは、そのシステムと、作成者が呼ぶ規律あるプルとを組み合わせたものです。ノードは最初に 1 つのピアからセグメントを要求し、定義されたタイムアウトを待ち、最初のピアが配信に失敗した場合は別のソースに移動します。

調査によると、ペイロードサイズが 1 MiB の場合、統制のとれたプルにより、受信トラフィックがノードあたり約 1.5 ペイロードコピーに減少しました。これに対し、あまり制御されていないバリアントでは重複トラフィックが大幅に増加しました。研究者らは、利用可能なアップロード帯域幅が限られている場合、重複を減らすことがますます有用になることを発見しました。

このアプローチでは別のトレードオフが生じます。悪意のあるピアまたは過負荷のピアは、セグメントをアナウンスした後、その提供を拒否する可能性があります。研究者らは、一部のノードがセグメントをアドバタイズしたがリクエストに応答しないという源泉徴収シナリオをテストしました。より高い源泉徴収レベルでは、調整されたプルベースの設計により、テールレイテンシの上昇が示されました。著者らは、その危険性を制限する方法として、より短いタイムアウトと考えられる複数のリクエストソースをテストしました。

3 番目の層では、リードソロモン消去コーディングが追加されます。ペイロードは圧縮され、追加のパリティピースでエンコードされ、セグメントに分割されます。ノードは、元のセグメントをすべて待つことなく、十分なピースを収集した後にペイロードを再構築できます。

研究者らは、コード化されたモデルはテストでテール遅延が最も低く、一部のセグメントが保留された場合でも機能し続けたと述べた。パリティデータにより送信される量が増加するため、パブリッシュソースの帯域幅が増加するというコストがかかりました。

EIP-8411 はヘゴタの包含に関する議論に直面しています

EIP-8411 は現在有効化された Ethereum 機能ではありません。 GitHub の提案は 9 月 4 日に公開され、まだレビュー待ちのドラフトネットワーキング EIP としてラベル付けされています。この提案には、イーサリアムに組み込まれた提案者と構築者の分離設計である EIP-7732 が必要です。

イーサリアム開発者らは、EIP-8411がグラムステルダム後に予想されるネットワークアップグレードであるヘゴタのPFI（Proposed for Inclusion）ステータスを取得することを要求した。 9月10日のAll Core Developers Executionディスカッション中、開発者らは、この変更は主にコンセンサスネットワーキングに影響を与えるため、この提案はコンセンサス層の開発者会議で検討されるべきだと述べた。

この要請は通常のヘゴタ PFI 期限後に行われた。その支持者らは、EIP-8411をEIP-8142の代替として提案した。EIP-8142はブロブにブロックを配置することを検討していたが、構築者側のKZG証明とtarget=”_blank”>の再利用に対する懸念を引き起こし、バリデーターが増加への支持を表明した後、イーサリアムのガス制限は2025年後半に6,000万に達した。

Vitalik Buterin 氏は、イーサリアムの拡張計画の一部として、より高いレイヤー 1 容量、PeerDAS、および将来の ZK-EVM の取り組みについて説明しました。ネットワークメッセージが大きくなると、ノードの帯域幅と伝播期限にさらに大きな圧力がかかるため、これらの変更と並行して、より高速なペイロード配信が研究されています。

プロトタイプコードは利用可能ですが、まだ実験段階です

研究者らは、Prysm と go-libp2p-pubsub のプロトタイプ実装を公開しました。推奨されるバリアントである Prysm ブランチには、-enable-segmented-payload-gossip フラグの背後にある一連の変更が含まれており、付随する libp2p ブランチは、調査で使用された転送ポリシーとリクエストポリシーを実装しています。

著者らは、自分たちの研究部門を「提案ではなく活用」であると明確に説明しています。高度な消去コーディング構成など、論文で測定された一部の機能は、テスト環境の実験的なコンポーネントのままであり、必ずしも EIP-8411 の最小仕様の一部ではありません。

研究者らによって特定された未解決の疑問には、制御メッセージトラフィックの増加、多数の小さなメッセージの処理による CPU コスト、代替セグメントマッピング、キュー管理、タイマー調整、および QUIC に重点を置いた新しいネットワーキングスタックが異なる結果を生み出す可能性があるかどうかなどが含まれます。

著者らは、バリアント A で使用される単一トピック設計、部分メッセージアプローチ、および個別のゴシップトピックを個々のセグメントに割り当てるモデルをさらに比較することを計画しています。現在のプロトタイプでは、シミュレーションにより、より小さい 8 KiB ピースでは制御トラフィックが増加してもレイテンシーがさらに増加しないことが示されたため、推奨ベースラインとして 16 KiB ピースが維持されています。