A Performance Analysis of BFT Consensus for Blockchains

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

2024-11-12

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.

Performance,Distributed, Parallel, and Cluster Computing

What problem does this paper attempt to address?

This paper attempts to solve the following problems:

1. **Performance differences of consensus protocols**: What are the performance differences among different Byzantine Fault - Tolerant (BFT) consensus protocols? How are these differences affected by the communication network?

2. **Timer setting problem**: In order to ensure that the consensus protocol can continue in the event of a failure, a timer is usually set. When the timer expires, the protocol assumes that a failure has occurred and restarts the consensus process. So, how should the initial timer value \( \tau_0 \) be set to optimize performance?

3. **Impact of network topology on consensus time**: What is the impact of different network topologies (such as Folded - Clos and Dragonfly) on consensus time? Especially in the case of different message patterns, how does the network topology affect the performance of two consensus protocols (Istanbul BFT and HotStuff)?

### Specific research content

- **Consensus protocol analysis**: The paper focuses on two consensus protocols (Istanbul BFT and HotStuff) and two network topologies (Folded - Clos and Dragonfly), and analyzes the impact of factors such as timer value, number of participants, number of failures, and number of switches on consensus time by establishing an analytical model.

- **Analytical model and simulation verification**: The paper provides closed - form expressions to analyze the impact of these factors on consensus time, and verifies the correctness of these formulas through simulation.

- **Performance modeling method**: The paper proposes a method based on rough approximation and basic probability theory for performance modeling. This method is simple but effective and can provide a global - view performance analysis.

### Main contributions

1. **Performance dependencies**: Analyzed how BFT consensus time depends on the number of validators, the number of failures, the timer value, and the network topology.
2. **Protocol and topology comparison**: Compared the performance of two consensus protocols (Istanbul BFT and HotStuff) and explored the impact of two network topologies (Folded - Clos and Dragonfly) on performance.
3. **Modeling method**: Proposed an analytical modeling method for consensus protocol performance analysis.

### Conclusion

Through the performance analysis of HotStuff and Istanbul BFT under different network topologies, the paper draws some conclusions about consensus time and provides guidance for future consensus protocol modeling. For example, for HotStuff, the recommended initial timer value \( \tau_0 \) can be set according to the following formula:
\[ \tau_0=\frac{m_H}{r_H^v}+3\sqrt{\frac{m_H\sigma^2}{r_H^v}} \]
where \( m_H = 4n-3n_f - f + 4 \), \( r_H^v \) is the rate at which validators process messages, and \( \sigma \) is the standard deviation of the processing time.

This setting can ensure that the timer value is large enough to adapt to changes in processing time, thereby minimizing the timeout probability and optimizing the consensus time.