Keywords

1 Introduction

The emergence of Bitcoin in 2008 [18] opened up the era of blockchain technology, which is an ingenious innovation that realizes consensus among distributed nodes by combining P2P network, distributed database, consensus protocol, cryptography, game theory and so on. Serving as a distributed ledger maintained by multiple participants, blockchain has shown its great potential in cryptocurrencies, financial industry, internet of things (IoT) and many other scenarios.

Blockchain can be classified into permissionless and permissioned ones according to entry limitation for network nodes. In a permissionless blockchain such as Bitcoin and Ethereum [21], anyone can join the system without a specific identity, whereas in a permissioned setting, every node maintaining the public ledger has an identity, and this identity is known to any other nodes in the system even though they may not trust each other. With the development of blockchain technology, permissioned blockchain is gaining more and more attraction within business and financial fields for its efficiency and controllability.

In the design of blockchain, the consensus mechanism is a core part to reach an agreement on the global ledger. In traditional distributed systems like database and file system, Byzantine Fault Tolerance (BFT) protocols have been intensively studied. Normally, BFT protocols run among a fixed set of consensus nodes, and can finally reach deterministic consensus and high efficiency with the tolerance of less than 1/3 malicious nodes. Due to these merits, BFT protocols especially PBFT [8] and its derivatives [4, 19] are widely deployed to construct consensus mechanisms in permissioned blockchain systems, e.g. Hyperledger Fabric [1], Tendermint [13] et al.

1.1 Research on BFT Protocols

Classical BFT protocols need a leader to lead the consensus process, and it will be replaced if it is found faulty. PBFT [8] proposed in 1999 is a typical BFT protocol of such a case, and it is the first practical BFT protocol that works under weak synchronous network assumption. Later works extend PBFT to simplify the design and reduce the cost, e.g. Zyzzyva [12] proposed in 2007 allows clients to adopt proposals from the leader optimistically and solve the inconsistency if needed. However, the main problem for BFT protocols with a leader is its vulnerability when suffering DoS attacks [16].

Some leaderless BFT protocols have been constructed in the face of DoS attacks. HoneyBadger BFT [16] is the first practical asynchronous BFT protocol without a leader. It combines threshold encryption with an efficient realization of Asynchronous Common Subset (ACS), together with a random selection method for proposals. With these in hand, the communication cost of HoneyBadger BFT is greatly reduced. In 2018, Duan et al. [9] extended HoneyBadger BFT to BEAT by replacing its cryptography components. And BEAT provides different versions for various scenarios. Hashgraph [3] is another leaderless BFT protocol that takes advantage of a kind of gossip about gossip design to realize virtue voting, as a result, it saves much communication overhead.

Besides the single consensus scheme, BFT protocols are also introduced together with other consensus protocols to achieve better performance. Typical blockchain schemes including Byzcoin [11], RapidChain [22], Elastico [15] et al. combine proof-of-work (PoW) with BFT to achieve both security and efficiency. Apart from them, Cosmos [14] combines delegated proof-of-stack (DPoS) with BFT under the same consideration.

All BFT protocols listed above, however, can only support static setting in which network nodes are fixed, and they can not support dynamically changes of the consensus group without reconfiguring the whole system. Indeed, the change of consensus group for a permissioned blockchain system is of necessity in business and financial fields, and without support for dynamic property, the reconfiguration process may be burdensome and costly. On the other hand, how to detect inactive or even malicious nodes is also of great importance, but it is not referred in most BFT protocols. Based on these observations, we carry out this work to build an enhanced BFT protocol atop HoneyBadger BFT, and a comparison among related BFT protocols is shown in Table 1.

Table 1. Comparation among typical BFT protocols
Full size table

1.2 Our Contribution

  • We propose a new dynamic enhanced BFT (DEBFT) protocol under leaderless setting with O(N) communication complexity, which allows consensus nodes to dynamically join and leave the network.

  • We design Join and Quit protocol, providing detailed protocol procedures as well as data structures of relevant messages types. By Join and Quit protocol, DEBFT allows a consensus node to join or leave the consensus group without reconfiguring the whole system.

  • We describe the metrics to assess the behavior of a consensus node, and design Clear protocol to clear malicious or inactive consensus nodes out of the system to maintain its long-term benign work.

  • We analyze key properties of the DEBFT, including dynamic property, fairness, agreement, and total order.

