Efficient dynamic BFT consensus implementation method suitable for alliance chain

Abstract

The invention relates to the field of block chains, and discloses an efficient dynamic BFT consensus implementation method suitable for an alliance chain, which is used for solving the problems that when a node dynamically participates in or exits, the total number of committee nodes is continuously changed and cannot be predicted in advance, and a corresponding static BFT consensus protocol loses activity. A protocol in a network is initialized, main node election is carried out on nodes in the network, a dynamic consistency protocol is set for the nodes, the dynamic consistency protocol comprises a general process and a rapid process, the set dynamic consistency protocol is embedded into a communication process of a traditional Byzantine fault-tolerant protocol, and a dynamic BFT protocol is obtained. The uncertainty of the state of the committee node in a real scene is fully considered, and the problem of dynamic participation of the committee node is effectively solved.

Description

Technical Field

[0001] The present invention relates to the field of blockchain, and more specifically to an efficient dynamic BFT consensus implementation method suitable for alliance chains. Background Art

[0002] Consortium chain is a type of blockchain, which is between public chain and private chain. It is mainly used in scenarios that require partial trust and collaboration between partners. Consortium chain is usually jointly managed by multiple institutions or organizations and is not completely public. Each participating institution or organization has the right to join the network, but external users do not have direct access rights.

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

[0004] For example, the optimized asynchronous BFT consensus implementation method for alliance chain announced by the invention patent with announcement number CN117792608A includes: after initialization, transaction packaging and block generation are performed, and the generated blocks are broadcasted, verified and voted for in a consistent manner, and each node uses the GPC sub-protocol to confirm and submit the blocks in a consistent manner. The DAG chain structure adopted by the present invention not only retains the blocks proposed by each node to improve transaction throughput, but also can use the reference relationship of DAG nodes to promote the protocol; based on consistent broadcast (CBC) and global perfect coin tossing (GPC), the security of the asynchronous consensus protocol is guaranteed, the directed acyclic graph DAG is used as the topological structure of the chain, and the reference relationship of the DAG edge is used as part of the voting in the BFT consensus, which speeds up the operation efficiency of the asynchronous BFT consensus protocol and reduces the communication complexity of the consensus protocol.

[0005] For example, the alliance chain consensus method and system based on partition technology, which is announced by the invention patent announcement number CN117424692A, includes: designing a two-layer consensus framework based on linear BFT, and adopting an innovative partitioning architecture to divide network nodes into different partitions to achieve parallel consensus of partitions; at the same time, by building upper-layer partitions to ensure global state consistency, and proposing a linear BFT consensus solution to solve the high communication complexity O(n2) problem of the PBFT-type consensus mechanism of the traditional alliance chain, it greatly improves the consensus efficiency and scalability in large-scale scenarios. In addition, in order to improve the throughput and performance of the alliance chain, a general modular Byzantine consensus protocol library is designed. This solution can effectively solve the scalability problems of the traditional consensus mechanism, is applicable to various types of partitioned alliance chain systems, and is used to coordinate nodes to reach consensus on messages, and has a wide range of applicability.

[0006] However, in the process of implementing the technical solution of the invention in the embodiments of the present application, the present application found that the above technology has at least the following technical problems:

[0007] However, in reality, nodes may join or exit the protocol due to network problems or hardware failures. When nodes participate dynamically, the total number of committee nodes N changes constantly and cannot be predicted in advance. The original static threshold N / 2 cannot be reached, and the corresponding static BFT consensus protocol loses its activity. The present invention is based on traditional PBFT consensus and dynamic consistency sub-protocol implementation, fully considering the uncertainty of the state of committee nodes in real scenarios, and solving the problem of dynamic participation of committee nodes under the dormant model. The present invention is safe, efficient and dynamic. Summary of the invention

[0008] In order to overcome the above-mentioned defects of the prior art, the present invention provides an efficient dynamic BFT consensus implementation method suitable for alliance chain to solve the problems existing in the above-mentioned background technology.

