Dynamic Byzantine Fault-Tolerant Consensus Algorithm with Supervised Feedback Mechanisms

Abstract

Among the existing consensus algorithms, there are very few low-latency consensus algorithms that can simultaneously take into account node dynamics, fault tolerance, and scalability, and which are applicable to large-scale open scenarios where low latency is required. Therefore, this paper proposes a low-latency scalable dynamic consensus algorithm with high fault tolerance utilizing a combination of layered and threshold signature technologies, known briefly as LTSBFT. Firstly, LTSBFT achieves linear communication complexity through the utilization of threshold signature technology and a two-layer structure. Secondly, the mutual supervision feedback mechanism among nodes enables the attainment of linear complexity for reaching consensus on the faulty upper-layer nodes during the view-change. Lastly, a node dynamic protocol was proposed for the first time to support dynamic changes in the number of nodes during the consensus process. That is to say, consensus can still be reached when the number of nodes dynamically changes without interrupting the client’s request for consensus in the network. The experimental results indicate that LTSBFT exhibits lower communication latency and higher throughput compared to the classic HotStuff and PBFT algorithms. Furthermore, in comparison to double-layer PBFT, the LTSBFT has been demonstrated to have improved fault tolerance.

1. Introduction

In order to maintain the block consistency of nodes, the consensus mechanism is essential in blockchain technology [1]. The Practical Byzantine Fault Tolerant (PBFT) consensus algorithm [2,3,4], which is an alternative to traditional resource proof-based consensus algorithms [5,6,7], addresses the issues of low throughput and resource wastage. Nevertheless, PBFT still faces challenges of inadequate scalability, low fault tolerance, and high communication latency. Especially concerning scalability, the communication complexity of PBFT is O(N²), which severely restricts its applicable scenarios. Additionally, the communication complexity of view-change caused by a malicious leader is O(N³), leading to huge communication-related resource consumption.

W. Li et al. [8] proposed a multi-layer PBFT consensus algorithm which effectively reduced the communication complexity of Byzantine Fault Tolerant (BFT) consensus algorithms by hierarchizing the nodes. However, the latency and fault-tolerance performance of multi-layer PBFT are degraded compared to PBFT. To address the high latency and low fault tolerance of multi-layer PBFT, some improvement algorithms for multi-layer PBFT [9,10,11] have been proposed. A common problem with hierarchical consensus algorithms is that their tolerance for the number of faulty nodes is less than N/3, where N denotes the total number of nodes in the network. Consequently, the hierarchical consensus algorithm cannot be applied in open scenarios, and is only suitable for private and consortium blockchains that have more rigorous access mechanisms.

The HotStuff consensus algorithm [12] reduces the communication complexity of BFT to O(N) during reaching consensus and view-change. Moreover, algorithm security and liveness are guaranteed when there are less than N/3 faulty nodes in the network. However, the effectiveness of HotStuff is limited by the leader’s bandwidth and computing power, performing poorly in the parallel processing of transactions. Furthermore, HotStuff has more consensus phases, resulting in undesirable latency performance. Novel HotStuff improvement algorithms [13,14,15] have emerged gradually, which have effectively reduced the communication latency by omitting the prepare phase in different ways. Although chained HotStuff solves the problem of low throughput experienced with the basic HotStuff consensus algorithm, the risk of block forks caused by malicious nodes and mistake proposals cannot be ignored. However, these consensus algorithms do not sufficiently account for resource consumption, particularly that of the leaders. In addition, the above mentioned algorithms, except for traditional resource proof-based consensus algorithms, do not provide a clear and effective solution for the dynamic change of nodes in the network.

For the current consensus algorithms, the primary issues are concluded as follows:

(1)

Traditional PBFT consensus algorithms consume high communication resources and have low consensus efficiency and scalability.

(2)

HotStuff-based consensus algorithms address the issues of low efficiency and high consumption of PBFT. However, to ensure consensus performance, they require leader nodes to have strong computing power and high bandwidth.

(3)

The current consensus algorithms do not provide a clear and effective solution for the dynamic change of nodes in the network, except for traditional resource proof-based consensus algorithms.

For consensus algorithms, lower resource consumption and higher consensus efficiency are both desirable. Thus, to address the above problems, this paper proposes a high efficiency, low computational consumption, dynamic consensus algorithm based on the combination layering and threshold signature technologies [16,17,18], known briefly as LTSBFT.

First, threshold signature technology is utilized to reduce the consensus communication complexity of reaching consensus on the client request to O(N). Subsequently, by interleaving the feedback of malicious node information from replica-layer nodes to committee-layer nodes, the combination of confirming the NodeID set of malicious nodes with the consensus process is realized within the network, and the complexity of consensus communication to reach consensus of the malicious leaders or supervisory nodes is reduced to O(N). Finally, the node dynamic change within the network without interrupting the consensus process of inter-node is realized by embedding the information of nodes joining or leaving the network into the consensus message.

To the best of our knowledge, the major contributions of this paper are as below:

(1)

We propose a consensus process with a feedback mechanism for malicious nodes to achieve communication complexity for reaching consensus on normal execution or view-change at O(N).

(2)

Aiming at the issue of dynamic node changes, we firstly propose incorporating the consensus of the nodes to be changed within the network into the client request consensus process.

(3)

We propose to set supervisory nodes to supervise leaders and transfer the message of first-time validation pass to the followers, which improves the success rate of consensus and the identification rate of malicious leaders.

The experimental results indicate that LTSBFT exhibits lower communication latency and higher throughput compared to the classic HotStuff and PBFT algorithms. Furthermore, in comparison to double-layer PBFT, the LTSBFT has been demonstrated to have improved fault tolerance.

2. Related Work

The problems of traditional BFT consensus algorithms mainly include the following aspects: arbitrary selection of the leader, high communication complexity, poor scalability, large communication latency, dynamic joining or exiting of nodes leading to interruption of the network consensus process, and low fault tolerance. In improving the arbitrary aspect of leader selection, the RBFT [19] consensus algorithm proposes to select a leader based on node reputation values, which effectively reduces the probability of a malicious leader. In terms of improving the high communication complexity, consensus algorithms such as Zyzzyva [20], Tendermint [21], and HotStuff [12] reduce the communication complexity of the BFT consensus algorithm to linear level. On improving the communication latency, the HCA [22] consensus algorithm utilizes the re-vote mechanism, which effectively improves the problem of high communication latency in the HotStuff consensus. Dynamic PBFT [23] proposes an improved quorum mechanism to solve the problem of nodes joining or exiting dynamically. Aiming at improving the low fault tolerance, NBFT [24] utilizes the aggregated signature [25] technique to make the upper fault tolerance limit higher than N/3, but the lower fault tolerance limit much less than N/3.

