Die Segmentierung von Execution-Payloads gemäß EIP-8411 reduziert Latenzen und CPU-Last, selbst bei steigenden Gas-Limits. Durch umfangreiche Cross-Simulationen und Messungen auf dem Linux-Netzwerk-Stack wird belegt, dass die segmentierten Varianten die monolithische Vollnachrichten-Gossip-Lösung über QUIC und TCP deutlich übertreffen und das dreisekündige Zeitbudget einhalten.
Protokollkontext und Abhängigkeit von EIP-7732 (ePBS)
EIP-8411 ersetzt das in EIP-7732 eingeführte Topic executionpayload durch executionpayloadchunks. Die einzige notwendige Konsensänderung besteht im Einbetten eines Merkle-Tree-Commitments in das Builder-Bid, wodurch jedes Segment vor dem Weiterleiten kryptografisch verifiziert werden kann. Damit entfallen klassische Store-and-Forward-Mechanismen und Knoten können bereits validierte Fragmente sofort weiterleiten.
- Segmentgröße (Tier 1): 16 KiB pro Chunk (für Pipelining ohne vollständiges Store-and-Forward)
- Payload-Größe im Benchmark: 1 MiB Test-Payload bei 500 Knoten (Home-Builder-Szenario)
Benchmark-Design und eingesetzte Simulatoren
Die Studie vergleicht drei Testumgebungen:
- go-libp2p-Harness (Simnet): In-Process-Simulation mit Fair-Queueing (fq\codel, RFC 8290).
- Shadow-Simulator: Echt-Prozess-Pro-Node, verwendet FIFO-Queue-Modell.
- Linux-Kernel-Stack: Real-World-Messung auf einem 40‑Thread‑Maschine, 100 Prozesse, Traffic-Control-Shaping.
Alle Szenarien nutzen dieselbe Topologie, Link‑Raten (50 Mbps Up / 100 Mbps Down) und 10 Seeds pro Messpunkt. Varianten A‑tuned, B und C werden sowohl über QUIC als auch über TCP getestet.
Design A‑tuned – Referenzvariante
Design A‑tuned kombiniert Segmentierung mit Batch‑Publishing und gezielten Pull‑Anfragen (disciplined pulls). Es nutzt ein einziges Gossipsub‑Topic für alle Segmente, reduziert Duplikate und hält das 3‑Sekunden‑Budget ein.
Performance‑Ergebnisse: Latenz, CPU‑Last und Bandbreiteneffizienz
Die wichtigsten Messwerte (Quelle S1) zeigen klare Vorteile der segmentierten Varianten:
- Median‑Verbreitungszeit A‑tuned (Simnet): 0,75 s
- p99‑Latenz A‑tuned (Simnet): 1,00 s
- Median‑Verbreitungszeit Vollnachricht (Simnet): 4,9 s
- Median‑Verbreitungszeit Vollnachricht (Shadow QUIC): 3,2 s
- Baseline‑Latenz monolithisch (Simnet): 5,0 s (median bei 500 Home‑Nodes)
- Payload‑Overhead (Kopien pro Node): A‑tuned 1,5 vs. monolithisch 4,6
Auf dem realen Linux‑Stack verursacht die Vollnachricht eine 2‑ bis 4‑fach höhere CPU‑Last im Vergleich zu den segmentierten Varianten. Beispielhafte CPU‑Auslastungen (QUIC) zeigen:
- Vollnachricht: 35 % CPU‑Auslastung
- A‑tuned: 8 % CPU‑Auslastung
- Variante C (QUIC): 14 % CPU‑Auslastung
Die segmentierten Varianten erreichen somit nicht nur sub‑Sekunden‑Latenzen, sondern reduzieren auch die Netzwerklast und CPU‑Belastung signifikant.
Einfluss von Active Queue Management und Scheduling
Die Diskrepanz zwischen Harness (fq\codel) und Shadow (FIFO) erklärt die unterschiedliche Performance von Variante C und die Gesamtlatenz des Vollnachrichten‑Baseline. fq\codel (RFC 8290) sorgt für faire Bandbreiten‑Aufteilung und verhindert Bufferbloat, während FIFO zuerst‑ankommende‑zuerst‑verarbeitet‑Prinzip parallel laufende Segmente benachteiligt.
- RFC 8290 (fq\codel) – FlowQueue‑CoDel, 2018
- RFC 8033 (PIE) – Proportional Integral controller Enhanced AQM, 2017 (nicht gemessen, aber erwähnt)
Variante C profitiert unter FIFO, weil mehrere 32 KiB‑Segmente gleichzeitig in die Uplink‑Queue gelangen. Unter fq\codel werden alle Flows gleichmäßig verlangsamt, was C im Vergleich zu A‑tuned langsamer macht.
Risiken, Gegenargumente und offene Forschungsfragen
Obwohl die Ergebnisse überzeugend sind, identifizieren die Autoren mehrere kritische Punkte:
- Abhängigkeit von EIP‑7732: Der Rollout von EIP‑8411 erfordert die formale Verankerung des Builder‑Bids im Konsens. Verzögerungen bei EIP‑7732 könnten EIP‑8411 blockieren.
- Skalierungsgrenzen des Linux‑Namespace‑Tests: Tests wurden auf 100 Knoten und einer einzelnen 40‑Thread‑Maschine durchgeführt. Die CPU‑Kosten bei echter Mainnet‑Last bleiben ungeprüft.
- Validierungs‑Overhead von Merkle‑Beweisen: Jeder Chunk muss kryptografisch verifiziert werden. Bei DoS‑Angriffen mit ungültigen Chunks könnte dies Knoten asymmetrisch belasten.
Weitere offene Fragen betreffen die Bandbreiten‑Modellierung, das Verhalten unter Cross‑Traffic, Peer‑Churn und die Integration von Reed‑Solomon‑Kodierung (RS) für Fehlertoleranz.
Häufig gestellte Fragen (FAQ)
Was ist der Unterschied zwischen Variante A, B und C in EIP‑8411?Variante A überträgt alle Segmente über ein einzeltes Gossipsub‑Topic, B nutzt eine Partial‑Message‑Erweiterung für Chunks, und C betreibt separate Topics pro Segment.Warum reagiert Variante C empfindlicher auf die Queue‑Disziplin (FIFO vs. fq\codel)?Variante C legt parallel mehrere Segmente in die Uplink‑Queue. Bei fq\codel werden alle Flows fair geteilt, während FIFO den ersten Chunk bevorzugt, was C schneller macht.Welche Konsensänderung verlangt EIP‑8411?Nur die Aufnahme einer Merkle‑Wurzel für die Payload‑Chunks in das verbindliche Builder‑Bid, damit Zwischenknoten Chunks vor dem vollständigen Download kryptografisch verifizieren können.
Fazit
Robuste Simulationen mit dem go‑libp2p‑Harness, dem Shadow‑Simulator und Messungen auf dem realen Linux‑Netzwerk‑Stack belegen, dass die segmentierte Payload-Verbreitung nach EIP‑8411 die Latenz von rund fünf Sekunden auf unter eine Sekunde reduziert, den Payload‑Overhead von 4,6 auf 1,5 Kopien pro Node senkt und die CPU‑Last um das Zwei‑ bis Vierfache verringert. Die Ergebnisse bleiben konsistent, solange das zugrunde liegende Builder‑Bid gemäß EIP‑7732 verankert ist und die Queue‑Disziplinen (fq\codel vs. FIFO) berücksichtigt werden. Offene Fragen zu Skalierbarkeit, DoS‑Resistenz und Bandbreiten‑Modellierung sollten in zukünftigen Testreihen adressiert werden, doch die aktuelle Evidenz macht A‑tuned zum stärksten Referenzdesign für die geplante Hard‑Fork‑Integration Hegotá.