[0009] To achieve the above object, the present invention provides the following technical solutions:

[0010] An efficient dynamic BFT consensus implementation method suitable for alliance chains includes the following steps: Step 1: Initialize the protocol in the network; Step 2: Elect the master node for the nodes in the network; Step 3: Set a dynamic consistency protocol for the nodes, and the dynamic consistency protocol includes a general process and a fast process; Step 4: Embed the dynamic consistency protocol set in step 3 into the communication process of the traditional Byzantine fault tolerance 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 to ensure that the message is delivered within the maximum delay time, and the protocol is implemented based on a lock-step synchronous network so that the local clocks maintained by each node are basically consistent; when the protocol starts, the committee is initialized so that the number of nodes in the committee is N, and the number of nodes in the committee is public, and each node is guaranteed to have a unique number; the communication network is set to a p2p network, and each node in the network accesses the network through flooding and transmits the received message; before the protocol runs, the node generates its own public key and private key locally, and uses the public key as identity information, and each node broadcasts its own public key to the entire network when the protocol is initialized; the current round of the protocol is set, recorded as the initialization view number, and the view number increases each time the master node changes or a new round of block proposals begins; each node collects the transaction record transaction pool in the network, and subsequent nodes take out the transaction packaged block from the transaction pool; during the operation of the network, if a protocol joins or exits the network, an honest majority constraint is set.

[0012] Preferably, each node collects a transaction record transaction pool in the network, and the subsequent node takes out the transaction package block from the transaction pool in the following steps: broadcast the user transaction to the entire network so that each node will receive these transactions; temporarily store the received transactions in the "transaction pool" and wait for the node to include them in a block; the node screens out transactions from the transaction pool according to the handling fee; the node organizes the screened transactions into a block data structure, and performs hash calculation on the block data to obtain a unique block hash value of the block; after the node completes the packaging and verification of a block according to the block hash value, it broadcasts the block to the network and notifies other nodes to update their blockchain records; other nodes verify the validity of the new block, and if it is verified to be 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 of the block is: obtaining various data in the block, wherein the various data include a hash of a previous block, a Merkle root, and a timestamp; a method of obtaining a unique block hash value of the block according to the various data is BH=H(PH+MR+TP+NO), wherein BH represents a unique block hash value of the block, H is a hash function, PH is a hash value of the previous block, MR is a root hash value of all transactions in the block, TP is a timestamp generated by the block, and NO is a random number.

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

[0015] Preferably, the step of electing a master node for nodes in the network is as follows: at the beginning of each round of election, the round number of the view is initialized, and the round number corresponds to the term of office of the master node in the current election round; all online nodes calculate through a verifiable random function to obtain a VRF value; after each online node calculates the VRF value, the VRF value is broadcast to the network; all nodes in the network collect the VRF values ​​broadcast in the network, and compare these values, and select the node with the largest VRF value as the master node of this round, that is, the block-generating node; a new block is generated and broadcasted by the selected master node, and the honest nodes in the network verify the new block, and reach a consensus after confirming the validity of the block, and add the new block to the blockchain; after the block generation and confirmation of this round is completed, the view number is updated, and at the beginning of the next round of election, all nodes calculate the new VRF value again to select the master node of the new round.

[0016] Preferably, all online nodes are calculated through a verifiable random function to obtain a VRF value in the following steps: obtaining the public key and private key of the node; the method for obtaining the VRF value according to the public key and private key of the node is VRF=H(Sig(sk, x)), where VRF is expressed as a 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.