Combining some typical BFT consensus algorithms, two novel directions for improved BFT consensus algorithms have been demonstrated. One of the novel improved directions is to divide a large network into different shards, and the consensus is executed independently within the shards. CSBFT [26] proposes a blockchain protocol with flexible sharding to reduce the confirmation latency when processing cross-shard transactions. SharBFT [27] integrates a sharding optimization model (SOM) to improve the efficiency of consensus under dynamic system environments. The SOM minimizes the average consensus latency and also ensures the security and scalability of the network. Yizhong Liu et al. [28] proposed a secure and scalable hybrid consensus (SSHC) scheme, which designs pipelined Byzantine fault tolerance for intra-shard consensus by combining pipelined technology with threshold signatures, thus effectively improving the intra-shards consensus efficiency of the sharding consensus algorithm.

Another improvement direction is to combine consensus algorithms with digital signatures, i.e., reduce the consensus communication complexity using digital signature technology. One of the most typical HotStuff [12] algorithms reduces the communication complexity to O(N) based on threshold signature technology. In addition, Fast-HotStuff [13] reduces the communication complexity to O(N) using aggregate signature technology. Jieyi L. et al. [29] proposed the aggregated signature Gossip [30] protocol, which utilizes a non-interactive leaderless BLS signature aggregation scheme to significantly reduce the communication complexity of transferring messages.

In addition to the above consensus algorithms, there is another category of typical consensus algorithms designed for crash fault scenarios, e.g., Raft [31] and Paxos [32]. They are non-Byzantine fault-tolerant protocols based on state machine replication and have linear communication complexity. Raft is a simplified version of Paxos, offering better understandability.

3. The Proposed Scheme

3.1. The Model

Assume that in a network, there are total N nodes, and each node has a unique node number. Suppose the node number of each node is denoted as NodeID, and all the nodes are divided into N_L groups according to the neighboring NodeID. In addition, it is ensured that the number of nodes in each group is basically the same. After that, from all the groups, N_L leaders are selected by a Proof of Work (PoW) consensus algorithm. When selecting the leaders, the node with the smallest NodeID broadcasts the mining proposal to all nodes. In each group, the node that solves the puzzle ξ first is the leader. The selected leaders are placed in the committee layer and are no longer affiliated to any group. The leaders are sorted according to the size of the initial NodeID and renumbered in order starting from 0 (NodeID = 0, ⋯, N_L − 1). Subsequently, the remaining nodes are categorized into a replica layer. In the replica layer, N_S supervisory nodes are selected. Similarly, the PoW consensus algorithm is used to select the supervisory nodes, and the proposal is broadcasted by the leader with NodeID = 0 to the replica-layer nodes. The top N_S nodes that are the first to solve the puzzle ξ are the supervisory nodes. The selected supervisory nodes are no longer affiliated with any group, and the remaining nodes are the followers. In the same way as the committee-layer nodes are numbered, the supervisor nodes are first numbered starting from N_L (NodeID = N_L, ⋯, N_L + N_S − 1). The followers are numbered from N_L + N_S (NodeID = N_L + N_S, ⋯, N − 1). The node division structure is shown in Figure 1.

The nodes in the network store the NodeID and public key of all the nodes and their corresponding (IP; Port). When a new node joins, based on the number of nodes in each group, the group with the least number of nodes is selected to join, and the node is numbered as NodeID = N. Suppose the kth group from the number of nodes is $N_{f_k}$. When a NodeID = i node exits, each node needs to delete the stored NodeID and the corresponding (IP; Port), and the node with NodeID > i will change its node number to NodeID − 1. The specific node dynamic protocol content is described in an expanded manner in Section 3.4.

3.2. RSA Threshold Signature

The LTSBFT consensus algorithm uses the (t, n)-RSA threshold signature scheme. Each leader in the committee layer has a unique private key s and a verification private key v. All nodes together hold the verification public key VK and the complete digital signature public key PK. v, PK, and VK are made public, and s is secret. Assume that the message m is signed by leader_i via private key s_i as ${\left\{tsign\left(m,s_i\right)\right\}}_{i\in I}$. Each leader contributes a partial signature ${\left\{tsign\left(m,s_i\right)\right\}}_{i\in I}$, and when a leader collects |I| = t valid threshold signatures ${\left\{tsign\left(m,s_i\right)\right\}}_{\left|I\right|=t}$, it can generate to the complete digital signature $\sigma =combine\left(tsign\right(m,s_{i_1}),\cdots ,tsign(m,s_{i_t}\left)\right)$. In the LTSBFT consensus algorithm (t, n) threshold signature scheme, set t = ⌊N_L/2 + 1⌋, n = N_L.

Each leader verifies the validity of each partial signature ${\left\{tsign\left(m,s_i\right)\right\}}_{i\in I}$ sequentially before generating the complete digital signature σ. The pseudocode for partial signature generation, partial signature validity verification, complete digital signature generation, and digital signature verification is shown in Algorithm 1.

Algorithm 1 threshold signature

$⊳$ Key Generation //The Key Generation Center (KGC) generates corresponding keys for each node. 1:as a leader 2:storage ${(v_i,VK,leader.s,PK)}_{i=1}^N$ to local $keypool$   //$VK=v$, $v_i=v^{s_i}$, $s_i==l{eader}_i.s$ 3:as a follower 4:  storage $PK$ to local $keypool$ $⊳$ Partial Signature Generation 5:the leader generates ${\left\{t{sign\left(m,s_i\right)}_i\right\}}_{i\in I}=m^{2\mathsf{\Delta }{s}_i}\in Q_n$//$Q_n$ is an n-element finite field $⊳$ Partial Signature Verification 6:the leader computes $b=H\left(v^r,m^{4\Delta r}\right),z=leader.s·b+r$ //r is a random number chosen by the leader ($r\in \{0,\cdots ,2^{512}-1\})$ 7:if $\mathrm{b}==\mathrm{H}\left(v^z{v_i}^{-b},m^{4\Delta z}{ts}_i^{-2b}\right)$//${ts}_i=={\left\{t{sign\left(m,s_i\right)}_i\right\}}_{i\in I}$, $\mathrm{H}$ is a Hash function 8:  ${\left\{t{sign\left(m\right)}_i\right\}}_{i\in I}$ is a valid signature 9:else 10:  ${\left\{t{sign\left(m,s_i\right)}_i\right\}}_{i\in I}$ is an invalid signature $⊳$ Signature Combine 11:if the leader collects $\left|I\right|=t$ valid signatures 12:  the leader computes $\sigma =combine({ts}_{i_1},\cdots ,{ts}_{i_t})$ $⊳$ Digital Signature Verification 13:if $Verify\left(\mathsf{\sigma },PK\right)==ture$ 14: $\sigma$ is a correct digital signature 15:else 16: $\sigma$ is a fault digital signature

3.3. Hierachical Consensus Protocols

In the LTSBFT consensus algorithm, a consensus is reached among the leaders in the committee layer using a threshold signature, which produces an acknowledgement of the authenticity of the message by each signing leader. Utilizing the verifiability of the threshold signature, replica-layer nodes only need to validate that the threshold signature sent from any node passes to confirm the authenticity of the message.

