Ethereum's networking problem has a number attached, and this week it got a smaller one. In test results published September 17, Ethereum Research reported that a simulated 1 MiB execution payload reached half the network in a median of about 0.75 seconds using EIP-8411's segmented broadcasting design — versus roughly five seconds when the payload travels as a single message. The difference is the gap between a block arriving in time and validators missing their slots, and it is the kind of margin Ethereum needs if it keeps raising the gas limit. The ACDC call scheduled for 14:00 UTC today was set to discuss whether EIP-8411 earns Proposed-for-Inclusion status in Hegotá, the upgrade after Glamsterdam; at press time, no decision had been recorded.
The numbers deserve their caveats before their celebration. They come from a simulation harness running real Prysm and go-libp2p-pubsub code against a virtual network of 500 nodes with geographic latency and home-builder bandwidth of 50 Mbps up, 100 Mbps down — not from Ethereum mainnet, a distinction the researchers repeat often. Each measurement used ten randomized network configurations. Still, the result is the first serious evidence that chunked payloads can fix what researchers call the store-and-forward problem.
What EIP-8411 Changes in Ethereum's Networking
Under Ethereum's current gossip model, a node must receive and validate a complete payload before forwarding it — the whole message crosses one hop before the next begins. EIP-8411 replaces the single execution_payload gossip topic introduced by EIP-7732, the enshrined proposer-builder separation design it depends on, with an execution_payload_chunks topic. The builder divides the payload into fixed pieces — 64 chunks in the current draft — and each segment carries a Merkle inclusion proof tied to a root committed in the builder's execution bid. A receiving node checks one 16 KiB segment and starts forwarding it while the rest are still arriving. The Merkle commitment is the main consensus-level addition the change requires; the rest is networking.
In the Tier 1 simulation, that combination with batch publishing — the source distributing different pieces to different peers early so several sections move at once — cut the 1 MiB median from five seconds to under one second and the tail from roughly six seconds to just over one. The cost: about one-third more received bytes than today's whole-message approach, paying control-message overhead for speed.
The Tiers That Trade Bandwidth for Latency
Pushing every segment to every mesh peer wastes bandwidth, so the second tier pushes pieces to a limited group and announces availability to the rest, with peers requesting missing segments only when needed. Its "disciplined pulls" — request one segment from one peer, wait a defined timeout, move to the next source on failure — reduced received traffic to roughly 1.5 payload copies per node at 1 MiB. The failure mode is withholding: a peer that advertises a segment and refuses to serve it inflates tail latency, which researchers counter with shorter timeouts and multiple request sources. The third tier adds Reed-Solomon erasure coding, compressing the payload and encoding parity pieces so nodes can reconstruct it without collecting every original segment. That model posted the lowest tail latency in testing and stayed functional under withholding, at the price of higher source-side bandwidth.
The design connects directly to Ethereum's scaling roadmap. The gas limit reached 60 million in late 2025 after validators signaled support, and every increment makes execution payloads bigger while consensus deadlines stay fixed — the exact pressure EIP-8411 exists to relieve, alongside PeerDAS and the ZK-EVM work Vitalik Buterin has described as the longer-term plan. A chain that wants bigger blocks must first make blocks move faster.
From Simulation to Hegotá
The proposal's path is tight and slightly irregular. GitHub opened it on September 4 as a Draft networking EIP; during the September 10 All Core Developers Execution call, developers said it should be handled by the consensus-layer call because it primarily affects consensus networking, and its proponents requested PFI status for Hegotá — after the normal inclusion deadline had passed. It replaces EIP-8142, an earlier idea that put blocks into blobs but raised builder-side KZG proving and data-availability subnet concerns. Prototype code exists for Prysm and go-libp2p-pubsub behind an experimental flag, but the authors describe their branch as "a harness, not a proposal," and the specification itself remains a draft pending review. Ethereum's researchers have been unusually disciplined about what these results do and do not prove — a network where milliseconds already decide who captures value will scrutinize any change to how blocks propagate.
The honest read: a fivefold propagation improvement measured in simulation is a strong argument, not a decision. Hegotá's feature set is being narrowed across account abstraction, scaling and censorship-resistance work, and a late networking proposal competing for a slot will need consensus-layer developers convinced that the complexity — Merkle commitments, chunk accounting, withholding resistance — earns its place. If today's call gives it PFI status, the next milestones are devnet benchmarks and real-bandwidth tests. If it does not, EIP-8411 becomes a well-documented idea waiting for the gas limit to make it unavoidable.
