Gatling: Rapid-Fire Consensus via Parallel Composition

• Gatling is an atomic broadcast protocol that employs parallel consensus instances to reduce inter-proposal time below network delay while preserving the base confirmation time.
• It deterministically interleaves outputs from staggered schedules to merge independent instances into a consistent global log used in blockchain and replicated state machine contexts.
• The design carefully trades faster proposal cadence against potential head-of-line blocking, with the optimal number of instances adapting to network reliability.

Gatling is an atomic broadcast protocol that composes multiple parallel instances of a black-box atomic broadcast protocol and deterministically interleaves their outputs into a single global log, with the aim of reducing the effective inter-proposal time below the network delay while preserving the component protocol’s confirmation time (Scaffino et al., 16 Jun 2026). In the formulation of "Gatling: Rapid-Fire Consensus from Parallel Composition," consensus protocols are treated as the core of blockchains and other replicated state machines, where performance in fault-free executions is driven by good-case transaction latency: the interval between a transaction becoming known to all nodes and its confirmation by the consensus protocol. Gatling addresses the open question of whether inter-proposal time can be reduced below the state-of-the-art of one network delay under rotating leader schedules, and the paper states that it can achieve arbitrarily small inter-proposal times by parallel composition and staggered proposal schedules (Scaffino et al., 16 Jun 2026).

1. Problem setting and performance objective

The paper situates Gatling in partially-synchronous BFT protocols such as PBFT, HotStuff, and Simplex, where block or proposal times are bounded below by the network delay $d$ because each leader must see—or safely assume—a quorum on the previous proposal before issuing the next (Scaffino et al., 16 Jun 2026). This yields an inter-proposal time $\Delta \ge d$, which in turn produces a lower bound on good-case transaction latency of roughly $3 \cdot d + \Delta/2$, with the example decomposition given as $3 \cdot d$ for confirmation plus $\Delta/2$ average wait for inclusion.

The stated point of departure is that prior work had already established tight lower bounds on confirmation latency that modern protocols already achieve, whereas reducing inter-proposal time below one network delay remained open (Scaffino et al., 16 Jun 2026). Gatling therefore does not attempt to improve the underlying confirmation-latency floor; instead, it targets the waiting time before a transaction enters a proposal. This framing is central to the protocol’s design: the system leaves the component consensus logic unchanged and restructures the proposal schedule at the composition layer.

A plausible implication is that Gatling should be read less as a replacement for existing atomic broadcast protocols than as a wrapper construction for improving proposal cadence when the base protocol already has near-optimal confirmation latency. The paper explicitly supports this reading by describing the construction as compatible with off-the-shelf component protocols and by emphasizing that the component protocol need not be fine-tuned for minimum latency (Scaffino et al., 16 Jun 2026).

2. Parallel composition and staggered schedules

Gatling assumes a component atomic-broadcast protocol $\Pi$ that runs in slots $s = 1,2,\ldots$ with a fixed proposal schedule every $\Delta$ time, guarantees good-case $(\Delta, T_{\mathrm{conf}})$ latency, and exports the interface broadcast(tx) and deliveredAnnotatedLog() → sequence of (tx, slot) pairs (Scaffino et al., 16 Jun 2026). Gatling$(I = \Pi, k, \Delta)$ then runs $\Delta \ge d$0 independent copies $\Delta \ge d$1 of $\Delta \ge d$2.

The core notation is explicit in the paper:

• $\Delta \ge d$3: inter-proposal time of each component instance
• $\Delta \ge d$4: worst-case network delay
• $\Delta \ge d$5: number of parallel instances
• $\Delta \ge d$6: Gatling’s global inter-proposal time
• $\Delta \ge d$7: confirmation latency of $\Delta \ge d$8, typically $\Delta \ge d$9 (Scaffino et al., 16 Jun 2026)

Instance $3 \cdot d + \Delta/2$0 uses proposal times

$3 \cdot d + \Delta/2$1

so that across all $3 \cdot d + \Delta/2$2 instances proposals occur every $3 \cdot d + \Delta/2$3 time (Scaffino et al., 16 Jun 2026). This staggered schedule is the mechanism by which Gatling converts $3 \cdot d + \Delta/2$4 component instances, each spaced by $3 \cdot d + \Delta/2$5, into a composite system with effective spacing $3 \cdot d + \Delta/2$6.

