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>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 target=”_blank”>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.
