Ethereum EIP-8411: Ausführungslast breitet sich in unter einer Sekunde aus

Ethereum-Forscher haben berichtet, dass für eine simulierte 1-MiB-Execution-Payload unter Verwendung des segmentierten Broadcast-Designs von EIP-8411 eine mediane Verbreitung von unter einer Sekunde erreicht wurde, verglichen mit etwa fünf Sekunden, wenn die Payload als eine einzige Nachricht gesendet wird.

Ethereum Research veröffentlichte die neuesten Testergebnisse am 17. September und beschrieb einen Prototyp, der Execution-Payloads in kleinere Teile zerlegt, damit Knoten jedes Segment verifizieren und weiterleiten können, bevor sie die vollständige Payload erhalten. Die Ergebnisse stammen aus Simulationen und Prototyp-Client-Code, nicht aus Messungen im Ethereum-Mainnet.

Der Vorschlag ist weiterhin ein Draft-Networking-EIP im Ethereum-EIPs-Repository. Sein aktuelles Design ersetzt das einzelne execution_payload-Gossip-Topic, das durch EIP-7732 eingeführt wurde, durch ein execution_payload_chunks-Topic und bindet die Teile über einen Merkle-Root, der im Execution-Bid des Builders enthalten ist.

Ethereum EIP-8411 beseitigt das Warten auf die gesamte Payload

Ethereums bestehendes Gossip-Modell kann erfordern, dass ein Knoten eine große Nachricht empfängt und validiert, bevor er sie an Peers weiterleitet. Die Forscher hinter EIP-8411 beschreiben die daraus resultierende Verzögerung als Store-and-Forward-Problem, da die vollständige Payload einen Netzwerk-Hop überqueren muss, bevor der nächste beginnen kann.

Bei der segmentierten Verbreitung teilt ein Builder die Payload in feste Teile auf. Jedes Segment trägt einen Merkle-Inklusionsbeweis, der an den im Execution-Bid festgeschriebenen Root gebunden ist. Ein empfangender Knoten kann ein Segment prüfen und mit dem Weitersenden beginnen, während die übrigen Teile noch eintreffen.

Darüber hinaus beschreibt die EIP-Diskussion auf Ethereum Magicians die geplante Änderung als Ersatz für die einzelne Payload-Nachricht von EIP-7732 durch unabhängig verifizierbare Chunks. Der Entwurf schlägt derzeit 64 Chunks und eine Merkle-Proof-Struktur vor, die jedes Teil an die ursprüngliche Payload-Commitment bindet. Die Forscher sagten, dass die Merkle-Commitment die wichtigste Ergänzung auf Konsensebene darstellt, die für die grundlegende Segmentierung erforderlich ist. Der neueste Forschungsprototyp behält das bestehende gossipsub-Wire-Format, den Aufbau des Netzwerk-Meshs, den Peer-Grad und das Scoring-System bei, ändert jedoch die Art und Weise, wie Payload-Teile veröffentlicht und weitergeleitet werden.

Ethereums Dokumentation beschreibt Execution-Payloads derzeit als transaktions- und zustandsbezogene Daten, die vom Execution-Client erzeugt und durch den Konsensprozess transportiert werden. Validatoren erhalten vorgeschlagene Blöcke über das Konsens-Gossip-Netzwerk, bevor sie Execution-Daten zur Validierung an ihre Execution-Clients senden.

Simulation reduziert 1-MiB-Median von fünf Sekunden

Die stärksten Leistungszahlen im Bericht vom 17. September stammen aus einer kontrollierten Simulation. Die Forscher modellierten 500 Knoten unter Verwendung geografischer Netzwerklatenz, 50 Mbit/s Upload-Kapazität und 100 Mbit/s Download-Kapazität, wobei eine 1-MiB-Payload von einem Home-Builder ausging und keine Hochbandbreiten-Rechenzentrumsknoten vorhanden waren.

Unter diesem Aufbau dauerte das Senden der Payload als eine vollständige gossipsub-Nachricht etwa fünf Sekunden, um die Hälfte der empfangenden Knoten zu erreichen, und knapp sechs Sekunden am Tail. Eine optimierte segmentierte Version erreichte einen Median von etwa 0,75 Sekunden und einen Tail von etwa einer Sekunde.

