An efficient dynamic BFT consensus implementation method suitable for alliance chain

Abstract

The present application relates to the field of block chain, and discloses a kind of efficient dynamic BFT consensus implementation method suitable for alliance chain, for solving when node carries out dynamic participation or exit, the total number of committee node constantly changes and cannot be predicted in advance, corresponding static BFT consensus protocol loses activity problem, including, the protocol in network is initialized, node in network is main node election, node is set dynamic consistency protocol, dynamic consistency protocol includes general flow and fast flow, the dynamic consistency protocol set is embedded in the communication flow of traditional byzantine fault tolerance protocol, and dynamic BFT protocol is obtained, the uncertainty of committee node state in real scene is fully considered, and the problem of dynamic participation of committee node is effectively solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of blockchain, more particularly to an efficient dynamic BFT consensus implementation method suitable for consortium chain. BACKGROUND

[0002] Consortium chain is a type of blockchain, which is between public chain and private chain, mainly applied to the collaborative scenario between partners requiring partial trust. Consortium chain is usually managed by multiple institutions or organizations, and is not completely open. Each participating institution or organization has the right to join the network, but external users have no direct access.

[0003] The BFT consensus protocol in the traditional consortium chain adopts a static committee, that is, the number of committees N is always fixed. In a synchronous network environment with no communication delay, for each newly generated block, the committee members vote, and when the committee collects more than N / 2 consistent voting opinions, the legal evidence of the validity of the block is formed, and the block can be safely submitted.

[0004] For example, the invention patent announcement with the announcement number: CN117792608A, an optimized asynchronous BFT consensus implementation method suitable for consortium chain, includes: after completing initialization, transaction packaging and block generation, after using consistency broadcast, verification and voting, each node uses GPC sub-protocol based on consistency confirmation and submission of the block. The DAG chain structure adopted by the present application not only retains the block of each node proposal to improve transaction throughput, but also can use the reference relationship of DAG nodes to promote the protocol; based on consistency broadcast (CBC) and global perfect coin throwing (GPC), the safety of the asynchronous consensus protocol is guaranteed, the directed acyclic graph DAG is used as the topology structure of the chain, the reference relationship of the DAG edge is used as part of the voting in the BFT consensus, the running efficiency of the asynchronous BFT consensus protocol is accelerated, and the communication complexity of the consensus protocol is reduced.

[0005] For example, the invention patent announcement with the announcement number: CN117424692A, a consortium chain consensus method and system based on partition technology, includes: a double-layer consensus framework based on linear BFT is designed, and an innovative partition architecture is adopted to divide network nodes into different partitions to realize parallel consensus of the partitions; at the same time, the global state consistency is guaranteed by constructing an upper layer partition, and a linear BFT consensus scheme is proposed to solve the high communication complexity O(n2) problem of the traditional consortium chain PBFT type consensus mechanism, which greatly improves the consensus efficiency and scalability in large-scale scenarios. In addition, in order to improve the throughput and performance of the consortium chain, a general modular Byzantine consensus protocol library is designed. This scheme can effectively solve the problem of scalability of the traditional consensus mechanism, and is suitable for various partition consortium chain systems, used for coordinating nodes to reach consensus on messages, and has wide applicability.

[0006] But in the process of implementing the technical scheme of the embodiment of the application, the application finds that the above-mentioned technology at least has the following technical problems:

[0007] However, in reality, nodes will join or exit the protocol operation due to network problems or hardware failures, etc. When the nodes participate dynamically, the total number N of committee nodes constantly changes and cannot be predicted in advance, the original static threshold N / 2 cannot be achieved, and the corresponding static BFT consensus protocol loses activity. The application is based on the realization of the traditional PBFT consensus and dynamic consensus sub-protocol, fully considers the uncertainty of the state of the committee nodes in the real scene, solves the problem of dynamic participation of the committee nodes under the sleep model, and has safety, efficiency and dynamics. SUMMARY

[0008] In order to overcome the above-mentioned defects of the prior art, the application provides a high-efficiency dynamic BFT consensus implementation method suitable for a consortium chain to solve the problems in the above background art.

[0009] To achieve the above object, the application provides the following technical scheme:

