Optimierung der P2P-Payload-Verbreitung in Ethereum durch segmentierte Übertragung und kryptografische Bindung (EIP-7732)

5. September 2026 Kryptowährungen

Mit steigenden Gas-Limits und kürzeren Slot-Zeiten wird die bisherige Store-and-Forward-Mechanik von libp2p Gossipsub zunehmend überfordert. Ohne eine protokollseitige Segmentierung droht eine De-Facto-Zentralisierung, weil Heim-Validatoren große Payloads nicht mehr fristgerecht vor dem Payload Timeliness Committee (PTC) propagieren können. Die geplante Enshrined Proposer-Builder Separation (ePBS) im Rahmen von EIP-7732 (Gloas/Glamsterdam-Upgrade) bietet einen formalen Rahmen, um diese Probleme durch segmentierte Übertragung und kryptografische Bindung zu lösen.

Herausforderungen durch steigende Gas-Limits und kürzere Slot-Zeiten

  • Aktuelle Mainnet-Payloads erreichen bei einem Gas-Limit von 60 M etwa 200 KB (Quelle S1, 2026).
  • Der Payload-Timeliness-Commitment-Deadline (PAYLOADDUEBPS) liegt bei 5 000 Basispunkten, also 6 Sekunden nach Slot-Start (EIP-7732, 2024).
  • Das Payload-Timeliness-Committee besteht aus 512 zufällig ausgewählten Validatoren, die bei 9 Sekunden abstimmen (EIP-7732, 2024).
  • Bei den heutigen Slot-Längen von 12 Sekunden muss die gesamte Payload innerhalb der ersten Slot-Hälfte bereitgestellt werden, sonst verliert der Builder seine Belohnung.

EIP-7732 (Gloas) und das Payload Timeliness Committee (PTC)

EIP-7732 trennt den Consensus-Block vom Execution-Payload und definiert eine harte 6-Sekunden-Frist (PAYLOADDUEBPS) für die Bereitstellung. 512 Validatoren bilden das PTC und entscheiden per Bit-Flag, ob die Payload rechtzeitig eingetroffen ist. Eine Überschreitung der Frist wird im Protokoll wie ein Totalausfall behandelt, wodurch der Builder seine Belohnung einbüßt und Reorg-Risiken entstehen.

Segmentierte Payload-Verbreitung: Konzept und Vorteile

Die Kernidee ist die Aufteilung einer großen Payload in feste Segmente (z. B. 32 × 32 KiB). Kombiniert mit Batch-Publishing und disciplined pulls reduziert diese Methode die Latenz um ein Vielfaches und senkt den Daten-Overhead drastisch.

  • Durch Segmentierung sinkt die mittlere Empfangszeit von 4,9 s (ganze Payload) auf 0,73 s (segmentiert) bei einem Home-Builder ohne Datacenter-Knoten.
  • Die pro Node empfangenen Payload-Kopien fallen von 4,4-fach auf 1,4-fach, also um 68 %.
  • Die Latenzreduktion durch Duplikatvermeidung in Gossipsub-Optimierungen (PREAMBLE & IMRECEIVING) beträgt 35 % (Vac-Research, 2025).
  • Ein zusätzlicher Commitment-Feld in ExecutionPayloadBid ermöglicht stufenweise Validierung, ohne das libp2p-Protokoll zu brechen.

Kryptografische Bindung über das Commitment-Feld

Ein neues Feld im ExecutionPayloadBid enthält einen Merkle-Root, der die Segment-Sequenz kryptografisch bindet. Jeder empfangene Abschnitt trägt einen Merkle-Proof, der gegen den im Block installierten Commitment geprüft wird. Damit kann ein Validator ein Segment bereits vor dem vollständigen Empfang verifizieren und nur verifizierte Segmente weiterleiten. Die Bindung erfolgt vollständig auf Applikationsebene – libp2p bleibt unverändert.

Ergebnisse aus Simulationen und Messungen