Therefore, the LTSBFT consensus algorithm selects S ($S\in [2,(N_L+1)/2]$) leaders to send client requests to replica-layer nodes, and the other leaders supervise the behavior of the selected S leaders. Due to the utilization of an interleaved feedback mechanism and the insertion of the NodeID set of malicious nodes within the consensus message for client requests, communication complexity for reaching consensus of malicious nodes only requires O(N).

In the inter-leader generation threshold signature phase, a leader needs to be selected to send pre-prepare messages to other leaders. Here, taking a reference from the PBFT consensus algorithm for leader selection, the leader is selected by L_v = v mod N_L, where v is the current view. When the leader leader_i with NodeID = i ($i\in [0,N_{L-1}]$) receives a client request, it needs to transfer it to the leader with NodeID = L_v. If leader_i does not enter the prepare phase after receiving a new client request message, it reselects the leader with NodeID = L_v + 1 to send the pre-prepare message. The basic process of the LTSBFT consensus protocol is shown in Algorithm 2, the flow chart is shown in Figure 2, and the operation flow is shown in Figure 3. The LTSBFT layered consensus protocol is implemented as follows:

Client request phase. The client initiates a request to the leader ${<request,o,t,c>}_{{\sigma }_{client}}$, where o is the client request, ${\sigma }_{client}$ denotes the digital signature of the client, t is the timestamp of generating the message, and c is the client identity (lines 6–7).

Pre-prepare phase. When the ${leader}_{L_v}$ receives client request, it sends a pre-prepare message ${<<preprepare,m,tsign\left(m,s_{L_v}\right),b_{L_v},z_{L_v}>}_{{\sigma }_{Lv}},msg>$ to other leaders. In this case, msg is the request message from the client; ${\sigma }_{L_v}$ is the digital signature of the ${leader}_{L_v}$; and m denotes $<t,n,{v,l}_v,{Hash}_n>$, where, v and n are the view number and the message sequence number, respectively. Furthermore, Hash_n = SHA256 (msg) + Hash_n−1. $b_{L_v}$ and $z_{L_v}$ are used to validate the validity of $tsign\left(m,s_{L_v}\right)$. l_v is the NodeID set of malicious nodes for which the current view leader expects to reach a global consensus, and $s_{L_v}$ is the private key of ${leader}_{L_v}$.(line 7).

Prepare phase. If leaders receive the pre-prepare messages and successfully validate the pre-prepare messages, they then send a partial signature $<prepare,tsign\left(m,s_i\right),b_i,z_i>$ to the other leaders (lines 8–9).

Commit phase. Leaders receive the prepare message and verify the validity of each partial signature. After the leaders collect |I| = ⌊N_L/2 + 1⌋ valid ${\left\{{tsign\left(m,s_i\right)}_i\right\}}_{i\in I}$, they generate a complete digital signature utilizing $\sigma =combine(sign\left(m,s_{i_1}\right),\cdots ,sign(m,s_{i_t}\left)\right)$. After that, the S leader with NodeID = LS_i (i = 1, 2, ⋯, S) is selected to send the $<commit,t,n,v,k_{v-1},msg,\mathsf{\sigma },{LS}_i>$ message to the kth ({k | i = k mod S}) group of followers and all the supervisory nodes (lines 10–19).

Follower reply phase. If followers receive the commit message and verify that the commit message is correct, then followers reply ${<freply,n,t,v,f_v,res,i>}_{{\sigma }_i}$ to the corresponding leader. Here, f_v is the NodeID set of the malicious node feedback to the certain leaders from the certain followers in view v, containing the NodeID of the malicious leaders and the malicious supervisory nodes determined by that follower. For the malicious leader or supervisory node identification, if leaders or supervisory nodes do not adhere to the protocol, broadcast a message that fails verification, or fail to broadcast a message, they will be identified as malicious nodes.

In addition, res is the confirmation result of the follower. In this case, res = 1. If the follower obtains the first commit message that can be validated to pass from the leader with NodeID = LS_{i=k mod S}, then LS_{i=k mod S} $\notin$ f_v. Otherwise, LS_{i=k mod S} $\in$ f_v. If the follower, after confirming the client request, does not receive ${<\mathrm{s}commit,commit,j>}_{{\sigma }_j}$ from a supervisory node supervisory node_j (j $\in$ [N_L, N_L + N_S − 1]) within the maximum network latency, j $\in$ f_v+1. The follower will feedback f_v+1 to the leader at v + 1 view (Algorithm 2: line 22–line 38). After the first correct commit message received, the supervisory node sends a ${<\mathrm{s}commit,commit,j>}_{{\sigma }_j}$ message to all followers and replies to all the leaders with ${<sreply,n,t,v,s_v,res,j>}_{{\sigma }_j}$. Here, j is the NodeID of the supervisory node. Subsequently, the supervisory node collects commit messages from all S leaders. If within the maximum network latency, a supervisory node does not collect the correct commit message from a leader leader_l (l $\in$ C), l $\in$ s_v+1. The supervisory node will then feedback s_v+1 to all non-malicious leaders at v + 1 view. C is the NodeID set of the selected S leaders (lines 20–46).

Leader reply phase. When the leader with NodeID = k (k $\in$ [0, N_L−1]) receives more than $⌊N_{f_k}/2+1⌋$ valid replies with consistent res_f = 1 from the followers, then it is considered that the consensus of the kth group has been reached. Thus, the leader replies ${<lreply,n,t,v,res>}_{{\sigma }_l}$ to the client. When the client receives f + 1 valid and consistent replies, then it is considered that the whole network consensus has been reached (lines 47–51).

Algorithm 2 LTSBFT consensus protocol

1:function $tsigh\left(m,s\right),vparsign\left(t{sign\left(m,s_i\right)}_i,b_i,z_i\right),vsign\left(\sigma ,pk\right)$    //signing, validating partial signature, validating digital signature 2:function $vmsg\left(msg\right)$//validating message with request  if msg.n==n+1$\wedge$msg.v == v+1$\wedge$msg.o$\ne$msg.o   return true 3:function $vhash\left(msg\right)$//validating message with hash value   if msg.v==node.v+1 && msg.v==node.v+1 && msg.hash != msg’.hash    return true 4:function $chnodeID\left(nodeID\right)$//select a $nodeID$ for the reply required  for $id=nodeID+1,nodeID+2,\cdots$   if $id$ $\in nonfaultset$     $ReplyLID=id$    break  return $ReplyLID$

5:for $v=\mathrm{0,1},2,\cdots$ $⊳$ request phase  as a client 6:send $request$ to a random leader $⊳$ preprepare phase  as the certain leader//the leader who receives the $request$ message 7:send $preprepare$ to the other leaders $⊳$ prepare phase  as a leader//the leader is the node that receives the $preprepare$ message 8:if $vmsg\left(preprepare\right)$

