Ipotane: Balancing the Good and Bad Cases of Asynchronous BFT

of these replicas, termed Byzantine replicas, may deviate arbitrarily from the protocol. BFT consensus protocols traditionally fall into three categories based on their network assumptions: asynchronous, partially synchronous, and synchronous. Asynchronous protocols [7] , [8] , [9] ensure safety and liveness under arbitrary network conditions, whereas (partially-)synchronous protocols are prone to network attacks [10] . On the flip side, asynchronous protocols are known to be inherently randomized [11] , which makes them less efficient and more challenging to design than their synchronous and partiallysynchronous counterparts (e.g., PBFT [12] and HotStuff [13] ), which can be fully deterministic. A. Asynchronous protocols with an optimistic path To harness the strengths of both (partially-)synchronous and asynchronous protocols, a line of research has proposed incorporating an optimistic path into an asynchronous protocol [14], [15], [16], [17]. This typically involves using a partially-synchronous protocol, like 2-chain HotStuff [18] , as the optimistic path, while an asynchronous protocol, often Validated Asynchronous Byzantine Agreement (VABA), acts as the pessimistic fall-back path. This dual-path paradigm considers two situations: favorable and unfavorable. A favorable situation is characterized by a non-faulty leader on the optimistic path and good network conditions, enabling the protocol to make progress through the optimistic path. In contrast, an unfavorable situation arises when we have a faulty leader or poor network conditions, in which case the protocol will fall back to the pessimistic path to achieve liveness. Formal definitions of favorable/unfavorable situations are presented in Section V-D. The ultimate goal in this dual-path paradigm is to match the performance of a partially-synchronous protocol in favorable situations and that of a purely asynchronous protocol in unfavorable ones. While many prior works have focused on optimizing performance in favorable situations, it is also critical to address performance in unfavorable situations, as they can be common in real-world deployments. Specifically, a leader may become temporarily inoperative, or the network connecting to the leader might experience jitter, making such Abstract-State-of-the-art asynchronous Byzantine Fault Tolerance (BFT) protocols integrate a partially-synchronous optimistic path. Their ultimate goal is to match the performance of a partially-synchronous protocol in favorable situations and that of a purely asynchronous protocol in unfavorable situations. While prior works have excelled in favorable situations, they fall short when conditions are unfavorable. To address these shortcomings, a recent work, Abraxas (CCS'23), retains stable throughput in all situations but incurs very high worst-case latency in unfavorable situations due to slow detection of optimistic path failures. Another recent work, ParBFT (CCS'23) ensures good latency in all situations but suffers from reduced throughput in unfavorable situations due to the use of extra Asynchronous Binary Agreement (ABA) instances. We propose Ipotane, a protocol that attains performance comparable to partially-synchronous protocols in favorable situations and to purely asynchronous ones in unfavorable situations, in terms of both throughput and latency. Ipotane also runs two paths simultaneously: 2-chain HotStuff as the optimistic path and a new primitive Dual-functional Byzantine Agreement (DBA) for the pessimistic path. DBA packs the functionalities of biased ABA and Validated Asynchronous Byzantine Agreement (VABA). In Ipotane, each replica inputs 0 to DBA if its optimistic path is faster, and 1 if its pessimistic path is faster. DBA's ABA functionality promptly signals the optimistic path's failure by outputting 1, ensuring Ipotane's low latency in unfavorable situations. Meanwhile, Ipotane executes DBA instances to continuously produce pessimistic blocks through their VABA functionality. Upon detecting a failure, Ipotane commits the last two pessimistic blocks to maintain high throughput. Moreover, Ipotane leverages DBA's biased property to ensure the safety of committing pessimistic blocks. Extensive experiments validate Ipotane's high throughput and low latency across all situations.