# FlexBFT: A Flexible and Effective Optimistic Asynchronous BFT Protocol
## 1 Introduction  
Blockchain technology has garnered substantial attention within the field of distributed systems primarily for its inherent ability to ensure data consistency and resist unauthorized modifications [1]. In the realm of blockchain, state machine replication (SMR) plays a pivotal role in upholding ledger consistency among blockchain nodes. In this context, Byzantine fault tolerance (BFT) protocols, which are crucial for implementing SMR, have earned significant recognition for their robust fault-tolerant properties [2]. In scenarios involving both synchronous and partially synchronous networks, BFT protocols have witnessed remarkable advancements in terms of efficiency improvements [3; 4; 5; 6]. They hold a central position in modern blockchain and distributed systems [7; 8]. These algorithms typically feature a leader node working in conjunction with multiple replica nodes, and their innovative techniques, including threshold signatures and pipelining, have significantly reduced time and message complexities, resulting in linear time complexity. Nonetheless, the groundbreaking work by [PERSON] et al. [9] has shed light on a pivotal revelation: despite their remarkable efficiency in synchronous networks, these high-performance protocols face significant challenges when confronted with the unpredictable nature of asynchronous network conditions. This complex predicament leads to a standstill in the progress of state machine replication (SMR), rendering it incapable of seamless operation. This dilemma presents a formidable challenge for blockchain protocols, given thatreal-world network environments often exhibit inherent asynchrony, be it in the realm of industrial blockchain deployments [10] or the intricate ecosystems of cryptocurrencies [11]. Consequently, the academic community has experienced a noticeable shift in focus toward asynchronous protocols, a subject that has been a continuous subject of scholarly inquiry since the 1980s. In contrast with their synchronous counterparts, asynchronous protocols function under the assumption of message eventual delivery without strict emphasis on the precise timing of message arrivals. It is worth noting that while asynchronous protocols often incorporate randomness as an auxiliary computational resource, they are capable of ensuring correctness in asynchronous network environments, albeit sometimes at the expense of reduced efficiency compared with their synchronous counterparts during normal operational conditions. To address the performance limitations of asynchronous protocols, researchers have recently introduced optimistic asynchronous protocols [12; 13; 14; 15]. These algorithms typically incorporate two distinctive paths: an optimistic path, reliant on multicast communication, and a pessimistic path, founded on complete asynchronous consensus. The optimistic path leverages multicast to operate swiftly under favorable network conditions, delivering low latency and minimal communication overhead. Conversely, the pessimistic path, rooted in asynchronous protocols, offers robustness against foreseeable errors and challenges that might impede the fast lane. While optimistic two-phase asynchronous protocols excel in synchronous networks with low complexity and offer reliability in asynchronous environments, they follow a fixed path order. In each round, the algorithm initially executes the optimistic path. In cases where the optimistic path fails to make progress, such as in asynchronous networks, it abandons this path and transitions to the pessimistic path to ensure consensus continuity. Following the completion of the pessimistic path, the algorithm recommences a new round of the fast lane as the entry point. However, adhering to this fixed path order proves detrimental, especially in fully asynchronous networks or under latency attacks. Expanding the role of the fast lane in these optimistic asynchronous protocols results in additional overhead compared with pure asynchronous protocols.