[0017] Preferably, the general process steps are as follows: Step 3.1: The online node sends an awake message when entering the protocol, and the message format is<awake,v,s,H(pre)> PK , where v is the current view number, s is the message belonging to the sth step in view v, H(pre) is the hash value of the node's latest status message pre, and the subscript PK is the node's public key; collect the awake messages sent by online nodes in a set Awk, and the newly joined nodes are updated to the current state after receiving the information in the Awk set, and the exiting nodes will be automatically ignored; Step 3.2: All online nodes collect the awake messages in the Awk set. If a new node joins or the original online node exits, the original online committee node receives the input value b, verifies the correctness of b, and broadcasts the confirmed Echo message to the entire network. The newly joined node needs to download and receive past historical data information and synchronize to the latest state of the network in order to access the consensus Process; Step 3.3: When the number of Echo messages received by the online nodes exceeds half of the online nodes, that is, more than half of them reach a consensus, it is determined that the nodes have reached a consensus, and a signature QC containing the consent of the majority of nodes is generated, and the QC is broadcast to the entire network; Step 3.4: The 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, generate the final Agree certificate and broadcast it. When the Agree certificate reaches more than half, it ensures the consistency of the protocol and moves towards decision-making; Step 3.5: When the Agree certificate exceeds half of the online nodes, it is determined that the vast majority of nodes in the network have reached a consensus on the input b, and the input value b is used as the final result of the protocol, and the node finally outputs 1, confirming that the consensus has been reached.

[0018] Preferably, the quick process steps are: the online node verifies the correctness of the input b and broadcasts an Echo message, and counts the number of Echo messages; when the Echo message reaches half, the node generates a QC certificate, and when the QC certificate exceeds half of the online nodes, it generates an Agree certificate and broadcasts it; after the online node receives more than half of the Agree certificates, the node confirms that the protocol has been reached, outputs the result 1, and completes the input confirmation.

[0019] Preferably, the steps of obtaining the dynamic BFT protocol are as follows: PROPOSE phase: the master node is selected by a verifiable random function VRF in each round; if a new node joins or an old node exits during the proposal phase, the new node is synchronized with the latest status through the dynamic consistency protocol, and the network adjusts the status to reflect the number of nodes currently online; PREPARE phase: the node receiving the proposal verifies whether the new block meets the protocol requirements, and broadcasts a "PREPARE" message after confirming that it meets the requirements; if the network receives PREPARE messages from more than half of the nodes, the node determines that a preliminary consensus has been reached on the proposed block; COMMIT phase: after receiving PREPARE messages from more than half of the nodes, the node sends a "COMMIT" message. When more than half of the nodes have sent the "COMMIT" message, the block is recorded in the account book to reach an unchangeable consensus; when a node exits during the COMMIT phase or a new node joins, the dynamic protocol ensures that each honest node sends or receives a COMMIT message based on the latest status.

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

[0021] 1. Initialize the protocol in the network and set basic protocol rules for network nodes. Through initialization, ensure that all nodes can operate on the same basis, laying the foundation for subsequent protocol operations; provide consistency and efficiency for the entire consensus process, avoid communication delays or node asynchrony. After initialization, the network enters a lock-step synchronization state to ensure the correct operation of the protocol.

[0022] 2. Conduct master node elections for nodes in the network, and select a master node in the network to assume the responsibility of generating new blocks, proposing, and leading the consensus process. The master node is selected through a verifiable random function (VRF), making it difficult to predict the master node, reducing the risk of attack by malicious nodes; enhancing network security and anti-attack capabilities. Dynamic elections can effectively avoid targeted attacks that may be suffered by fixed master nodes, and increase the reliability and fairness of the network.

[0023] 3. Set up a dynamic consistency protocol for nodes and establish a protocol mechanism so that honest nodes can reach consensus on network input values ​​when nodes participate dynamically. This includes broadcasting awake status, adjusting protocol rules in real time, etc., to ensure that nodes can still reach consensus synchronously even when joining or leaving; improve the flexibility and scalability of the network, and support dynamic joining or leaving of nodes. At the same time, in the face of failures or malicious behaviors of some nodes, consistent consensus can still be achieved to ensure the normal operation of the network.

