LBFT: An Asynchronous Committee-Based Blockchain Storage Strategy on Zero Trust Model

Abstract

The high storage costs brought by the full-replication storage strategy adopted in most existing blockchain systems have become the main bottleneck to system scalability. To address the above, we propose an asynchronous committee-based blockchain storage strategy named lightweight BFT (LBFT), which can be applied to more diverse scenarios with better system performance. It is the first blockchain storage scheme that is designed on the conception of the zero-trust model, achieving higher-level security and fending off internal, as well as external attackers. In addition, it makes the following progress on system performance on the premise of maintaining the merits of the blockchain: (1) decreases communication complexity by involving only a part of the nodes in each decoding round; (2) enhances the robustness of the scheme regardless of the time assumption of the network; (3) improves the computational efficiency in the encoding and decoding process; and (4) reduces the storage costs and improves system scalability. In addition, we implemented experiments on LBFT and two other existing blockchain-based storage strategies, and the experimental results showed that LBFT indeed has significant improvements in system performance.

1. Introduction

The blockchain is known as a distributed ledger maintained by all the peers in the network that records the executed transactions in the form of blocks on a chronological chain [1,2]. In recent decades, the surprising success of blockchain technology has brought it into more application scenarios, including a variety of enterprise-level applications. As a result, a rapidly increasing amount of data is being stored on the blockchain, e.g., the total amount of data on Bitcoin is 400 GB, and the Ethereum blockchain generates about 0.2 GB data every day (https://www.statista.com, accessed on 11 July 2022). However, most existing blockchain systems adopt full-replication storage, constraining each node to devote a huge amount of storage space for data preservation. Undoubtedly, this seriously impairs the system performance and scalability and becomes the main obstacle to the sustainable development of blockchains.

To address the above, much attention and effort has been put into reducing storage overheads while ensuring the security and consistency of the stored data. Recently, the work [3] proposed a reliable storage scheme named BFT-Store, which combines the practical Byzantine Fault Tolerance (PBFT) protocol with Erasure coding (ES) to decrease the storage consumption and improve the scalability of the system. It overturns the traditional full-replication storage strategy; however, there still remain some defects to be improved.

On the one hand, BFT-Store is designed for a permissioned blockchain based on the traditional security model, requiring authentication on nodes and restricting the permissions of the nodes, so that it weakens the decentralization of the system to some extent. Nevertheless, decentralization is one of the most favorable aspects of blockchain technology, which prevents parties from disclosing information to a centralized third party or leaving traces that might be utilized by attackers [4]. In contrast, a public blockchain is more decentralized, in which any node can join the system without authorization and has equal access to its resources. Additionally, BFT-Store employs the Threshold Signature (TS), which depends on a certain Trusted Third Party (TTP) or a center node (i.e., dealer) to deliver the keys, which is contradictory to decentralization and increases the risk of key disclosure, increasing the risk of attacks on the TTP.

On the other hand, except for the conventional consensus phase, the additional ES encoding and decoding processes, which involve all the peers, inevitably degrade the system performance (e.g., increase the communication bits and response time) to a certain extent.

To address above, we consider improvement from two aspects: (1) how to strengthen the decentralization of the system as much as possible; (2) how to avoid the loss of system performance caused by abandoning the full-replication strategy.

Firstly, to enhance decentralization, we aim to design a storage strategy that is based on a higher-level security model, known as the zero-trust model. Instead of focusing on perimeter defenses in the traditional trust model, it labels all the network traffic as untrusted and requires strict verification, regardless of whether the packets are transmitted from internal or external networks. Additionally, we employ a Certificateless Aggregate Signature (CLAS) scheme, which eliminates the reliance on the TTP to generate, store, and update the keys of the nodes.

Secondly, inspired by a committee-based protocol named SCP [5], placing the nodes in different committees and running an internal consensus protocol within each committee concurrently, we propose a feasible solution in which only a part of the nodes is involved in each decoding round for data access. To further reduce the communication and computational complexity, we partition the original blocks before encoding. To address the above, we propose an asynchronous storage strategy for the public blockchain named lightweight BFT (LBFT), which is the first blockchain storage strategy that can adapt to the zero-trust model.

1.1. Our Contributions

To relieve the storage pressure, two blockchain storage strategies combining erasure coding and BFT protocols, BFT-Store and PartitionChain, have been proposed previously. Based on this idea, we construct LBFT, an improved storage strategy for the public blockchain, which combines Reed–Solomon (RS) coding and the HoneyBadger-BFT (HB-BFT) protocol. Compared to BFT-Store, LBFT has significantly better computational and communication efficiency, and compared to PartitionChain, LBFT trades a small loss of efficiency for greater liveness towards the network situation and node faults. The detailed comparison of the performance is presented in

Table 1. The comparison of the performance between LBFT and BFT-Store.

	LBFT	BFT-Store	PartitionChain
Security Model	Zero-Trust Model	Traditional Trust Model	Traditional Trust Model
Time Assumption	Asynchronous	Partially Synchronous	Partially Synchronous
Participants in Dec	Committees	Whole Network	Whole Network
Communication Complexity	$O(k^2·T+k·c·l)$	$O(n^2·T+n·l)$	$O(n·t+n·l)$
Complexity in Enc	$O(n·\frac{T^2}{c})$	$O(n^2·T^2)$	$O(n·T·t)$
Complexity in Dec	$E·O(k·c·T^2)$	$O(n^3·T^2)$	$O(n^2·T·t)$

, where t is the fixed size of the block partitions in [6] and is usually less than $\frac{1}{2^{10}}$ of the original block size T.

Compared to the previous works, the most significant innovations of the LBFT include the two following aspects:

• Completely decentralized: LBFT is designed on the basis of the conception the zero-trust model, which assumes that all network traffic is untrusted [7,8]. In LBFT, all the messages transmitted on the network are inspected and verified before use by the receivers regardless of previous authority or authentication, which avoids authentication but not verification in the traditional trusted models. Moreover, LBFT deploys a CLAS scheme [9], in which the key generation center only delivers partial private keys in the initialization phase of each party and no longer participates in system operation.
• Committee-based decoding: In LBFT, only a random part of the nodes divided into several committees participate in the decoding process, to recover the requested data. It can be seen from Table 1 that, in BFT-Store, which requires all the parties to perform decoding, an $O\left(n^2\right)$ level of communication complexity (where n is the number of nodes) is incurred, while the communication complexity of LBFT is merely $O(k·c·l+k^2·T)$ (where k is the number of committees, c is the number of members in each committee, l is the decoded message length, and T is the size of a block).

In addition, we aim to make LBFT suitable for more large-scale and complex application scenarios without a pre-set time assumption. We also focus on minimizing the performance loss, including the computational costs, brought by the additional decoding process in comparison with the conventional blockchain system, which adopts the full-replication strategy. More formally, the major advantages and characteristics of LBFT are listed in detail as follows:

• LBFT is a blockchain storage strategy that obtains higher robustness than BFT-Store and PartitionChain and that is still workable even in scenarios with large geographical ranges and unpredictable network situations. In addition, due to the elimination of a time-bound, the parties will make progress as soon as the messages are delivered, leading to a shorter latency in LBFT.
• LBFT is a combination of RS coding and the HB-BFT protocol, which enables each node to store merely a part of encoded blocks rather than a complete ledger in order to decrease storage consumption and improve system scalability. Moreover, as shown in Table 1, original blocks are partitioned before encoding, which will reduce the computational complexity of encoding and decoding from $O(n^2·T^2)$ level to $O(\frac{T^2}{c}·n)$ and $E·O(k·c·T^2)$, respectively, where E is the expected decoding rounds of recovering a block, which will be illustrated in Section 5.

1.2. Related Work

Storage boosting. As mentioned before, an increasing amount of data is stored on the blockchain, causing severe storage redundancy, and many solutions have been proposed. Various distributed storage systems have been introduced. StorJ and IPFS [10,11] are popular distributed storage schemes that improve traditional storage systems and obtain better performance. Moreover, some strategies, such as Merkle-Tree, light-node, and lightening networks, are proposed, aiming to decrease the amount of information stored on the chain [12,13,14,15,16]. Nevertheless, these schemes merely decrease the amount of data that need to be stored in full-replication or the number of nodes of full-replication (i.e., full nodes), which does not fundamentally overturn the full-replication storage strategy.

The recently proposed BFT-Store offers a brand new idea that combines erasure coding with the PBFT protocol, enabling each node to store merely a part of the encoded blocks [3]. Soon afterward BFT-Store was proposed, PartitionChain [6] improved its encoding strategy and achieved higher efficiency while also maintaining low storage overheads. Inspired by this exciting innovation, we propose LBFT, which has better robustness and wider applications. In the design of LBFT, we mainly consider improving system performance from three aspects: security model, time assumption of the network, and participants dedicated to decoding.

Traditional security model or zero-trust model. In recent decades, the traditional perimeter-based security model was widely used in the world of information security, which contains at least one trusted port and another untrusted port [7]. Nevertheless, in the real world, it is scarcely possible for security professionals to identify which interfaces can be trusted. Worse still, in the position of trust, malicious insiders who have broad access to corporate resources might commit a crime or act insidiously, causing information disclosure and severe economic loss with ease.

To address the above and achieve higher-level security, a disruptive model termed the zero-trust model is proposed, focusing on protecting system resources regardless of the location parameters. The elegant work of [17] clarifies the indispensable requirements of implementing a zero-trust model: (1) all network traffic needs to be encrypted regardless of the topological location of the network; (2) access to the system resources is authorized dynamically on a per-connection basis, and it will not automatically permit access to another different resource.

On the other side, BFT protocols are the fundamental mechanisms of the consensus on proposed transactions in blockchain systems, enabling untrusted peers to reach an agreement on an eventual output based on their respective inputs against Byzantine nodes [18,19]. According to different design goals and application scenarios, the BFT protocols are constructed in diverse flavors.

Synchronous or asynchronous BFT protocols. According to the time assumption of the system model, the BFT protocols can be divided into three categories: synchronous, partially synchronous, and asynchronous.

In the earlier years, considering that the scale of the network is small and the peers are geographically close and well-connected, the designed BFT protocols always have a synchronous time assumption [20]. Dfinity, for instance, is a four-layer synchronous BFT protocol that contains a randomness beacon acting as a verifiable random function (VRF), which produces a stream of consensual outputs [21]. Another well-known synchronous protocol is Sync HotStuff, an intuitive synchronous BFT solution that can achieve consensus with a latency of $2\mathsf{\Delta }$ in time assumption (where $\mathsf{\Delta }$ is the delay upper bound) [22].

With the development of the Internet, the application scenarios of BFT have become more diverse and complicated, so lots of effort are put into relaxing the time assumption. The Practical Byzantine Fault Tolerance (PBFT) protocol only requires that the messages will be delivered within $\mathsf{\Delta }$ after a global stabilization time (GST) and tolerates up to $\lfloor \frac{n}{3}\rfloor$ (where n is the number of nodes) Byzantine faults [23]. In addition, the classic protocol HotStuff is also a notable example of a partially synchronous protocol [24]. Aardvark shifts the focus from improving peak throughput to maintaining acceptable and predictable protocols even when Byzantine faults occur.

Due to the successful application of blockchain technology, BFT protocols have been applied in a wider area, and their design goal shifts to further relax the time assumption. The network connection may be unreliable, and the delay may be time-varying [1]. Various works construct asynchronous BFT protocols that can make progress even if the time assumption does not hold. The notable HoneyBadger-BFT and Dumbo can achieve consensus in an asynchronous network but suffer from a relatively high communication complexity [25,26].

In addition to robustness, asynchronous protocols always have a higher efficiency compared with synchronous protocols. Generally, synchronous BFT protocols are parameterized by an assumed network latency, which is much larger than the actual one, and obviously the efficiency of these protocols depends on the pre-set latency [26]. On the contrary, asynchronous protocols are more efficient because they make progress as soon as the messages are delivered, without relying on any time bound.

Whole-network or committee-based BFT protocols. The majority of existing BFT protocols require the whole system to broadcast and verify the inputs so that the system can eventually achieve consensus on the output. As a consequence, these protocols always suffer from high communication complexity. The first practical asynchronous BFT protocol, HoneyBadger-BFT, has $n^2$ or even $n^3$ terms in communicated bits [25]. Another notable protocol, multi-valued validated Byzantine agreement (MVBA), also achieves $O(L{n}^2+\lambda n^2+n^3)$ (where L is the input length, and $\lambda$ is the security parameter) in [27] in communication complexity. To reduce communication, several improved protocols are constructed, but they do not radically overturn the whole network involved in consensus and just mildly reduce the number of communicated bits [27,28].

On the other hand, whole-network participation also results in a low efficiency for two reasons: (1) some of the broadcast protocol instances may terminate very slowly due to the unstable network, so the subsequent operations will be delayed; (2) the large scale concurrent execution will sharply degrade efficiency [29]. To address the above, many committee-based schemes have been proposed. Chen et al. design several committee-based frameworks and algorithms for energy trading systems by combining a hierarchical-optimization scheme with blockchain technology, to replace the traditional coordination center with a delegation consisting of several chosen participants [30,31,32].

In addition, the previous works [10,33] propose an improved delegated Proof-of-Stake (DPoS) scheme and related election mechanism, in which only a part of nodes can be the candidates of the delegation responsible for generating and verifying blocks, thus achieving higher effectiveness and security than PoW and PoS mechanisms. In contrast to the execution of n ABA instances in HoneyBadger-BFT, Dumbo-1 selects K out of n parties (where K is a security parameter independent of n) and lets them execute the ABA protocol to decrease the running time from $O(logn)$ to $O(logK)$ [25,26,34]. In another committee-based BFT protocol, SCP [5], the parties are randomly divided into different committees and each committee runs an internal consensus protocol in parallel, to reach higher efficiency.

1.3. Organization

The rest of this paper is organized as follows:

Section 2 introduces the assumed system model and the design goals of LBFT. Section 3 illustrates the fundamental knowledge and techniques involved in the construction of LBFT. Section 4 elaborates the design of the consensus block and the decoding block in LBFT. Section 5 analyzes the communication complexity and computational efficiency and Section 6 evaluates the practical performance of LBFT through experiments. Section 7 concludes this paper.

2. System and Problem Statement

2.1. System Model

Asynchronous Network. We assume that any two nodes in the system are connected by asynchronous, fully meshed, authenticated point-to-point (P2P) channels. In this model, the adversary can arbitrarily delay the messages sent by the honest nodes, but they will be eventually delivered. This means two things: (1) all the messages sent from the honest nodes will not be dropped, and (2) they might be reordered by the adversary at will.

Threat Model. In our system model, any node from the internet can join or leave the system without approval or authentication. There exists a round-adaptive Byzantine adversary, which can arbitrarily control the nodes at the beginning of each round to behave maliciously (e.g., forge and drop the messages), in order to impede the system to achieve consensus. In such a system with $n=r·f+1$ nodes, the adversary can corrupt up to f Byzantine nodes (where r is the fault factor satisfying that $r\ge 3$).

Zero-Trust Model. We assume our system model is a practical application of the concept Zero Trust, removing the definitions of trusted networks (usually the internal networks) and untrusted networks (external networks) [35]. As a result, all the network traffic is considered threat traffic, even if the channels and devices are authenticated. Hence, the packets need to be verified that they are indeed inspected, authorized, and secured before access because the information in the packets cannot manifest the veracity of the asserted identities. To ensure system security in such a model, the following requirements are necessary [8]:

• Ensure that all the resources are accessed securely, no matter where they originate from or who create them;
• Adopt a least privilege strategy to reduce the likelihood for people to behave maliciously, and enforce access control strictly to protect access to restricted resources;
• Inspect and log all the network traffic, flipping the mantra trust but verify into verify and never trust.

2.2. Design Goals

LBFT is constructed as an asynchronous committee-based storage strategy for the blockchain. We consider its strengths and functionalities listed in detail in Section 1 from the following aspects:

1

Decentralization and Security. To carry forward the conception of decentralization, we should eliminate the reliance on a certain third trust party during the whole operation process of LBFT as far as possible. For system security, all the network traffic should be inspected and logged, and the transmitted values should be verified before they are accessed and operated. Access to certain resources and applications should also be strictly enforced [36].

2

Frugal Communication. LBFT is constructed on a zero-trust model. Moreover, in the previous work BFT-Store, suffering from $O\left(n^2\right)$ communication complexity in the decoding process, we aim to construct a protocol that can remove the $O\left(n^2\right)$ term during each decoding round, on the premise that the system can recover the original block successfully for client requests.

3

Robustness. Unlike the synchronous schemes that can only be applied to the relatively private and well-connected networks, we hope that LBFT can suit more large-scale, manifold, and unstable networks and can make progress even if the timing assumption of message delivery does not hold.

4

Efficiency. To make LBFT an efficient strategy, we have twofold expectations: (1) minimize the loss of performance resulting from the extra encoding and decoding rounds (compared to the primordial blockchain storage scheme); (2) free the nodes from the constraint of the pre-set timing assumption, so that they can respond immediately after the messages are delivered.

5

Scalability. We expect that LBFT, which is designed to be deployed in promising blockchain systems, can improve the system scalability as well as maintain the original functionalities of the blockchain. In LBFT, the storage costs of the blocks should maintain a constant level in regard to the number of nodes n in the system, on the premise that the data stored on the chain is consistent and accessible at any time.

3. Preliminaries

3.1. Methods and Technologies

In this section, we introduce the technologies utilized in the construction of LBFT.

Reliable Broadcast (RBC) is a broadcast protocol, in which a node termed sender who aims to broadcast a message successfully to all the other nodes [37]. An RBC protocol has the following guarantees:

• Agreement. If any two honest nodes output the values v and v’, respectively, then v = v’.
• Totality. If one honest node outputs the value v, then all the honest nodes will output v.
• Validity. If the sender is honest and it inputs the value v to the protocol, then all the honest nodes will output v.

Asynchronous binary agreement (ABA) is an asynchronous Byzantine agreement protocol, in which each node inputs a single-bit (0/1), and their goal is to reach an agreement on the output bit [38,39]. An ABA protocol should satisfy the following properties:

• Agreement. If any honest node decides a bit b, then every honest node will decide the bit b.
• Validity. If any honest node decides a bit b, then at least one honest node has received the bit b as input.
• Termination. If all the honest nodes receive a bit as input, then every honest node will decide a bit.

HoneyBadger-BFT (HB-BFT) is the first practical asynchronous BFT protocol in which the nodes eventually achieve consensus on a subset of their inputs. The main underlying building block of HB-BFT is the asynchronous common subset protocol (ACS) [40], constituted with n RBC instances to have each node propose its input and n ABA instances to decide an eventual output for each proposed value. It has been proven to satisfy the agreement and total order properties except for negligible possibility in [25].

As shown in Figure 1, each node first activates an RBC instance by inputting a selected batch of transactions as the proposed value, and then the RBC instances broadcast the values to the whole network. If a node $P_i$ has received the value from another node $P_j$ through the instance $RB{C}_j$, it takes 1 as the input to activate the corresponding $AB{A}_j$ instance. After receiving $n-f$ values (where f is the number of Byzantine nodes), the node inputs 0 into the remaining ABA instances. The ACS ensures that all the nodes output the same value.

Reed–Solomon (RS) Coding is a widely-applied Erasure Coding (EC). For an original message

$$m=(m_0,m_1,\dots ,m_{k-1}),$$

$(k,n)$-RS firstly generates a specific polynomial, where $X\in \{1,2,\dots ,n\}$,

$$f_m\left(X\right)=\sum _{i=0}^{k-1}{m}_i{X}^i.$$

The message pieces are encoded by evaluating the polynomial with n distinct evaluation points from a finite field $F_q$ (where $k\le n\le q$):

$$RS\left(m\right)=(f_m\left({\alpha }_0\right),f_m\left({\alpha }_1\right),\dots ,f_m\left({\alpha }_{n-1}\right)).$$

Each node $N_i$ calculates and maintains its corresponding encoded value $f_m\left({\alpha }_i\right)$. A node can recover the original message so long as it receives random k of the n values [41]. In detail, the node substitutes the k received values for $f_m\left(X\right)$, and the k corresponding evaluation points $\{{\alpha }_0$, …, ${\alpha }_{k-1}\}$ for X to obtain a k-element linear equation set as follows:

$$\left\{\begin{array}{cc}{m}_0+m_1{\alpha }_1+m_2{\alpha }_1^2+\dots +m_{k-1}{\alpha }_1^{k-1}=f_m\left({\alpha }_1\right)& \\ ⋮& .\hfill \\ m_0+m_1{\alpha }_k+m_2{\alpha }_k^2+\dots +m_{k-1}{\alpha }_k^{k-1}=f_m\left({\alpha }_k\right)\end{array}\right.$$

Intuitively, the solutions $(m_0,m_1,\dots ,m_{k-1})$ of this equation set are the original message.

The Certificateless Aggregate Signature Scheme (CLAS) is designed on the foundation of Schnorr Signature [42]. For n users $u_1,u_2,\dots ,u_n$, their identities are respectively $I{D}_1,I{D}_2,\dots ,I{D}_n$; the n corresponding public keys are $p{k}_1,p{k}_2,\dots ,p{k}_n$; and the certain system state information is $\delta$. CLAS compresses the n signatures ${\sigma }_1,{\sigma }_2,\dots ,{\sigma }_n$ by these users on messages $m_1,m_2,\dots ,m_n$ into a single signature $\sigma$ with constant length [9]. In addition, CLAS provides a verification algorithm to make a verdict on whether the signature $\sigma$ is valid.

Compared to traditional signature schemes, CLAS has two prominent advantages: (1) it enables the parties to generate their complete keys without a TTP in the initialization phase, and dynamically update their keys by themselves when the system status changes, and (2) it reduces the total length of the signatures and the improves the computational efficiency for signature verification [43].

3.2. Related Parameters

To provide a clear illustration, we present the principal parameters mentioned in this paper and their corresponding descriptions in

Table 2. Descriptions of the notations mentioned in this paper.

Parameters	Descriptions
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

.

4. Design

4.1. 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 $AB{A}_j$ if it has received sufficient signatures on a certain value $f_h\left(j\right)$. 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$.

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 $RB{C}_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. We employ the $(c,n)$-RS scheme in LBFT, and hence, the probability $\mathcal{P}$ that the recovered block is valid can be expressed approximately as follows:

$$\mathcal{P}={\left(\frac{C_{n-f}^c}{C_n^c}\right)}^{\frac{k}{2}}={\left[\frac{(n-f-c+1)···(n-c)}{(n-f+1)···n}\right]}^{\frac{k}{2}}.$$

We can infer that the member of each committee c and the fault factor r are the dominating factors influencing the probability of decoding success. The smaller c is, or the greater r is, the higher the probability of decoding success will be. Thus, when designing LBFT, we need to balance the storage consumption (depends on c), the threshold of fault tolerance (depends on r), and the probability of decoding success, based on different application scenarios. In addition, we introduce some other methods to increase the probability of decoding success $\mathcal{P}$ in a later section.

4.2. Detailed Construction

The construction of LBFT is elaborated in this section. We assume an asynchronous network with $n=r·f+1$ nodes (where r is the fault factor, f is the threshold of the Byzantine nodes, and n is the number of nodes), and more assumptions are illustrated in Section 2.

Encoding and Consensus. Similar to the HB-BFT [25], LBFT employs the critical building block ACS to achieve consensus; nevertheless, the original blocks are partitioned and encoded before reaching agreement. Algorithm 1 presents the details of encoding and consensus process in LBFT for a certain block B(h) with hash h, which is implemented on a node $N_s$.

Algorithm 1 Encoding and Consensus in LBFT.

Input: node $N_s$, original block $\mathcal{B}\left(h\right)$ 1: $\mathcal{B}=\{{\mathcal{B}}_1\left(h\right),\dots ,{\mathcal{B}}_c\left(h\right)\}\leftarrow$ Partition($\mathcal{B}\left(h\right)$, c) 2: fori from 1 to n do 3:     $\mathcal{F}=\mathcal{F}\cup \{f_h\left(i\right)\leftarrow$ RSEncode($\mathcal{B}$, c, n, i) } 4:     $\mathcal{H}\leftarrow \mathcal{H}\cup$ Sign($f_h\left(i\right)$, s) 5: end for 6: activate $RB{C}_s$ with the input $\mathcal{H}$ 7: if receive f + 1 messages then 8:     ${\mathcal{H}}_1,\dots ,{\mathcal{H}}_{f+1}\leftarrow f+1$ signature sets 9:      $signs\leftarrow \{{\mathcal{H}}_1\left[f_h\left(s\right)\right],\dots ,{\mathcal{H}}_{f+1}\left[f_h\left(s\right)\right]\}$ 10:     ${\sigma }_{h,s}\leftarrow$ Aggregate(signs) 11:     for i from 1 to n do 12:         if more than f + 1 valid signatures on $f_h\left(i\right)$ then 13:            activate $AB{A}_i$ with the input b = 1 14:         else 15:            activate $AB{A}_i$ with the input b = 0 16:         end if 17:     end for 18:     store ${\sigma }_{h,s}$ together with $f_h\left(s\right)$ 19: end if

For the original block $B\left(h\right)$, each node $N_s$ first partitions it into c data pieces $\mathcal{B}=\{{\mathcal{B}}_1\left(h\right),\dots ,{\mathcal{B}}_c\left(h\right)\}$ using the function $Partition\left(\right)$ to decrease the computational complexity and number of communication bits during encoding and decoding (Line 1) [3,6]. Then, node $N_s$ encodes the pieces into n values: $\mathcal{B}=\{f_h\left(1\right),\dots f_h\left(n\right)\}$ within the $(c,n)$-RS schema through function $RSEncode\left(\right)$ and meanwhile signs each encoded piece (Line 2–5). After that, node $N_s$ acts as the sender to activate the corresponding $RB{C}_s$ instance with the input signature set $\mathcal{H}$ (Line 6).

If Node $N_s$ has received $f+1$ messages from other different nodes and has affirmed that the signatures are valid, it informs others which values are signed by enough nodes through the ABA protocol and aggregates the signatures into a single aggregate signature (Line 7–19). In more detail, node $N_s$ firstly extracts the $f+1$ signatures on the value $f_h\left(s\right)$ which it needs to store from the signature sets: ${\mathcal{H}}_1,\dots ,{\mathcal{H}}_{f+1}$, respectively (Line 8–9); it then compresses them into a single signature with the function $Aggregate\left(\right)$ (Line 10).

To achieve consensus on the encoded values, node $N_s$ inputs b = 1 to $AB{A}_i$ instance after it collects at least f + 1 signatures from different nodes on the value $f_h\left(i\right)$ (Line 12–13); otherwise, it inputs b = 0 to $AB{A}_i$ instance (Line 14–15). The $AB{A}_i$ instance outputs b = 1 if it has received at least f + 1 inputs b = 1, indicating that a majority of nodes have verified the value $f_h\left(s\right)$. After the consensus of all the encoded values is achieved, each node $N_s$ preserves the corresponding value $f_h\left(s\right)$ together with the aggregate signature ${\sigma }_{h,s}$ as the proof, discarding the other redundant data (Line 18).

Recovery of Blocks. When a client requests to access data, LBFT randomly selects $c·k$ nodes, averagely placing them into k committees. Each committee nominates a leader (by some algorithms such as Round-Robin scheduling [44]) to be in charge of the decoding process, while the remaining nodes in the committee are termed followers. Figure 3 presents the details of the internal decoding process in each committee. The committees perform the decoding in parallel in order to further shorten system response time. After completing the decoding process, each leader inputs the recovered value of its committee into ABA protocol for the next consensus.

The detailed steps of decoding a certain block B(h) in each committee and the consensus on the final output among the committees are illustrated in Algorithm 2. Firstly, as shown in Figure 3, the leader $L_i$ of a committee $C_i$ broadcasts a decode message $<DECODE,h,c,n,id>$ to the followers in $C_i$, where c and n are the principal parameters of the related RS scheme, and id is the unique identity of the committee (Line 2).

Algorithm 2 Data Recovery of a Certain Block.

1: (Processing on leader $L_i$ of Committee $C_i$) 2: broadcast decode message $<DECODE,h,c,n,id>$ to the followers 3: if receive $c-1$ messages then 4:     $\mathcal{F}=\{f_h\left(1\right),\dots ,f_h\left(c\right)\}\leftarrow c$ values 5:     ${\mathcal{B}}_i\left(h\right)\leftarrow$ RSDecode($\mathcal{F},c,n,id$) 6:     broadcast the recovered value ${\mathcal{B}}_i\left(h\right)$ 7: end if 8: if receive $\frac{k}{2}+1$ same recovered values $\mathcal{B}\left(h\right)$ then 9:     activate $ABA$ with the input $b=1$ 10: else 11:     activate $ABA$ with the input $b=0$ 12: end if 13: if receive the output $b=1$ from $ABA$ then 14:     return $\mathcal{B}\left(h\right)$ 15: else 16:     decoding failure, LBFT re-organize committees 17: end if 18: (Processing on followers $N_s$) 19: if receive the decode message then 20:     $msg\leftarrow <f_h\left(s\right),{\sigma }_{h,s},h,s,id{>}_{{\sigma }_s}$ 21:     SendMessage($L_i,msg$) 22: end if

Receiving the decode message from the leader, each follower $N_s$ replies with its stored value $f_h\left(s\right)$, the aggregate signature ${\sigma }_{h,s}$, the hash of block h, its index s, and the identity of the committee id to the leader $L_i$ (Line 18–22).

The leader $L_i$ computes the recovered value ${\mathcal{B}}_i\left(h\right)$ using the function $RSDecode\left(\right)$ if it has received all the encoded values from different followers in committee $C_i$ and broadcasts the value to the leaders of other committees (Line 3–7). If the leader $L_i$ receives more than $\frac{k}{2}$ of the same computed values ${\mathcal{B}}_i\left(h\right)$ (i.e., a majority of committees have recovered the same value), it activates the common $ABA$ instance with the input b = 1; otherwise, it inputs b = 0 (Line 8–12).

The common ABA outputs b = 1 if it has more than a half inputs are b = 1. If ABA instance outputs b = 1, indicating the recovered value ${\mathcal{B}}_i\left(h\right)$ is correct unless a negligible possibility $\epsilon$, LBFT replies ${\mathcal{B}}_i\left(h\right)$ to the client (Line 13–14). Oppositely, LBFT will re-select nodes to form new committees and repeat the above steps until the correct value is recovered (Line 15–17).

4.3. Committee Election

According to the aforementioned design details, the system will form k committees before each decoding round. To achieve this, we deploy Committee Election (CE) protocol [26], which will terminate with k specified size committees as long as more than f + 1 honest nodes participate. In LBFT, we further improve the selection strategies during committee election to increase the probability of successful decoding.

On one hand, some honest nodes will be crashed for any reason (e.g., equipment failure, network connection failure) and not make progress, causing a standstill or failure of the protocol. To avoid this and minimize the failure probability of decoding, LBFT checks the status of the nodes in a timely manner and randomly selects the nodes with normal states to form committees.

On the other hand, LBFT introduces a malicious behavior inspection mechanism, in which each node in the system gains its credit dynamically according to the contributions it has made to push forward the protocol. To achieve this, each node maintains an array to store the credits of all the nodes and dynamically updates the array if it detects some misbehaviors. Note that the recorded credits can also be verified with CLAS and reach consensus by all the nodes, which is illustrated in detail in [6]. The nodes whose credit is lower than the lower bound will be regarded as malicious nodes while the others are considered honest nodes. When organizing the committees to be involved in decoding, LBFT checks the credits of the nodes and gives preference to those honest nodes.

4.4. Adapting to the Zero-Trust Model

In our system model mentioned in Section 2, we construct LBFT in a zero-trust model, in which all the system resources and packets are assumed threatening by default unless they are verified to be inspected, authorized, and secured [8]. To achieve this, all the received values are verified by the receivers through the CLAS in LBFT. Moreover, the key technologies to support the implementation of the zero-trust model on LBFT are depicted in Figure 4.

It can be seen that there are two layers in the architecture; in the control plane, the core and supporting components collaborate to manage the access, while in the data plane, the users and/or devices establish connections with resources and/or data through Policy Enforcement Point.

There are three core components in the architecture of the zero-trust model responsible for enabling the users or devices to access resources and data successfully.

The Policy Engine makes decisions to grant permission for users or devices to certain system resources or data. In addition, it calculates and assigns different confidence levels to the users and devices.

The Policy Administrator is responsible for establishing and maintaining the connection between a user or device and certain system resources or data during the access.

The Policy Enforcement Point monitors the connections between a user or device and certain system resources or data and eventually terminates the connection after this access is complete.

In addition, we also adopt four supporting components, to guarantee the tenets and requirements of zero-trust in the whole access process. Among them, the NAV system and RBAC system are key components, which will be described in detail.

The Continuous Diagnostics and Mitigation (CDM) System gathers information and parameters about the current state of the resources and data from the NAV system and updates the related records in configuration settings.

Threat Intelligence collects newly discovered attacks and/or vulnerabilities in the packets from internal and/or external sources and then reports to the Policy Engine, as a basis for making access decisions.

The Role-based Access Control (RBAC) System is a standard technology that is well-suited to prevailing business and technology trends. In LBFT, we deploy the basic model $RBA{C}_0$ [45].

The users are dynamically placed into various roles, and the Policy Engine designates different permissions to certain resources based on the roles to avoid abuse of the resources and data in the system.

The Network Analysis and Visibility (NAV) System is a set of diverse tools used to supervise, log, and analyze the network traffic [7]. It collects and records the information in the network, for other components to further operate and analyze. It has two main functions, as follows:

• Provide real-time information on the network situation. The NAV system helps the core components to learn what is going on and to decide the permissions to resources or data for users.
• Give caution to the potential malicious nodes. The deployment of NAV can warn both the inside and outside individuals that their behavior is under supervision so that they will be less tempted to behave maliciously, which lessens the potential malicious behaviors and attacks to some extent.

5. Performance Analysis

5.1. Communication Complexity

When we construct LBFT, we focus on improving the decoding phase to significantly reduce the communicated bits by introducing the concept of a committee. In the consensus phase, we just partition the blocks before encoding to decrease the communication complexity slightly. Hence, in this section, we emphatically analyze the communication complexity in the decoding phase. As illustrated in Figure 2 and Figure 3, we can see that in each decoding round, there is:

1

k$one-to-c$ round: leader $\stackrel{decode}{⟶}$ followers, generating a total of $O(k·c)$ l-bit decode messages (where l is the length of decode message);

2

k$c-to-one$ round: followers $\stackrel{f_h\left(i\right)}{⟶}$ leader, incurring $O(k·c·\frac{T}{c})$ communicated bits altogether (where T is the average size of an original block);

3

a $k-to-k$ round: committees $\stackrel{B_i\left(h\right)}{⟶}$ committees, transmitting $O\left(k^2\right)$ recovered blocks of size T;

4

a $one-to-k$ round: committees $\stackrel{0/1}{⟶}$ ABA instance, where the leader of each committee (i.e., k committees altogether) inputs one bit to the common ABA instance;

5

a $k-to-one$ round: ABA instance $\stackrel{0/1}{⟶}$ committees, where the common ABA instance broadcasts a one-bit result to every committee.

Hence, the communicated bits of the decoding process in LBFT can be deduced as follows:

$$O(k·c·l)+O(k·c·\frac{T}{c})+O(k^2·T)+O\left(k\right)+O\left(k\right)=O(k·c·l+k^2·T),$$

Compared to BFT-Store, apparently, the $O\left(n^2\right)$ term has been eliminated in communication complexity in LBFT.

5.2. Computation Efficiency

The computation efficiency of coding is greatly improved in LBFT through partitioning an original block into smaller pieces before encoding, compared to other coding-applied blockchain systems [3,46]. In this section, we present the computational complexity in encoding and decoding in LBFT.

For a (c, n)-RS schema, the computational complexity in encoding and decoding are:

$$ERS\left(c\right)=O(c·n),$$

(1)

and

$$DRS\left(c\right)=O\left(c^3\right).$$

(2)

Assume that the average size of an original block is T; thus, the computational complexity of encoding a block in LBFT can be deduced from Equation (1) as follows:

$$O({\left(\frac{T}{c}\right)}^2·ERS\left(c\right))=O({\left(\frac{T}{c}\right)}^2·c·n)=O(n·\frac{T^2}{c}).$$

In recovery of a block, the k committees compute a recovered value several times in parallel; that is, the decoding process will be performed k times concurrently. Thus, the computational complexity of a single decoding round can be reckoned from Equation (2) as follows:

$$O(k·{\left(\frac{T}{c}\right)}^2·DRS\left(c\right))=O(k·{\left(\frac{T}{c}\right)}^2·c^3)=O(k·c·T^2).$$

(3)

As mentioned in Section 4, however, there exists a probability that the decoding fails since more than half the committees are dominated by malicious nodes. Considering this, the expected decoding rounds E might be calculated as:

$$E=\sum _{i=1}^{N}i·\mathcal{P}·{(1-\mathcal{P})}^{i-1},$$

(4)

where $\mathcal{P}$ is the probability that a block is successfully recovered, elaborated in Section 4. Combining Equations (3) and (4), we can compute the expected computational complexity of decoding in LBFT as:

$$E·O(k·c·T^2).$$

In comparison, BFT-Store incurs higher computational complexity for two reasons: (1) it encodes every f + 1 blocks into n chunks without any data partitioning, which brings about the large computing scale of encoding and decoding; (2) it has to recover f + 1 blocks even if the client merely requests for one, preserving redundant computational work. Deduced from Equations (1) and (2), the computational complexity of encoding and decoding respectively reaches $O(n^2·T^2)$ and $O(n^3·T^2)$. Obviously, the $O\left(n^2\right)$ term is removed from the computational complexity in LBFT, where c is much less than n (e.g., in a system with n = 10,000 nodes, the number of members c in each committee may be 100) and k is a small number (e.g., 10).

6. Experimental Evaluation

6.1. Experimental Parameter Setting

We implement LBFT Partition Chain and BFT-Store to comprehensively evaluate their performance by comparing their latency and throughput. We use the zfec library to implement RS coding and adopt LevelDB for data persistence. In all experiments, each node is equipped with 16 CPU cores with 2.10 GHz, 96 GB RAM, and 3 TB disk space; the network bandwidth is 1 Gbps.

The security parameters and system initial state are the same as [3]. We select the case that the faulty factor of the system r = 3 and the number of replicas of each block equals 1 in BFT-Store. In LBFT, since the number of nodes in the experiments is much less than in practical application scenarios, we set the number of members of each committee $c=\lfloor \frac{n}{10}\rfloor$.

6.2. Storage Consumption

To evaluate the storage consumption of LBFT, we also conduct experiments on the full replication strategies, PartitionChain and BFT-Store, for comparison. In our experiment, we set the size of each block fixed at 1MB and assume that only one block is in the blockchain, while the number of nodes ranges from 4 to 40. Moreover, we assume that each node has 200 MB of storage space, meaning that each node can store 200 blocks at most.

We can learn from Figure 5 that in full-replication strategy, the storage overhead per block is proportional to the number of nodes while the storage consumption in LBFT, PartitionChain, and BFT-Store approximately remain roughly the same and steady, which proves that they have relieved storage pressure against the number of nodes.

6.3. Throughput

The system throughput is defined as the number of committed transactions per second in this paper, which is influenced by the batch size of the input, as well as the number of nodes in the system [26]. We set the different batch sizes that each node proposes 256, 512, 1024, 2048, 4096, 8192, 16,384, 65,536, and 131,072 transactions to test the performance of LBFT and presents the relationship between throughput and batch size in Figure 6.

We can see from Figure 6 that the system throughput increases with the growth of the batch size in LBFT, PartitionChain, and BFT-Store when the number of nodes equals n = 64 and n = 104. The difference is that the increase rate of the throughput against batch size in LBFT and PartitionChain is more significant than in BFT-Store. Notably, the increase in the number of nodes hardly influences the increasing trend of the throughput in LBFT, while it distinctly slows down the increase rate of the throughput in BFT-Store and PartitionChain; the throughput of LBFT even surpasses that of PartitionChain when the number of nodes n = 104, indicating that LBFT has the best scalability.

On the other side, we set the number of nodes in the system to be 32, 40, 48, 56, 64, 80, and 100. The comparison of system throughputs in LBFT, PartitionChain, and BFT-Store is presented in Figure 7.

It can be inferred from Figure 7 that LBFT and PartitionChain have a similar system throughputs, which are both significantly higher than BFT-Store in the experiment. More precisely, LBFT has approximately three times the system throughput of BFT-Store regardless of the number of nodes, mainly because LBFT partitions the block into smaller pieces and frees the nodes from the pre-set time bound for higher computational efficiency. For instance, when the number of nodes is 104, the throughput of LBFT exceeds $2.12\times {10}^4$ transactions per second, while the throughput of BFT-Store merely reaches $0.81\times {10}^4$ transactions per second. Additionally, it is observed that LBFT gradually obtains better performance than PartitionChain when the number of nodes increases.

6.4. Latency

Similar to [25], the system latency is defined as the average time interval beginning at the moment when the first node activates the protocol, and ending when the $(n-f)$-th node gets the result. In addition, we also consider the basic latency in the experiments, which means that each node proposes only one transaction during the whole execution of the protocol. The latency of LBFT, PartitonChain, and BFT-Store against the number of nodes is depicted in Figure 8.

As depicted in Figure 8, the latency increases slightly as the number of nodes rises in LBFT, PartitonChain, and BFT-Store. It is obvious that LBFT and PartitionChain share a similar latency, which is merely half of the latency in BFT-Store. For example, when the number of nodes is 56, the latency in LBFT is about 39.2 ms, while the latency in BFT-Store reaches 92.1 ms.

7. Conclusions

We propose the first storage strategy for the blockchain, named LBFT, that enables the system to operate normally in a zero-trust model. Additionally, it combines RS coding and HoneyBadger-BFT to improve the system’s performance, scalability, and robustness. The primary contributions of this paper include: (i) reducing communication costs by involving only a part of the nodes in each decoding round; (ii) improving system scalability on the premise of maintaining the advantages of the blockchain; (iii) markedly decreasing the computational complexity in encoding and decoding; (iv) enhancing the robustness of the scheme so that it still works when the time assumption does not hold; and (v) improving security by strengthening the supervision and verification of network traffic and system resources to adapt to the zero-trust model.

In this paper, we deploy the core building block ACS of HB-BFT in the consensus process of LBFT, which can be further improved through the similar method introduced in the work [26] to achieve lower communication costs in the future.