Die Forscher betonen, dass die Messungen aus einer Simulationsumgebung stammen, die echten Prysm- und go-libp2p-pubsub-Code gegen ein simuliertes Netzwerk und eine virtuelle Uhr ausführt. Jede Messung verwendete zehn randomisierte Netzwerkkonfigurationen. Mainnet-Bedingungen könnten von den modellierten Annahmen zu Topologie, Bandbreite und Verkehr abweichen.

Ihr grundlegendes Tier-1-Design kombiniert Segmentierung mit Batch-Publishing. Unter Verwendung von 16-KiB-Segmenten heißt es im Bericht, dass die mediane Verbreitung für eine 1-MiB-Payload von fünf Sekunden auf unter eine Sekunde fiel, während die Tail-Latenz von etwa sechs Sekunden auf knapp über eine Sekunde sank.

Die Batch-Veröffentlichung ändert die Art und Weise, wie die Quelle Teile sendet. Anstatt jede Kopie eines Segments zu senden, bevor mit dem nächsten begonnen wird, verteilt der Builder verschiedene Teile frühzeitig an verschiedene Peers, sodass mehrere Abschnitte der Nutzlast gleichzeitig durch das Netzwerk zu wandern beginnen. Forscher sagten, dass Tier 1 etwa ein Drittel mehr empfangene Bytes benötigte als der heutige Ganznachrichten-Ansatz. Der Kompromiss entsteht durch das Senden vieler unabhängig identifizierter Teile und der zusätzlichen Steuernachrichten, die zu deren Ankündigung erforderlich sind.

Fortgeschrittenere Stufen reduzieren doppelten Netzwerkverkehr

Eine zweite vorgeschlagene Stufe befasst sich mit doppelten Daten. Anstatt jedes Segment an alle geeigneten Mesh-Peers zu pushen, können Knoten Teile an eine begrenzte Gruppe pushen, während sie anderen die Verfügbarkeit ankündigen. Peers fordern fehlende Segmente nur bei Bedarf an.

Der Prototyp kombiniert dieses System mit dem, was seine Autoren als disziplinierte Pulls bezeichnen. Ein Knoten fordert zunächst ein Segment von einem Peer an, wartet auf ein definiertes Timeout und wechselt zu einer anderen Quelle, wenn der erste Peer nicht liefert.

Bei einer Nutzlastgröße von 1 MiB reduzierte disziplinierte Pulls laut der Forschung den empfangenen Verkehr auf etwa 1,5 Nutzlastkopien pro Knoten, verglichen mit deutlich mehr doppeltem Verkehr in weniger kontrollierten Varianten. Forscher fanden heraus, dass die Reduzierung von Duplikaten zunehmend nützlich wurde, wenn die verfügbare Upload-Bandbreite begrenzt war.

Der Ansatz schafft einen weiteren Kompromiss. Ein bösartiger oder überlasteter Peer könnte ein Segment ankündigen und dann die Bereitstellung verweigern. Forscher testeten ein Zurückhaltungsszenario, in dem einige Knoten Segmente bewarben, aber Anfragen nicht beantworteten. Bei höheren Zurückhaltungsstufen zeigte das abgestimmte pull-basierte Design eine steigende Tail-Latenz. Die Autoren testeten kürzere Timeouts und mehrere mögliche Anforderungsquellen als Methoden zur Begrenzung dieser Exposition.

Ihre dritte Stufe fügt Reed-Solomon-Erasure-Coding hinzu. Eine Nutzlast wird komprimiert, mit zusätzlichen Paritätsteilen kodiert und in Segmente unterteilt. Knoten können die Nutzlast rekonstruieren, nachdem sie genügend Teile gesammelt haben, ohne auf jedes ursprüngliche Segment warten zu müssen.

Forscher sagten, dass das kodierte Modell in ihren Tests die niedrigste Tail-Latenz aufwies und funktionsfähig blieb, wenn einige Segmente zurückgehalten wurden. Der Preis war eine höhere Bandbreite an der Veröffentlichungsquelle, da die Paritätsdaten die gesendete Menge erhöhen.

EIP-8411 steht nun vor einer Hegotá-Aufnahmediskussion

EIP-8411 ist derzeit keine aktivierte Ethereum-Funktion. Der GitHub-Vorschlag wurde am 4. September eröffnet und bleibt als Draft-Networking-EIP gekennzeichnet, der auf Überprüfung wartet. Der Vorschlag erfordert EIP-7732, Ethereums verankertes Proposer-Builder-Separation-Design.