[0024] 4. Embed the set dynamic consistency protocol into the communication process of the traditional Byzantine fault-tolerant protocol to obtain the dynamic BFT protocol. Integrate the dynamic consistency protocol into the communication process of the traditional Byzantine fault-tolerant protocol PBFT, so that PBFT can maintain activity and consistency in the face of dynamic changes in nodes. PBFT reaches consensus through the proposal of the master node and the voting of other nodes. Embedding dynamic protocols in each process can better adapt to the node changes of the network; combining the high security of PBFT with the adaptability of the dynamic consistency protocol, the BFT protocol has dynamic fault tolerance and can maintain safe and effective consensus operations in the case of dynamic changes in nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 A flow chart of an efficient dynamic BFT consensus implementation method suitable for alliance chains provided in an embodiment of the present application.

[0026] Figure 2 This is the flow chart of the dynamic consistency protocol.

[0027] Figure 3 This is the general flow chart of the dynamic BFT protocol.

[0028] Figure 4 A quick flow chart for the dynamic BFT protocol. DETAILED DESCRIPTION

[0029] The technical solution of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the present invention. In addition, the forms of the various structures recorded in the following embodiments are merely illustrative. The efficient dynamic BFT consensus implementation method suitable for alliance chains involved in the present invention is not limited to the various structures recorded in the following embodiments. All other implementations obtained by ordinary technicians in this field without making creative work belong to the scope of protection of the present invention.

[0030] The present invention provides an efficient dynamic BFT consensus implementation method suitable for alliance chain, comprising the following steps:

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

[0032] In this embodiment, it should be specifically explained that the steps for initializing the protocol in the network are:

[0033] The maximum delay time specified by the protocol is set to ensure that any message can be delivered within the maximum delay time. The protocol is implemented based on a lock-step synchronous network, so that the local clocks maintained by each node are basically consistent. This assumption facilitates the design of the consensus protocol because all nodes communicate in unison, avoiding the uncertainty caused by network delays.

[0034] When the protocol starts, the committee is initialized so that the number of nodes in the committee is N. The number of nodes in the committee is public and defined in advance in the network. Each node is numbered from 1 to N to ensure that each node has a unique number.

[0035] Set the communication network to a p2p network. Each node in the network accesses the network and transmits the received messages through flooding. Before the protocol runs, the node needs to generate its own public key and private key locally, and use the public key as identity information. Each node broadcasts its public key to the entire network when the protocol is initialized so that other nodes can identify and authenticate it. In this way, all nodes can identify each other and establish trust when joining the consensus network.

[0036] Set the current round of the protocol, recorded as the initialization view number. The view number is a counter used to identify the current round during the operation of the consensus protocol. The view number will increase each time the master node changes or a new round of block proposals begins. The process of initializing the view number is usually set to 0 or other starting values ​​to ensure that the protocol starts from a unified starting point. The main function of the view number is to help all nodes in the network stay synchronized so that each node knows which round of consensus is currently in progress. 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, thereby selecting 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 subsequent nodes take out the transaction package blocks from the transaction pool.

[0038] The protocol stipulates that nodes can join and leave the network at will during operation. In order to maintain network security, the protocol sets an honest majority constraint condition. The honest majority constraint condition is to obtain the total number of online nodes n and the number of malicious nodes f t ,and It means 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 lock-step synchronous network is a model that assumes that network communication is delay-free, allowing each node of the protocol to perform synchronous operations within a fixed step size (lock-step). 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 each node can perform protocol operations at the same pace, thereby maintaining consistency in the network.

[0040] Byzantine nodes are maliciously manipulated or faulty nodes in a distributed network. These nodes do not follow the normal operation of the network protocol and may send erroneous, false or conflicting information in an attempt to influence the decisions and consensus of other nodes. Byzantine nodes may cause confusion or incorrect consensus among other nodes in the network through dishonest behavior or intentional sending of inconsistent data.

[0041] In this embodiment, it should be specifically explained that each node collects the transaction record transaction pool in the network, and the subsequent node takes out the transaction package block from the transaction pool in the following steps:

