Ethereum EIP-8411 tests sub-1s payload propagation

Ethereum researchers have reported sub-one-second median propagation for a simulated 1 MiB execution payload using EIP-8411’s segmented broadcasting design, compared with roughly five seconds when sending the payload as one message.

Ethereum Research published the latest test results on Sept. 17, detailing a prototype that breaks execution payloads into smaller pieces so nodes can verify and forward each segment before receiving the full payload. The findings come from simulations and prototype client code, not Ethereum mainnet measurements.

The proposal remains a Draft networking EIP in the Ethereum EIPs repository. Its current design replaces the single execution_payload gossip topic introduced through EIP-7732 with an execution_payload_chunks topic and commits the pieces through a Merkle root included in the builder’s execution bid.

Ethereum EIP-8411 removes whole-payload waiting

Ethereum’s existing gossip model can require a node to receive and validate a large message before forwarding it to peers. Researchers behind EIP-8411 describe the resulting delay as a store-and-forward problem because the complete payload must cross one network hop before beginning the next.

With segmented propagation, a builder divides the payload into fixed pieces. Each segment carries a Merkle inclusion proof tied to the root committed in the execution bid. A receiving node can check one segment and begin sending it onward while the remaining pieces are still arriving.

Moreso,the EIP discussion on Ethereum Magicians describes the planned change as replacing EIP-7732’s single payload message with independently verifiable chunks. The draft currently proposes 64 chunks and a Merkle proof structure that binds every piece to the original payload commitment. Researchers said the Merkle commitment represents the main consensus-level addition required for basic segmentation. The latest research prototype keeps the existing gossipsub wire format, network mesh construction, peer degree and scoring system intact while changing how payload pieces are published and forwarded.

Ethereum’s documentation currently describes execution payloads as transaction and state-related data generated by the execution client and carried through the consensus process. Validators receive proposed blocks through the consensus gossip network before sending execution data to their execution clients for validation.

Simulation cuts 1 MiB median from five seconds

The strongest performance figures in the Sept. 17 report come from a controlled simulation. Researchers modeled 500 nodes using geographic network latency, 50 Mbps upload capacity and 100 Mbps download capacity, with a 1 MiB payload originating from a home builder and no high-bandwidth data-center nodes.

Under that setup, sending the payload as one complete gossipsub message took approximately five seconds to reach half the receiving nodes and close to six seconds at the tail. A tuned segmented version reached a median near 0.75 seconds and a tail close to one second.

The researchers stress that the measurements come from a simulation harness running real Prysm and go-libp2p-pubsub code against a simulated network and virtual clock. Each measurement used ten randomized network configurations. Mainnet conditions could differ from the modeled topology, bandwidth and traffic assumptions.

Their basic Tier 1 design combines segmentation with batch publishing. Using 16 KiB segments, the report says median propagation for a 1 MiB payload fell from five seconds to under one second, while tail latency dropped from roughly six seconds to just over one second.

Batch publishing changes how the source sends pieces. Instead of sending every copy of one segment before beginning the next, the builder distributes different pieces to different peers early, allowing several sections of the payload to start moving through the network at once. Researchers said Tier 1 required roughly one-third more received bytes than today’s whole-message approach. The tradeoff comes from sending many independently identified pieces and the extra control messages required to announce them.

More advanced tiers cut duplicate network traffic

A second proposed tier tackles duplicate data. Instead of pushing every segment to all eligible mesh peers, nodes can push pieces to a limited group while announcing availability to others. Peers request missing segments only when required.

The prototype combines that system with what its authors call disciplined pulls. A node initially requests a segment from one peer, waits for a defined timeout and moves to another source if the first peer fails to deliver.

At a 1 MiB payload size, the research says disciplined pulls reduced received traffic to around 1.5 payload copies per node, compared with considerably more duplicate traffic in less controlled variants. Researchers found that reducing duplicates became increasingly useful when available upload bandwidth was limited.

The approach creates another tradeoff. A malicious or overloaded peer could announce a segment and then refuse to provide it. Researchers tested a withholding scenario in which some nodes advertised segments but failed to answer requests. At higher withholding levels, the tuned pull-based design showed rising tail latency. The authors tested shorter timeouts and multiple possible request sources as methods for limiting that exposure.

Their third tier adds Reed-Solomon erasure coding. A payload is compressed, encoded with extra parity pieces and divided into segments. Nodes can reconstruct the payload after collecting enough pieces without waiting for every original segment.

Researchers said the coded model had the lowest tail latency in their tests and remained functional when some segments were withheld. The cost was higher bandwidth at the publishing source because the parity data increases the amount sent.

EIP-8411 now faces a Hegotá inclusion discussion

EIP-8411 is not currently an activated Ethereum feature. The GitHub proposal was opened on Sept. 4 and remains labeled as a Draft networking EIP awaiting review. The proposal requires EIP-7732, Ethereum’s enshrined proposer-builder separation design.

Ethereum developers have requested that EIP-8411 receive PFI, or Proposed for Inclusion, status for Hegotá, the network upgrade expected after Glamsterdam. During the Sept. 10 All Core Developers Execution discussion, developers said the proposal should be considered by the consensus-layer developer call because the change primarily affects consensus networking.

The request came after the normal Hegotá PFI deadline. Its proponents proposed EIP-8411 as a replacement for EIP-8142, which had explored placing blocks into blobs but raised concerns over builder-side KZG proving and reuse of data-availability subnets.

The ACDC #187 agenda schedules an EIP-8411 PFI discussion for Sept. 17 at 14:00 UTC. At the time of this report, the call had not yet taken place, so no decision to include EIP-8411 in Hegotá had been recorded.

Developers have been narrowing Hegotá’s feature set across account abstraction, scaling, censorship resistance and other protocol work. EIP-8411 entered that process later than many proposals and still needs a core-developer inclusion decision.

The networking proposal is tied to Ethereum’s work on raising Layer 1 capacity. Larger gas limits can lead to larger execution payloads, increasing the amount of data validators must receive within fixed consensus deadlines. Ethereum’s gas limit reached 60 million in late 2025 after validators signaled support for the increase.

Vitalik Buterin has described higher Layer 1 capacity, PeerDAS and future ZK-EVM work as parts of Ethereum’s scaling plan. Faster payload delivery is being researched alongside those changes because larger network messages place more pressure on node bandwidth and propagation deadlines.

Prototype code is available but remains experimental

The researchers have published prototype implementations for Prysm and go-libp2p-pubsub. The recommended variant-a Prysm branch contains a series of changes behind an –enable-segmented-payload-gossip flag, while the accompanying libp2p branch implements forwarding and request policies used in the study.

The authors explicitly describe their research branch as “a harness, not a proposal.” Some features measured in the paper, including advanced erasure-coding configurations, remain experimental components of the test environment and are not necessarily part of the minimum EIP-8411 specification.

Open questions identified by the researchers include increased control-message traffic, CPU costs from processing many smaller messages, alternative segment mappings, queue management, timer tuning and whether a newer QUIC-focused networking stack could produce different results.

The authors plan further comparisons between the single-topic design used by variant A, partial-message approaches and models that assign separate gossip topics to individual segments. The current prototype keeps 16 KiB pieces as its recommended baseline after simulations showed smaller 8 KiB pieces did not produce further latency gains while increasing control traffic.