Rapidblocks, take two: a pipelined consensus for independent blocks

Rapidblocks, Take Two: A Pipelined Consensus for Independent Blocks

TL;DR – The new Rapidblocks design lets each block build on a state from two slots earlier while respecting a Bloom‑filter of concurrent modifications. By voting on slot values rather than ordering blocks, the protocol achieves fast confirmation, high concurrency, and resilience to reorgs.

---

1. The Core Idea – Independent Sub‑Chains

Traditional blockchains require each block to reference its immediate predecessor, creating a strict linear chain. Rapidblocks 2 relaxes this requirement:

• State Edge (Hist) – A block executes on the state of the block two slots before it (slot j‑2). This creates a pipeline where producers can start work earlier.
• Filter Edge (Refs) – Each block also carries a Bloom filter (BMF) that records the keys it modifies. When a block is proposed, it must be compatible with every other block in the current window of L slots: the set of keys it reads (`A(b)`) must not intersect the set of keys any concurrent block writes (`M(c)`).

If a block fails compatibility, it is simply omitted from the canonical set; later blocks that do not depend on it remain valid. This eliminates the need for costly reorgs when a slot is missed.

---

2. Slot‑Based Consensus – Voting on Values, Not Order

Instead of ordering blocks, the protocol decides a single value per slot – either a block header hash or ⊥ (empty). The process unfolds in several timed phases:

| Phase | Timing (relative to slot start) | Purpose | |------|--------------------------------|----------| | Header Arrival | `j·τ + Δ` | Nodes check whether the header arrived on time. Late headers are ignored to preserve the earlier‑slot‑wins rule. | | Round A (Body Vote) | `j·τ + a` | Voters verify the block body, confirm that its Hist and filter edges are feasible, and cast their vote. | | Follow‑Rounds | Every `m`‑th slot after Round A | Votes are propagated, merged with the producer’s view, and ties resolve to ⊥. |

Key parameters:

• `τ` – slot duration.
• `Δ` – maximum network delay for honest messages.
• `a` – offset for the body vote (typically `0.5·τ`).
• `m` – cadence of follow‑rounds (1 or 2 slots).
• `L` – size of the concurrency window (e.g., 4 slots).
• `T` – fast‑confirmation threshold (≥ 2/3 of voting stake).

A block is fast‑confirmed when > 2/3 of the committee votes for it in a single round and the vote is received before `(r+m)·τ – 2Δ`. Because votes are counted per slot, a block’s weight is independent of unrelated conflicts in the same window, preserving the independence property.

---

3. Safety Mechanisms – Own Values, Closure, and Cadence

Own Values

Between rounds, each node retains the value it would have cast in the most recent round it observed. This “own value” is used for feasibility checks, ensuring that a producer cannot be misled by a partially‑observed majority.

Closure

A block’s confirmation is final only after the blocks it depends on (its Hist) are themselves confirmed at least `m` rounds earlier. This prevents a block from being built on a decision that later flips, which would otherwise cause cascading drops.

Explicit Cadence

If votes lag beyond the next round’s freeze, nodes fall back to older rounds, avoiding interleaved decision streams that an adversary could exploit. Adjusting `m` and `L` lets the protocol tolerate slower networks while keeping concurrency bounded.

---

4. Performance & Security Insights

• Fast Confirmation – With `m = 1` and `τ = 2 s`, a block can be confirmed in roughly 3 Δ ≈ 3 s, and the next producer can start building on it after 3.5 s. This matches the original one‑slot pipeline.
• Concurrency – The window `L` determines how many slots can be “open” simultaneously. For `L = 4` and `m = 2`, up to two slots may be concurrent, still preserving safety.
• Adversarial Impact – Simulations with 30 % adversarial stake show that without the own values and closure rules, up to 28 % of honest blocks could be lost. With the full rule set, loss drops to < 1 %.
• Probability of Missed Deadline – The chance that a block misses its decision deadline is bounded by `β^{1+⌊(L‑a)/m⌋}`. For `β = 0.2`, `L = 4`, `a = 1`, this is about 0.0016, i.e., roughly one missed deadline every 20 minutes at `τ = 2 s`.

---

5. Open Questions & Next Steps

1. Finality Integration – How to embed a Fork‑Choice‑Finality‑Gadget (FFG) into the same vote structure remains an open design point.
2. Large‑Scale Deployment – Measuring real‑world vote aggregation latency will determine whether `m = 1` (single‑slot pipeline) or `m = 2` (two‑slot pipeline) is realistic.
3. Model‑Checking at Scale – Ongoing work with Quint/Apalache aims to verify the safety properties for larger `m` and more validators.

---

Closing Thoughts

Rapidblocks 2 demonstrates that a pipelined, slot‑based consensus can safely support independent sub‑chains, dramatically reducing the cost of missed slots and enabling higher throughput. By shifting the consensus problem from ordering blocks to agreeing on per‑slot values and by enforcing feasibility through Bloom‑filter compatibility, the design retains strong safety guarantees while offering flexibility to adapt to network conditions. Continued simulation, formal verification, and real‑world testing will be essential to move this promising concept toward production deployment.