[0010] A high-efficiency dynamic BFT consensus implementation method suitable for a consortium chain, comprising the following steps: step 1, initializing the protocol in the network; step 2, electing the master node in the network; step 3, setting a dynamic consensus protocol for the node, the dynamic consensus protocol comprising a general flow and a fast flow; and step 4, embedding the dynamic consensus protocol set in step 3 into the communication flow of the traditional Byzantine fault-tolerant protocol to obtain a dynamic BFT protocol.

[0011] Preferably, the step of initializing the protocol in the network is: setting the maximum delay time of the protocol, ensuring that the message is delivered within the maximum delay time, and the protocol is realized based on the lockstep synchronization network, so that the local clocks maintained by each node are basically consistent; initializing the committee when the protocol starts, so that the number of nodes in the committee is N, and the number of nodes in the committee is public, and each node has a unique number; setting the communication network as a p2p network, and each node in the network accesses the network through the flooding mode and delivers the received message; before the protocol runs, each node generates its own public key and private key locally, and uses the public key as the identity information, and each node broadcasts its own public key to the whole network during the initialization of the protocol; setting the current round of the protocol as the initialization view number, and increasing the view number each time the master node is changed or a new round of block proposal starts; each node collects the transaction record transaction pool in the network, and the subsequent node packs the block from the transaction pool; during the network operation, if there is a protocol joining or exiting the network, a constraint condition of an honest majority is set.

[0012] Preferably, the nodes collect transaction records in the network into a transaction pool, and the subsequent nodes take transactions from the transaction pool to package blocks, which includes the following steps: broadcasting user transactions to the entire network so that each node receives the transactions; temporarily storing the received transactions in the "transaction pool" and waiting for the nodes to include them in a block; the nodes select transactions from the transaction pool according to the transaction fees; the nodes arrange the selected transactions into a block data structure, and perform hash calculation on the block data to obtain a unique block hash value; after the nodes complete the packaging and verification of a block according to the block hash value, the nodes broadcast the block to the network to notify other nodes to update their blockchain records; other nodes verify the validity of the new block, and if the verification is valid, the block is added to the local blockchain ledger.

[0013] Preferably, the step of performing hash calculation on the block data to obtain a unique block hash value includes the following steps: obtaining each item of data in the block, including the hash of the previous block, the Merkle root, and the timestamp; and obtaining a unique block hash value according to each item of data by BH = H(PH + MR + TP + NO), where BH represents the unique block hash value, H is a hash function, PH is the hash value of the previous block, MR is the root hash value of all transactions in the block, TP is the timestamp of the block generation, and NO is a random number.

[0014] Preferably, the constraint condition of the honest majority is that the total number of online nodes n and the number of malicious nodes f t The number of online Byzantine nodes f at any time t t Cannot exceed half of the total number of online nodes n, that is

[0015] Preferably, the step of electing a master node in the network includes the following steps: initializing the round number of the view at the start of each election, which corresponds to the master node term in the current election round; all online nodes calculate a VRF value through a verifiable random function; each online node broadcasts the VRF value to the network after calculating the VRF value; all nodes in the network collect the broadcasted VRF values in the network and compare these values to select the node with the largest VRF value as the master node in this round, that is, the block generation node; generating a new block through the selected master node and broadcasting it, and the honest nodes in the network verify the new block and reach a consensus to add the new block to the blockchain after confirming the validity of the block; after the generation and confirmation of the block in this round are completed, the view number is updated, and at the start of the next election, all nodes calculate new VRF values again to select a new master node.

[0016] Preferably, the step of obtaining a VRF value by calculating a verifiable random function for all online nodes is as follows: obtaining the public key and private key of the node; the method for obtaining the VRF value based on the public key and private key of the node is VRF = H(Sig(sk, x)), where VRF represents the VRF value, H is a hash function, Sig is a digital signature function, sk is the private key of the node, and x is the input data.