1.3 Paper Organization

The rest of this paper is organized as follows. We start by introducing the system module (Sect. 2). After that, the overview of HoneyBadger BFT is described (Sect. 3), as well as the building blocks of this work (Sect. 4). Next, we give the detailed protocol design (Sect. 5) and its security analysis (Sect. 6), then we conclude the paper (Sect. 7).

2 System Module

Participants Definition. There are three kinds of participants in this system: client, dealer, and consensus node (noted as node in the following context for simplification). Here we depict their roles in our protocol.

  • Clients generate transaction requests and broadcast them to all nodes. Clients will also gather feedback from nodes. Enough signatures from different nodes on one transaction denote it has been output as a consensus result.

  • Dealer represents a trusted party providing validity check for nodes. Hence it is responsible for the initialization of the system and leads the dynamic joining process of nodes.

  • Nodes are validated by the dealer before joining the system. They will receive transactions from clients, then execute the protocol together to get the consensus result that decides which transactions should be output.

Timing Assumption. The system works under a partially synchronous network assumption [10]. For all nodes computation proceeds in synchronized rounds and messages are received by their recipients within some specified time bound. We assume that the nodes are equipped with synchronized clocks to guarantee this round synchronization. In our system, there exists an adversary. In every round of communication, the adversary can wait for the messages of the uncorrupted nodes to arrive, then decide on his computation and communication strategy for that round. The adversary can still ensure that his messages delivered to the honest nodes on time. Therefore we should always assume the worst case that the adversary speaks last in every communication round.

Security Module. Assuming that there exists an adversary willing to prevent the system from making consensus or to subvert the system, here gives the definition of its ability.

The adversary can completely control up to t corrupted nodes, and t satisfies \(3t+1\le n\) where n is the total number of consensus nodes. The controlled nodes are called faulty nodes standing on the opposite of honest nodes which totally obey the protocol. Faulty nodes can choose arbitrary malicious actions, including not responding, sending conflicting messages to different nodes, corrupting other nodes and so on.

3 Reviewing HoneyBadger BFT

HoneyBadger BFT is the first practical asynchronous BFT protocol. Clients in the network will send their transaction requests to all nodes, and nodes execute the BFT protocol in consecutive rounds. At the beginning of a round every node will raise its proposal and at the end of this round a common subset of proposals will be output as the consensus result. Figure 1 shows the basic working procedures. Next we will depict main components applied in HoneyBadger BFT.

3.1 Protocol Components

HoneyBadger BFT mainly consists of two components: threshold encryption and Asynchronous Common Subset (ACS). In every round, each node chooses a set of transactions as its proposal and encrypts it through threshold encryption scheme, then submits the ciphertext as input to ACS module and a common subset of these ciphertexts will be output. At last the subset will be decrypted still by threshold encryption scheme to get final consensus results.

HoneyBadger BFT uses the threshold encryption scheme TPKE from Baek and Zheng [2]. In the design of TKPE, to decrypt the ciphertext, at least \(t+1\) nodes need to get their decryption shares separately and combine them together. This design ensures that the adversary controlling less than t faulty nodes can not get the plaintext without the help of honest nodes. As TPKE is secure under the adaptive chosen ciphertext attack, its application in HoneyBadger BFT helps to realize censorship resilience property which prevents the adversary from delaying honest client requests on purpose. ACS is the main module to reach consensus among nodes. As Fig. 1 shows, it consists of Reliable Broadcast (RBC) module and Binary Agreement (BA) module. In HoneyBadger BFT, RBC module from Cachin and Tessaro [7] is used to transmit the proposal of each node to all other nodes. BA module from Mostéfaoui [17] is used to decide on a bit vector indicating which proposals should be output as the consensus result.

Fig. 1.
figure 1

HoneyBadger BFT

Full size image

3.2 Protocol Security Properties

On a high level HoneyBadger BFT satisfies below properties [16]:

  • (Agreement) If any correct node includes transaction tx into its consensus result, then every correct node includes tx into its consensus result.

  • (Total Order) If one correct node has output the sequence of transactions \(\langle tx_0, tx_1, \ldots tx_j \rangle \) and another has output \(\langle tx_0^\prime , tx_1^\prime , \ldots tx_j^\prime \rangle \), then \(tx_i = tx_i^ \prime \) for \(i \le min( j, j^\prime )\).

  • (Censorship Resilience) If a transaction tx is input to \(n-t\) correct nodes, then it is eventually output by every correct node. Intuitively this means the adversary cannot prevent a transaction from being output as a consensus result.