Input handling is equally direct. When a node receives a transaction from its local client at time $3 \cdot d + \Delta/2$7, it immediately calls broadcast(tx) in every instance $3 \cdot d + \Delta/2$8 (Scaffino et al., 16 Jun 2026). The paper states that the transaction therefore appears in the next proposal of whichever instance’s scheduled slot arises first, at worst $3 \cdot d + \Delta/2$9 time later. In the fault-free case, this leads to good-case transaction latency $3 \cdot d$0, and since $3 \cdot d$1 can be made arbitrarily large, $3 \cdot d$2 while the confirmation component remains fixed (Scaffino et al., 16 Jun 2026).

This design suggests a decomposition of latency into two independent terms: inclusion delay controlled by cross-instance staggering, and confirmation delay inherited from the base protocol. The paper’s formal good-case statement is consistent with that separation.

3. Deterministic interleaving and global-log construction

The outputs of the $3 \cdot d$3 component instances are merged by a deterministic interleaving rule (Scaffino et al., 16 Jun 2026). Let $3 \cdot d$4 be the payload, possibly empty, that instance $3 \cdot d$5 decides for slot $3 \cdot d$6. Gatling computes the delivered log using

$3 \cdot d$7

and

$3 \cdot d$8

If $3 \cdot d$9, the log is

$\Delta/2$0

and otherwise the same prefix is extended by

$\Delta/2$1

In words, confirmed blocks are interleaved by ascending slot and then by ascending instance index (Scaffino et al., 16 Jun 2026).

The paper also gives a compact index-based description. If

$\Delta/2$2

then the global index is

$\Delta/2$3

The $\Delta/2$4-th entry of the Gatling log is block $\Delta/2$5, where $\Delta/2$6 using 1-based arithmetic (Scaffino et al., 16 Jun 2026). Equivalently, the delivered log is

$\Delta/2$7

A block $\Delta/2$8 is confirmed by Gatling as soon as three conditions hold: $\Delta/2$9 has decided slot $\Pi$0; all other instances have decided all slots less than $\Pi$1; and for instances with lower index $\Pi$2, slot $\Pi$3 has also been decided (Scaffino et al., 16 Jun 2026). The significance of this rule is that all honest nodes produce exactly the same merged log because each $\Pi$4 is itself consistent across nodes.

A common misconception would be that parallel instances could introduce nondeterministic cross-instance races. The deterministic interleaving rule addresses precisely that concern: concurrency is used for proposal generation, but not for ambiguity in log order.

4. Security, liveness, and good-case latency

The paper’s first main theorem states: if $\Pi$5 is a secure atomic broadcast protocol with safety and liveness up to $\Pi$6 faults, then Gatling$\Pi$7 is also secure, with the same safety, liveness, and fault tolerance (Scaffino et al., 16 Jun 2026). The construction therefore preserves the component protocol’s fault model rather than redefining it.

The second main theorem gives the good-case latency guarantee. If $\Pi$8 satisfies good-case $\Pi$9 latency under partial synchrony with worst-case round length $s = 1,2,\ldots$0, then Gatling achieves good-case latency with inter-proposal time $s = 1,2,\ldots$1 and confirmation time $s = 1,2,\ldots$2 (Scaffino et al., 16 Jun 2026). In particular, once GST has passed and all nodes are honest, any transaction arriving by time $s = 1,2,\ldots$3 enters some instance’s next proposal within $s = 1,2,\ldots$4 time and is then confirmed within $s = 1,2,\ldots$5 time.

The importance of this theorem is narrowly specified. Gatling does not claim to reduce confirmation time below the lower bounds already met by modern protocols; rather, it pushes the proposal rate so that the total latency approaches the confirmation-latency floor (Scaffino et al., 16 Jun 2026). In the notation of the paper, the fault-free latency becomes

$s = 1,2,\ldots$6

Since $s = 1,2,\ldots$7 can be made arbitrarily large, the inclusion term can be driven toward zero.