[0017] Preferably, the general process steps are as follows: Step 3.1: When an online node enters the protocol, it sends an awake message with the following format:<awake,v,s,H(pre)> PK Where v is the current view number, s is the s-th step of the message in view v, H(pre) is the hash value of the latest state message pre of the node, and the index PK is the node's public key; the awake messages sent by online nodes are collected in a set Awk, and newly joined nodes update their current state after receiving information from the Awk set, while exiting nodes are automatically ignored; Step 3.2: All online nodes collect awake messages in the Awk set. If a new node joins or an existing online node exits, the original online committee node receives the input value b, verifies the correctness of b, and broadcasts a confirmation Echo message to the entire network. The newly joined node needs to download and receive historical data information and synchronize it to the latest state of the network in order to access consensus. Process; Step 3.3: When the number of Echo messages received by online nodes exceeds half of the online nodes, that is, when more than half of the nodes reach consensus, the nodes are considered to have reached consensus, and a signature QC containing the majority of nodes' agreement is generated and broadcast to the entire network; Step 3.4: Online nodes collect the QC messages broadcast by other online nodes, count the number of QC messages, and when the number of QC messages exceeds half, the final Agree credential is generated and broadcast. When the Agree credential reaches more than half, the consistency of the protocol is ensured and the process moves towards a decision; Step 3.5: When the Agree credential exceeds half of the online nodes, it is determined that the vast majority of nodes in the network have reached consensus on input b, and the input value b is taken as the final result of the protocol. The nodes finally output 1, confirming that consensus has been reached.

[0018] Preferably, the rapid process steps are as follows: the online node verifies the correctness of input b and broadcasts an Echo message, and counts the number of Echo messages; when the number of Echo messages reaches half, the node generates a QC certificate; when the number of QC certificates exceeds half of the online nodes, an Agree certificate is generated and broadcast; after receiving more than half of the Agree certificates, the online node confirms that the protocol has been agreed upon, outputs result 1, and completes the input confirmation.

[0019] Preferably, the dynamic BFT protocol step is: the PROPOSE stage: the master node is selected by a verifiable random function VRF every round; if a new node joins or an old node exits in the proposal stage, the dynamic consensus protocol is used to synchronize the latest state of the new node and make the network adjust the state to reflect the current number of online nodes; the PREPARE stage: the node receiving the proposal verifies whether the new block meets the protocol requirements, and broadcasts the "PREPARE" message after confirmation; if the network receives more than half of the PREPARE messages, the node determines that the proposal block has reached preliminary consensus; the COMMIT stage: after receiving more than half of the PREPARE messages, the node sends the "COMMIT" message, and when more than half of the nodes send the "COMMIT" message, the block is recorded in the ledger, and the consensus is reached; when a node exits or a new node joins in the COMMIT stage, the dynamic protocol ensures that each honest node sends or receives the COMMIT message according to the latest state.

[0020] The one or more technical solutions provided in the embodiments of the application have at least the following technical effects or advantages:

[0021] 1. The protocol in the network is initialized, and the basic protocol rules are set for the network nodes. Through initialization, it is ensured that each node can run on the same basis, laying the foundation for subsequent protocol operation; consistency and efficiency are provided for the entire consensus process, avoiding communication delay or node synchronization situation, and after initialization, the network enters the lockstep synchronization state, ensuring the correct operation of the protocol.

[0022] 2. The master node is elected in the network, and a master node is selected in the network to bear the responsibility of generating new blocks, proposals and leading consensus processes. The master node is selected by a verifiable random function (VRF), making it difficult to predict the master node and reducing the risk of attacks by malicious nodes; the network security and attack resistance are enhanced. Dynamic election can effectively avoid the targeted attacks that the fixed master node may suffer, and increase the reliability and fairness of the network.

[0023] 3. The dynamic consensus protocol is set for the nodes, and a protocol mechanism is established, so that honest nodes can reach consensus on network input values in the case of dynamic participation of nodes. This includes broadcasting clear state, real-time adjustment of protocol rules, etc., to ensure that nodes can still synchronize and reach consensus even in the case of joining or exiting; improve the flexibility and scalability of the network, support dynamic joining or exiting of nodes. At the same time, in the face of partial node failures or malicious behavior, consistent consensus can still be achieved, ensuring the normal operation of the network.

[0024] 4, the dynamic consistency protocol is embedded into the communication process of the traditional byzantine fault tolerance protocol, a dynamic BFT protocol is obtained, the dynamic consistency protocol is integrated into the communication process of the traditional byzantine fault tolerance protocol PBFT, so that PBFT remains active and consistent in the case of dynamic change of nodes. PBFT reaches consensus through the proposal of the master node and the voting of other nodes, and the dynamic protocol is embedded in each process to better adapt to the node change of the network; the high security of PBFT and the adaptability of the dynamic consistency protocol are combined, so that the BFT protocol has dynamic fault tolerance capability and can maintain safe and effective consensus operation in the case of dynamic change of nodes. BRIEF DESCRIPTION OF DRAWINGS