9:  send $prepare$ message to the other leaders $⊳$ commit phase  as a leader 10:$leader.parsignNum=0$ 11:if vhash(prepare) && vparsign(prepare.sign, prepare.b, prepare.z) 12:   leader.parsignNum=leader. parsignNum+1 13:if $leader.parsignNum==⌊N_L/2+1⌋$ && $leader.NodeID=={LS}_i$ 14://$fnum=\left|\left\{{NodeId}_{l_s}|\left({LS}_i+v^2\right)mod{N}_L\in [0,S+fnum)\cap faultset\right\}\right|$ 15://$\left|C=\left\{{LS}_i|\left({LS}_i+v^2\right)mod{N}_L\in [0,S+fnum)\cap nonfaultset\right\}\right|==S$  //$faultset$ is a set of evil leaders NodeID;$nonfaultset$ is a set of honest leaders NodeID 16:    $\sigma =combine({prepare.sign}_1,\cdots ,{prep-are.sign}_t)$ 17:    $<commit,t,n,v,l_v,msg,\mathsf{\sigma },{LS}_i>=Commitmess$ 18:    send $Commitmess$ to the followers of $kth\left(kmodS==i\right)$ group 19:    send $Commitmess$ to supervisory nodes//$i$ is the position of ${LS}_i$ in set C $⊳$ follower reply phase  as a follower//the follower is a node in group k 20:$ifreplyleader=false$//record whether the follower replies to the corresponding leader 21:$ReplyLID=k$ 22:if $k\in faultset$ 23:  $ReplyLID=chnodeID\left(k\right)$ 24:if $Commitmess$ sent by leader &&$vsign\left(Commitmess.\sigma ,pk\right)$ 25:  $f_v\leftarrow nil,{res}_f=1,ifreplyleader\leftarrow true$ and send $freply$ to the ${leader}_{ReplyLID}$ 26:if $\mathrm{s}commit$ sent by supervisory nodes && $!timeout$ 27://determine if waiting exceeds the maximum network delay 28:  append $\mathrm{s}commit.NodeID$ to $recordSID$ 29:  if ifreplyleader == false && Verify(Commitmess.σ, PK) 30:   $f_v\leftarrow {NodeId}_{l_f},{res}_f=1$  31:   if $ReplyLID=={NodeId}_{l_f}$ 32:    $ReplyLID=chnodeID\left(k\right)$ 33:   send $freply$ to ${leader}_{ReplyLID}$ and $ifreplyleader\leftarrow true$ 34:if $ifreplyleader$ 35:  for $SID=N_L,\cdots ,N_L+N_S-1$ 36:   if $SID\notin recordSID$ 37:   append $SID$ to $f_{v+1}$  as a supervisory node 38:$ifreply\leftarrow false$ 39:if $Verify\left(Commitmess.\mathsf{\sigma },PK\right)\&\&!timeout$ 40:  if$!ifreply$  41:   $ifreply\leftarrow true{,res}_f=1$ 42:   send $scommit$ to all followers and send $sreply$ to all leaders 43:  append $Commitmess.NodeID$ to $recordNID$ 44:for $leaderID=$ range $nonfaultset$ 45:  if $leaderID\notin recordNID$ 46:   append $leaderID$ to $s_{v+1}$ $⊳$ leader reply phase  as a leader 47:$leader.freplyNum=0$ 48:if $freply.{res}_f==1$  49:  $leader.freplyNum=leader.freplyNum+1$ 50:if $leader.freplyNum==⌊F{num}_j/2+1⌋$ 51:  send $lreply$ to the client

If the correctly completed digital signature is not generated among the leaders during the commit phase, all nodes in the network execute the PBFT consensus algorithm. The leader sends pre-prepare messages to all followers to be validated. The follower calculates NodeID_PL = (v + N) mod N_L among the leaders that send the pre-prepare message, and the leader whose NodeID is closest to NodeID_PL is selected as the leader that executes the PBFT consensus algorithm. If the NodeIDs of leaders are equal in distance to NodeID_PL, the leader with the larger NodeID is selected. Within the LTSBFT consensus algorithm, a case may exist in which the consensus of a group has been reached, but the corresponding leader does not reply to the client. Thus, when a follower receives a client request which has been saved locally, the follower replies to the client directly, and the consensus of the network is considered reached when the client receives more than ⌊N/2 + 1⌋ replies from the followers. In order to ensure the network liveness, if an honest leader leader_i generates a threshold signature and does not receive a reply from the ith group of followers within the maximum network latency, it sends a commit message to all followers in the group that satisfy {k | k mod S == i mod S}. Here, k is the group number of the followers.

3.4. Node Dynamic Protocol

The dynamic change of nodes in the network is mainly categorized into three cases: (1) nodes actively applying to join the network; (2) nodes actively applying to exit the network; and (3) nodes crashing, resulting in passive exit from the network. The protocols will be described in detail for each of the three cases.

When a new node applies to join the network, it sends ${<Join,t_1,PK,(IP;Port)>}_{\sigma }$ to a node in the network that can be contacted, where t₁ is the timestamp of the Join message generation, and PK is the public key for verifying the new node’s digital signature σ. If the node Node_k with NodeID = k receives a Join request in view v, it will transfer the Join request to all leaders at the end of the execution of the current view. Then Node_k sends the (IP; Port) and public key information of all the nodes within the network stored by itself to the new node applying to join. After the leaders input PK to verify that the Join message has passed, in view v + 1, a consensus protocol which incorporates client request consensus with node join request consensus will be executed. Below, this protocol is described in detail.

In the pre-prepare phase, the ${leader}_{L_{v+1}}$ sends <<preprepare&&join, m, tsign(m, ${s_{L_{v+1}},\mathrm{S}\mathrm{H}\mathrm{A}256\left(Join\right)),b_{L_{v+1}},z_{L_{v+1}}>}_{{\sigma }_{L_{v+1}}},msg>$ to other leaders, where SHA256(Join) is the hash value of the Join message. The leader_k ($k\in [0,N_L-1]/L_{v+1}$) receives the preprepare&&join message and verifies that the message has passed, then it enters the prepare phase. Then, leader_k sends <prepare&&join, {tsign(m, s_k, SHA256(Join))_k ${{\}}_{k\in I},b_k,z_k>}_{{\sigma }_k}$ to other leaders. A commit&join message is generated by |I| = ⌊N_L/2 + 1⌋ valid prepare&join messages. The commit&join message format is ${<commit\&\&join,t,n+1,{v+1,f}_{v+1},msg,Join,{\mathsf{\sigma }}_{join}>}_{{\sigma }_i}$, where ${\mathsf{\sigma }}_{join}=combine\left\{tsign\left(m,s_{i_1},SHA256\left(Join\right)\right),\cdots ,tsign(m,s_{i_t},SHA256\left(Join\right))\right\}$. After that, leader_LS sends a commit&&join message to the replica-layer node. The replica-layer node Node_k ($k\in [N_L,N-1]$) receives and validates the correctness of the commit&&join message, and then it saves the client request of view v + 1 locally and considers that the consensus of the new node joining has been reached. Thus, Node_k saves the (IP; Port) and PK of the new node locally. Since the follower reply phase and leader reply phase are consistent with the LTSBFT layered consensus protocol, it is not described here.