3.3 Limitations of HoneyBadger BFT

As the first practical asynchronous BFT protocol which guarantees both liveness and safety, HoneyBadger BFT has abundant application scenarios like banks and financial institutions. It is especially suitable for permissioned blockchain applications, where a fixed number of nodes are authorized to enter the system.

However, HoneyBadger BFT is a traditional static BFT protocol which means that it could not support a consensus node to join or leave the consensus group without reconfiguring the whole system. On the other hand, there may exist malicious or inactive nodes in the system, and the current protocol lacks the function to detect these faulty nodes to exclude them from the system, this may hamper the long-term benign working of the system.

Considering above limitations, this paper focuses on the dynamic property and clear function of BFT protocol. Through the application of cryptography components introduced in Sect. 4, together with rational protocol procedure, we construct the new protocol DEBFT which is based on HoneyBader BFT.

Fig. 2.
figure 2

The algorithm procedure of DTIBE

Full size image

4 Building Blocks

This section describes several cryptography components applied in our work. We will separately show their functions and details.

Dynamic Threshold Identity-Based Encryption (DTIBE). The threshold encryption scheme TPKE [2] in HoneyBadger BFT can only set the threshold parameter and define the consensus group during the configuration phase. We utilize the dynamic threshold identity-based (DTIBE) scheme from Susilo et al. [20] for its dynamic property, where after the initialization of the system, a sender can dynamically select the set of recipients as well as dynamically set the threshold t upon the creation of ciphertext. This character meets the need of joining and quitting of members in a working consensus system. Figure 2 shows the details.

Distributed Key Generation (DKG). HoneyBadger BFT uses BA to decide on a bit vector representing the proposals to be output. Its BA scheme uses the Boldyreva’s pairing-based threshold signature scheme [5] as a randomizer to build the common coin which can not support changes of consensus group flexibly. In this work we use the Distributed Key Generation (DKG) scheme from Gennaro et al. [10] to generate randomness and the updated BA is represented as \(\widetilde{{BA}}\) in our work. To distinguish from the primitive ACS in HoneyBadger BFT, we define the combination of RBC and \(\widetilde{{BA}}\) as Round Common Subset (RCS) in our scheme. Figure 3 shows the details to generate randomness by the DKG scheme.

Fig. 3.
figure 3

The common coin based on DKG

Full size image

Boneh-Boyen Short Signature Scheme. In Sect. 2, we assume the identity of a node can not be fabricated. For this purpose, a node needs to transmit kinds of messages to other nodes with its signature. In this work this is ensured by using the Boneh-Boyen short signature scheme [6], and its main procedures are shown in Fig. 4.

Fig. 4.
figure 4

Boneh-Boyen signature scheme

Full size image

5 Protocol Design

This chapter provides the detailed description of our dynamic enhanced BFT protocol DEBFT, including the initialization phase, regular consensus procedure and Join/Quit/Clear protocols for specific functions.

5.1 System Initialization

As mention in Sect. 3, there exist clients, a dealer, and consensus nodes in the system. In our system, \(D_{trust}\) represents the trusted dealer. N is the possible maximal number of nodes. n is the current number of nodes. Let \(P_{i}\) represents the ith node in the system, where \(i \in \{1,2,\cdots ,n\}\). t is the maximal number of faulty nodes, which satisfies \(t=\lfloor (n-1)/3 \rfloor \).

Before the system begins to work, each node \(P_i\) with identity \(ID_i\) will generate its signature key pair \((SIG_{{pk}_i}, SIG_{{sk}_i})\) by the Boneh-Boyen signature scheme. \(SIG_{{pk}_i}\) is the public key of node \(P_i\), and \(SIG_{{sk}_i}\) is its secret key to generate signature. \(D_{trust}\) verifies whether each node \(P_i\) should join the consensus group, then executes the DTIBE.Setup algorithm and broadcasts master public key MPK to all valid nodes in network. \(D_{trust}\) will generate and send the secret key \(d_{ID_i}\) for node \(P_i\) via the DTIBE.Gen algorithm. The public information of node \(P_i\) can be represented by a pair \((ID_{i},SIG_{{pk}_i})\) which is signed and bound by the \(D_{trust}\).