[0025] Figure 1 A high-efficiency dynamic BFT consensus implementation method suitable for alliance chain is provided.

[0026] Figure 2 A dynamic consistency protocol flowchart.

[0027] Figure 3 A dynamic BFT protocol general flowchart.

[0028] Figure 4 A dynamic BFT protocol fast flowchart. DETAILED DESCRIPTION

[0029] The technical solutions in the application will be described clearly and completely in combination with the drawings in the application, and additionally, the forms of each structure described in the following embodiments are only examples, and the high-efficiency dynamic BFT consensus implementation method suitable for alliance chain is not limited to each structure described in the following embodiments, and all other embodiments obtained by those skilled in the art without creative labor belong to the protection scope of the application.

[0030] The application provides a high-efficiency dynamic BFT consensus implementation method suitable for alliance chain, which comprises the following steps:

[0031] Step 1: initializing the protocol in the network.

[0032] In the embodiment, it is particularly pointed out that the step of initializing the protocol in the network is:

[0033] The maximum delay time specified by the protocol is set, it is ensured that any message can be sent within the maximum delay time, and the protocol is realized based on the lockstep synchronization network, so that the local clocks maintained by each node are basically consistent, and this assumption facilitates the design of the consensus protocol, because the communication pace of all nodes is consistent, and the uncertainty caused by network delay is avoided;

[0034] At the start of the protocol, the committee is initialized, the number of nodes in the committee is N, and the number of nodes in the committee is public and defined in advance in the network, each node is numbered from 1 to N, and it is ensured that each node has a unique number;

[0035] The communication network is set to a p2p network, each node in the network accesses the network by flooding and delivers the received message, before the protocol runs, the node needs to generate its own public key and private key locally, and uses the public key as the identity information, each node broadcasts its own public key to the whole network at the initialization of the protocol, so that other nodes can identify and authenticate, in this way, all nodes can identify and establish trust with each other when joining the consensus network;

[0036] The current round of the protocol is set, denoted as the initialization view number, the view number is a counter used to identify the current round in the consensus protocol running process, the view number will increase each time the master node is changed or a new round of block proposal starts. The initialization view number is usually set to 0 or other starting value to ensure that the protocol starts from a unified starting point, and the main function of the view number is to help all nodes in the network keep synchronized, so that each node knows which round of consensus phase is currently being carried out. The existence of the view number allows the protocol to switch to the next view when the master node crashes or the network is partitioned, so as to select a new master node to continue the consensus process, this process is also called view switching;

[0037] Each node collects the transaction record transaction pool in the network, and the subsequent node takes out the transaction from the transaction pool to pack the block.

[0038] It is stipulated that the protocol can be added or removed from the network at any time, and the protocol sets an honest majority constraint condition to maintain network security, the honest majority constraint condition is that the total number of online nodes n and the number of malicious nodes f t , and represents that at any time t, the number of online Byzantine nodes f_t cannot exceed half of the total number of online nodes n.

[0039] The lockstep synchronization network is a model that assumes no delay in network communication, allowing the nodes of the protocol to operate synchronously within a fixed step (lockstep). Each node completes the same operation process at each time step, which means that messages can be reliably delivered and processed within a fixed time interval, ensuring that nodes can execute protocol operations at the same pace, thereby maintaining consistency in the network.

[0040] A Byzantine node is a node in a distributed network that is maliciously manipulated or malfunctioning. These nodes do not follow the normal operation of the network protocol and may send incorrect, false or conflicting information, trying to influence the decision and consensus of other nodes. Byzantine nodes may cause confusion or false consensus among other nodes in the network by dishonest behavior or intentionally sending inconsistent data

[0041] In this embodiment, it needs to be specifically pointed out that each node collects the transaction records in the network, and the subsequent node takes out the transactions from the transaction pool to package the block as follows:

