Ethereum-onderzoekers meldden dat een ontwerp met gesegmenteerde uitzending onder het ontwerpproposal EIP-8411 in simulatie de mediane propagatietijd van een execution payload van 1 MiB reduceerde van ongeveer vijf seconden naar circa 0,75 seconden, volgens een publicatie op Ethereum Research.

Propagatiesnelheid weegt in een proof-of-stake-netwerk extra zwaar, omdat validators een beperkt venster hebben om elk nieuw blok te ontvangen en verifiëren voordat zij erover attesteren.

De test modelleerde 500 knooppunten met geografische latentie, een uploadcapaciteit van 50 Mbps en een downloadcapaciteit van 100 Mbps. De payload werd verzonden vanaf een thuis-builder in plaats van een knooppunt in een datacentrum met hoge bandbreedte, een keuze die testte hoe het ontwerp presteert zonder datacentrum-infrastructuur aan de verzendende kant. De onderzoekers draaiden echte Prysm- en go-libp2p-pubsub-code op een gesimuleerd netwerk met een virtuele klok en herhaalden elke meting in 10 gerandomiseerde configuraties om niet van één specifieke topologie afhankelijk te zijn.

Toen de volledige payload als één GossipSub-bericht werd verzonden, bereikte die de helft van het netwerk in ongeveer vijf seconden, terwijl de langzaamste knooppunten hem pas na bijna zes seconden ontvingen. De afgestemde gesegmenteerde variant reduceerde die cijfers tot respectievelijk circa 0,75 seconden en één seconde.

EIP-8411 vervangt wachten op de volledige payload door gesegmenteerde uitzending

EIP-8411 vervangt het enkele execution_payload-gossiponderwerp uit EIP-7732 door een nieuw execution_payload_chunks-onderwerp. Knooppunten hoeven niet langer te wachten op een volledige payload voordat ze die doorsturen. In plaats daarvan kunnen zij onafhankelijk geauthenticeerde segmenten verifiëren en doorsturen zodra die binnenkomen, waarbij elk segment wordt gecontroleerd tegen een Merkle-wortel die in de execution bid van de builder is opgenomen.

Het voorstel werd op 4 september 2026 geopend en is nog steeds een niet-goedgekeurd Draft networking EIP. Het is bovendien afhankelijk van EIP-7732, Ethereums ingebedde proposer-builder-scheiding, waarbij builders execution payloads construeren en die via execution bids aan proposers aanbieden, waardoor blokbouw en blokvoorstel van elkaar worden gescheiden.

De resultaten kwamen uit een gecontroleerde simulatie met prototype-clientcode, niet uit metingen op Ethereum mainnet. Eventuele prestatiewinst in de praktijk zou daarom nog moeten worden bevestigd. De onderzoekers omschreven hun branch als "een harness, geen proposal."

De bevindingen werden ook beschreven in een 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

Snellere propagatie gaat gepaard met meer netwerkoverhead

De consensuslaag van Ethereum gebruikt GossipSub, een publish-subscribe-gossipprotocol, om blokken en andere berichten te verspreiden over het peer-to-peer-netwerk. Het huidige gossipmodel kan een store-and-forward-vertraging veroorzaken, omdat een knooppunt een volledig groot bericht moet ontvangen en valideren voordat het het doorstuurt. Het basale Tier 1-ontwerp gebruikt 16 KiB-segmenten in combinatie met batch-publicatie. In tests reduceerde het de mediane propagatietijd van 1 MiB van vijf seconden naar minder dan één seconde. De tail-latency daalde ook, van ongeveer zes seconden naar iets meer dan één seconde.

De afweging was circa een derde meer ontvangen bytes dan bij de huidige aanpak met hele berichten. Geavanceerdere varianten richten zich direct op die overhead door dubbele bytes. Bij één aanpak, disciplined pulls genaamd, vraagt een knooppunt een ontbrekend segment aan één peer. Als die peer een time-out krijgt, valt het knooppunt terug op een andere. Dit reduceerde het ontvangen verkeer tot ongeveer 1,5 payloadkopieën per knooppunt. De tail-latency nam echter toe wanneer peers segmenten inhielden die zij hadden aangekondigd.

Een derde tier voegt daarbovenop Reed-Solomon-erasure coding toe. Dit leverde in tests de laagste tail-latency op en bleef werken toen peers segmenten inhielden. De kosten waren een grotere bandbreedtevraag aan de bron.

Die afweging is relevant voor Ethereums schalingsrouteka na Glamsterdam. Hogere gaslimieten en grotere execution payloads zullen naar verwachting extra druk leggen op de bandbreedte van knooppunten. De onderzoekers identificeerden tevens open vragen rond besturingsberichtverkeer, de CPU-kosten van het verwerken van veel kleinere berichten, wachtrijbeheer, het afstellen van timers en coördinatie tussen clients.

ACDC overweegt EIP-8411 voor Hegotá

Binnen het Ethereum-ecosysteem werd ook gesproken over mogelijke opname van het voorstel in Hegotá, de netwerkupgrade die na Glamsterdam wordt verwacht. In een X-post schreef Barnabé Monnot:

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-ontwikkelaars vroegen de status Proposed for Inclusion voor EIP-8411 in Hegotá aan, na de normale Hegotá-PFI-deadline. Proposed for Inclusion, of PFI, is de status die een EIP markeert als kandidaat voor een specifieke netwerkupgrade. De ACDC #187-agenda plande een PFI-discussie op 17 september om 14:00 UTC. Ten tijde van het oorspronkelijke rapport had die oproep echter nog niet plaatsgevonden en was er geen opnamebeslissing vastgelegd.

Prototype-implementaties voor Prysm en go-libp2p-pubsub zijn al gepubliceerd. De onderzoekers waarschuwden dat geavanceerde erasure-coding-configuraties experimentele functies in een testomgeving blijven in plaats van bevestigde onderdelen van de minimale EIP-8411-specificatie. Of EIP-8411 deel wordt van Ethereums schalingsinfrastructuur, hangt af van een toekomstige beslissing van de core-ontwikkelaars.