5.2 Regular Consensus Procedure

This part depicts the whole process for transactions to be confirmed. The consensus protocol proceeds in consecutive rounds. Assuming the current round is numbered as r, each node generates its proposal then the consensus protocol executes among all nodes. Finally the consensus result of round r is a common subset of the proposals. Figure 5 gives an intuitive representation of the whole procedure, detail steps are as follows.

  • \(\varvec{step\;1{:}\;Batch\; Selection}\)

  • Clients send requests to all nodes, and each node \(P_i\) stores enough requests in a local FIFO queue \(buf_i\). There is a properly set parameter B representing the batch size. \(P_i\) randomly selects B/n elements from the first B elements of \(buf_i\).

  • \(\varvec{step\;2{:}\;Threshold\; Encryption}\)

  • \(P_i\) chooses the decryption set and uses the DTIBE.Enc algorithm to encrypt the elements selected in step 1, and gets ciphertext \(v_i\) as output.

  • \(\varvec{step\;3{:}\;Agreement\;on\;Ciphertexts}\)

  • RCS[r] is responsible for generating the common subset of proposals for round r. In this phase n nodes run RCS[r] together, and each node \(P_i\) passes \(v_i\) as input to it. RCS[r] consists of n reliable broadcast instances \({\{RBC_i\}}_n\) to disseminate the n proposals and n binary agreement instances \(\{\widetilde{{BA}_i}\}_n\) to collect votes for the n proposals. Here node \(P_i\) is the sender of \(RBC_i\) and \(\widetilde{{BA}_i}\) decides whether its proposal will be accepted. Detailed process is listed as follows.

  • \(v_i\) is the input of \(RBC_i\), and \(RBC_i\) will disseminate it to all other nodes.

  • For node \(P_i\), upon delivery of \(v_j\) from \(RBC_j\), if input has not yet been provided to \(\widetilde{{BA}_j}\), then provide input 1 to \(\widetilde{{BA}_j}\). as referred previously DKG scheme is used to generate randomness during the process of \(\widetilde{{BA}_j}\).

  • Upon delivery of value 1 from at least \(n-t\) instances of \(\widetilde{BA}\), provide input 0 to each instance of \(\widetilde{BA}\) that has not yet been provided input.

  • Once all instances of \(\widetilde{BA}\) have completed, get output from RCS[r]: an agreement on a common subset \({\{v_j\}}_{j\in S}\), where \(S\subset [1\ldots n]\) containing all indexes of each \(\widetilde{BA}\) that delivered 1.

  • \(\varvec{step\;4{:}\;Threshold\; Decryption}\)

  • Each node \(P_i\) uses DTIBE.ShareDec to calculate its decryption shares for \(v_j, j\in S\).

  • Each node \(P_i\) multicasts the shares to all other nodes.

  • For each element in \({\{v_j\}}_{j\in S}\), node \(P_i\) waits until receiving at least \(t+1\) valid shares, then uses DTIBE.Combine to get the plaintext \({\{y_j\}}_{j\in S}\).

  • Let \({\{block\}}_r = sorted(\cup {y_j}),j\in S\), such that \({\{block\}}_r\) is sorted in a canonical order (e.g., lexicographically).

  • \(P_i\) updates \(buf_i\) and gets ready for round \(r+1\).

Fig. 5.
figure 5

Regular consensus procedure

Full size image

5.3 Join Protocol

Join protocol is designed to allow a new node to join the network without stopping and reconfiguring the whole system.

Assuming there already exist n nodes in the system, a new node numbered as \(n+1\) is willing to join the system, which satisfies \(n+1\le N\). The protocol process is shown in Fig. 6 and we show the details as follows.

Fig. 6.
figure 6

Join protocol

Full size image

  • \(\varvec{step\;1{:}\;Join\;Request\;Phase}\)

  • Node \(P_{n+1}\) invokes KeyGen of Boneh-Boyen signature scheme to generate its key pairs \((SIG_{{pk}_{n+1}}, SIG_{{sk}_{n+1}})\).

  • Node \(P_{n+1}\) sends JoinReq to \(D_{trust}\).

    $$\begin{aligned} \begin{aligned} JoinReq= ((Join, SUB_{n+1}, SIG_{{pk}_{n+1}}, ID_{n+1}), SigGen(h(m), SIG_{{sk}_{n+1}})) \end{aligned} \end{aligned}$$
    (1)

