Table of Contents
Fetching ...

A Performance Analysis of BFT Consensus for Blockchains

J. D. Chan, Y. C. Tay, Brian R. Z. Yen

TL;DR

An analytical model is presented to address issues in the case of crash faults of two consensus protocols (Istanbul BFT and HotStuff and HotStuff) and two network topologies (Folded-Clos and Dragonfly).

Abstract

Distributed ledgers are common in the industry. Some of them can use blockchains as their underlying infrastructure. A blockchain requires participants to agree on its contents. This can be achieved via a consensus protocol, and several BFT (Byzantine Fault Tolerant) protocols have been proposed for this purpose. How do these protocols differ in performance? And how is this difference affected by the communication network? Moreover, such a protocol would need a timer to ensure progress, but how should the timer be set? This paper presents an analytical model to address these and related issues in the case of crash faults. Specifically, it focuses on two consensus protocols (Istanbul BFT and HotStuff) and two network topologies (Folded-Clos and Dragonfly). The model provides closed-form expressions for analyzing how the timer value and number of participants, faults and switches affect the consensus time. The formulas and analyses are validated with simulations. The conclusion offers some tips for analytical modeling of such protocols.

A Performance Analysis of BFT Consensus for Blockchains

TL;DR

An analytical model is presented to address issues in the case of crash faults of two consensus protocols (Istanbul BFT and HotStuff and HotStuff) and two network topologies (Folded-Clos and Dragonfly).

Abstract

Distributed ledgers are common in the industry. Some of them can use blockchains as their underlying infrastructure. A blockchain requires participants to agree on its contents. This can be achieved via a consensus protocol, and several BFT (Byzantine Fault Tolerant) protocols have been proposed for this purpose. How do these protocols differ in performance? And how is this difference affected by the communication network? Moreover, such a protocol would need a timer to ensure progress, but how should the timer be set? This paper presents an analytical model to address these and related issues in the case of crash faults. Specifically, it focuses on two consensus protocols (Istanbul BFT and HotStuff) and two network topologies (Folded-Clos and Dragonfly). The model provides closed-form expressions for analyzing how the timer value and number of participants, faults and switches affect the consensus time. The formulas and analyses are validated with simulations. The conclusion offers some tips for analytical modeling of such protocols.

Paper Structure

This paper contains 31 sections, 19 equations, 13 figures, 1 table.

Figures (13)

  • Figure 1: Simulated consensus time for (a) HotStuff with varying number of faults ($n=16$, clique), (b) HotStuff vs IBFT on Dragonfly (${\nu_d}=5, {r^\mathcal{P}_s}=9$) and (c) HotStuff vs IBFT on Dragonfly (${\nu_d}=3$, $n=31$). The unit of time on the vertical axis follows that for message processing time at a validator (see Sec. \ref{['sec:simulator']}).
  • Figure 2: IBFT and HotStuff have very different patterns for message exchange.
  • Figure 3: Topology examples with parameters (a) ${\nu_e}=8,{\nu_{12}}=4$; (b) ${\nu_e}=9,{\nu_{12}}=3$; (c) ${\nu_d}=3$; (d) ${\nu_d}=4$.
  • Figure 4: Comparison of Eqn.(\ref{['eqn:ETHC']}) with simulation (with full round change). Vertical lines indicate ${\tau_0}^\ast$ (Eqn.(\ref{['eqn:THCrec']})). The unit of time follows that for $1/{r^\mathcal{P}_v}$ (see Sec. \ref{['sec:simulator']}).
  • Figure 5: Comparison of Eqn.(\ref{['eqn:ETIC']}) with simulation (with full round change). Leaders have a specified order in the simulation, but are randomly selected in the model. Vertical dashed lines indicate $\tau_0^\ast$ (Eqn.(\ref{['eqn:TICrec']})).
  • ...and 8 more figures