Ethereum-Entwickler haben darum gebeten, dass EIP-8411 den PFI-Status (Proposed for Inclusion) für Hegotá erhält, das nach Glamsterdam erwartete Netzwerk-Upgrade. Während der All Core Developers Execution-Diskussion am 10. September sagten Entwickler, dass der Vorschlag vom Konsensschicht-Entwickler-Call behandelt werden sollte, da die Änderung hauptsächlich das Konsensnetzwerk betrifft.

Die Anfrage kam nach der normalen Hegotá-PFI-Frist. Die Befürworter schlugen EIP-8411 als Ersatz für EIP-8142 vor, das untersucht hatte, Blöcke in Blobs zu platzieren, aber Bedenken hinsichtlich builder-seitiger KZG-Beweise und der Wiederverwendung von Data-Availability-Subnetzen aufwarf.

Die ACDC #187-Agenda sieht eine EIP-8411-PFI-Diskussion für den 17. September um 14:00 UTC vor. Zum Zeitpunkt dieses Berichts hatte der Call noch nicht stattgefunden, sodass keine Entscheidung zur Aufnahme von EIP-8411 in Hegotá verzeichnet wurde.

Entwickler haben den Funktionsumfang von Hegotá in den Bereichen Account-Abstraktion, Skalierung, Zensurresistenz und anderer Protokollarbeit schrittweise eingegrenzt. EIP-8411 trat später als viele andere Vorschläge in diesen Prozess ein und benötigt noch eine Aufnahmeentscheidung der Kernentwickler.

Der Netzwerkvorschlag ist mit Ethereums Arbeit zur Erhöhung der Layer-1-Kapazität verbunden. Größere Gas-Limits können zu größeren Ausführungsnutzlasten führen, wodurch die Datenmenge steigt, die Validatoren innerhalb fester Konsensfristen empfangen müssen. Ethereums Gas-Limit erreichte Ende 2025 60 Millionen, nachdem Validatoren Unterstützung für die Erhöhung signalisiert hatten.

Vitalik Buterin hat höhere Layer-1-Kapazität, PeerDAS und zukünftige ZK-EVM-Arbeit als Teile von Ethereums Skalierungsplan beschrieben. Eine schnellere Nutzlastbereitstellung wird neben diesen Änderungen erforscht, da größere Netzwerknachrichten mehr Druck auf Knotenbandbreite und Propagationsfristen ausüben.

Prototyp-Code ist verfügbar, bleibt jedoch experimentell

Die Forscher haben Prototyp-Implementierungen für Prysm und go-libp2p-pubsub veröffentlicht. Der empfohlene Variante-a-Prysm-Branch enthält eine Reihe von Änderungen hinter einem –enable-segmented-payload-gossip-Flag, während der begleitende libp2p-Branch Weiterleitungs- und Anforderungsrichtlinien implementiert, die in der Studie verwendet wurden.

Die Autoren beschreiben ihren Forschungs-Branch ausdrücklich als „ein Testgerüst, keinen Vorschlag“. Einige im Paper gemessene Funktionen, darunter fortgeschrittene Erasure-Coding-Konfigurationen, bleiben experimentelle Komponenten der Testumgebung und sind nicht unbedingt Teil der minimalen EIP-8411-Spezifikation.

Zu den von den Forschern identifizierten offenen Fragen gehören erhöhter Kontrollnachrichtenverkehr, CPU-Kosten durch die Verarbeitung vieler kleinerer Nachrichten, alternative Segmentzuordnungen, Warteschlangenverwaltung, Timer-Abstimmung und ob ein neuerer QUIC-fokussierter Netzwerk-Stack andere Ergebnisse liefern könnte.

Die Autoren planen weitere Vergleiche zwischen dem von Variante A verwendeten Single-Topic-Design, Teilnachrichten-Ansätzen und Modellen, die einzelnen Segmenten separate Gossip-Topics zuweisen. Der aktuelle Prototyp behält 16-KiB-Stücke als empfohlene Basislinie bei, nachdem Simulationen zeigten, dass kleinere 8-KiB-Stücke keine weiteren Latenzgewinne brachten, während sie den Kontrollverkehr erhöhten.