Die steigenden Gaslimits von Ethereum, die bereits heute 60 Millionen Gas erreichen und langfristig auf 200 Millionen Gas zielen, vergrößern die Execution-Payloads auf ein Megabyte (MiB) und mehr. In der aktuellen Netzwerkarchitektur müssen Home-Staker diese großen Blöcke innerhalb des engen 3-Sekunden-Zeitfensters des Payload-Timeliness-Committees (PTC) propagieren. Ohne gezielte Protokolloptimierungen ist das in reinen Home-Staker-Topologien kaum möglich, was die Dezentralisierung gefährdet und Rechenzentren bevorzugt.

Problemstellung: Grenzen des unveränderten Gossipsub-Protokolls

Das klassische Store-and-Forward-Prinzip von Gossipsub wurde für kleine Nachrichten konzipiert. Bei einer 1-MiB-Payload scheitert es in reinen Home-Staker-Netzwerken: die Pünktlichkeitsrate liegt bei lediglich 1 % bis 11 %.

• Median-Fertigstellungszeit (Whole-Message, reines Home-Netzwerk): 4,89 s (Quelle S1, 2026)
• Pünktlichkeitsquote (Whole-Message, reines Home-Netzwerk): 1-11 % (Quelle S1, 2026)

Die Ursache liegt darin, dass jeder Knoten die komplette Nachricht empfangen, verifizieren und erst dann weiterleiten muss. Dadurch wird die Uplink-Bandbreite jedes einzelnen Knotens zum Flaschenhals.

EIP-7732 (ePBS / Gloas) verankert neue Zeitvorgaben

EIP-7732 formalisiert das Enshrined Proposer-Builder Separation (ePBS) und definiert klare Fristen für das Payload-Timeliness-Committee:

• PTC-Frist (PAYLOADDUEBPS): 6 s nach Slot-Halbzeit bei 12-Sekunden-Slots (Jahr 2024, Quelle S2)
• PTC-Abstimmungszeitpunkt: 9 s (drei Viertel des Slots) (Jahr 2024, Quelle S2)

Der Proposer signiert einen Beacon-Block, der das Bid-Commitment enthält; der Builder veröffentlicht die Execution-Payload separat. Das PTC bewertet, ob die Payload vor der 6-Sekunden-Marke eintrifft.

Segmentierung als Kernlösung