[0042] In a blockchain network, users constantly send transactions such as transfers, contract calls, etc. First, these transactions are broadcast to the entire network, so that each node will receive these transactions; the received transactions are temporarily saved in the "transaction pool" and wait for the node to be included in a block. The transaction pool can be understood as a list of transactions to be processed;

[0043] The node selects valid transactions that meet the block size or specific protocol conditions from the transaction pool according to the transaction fee. The selection process usually prioritizes transactions with high transaction fees because the node wants to earn more transaction fees; select transactions that meet the block size or specific protocol conditions to ensure that the block does not exceed the allowed size;

[0044] The node arranges the selected transactions into a block data structure, and each block contains a series of information such as the hash of the previous block, all transaction records in the block, the timestamp, and some protocol-specified metadata;

[0045] To ensure data integrity and prevent tampering, the node performs a hash calculation on the block data to obtain a unique block hash value for the block;

[0046] After the node completes the packaging and verification of a block, it broadcasts the block to the network to notify other nodes to update their blockchain records and ensure network consistency; other nodes will verify the validity of the new block, such as whether the transaction is legal, the block hash is correct, etc., and add the block to the local blockchain ledger.

[0047] In this embodiment, it needs to be specifically pointed out that the node performs a hash calculation on the block data to obtain a unique block hash value for the block as follows:

[0048] Obtain each item of data in the block, including the hash of the previous block, the Merkle root, the timestamp, etc.

[0049] The method for calculating the block hash value unique to the block according to various data is BH=G(PH+MR+TP+NO), where BH represents the block hash value unique to the block, H is a hash function, PH is the hash value of the previous block, MR is the root hash value of all transactions in the block, TP is the timestamp of the block generation, and NO is a random number, which is usually used to meet the hash condition required by a specific consensus mechanism (such as proof of work).

[0050] Step 2: Master node election for nodes in the network.

[0051] In this embodiment, it needs to be specifically pointed out that the master node election step for nodes in the network is:

[0052] At the beginning of each round of election, the round number of the view is initialized, and the round number corresponds to the master node term in the current election round. The round number of the view is used to mark the order of the current master node, ensuring that the election is conducted consecutively between rounds.

[0053] All online nodes calculate a VRF value through a verifiable random function to participate in the election of the master node. The VRF value is equivalent to the "score" of the online node in this round, and the VRF value has randomness and unpredictability, so different master nodes will be produced in each election. The online node refers to the node that is currently in a running state and can participate in the protocol process.

[0054] After each online node calculates the VRF value, it broadcasts the VRF value to the network.

[0055] All nodes in the network collect the broadcasted VRF values in the network and compare these values, and select the node with the largest VRF value as the master node of this round, i.e., the block generation node. The master node will be responsible for generating a new block and submitting it to the network.

[0056] The selected master node generates a new block and broadcasts it, and the honest nodes in the network will verify the new block and reach a consensus after confirming the validity of the block, adding the new block to the blockchain. Honest nodes refer to nodes that follow protocol rules and perform tasks in good faith. Their handling of data is open, transparent, and unbiased, and there is no malicious behavior such as tampering, discarding, or forging transactions.

[0057] Once the block of this round is generated and confirmed, the view number is updated, and when the next round of election begins, all nodes calculate new VRF values again to select a new master node for the next round.

[0058] In this embodiment, it needs to be specifically pointed out that the step of all online nodes calculating a VRF value through a verifiable random function is:

[0059] Obtaining the public key and the private key of the node, for encryption and verification;

[0060] The method for obtaining the VRF value according to the public key and the private key of the node is VRF = H (Sig (sk, x) ), wherein VRF represents the VRF value, H is a hash function method, Sig is a digital signature function, sk is the private key of the node, and x is input data, which is usually a view number or a round identifier.

[0061] Step 3: Setting a dynamic consensus protocol for the node, such as Figure 2 As shown in the figure, the dynamic consensus protocol includes a general process and a fast process.

[0062] The dynamic consensus protocol is a distributed consensus protocol that ensures that consensus can still be reached in the case of dynamic joining or exiting of nodes. The protocol dynamically adjusts the consensus mechanism according to the fluctuation degree of the nodes through two modes of general process and fast process, so as to ensure that the system can reach stable consensus at any time.

