Ethereum-Forscher berichteten, dass ein segmentiertes Broadcasting-Design im Rahmen des Entwurfs EIP-8411 die simulierte mediane Verbreitungszeit einer 1-MiB-Execution-Payload von rund fünf Sekunden auf etwa 0,75 Sekunden reduzierte, wie aus einem Bericht auf Ethereum Research hervorgeht.

Die Verbreitungsgeschwindigkeit ist in einem Proof-of-Stake-Netzwerk von besonderer Bedeutung, da Validierer nur ein begrenztes Zeitfenster haben, um jeden neuen Block zu empfangen und zu verifizieren, bevor sie ihn bestätigen.

Der Test modellierte 500 Knoten mit geografischer Latenz, 50 Mbit/s Upload- und 100 Mbit/s Download-Kapazität. Die Payload wurde von einem Heim-Anbieter statt von einem Hochbandbreiten-Rechenzentrumsknoten gesendet – eine Entscheidung, die测试 prüfte, wie sich das Design ohne Rechenzentrumsinfrastruktur auf der Senderseite verhält. Die Forscher führten echten Prysm- und go-libp2p-pubsub-Code auf einem simulierten Netzwerk mit virtueller Uhr aus und wiederholten jede Messung über 10 randomisierte Konfigurationen, um sich nicht auf eine einzige Topologie zu stützen.

Wurde die vollständige Payload als eine einzige GossipSub-Nachricht gesendet, erreichte sie die Hälfte des Netzwerks in etwa fünf Sekunden, während die langsamsten Knoten sie erst nach fast sechs Sekunden erhielten. Die optimierte segmentierte Variante reduzierte diese Werte auf etwa 0,75 Sekunden bzw. eine Sekunde.

EIP-8411 ersetzt das Warten auf die gesamte Payload durch segmentierte Übertragungen

EIP-8411 ersetzt das einzelne execution_payload-Gossip-Topic aus EIP-7732 durch ein neues execution_payload_chunks-Topic. Knoten müssen nicht mehr auf die vollständige Payload warten, bevor sie sie weiterleiten. Stattdessen können sie unabhängig authentifizierte Segmente verifizieren und weiterleiten, sobald sie eintreffen, und jedes Segment anhand einer Merkleurzel prüfen, die im Execution-Bid des Builders enthalten ist.

Der Vorschlag wurde am 4. September 2026 eingereicht und ist weiterhin ein ungenehmigter Netzwerk-EIP-Entwurf. Er hängt zudem von EIP-7732 ab, Ethreums enshrined Proposer-Builder-Separation-Design, bei dem Builder Execution-Payloads erstellen und sie Proposern über Execution-Bids anbieten, wodurch Blockerstellung und Blockvorschlag getrennt werden.

Die Ergebnisse stammen aus einer kontrollierten Simulation mit Prototyp-Client-Code und nicht aus Messungen auf dem Ethereum-Mainnet. Etwaige Vorteile in der Praxis müssten daher noch bestätigt werden. Die Forscher bezeichneten ihren Zweig als „ein Testgeschirr, kein Vorschlag“.

Die Ergebnisse wurden auch in einem X-Post beschrieben:

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

Schnellere Verbreitung geht mit höherem Netzwerk-Overhead einher

Ethreums Consensus-Layer nutzt GossipSub, ein Publish-Subscribe-Gossip-Protokoll, um Blöcke und andere Nachrichten über sein Peer-to-Peer-Netzwerk zu verteilen. Das aktuelle Gossip-Modell kann eine Store-and-Forward-Verzögerung verursachen, da ein Knoten eine gesamte große Nachricht empfangen und validieren muss, bevor er sie weiterleitet. Das grundlegende Tier-1-Design verwendet 16-KiB-Segmente zusammen mit Batch-Veröffentlichung. Im Test reduzierte es die mediane Verbreitungszeit von 1 MiB von fünf Sekunden auf unter eine Sekunde. Die Tail-Latenz sank ebenfalls von rund sechs auf etwas über eine Sekunde.

Der Kompromiss bestand in etwa einem Drittel mehr empfangenen Bytes gegenüber dem aktuellen Whole-Message-Ansatz. Fortgeschrittenere Varianten zielen direkt auf diesen Duplikat-Byte-Overhead ab. Bei einem Ansatz, den sogenannten disciplined pulls, fordert ein Knoten ein fehlendes Segment von einem Peer an. Überschreitet dieser Peer das Zeitlimit, weicht der Knoten auf einen anderen aus. Dies reduzierte den empfangenen Traffic auf rund 1,5 Payload-Kopien pro Knoten. Die Tail-Latenz stieg jedoch, wenn Peers angekündigte Segmente zurückhielten.

Eine dritte Stufe ergänzt Reed-Solomon-Erasure-Coding. Sie erzielte im Test die niedrigste Tail-Latenz und funktionierte auch bei zurückgehaltenen Segmenten weiter. Preis ist ein höherer Bandbreitenbedarf an der Quelle.

Dieser Kompromiss ist für Ethreums Skalierungs-Roadmap nach Glamsterdam relevant. Höhere Gas-Limits und Execution-Payloads werden die Knoten-Bandbreite voraussichtlich zusätzlich belasten. Die Forscher identifizierten zudem offene Fragen im Zusammenhang mit Control-Message-Traffic, den CPU-Kosten der Verarbeitung vieler kleinerer Nachrichten, Queue-Management, Timer-Tuning und der Koordination zwischen Clients.

ACDC berät über EIP-8411 für Hegotá

Im Ethereum-Ökosystem wurde auch die mögliche Aufnahme des Vorschlags in Hegotá erörtert, das nach Glamsterdam erwartete Netzwerk-Upgrade. In einem X-Post schrieb 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-Entwickler beantragten den Proposed-for-Inclusion-Status für EIP-8411 in Hegotá nach der regulären Hegotá-PFI-Frist. Proposed for Inclusion (PFI) ist der Status, der einen EIP als Kandidaten für ein bestimmtes Netzwerk-Upgrade ausweist. Die ACDC-#187-Agenda sah eine PFI-Diskussion für den 17. September um 14:00 UTC vor. Zum Zeitpunkt des primären Berichts hatte dieser Call jedoch noch nicht stattgefunden, und es lag keine Entscheidung über die Aufnahme vor.

Prototyp-Implementierungen für Prysm und go-libp2p-pubsub sind bereits veröffentlicht. Die Forscher wiesen jedoch darauf hin, dass fortgeschrittene Erasure-Coding-Konfigurationen weiterhin experimentelle Testumgebungs-Features sind und keine bestätigten Bestandteile der Mindestspezifikation von EIP-8411. Ob EIP-8411 Teil von Ethreums Skalierungsinfrastruktur wird, hängt von einer künftigen Entscheidung der Core-Entwickler ab.