Suppose Node_i ($i\in [0,N-1]$) requests to exit from the network at view v. Node_i sends an Exit message ${<Exit,t_2,i,(IP;Port)>}_{{\sigma }_i}$ to all the leaders after completing the consensus of the current view, where t₂ is the timestamp of the Exit message generation. After Node_i sends the Exit message to the leaders, in view v + 1, a consensus protocol which incorporates client request consensus with node exit request consensus will be executed. The execution of this protocol is similar to the case of a node requesting to join the network. At each phase the “join” in the message header is replaced with “exit”, SHA256(Join) in the message body is replaced with SHA256(Exit), and ${\mathsf{\sigma }}_{join}$ is replaced with ${\mathsf{\sigma }}_{exit}=combine\left\{tsign\left(m,s_{i_1},SHA256\left(Exit\right)\right),\cdots ,ts-ign(m,s_{i_t},SHA256\left(Exit\right))\right\}$. If Node_i is a leader, the network complements the exiting leader when the leader is re-selected.

There are three main cases through which to judge node crash: (1) followers crash; (2) supervisory nodes crash; and (3) leaders crash. The leaders check the followers’ and supervisory nodes’ storage states by executing the state consistency check protocol in Section 3.5 to judge whether they are in a crash state. If the followers or supervisory nodes do not send Check messages to the majority of the leaders during the state consistency check phase, each leader sends ${<preExit,SetID,SetIP,j>}_{{\sigma }_j}$ to other leaders, where SetID and SetIP are the set of NodeID and (IP; Port) of the nodes that did not send the Check message, and j and σ_j are the NodeID and digital signature of the leader that sent the preExit message, respectively. If a leader collects more than ⌊N_L/2 + 1⌋ valid preExit messages sent by different leaders, it proves that the node represented by the NodeID contained within the SetID has not participated in the state consistency check, and the node may have crashed. After the state consistency check is over, it enters (v + 1)th view, and the leader ${leader}_{L_{v+1}}$ that tranfers the client request in v + 1 view sends preprepare &&Exit messages to other leaders. Subsequently, a consensus protocol which incorporates the client request consensus with the node exit request consensus will be executed. The Exit message within preprepare&&Exit, prepare&&Exit and commit&&Exit is ${<Exit,t_2,setID,setIP>}_{{\sigma }_{Lv+1}}$. In this case, multiple crashed nodes can exit the network at the same time.

If a leader crashes during consensus execution, it will be marked as a malicious leader when it is selected to send client requests to replica-layer nodes. At the time of re-selecting the leader, this crash leader is replaced as a follower and exits from the network at the end of the execution of the state consistency check protocol, since the malicious leader is skipped when the leader is selected to send the client request to the replica-layer node. The node is not re-elected as a leader or supervisor node after it is marked as a malicious node. Therefore, the normal execution of the protocol is not affected until the crashed leader is excluded from the network.

3.5. State Consistency Check Protocol

The state consistency check has two main roles: (1) to ensure that the replica-layer nodes and the leader maintain a consistent state, and that the nodes within the network delete the stored logs, reducing the node storage load; and (2) to facilitate the leader checking the state of the replica-layer nodes, resulting in timely clean up of the crashed nodes within the network in order to reduce the adverse impact of the crashed nodes on the network.

Referring to the node state storage structure of PBFT [3], each node manages each state in the form of a partition tree, and each page saves the client requests that have reached consensus. In order to prevent block forking, ${Hash}_n=SHA256\left(msg\right)+{Hash}_{n-1}$ is put into the threshold signature during the signature process of the inter-leader. Therefore, the followers or supervisory nodes correctly verify the threshold signature only if they have not lost their previous state. In order to ensure that most replica-layer nodes have the correct state, the leaders are set to execute a state consistency check at a certain interval, based on a fixed number of rounds. The ${〈Check,R,i,t_3〉}_{{\sigma }_i}$ is sent to all leaders by replica-layer nodes, where R is all the metadata in the partition tree stored by the replica-layer node, and t₃ is the timestamp of the Check message generation. The leader verifies whether each metadata value is correct or not. If a leader verifies that a metadata value of a follower or supervisor node is wrong, it will start the state transfer and send ${<transfer,P,l,v>}_{{\sigma }_l}$ to this node, where P contains all the page values under the metadata that failed authentication and each page contains a client request, and l is the NodeID of the leader. If a replica-layer node receives consistent transfer messages from more than ⌊(N_L + 1)/2⌋ leaders, it considers its own state as in error. In this case, the node will copy the state transferred from the most leaders.

At the end of the state consistency check, the state of the replica-layer node that lost its state is restored and the nodes within the network are in a stable state. After that, in order to prevent the increasing length of the message log stored by the nodes, all the nodes within the network retain only the previously stored digest of each client request.

3.6. View-Change Protocol

Assume that under the current view v, no malicious node has been discovered by the replica-layer node, and the client request reaches consensus normally; then, all nodes within the network will directly change view. If a leader or supervisory node is found to be malicious by the replica-layer nodes under view v, a consensus on the NodeID of the malicious node needs to be reached within the network. Subsequently, all nodes within the network will change view. If a leader is judged to be a malicious node, it will not be selected to send commit messages to the followers and the followers will not reply freply messages to it.

Since the set of malicious NodeIDs is embedded within the freply (sreply), prepare (prepare&&join, prepare&&exit), and commit (commit&&join, commit&&exit) messages, the confirmation of malicious nodes is incorporated into the follower reply, prepare, and commit phases of consensus. leader_i $(i\in [0,N_L-1]$) only needs to collect the freply (sreply) messages within the maximum network latency to judge whether a malicious node exists or not. If there is a malicious node, then the freply (sreply) message containing the ${NodeID}_{n_f}$ ($n_f\in [0,N_L+N_S-1]$) is transferred by leader_i to other leaders, where ${NodeID}_{n_f}$ is the NodeID of a malicious node judged by leader_i. In this way, leader_i informs the other leaders that the node ${node}_{n_f}$ with $NodeID={NodeID}_{n_f}$ is judged as a malicious node. If the threshold signature containing the ${NodeID}_{n_f}$ is generated correctly in the prepare phase of the next view, it proves that the consensus has been reached between the leaders that the ${node}_{n_f}$ is a malicious node.

If a leader collects ⌊N/2 + 1⌋ freply messages which all contain the feedback of the ${NodeID}_{s_f}$ of the supervisory node ${Supervisorynode}_{s_f}$ in view v, then the leader judges that the supervisory node ${Supervisorynode}_{s_f}$ is a malicious node. The leader judges whether a node is a malicious leader or not, which can be divided into two cases:

(1)