Join is a message type. \(SUB_{n+1}\) is the materials submitted by \(P_{n+1}\) to be verified by \(D_{trust}\). \(SIG_{{pk}_{n+1}}\) is the public key of node \(P_{n+1}\). \(ID_{n+1}\) is the ID of \(P_{n+1}\). h(m) is the hash of the concatenation of the information above, and this applies to all h(m) in the following description. \(SigGen(h(m), SIG_{{sk}_{n+1}})\) is the signature of \(P_{n+1}\) on h(m).

  • \(\varvec{step\;2{:}\;Dealer\;Verify\;Phase}\)

  • After receiving JoinReq from node \(P_{n+1}\), \(D_{trust}\) firstly checks \(SUB_{n+1}\) to verify whether node \(P_{n+1}\) should join the system, then checks the correctness of \(SigGen(h(m), SIG_{{sk}_{n+1}})\).

  • If node \(P_{n+1}\) passes above verification, \(D_{trust}\) uses DTIBE.Gen to generate \(d_{ID_{n+1}}\) as the private key of node \(P_{n+1}\) in DTIBE scheme. Next \(D_{trust}\) sends JoinAcc with \(d_{ID_{n+1}}\) to node \(P_{n+1}\).

    $$\begin{aligned} \begin{aligned} JoinAcc = ((Accept,JoinReq), SigGen(h(m), SIG_{{sk}_{D_{trust}}})) \end{aligned} \end{aligned}$$
    (2)

Accept is a message type. \(SigGen(h(m), SIG_{{sk}_{D_{trust}}})\) is the signature of \(D_{trust}\) on h(m).

  • \(\varvec{step\;3{:}\;Node\;Accept\;Phase}\)

  • After receiving JoinAcc, Node \(P_{n+1}\) broadcasts JoinAcc to all nodes.

  • For each node \(P_i, i\in (1,\ldots ,n)\), after receiving JoinAcc from node \(P_{n+1}\), if the signature of \(D_{trust}\) is valid then replies NodeJoinAcc to node \(P_{n+1}\).

    $$\begin{aligned} \begin{aligned} NodeJoinAcc = ((JoinConf, ID_{n+1},ID_{i},r), SigGen(h(m), SIG_{{sk}_{i}})) \end{aligned} \end{aligned}$$
    (3)

JoinConf is a message type. \(ID_{i}\) is the ID of node \(P_i\). r is the current round number. \(SigGen(h(m), SIG_{{sk}_{i}})\) is signature of \(P_i\) on h(m).

  • After receiving \(2t+1\) NodeJoinAcc messages, node \(P_{n+1}\) packages and broadcasts them to all nodes and \(D_{trust}\). \(P_{n+1}\) will join the network from round \(r+2\). This design is to ensure that a node will only join the system from the beginning of a round, and ensures there exists at least the time of a round for messages to be delivered.

  • After receiving \(2t+1\) valid NodeJoinAcc, node \(P_i\) will include node \(P_{n+1}\) into the system from round \(r+2\).

5.4 Quit Protocol

Quit protocol is designed to allow a node to quit from the network without stopping and reconfiguring the whole system. When a node \(P_k, k\in (1,\ldots n)\) wants to leave the network, The protocol process is shown in Fig. 7 and below gives the details.

Fig. 7.
figure 7

Quit protocol

Full size image

  • \(\varvec{step\;1{:}\;Quit\;Request\;Phase}\)

  • Node \(P_k\) broadcasts QuitReq to all nodes in the system.

$$\begin{aligned} \begin{aligned} QuitReq = ((Quit,ID_{k},SIG_{{pk}_{k}}), SigGen(h(m), SIG_{{sk}_{k}})) \end{aligned} \end{aligned}$$
(4)

Quit is a message type. \(ID_k\) is the identity of \(P_k\) and \(SIG_{{pk}_{k}}\) is its public key. \(SigGen(h(m), SIG_{{sk}_{k}})\) is signature of node \(P_k\) on h(m).

  • \(\varvec{step\;2{:}\;Node\;Verify\;Phase}\)

  • For each node \(P_i, i\in (1,\ldots ,n)\) in the system, after receiving QuitReq from node \(P_{k}\), if the signature is valid replies NodeQuitAcc to node \(P_{k}\).