[0042] In the blockchain network, users continuously send transactions, such as transfers, contract calls, etc. These transactions are first broadcast to the entire network so that each node will receive them; the received transactions are temporarily stored in the "transaction pool" and wait for the node to include them in a block. The transaction pool can be understood as a list of pending transactions;

[0043] Nodes filter out valid transactions that meet the block size or specific protocol conditions from the transaction pool based on the handling fee. The screening process usually gives priority to transactions with high handling fees because nodes hope to obtain more handling fee income; filter out transactions that meet the block size or specific protocol conditions to ensure that the block does not exceed the allowed size;

[0044] The node organizes 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, timestamps, and some metadata specified by the protocol;

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

[0046] After a node completes the packaging and verification of a block, it broadcasts the block to the network, notifying other nodes to update their blockchain records to ensure the consistency of the entire network; 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 should be specifically explained that the node performs hash calculation on the data of this block to obtain the unique block hash value of the block in the following steps:

[0048] Get various data in the block, including the hash, Merkle root, timestamp, etc. of the previous block;

[0049] The method for calculating the unique block hash value of the block based on various data is BH=G(PH+MR+TP+NO), where BH represents the unique block hash value of the block, H is the 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 block generation, and NO is a random number, which is usually used to meet the hash conditions required by a specific consensus mechanism (such as proof of work).

[0050] Step 2: Elect the master node for nodes in the network.

[0051] In this embodiment, it should be specifically explained that the steps of electing a master node for nodes in the network are:

[0052] At the beginning of each election round, the round number of the view is initialized. The round number corresponds to the term of the master node in the current election round. The round number of the view is used to mark the order of the current master node to ensure that the election is carried out continuously between rounds.

[0053] All online nodes are calculated through a verifiable random function to obtain a VRF value, which is used 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 is random and unpredictable, so each election will produce a different master node. The online node refers to the node that is currently in operation and can participate in the protocol process;

[0054] After calculating the VRF value, each online node broadcasts the VRF value to the network;

[0055] All nodes in the network collect the VRF values ​​broadcast in the network, compare these values, and select the node with the largest VRF value as the master node of this round, that is, the block-producing node. The master node will be responsible for generating new blocks and submitting them to the network;

[0056] New blocks are generated and broadcasted through the selected master nodes. The honest nodes in the network will verify the new blocks, reach a consensus after confirming the validity of the blocks, and add the new blocks to the blockchain. Honest nodes refer to nodes that follow the protocol rules and perform tasks in an honest manner. Their processing of data is open, transparent, and unbiased, and there is no malicious behavior, such as tampering, discarding, or forging transactions;

[0057] Once the blocks of this round are generated and confirmed, the view number is updated. When the next round of elections begins, all nodes calculate the new VRF value again and select the new master node.

[0058] In this embodiment, it should be specifically explained that all online nodes calculate through a verifiable random function to obtain a VRF value in the following steps:

[0059] Get the node's public key and private key for encryption and verification;

[0060] The method to obtain the VRF value based on the public key and private key of the node is VRF=H(Sig(sk,X)), where VRF is represented by 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, usually a view number or a round identifier.

[0061] Step 3: Set up a dynamic consistency protocol for the node, such as Figure 2 As shown, the dynamic consistency protocol includes a general process and a fast process.

[0062] The dynamic consistency protocol is a distributed consensus protocol that ensures that consensus can be reached even when nodes dynamically join or exit. The protocol uses two modes, general process and fast process, to dynamically adjust the consensus mechanism according to the degree of node fluctuation, thereby ensuring that the system can reach a stable consensus at any time.

[0063] The dynamic consistency protocol has two operating modes: general process and fast process, which are suitable for situations with large and small node fluctuations respectively.

[0064] In this embodiment, it should be specifically explained that Figure 3 As shown, the general process steps are:

