SEACAST: fast, lean broadcast for Ethereum, with an executable spec and a formal model

SEACAST: Fast, Lean Broadcast for Ethereum

Ethereum’s ecosystem is increasingly dealing with large objects—execution payloads, data‑availability columns, and future post‑quantum signatures—that must be disseminated quickly to many nodes. Traditional gossip protocols, such as gossipsub, wait for a node to receive the entire object before forwarding it and often deliver multiple redundant copies, leading to unnecessary latency and bandwidth consumption. SEACAST (Segmented, Encoded, Availability‑sampled broadCAST) addresses these inefficiencies with a protocol built on three core ideas:

1. Segmented, Coded Diffusion

• Segments (chunks): An object is split into erasure‑coded chunks (currently Reed–Solomon). Any subset of k chunks can reconstruct the full object, eliminating the “last chunk” bottleneck.
• Immediate forwarding: Nodes forward each chunk as soon as it arrives, without waiting for the whole object. This mirrors techniques from early P2P streaming systems (e.g., SplitStream, CoolStreaming).
• Push‑pull balance: A small push budget (typically two pushes per chunk) quickly spreads chunks, while pull requests fill any gaps, similar to Plumtree’s split strategy.

2. Elastic, Sample‑Driven Delivery

• Data‑availability sampling (DAS): Nodes declare whether they need the full object, a specific set of columns, or a random sample of cells. The protocol respects this interest, sending only the required chunks.
• Bitfield announcements: Each node maintains a bitmap of owned chunks and periodically announces it to peers, enabling efficient pull decisions and reducing duplicate transmissions.
• Rate‑controlled windows: Out‑flight chunks are limited by the node’s uplink capacity, ensuring that bandwidth‑constrained nodes (e.g., home users with 10‑50 Mbps uplinks) stay close to the theoretical lower bound on delay.

3. Executable Specification & Formal Model

• Executable spec: The protocol is defined in concise pseudocode that runs unchanged in a reference simulator, providing a clear, testable description.
• Formal verification: A TLA⁺ model checks safety properties (delivery, promise handling, expiry). Early versions uncovered ten gaps; version 0.5 already fixed eight, and the model is published alongside the spec.

---

Performance Highlights (Simulation Results)

| Scenario | Object Size | 99 % Delivery Time | Bandwidth per Node (copies) | |----------|-------------|-------------------|-----------------------------| | Home‑node network (50 Mbps up) | 1 MiB payload | 0.64 s (vs. 0.97 s with ECBroadcast, 4.5 s with gossipsub) | 1.7× (vs. 4.4× with gossipsub) | | Datacenter source (1 Gbps) & home peers | 1 MiB payload | 0.45 s (vs. 0.58 s ECBroadcast, 1.6 s gossipsub) | ≈0.6× of ECBroadcast, <0.5× of gossipsub | | Column‑shaped DAS object (128 columns, 8 per node) | – | 0.7 s for 99 % of nodes to receive assigned columns | 1.3× copies for median node |

These results show that SEACAST consistently stays within 2.2–2.5 × the theoretical lower bound on delay, while using roughly half to a third of the bandwidth of competing protocols.

---

Integration Paths

SEACAST is defined as a stand‑alone libp2p protocol, but it can also be layered on top of existing gossipsub transports via the Partial Messages extension. This flexibility allows incremental rollout:

1. Native libp2p implementation – clean separation of messages (holdings, asks, chunks).
2. gossipsub binding – reuse existing topic infrastructure for gradual migration.
3. Custom transports – any future P2P layer can adopt the same message semantics.

---

Practical Takeaways

• Lower latency: By forwarding chunks immediately and limiting in‑flight data to the uplink capacity, SEACAST meets tight slot deadlines even on modest home connections.
• Bandwidth efficiency: Nodes receive just enough data to reconstruct what they need, cutting redundant traffic dramatically.
• Robustness: The formal model and executable spec provide confidence that the protocol behaves correctly under adversarial conditions (e.g., nodes that withhold or lie about holdings).
• Ease of adoption: Existing Ethereum clients can integrate SEACAST via libp2p or a gossipsub overlay, allowing a phased transition from current gossip mechanisms.

In summary, SEACAST offers a principled, well‑specified broadcast solution tailored to Ethereum’s evolving data‑distribution demands, delivering faster propagation with far less network overhead than today’s gossip‑based approaches.