$$\begin{aligned} \begin{aligned} NodeQuitAcc = ((QuitConf,ID_{k},ID_i,r), SigGen(h(m), SIG_{{sk}_{i}})) \end{aligned} \end{aligned}$$
(5)

QuitConf is a message type. \(ID_i\) is the identity of node \(P_i\). r is the current round number. \(SigGen(h(m), SIG_{{sk}_{i}})\) is the signature of \(P_i\) on h(m).

  • \(\varvec{step\;3{:}\;Notify\;Phase}\)

  • After receiving \(2t+1\) NodeQuitAcc messages, node \(P_{k}\) packages and broadcasts them to all nodes and \(D_{trust}\). \(P_{k}\) will quit from the network from round \(r+2\).

  • After receiving the \(2t+1\) valid NodeQuitAcc message, node \(P_i\) will exclude node \(P_{k}\) from the network from round \(r+2\).

5.5 Clear Protocol

Clear protocol is design to exclude malicious or inactive nodes from consensus group. Before depicting details of Clear protocol, we describe how to evaluate actions of nodes to find faulty ones.

Firstly consider malicious behavior, if node \(P_i\) detects malicious behavior of node \(P_j\), it will invoke Clear protocol at once. Generally, malicious behavior includes below items:

  • The proposal of node \(P_j\) is finally output in the common subset, while it contains invalid transactions.

  • Node \(P_j\) is found sending conflicting messages to different nodes.

Another kind of faulty behavior is being inactive, which needs to be measured properly. Assuming w is number of rounds properly chosen, if during the most recent w rounds, node \(P_j\) output less than p proposals totally, then other honest nodes can invoke Clear protocol for it. Assume there already exist n nodes in the system and a node \(P_s, s\in (1,\ldots n)\) is detected as malicious or inactive. To keep the liveness and robust of the system, \(P_s\) needs to be cleared from the network. The protocol process is shown in Fig. 8 and the details is given as follows.

Fig. 8.
figure 8

Clear protocol

Full size image

  • \(\varvec{step\;1{:}\;Node\;Detect\;Phase}\)

  • Each node \(P_i\) evaluates actions of all nodes during consensus processes, and will note some nodes as inactive or malicious.

  • \(\varvec{step\;2{:}\;Node\;Request\;Phase}\)

  • If node \(P_i\) considers node \(P_s\) as malicious or inactive, it will send message ClearReq to \(D_{trust}\).

$$\begin{aligned} \begin{aligned} ClearReq = ((Clear,ID_{s},ID_i), SigGen(h(m), SIG_{{sk}_{i}})) \end{aligned} \end{aligned}$$
(6)

Clear is a message type. \(ID_s\) is the identity of the node to be cleared. \(ID_i\) is the identity of \(P_i\). \(SigGen(h(m), SIG_{{sk}_{i}})\) is signature of \(P_i\) on h(m).

  • \(\varvec{step\;3{:}\;Dealer\;Clear\;Phase}\)

  • If \(D_{trust}\) has received ClearReq about \(ID_s\) from more than t different nodes, it will broadcast ClearAcc to the whole network and add \(P_s\) into its blacklist.

$$\begin{aligned} ClearAcc=((Clr,ID_{s}), SigGen(h(m), SIG_{{sk}_{D_{trust}}})) \end{aligned}$$
(7)

Clr is a message type. \(SigGen(h(m), SIG_{{sk}_{D_{trust}}})\) is signature of \(D_{trust}\) on h(m).

  • \(\varvec{step\;4{:}\;Node\;Clear\;Phase}\)

  • After receiving ClearAcc about \(ID_{s}\) from \(D_{trust}\), node \(P_i\) will immediately clear \(P_s\) from its view of the network, and add it into its local blacklist.

6 Security and Performance

In this section, we will analyze several properties of the new scheme, including dynamic property, censorship resilience, agreement, and total order. We also show the performance and further consideration of DEBFT protocol.

6.1 Dynamic Property

Theorem 1

In an already working system, requests from nodes to join or leave the consensus group will finally take effect if and only if they are valid.

Proof