[0063] The dynamic consensus protocol has two operation modes: general process and fast process, which are suitable for the cases of large and small fluctuations of nodes, respectively.

[0064] In this embodiment, it needs to be specifically explained that, as shown in Figure 3 The general process steps are as follows:

[0065] Step 3.1: The online node sends an "awake state" message (awake message) when entering the protocol, to inform the network that it has joined or resumed the awake state, and the message format is <awake, v, s, H (pre) > PK , wherein v is the current view number, s is the step s in the view v to which the message belongs, H (pre) is the hash value of the latest state message pre of the node, the subscript PK is the public key of the node, and the signature of the message sender to the message; The awake message sent by the online node is collected in a set Awk, and the Awk set represents the current active node list. The protocol only pays attention to the nodes that have been online since the beginning of this step and have been awake, and ignores the influence of the nodes that have joined or exited during the running on the consistency of the result. The newly joined node updates to the current state after receiving the information in the Awk set, and the exiting node is automatically ignored;

[0066] Step 3.2: All online nodes collect the awake message in the Awk set, if there is a new node joining and the original online node exiting, the original online committee node receives the input value b, verifies the correctness of b, and broadcasts the Echo message to the whole network to confirm that the node has received the input. The Echo message is equivalent to an acknowledgement signal, indicating that the node has confirmed the legality of the input value b, and the newly joined node needs to download and receive the past historical data information and synchronize to the latest state of the network in order to access the consensus process;

[0067] Step 3.3: When the number of received Echo messages exceeds half of the online nodes, that is, more than half of the nodes agree, the node is determined to reach a consensus, then a signature QC containing the majority node agreement is generated and broadcasted to the whole network, indicating that the preliminary consensus is reached and preparing for the next step;

[0068] Step 3.4: Online nodes collect QC messages broadcasted by other online nodes and count the number of QC messages; when the number of QC messages exceeds half, generate the final Agree certificate and broadcast it, indicating further consensus support, when the Agree certificate reaches more than half, then ensure the consistency of the protocol to the decision;

[0069] Step 3.5: When the Agree certificate exceeds half of the online nodes, it is determined that the majority of nodes in the network reach a consensus on the input b, and the input value b is taken as the final result of the protocol, and the node finally outputs 1 to confirm that the consensus has been reached.

[0070] In this embodiment, it needs to be specifically pointed out that, as shown in Figure 4 The fast process steps are:

[0071] Online nodes verify the correctness of the input b and broadcast Echo messages, and count the number of Echo messages;

[0072] When the number of Echo messages reaches half, the node generates a QC certificate, and when the number of QC certificates exceeds half of the online nodes, an Agree certificate is generated and broadcasted;

[0073] After receiving more than half of the Agree certificates, the node confirms that the protocol has reached a consensus, outputs the result 1, and completes the input confirmation.

[0074] Step 4: Embed the dynamic consensus protocol set in step 3 into the communication process of the traditional Byzantine Fault Tolerance (PBFT) protocol to obtain a dynamic BFT protocol.

[0075] The Byzantine Fault Tolerance (PBFT) protocol is a fault-tolerant consensus algorithm that ensures data consistency in a distributed network with partial malicious nodes. The PBFT protocol reaches consensus among honest nodes through three main stages: PROPOSE, PREPARE, and COMMIT. Even if no more than one-third of the nodes in the system are Byzantine (malicious or unreliable), the protocol guarantees the safety and correctness of the data. In each stage, nodes verify the validity of the proposal through message exchange, and eventually reach a consensus on the proposal with the support of a majority of honest nodes, thus achieving fault tolerance for the system.

[0076] Dynamic consensus protocols allow nodes to enter or exit the network at any time. Exiting nodes do not affect the consensus result, and new nodes can quickly synchronize to the latest state and join the consensus process. Even if there are malicious nodes that do not send messages, dynamic BFT protocols can ensure that the consensus process of online honest nodes is completed smoothly.

[0077] In this embodiment, it is necessary to specifically explain that the steps of obtaining the dynamic BFT protocol are:

[0078] The PROPOSE stage: In each round, the master node is selected by a verifiable random function (VRF). The master node is responsible for generating a new block and proposing it to other nodes. If new nodes join or old nodes exit during the proposal stage, the dynamic consensus protocol is used to synchronize the latest state of the new nodes, and the network adjusts the state to reflect the current number of online nodes.