[0065] Step 3.1: When entering the protocol, the online node sends an "awake" message to inform the network that it has joined or regained consciousness. The message format is<awake,v,s,H(pre)> PK , where v is the current view number, s is the sth step in view v that the message belongs to, H(pre) is the hash value of the node's latest status message pre, and the subscript PK is the node's public key, which indicates the signature of the message sender on the message; the awake messages sent by online nodes will be collected in a set Awk, which represents the list of currently active nodes. The protocol only focuses on nodes that have been awake and online since the start of this step. For nodes that are newly added or exited during the operation, the protocol ignores their impact on the consistency of the results. Newly added nodes are updated to the current state after receiving the information in the Awk set, and exited nodes are automatically ignored;

[0066] Step 3.2: All online nodes collect the awake messages in the Awk set. If a new node joins or an original 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, indicating that the node has received the input. The Echo message is equivalent to a confirmation signal, indicating that the node has confirmed the legitimacy of the input value b. The newly joined node needs to download and receive past historical data information and synchronize to the latest status of the network in order to access the consensus process;

[0067] Step 3.3: When the number of Echo messages received by online nodes exceeds half of the online nodes, that is, more than half of them reach a consensus, the nodes are determined to have reached a consensus, and a signature QC containing the consent of the majority of nodes is generated and broadcast to the entire network, indicating that a preliminary consensus has been reached and that the next step is ready;

[0068] Step 3.4: Online nodes collect QC messages broadcast by other online nodes and count the number of QC messages. When the number of QC messages exceeds half, the final Agree certificate is generated and broadcasted to indicate further consensus support. When the Agree certificate reaches more than half, the consistency of the protocol is ensured and the decision is made.

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

[0070] In this embodiment, it should be specifically explained that Figure 4 As shown, the quick process steps are:

[0071] The online node verifies the correctness of input b and broadcasts an Echo message, counting the number of Echo messages;

[0072] 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 broadcasted.

[0073] After receiving more than half of the Agree certificates, the online nodes confirm that the agreement has been reached, output the result 1, and complete the input confirmation.

[0074] Step 4: Embed the dynamic consistency 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 Tolerant (PBFT) protocol is a fault-tolerant consensus algorithm that can ensure data consistency in a distributed network with some 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 nodes (malicious or unreliable nodes), the protocol can ensure the security and correctness of the data. At each stage, the nodes will verify the validity of the proposal through message exchange, and finally reach confirmation of the proposal with the support of the majority of honest nodes, thereby achieving the fault tolerance of the system.

[0076] The dynamic consistency protocol allows nodes to enter or exit the network at any time. The exited nodes do not affect the consensus results, and new nodes can quickly synchronize to the latest status and join the consensus process. Even if there are malicious nodes that do not send messages, the dynamic BFT protocol can ensure that the consensus process of online honest nodes is completed smoothly.

[0077] In this embodiment, it should be specifically explained that the steps for obtaining the dynamic BFT protocol are:

[0078] PROPOSE phase: The master node is selected by a verifiable random function (VRF) in each round. The master node is responsible for generating a new block and proposing it to other nodes. If a new node joins or an old node exits during the proposal phase, the dynamic consistency protocol is used to synchronize the latest state of the newly joined node and adjust the network state to reflect the number of nodes currently online.

[0079] PREPARE phase: The node receiving the proposal verifies whether the new block meets the protocol requirements, such as verifying the block signature, transaction legitimacy, etc. After confirming compliance, it broadcasts a "PREPARE" message; after the network receives PREPARE messages from more than half of the nodes, the nodes believe that the proposed block has reached a preliminary consensus;

[0080] In the PREPARE phase, if a node status changes, the dynamic consensus protocol allows the new node to synchronize block data and preparation status and participate in the rest of the protocol process. Byzantine nodes may deliberately not send "PREPARE" messages, but the dynamic protocol ensures that other honest nodes can reach a consensus;

