Ethereum researchers have proposed a new approach to speed up the transmission of large execution payloads across the network.
The proposal, called EIP-8411, titled Fast Execution Payload Broadcast, uses segmented payload diffusion, which breaks a payload into smaller pieces that can move through the network at the same time.
According to the research, this could significantly reduce the time needed to distribute large payloads. In the researchers’ baseline simulation, a 1 MiB payload reached half of the network in about five seconds using the current approach. With segmentation and batch publishing, median propagation dropped to about 0.73 seconds in the researchers’ least-favorable setting, or about 0.75 seconds in related prototype reporting, while the slower end was close to one second.
The results come from simulations and prototype client code rather than Ethereum mainnet measurements.
The main benefit comes from removing what researchers call the “store-and-forward delay.” Under the current approach, a node generally needs to receive and validate the complete payload before forwarding it. With EIP-8411, nodes can verify and forward individual segments while the remaining pieces are still arriving.
How EIP-8411 works
Ethereum currently sends an execution payload as a single large message. EIP-8411 would divide the payload into smaller segments.
Each segment would include a proof that links it to a Merkle root included in the builder’s bid. This allows a receiving node to verify an individual segment before forwarding it to other peers.
As different segments move through the network simultaneously, the process creates a form of pipelining.
The draft proposes replacing the single execution_payload gossip topic introduced through EIP-7732 with an execution_payload_chunks topic. The current design uses 64 chunks, with the Merkle structure linking each segment to the original payload commitment.
Researchers said the Merkle commitment is the main consensus-level change required for basic segmentation. The prototype otherwise keeps much of the existing Gossipsub network structure, including its wire format, mesh and peer-management system.
Tests show faster propagation
The main test used 500 simulated nodes with 50 Mbps upload and 100 Mbps download speeds. A 1 MiB payload was sent from a home builder without using high-bandwidth data-center nodes.
With the current approach, the payload took about five seconds to reach half of the network and nearly six seconds at the slower end. With segmentation and batch publishing, median propagation dropped to about 0.75 seconds, while the slower end was close to one second.
The tests used real Prysm and go-libp2p-pubsub code in a simulated network. Researchers noted that actual Ethereum mainnet results could differ.
The researchers found that 16 KiB segments provided a good balance between speed and network traffic. Smaller 8 KiB segments increased control traffic without improving propagation time.
Three proposed tiers
The research outlines three implementation tiers, with each adding another layer to improve Ethereum’s payload propagation:
- Tier 1: Splits the payload into smaller segments and sends them to multiple peers at the same time. In the 1 MiB test, this reduced median delivery time from about five seconds to under one second.
- Tier 2: Adds a push-and-pull system. Nodes share segments with some peers and announce them to others, which can request missing segments. This helps reduce duplicate network traffic.
- Tier 3: Adds erasure coding, which creates extra segments that can help rebuild the payload if some original segments are missing or delayed. This can reduce delays caused by slow parts of the network.
The researchers described Tier 3 as the option focused on the network “tail,” where the last few segments can determine how long it takes a node to complete the payload.
Erasure coding reduces delays
The erasure-coding design uses a rate-½ Reed-Solomon code in the study. Researchers recommend compressing the payload before applying the coding so that the resulting segments remain more evenly sized.
Instead of waiting for one specific missing segment, a node can reconstruct the payload after receiving enough pieces.
The researchers found that this approach performed well in simulated withholding conditions, where some nodes advertised or received segments but failed to provide them when requested.
However, erasure coding also increases bandwidth use because additional parity data has to be transmitted. This makes it a trade-off between stronger protection against slow segments and higher network traffic.
Ethereum scaling and EIP-8411 Review
Researchers also tested networks ranging from 250 to 4,000 nodes and found that segmentation continued to provide an advantage as the simulated network grew.
They said faster payload propagation could reduce Ethereum’s reliance on high-bandwidth nodes and potentially help support shorter slot times. The approach could also provide more network capacity for larger objects, including post-quantum signatures, larger consensus blocks, and zero-knowledge proofs.
This could become more relevant as Ethereum works to increase Layer 1 capacity. Larger gas limits can result in larger execution payloads, increasing the amount of data validators need to receive within fixed consensus deadlines.
EIP-8411 is currently a Draft networking EIP and is not an activated Ethereum feature. The proposal was opened on September 4 and created as a draft on September 5. It depends on EIP-7732.
Developers have requested Proposed for Inclusion status for Hegotá, the network upgrade expected after Glamsterdam. The ACDC #187 agenda scheduled an EIP-8411 discussion for September 17 at 14:00 UTC.
At the time of the research report, no final decision had been recorded on whether EIP-8411 would be included in Hegotá.
Overall, the research suggests that independently verifiable payload segments could reduce propagation delays in the tested network model. However, the findings are based on simulations and prototype testing, while EIP-8411 remains under developer review and has not been approved for Ethereum mainnet.
Also Read: Ethereum Deploys Multi-Party Block Construction on Mainnet
