Ethereumの研究者らは、ドラフト提案EIP-8411に基づくセグメント化ブロードキャスト設計により、1 MiBの実行ペイロードのシミュレーション上の中央伝播時間が約5秒から約0.75秒に短縮されたと、Ethereum Researchの記事で報告した。

プルーフ・オブ・ステークのネットワークでは、バリデータが各新しいブロックを受け取り検証してから証明（アテステーション）するまでの時間が限られているため、伝播速度はとりわけ重要な意味を持つ。

このテストでは、地理的レイテンシ、上り50 Mbps、下り100 Mbpsの容量を持つ500ノードをモデル化した。ペイロードは高帯域幅のデータセンターノードではなく家庭向け環境のビルダーから送信されており、送信側にデータセンターインフラがない場合の設計の性能を検証する選択であった。研究者らはシミュレーションネットワーク上で仮想クロックを用いて実際のPrysmおよびgo-libp2p-pubsubのコードを実行し、単一のトポロジーに依存しないよう各測定を10回のランダム化された構成で繰り返した。

ペイロード全体を1つのGossipSubメッセージとして送信した場合、約5秒でネットワークの半分に到達し、最も遅いノードでは6秒近くかかった。一方、調整済みのセグメント化方式は、これらの数値をそれぞれ約0.75秒と1秒に短縮した。

EIP-8411、ペイロード全体の待機をセグメント化ブロードキャストに置き換え

EIP-8411は、EIP-7732の単一のexecution_payloadゴシップトピックを、新しいexecution_payload_chunksトピックに置き換える。ノード中継前にペイロード全体を待つ必要がなくなる。代わりに、到着した独立して認証されたセグメントを検証・転送でき、各セグメントをビルダーの実行入札に含まれるMerkleルートと照合する。

この提案は2026年9月4日にオープンされ、いまだ未承認のDraftネットワーキングEIPである。また、EIP-7732、すなわちEthereumの組み込みプロポーザー・ビルダー分離設計に依存しており、この設計ではビルダーが実行ペイロードを構築し実行入札を通じてプロポーザーに提示することで、ブロック構築とブロック提案が分離される。

この結果はプロトタイプのクライアントコードを用いた管理されたシミュレーションによるものであり、Ethereumメインネットでの測定結果ではない。したがって、実際の環境での性能向上については依然として検証が必要である。研究者らは自身のブランチを「プロポーザルではなくハーネス」と表現した。

この知見はXの投稿でも紹介された：

Ethereum researchers just exposed the hidden dependency behind fast block propagation: datacenters. Then they removed them.
1 MiB payload. 500 nodes. Home-grade bandwidth. No high-bandwidth datacenter nodes.
GossipSub: ~5s median
Segmented propagation: ~0.75s
But the more… pic.twitter.com/cytAvwJtwr
— slymnogunc (@slymnogunc) September 17, 2026
https://x.com/slymnogunc/status/2100558704584151054?ref_src=twsrc%5Etfw

高速な伝播はより高いネットワークオーバーヘッドを伴う

Ethereumのコンセンサスレイヤーは、GossipSubというパブリッシュ・サブスクライブ型ゴシッププロトコルを用いて、ブロックやその他のメッセージをピアツーピアネットワーク全体に拡散している。現在のゴシップモデルでは、ノードが大きなメッセージ全体を受信・検証してからでないと中継できないため、ストア・アンド・フォワード遅延が生じうる。基本的なTier 1設計は16 KiBのセグメントをバッチ公開と併せて使用する。テストでは、1 MiBの中央伝播時間が5秒から1秒未満に短縮された。末尾レイテンシも約6秒から1秒強に低下した。

トレードオフとして、受信バイト量は現在のメッセージ全体方式より約3分の1増加した。より高度な方式は、この重複バイトのオーバーヘッドを直接ターゲットにしている。disciplined pullsと呼ばれる方式では、ノードは欠落したセグメントを1つのピアに要求し、そのピアがタイムアウトした場合は別のピアにフォールバックする。これにより受信トラフィックはノードあたり約1.5ペイロード分に削減された。ただし、ピアがアドバタイズしたセグメントを提供しなかった場合、末尾レイテンシは増加した。

第3のアではリード・ソロモン消去符号を追加する。これはテストで最も低い末尾レイテンシを記録し、ピアがセグメントを保留しても動作し続けた。その代償は送信元での帯域幅需要の増大である。

このトレードオフは、Glamsterdam以降のEthereumのスケーリングロードマップに関係する。より大きなガスリミットと実行ペイロードは、ノードの帯域幅にさらなる負担をかけると予想される。研究者らはまた、制御メッセージのトラフィック、多数の小さなメッセージ処理によるCPUコスト、キュー管理、タイマーの調整、クライアント間の調整に関する未解決の課題も指摘した。

ACDC、Hegotá向けEIP-8411を検討

Ethereumエコシステムでは、Glamsterdam後に予定されるネットワークアップグレードであるHegotáへの提案の組み込み可能性についても議論された。Barnabé MonnotはXに次のように投稿した：

After a month of community outreach, @ethlabs_org is shipping a major piece on a faster Ethereum with faster L1 blocks, collecting perspectives from all corners of the ecosystem. Ethereum core developers are in the final stretches of deciding what to include in Hegotá, the…
— Barnabé Monnot | barnabé.eth (@barnabemonnot) September 17, 2026
https://x.com/barnabemonnot/status/2100575903461839032?ref_src=twsrc%5Etfw

Ethereumの開発者らは、通常のHegotá PFI締切後に、HegotáにおけるEIP-8411のProposed for Inclusion（組み込み候補）ステータスを要請した。Proposed for Inclusion（PFI）とは、EIPを特定のネットワークアップグレードの候補とするステータスである。ACDC #187のアジェンダでは9月17日14:00 UTCにPFIに関する議論が予定されていた。ただし、一次報告の時点でそのコールはまだ行われておらず、組み込みの決定は記録されていなかった。

Prysmとgo-libp2p-pubsubのプロトタイプ実装はすでに公開されている。しかし研究者らは、高度な消去符号の構成は、EIP-8411の最小仕様の確認済み構成要素ではなく、実験的なテスト環境機能にとどまると注意を促している。EIP-8411がEthereumのスケーリングインフラの一部となるかどうかは、今後のコア開発者による決定にかかっている。