Durch Aufteilen der Payload in feste Segmente (z. B. 32 × 32 KiB) und Kombination mit Batch-Publishing sowie den sogenannten „Disciplined Pulls“ (libp2p PR #625) wird die Latenz drastisch reduziert.

• Median-Fertigstellungszeit (empfohlene Segmentierung, Home-Netzwerk): 0,73 s (Quelle S1, 2026)
• Payload-Empfangsvielfaches pro Node (Segmentierung): 1,4 Kopien vs. 4,4 Kopien bei Whole-Message (Quelle S1, 2026)
• Minimale residuale Uplink-Bandbreite für 3-s-Budget (1 MiB Payload): 15 Mbps (Quelle S1, 2026)

Die Segmentierung senkt die Latenz um den Faktor 2,8 – von fast 5 s auf unter 1 s – und stellt sicher, dass jede Node das Segment bereits vor der Block-Installation verifizieren kann, weil die Merkle-Proofs an das Bid-Commitment im Konsensblock geknüpft sind.

Technische Details der Segmentierung

• Segmentgröße: 32 KiB (Beispiel für 1 MiB Gesamtgröße)
• Kryptografische Vertrauenskette: Block → Bid-Commitment → Merkle-Wurzel → Segment-Proof
• Jedes Segment trägt einen Merkle-Proof (ca. 210 Byte Overhead, ~0,6 % des Segments)
• Der Bid-Commitment-Feld wird im Gloas-Konsensfork verankert; die Netzwerkregeln aktivieren im nachfolgenden Hegota-Fork.

Substrat-Optimierung in libp2p: Disciplined Pulls (PR #625)

Der Pull-Request-Mechanismus begrenzt ausstehende Anfragen pro Message-ID und verhindert Peer-Spam. Dadurch reduziert sich der Payload-Overhead erheblich.

• Reduktion des Payload-Overheads: 1,4 vs. 4,4 empfangene Kopien pro Node (Jahr 2026, Quelle S1)
• IWANT-Anfragelimit: 1 pro Message-ID pro Heartbeat (Jahr 2025, Quelle S3)
• Kein Änderungsbedarf am libp2p-Wire-Format; Anpassungen erfolgen auf Anwendungsebene.

Diese Optimierung ist kein Ethereum-spezifischer Hack, sondern eine generische Verbesserung des P2P-Networking-Layers, die bereits upstream implementiert ist.

Roadmap-Abfolge: Glamsterdam vs. Hegota

Die Ethereum-Core-Entwicklung unterscheidet zwischen Konsens- und Netzwerkschicht-Upgrades.

• Glamsterdam (Gloas) – Konsens-Fork, der das Bid-Commitment-Feld einführt.
• Hegota – Nachfolgender Fork, der die reinen Netzwerk-Validierungs- und Pipelining-Regeln aktiviert.
• Geplantes Gaslimit-Fernziel: 200 Millionen Gas pro Block (Jahr 2026, Quelle S4)
• Heutiges Gaslimit-Niveau: 60 Millionen Gas pro Block (Jahr 2026, Quelle S4)

Damit wird die zweistufige Implementierung in den offiziellen Hard-Fork-Zeitplan der Ethereum-Foundation eingebettet.

Risiken und Gegenargumente

• Abhängigkeit von Block-Installations-Latenzen: Segmente können erst nach Validierung des Konsens-Blocks kryptografisch verifiziert werden. Verzögerungen können lokale Pufferstaus verursachen, besonders unter DoS-Angriffen.
• Fehlende Redundanz gegen Source-Withholding: Variante A verwendet unkodierte Segmente. Ein bösartiger Builder, der einzelne Fragmente zurückhält, könnte die Rekonstruktion verhindern, was mittelfristig den Einsatz von Reed-Solomon-Erasure-Coding nötig machen könnte.

Häufig gestellte Fragen (FAQ)

Warum greift Data Availability Sampling (DAS / PeerDAS) hier nicht?

Data Availability Sampling setzt voraus, dass Knoten nur Teilmengen der Daten prüfen müssen. Bei Execution-Payloads benötigt jedoch jeder ausführende Validator die vollständige Transaktionsfolge, solange keine allgemeinen ZK-Execution-Proofs auf L1 existieren.

Warum kann ein Knoten ein Segment nicht unabhängig vom Block validieren?

Ein einzelnes Segment besitzt keine eigenständige Signatur oder Berechtigung. Erst der autorisierende Konsensblock bindet über das Bid-Commitment die Merkle-Wurzel an den Slot, wodurch gefälschte Fragmente zweifelsfrei erkannt und abgewiesen werden.

Welche Änderungen sind an der libp2p-Spezifikation erforderlich?

Keine Änderungen am libp2p-Wire-Format. Die Modifikationen betreffen anwendungsspezifische Ethereum-Validierungsregeln, hybride Message-IDs auf Applikationsebene sowie lokale Puffer- und Pull-Strategien in den Konsens-Clients.

Fazit

Die Kombination aus segmentierter Payload-Diffusion, einem kryptografisch verankerten Bid-Commitment und den libp2p-Optimierungen „Disciplined Pulls“ liefert eine praktikable Skalierungslösung für die anstehenden 1-MiB-Payloads. Messungen zeigen, dass die Median-Fertigstellungszeit von 4,89 s auf 0,73 s sinkt und die Bandbreitenbelastung pro Node von 4,4-fachen Kopien auf 1,4-fach reduziert wird. Damit wird das 3-Sekunden-Budget des PTC zuverlässig eingehalten, selbst in reinen Home-Staker-Umgebungen, und die Dezentralisierung bleibt erhalten. Die vorgeschlagene zweistufige Implementierung – Konsens-Änderung im Glamsterdam-Fork und Netzwerk-Regeln im Hegota-Fork – ist klar im offiziellen Hard-Fork-Plan verankert und ermöglicht eine schrittweise, risiko-arme Einführung. Während offene Fragen zu Block-Installations-Latenzen und Source-Withholding bestehen, bieten Erasure-Coding und weitere Optimierungen zukünftige Erweiterungsmöglichkeiten, ohne die Grundarchitektur zu verändern.