When a new node wants to join the system, the dealer will verify its request and sign if it is valid. Since the dealer is assumed to be reliable, nodes can trust the messages sent by the dealer with valid signatures. Next current consensus nodes will send NodeJoinAcc messages representing their acceptance. Later when every honest node receives NodeJoinAcc from \(2t+1\) nodes it can ensure at least \(t+1\) honest nodes has accepted this new node. This stands for the acceptance of the consensus group and every honest node will finally include the new node into the consensus group.

When a node currently in the consensus group wants to leave the system, it will broadcast QuitReq to all other nodes with its signature which cannot be fabricated. Other nodes will send NodeQuitAcc and finally receive at least \(2t+1\) NodeQuitAcc from other nodes. This quorum contains at least \(t+1\) honest nodes representing the acceptance of the consensus group and finally all honest nodes will exclude this node from the consensus group.

Since the dealer provides validation for new nodes, the sybil attack cannot take effect. And an honest node will only quit from the network by sending QuitReq by itself because its signature cannot be fabricated. In a word, only valid requests will finally take effect.

Theorem 2

The system could clear malicious and inactive nodes timely and correctly.

Proof

Through communication among nodes during the consensus process, malicious actions of faulty nodes could be detected by honest nodes, and inactive nodes could be detected through statistical results collected in recent rounds. All honest nodes will sponsor Clear protocol to exclude the malicious or inactive nodes from the system, and the dealer will receive enough signatures for a faulty node and process to clear it. On the other hand, the adversary could not attack an honest node to exclude it from the system, since the threshold is \(t+1\) and there are at most t malicious nodes.

6.2 Normal Consensus Properties

Theorem 3

The system satisfies censorship resilience property.

Proof

Due to DTIBE scheme applied in the protocol, at any time a node specifies the decryption set and a threshold t according to its view of all nodes. DTIBE scheme ensures the input to RCS protocol is secure under the adaptive chosen ciphertext attack, which can avoid the adversary from early getting the content of proposals and deliberately delaying a specific request. DKG scheme is adopted to generate randomness in \(\widetilde{BA}\) and it can effectively avoid any bias on randomness. These properties together guarantee that the final consensus result will not be manipulated by the adversary. Now let T be the size of requests previously input to any correct node before request m, since in every round, the number of committed requests has the same order with batch size B, then m will be committed within \(O(T/B + \lambda )\) epochs except with negligible probability, where \(\lambda \) is a security parameter.

Theorem 4

The system satisfies agreement property.

Proof

For the property of DKG all honest nodes in the system will generate the same unbiased randomness, which is resistant to the attack of \(t+1\) faulty nodes. Hence RCS protocol guarantees that in each round r a common subset will be output. If any honest nodes output request m, then m must be the plaintext of one component in the common subset of RCS[r]. According to the robustness of DTIBE scheme, every honest node will give their shares to decrypt the ciphertext to get request m, and m will finally be the output of all honest nodes.

Theorem 5

The system satisfies the total order property.

Proof

Firstly, since the system works in consecutive rounds, the consensus results of different rounds have an order. When considering the output requests in the same round, there exists an public ordering method(e.g., lexicographically), as a result all honest nodes will output requests in the same order.

The main consensus procedure of this new protocol inherits from HoneyBadger BFT, as a result DEBFT inherits the merits of its communication complexity which is O(N), detail proof is shown in [16].

6.3 Further Consideration

As defined in Sect. 2, DEBFT protocol works under a partial synchronous network. Compared to the asynchronous network assumption, this limitation is due to the work environment of DKG scheme applied in \(\widetilde{BA}\) [10]. It has been proved that the DKG scheme can safely work under a partially synchronous communication module. To extend DEBFT to asynchronous environment, we should find a way to generate randomness resistant to t malicious nodes under asynchronous assumption in a dynamic changing group. When still using DKG scheme, this can be solved by specifying the QUAL set before the beginning of a round, and one solution is to generate QUAL set from previous consensus result. This aspect could be further researched.

7 Conclusion

In this paper, we have proposed a practical dynamic enhanced BFT protocol. While reserving the merits of HoneyBadger BFT, through the combination of two appropriate cryptography components and rational protocol design, we realized dynamic joining and quitting functions for nodes and function to clear faulty nodes for the system. Analysis of several properties is given. It is believed that this new protocol has a wide range of application scenarios.