Feedback from both supervisory nodes and followers: if leader_i collects ⌊Ns/2 + 1⌋ sreply messages in view v and ⌊N/4S + 1⌋ freply messages in view v – 1, and the sreply and freply messages all contain feedback of ${NodeID}_{l_f}$, leader_i considers ${leader}_{l_f}$ as a malicious node.

(2)

Feedback from followers: if in view v, leader_i collects ⌊N/2S + 1⌋ freply messages which all contain feedback of ${NodeID}_{l_f}$, leader_i considers ${leader}_{l_f}$ as a malicious node.

Case (1) is given in order to supervise the leaders to send correct commit (commit && join, commit && exit) messages to the supervisory node; case (2) is given in order to supervise the leader to send timely commit (commit && join, commit && exit) messages to the followers. The way followers and supervisory nodes judge whether a leader is malicious, and the way followers judge whether a leader is malicious, are shown below.

If a follower does not receive a corresponding commit message from ${leader}_{l_s}$ before receiving the correct commit message from the supervisory nodes, it considers ${leader}_{l_s}$ as a malicious leader. Thus, the follower inserts the NodeID of ${leader}_{l_s}$ into f_v (Algorithm 2: lines 28–31).

If a follower does not receive a scommit message from a particular supervisory node supervisory node_i within the maximum network latency, supervisory node_i is considered as a malicious supervisory node. Therefore, the follower inserts the NodeID of supervisory node_i into f_v+1. The f_v+1 set sent by the follower contains the NodeID of the malicious leader and the malicious supervisory node (Algorithm 2: lines 35–38).

Suppose leader_f is the node that should send a commit message to the replica-layer node in view v, but leader_f does not send a commit message to the supervisory node supervisory node_i $(i\in [N_L,N_L+N_S-1]$) within the maximum network latency. Thus, supervisory node_i inserts the NodeID of leader_f into s_v+1 during the freply phase within view v + 1 (Algorithm 2: lines 41–48).

Once the number of malicious leaders reaches ⌊(N_L − 1)/2⌋, or the upper layer node threshold signature cannot be generated, the non-malicious leader with the smallest NodeID broadcasts a proposal to all the groups to replace all the malicious leaders by PoW consensus algorithm. The top N_f non-malicious followers with successful mining are considered as master nodes, where N_f is the number of the malicious leaders in the committee layer. The NodeID of the elected non-malicious followers and the NodeID of the malicious leaders are sorted, respectively, and the NodeIDs of both of them are exchanged with each other in order. The malicious leader is placed in the group of followers of the same NodeID as the original follower to make the malicious leader a follower. Finally, leaders re-initialize the key.

If the supervisory node is found to be malicious node, a new supervisory node is selected based on NodeID_C = N_L + N_S + v mod (N − N_L − N_S). If the node with NodeID = NodeID_C is a malicious node, then the non-malicious follower which is closest to NodeID_C is selected. If the NodeIDs of two followers are equal in distance from NodeID_C, then the follower with the larger NodeID is selected. The NodeIDs of the selected follower and the malicious supervisory node are exchanged, and the malicious supervisory node becomes a follower and is placed into the group where the selected follower node is located.

The original malicious node remains a malicious node after changing to a follower. The nodes within the network replace the previously stored NodeID of malicious nodes with the NodeID of the current malicious node after the leader and supervisory node reselection. A malicious node cannot be selected as a leader or supervisory node.

3.7. State Transfer Protocol

If a node node_i ($i\in [0,N-1]$) finds that the message sequence numbers in the state machine are not continuous, then node_i executes the transfer state protocol. node_i sends ${<Fetch,n_1,n_2,i>}_{{\sigma }_i}$ to any one of the other nodes, where n₁ is the message sequence number at the beginning of the message to be transferred and n₂ is the message sequence number at the end of the message to be transferred. When the Fetch message is received by node_j ($j\in [0,N-1]/j$), it replies ${<transfer,P,j>}_{{\sigma }_f}$ to node_i, where P contains correct commit messages from n₁ to n₂ which have been verified. If node_i initiates a Fetch request but does not receive a reply, it can again initiate a Fetch request to other nodes.

4. Algorithm Analysis

4.1. Security Analysis

The inter-leader conducts the threshold signature in the pre-prepare and prepare phases to generate a complete digital signature $\sigma$. If the followers successfully verify the $\sigma$, they store the commit message. In the RSA threshold signature scheme, the threshold t = ⌊N_L/2 + 1⌋ is set to generate a proof on the votes of the most leaders by commit messages. Therefore, the security of linearly multicasting commit messages from leaders can be guaranteed by the LTSBFT consensus algorithm. After that, we further analyze the security of LTSBFT by referring to the FPD model in [8]. In the FPD model, the number of nodes is fixed, and the consensus success rate of the LTSBFT consensus algorithm is calculated by altering the malicious node probability p.

Suppose that the network contains N_L groups, N_L leaders, and N_S supervisory nodes. There are N_f followers within each group and S leaders are selected to send commit messages to replica-layer nodes. To simplify the case, assume that if the selected leaders is honest, they will send the correct message to the corresponding followers of N_L/S groups and all supervisory nodes; if the selected leaders are faulty, they will not send the correct message to any of the nodes. When more than ⌊N_L/2 + 1⌋ groups can reach consensus, it can be considered that consensus has been reached within the network.

Subsequently, the discussion is based on the case that the threshold signature can be generated correctly among leaders. If the consensus can be reached, there are two cases for followers receiving the commit message: (1) all followers can receive the valid commit message; or (2) only a partial number of followers can receive the valid commit message. Case 1 is satisfied if there exists any honest leader among the elected S leaders and there exists any honest supervisory node, or all of the elected S leaders are honest leaders; case 2 is satisfied if all the supervisory nodes are malicious nodes and there exists [⌊S/2 + 1⌋, S − 1] honest leaders among the S leaders.

Suppose that the inter-leader can generate the correct threshold signature as event A; more than half of the followers in a group are honest followers as event B; all followers can receive the correct commit message as event C₁; and partial followers can receive the correct commit message as event C₂. The probabilities of reaching events A, B, C₁, and C₂ are, respectively, P(A), P(B), P(C₁) and P(C₂), and their equations are shown in Equation (1).

$$\begin{array}{l}P(A)={\displaystyle \sum _{i=0}^{⌊N_L/2+1⌋}{C}_{N_L}^i{p}^i{(1-p)}^{N_L-i}}\\ P(B)={\displaystyle \sum _{k=0}^{⌊N_f/2+1⌋}{C}_{N_f}^k{p}^k{(1-p)}^{N_f-k}}\\ P(C_1)=1-\left\{p^S+{\displaystyle \sum _{j=1}^{S-1}{C}_S^j{(1-p)}^{S-j}{p}^{N_S+j}}\right\}\\ P(C_2)={\displaystyle \sum _{l=⌊S/2+1⌋}^{S-1}{C}_S^l{p}^{S+N_S-l}{(1-p)}^l}\end{array}$$

(1)

