# LBFT: An Asynchronous Committee-Based Blockchain Storage Strategy on Zero Trust Model
## 4 Design  
### High-Level Overview  
To reduce the communication complexity and improve the efficiency of the system with LBFT, we partition the blocks before encoding and involve only a part of the nodes in each decoding round, on the premise that the original data are accessible by a client at any time. LBFT can be applied to blockchain systems even in asynchronous networks. Its main underlying constituent parts are _encoding and consensus_ and the _recovery of blocks_. **Encoding and Consensus. ** Illuminated by the work of BFT-Store [3], we consider the idea that the system encodes the blocks and achieves consensus on the encoded values, and then each node stores a part of encoded blocks instead of the complete ledger. To achieve consensus, we employ ACS, the principal building block of HB-BFT, meanwhile ensuring that LBFT can make progress even in an asynchronous network. To achieve less communicated bits and higher efficiency, each node first partitions the original block into several pieces before encoding. Since every packet transmitted from one peer to another is considered untrusted and required to be verified in the zero-trust model, we employ CLAS in order for the receivers to check the validity of the values. As depicted in Figure 2, the node activates the corresponding RBC instance with its set of signatures. A node \(N_{i}\) will input a bit \(b=1\) into \(ABA_{j}\) if it has received sufficient signatures on a certain value \(f_{h}(j)\). After receiving enough \(b=1\) as inputs, the ABA instance outputs the bit \(b=1\). The sign of consensus on the encoded values is that every ABA instance outputs \(b=1\). \begin{table}
\begin{tabular}{c c} \hline \hline
**Parameters** & **Descriptions** \\ \hline \(n\) & the number of nodes in the system \\ \(r\) & the fault factor of the system \\ \(f\) & the threshold of Byzantine nodes that can be \\  & controlled by the adversary \\ \(k\) & the number of committees \\ \(c\) & the number of members in each committee \\ \(l\) & the length of decode messages \\ \(T\) & the size of a block \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Descriptions of the notations mentioned in this paper. **Recovery of Blocks. ** In the previous works that combine erasure coding and BFT protocols, all the nodes are obligated to cooperate to recover the original block when the client requests data. To subvert the whole network's involvement, we construct the committee-based LBFT for lower communication complexity as well as higher computational efficiency. As shown in Figure 2, when receiving the request from a client, LBFT randomly selects a part of nodes and averagely places them into committees by Committee Election (CE) protocol. Each committee \(C_{i}\) nominates a leader \(L_{i}\) who performs the decoding operation and decides a recovered value. Similar to the encoding process, the committees achieve agreement on the final value with the help of RBC and the ABA protocol. After each committee \(C_{i}\) has decoded the original value severally, the leader \(L_{i}\) broadcasts the value through the \(RBC_{i}\) instance and inputs a bit \(b=1\) to the common ABA instance if it has received enough identical values. LBFT sends the recovered block to the client if the ABA instance outputs 1 (decode successfully); otherwise, it re-selects the committees and repeats the above operations. **Trade-off for Decoding Success Probability. ** In each decoding round, there are \(k\) committees, each composed of \(c\) members, decoding in parallel. The recovered value is considered valid only if more than half (i.e., \(\frac{k}{2}\)) of the committees have obtained this value.