Die Messungen basieren auf einem 500-Node-Netzwerk mit durchschnittlicher Latenz von 56 ms und Heim-Links von 50/100 Mbps. Die wichtigsten Resultate:

  • Whole-Message-Diffusion (keine Segmentierung) erreicht bei einem reinen Home-Builder eine mediane Completion-Zeit von 4,89 s und nur 5 % rechtzeitige Empfänger.
  • Mit 20 % Datacenter-Knoten sinkt die Completion-Zeit auf 2,90 s, bei 34-70 % rechtzeitigen Empfängern.
  • Segmentierte Diffusion (32 × 32 KiB) reduziert die mediane Completion-Zeit auf 0,73 s und erreicht 100 % rechtzeitige Empfänger.
  • Der Overhead pro Segment beträgt ca. 210 Byte (≈0,6 % bei 32 KiB Segmenten).
  • Durch disciplined pulls wird die empfangene Datenmenge pro Node von 4,4-fach auf 1,4-fach reduziert (68 % Reduktion).

Weitere Varianten wurden verglichen:

  • Ein geteiltes Topic pro Segment (Variant C) liefert 667 ms median, erzeugt jedoch mehr Overhead bei Fehlverhalten.
  • Erasure-Coding (Variant D) erhöht die Fehlertoleranz, kostet jedoch zusätzliche Komplexität.
  • Die einfachste Variante (ein gemeinsames Topic, Variant A) erreicht mit 0,73 s die beste Latenz-/Byte-Balance.

Risiken und Gegenmaßnahmen

  • Erhöhte CPU- und Verifizierungs-Komplexität: 32 separate Merkle-Beweise pro Payload können bei ressourcenschwachen Staking-Nodes I/O- und CPU-Spitzen verursachen.
  • Block-Arrival-Kopplung: Verzögerte Beacon-Block-Ankunft blockiert die Weiterleitung aller Segmente, weil Segmente erst nach Block-Installation verifiziert werden dürfen.

Gegenmaßnahmen umfassen das Setzen eines per-Sender-Slot-Limits für Segment-Anfragen und das Puffern von nicht-verifizierten Segmenten in einer begrenzten Queue, um Denial-of-Service-Angriffe zu begrenzen.

FAQ zur Umsetzung

Warum reicht die bisherige MEV-Boost-Architektur für 1-MiB-Payloads nicht mehr aus?MEV-Boost stützt sich auf zentrale Relays und Rechenzentrum-Builder-Pipelines. Steigt das Gas-Limit oder sinkt die Slot-Zeit, scheitern lokale Home-Builder an den Uplink-Bandbreiten von Store-and-Forward-Gossip.Erfordert die Einführung segmentierter Payloads eine Änderung am libp2p-Netzwerkprotokoll?Nein. Die Adressierung erfolgt über anwendungsspezifische hybride Message-IDs auf Applikationsebene der Ethereum-Clients. libp2p selbst bleibt unverändert.

Fazit

Die Kombination aus harter Fristsetzung durch EIP-7732, einem 512-Member-Payload-Timeliness-Committee und einer segmentierten Payload-Verbreitung mit kryptografischer Bindung liefert eine nachweislich robuste Lösung für die wachsende Belastung des Ethereum-P2P-Stacks. Empirische Messungen zeigen, dass die mediane Completion-Zeit von fast 5 s auf unter 1 s sinkt und die pro-Node-Datenmenge um mehr als die Hälfte reduziert wird. Gleichzeitig bleibt das System kompatibel zu libp2p, weil die Änderungen ausschließlich auf Applikationsebene stattfinden. Trotz erhöhter Verifizierungs-Kosten und der Notwendigkeit, Block-Ankunfts-Kopplungen zu managen, ermöglichen die vorgestellten Mechanismen eine dezentrale Payload-Verbreitung, die auch für Heim-Validatoren mit handelsüblichen Anschlüssen praktikabel ist. Damit wird das Risiko einer De-Facto-Zentralisierung durch Rechenzentren deutlich reduziert und das Ethereum-Netzwerk für die zukünftige Entwicklung von Gas-Limits und Slot-Zeiten zukunftssicher gemacht.