Here, to simplify the case, it is assumed that events C₁ and C₂ are independent of event A. In practice, events C₁ and C₂ are related with event A. Due to this, the possibility for followers to receive the correct commit message is dependent on the correct generation of the threshold signature. When event C₁ is held, the probability is calculated as P₁; when event C₂ is held, the probability is calculated as P₂. P₁ and P₂ equations are shown in Equation (2). Finally, the probability of reaching consensus is calculated as P = P₁ + P₂. Since both the calculated P₁ and P₂ are smaller than the actual probability of occurrence, the calculated probability P of reaching consensus will also be lower than the actual simulation.

$$\begin{array}{l}{P}_1={\displaystyle \sum _{t=⌊N_L/2+1⌋}^{N_L}{C}_{N_L}^{t}P(C_1)P{(B)}^t{[1-P(B)]}^{N_L-t}P(A)}\\ P_2={\displaystyle \sum _{l=⌊S/2+1⌋}^{S-1}{C}_S^l{p}^{S+N_S-l}{(1-p)}^l}{\displaystyle \sum _{t=⌊N_L/2+1⌋}^{⌈N_{L}l/S⌉}{C}_{N_L}^{t}P{(B)}^t{[1-P(B)]}^{N_L-t}P(A)}\end{array}$$

(2)

To verify the correctness of the analysis, the probability of simulation by the actual network is compared with the probability of calculation by the analysis, where N_L = 15, N_S = 3, S = 3, and N_f = 9. Furthermore, the number of nodes in the first layer of double-layer PBFT is 15 and the number of nodes in each group is 9. The security of the LTSBFT consensus algorithm is evaluated by comparison with the success rate of double-layer PBFT [8]. The comparison results are shown in Figure 4.

As can be observed from Figure 4, the consensus success rate of the LTSBFT consensus algorithm is much higher than the consensus success rate of double-layer PBFT. When the node malicious probability p < 0.2, the LTSBFT consensus algorithm network consensus success rate is close to 1. Therefore, it can be concluded that the LTSBFT consensus algorithm has improved security.

4.2. Liveness Analysis

When the threshold signature cannot be generated correctly among leaders, the PBFT consensus algorithm is executed instead. This ensures the algorithm liveness when more than half of the leaders are malicious leaders. When honest leaders generate a complete digital signature, after maximum network latency, they cannot receive replies from the corresponding followers. Therefore, leaders broadcast commit messages to those followers. This ensures algorithm liveness when more than half of the honest followers fail to receive a correct commit message. When followers receive a committed client request, followers directly reply to the client. This ensures the algorithm liveness when leaders are malicious during replying to the client. To summarize, when the number of malicious nodes in the system is less than N/3, the LTSBFT consensus algorithm can ensure liveness.

4.3. Resource Consumption Analysis

Furthermore, the LTSBFT algorithm also addresses resource consumption, including both communication and computational resources. Compared to PBFT, LTSBFT significantly reduces communication overhead, with only negligible additional communication costs. Specifically, LTSBFT uses threshold signature technology among a small committee of nodes, reducing communication complexity to O(N), whereas PBFT has a communication complexity of O(N²).

For HotStuff-based consensus algorithms, the issues of limited bandwidth and computational power for the leader remain unresolved. Generating complete threshold signatures requires computational complexity of O(N³) for the leader. In contrast, the use of threshold signatures in LTSBFT, limited to the committee layer, significantly reduces computational resource consumption.

4.4. Scalability Analysis

According to the previous description, there are a total of N_L leaders, N_S supervisory nodes, and N_f followers in each group, and S leaders are selected to send commit messages to replica-layer nodes. Assuming the number of followers in each group is equal, the total number of followers in the network is Z = N_L N_f.

In the pre-prepare and prepare phases, leaders generate the threshold signature and the communication overheads are $N_L\left(N_L-1\right)+N_L={N_L}^2$. In commit phase, the selected leaders broadcast commit messages to the corresponding nodes in the replica layer. The communication overheads in the commit phase are $N_L{N}_f+S{N}_S=Z+S{N}_S$. In the follower reply phase, once the followers successfully verify the threshold signature, they reply to the corresponding leader; the supervisory nodes successfully verify the threshold signature, and they broadcast scommit messages to all followers and replies to all leaders. The communication overheads in the follower reply phase are $\mathrm{Z}+N_S\mathrm{Z}+N_L{N}_S=Z+N_S(Z+N_L)$. In the leader reply phase, when leaders receive a reply from more than half of the followers within the same group, leaders reply to clients. The communication overheads in leader reply phase are $N_L$. To sum up, the total communication overheads for LTSBFT are $\left(2+N_S\right)Z+{N_L}^2+\left(S+N_L\right)N_S+N_L$. Since $N_S\approx S<N_L\ll Z$, the LTSBFT consensus communication complexity is O(N).

Finally, the scalability of LTSBFT is evaluated by comparing the communication overheads of LTSBFT with that of HotStuff, double-layer PBFT, and PBFT. In this case, when calculating the communication overheads of double-layer PBFT, the node distribution is based on the equation $N^3+3N^2+N=2M-1(3\le N\le (M-4)/3)$ given in [8], which has a minimum communication complexity of O(N^4/3). Here, N and M denote the number of nodes in the network and the number of nodes within groups, respectively. Furthermore, in the actual calculation, the number of nodes within groups is taken as a positive integer closest to n. In the LTSBFT consensus algorithm, N_L = 11, N_S = 3, and S = 3. The comparison results of scalability are shown in Figure 5.

4.5. Communication Overheads Analysis under Attacks

Based on the LTSBFT consensus algorithm, the replica-layer nodes feedback the NodeID set of malicious nodes to the committee-layer nodes, which is embedded within the freply (sreply) messages. To determine the NodeID of malicious leaders, leaders, excluding the malicious ones, reach consensus on the NodeID set of malicious nodes during the generation of threshold signatures within the committee layer. Therefore, only leaders broadcasting freply (sreply) messages pose additional communication overheads. Assuming that malicious nodes do not broadcast the correct commit (scommit) messages to any node, the communication overheads to reach the consensus of malicious supervisory nodes are (N_L − 1)(N_L − 1)Z/N_L $\approx$ N_LZ, and the communication overheads to reach the consensus of malicious leaders are (N_L − 1)(N_L − 1)Z/SN_L $\approx$ N_LZ/S. Since the number of supervisory nodes is fewer, the communication overheads on sreply messages broadcasted by leaders can be ignored. Therefore, the communication complexity of the LTSBFT to reach consensus of malicious leaders is at linear level.

Based on the PBFT consensus algorithm, reaching consensus on malicious leaders requires followers to multicast evidence to the other followers, and therefore requires O(N³) communication complexity. Based on the double-layer PBFT consensus algorithm, the followers confirm malicious leaders within the group, and then the newly elected leader confirmation is embedded within the pre-prepare messages. Therefore, the communication complexity under attacks is O(N_L³ + N_L²M), where N_L and M are the number of leaders and the number of followers within a group, respectively. Moreover, the replacement of leaders in double-layer PBFT will be more frequent than PBFT due to its multiple leaders.

