# FlexBFT: A Flexible and Effective Optimistic Asynchronous BFT Protocol
## 4 FlexBFT Design
### Back-Up Mode Protocol  
The back-up mode protocol is proposed to handle asynchronous network conditions and ensure liveness even in the presence of adversarial interference. Typically, back-up protocols for asynchronous networks directly use ABC as a black box. However, while ACS offers good throughput, it often suffers from significant latency due to the use of randomness-based methods. Recently, ParBFT [39] restructured the framework of optimistic asynchronous consensus, proposing a method that runs the optimistic path and pessimistic path in parallel and uses ABA for nodes to reach consensus on which path to choose. This method guarantees the effectiveness of asynchronous environments and ensures rapid output in good network conditions by treating the optimistic path as a fast lane. Our proposed approach also aims to make the back-up mode protocol as efficient as possible through parallel processing. However, unlike ParBFT, FlexBFT does not consider the output of the optimistic path as a signal to abort the ongoing pessimistic path since, in a sense, this would be detrimental to censorship. An adversary could manipulate the network to determine whether the consensus result for that round comes from the optimistic or pessimistic path. Moreover, in cases where the output of the optimistic path is in plaintext, the adversary could delay transactions as desired. As shown in Algorithm 3, the back-up mode protocol consists of two modules running in parallel. The first module provides the primary functionality of the back-up mode protocol, enabling it to operate successfully and produce blocks in adverse network conditions, serving as the ABC module. The second module, considering algorithm reusability, comprises the snw-ABC and pace synchronization introduced in the fast mode protocol, ensuring that even in the presence of favorable networks, it competes for block output. ```
// invoke Optimistic path
1: let \(e^{\prime}\gets 0\) be the epoch number
2: let \(Blocks_{o}\leftarrow[\big{]}\)
3: activate snw_ABC[\(e\)] instance
4:upon snw_ABC[\(e\)]delivers a BAP:
5: activate snw_ABC[\(e^{\prime}\)].retrieve[\(Proof_{p}\)]
6:upon TX\(s_{o}\) is delivered:
7:output\(pending^{\prime}_{e}\)
8:\(Blocks_{o}\gets Block_{o}+pending^{\prime}_{e}\)
9: let \(Block_{o}\) be the combination of BAP and TX\(s_{o}\)
10:\(Blocks_{o}\gets Block_{o}+pending^{\prime}_{e}\)
11:\(pending^{\prime}_{e}\gets Block_{o}\) // invoke Pessimistic path
12: let \(txs_{i}\leftarrow\) randomly select [B / n]-sized transactions from the top of buf
13: let \(x_{i}\leftarrow\) threshold-encrypted \(txs_{i}\)
14: let \(\{x_{j}\}\leftarrow\) dumbo[\(e^{\prime}\)](\(x_{i}\))
15: let \(block_{p}\leftarrow\) decrypted \(\{x_{j}\}\) // decide return fast mode protocol or not
16:upon\(block_{p}\
eq\varnothing\):
17:\(block_{p}\leftarrow block_{p}-\{TX\text{ in }Blocks_{o}\}\)
18:output\(block_{p}\)
19:if\(Blocks_{o}\
eq\varnothing\):
20: multicast RESTART(\(e^{\prime}\), \(p_{e^{\prime}}\),\(Proof_{e^{\prime}}\))
21:Upon receiving \(n-f\) RESTART(\(e\), \(p^{\prime}_{e^{\prime}}\),\(Proof^{\prime}_{e}\)):
22: invoke pace_sync[\(e^{\prime}\)], invoke fast mode protocol and wait its return to continue
23: proceed to the next epoch \(e^{\prime}\gets e^{\prime}+1\)
```  
**Algorithm 3** Back-up mode protocol  
The construction of the ABC module has many works to refer to, but most of them build ABC based on [PERSON]'s work using ACS to construct ABC. We construct the ABC module based on Dumbo as a black box, even though Dumbo may not be the optimal ACS. Considering censorship, nodes must perform threshold encryption on transactions before inputting them into the Dumbo instance and then decrypt and output them. **Optimistic output in back-up mode. ** The optimistic path in the back-up mode protocol consists of a series of snw-ABC and a final pace synchronization, similar to the construction of the fast mode protocol.