Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Fast Leaderless Byzantine Total Order Broadcast

Matteo Monti, Martina Camaioni, Pierre-Louis Roman

TL;DR

The paper addresses Byzantine fault-tolerant total-order broadcast with leaderless, signature-free protocols, introducing Blink as a Representative Binary Consensus and Flutter as a leaderless Total-Order Broadcast built on Blink. Blink achieves a fast path in the good case via a one-step, all-to-all suggestion phase and Representative Validity, enabling decisions in $Δ$ when all correct servers agree. Flutter leverages Bets attached to client messages and Overseen by Representative Binary Consensus to deliver in a good-case latency of $2Δ+ε$, a quasi-optimal bound, significantly improving over leader-based schemes. The work provides formal correctness sketches and latency analyses, compares to related work (e.g., Bosco, FaB Paxos), and discusses limitations such as denial-of-service considerations and avenues for future optimization and hardware acceleration.

Abstract

This paper presents the Byzantine fault-tolerant agreement protocols Flutter and Blink. Both algorithms are deterministic, leaderless and signature-free; both assume partial synchrony and at least $(5f + 1)$ servers, where $f$ bounds the number of faults. The main contribution, Flutter, is a Total-Order Broadcast implementation that achieves faster broadcast-to-delivery latency by removing the extra message delay associated with serializing messages through a leader. In the "good case" where all processes are correct, the network is synchronous, and local clocks are well-synchronized, Flutter delivers client requests in $(2Δ+ ε)$ time units, $Δ$ being the message delay and $ε$ an arbitrarily small constant. Under the same conditions, state-of-the-art protocols require $3Δ$ time units. Flutter's good-case latency is quasi-optimal, meaning it cannot be improved upon by any finite amount. Under the hood, Flutter builds upon Blink, a (Representative) Binary Consensus implementation whose fast path enables decisions in $Δ$ time units when all correct servers propose the same value. Blink generalizes the existing Binary Consensus solution Bosco from the $(7f + 1)$ to the $(5f + 1)$ setting.

Fast Leaderless Byzantine Total Order Broadcast

TL;DR

The paper addresses Byzantine fault-tolerant total-order broadcast with leaderless, signature-free protocols, introducing Blink as a Representative Binary Consensus and Flutter as a leaderless Total-Order Broadcast built on Blink. Blink achieves a fast path in the good case via a one-step, all-to-all suggestion phase and Representative Validity, enabling decisions in when all correct servers agree. Flutter leverages Bets attached to client messages and Overseen by Representative Binary Consensus to deliver in a good-case latency of , a quasi-optimal bound, significantly improving over leader-based schemes. The work provides formal correctness sketches and latency analyses, compares to related work (e.g., Bosco, FaB Paxos), and discusses limitations such as denial-of-service considerations and avenues for future optimization and hardware acceleration.

Abstract

This paper presents the Byzantine fault-tolerant agreement protocols Flutter and Blink. Both algorithms are deterministic, leaderless and signature-free; both assume partial synchrony and at least servers, where bounds the number of faults. The main contribution, Flutter, is a Total-Order Broadcast implementation that achieves faster broadcast-to-delivery latency by removing the extra message delay associated with serializing messages through a leader. In the "good case" where all processes are correct, the network is synchronous, and local clocks are well-synchronized, Flutter delivers client requests in time units, being the message delay and an arbitrarily small constant. Under the same conditions, state-of-the-art protocols require time units. Flutter's good-case latency is quasi-optimal, meaning it cannot be improved upon by any finite amount. Under the hood, Flutter builds upon Blink, a (Representative) Binary Consensus implementation whose fast path enables decisions in time units when all correct servers propose the same value. Blink generalizes the existing Binary Consensus solution Bosco from the to the setting.

Paper Structure

This paper contains 87 sections, 49 theorems, 15 equations, 6 figures, 3 algorithms.

Table of Contents

  1. Introduction
  2. Goal 1: Simplicity.
  3. Goal 2: Leader-freedom.
  4. Goal 3: Signature-freedom.
  5. Goal 4: Optimism.
  6. Blink.
  7. Flutter.
  8. Contributions summary.
  9. Roadmap.
  10. Model and Background
  11. Model
  12. System, links and scheduling.
  13. Adversary and faults.
  14. Abstractions
  15. Representative Binary Consensus.
  16. ...and 72 more sections

Key Result

Lemma 1

Every correct server eventually triggers ${\left\langle dep\xspace.\textrm{Decide}\right\rangle}$.

Figures (6)

  • Figure 1: Good-case latencies of Flutter and FaB Paxos fab-paxos-dsn05. Other fast Byzantine Total-Order Broadcast protocols follow FaB Paxos' leader-based pattern: (1) the client $\theta$ sends its message to the leader $\pi_1$, (2) which disseminates it to all servers $\pi_1 \ldots \pi_n$, (3) each of which disseminates a confirmation message, (4) upon which all servers decide. These protocols have a good-case latency of $3\Delta$. Flutter skips the forwarding leader, saving a message delay as in Fast Paxos lamport-fast-paxos-dc06, but adds an arbitrarily small delay $\epsilon$ for a good-case latency of ${\left(2\Delta + \epsilon\right)}$.
  • Figure 2: Blink algorithm. A correct server disseminates its proposal as a suggestion, then proposes to Binary Consensus whichever value it was suggested the most. In the fast path, a correct server decides after receiving ${\left(4 f + 1\right)}$ matching suggestions. In the slow path, a correct server decides whatever Binary Consensus decides. Notation: a correct server's engagement in Binary Consensus is marked by a crossed bar; proposals and decisions are indicated at the beginning and end of each bar; ✓ represents $\text{\tt True}$.
  • Figure 3: Example client messages in Flutter, noted $a$ to $p$, as seen by a correct server at a given time. Messages are organized on a timeline, appearing at the time of their bet. The Consensus status of each message is represented by the two symbols on top of the message: the server's proposal on top (✓ to deliver the message, X to reject it), Representative Binary Consensus's decision on the bottom (✓ or X to deliver or reject, ? if Representative Binary Consensus is still running). The server already delivered all messages whose decision is boxed. Messages marked by a solid line are candidates, those marked by a dashed line are not.
  • Figure 4: Examples of (a) good case and (b) bad case executions of Flutter. Broadcast times are indicated with a question mark; delivery times with an exclamation mark; a correct server's engagement in Representative Binary Consensus is marked by a striped bar; proposals and decisions are indicated at the beginning and end of each bar; ✓ represents $\text{\tt True}$; X represents $\text{\tt False}$.
  • Figure : Blink
  • ...and 1 more figures

Theorems & Definitions (54)

  • Lemma 1
  • Theorem 1
  • Lemma 2
  • Lemma 3
  • Lemma 4
  • Theorem 2
  • Theorem 3
  • Theorem 4
  • Theorem 5
  • Lemma 5
  • ...and 44 more