[0079] The PREPARE stage: Nodes that receive the proposal verify whether the new block meets the protocol requirements, such as verifying the block signature, transaction legality, etc. After confirmation, they broadcast the "PREPARE" message. After receiving more than half of the PREPARE messages from the network, the node considers that the proposed block has reached preliminary consensus.

[0080] In the PREPARE stage, if the state of a node changes, the dynamic consensus protocol allows the new node to synchronize block data and prepare the state, and participate in the remaining protocol process. Byzantine nodes may intentionally not send "PREPARE" messages, but the dynamic protocol ensures that other honest nodes can reach consensus.

[0081] Commit phase: after receiving enough 'Prepare' messages, the node sends a 'Commit' message, indicating the final agreement on the block. Only when more than half of the nodes send the 'Commit' message, the block will be recorded in the ledger, reaching an irreversible consensus; when the node exits in the Commit phase or a new node joins, the dynamic protocol ensures that each honest node sends or receives the Commit message according to the latest state, maintains the stability of the consensus, and the existence of the Commit phase can guarantee that if the master node is a malicious node in the previous Prepare phase, it will not cause inconsistency of the block result, and the Commit phase is still based on the dynamic consensus protocol.

[0082] Finally: the above is only the preferred embodiment of the present application, and is not used to limit the present application, any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present application should be included in the protection scope of the present application.

[0083] The above is only a specific embodiment of the present application, but the protection scope of the present application is not limited to this, any person skilled in the art can easily think of changes or replacements within the technical range disclosed by the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. An efficient dynamic BFT consensus implementation method suitable for alliance chain, characterized in that, The method comprises the following steps: Step 1: initializing the protocol in the network; Step 2: master node election in the nodes in the network; Step 3: setting a dynamic consensus protocol for the nodes, wherein the dynamic consensus protocol comprises a general process and a fast process; The general process step is: Step 3.1: An online node sends an awake message when entering the protocol, with the message format where v is the current view number, s is the step number in view v that the message belongs to, is the hash value of the node's latest state message pre, and the subscript PK is the public key of the node. Awake messages sent by online nodes are collected in a set Awk, and a newly added node updates to a current state after receiving information in the Awk set, and an exiting node is automatically ignored; Step 3.2: all online nodes collect awake messages in the Awk set, if there is a new node joining or an original online node exiting, an original online committee node receives an input value b, verifies the correctness of b, broadcasts an Echo message for confirmation to the whole network, and a newly added node needs to download and receive past historical data information and synchronize to the latest state of the network so as to access the consensus process; Step 3.3: when the number of received Echo messages of the online node exceeds half of the number of online nodes, that is, more than half of the number of online nodes agrees, it is determined that the nodes reach an agreement, a signature QC containing the agreement of the majority of nodes is generated, and the QC is broadcasted to the whole network; Step 3.4: online nodes collect QC messages broadcasted by other online nodes, and generate a final Agree voucher when the number of QC messages exceeds half, and broadcast the Agree voucher, and when the Agree voucher exceeds half, the protocol reaches a decision; Step 3.5: when the Agree voucher exceeds half of the number of online nodes, it is determined that the majority of nodes in the network reach a consensus on the input b, and the input value b is taken as the final result of the protocol, and the node finally outputs 1 to confirm that the consensus has been reached; Step 4: embedding the dynamic consensus protocol set in step 3 into a communication process of a traditional Byzantine fault-tolerant protocol to obtain a dynamic BFT protocol; The dynamic BFT protocol obtaining step is: The PROPOSE stage: a verifiable random function VRF is used to select a master node in each round; If a new node joins or an old node exits in the proposal stage, the dynamic consensus protocol is used to synchronize the latest state of the newly added node, and the network adjusts the state to reflect the current number of online nodes; The PREPARE stage: the node receiving the proposal verifies whether the new block meets the protocol requirements, and broadcasts a "PREPARE" message after confirmation; if the network receives more than half of the PREPARE messages, the node determines that the proposal block preliminarily reaches a consensus; The COMMIT stage: after receiving more than half of the PREPARE messages, the node sends a "COMMIT" message, and when more than half of the nodes send the "COMMIT" message, the block is recorded in the ledger, and an unchangeable consensus is reached; when a node exits or a new node joins in the COMMIT stage, the dynamic protocol ensures that each honest node sends or receives the COMMIT message according to the latest state. 2.The method of claim 1, wherein: The protocol initialization step in the network is: The maximum delay time of the protocol is set to ensure that the message reaches within the maximum delay time, and the protocol is implemented based on the lockstep synchronization network to make the local clocks maintained by each node substantially consistent; When the protocol is started, the committee is initialized, the number of nodes in the committee is N, and the number of nodes in the committee is public, and each node has a unique number; The communication network is set to a p2p network, and each node in the network accesses the network through flooding and delivers the received message; Before the protocol runs, each node generates its own public key and private key locally, and uses the public key as the identity information, and each node broadcasts its public key to the entire network during the initialization of the protocol; The current round of the protocol is set, denoted as the initialization view number, and the view number is increased each time the primary node is changed or a new round of block proposal starts; Each node collects the transaction pool in the network, and subsequent nodes take out transactions from the transaction pool to pack blocks; During the operation of the network, if a protocol joins or exits the network, a constraint condition of an honest majority is set. 3.The method of claim 2, wherein, The step of collecting the transaction pool in the network by each node, and taking out transactions from the transaction pool by subsequent nodes to pack blocks is: Broadcast the user transaction to the entire network, so that each node will receive these transactions; temporarily save the received transactions in the "transaction pool", and wait for the node to include them in a block; The node selects transactions from the transaction pool according to the handling fee; The node arranges the selected transactions into a data structure of a block, and performs hash calculation on the data of the block to obtain a unique block hash value of the block; After the node completes the packing and verification of a block according to the block hash value, the node broadcasts the block to the network to notify other nodes to update their blockchain records; other nodes verify the validity of the new block, and if the verification is valid, the block is added to the local blockchain ledger.