The paper’s broader takeaway is that parallel composition and staggered proposals break the traditional $s = 1,2,\ldots$8 bound on inter-proposal time, allowing sub-$s = 1,2,\ldots$9 proposals while retaining the base protocol’s confirmation behavior (Scaffino et al., 16 Jun 2026). This suggests that the conventional coupling between leader rotation frequency and network delay is not fundamental once one permits multiple concurrently running instances and deterministic post hoc merging.

5. Head-of-line blocking and the optimal number of instances

The principal cost of the construction is head-of-line blocking (Scaffino et al., 16 Jun 2026). If instance $\Delta$0 fails to decide a slot promptly, for example because its leader crashes, that slot becomes empty after $\Delta$1, but Gatling must still wait for that empty-slot decision before appending later blocks from other instances in the same global turn. Faster proposal spacing therefore creates an opposing pressure: more instances reduce $\Delta$2, but they also increase exposure to stalls at merge points.

To analyze this tradeoff, the paper models the decision time $\Delta$3 of the $\Delta$4-th global proposal as i.i.d. with CDF $\Delta$5, under global spacing $\Delta$6 (Scaffino et al., 16 Jun 2026). The probability that the $\Delta$7-th proposal is appended to the Gatling log within time $\Delta$8 after issuance is

$\Delta$9

By the survival-integral formula, the steady-state expected append delay is

$(\Delta, T_{\mathrm{conf}})$0

and adding the average inclusion wait $(\Delta, T_{\mathrm{conf}})$1 yields total latency

$(\Delta, T_{\mathrm{conf}})$2

For a simple stochastic model in which each decision attempt, costing $(\Delta, T_{\mathrm{conf}})$3, succeeds with probability $(\Delta, T_{\mathrm{conf}})$4 and fails with probability $(\Delta, T_{\mathrm{conf}})$5, the paper approximates $(\Delta, T_{\mathrm{conf}})$6 by a shifted exponential:

$(\Delta, T_{\mathrm{conf}})$7

with

$(\Delta, T_{\mathrm{conf}})$8

Letting $(\Delta, T_{\mathrm{conf}})$9, the paper states that one can show, using $(I = \Pi, k, \Delta)$0-Pochhammer notation,

$(I = \Pi, k, \Delta)$1

and obtains a closed-form characterization of the unique optimum $(I = \Pi, k, \Delta)$2, equivalently $(I = \Pi, k, \Delta)$3, in Theorem 5.1 (Scaffino et al., 16 Jun 2026):

$(I = \Pi, k, \Delta)$4

where $(I = \Pi, k, \Delta)$5 is the unique root in $(I = \Pi, k, \Delta)$6 of

$(I = \Pi, k, \Delta)$7

The numerical conclusion reported in the paper is that $(I = \Pi, k, \Delta)$8 as $(I = \Pi, k, \Delta)$9, with $\Delta \ge d$00; for lower reliability $\Delta \ge d$01, one uses smaller $\Delta \ge d$02 to balance head-of-line blocking against reduced $\Delta \ge d$03 (Scaffino et al., 16 Jun 2026). This is the main qualification to the otherwise asymptotic statement that inter-proposal time can be made arbitrarily small: the best operating point depends on reliability, not only on nominal network delay.

6. Predictable validity and protocol variants

The paper states that Gatling as described sacrifices predictable validity when $\Delta \ge d$04 and the leader rotates every slot, because leaders cannot validate transactions on-chain before proposing (Scaffino et al., 16 Jun 2026). This is the paper’s most explicit caveat. The issue is not safety or liveness of the merged log, but the ability of proposers to rely on a fully propagated and validated chain prefix when constructing state-dependent blocks.

Two mitigations are given, both under slowly rotating leader schedules with windows of consecutive slots per leader and inter-window gaps (Scaffino et al., 16 Jun 2026).

The first is the Empty-Blocks Variant. It designates disjoint time windows of length at least $\Delta \ge d$05 in which one leader issues up to $\Delta \ge d$06 proposals at spacing $\Delta \ge d$07, and inserts gaps of length at least $\Delta \ge d$08 between windows during which the same or a special proposer issues empty proposals (Scaffino et al., 16 Jun 2026). The stated result is that the gap of $\Delta \ge d$09 empty blocks ensures that no real blocks are proposed until the previous window’s blocks have fully propagated, so each real proposer sees a correct prefix and can validly build on it. The proof sketch says that the $\Delta \ge d$10-length gap ensures that any real block in window $\Delta \ge d$11 has been delivered to the next window’s leader before it issues a real proposal.