[0081] COMMIT stage: After receiving enough "PREPARE" messages, the node sends a "COMMIT" message to indicate the final agreement on the block. Only after more than half of the nodes have sent the "COMMIT" message will the block be recorded in the ledger and an unchangeable consensus be reached; when a node exits the COMMIT stage or a new node joins, the dynamic protocol ensures that each honest node sends or receives the COMMIT message according to the latest status to maintain the stability of the consensus. The existence of the COMMIT stage can ensure that if the master node is a malicious node in the previous PREPARE stage, it will not cause inconsistency in the block result. The COMMIT stage is still implemented based on the dynamic consistency protocol.

[0082] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

[0083] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in 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 based on the protection scope of the claims.

Claims

1. An efficient dynamic BFT consensus implementation method suitable for alliance chains, characterized by: The following steps are involved: Step 1: Initialize the protocol in the network; Step 2: Elect the master node for nodes in the network; Step 3: Set a dynamic consistency protocol for the node. The dynamic consistency protocol includes a general process and a fast process. Step 4: Embed the dynamic consistency protocol set in step 3 into the communication process of the traditional Byzantine fault tolerance protocol to obtain a dynamic BFT protocol.

2. According to claim 1, an efficient dynamic BFT consensus implementation method suitable for alliance chain, characterized in that: The steps for initializing the protocol in the network are: The maximum delay time of the protocol is set to ensure that the message is delivered within the maximum delay time. The protocol is implemented based on a lock-step synchronous network so that the local clocks maintained by each node are basically consistent. When the protocol starts, the committee is initialized so that the number of nodes in the committee is N. The number of nodes in the committee is public and each node has a unique number. Set the communication network to a p2p network, where each node accesses the network and transmits the received messages through flooding; Before the protocol runs, the node generates its own public key and private key locally and uses the public key as identity information. Each node broadcasts its public key to the entire network when the protocol is initialized. Set the current round of the protocol, recorded as the initialization view number, and the view number increases every time the master node changes or a new round of block proposals begins; Each node collects transaction records in the network into a transaction pool, and subsequent nodes take out transaction packaging blocks from the transaction pool; During the operation of the network, if a protocol joins or exits the network, an honest majority constraint is set.

3. According to claim 2, an efficient dynamic BFT consensus implementation method suitable for alliance chain is characterized in that: Each node collects the transaction record transaction pool in the network, and the subsequent node takes out the transaction package block from the transaction pool in the following steps: Broadcast user transactions to the entire network so that every node will receive these transactions; temporarily store 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 based on the transaction fee; The node organizes the filtered transactions into a block data structure and performs hash calculation on the block data to obtain the block's unique block hash value; After a node completes packaging and verification of a block based on the block hash value, it broadcasts the block to the network and notifies other nodes to update their blockchain records; other nodes verify the validity of the new block, and if it is verified to be valid, the block is added to the local blockchain ledger.

4. According to claim 3, an efficient dynamic BFT consensus implementation method suitable for alliance chain is characterized in that: The steps of performing hash calculation on the block data to obtain the unique block hash value of the block are: Obtain various data in the block, including the hash, Merkle root, and timestamp of the previous block; The method to obtain the unique block hash value of the block based on various data is BH=H(PH+MR+TP+NO), where BH represents the unique block hash value of the block, H is the 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 generated by the block, and NO is a random number.

5. According to claim 2, an efficient dynamic BFT consensus implementation method suitable for alliance chain, characterized in that: The constraints of the honest majority are: Get the total number of online nodes n and the number of malicious nodes f t , at any time t, the number of online Byzantine nodes f t It cannot exceed half of the total number of online nodes n, that is, 6. According to claim 1, an efficient dynamic BFT consensus implementation method suitable for alliance chain, characterized in that: The steps of electing a master node for nodes in the network are: At the beginning of each election round, the round number of the view is initialized, and the round number corresponds to the term of the master node in the current election round; All online nodes calculate through the Verifiable Random Function (VRF) to obtain a VRF value; After calculating the VRF value, each online node broadcasts the VRF value to the network; All nodes in the network collect the VRF values ​​broadcast in the network, compare these values, and select the node with the largest VRF value as the master node of this round, that is, the block-producing node; The new block is generated and broadcasted by the selected master node. The honest nodes in the network verify the new block and reach a consensus after confirming the validity of the block, and then add the new block to the blockchain. After the blocks of this round are generated and confirmed, the view number is updated, and at the beginning of the next round of elections, all nodes calculate the new VRF value again and select the new master node.

