Das neuartige Protokoll SEACAST (Segmented, Encoded, Availability-sampled broadCAST) wurde entwickelt, um im Ethereum-Netzwerk große Datenobjekte schnell und bandbreiteneffizient zu verteilen. Durch die Kombination von Erasure Coding, Cut-Through-Chunk-Forwarding und selektivem Sampling reduziert SEACAST sowohl Latenz als auch Bandbreiten-Overhead. Das ist besonders wichtig, da Block- und Blob-Größen wachsen und die Slot-Deadlines immer kürzer werden – das etablierte Store-and-Forward-Verfahren Gossipsub kann dadurch Home-Validatoren (Home Staker) nicht mehr zuverlässig bedienen.

Leistungsbenchmark: SEACAST vs. Gossipsub

Die wichtigsten Messwerte stammen aus Simulationen mit 500 rein heimischen Nodes (Up-link 50 Mbps, Down-link 100 Mbps) und einer Payload-Größe von 1 MiB. Alle Ergebnisse beziehen sich auf das Erreichen von 99 % der Nodes.

• Verbreitungszeit SEACAST: 0,64 s
• Verbreitungszeit Gossipsub: 4,5 – 6,3 s
• Empfangenes Gesamtvolumen pro Node (SEACAST): 1,3 MiB
• Empfangenes Gesamtvolumen pro Node (Gossipsub): 4,2 MiB
• Sendefenstergröße (Uplink-Pacing): 130 ms

Zusätzlich zeigte SEACAST bei reduzierter Up-link-Bandbreite (10 Mbps) eine Verbreitungszeit von 1,8 s – etwa das Dreifache der Zeit bei 50 Mbps, jedoch immer noch deutlich schneller als Gossipsub, das bei gleichen Bedingungen 22-37-mal über dem theoretischen Untergrenzenwert liegt.

Integration von SEACAST in die Ethereum-Roadmap (EIP-8411 & EIP-7732)

SEACAST operationalisiert die Segmentierung, die in EIP-8411 (Fast Execution Payload Broadcast) definiert ist. Im Zusammenspiel mit dem kommenden Proposer-Builder-Separation-Standard EIP-7732 adressiert SEACAST das kritische Zeitfenster, in dem Home-Builder und Validatoren Payload-Envelopes verifizieren müssen, bevor die Attestation-Deadlines verstrichen.

• Verbreitungszeit-Budget für Execution Payloads (EIP-8411): 50 % Reduktion des Datenvolumens gegenüber reinem Push-Gossip (Jahr 2026).
• SEACAST liefert einen bandbreitenadaptiven Transport-Algorithmus, der exakt an die in EIP-8411 spezifizierten Merkle-Root-Commitments gekoppelt ist.

Damit wird die Sub-Sekunden-Auslieferung großer Payloads – selbst bei dezentralen Heim-Validatoren – ermöglicht, sodass Attestation-Fristen eingehalten und eine Zentralisierung zugunsten von Hochleistungs-Rechenzentren verhindert werden kann.

Synergie mit Data Availability Sampling (PeerDAS & RowDAS)

Bestehende DAS-Architekturen wie PeerDAS (EIP-7594) benötigen bei steigender Blob-Zahl hohe Redundanz und komplexe Subnet-Topologien. SEACAST trennt das Interesse (Interest) von der Weiterleitungspflicht (Duty) und integriert dadurch PeerDAS-Spalten und RowDAS-Zeilen ohne separate Subnet-Subscriptions pro Dateneinheit.

• CPU-Entlastung bei Blob-Rekonstruktion durch RowDAS: bis zu 128-fach Reduktion (von ca. 5-20 s auf 40-162 ms pro Slot bei 32-128 Blobs, Jahr 2026).
• Standardmäßige Spalten-Custody pro PeerDAS-Node: 8 von 128 (etwa 1/16 der Gesamtdaten, Jahre 2024-2026).
• SEACASTs Uplink-Pacing verhindert, dass asymmetrische Heimanschlüsse durch unkoordinierte Flood-Wellen überlastet werden.

Durch die Kombination von Interest/Duty-Trennung und elastischer Bandbreiten-Adaptivität ermöglicht SEACAST einen universellen Transport-Layer, der sowohl komplette Execution Payloads als auch fragmentarische DAS-Samples effizient verteilt.

Formale Verifikation und reale Kernel-Simulationen

Die Spezifikation von SEACAST wurde formal mittels Quint und TLC modelliert. Dabei wurden Liveness-Gaps entdeckt und eine zentrale Penalty-Regel in Veil/Lean induktiv für beliebige Netzwerkgrößen bewiesen.

