High Performance Consensus without Duplication: Multi-pipeline Hotstuff

TL;DR

Multi-pipeline HotStuff is a novel consensus protocol that enhances throughput and concurrency in permissioned blockchain by combining multiple instances to propose batches without duplication, outperforming existing protocols.

Contribution

It introduces a new multi-pipeline approach that allows simultaneous proposing and voting, significantly improving throughput and network efficiency over HotStuff.

Findings

Achieves approximately 60% higher throughput than HotStuff.

Maintains comparable latency with improved performance under poor network conditions.

Successfully reduces the delay in proposal certification process.

Abstract

The state-of-the-art HotStuff operates an efficient pipeline in which a stable leader drives decisions with linear communication and two round-trips of message. However, the unifying proposing-voting pattern is not sufficient to improve the bandwidth and concurrency performance of the modern system. In addition, the delay corresponding to two rounds of message to produce a certified proposal in that scheme is a significant performance bottleneck. Thus, this study developed a new consensus protocol, Multi-pipeline HotStuff, for permissioned blockchain. To the best of the authors' knowledge, this is the first protocol that combines multiple HotStuff instances to propose batches in order without a concurrent proposal, such that proposals are made optimistically when a correct replica realizes that the current proposal is valid and will be certified by quorum votes in the near future. Because simultaneous proposing and voting are allowed by the proposed protocol without transaction duplication, it produced more proposals in every two rounds of messages. In addition, it further boosted the throughput at a comparable latency with that of HotStuff. The evaluation experiment conducted confirmed that the throughput of Multi-pipeline HotStuff outperformed that of the state-of-the-art protocols by approximately 60\% without significantly increasing end-to-end latency under varying system sizes. Moreover, the proposed optimization also performed better when it suffers a bad network condition.