The second is the Subprime-Blocks Variant. It introduces two tiers of block space: prime blocks in windows, which are state-sensitive, with DeFi transactions given as the example; and subprime blocks in gaps, which are state-independent, with data blobs given as the example (Scaffino et al., 16 Jun 2026). Consensus still merges windows and gaps by slot and index, but the execution layer reorders each window-gap pair so that all prime blocks of window $\Delta \ge d$12 are executed before the subprime blocks of gap $\Delta \ge d$13. The stated result is that prime-block proposers always build on an up-to-date prefix, since they precede the gap in execution, and subprime blocks need no validity checks.

These variants clarify an important distinction. Gatling’s baseline construction is about ordering and latency; predictable validity concerns state-dependent proposal formation under rapid leader rotation. The paper’s response is therefore not to alter the core merge rule, but to structure time into windows and gaps so that propagation and validation requirements can be reintroduced where needed (Scaffino et al., 16 Jun 2026).

7. Experimental evaluation and empirical operating regimes

The experiments were run on a global 10-node cluster with nodes in London, Tokyo$\Delta \ge d$14, Singapore$\Delta \ge d$15, Dallas$\Delta \ge d$16, and Miami (Scaffino et al., 16 Jun 2026). The component protocol was Simplex, configured with per-instance $\Delta \ge d$17 ms, leader-timeout $\Delta \ge d$18 ms, notarize-timeout $\Delta \ge d$19 ms, and message delays up to approximately $\Delta \ge d$20 ms.

In the good case with $\Delta \ge d$21 drops, the paper reports that the inter-proposal time $\Delta \ge d$22 falls from $\Delta \ge d$23 ms at $\Delta \ge d$24 to approximately $\Delta \ge d$25 ms at $\Delta \ge d$26, confirmation time stabilizes at approximately $\Delta \ge d$27 ms, approximately $\Delta \ge d$28, and total latency bottoms at approximately $\Delta \ge d$29 ms around $\Delta \ge d$30--$\Delta \ge d$31, followed by small jitter (Scaffino et al., 16 Jun 2026). This empirical profile matches the theoretical decomposition: confirmation latency remains at the component protocol’s floor, while inclusion delay decreases with larger $\Delta \ge d$32.

With proposal-drop rates $\Delta \ge d$33 used to emulate failures, the latency curves $\Delta \ge d$34 exhibit a clear U-shape: decreasing for small $\Delta \ge d$35 because proposals are faster, then increasing for large $\Delta \ge d$36 because head-of-line blocking becomes dominant (Scaffino et al., 16 Jun 2026). The reported optima are summarized below.

Proposal-drop rate	Optimal $\Delta \ge d$37	Latency
$\Delta \ge d$38	$\Delta \ge d$39	$\Delta \ge d$40 ms
$\Delta \ge d$41	$\Delta \ge d$42	$\Delta \ge d$43 ms
$\Delta \ge d$44	$\Delta \ge d$45	$\Delta \ge d$46 ms

The paper also compares Gatling with single-instance and state-of-the-art baselines (Scaffino et al., 16 Jun 2026). Simplex alone, with $\Delta \ge d$47 ms, yields latency of approximately $\Delta \ge d$48 ms. Hydrangea++/Moonshot, with $\Delta \ge d$49 ms, yields approximately $\Delta \ge d$50 ms. Gatling at $\Delta \ge d$51 with $\Delta \ge d$52 drops yields $\Delta \ge d$53 ms and latency approximately $\Delta \ge d$54 ms.

The sensitivity result reported is that as network reliability $\Delta \ge d$55 increases, the optimal $\Delta \ge d$56 also increases, because head-of-line blocking becomes rarer (Scaffino et al., 16 Jun 2026). Even with round trips of approximately $\Delta \ge d$57 ms, Gatling rotates leaders every much less than $\Delta \ge d$58 ms among $\Delta \ge d$59 instances. The paper’s overall conclusion is that the construction is fully closed-box, composable with pipelining, speculative fast paths, and responsive designs, and can achieve end-to-end latencies well below what any single-instance protocol can (Scaffino et al., 16 Jun 2026).