Revisiting Speculative Leaderless Protocols for Low-Latency BFT Replication

TL;DR

Aspen presents a near-optimal low-latency BFT SMR protocol by integrating leaderless operation, speculative execution, and fast-path quorums with a best-effort ETA-based sequencing layer. It achieves end-to-end latency around $2Δ+ε$ by relying on synchronized clocks, a larger replica set to tolerate diverging replicas, and proactive alignment to minimize divergence, with a PBFT-style repair path ensuring safety under partial synchrony. The evaluation demonstrates commit latencies under 75 ms and around 19k requests per second in wide-area deployments, representing a significant latency improvement over prior fast-path approaches, albeit with lower throughput than some high-throughput baselines. Aspen’s design offers practical latency benefits for user-facing, latency-sensitive applications in permissioned blockchains, while preserving safety and liveness via a robust fallback mechanism and periodic alignment.

Abstract

As Byzantine Fault Tolerant (BFT) protocols begin to be used in permissioned blockchains for user-facing applications such as payments, it is crucial that they provide low latency. In pursuit of low latency, some recently proposed BFT consensus protocols employ a leaderless optimistic fast path, in which clients broadcast their requests directly to replicas without first serializing requests at a leader, resulting in an end-to-end commit latency of 2 message delays ($2Δ$) during fault-free, synchronous periods. However, such a fast path only works if there is no contention: concurrent contending requests can cause replicas to diverge if they receive conflicting requests in different orders, triggering costly recovery procedures. In this work, we present Aspen, a leaderless BFT protocol that achieves a near-optimal latency of $2Δ+ \varepsilon$, where $\varepsilon$ indicates a short waiting delay. Aspen removes the no-contention condition by utilizing a best-effort sequencing layer based on loosely synchronized clocks and network delay estimates. Aspen requires $n = 3f + 2p + 1$ replicas to cope with up to $f$ Byzantine nodes. The $2p$ extra nodes allow Aspen's fast path to proceed even if up to $p$ replicas diverge due to unpredictable network delays. When its optimistic conditions do not hold, Aspen falls back to PBFT-style protocol, guaranteeing safety and liveness under partial synchrony. In experiments with wide-area distributed replicas, Aspen commits requests in less than 75 ms, a 1.2 to 3.3$\times$ improvement compared to previous protocols, while supporting 19,000 requests per second.

Figures (12)

• Figure 1: PBFT has an end-to-end latency of $5\Delta$
• Figure 2: Summary of low-latency techniques in prior works
• Figure 3: In case 1, messages $a$ and $b$, multicasted from proxies $\mathbf{p}_0$ and $\mathbf{p}_1$, arrive on replicas in different orders, but the ETAs ($t_a$ and $t_b$) successfully order the requests as $(a, b)$. In case 2, message $d$ arrives late to replica $r$, and thus replica $r$ see an inconsistent sequence of requests: $(c, d)$, compared with replica $s$, where $c$ and $d$ arrived on time, resulting in a sequence of $(d, c)$. In case 2, we say $r$ and $s$ have diverged.
• Figure 4: Replica state in Aspen
• Figure 5: Alignment of the log of diverged replicas $r_d$ to a checkpoint provided by $r_j$.