• Abweichung der Latenzergebnisse zwischen Virtual-Clock-Harness und Shadow-Simulation: 6 % (Jahr 2026).
• CPU-Last-Faktor von Vollnachrichten-Gossip gegenüber SEACAST-Segmentierung: 2-4-fach höher (Jahr 2026).
• Ergebnisse aus Shadow-Simulation bestätigen die Robustheit der Segmentierung unter realen Linux-Kernel- und QUIC/TCP-Implementierungen.

Die Simulationen zeigen, dass die theoretischen Geschwindigkeitsvorteile von SEACAST auch unter realistischen OS-Puffer- und Transportschicht-Dynamiken erhalten bleiben.

Risiken und offene Fragen

Obwohl SEACAST erhebliche Vorteile bietet, wurden im Rahmen der formalen Analyse und der praktischen Messungen folgende Punkte als potenzielle Schwachstellen identifiziert:

• Fehlende Quellenanonymität: Direktes Pushen von Chunks an Nachbarknoten kann den Ursprung rekonstruieren und Angriffe (DoS, Zensur) gegen Home-Builder ermöglichen.
• Liveness-Gaps bei dynamischen Topologie-Änderungen: Zehn liveness-relevante Szenarien wurden gefunden; zwei bleiben in Version 0.5 ungelöst und erfordern sorgfältige Client-Implementierung.
• Kryptografischer Verifikations-Overhead pro Chunk: Jeder Chunk muss kryptografisch geprüft werden (Merkle- oder KZG-Proof). Bei DoS-Angriffen mit ungültigen Chunks kann die CPU-Belastung steigen und Puffer überlaufen lassen.

Diese Risiken müssen durch ergänzende Maßnahmen (z. B. Entry-Proxies, optimierte Verifikations-Pipelines) adressiert werden, um die Sicherheit und Liveness des Gesamtsystems zu garantieren.

Häufig gestellte Fragen zu SEACAST

• Was unterscheidet SEACAST grundlegend vom heutigen Gossipsub in Ethereum? Gossipsub wartet, bis ein vollständiges Datenobjekt empfangen wurde, bevor es weitergeleitet wird (Store-and-Forward). SEACAST zerlegt Objekte in Reed-Solomon-kodierte Chunks und leitet jedes Fragment sofort nach Eintreffen weiter (Cut-Through-Pipelining), gesteuert über dynamische Bitmap-Ankündigungen und ein Bandbreiten-Pacing-Fenster.
• Wie verhindert SEACAST, dass langsame Up-links durch zu viele Chunks verstopft werden? Das Protokoll begrenzt die im Transit befindlichen Chunks über ein Sender-Fenster, das an die Up-link-Kapazität gekoppelt ist (ca. 130 ms Sendezeit). Zusätzlich werden Chunks aktiv nur an wenige Peers (Budget = 2) gepusht, während der Rest lediglich den Besitz ankündigt, sodass fehlende Stücke gezielt abgefragt werden.
• Benötigt SEACAST Änderungen am Ethereum-Konsens-Mechanismus? Für die reine Payload-Verbreitung (gemäß EIP-8411) reicht ein Merkle-Root-Commitment im Builder-Bid. Auf P2P-Ebene kann SEACAST als eigenständiges libp2p-Protokoll oder über bestehende Gossipsub-Erweiterungen (Partial Messages) ohne Hard-Fork eingeführt werden.

Fazit

SEACAST stellt einen bedeutenden Fortschritt für die Datenverteilung im Ethereum-Netzwerk dar. Die gemessenen Leistungszahlen zeigen, dass 99 % der Nodes eine 1 MiB-Payload in ca. 0,6 s erhalten – ein Faktor von sieben gegenüber konventionellem Gossipsub – bei gleichzeitig geringerem Bandbreiten-Overhead (1,3 MiB vs. 4,2 MiB pro Node). Die elastische Skalierung mit verfügbarer Up-stream-Bandbreite, die klare Trennung von Interest und Duty sowie die nahtlose Integration in bestehende DAS-Architekturen (PeerDAS, RowDAS) machen SEACAST zu einem universellen Transport-Layer, der sowohl aktuelle als auch zukünftige Anforderungen der Ethereum-Roadmap (EIP-8411, EIP-7732) adressiert. Formale Verifikation und reale Kernel-Simulationen untermauern die Robustheit des Designs, während identifizierte Risiken – Quellen-Privacy, Liveness-Gaps und kryptografischer Overhead – klare Ansatzpunkte für weitere Optimierungen bieten. Insgesamt garantiert SEACAST eine schnellere, bandbreiteneffizientere und dezentralisierungs-stärkende Verteilung großer Datenobjekte und stellt damit einen Schlüsselbestandteil für die Skalierung von Ethereum dar.