Ethereum researchers reported that a segmented broadcasting design under draft proposal EIP-8411 reduced the simulated median propagation time for a 1 MiB execution payload from roughly five seconds to about 0.75 seconds, according to a write-up on Ethereum Research.

Propagation speed carries particular weight in a proof-of-stake network, where validators have a limited window to receive and verify each new block before attesting to it.

The test modeled 500 nodes with geographic latency, 50 Mbps upload capacity and 100 Mbps download capacity. The payload was sent from a home builder rather than a high-bandwidth data-center node, a choice that tested how the design performs without data-center infrastructure on the sending side. Researchers ran real Prysm and go-libp2p-pubsub code on a simulated network with a virtual clock, repeating each measurement across 10 randomized configurations to avoid relying on a single topology.

When the full payload was sent as one GossipSub message, it reached half of the network in about five seconds, while the slowest nodes received it in close to six seconds. The tuned segmented variant reduced those figures to roughly 0.75 seconds and one second, respectively.

EIP-8411 Replaces Whole-Payload Waiting With Segmented Broadcasts

EIP-8411 replaces the single execution_payload gossip topic from EIP-7732 with a new execution_payload_chunks topic. Nodes no longer need to wait for an entire payload before relaying it. Instead, they can verify and forward independently authenticated segments as they arrive, checking each segment against a Merkle root carried in the builder’s execution bid.

The proposal was opened on Sept. 4, 2026, and remains an unapproved Draft networking EIP. It also depends on EIP-7732, Ethereum’s enshrined proposer-builder separation design, under which builders construct execution payloads and offer them to proposers through execution bids, separating block building from block proposal.

The results came from a controlled simulation using prototype client code, not from measurements on Ethereum mainnet. Any real-world performance gains would therefore still need to be confirmed. The researchers described their branch as “a harness, not a proposal.”

The findings were also described in an X post:

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

Faster Propagation Comes With Higher Network Overhead

Ethereum’s consensus layer uses GossipSub, a publish-subscribe gossip protocol, to spread blocks and other messages across its peer-to-peer network. The current gossip model can create a store-and-forward delay because a node must receive and validate an entire large message before relaying it. The basic Tier 1 design uses 16 KiB segments together with batch publishing. In testing, it reduced the 1 MiB median propagation time from five seconds to under one second. Tail latency also declined from roughly six seconds to just over one second.

The tradeoff was approximately one-third more received bytes than with the current whole-message approach. More advanced variants target that duplicate-byte overhead directly. Under one approach, called disciplined pulls, a node requests a missing segment from one peer. If that peer times out, the node falls back to another. This reduced received traffic to around 1.5 payload copies per node. However, tail latency increased when peers withheld segments they had advertised.

A third tier adds Reed-Solomon erasure coding. It produced the lowest tail latency in testing and continued to work when peers withheld segments. The cost was greater bandwidth demand at the source.

That tradeoff is relevant to Ethereum’s post-Glamsterdam scaling roadmap. Larger gas limits and execution payloads are expected to place additional strain on node bandwidth. The researchers also identified open questions involving control-message traffic, the CPU cost of processing many smaller messages, queue management, timer tuning and coordination between clients.

ACDC Considers EIP-8411 for Hegotá

The Ethereum ecosystem also discussed the proposal’s possible inclusion in Hegotá, the network upgrade expected after Glamsterdam. In an X post, Barnabé Monnot wrote:

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 developers requested Proposed for Inclusion status for EIP-8411 in Hegotá after the normal Hegotá PFI deadline. Proposed for Inclusion, or PFI, is the status that marks an EIP as a candidate for a specific network upgrade. The ACDC #187 agenda scheduled a PFI discussion for Sept. 17 at 14:00 UTC. At the time of the primary report, however, that call had not taken place and no inclusion decision had been recorded.

Prototype implementations for Prysm and go-libp2p-pubsub have been published. The researchers cautioned that advanced erasure-coding configurations remain experimental test-environment features rather than confirmed components of the minimum EIP-8411 specification. Whether EIP-8411 becomes part of Ethereum’s scaling infrastructure depends on a future core-developer decision.