7. According to claim 6, an efficient dynamic BFT consensus implementation method suitable for alliance chain, characterized in that: All online nodes are calculated through a verifiable random function to obtain a VRF value in the following steps: Get the public key and private key of the node; The method of obtaining the VRF value according to the public key and private key of the node is VRF=H(Sig(sk,x)), where VRF is represented by 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 the input data.

8. According to claim 1, an efficient dynamic BFT consensus implementation method suitable for alliance chain, characterized in that: The general process steps are: Step 3.1: The online node sends an awake message when entering the protocol. The message format is<awake,v,s,H(pre)> PK , where v is the current view number, s is the message belonging to the sth step in view v, H(pre) is the hash value of the node's latest state message pre, and the subscript PK is the node's public key; The awake messages sent by online nodes are collected in a set Awk, and the newly added nodes are updated to the current state after receiving the information in the Awk set, and the exiting nodes are automatically ignored; Step 3.2: All online nodes collect the awake messages in the Awk set. If a new node joins or the original online node exits, the original online committee node receives the input value b, verifies the correctness of b, and broadcasts the confirmed Echo message to the entire network. The newly joined node needs to download and receive past historical data information and synchronize to the latest status of the network in order to access the consensus process; Step 3.3: When the number of Echo messages received by the online nodes exceeds half of the online nodes, that is, more than half of them reach a consensus, the nodes are determined to have reached a consensus, and a signature QC containing the consent of the majority of nodes is generated, and the QC is broadcast to the entire network; Step 3.4: The online node collects the QC messages broadcast by other online nodes, counts the number of QC messages, and generates and broadcasts the final Agree certificate when the number of QC messages exceeds half. When the Agree certificate reaches more than half, the consistency of the protocol is ensured and the decision is made. Step 3.5: When the Agree certificate exceeds half of the online nodes, it is determined that the vast majority of nodes in the network have reached a consensus on input b, and use the input value b as the final result of the protocol, and the node finally outputs 1, confirming that consensus has been reached.

9. According to claim 1, an efficient dynamic BFT consensus implementation method suitable for alliance chain, characterized in that: The steps of the fast process are: The online node verifies the correctness of input b and broadcasts an Echo message, counting 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 broadcasted. After receiving more than half of the Agree certificates, the online nodes confirm that the agreement has been reached, output the result 1, and complete the input confirmation.

10. According to claim 1, an efficient dynamic BFT consensus implementation method suitable for alliance chain, characterized in that: The steps for obtaining the dynamic BFT protocol are: PROPOSE phase: The master node in each round is selected by a verifiable random function VRF; If a new node joins or an old node exits during the proposal phase, the dynamic consistency protocol is used to synchronize the latest state of the newly joined node and adjust the network state to reflect the number of nodes currently online. PREPARE phase: The node receiving the proposal verifies whether the new block meets the protocol requirements. After confirming that it meets the requirements, it broadcasts the "PREPARE" message. If the network receives PREPARE messages from more than half of the nodes, the node determines that the proposed block has reached a preliminary consensus. COMMIT phase: After receiving PREPARE messages from more than half of the nodes, the node sends a "COMMIT" message. When more than half of the nodes have sent "COMMIT" messages, the block is recorded in the ledger to reach an unchangeable consensus. When a node exits during the COMMIT phase or a new node joins, the dynamic protocol ensures that each honest node sends or receives COMMIT messages based on the latest status.

Images