Table of Contents
Fetching ...

Banyan: Fast Rotating Leader BFT

Yann Vonlanthen, Jakub Sliwinski, Massimo Albarello, Roger Wattenhofer

TL;DR

Banyan addresses latency in Byzantine fault-tolerant state machine replication by introducing a rotating-leader protocol with a dual-mode fast path that can finalize a block in a single RTT under partial synchrony, parameterized by $n$, $f$, and $p$. It extends the Internet Computer Consensus with a fast-path mechanism that runs alongside the slow path, preserving optimistic responsiveness and avoiding view-change. The authors provide formal safety and liveness proofs, an open-source Golang implementation built on Bamboo, and extensive WAN experiments showing up to 30% latency reductions over ICC and other baselines. This work suggests Banyan is well-suited for global permissioned blockchains and Layer-2 sequencers where low latency is critical.

Abstract

This paper presents Banyan, the first rotating leader state machine replication (SMR) protocol that allows transactions to be confirmed in just a single round-trip time in the Byzantine fault tolerance (BFT) setting. Based on minimal alterations to the Internet Computer Consensus (ICC) protocol and with negligible communication overhead, we introduce a novel dual mode mechanism that enables optimal block finalization latency in the fast path. Crucially, the modes of operation are integrated, such that even if the fast path is not effective, no penalties are incurred. Moreover, our algorithm maintains the core attributes of the ICC protocol it is based on, including optimistic responsiveness and rotating leaders without the necessity for a view-change protocol. We prove the correctness of our protocol and provide an open-source implementation of it. Banyan is compared to its predecessor ICC, as well as other well known BFT protocols, in a globally distributed wide-area network. Our evaluation reveals that Banyan reduces latency by up to 30% compared to state-of-the-art protocols, without requiring additional security assumptions.

Banyan: Fast Rotating Leader BFT

TL;DR

Banyan addresses latency in Byzantine fault-tolerant state machine replication by introducing a rotating-leader protocol with a dual-mode fast path that can finalize a block in a single RTT under partial synchrony, parameterized by , , and . It extends the Internet Computer Consensus with a fast-path mechanism that runs alongside the slow path, preserving optimistic responsiveness and avoiding view-change. The authors provide formal safety and liveness proofs, an open-source Golang implementation built on Bamboo, and extensive WAN experiments showing up to 30% latency reductions over ICC and other baselines. This work suggests Banyan is well-suited for global permissioned blockchains and Layer-2 sequencers where low latency is critical.

Abstract

This paper presents Banyan, the first rotating leader state machine replication (SMR) protocol that allows transactions to be confirmed in just a single round-trip time in the Byzantine fault tolerance (BFT) setting. Based on minimal alterations to the Internet Computer Consensus (ICC) protocol and with negligible communication overhead, we introduce a novel dual mode mechanism that enables optimal block finalization latency in the fast path. Crucially, the modes of operation are integrated, such that even if the fast path is not effective, no penalties are incurred. Moreover, our algorithm maintains the core attributes of the ICC protocol it is based on, including optimistic responsiveness and rotating leaders without the necessity for a view-change protocol. We prove the correctness of our protocol and provide an open-source implementation of it. Banyan is compared to its predecessor ICC, as well as other well known BFT protocols, in a globally distributed wide-area network. Our evaluation reveals that Banyan reduces latency by up to 30% compared to state-of-the-art protocols, without requiring additional security assumptions.
Paper Structure (20 sections, 7 theorems, 4 equations, 6 figures, 1 table, 2 algorithms)

This paper contains 20 sections, 7 theorems, 4 equations, 6 figures, 1 table, 2 algorithms.

Key Result

lemma 1

If each honest replica broadcasts a fast vote in round $k$, then Banyan guarantees that each honest replica eventually observes at least one unlocked block.

Figures (6)

  • Figure 1: Banyan can terminate after just two communication steps. Existing rotating leader BFT protocols require at least three communication steps.
  • Figure 2: The different approaches of fast path protocols. In many protocols, the slow path starts after the fast path fails. In Banyan, the fast path is integrated into the slow path.
  • Figure 3: The diagram shows the steps necessary to reach the finalization of a block. Black blocks are finalized, dark gray blocks are notarized, while light gray blocks are not. In this example, $n=4$ and $f=1$. Initially, $n-f=3$ replicas send notarization votes (NV) for the rank-0 block of round $k$. Replicas will not send a NV for higher rank proposals, in this round. As soon as the NV are received, the replica combines them in a notarization (N). Then, the replicas that only sent an NV for the rank-0 block will also send a finalization vote (FV) for it. Once the three FV are received, they will be combined into a finalization (F) and both the r-0 block and its ancestor(s) are finalized.
  • Figure 4: Fast votes (FaV) received for each block are shown in the block-tree. Black blocks are finalized, dark gray blocks are unlocked, while light gray blocks are not. Supposing $n=4$, $f=1$, and $p=1$, for round $k$, Condition 1 is met, and the r-0 block is unlocked. Instead, for round $(k+1)$, Condition 2 is met, and all blocks in this round are unlocked.
  • Figure 5: Locations of the AWS datacenters used in our testbed. Red triangles represent the 4 datacenters employed in \ref{['exp:equi']}, yellow crosses indicate the 4 US datacenters used in \ref{['exp:byz']}, and black dots denote the 19 worldwide datacenters used in \ref{['exp:wan']}.
  • ...and 1 more figures

Theorems & Definitions (21)

  • remark 1: Finalization Latency
  • remark 2: Timeouts
  • remark 3
  • definition 1
  • definition 2: Fast Vote
  • definition 3
  • definition 4
  • remark 4
  • definition 5
  • definition 6
  • ...and 11 more