4. The method of claim 3, wherein, The step of performing hash calculation on the data of the block to obtain a unique block hash value of the block is: Obtain each item of data in the block, wherein the items of data include the hash of the previous block, the Merkle root, and the timestamp; The method for obtaining the block hash value unique to the block according to various data is wherein BH represents the block hash value unique to the block, H is a hash function, PH is a hash value of a previous block, MR is a root hash value of all transactions in the block, TP is a timestamp of block generation, and NO is a random number. 5.The method of claim 2, wherein: The constraint condition of the honest majority is: Obtain the total number of online nodes n and the number of malicious nodes At any time t, the number of Byzantine nodes online f_t cannot exceed half of the total number of online nodes n, that is . 6.The method of claim 1, wherein: The step of electing the primary node in the network is: When each round of election starts, the round number of the view is initialized, and the round number corresponds to the primary node term in the current election round; All online nodes calculate a VRF value through a verifiable random function; Each online node broadcasts the VRF value to the network after calculating the VRF value; All nodes in the network collect the broadcasted VRF values in the network, and compare these values to select the node with the largest VRF value as the primary node in this round, that is, the block generation node; A new block is generated by the selected primary node and broadcasted, and honest nodes in the network verify the new block and reach a consensus to add the new block to the blockchain after confirming the validity of the block; After the generation and confirmation of the block in the current round are completed, the view number is updated, and when the next round of election starts, all nodes calculate new VRF values again to select a new primary node for the next round.

7. The method of claim 6, wherein the method is a high-efficiency dynamic BFT consensus implementation method suitable for a consortium chain. The step of calculating a VRF value by all online nodes through a verifiable random function is: Obtaining the public key and the private key of the node; The method for obtaining the VRF value according to the public key and the private key of the node is wherein VRF represents the VRF value, HMAC is a hash function-based message authentication code algorithm, sk is the private key of the node, and x is input data. 8.The method of claim 1, wherein the method is characterized in that: The fast flow step is: The online node verifies the correctness of the input b and broadcasts the Echo message, and counts the number of Echo messages; When the Echo message reaches half, the node generates the QC certificate, and when the QC certificate exceeds half of the online nodes, the Agree certificate is generated and broadcasted; After receiving more than half of the Agree certificate, the online node confirms that the protocol has reached an agreement, outputs the result 1, and completes the input confirmation.

Images