Ethereum researchers have presented simulation results where the median propagation time for executing a payload of 1 MiB through EIP-8411 dropped below one second – compared to approximately five seconds when sent as a single message. Ethereum Research reported this on September 17.
The current propagation model requires a node to receive and verify a large message in its entirety before forwarding it. Researchers describe this delay as a 'store and forward' problem: the full payload must pass one network hop before the next begins. EIP-8411 proposes dividing it into fixed segments. Each carries a Merkle proof tied to a root fixed in the builder's proposal. Upon receiving one segment, a node can verify it and begin forwarding while the rest are still in transit. The proposal currently describes 64 segments.
The simulation involved 500 nodes with geographic latency, 50 Mbps upload, and 100 Mbps download. A 1 MiB payload was sent from a home builder – without high-speed data centers. Sending as a single message took about five seconds to reach half the nodes and nearly six seconds for the tail. The configured segmented version showed a median of about 0.75 seconds and a tail of about one second. Measurements were conducted on a simulator with real Prysm and go-libp2p-pubsub code and virtual clocks; each configuration was tested on ten random networks.
Base level 1 combines segmentation with batch publishing: the builder early distributes different segments to different neighboring nodes, and several parts of the payload begin moving through the network simultaneously. This increases the volume of bytes received by about a third – a cost for multiple identifiers and service messages.
Level 2 tackles duplication: instead of sending each segment to all neighbors, a node sends it to a limited group and informs others of its availability. The prototype adds retry requests – a node first requests a segment from one neighbor, waits for a timeout, and switches to another. For 1 MiB, this reduced traffic to about 1.5 copies of the payload per node. However, if a neighbor announces a segment and does not deliver it, the tail latency increases. Level 3 adds Reed-Solomon coding: the payload is encoded with redundant parts, and a node can recover the data without waiting for all segments. This resulted in the lowest tail latency and resilience to non-delivery but increased the load on the source.
EIP-8411 is not yet activated. The proposal was opened on September 4 and remains a draft in the EIPs repository. The proposal requires EIP-7732 and replaces its single execution data propagation topic with segmented topics. Developers requested a 'proposed for inclusion' status for the Hegotá update – an update expected after Glamsterdam. The request was made after the usual deadline. At the ACDC call #187, scheduled for September 17 at 14:00 UTC, the discussion had not yet taken place, and the decision to include it in Hegotá was not recorded. EIP-8411 is also proposed as a replacement for EIP-8142, which considered placing blocks in large binary objects but raised questions about KZG proofs on the builder's side.
Related articles