In the HotStuff consensus algorithm, view-change requires O(N) communication complexity. Once the leader may not multicast prepareQC to replicas, nodes of unlocked view launch view-change to ensure liveness after awaiting a maximum network latency. In this case, the consensus efficiency will be reduced. Moreover, the HotStuff consensus algorithm may consecutively change f + 1 (where f = ⌊N/3 + 1⌋) views consensus to commit a request, which causes the consensus efficiency to decrease dramatically.

Although the LTSBFT consensus algorithm re-selects the leaders, resulting in a decrease in throughput, multiple groups simultaneously select leaders by mining, effectively improving the efficiency of selecting leaders. Followers mining to compete for the leader makes the followers with greater computational power more likely to be selected as leaders. Therefore, leaders will be less probable to encounter crash errors. Furthermore, the LTSBFT consensus algorithm only requires linear complexity to reach consensus on Byzantine leaders.

5. Experimental Results

In this section, we implement a test of the performance of the LTSBFT consensus protocol. We use the Golang programming language to implement LTSBFT by listening to multiple TCP ports on the same host to simulate a multi-nodes environment. Specifically, each node is assigned a local loopback address and different port numbers, with nodes communicating by TCP connections. The performance tests include two cases: (1) a performance test without faulty nodes; and (2) a performance test with faulty nodes. In order to simulate an impact on the network consensus in the presence of an attack scenario, a leader that sends commit messages to the replica-layer nodes is designated as a Byzantine node. The attack of Byzantine nodes on the execution of the LTSBFT consensus protocol is simulated by sending error consensus messages.

For the testing of the performance of the LTSBFT consensus algorithm, two critical indicators are included: (1) latency refers to the time (ms) elapsed from the client sending a request to the client receiving the latest reply; and (2) throughput refers to the number of consensus messages processed per second in the system (op/s). The performance of the LTSBFT consensus algorithm is evaluated by comparing it with the PBFT and HotStuff consensus algorithms under the same parameter configuration.

5.1. Latency Test

The latency comparison of the LTSBFT consensus algorithm with the HotStuff and PBFT consensus algorithms at the same number of nodes is shown in Figure 6. In this test, the LTSBFT consensus algorithm takes N_L = 11, N_S = 3, and S = 3. Starting with 66 nodes, the number of nodes in each group is increased by one each time to achieve a gradual increase in the number of nodes in the network.

The advantage of the LTSBFT consensus algorithm in terms of latency can be shown by Figure 6. The LTSBFT consensus is consistent with the HotStuff consensus algorithm, and their consensus latency increases linearly with the number of nodes. However, the communication latency of the LTSBFT consensus algorithm is lower than that of the HotStuff and PBFT consensus algorithms under the same number of nodes. Meanwhile, it can also be shown by Figure 6 that malicious attacks on Byzantine nodes do not cause a large impact on the communication latency of the LTSBFT consensus algorithm.

In order to test the effect of different node topologies on the latency performance, the LTSBFT consensus algorithm takes N_S = 3, S = 3, and N = 135 and the followers are evenly distributed in each group. The consensus latency of the LTSBFT consensus algorithm is measured by varying the number of leaders, and the results are shown in Figure 7.

As can be shown in Figure 7, without changing the number of selected leaders who send commit messages to replica-layer nodes and the number of supervisory nodes, different numbers of leaders do not have a significant impact on the consensus latency. Moreover, in the case of varying the number of leaders, the attacks of the malicious leader who sends commit messages to Replica nodes does not have a significant impact on the consensus latency.

To test the effect of communication load on the consensus latency, the communication latency of client requests of different sizes for inter-node consensus is recorded. Without changing the node LTSBFT node topology and the number of nodes, the recorded results are shown in Figure 8. Here, the LTSBFT consensus algorithm takes N_S = 3, S = 3, N_L = 11, and N = 135. The HotStuff and PBFT consensus algorithms take N = 135.

As shown in Figure 8, the consensus latency increases steadily with the increase in communication load. Moreover, the consensus latency of the LTSBFT consensus algorithm is significantly lower than the consensus latency of the HotStuff and PBFT consensus algorithms, regardless of whether LTSBFT operates in the Byzantine scenario or not. Therefore, it can be concluded that the LTSBFT consensus algorithm has better latency performance compared to the HotStuff and PBFT consensus algorithms under different communication loads.

5.2. Throughput Test

The throughput performance is tested using the same number of nodes. The parallel processing capability of the LTSBFT consensus algorithm for transactions is evaluated by comparing the throughput of LTSBFT with that of the HotStuff and PBFT consensus algorithms. The throughput measurement results are shown in Figure 9. In this test, the LTSBFT consensus algorithm takes N_L = 7, N_S = 2, and S = 2. Starting with 42 nodes, the number of nodes in each group is increased by one each time to achieve a gradual increase in the number of nodes in the network.

It can be seen from Figure 9 that the throughput of the LTSBFT consensus algorithm is significantly greater than the throughput of the HotStuff and PBFT consensus algorithms. The attack of Byzantine nodes does not have a significant impact on the throughput of the LTSBFT consensus algorithm. Therefore, it can be concluded that the LTSBFT consensus algorithm has excellent parallel processing capability for transactions.

In order to test the effect of communication load on the throughput, the throughput of client requests of different sizes for inter-node consensus is recorded without changing the node LTSBFT node topology and the number of nodes. The recorded results are shown in Figure 10. The LTSBFT consensus algorithm takes N_S = 2, S = 2, N_L = 7, and N = 77. The HotStuff and PBFT consensus algorithms take N = 77.

As shown in Figure 10, the throughput decreases as the communication load increases. The throughput of the LTSBFT consensus algorithm is significantly higher than that of the HotStuff and PBFT consensus algorithms under different loads. Therefore, it can be concluded that the LTSBFT consensus algorithm has improved transaction parallel processing capability compared to the PBFT and HotStuff consensus algorithms under different communication loads.

6. Conclusions

In this paper, a low-latency scalable dynamic LTSBFT consensus algorithm with high fault tolerance is proposed. Firstly, the LTSBFT consensus algorithm achieves consensus linear complexity through the utilization of threshold signature technology. Secondly, the mutual supervision feedback mechanism among nodes ensures that reaching consensus on faulty upper-layer nodes during view changes is accomplished with linear complexity. Finally, a node dynamic protocol is proposed for the first time to support dynamic changes in the number of nodes during the consensus process. That is to say, consensus can still be reached when the number of nodes dynamically changes, without interrupting the client’s request for consensus in the network. The LTSBFT can be used in various fields such as the Internet of Things or blockchains. However, it still has some deficiencies, such as the problem of efficiency under attacks. Once most nodes corporately launch an attack in the committee layer, the LTSBFT will transform to the PBFT consensus algorithm, resulting in performance degeneration. Thus, in the future, we will improve its ability in resisting collusion attacks.