A multi-node dynamic addition and deletion method and system

Abstract

The present invention provides a multi-node dynamic addition and deletion method and system. Based on the idea of configuration change, the number of nodes in the cluster before dynamic addition and deletion is regarded as the old configuration, and the number of nodes in the cluster after dynamic addition and deletion is regarded as the new configuration. By setting a state of a transition configuration between the old and new configurations, all nodes first enter the transition configuration state, so that when nodes make corresponding decisions in the transition configuration state, they meet the majority principle conditions set in the hotstuff consensus algorithm in both the new configuration and the old configuration. Through the setting of the transition configuration, the problem of "split brain" that may occur can be effectively solved.

Description

Technical Field

[0001] The present invention belongs to the technical field of blockchain, and particularly relates to a multi-node dynamic addition and deletion method and system. Background Technique

[0002] The statements in this part only provide background technical information related to the present invention, and do not necessarily constitute prior art.

[0003] Currently, in a blockchain system, in order to ensure the practicability of the system, it is necessary to allow any node in the node cluster to join or leave the cluster at any time. Such behavior will cause the number of nodes in the system to change, thereby affecting the operation of the consensus algorithm among nodes. Therefore, the dynamic addition and deletion of nodes cannot be carried out arbitrarily, and corresponding algorithms need to be designed to ensure the correctness of the consensus process.

[0004] The existing node dynamic addition and deletion methods are mainly designed for the classic blockchain consensus algorithm PBFT (Practical Byzantine Fault Tolerance). Through relevant designs, it can be ensured that nodes in the blockchain system can achieve dynamic addition and deletion under the PBFT consensus algorithm framework.

[0005] However, the inventors found that such methods usually only support the dynamic addition and deletion of a single node, that is, one node is added or removed in one addition and deletion process. Once the solution is extended to the case of adding or deleting many nodes at a time, it may encounter the classic "brain split" problem in a distributed system. That is, during the process of the original node cluster reaching a consensus on the event of a newly added node, due to network latency, only a part of the nodes complete the consensus on the newly added node first. Then, because the network latency time is uncertain, the remaining part of the nodes will perform a view rotation in the original node cluster and elect another primary node for consensus. The newly added node and the nodes that have completed the consensus first will also continue to perform consensus, resulting in network partitioning among nodes and causing a situation of two leaders, thereby destroying the system security. For classic consensus algorithms such as PBFT, because its communication complexity is O(n2), the communication complexity among nodes will increase exponentially with the increase in the number of nodes. Therefore, it itself cannot support the situation where the number of nodes is very large. However, precisely because the number of nodes is not many, there is no need to add or delete many nodes at a time. For example, adding or deleting hundreds of nodes at a time. If there is a need to add or delete a small number of nodes, the solution of adding or deleting one node at a time can be repeated multiple times. Because the number of repetitions is not large, it will not affect the system performance. The newly proposed Hotstuff consensus algorithm in 2018 reduces the communication complexity to O(n) on the basis of the PBFT algorithm, can support the operation of a large-scale node cluster, and has been applied in enterprise-level large blockchain projects such as Libra. Therefore, it is very necessary to design a corresponding multi-node dynamic addition and deletion solution for it. Summary of the Invention

[0006] To solve the above problems, the present invention provides a multi-node dynamic addition and deletion method and system. Based on the idea of configuration change, the number of nodes in the cluster before dynamic addition and deletion is regarded as the old configuration, and the number of nodes in the cluster after dynamic addition and deletion is regarded as the new configuration. By setting a transitional configuration state between the old and new configurations, all nodes first enter the transitional configuration state, so that when nodes make corresponding decisions in the transitional configuration state, they meet the majority principle conditions set in the hotstuff consensus algorithm in both the new and old configurations. Through the setting of the transitional configuration, the problem of "brain split" that may occur can be effectively solved.

[0007] According to the first aspect of the embodiments of the present invention, a multi-node dynamic addition and deletion method is provided, which is applied to the original cluster master node in a blockchain system, and includes:

[0008] Receiving an addition or deletion application sent by the node cluster to be added or deleted;

[0009] Signing and sending a prepare message containing the transitional configuration to each node in the original cluster, and receiving the signed prepare-vote messages feedback by each node for voting; if the number of such messages is not less than a preset threshold, sending a precommit message with the original cluster credentials to each node in the original cluster after addition and deletion processing;

[0010] Sequentially executing the receipt of signed messages, voting based on the signed messages, and the issuance of messages with cluster credentials based on the voting results in the precommit stage, commit stage, decide-prepare stage, secondary precommit stage, and secondary commit stage of the hotstuff consensus process; wherein, in the secondary commit stage, sending a decide message with the credentials of the original cluster after addition and deletion processing to each node in the original cluster after addition and deletion processing;

[0011] For each node that receives the decide message, if the credential verification passes, submitting the new configuration information, and forming a block with the submitted information and connecting it to the end of the blockchain to realize the dynamic addition and deletion of multiple nodes.

[0012] Further, the precommit stage is specifically: receiving the signed precommit-vote messages feedback by each node in the original cluster after addition and deletion processing for voting, if the number of such messages is not less than a preset threshold, sending a commit message with the original cluster credentials and the credentials of the original cluster after addition and deletion processing to each node in the original cluster after addition and deletion processing;

[0013] Or,

[0014] The specific process of the secondary precommit stage is as follows: Receive the signed precommit-vote messages fed back by the nodes entering the new configuration state for voting. If the number of such messages is not less than the preset threshold, send the commit message with the original cluster credentials after addition and deletion processing to each node of the original cluster after addition and deletion processing.

[0015] Further, the specific process of the commit stage is as follows: Receive the signed commit-vote messages fed back by each node of the original cluster after addition and deletion processing for voting. If the number of such messages is not less than the preset threshold, send the decide-prepare message with the original cluster credentials and the original cluster credentials after addition and deletion processing to each node of the original cluster after addition and deletion processing; among them, for each node that receives the decide-prepare message, if the credential verification passes, submit the transitional configuration information and form a block with the submitted information and append it to the end of the blockchain.

[0016] Or,

[0017] The specific process of the secondary commit stage is as follows: Receive the signed commit-vote messages fed back by each node of the original cluster after addition and deletion processing for voting. If the number of such messages is not less than the preset threshold, send the decide message with the original cluster credentials after addition and deletion processing to each node of the original cluster after addition and deletion processing.

[0018] Further, the specific process of the decide-prepare stage is as follows: Receive the signed prepare-vote messages fed back by each node of the original cluster after addition and deletion processing for voting. If the number of such messages is not less than the preset threshold, send the precommit message with the original cluster credentials and the original cluster credentials after addition and deletion processing to each node of the original cluster after addition and deletion processing; among them, for each node that receives the precommit message, if the credential verification passes, enter the new configuration state.

[0019] According to the second aspect of the embodiments of the present invention, a method for dynamically adding and deleting multiple nodes is provided, which is applied to the nodes to be added and deleted and other nodes in the original cluster except the master node, and includes:

[0020] Send an addition or exit application to the master node of the original cluster in the blockchain system;

[0021] The receiving primary node receives a signed prepare message containing the transitional configuration. If the signature verification is legal, it stores the transitional configuration and feeds back a signed prepare-vote message to the primary node for voting. Among them, the node receiving the primary node's prepare message is the node other than the primary node in the original cluster.

[0022] Sequentially execute the receipt of credentialed messages, the verification of credential legality, and the feedback of signed vote messages based on the verification results in the precommit phase, commit phase, decide-prepare phase, secondary precommit phase, and secondary commit phase of the hotstuff consensus process. Among them, in the secondary commit phase, a signed commit-vote message is fed back to the primary node.

[0023] The receiving primary node receives a decide message with the original cluster credentials after addition and deletion processing. If the credential verification is legal, it submits the new configuration information and forms a block to be added to the end of the blockchain, realizing the dynamic addition and deletion of multiple nodes.

[0024] Furthermore, the precommit phase is specifically as follows: The node receives a precommit message with the original cluster credentials from the primary node. If the credential verification is legal, the node enters the transitional configuration state and feeds back a signed precommit-vote message to the primary node for voting.

[0025] Or,

[0026] The secondary precommit phase is specifically as follows: The node receives a precommit message with the original cluster credentials and the original cluster credentials after addition and deletion processing from the primary node. If the credential verifications are all legal, the node enters the new configuration state and feeds back a signed precommit-vote message to the primary node for voting.

[0027] Furthermore, the commit phase is specifically as follows: The node receives a commit message with the original cluster credentials and the original cluster credentials after addition and deletion processing from the primary node. If the credential verifications are all legal, it feeds back a signed commit-vote message to the primary node for voting.

[0028] Or,

[0029] The secondary commit phase is specifically as follows: The node receives a commit message with the original cluster credentials after addition and deletion processing from the primary node. If the credential verification is legal, it feeds back a signed commit-vote message to the primary node for voting.

[0030] Further, the decide-prepare phase is specifically as follows: receiving a decide-prepare message from the master node with the original cluster credentials and the original cluster credentials after addition and deletion processing; if the credential verification is all legal, submitting the transitional configuration information, and forming a block with the submitted information and appending it to the end of the blockchain; at the same time, feedback a signed prepare-vote message to the master node for voting.

[0031] According to the third aspect of the embodiments of the present invention, a multi-node dynamic addition and deletion method is provided, including a multi-node dynamic addition and deletion method applied to the original cluster master node in the blockchain system and a multi-node dynamic addition and deletion method applied to the nodes to be added and deleted and other nodes in the original cluster except the master node.

[0032] According to the fourth aspect of the embodiments of the present invention, a multi-node dynamic addition and deletion system is provided, including a master node, nodes to be added and deleted, and other nodes in the original cluster except the master node. Among them, the master node executes a multi-node dynamic addition and deletion method applied to the original cluster master node in the blockchain system; the nodes to be added and deleted and other nodes in the original cluster except the master node execute a multi-node dynamic addition and deletion method applied to the nodes to be added and deleted and other nodes in the original cluster except the master node.

[0033] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0034] (1) The present invention provides a multi-node dynamic addition and deletion method and system. The solution is based on the idea of configuration change. The number of nodes in the cluster before dynamic addition and deletion is regarded as the old configuration, and the number of nodes in the cluster after dynamic addition and deletion is regarded as the new configuration. By setting a transitional configuration state between the old and new configurations, all nodes first enter the transitional configuration state, so that when nodes make corresponding decisions in the transitional configuration state, they both meet the majority principle conditions set in the hotstuff consensus algorithm in the new configuration and the old configuration. Through the setting of the transitional configuration, the problem of "brain split" that may occur can be effectively solved.

[0035] (2) The solution of the present invention effectively solves the problem that the node cluster in the hotstuff consensus algorithm cannot be dynamically added and deleted, thus effectively improving the practicability of the hotstuff consensus algorithm.

[0036] The advantages of the additional aspects of the present invention will be partially given in the following description, partially become obvious from the following description, or be understood through the practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The specification drawings constituting a part of the present invention are used to provide a further understanding of the present invention. The schematic embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation to the present invention.

[0038] Figure 1 This is a flowchart of a multi-node dynamic addition and deletion method described in an embodiment of the present invention. Detailed implementation manners

[0039] The present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0040] It should be noted that the following detailed description is illustrative and is intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which the present invention belongs.

[0041] It should be noted that the terms used herein are only for describing specific implementation manners and are not intended to limit the exemplary embodiments according to the present invention. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that when the terms "comprise" and / or "include" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0042] In the case of no conflict, the embodiments in the present invention and the features in the embodiments can be combined with each other.

[0043] Term explanation:

[0044] Primary node: The node that initiates a proposal and is responsible for sending the proposal to other nodes, including sending it to itself;

[0045] Byzantine node: A node that can perform malicious behaviors. In the hotstuff algorithm, when the total number of nodes is 3f + 1, the algorithm can tolerate the existence of at most f malicious nodes;

[0046] Majority principle: The hotstuff algorithm stipulates that when the total number of nodes is no more than 3f + 1, if at least 2f + 1 nodes agree on a certain proposal message, it means that the message consensus is successful and enters the next stage;

[0047] Old configuration: The set of nodes in the cluster before dynamic addition and deletion is regarded as the old configuration. When a node applies the old configuration, if at least 2f + 1 nodes in the old configuration agree on a certain proposal message (the total number of nodes in the old configuration is 3f + 1), it means that the message consensus is successful;

[0048] New configuration: The set of nodes in the cluster after dynamic addition and deletion is regarded as the new configuration. When a node applies the new configuration, if at least 2f + 1 nodes in the new configuration agree on a certain proposal message (the total number of nodes in the new configuration is 3f + 1), it means that the message consensus is successful;

[0049] Transitional configuration: When a node applies a transitional configuration, if a proposal message is to reach consensus, it needs to reach consensus in both the new configuration and the old configuration.

[0050] Prepare: Preparation stage;

[0051] Prepare-vote: Preparation voting stage;

[0052] Precommit: Pre-commitment stage;

[0053] precommit-vote: Pre-commitment voting stage;

[0054] commit: Commitment stage;

[0055] commit-vote: Commitment voting stage;

[0056] decide: Decision stage;

[0057] decide-prepare: Decision - Preparation stage.

[0058] HotStuff consensus algorithm: Source paper of the algorithm: Yin M, Malkhi D, Reiter M K, et al. HotStuff: BFT Consensus with Linearity and Responsiveness [C] / / the 2019 ACM Symposium. ACM, 2019. The basic content of this algorithm will not be elaborated in this invention.

[0059] Embodiment 1:

[0060] The purpose of this embodiment is to provide a method for dynamically adding and deleting multiple nodes.

[0061] A method for dynamically adding and deleting multiple nodes, which is applied to the original cluster master node in a blockchain system, includes:

[0062] Receiving an addition or exit application sent by the node cluster to be added or deleted;

[0063] Signing the prepare message containing the transitional configuration and sending it to each node in the original cluster, and receiving the signed prepare-vote messages feedback by each node for voting; if the number of such messages is not less than the preset threshold, sending the precommit message with the original cluster credentials to each node in the original cluster after addition and deletion processing;

[0064] Successively execute the receipt of signed messages, voting based on signed messages, and the issuance of messages with cluster credentials based on the voting results in the precommit stage, commit stage, decide-prepare stage, secondary precommit stage, and secondary commit stage of the HotStuff consensus process; wherein, in the secondary commit stage, send the decide message with the original cluster credentials after addition and deletion processing to each node of the original cluster after addition and deletion processing;

[0065] For each node that receives the decide message, if the credential verification passes, submit the new configuration information, and form the submitted information into a block and append it to the end of the blockchain to achieve dynamic addition and deletion of multiple nodes.

[0066] Further, the precommit stage is specifically as follows: Receive and vote on the signed precommit-vote messages fed back by each node of the original cluster after addition and deletion processing. If the number of such messages is not less than the preset threshold, send the commit message with the original cluster credentials and the original cluster credentials after addition and deletion processing to each node of the original cluster after addition and deletion processing;

[0067] Or,

[0068] The secondary precommit stage is specifically as follows: Receive and vote on the signed precommit-vote messages fed back by the nodes entering the new configuration state. If the number of such messages is not less than the preset threshold, send the commit message with the original cluster credentials after addition and deletion processing to each node of the original cluster after addition and deletion processing.

[0069] Further, the commit stage is specifically as follows: Receive and vote on the signed commit-vote messages fed back by each node of the original cluster after addition and deletion processing. If the number of such messages is not less than the preset threshold, send the decide-prepare message with the original cluster credentials and the original cluster credentials after addition and deletion processing to each node of the original cluster after addition and deletion processing; wherein, for each node that receives the decide-prepare message, if the credential verification passes, submit the transitional configuration information, and form the submitted information into a block and append it to the end of the blockchain;

[0070] Or,

[0071] The secondary commit stage is specifically as follows: Receive and vote on the signed commit-vote messages fed back by each node of the original cluster after addition and deletion processing. If the number of such messages is not less than the preset threshold, send the decide message with the original cluster credentials after addition and deletion processing to each node of the original cluster after addition and deletion processing.

[0072] Further, the decide - prepare phase is specifically as follows: Receive the signed prepare - vote messages fed back by each node of the original cluster after addition and deletion processing for voting. If the number of such messages is not less than the preset threshold, send the pre - commit messages with the original cluster credentials and the original cluster credentials after addition and deletion processing to each node of the original cluster after addition and deletion processing; among them, for each node that receives the pre - commit message, if the credential verification passes, it enters the new configuration state.

[0073] Further, its specific details are described in detail in Embodiment 3.

[0074] Embodiment 2:

[0075] The purpose of this embodiment is to provide a method for dynamically adding and deleting multiple nodes.

[0076] A method for dynamically adding and deleting multiple nodes, which is applied to the nodes to be added and deleted and other nodes in the original cluster except the master node, includes:

[0077] Send an addition or exit application to the master node of the original cluster in the blockchain system;

[0078] Receive the signed prepare message containing the transitional configuration from the master node. If the signature verification is legal, store the transitional configuration and feedback the signed prepare - vote message to the master node for voting; among them, the nodes that receive the prepare message from the master node are the nodes in the original cluster except the master node;

[0079] Successively execute the receipt of credential - carrying messages, the verification of credential legality, and the feedback of signed voting messages based on the verification results in the pre - commit phase, commit phase, decide - prepare phase, secondary pre - commit phase, and secondary commit phase of the hotstuff consensus process; among them, in the secondary commit phase, the signed commit - vote message is fed back to the master node;

[0080] Receive the decide message with the original cluster credentials after addition and deletion processing from the master node. If the credential verification is legal, submit the new configuration information and form a block to be connected to the end of the blockchain, realizing the dynamic addition and deletion of multiple nodes.

[0081] Further, the pre - commit phase is specifically as follows: Receive the pre - commit message with the original cluster credentials from the master node. If the credential verification is legal, the node enters the transitional configuration state and feedbacks the signed pre - commit - vote message to the master node for voting;

[0082] Or

[0083] The specific process of the secondary precommit stage is as follows: receiving a precommit message from the primary node with the original cluster credentials and the original cluster credentials after addition and deletion processing; if the credential verifications are all legal, the node enters the new configuration state and feeds back a precommit-vote message with a signature to the primary node for voting.

[0084] Furthermore, the specific process of the commit stage is as follows: receiving a commit message from the primary node with the original cluster credentials and the original cluster credentials after addition and deletion processing; if the credential verifications are all legal, feeding back a commit-vote message with a signature to the primary node for voting;

[0085] Or

[0086] The specific process of the secondary commit stage is as follows: receiving a commit message from the primary node with the original cluster credentials after addition and deletion processing; if the credential verification is legal, feeding back a commit-vote message with a signature to the primary node for voting.

[0087] Furthermore, the specific process of the decide-prepare stage is as follows: receiving a decide-prepare message from the primary node with the original cluster credentials and the original cluster credentials after addition and deletion processing; if the credential verifications are all legal, submitting the transitional configuration information and forming a block with the submitted information to be appended at the end of the blockchain; meanwhile, feeding back a prepare-vote message with a signature to the primary node for voting.

[0088] Furthermore, its specific details are described in detail in Embodiment 3.

[0089] Embodiment 3:

[0090] The purpose of this embodiment is to provide a method for dynamically adding and deleting multiple nodes.

[0091] A method for dynamically adding and deleting multiple nodes includes a method for dynamically adding and deleting multiple nodes applied to the original cluster primary node in the blockchain system in Embodiment 1 and a method for dynamically adding and deleting multiple nodes applied to the nodes to be added and deleted and other nodes except the primary node in the original cluster in Embodiment 2.

[0092] Furthermore, for the convenience of understanding, the following describes the solution of this embodiment in detail with reference to the accompanying drawings:

[0093] For the convenience of description, the following variable symbol definitions are given in this embodiment:

[0094] Cluster A: the set of nodes before the dynamic addition and deletion behavior occurs, i.e., the original node set;

[0095] Cluster B: The set of nodes that need to join / leave;

[0096] Cluster A’: The set of nodes after dynamic addition and deletion;

[0097] QC: The certificate produced by the primary node through algorithms such as threshold signature or aggregate signature to prove that at least 2f + 1 votes for a certain proposal message have been received in the cluster, that is, to prove that the majority of nodes agree to the proposal. In the following text: QC1 represents the QC of Cluster A, and QC2 represents the QC of Cluster A’.

[0098] Specifically, to solve the problems existing in the prior art, this embodiment provides a multi-node dynamic addition and deletion method. Its main technical concept is to regard the number of nodes in the cluster before dynamic addition and deletion as the old configuration through the idea of configuration change, and regard the number of nodes in the cluster after dynamic addition and deletion as the new configuration. A transitional configuration state is set between the old and new configurations. All nodes first enter the transitional configuration state according to the designed algorithm. When the nodes are in the transitional configuration, the corresponding decisions need to satisfy the majority principle conditions set in the hotstuff algorithm in both the new and old configurations. By setting the transitional configuration, the possible "split brain" problem can be solved. The specific steps of the method are as follows:

[0099] Step 1: When in the join mode, the newly added nodes form Cluster B and send a pre-join application to the primary node of the hotstuff consensus cluster A in the blockchain system. After receiving the message, the primary node establishes a connection with the nodes in Cluster B. Cluster B starts to synchronize the previous block information as a learner until all nodes in Cluster B have synchronized the historical blocks of Cluster A, and then sends a formal join application to the primary node of Cluster A.

[0100] When in the exit mode, the nodes to be exited form Cluster B and directly send a formal exit application to the primary node of Cluster A.

[0101] Step 2: After receiving the formal application, the primary node generates a prepare message containing the transitional configuration, signs it, and then broadcasts the prepare message to all nodes in Cluster A.

[0102] Step 3: After receiving the prepare message sent by the primary node, the node first verifies the legality of the signature. If it is legal, it first stores the transitional configuration and replies to the primary node with a corresponding prepare-vote message as a vote for the prepare message, where the prepare-vote message should be attached with its own signature.

[0103] Among them, the configuration refers to the node cluster itself. The following is an example to illustrate the old configuration, new configuration, and transitional configuration:

[0104] For example:

[0105] Configuration 1 can be an old configuration, which is the node set {1, 2, 3, 4}.

[0106] Configuration 2 is a new configuration, which is the node set {1, 2, 3, 4, 5, 6, 7, 8, 9}.

[0107] Then the transition configuration is {1, 2, 3, 4}, {1, 2, 3, 4, 5, 6, 7, 8, 9}.

[0108] Applying the transition configuration means that it is necessary to meet the QC requirements in {1, 2, 3, 4} and also meet the QC requirements in {1, 2, 3, 4, 5, 6, 7, 8, 9}.

[0109] Step 4: After the primary node receives the prepare-vote message, it first verifies the legality of the signature. If it continuously receives at least 2f + 1 legal prepare-vote messages in cluster A, it aggregates QC1 of cluster A, forms a precommit message, and sends it to all nodes in A'.

[0110] Step 5: After a node receives the precommit message, it first verifies the correctness of QC1. If the verification passes, the node enters the transition configuration state, indicating that the node will only vote on this message after verifying the attached QC1 and QC2 of the proposal. Then the node that enters the transition configuration replies to the primary node with a precommit-vote message as a vote for the precommit-vote message, where the precommit-vote message should be attached with its own signature.

[0111] Step 6: After the primary node receives the precommit-vote message, it first verifies the legality of the signature. If it continuously receives at least 2f + 1 legal precommit-vote messages in cluster A, it aggregates QC1 of cluster A. If it continuously receives at least 2f + 1 legal precommit-vote messages in cluster A', it aggregates QC2 of cluster A'. Then it carries QC1 and QC2 in the formed commit message and sends it to all nodes in A'.

[0112] Step 7: After a node receives the commit message, it first verifies the correctness of QC1 and QC2. If both verifications pass, it replies to the primary node with a corresponding commit-vote message as a vote for the commit message, where the commit-vote message should be attached with its own signature.

[0113] Step 8: After the primary node receives the commit-vote message, it first verifies the legality of the signature. If it continuously receives no less than 2f + 1 legal commit-vote messages in cluster A, it aggregates QC1 of cluster A. If it continuously receives no less than 2f + 1 legal commit-vote messages in cluster A', it aggregates QC2 of cluster A'. Then, it carries QC1 and QC2 in the formed decide-prepare message and sends it to all nodes in A'.

[0114] Step 9: After a node receives the decide-prepare message, it first verifies the correctness of QC1 and QC2. If both verifications pass, it submits the transitional configuration information and forms a block with the submitted information and appends it to the end of the blockchain. At the same time, this message is also the prepare message for the consensus initiated by the primary node in the second round to change from the transitional configuration to the new configuration. Therefore, the node needs to reply to the primary node with a corresponding prepare-vote message as a vote for the prepare message, and the prepare-vote message should be accompanied by its own signature.

[0115] Step 10: After the primary node receives the prepare-vote message, it first verifies the legality of the signature. If it continuously receives no less than 2f + 1 legal prepare-vote messages in cluster A, it aggregates QC1 of cluster A. If it continuously receives no less than 2f + 1 legal prepare-vote messages in cluster A', it aggregates QC2 of cluster A'. Then, it carries QC1 and QC2 in the formed precommit message and sends it to all nodes in A'.

[0116] Step 11: After a node receives the precommit message, it first verifies the correctness of QC1 and QC2. If both verifications pass, the node enters the new configuration state. In the new configuration state, the node only needs to verify and pass the QC2 attached to the proposal and then vote on this message. Then, the node that enters the new configuration replies to the primary node with a precommit-vote message as a vote for the precommit-vote message, and the precommit-vote message should be accompanied by its own signature.

[0117] Step 12: After the primary node receives the precommit-vote message, it first verifies the legality of the signature. If it continuously receives no less than 2f + 1 legal precommit-vote messages in cluster A', it aggregates QC2 of cluster A'. Then, it carries QC2 in the formed commit message and sends it to all nodes in A'.

[0118] Step 13: After receiving the commit message, the node first verifies the correctness of QC2. If the verification passes, it replies to the master node with the corresponding commit-vote message as a vote for the commit message, where the commit-vote message must be accompanied by its own signature.

[0119] Step 14: After receiving the commit-vote message, the master node first verifies the legitimacy of the signature. If it continues to receive no less than 2f+1 legitimate commit-vote messages from cluster A', it aggregates QC2 of cluster A, and then carries QC2 in the formed decide message and sends it to all nodes in A'.

[0120] Step 15: After receiving the decide message, the node first verifies the correctness of QC2. If the verification passes, it submits the new configuration information and forms a block to be connected to the end of the blockchain.

[0121] Step 16: At this point, the number of nodes has been changed and all nodes can continue the Hotstuff consensus process in the new configuration.

[0122] Embodiment 4:

[0123] The purpose of this embodiment is to provide a multi-node dynamic addition and deletion system.

[0124] A multi-node dynamic addition and deletion system comprises a master node, nodes to be added or deleted, and other nodes in an original cluster except the master node, wherein the master node executes a multi-node dynamic addition and deletion method applied to the master node of the original cluster in a blockchain system in embodiment one; the nodes to be added or deleted and other nodes in the original cluster except the master node execute a multi-node dynamic addition and deletion method applied to the nodes to be added or deleted and other nodes in the original cluster except the master node in embodiment two.

[0125] Furthermore, the relevant technical details of the system described in this embodiment are described in detail in Embodiments 1 to 3, and will not be repeated here.

[0126] In further embodiments, there is also provided:

[0127] An electronic device includes a memory and a processor, and computer instructions stored in the memory and executed on the processor, wherein when the computer instructions are executed by the processor, the method described in Embodiment 1 is performed. For the sake of brevity, no further description is given here.

[0128] It should be understood that in this embodiment, the processor may be a central processing unit (CPU), or the processor may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0129] The memory may include a read-only memory and a random access memory, and provide instructions and data to the processor. A part of the memory may also include a non-volatile random access memory. For example, the memory may also store information about the device type.

[0130] A computer-readable storage medium is used to store computer instructions. When the computer instructions are executed by the processor, the method described in the first embodiment is completed.

[0131] The method in the first embodiment can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor. The software module may be located in a mature storage medium in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. This storage medium is located in the memory, and the processor reads the information in the memory and combines its hardware to complete the steps of the above method. To avoid repetition, it will not be described in detail here.

[0132] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with this embodiment can be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. A professional technician can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.

[0133] The multi-node dynamic addition and deletion method and system provided in the above embodiment can be realized and have broad application prospects.

[0134] The above are only the preferred embodiments of the present invention and are not used to limit the present invention. For those skilled in the art, the present invention may have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A multi-node dynamic addition and deletion method, which is applied to the original cluster master node in a blockchain system, and is characterized in that, Including: Receiving join or exit applications sent by the node cluster to be added or deleted; Signing and sending the prepare message containing the transitional configuration to each node in the original cluster, and receiving the signed prepare-vote messages feedback by each node for voting; If the number of signed prepare-vote messages is not less than the preset threshold, sending the precommit message with the original cluster credentials to each node in the original cluster after addition or deletion processing; Successively executing the receipt of signed messages, voting based on signed messages, and sending messages with cluster credentials based on the voting results in the precommit stage, commit stage, decide-prepare stage, secondary precommit stage, and secondary commit stage of the hotstuff consensus process; wherein, in the secondary commit stage, sending the decide message with the original cluster credentials after addition or deletion processing to each node in the original cluster after addition or deletion processing; For each node that receives the decide message, if the credential verification passes, submitting the new configuration information, and forming the submitted information into a block and appending it to the end of the blockchain to achieve dynamic addition and deletion of multiple nodes.

2. The multi-node dynamic addition and deletion method according to claim 1, wherein The precommit stage is specifically: receiving the signed precommit-vote messages feedback by each node in the original cluster after addition or deletion processing for voting, and if the number of such messages is not less than the preset threshold, sending the commit message with the original cluster credentials and the original cluster credentials after addition or deletion processing to each node in the original cluster after addition or deletion processing; Or, The secondary precommit stage is specifically: receiving the signed precommit-vote messages feedback by the nodes entering the new configuration state for voting, and if the number of such messages is not less than the preset threshold, sending the commit message with the original cluster credentials after addition or deletion processing to each node in the original cluster after addition or deletion processing.

3. The multi-node dynamic addition and deletion method according to claim 1, characterized in that, The commit stage is specifically: receiving the signed commit-vote messages feedback by each node in the original cluster after addition or deletion processing for voting, and if the number of such messages is not less than the preset threshold, sending the decide-prepare message with the original cluster credentials and the original cluster credentials after addition or deletion processing to each node in the original cluster after addition or deletion processing; wherein, for each node that receives the decide-prepare message, if the credential verification passes, submitting the transitional configuration information, and forming the submitted information into a block and appending it to the end of the blockchain; Or, The secondary commit stage is specifically: receiving the signed commit-vote messages feedback by each node in the original cluster after addition or deletion processing for voting, and if the number of such messages is not less than the preset threshold, sending the decide message with the original cluster credentials after addition or deletion processing to each node in the original cluster after addition or deletion processing.

4. A multi-node dynamic addition and deletion method according to claim 1, characterized in that In the decide - prepare phase, specifically: receive the signed prepare - vote messages fed back by each node of the original cluster after addition and deletion processing for voting. If the number of such messages is not less than the preset threshold, send the pre - commit messages with the original cluster credentials and the original cluster credentials after addition and deletion processing to each node of the original cluster after addition and deletion processing; among them, for each node that receives the pre - commit message, if the credential verification passes, it enters the new configuration state.

5. A multi-node dynamic addition and deletion method, which is applied to the nodes to be added and deleted and other nodes in the original cluster except the master node, and is characterized in that, It includes: Send an application to join or leave to the original cluster master node in the blockchain system; Receive the signed prepare message containing the transitional configuration from the master node. If the signature verification is legal, store the transitional configuration and feedback the signed prepare - vote message to the master node for voting; among them, the nodes that receive the master node's prepare message are the nodes in the original cluster except the master node; Sequentially execute the receipt of credentialed messages, the verification of credential legality, and the feedback of signed voting messages based on the verification results in the pre - commit phase, commit phase, decide - prepare phase, secondary pre - commit phase, and secondary commit phase of the hotstuff consensus process; among them, in the secondary commit phase, feedback the signed commit - vote message to the master node. Receive the decide message with the original cluster credentials after addition and deletion processing from the master node. If the credential verification is legal, submit the new configuration information and form it into a block to be connected to the end of the blockchain, realizing the dynamic addition and deletion of multiple nodes.

6. A multi-node dynamic addition and deletion method as described in claim 5, characterized in that In the pre - commit phase, specifically: receive the pre - commit message with the original cluster credentials from the master node. If the credential verification is legal, the node enters the transitional configuration state and feedbacks the signed pre - commit - vote message to the master node for voting; Or, In the secondary pre - commit phase, specifically: receive the pre - commit message with the original cluster credentials and the original cluster credentials after addition and deletion processing from the master node. If the credential verifications are all legal, the node enters the new configuration state and feedbacks the signed pre - commit - vote message to the master node for voting.

7. A multi-node dynamic addition and deletion method as claimed in claim 5, characterized in that, In the commit phase, specifically: receive the commit message with the original cluster credentials and the original cluster credentials after addition and deletion processing from the master node. If the credential verifications are all legal, feedback the signed commit - vote message to the master node for voting; Or, In the secondary commit phase, specifically: receive the commit message with the original cluster credentials after addition and deletion processing from the master node. If the credential verification is legal, feedback the signed commit - vote message to the master node for voting.

8. A multi-node dynamic addition and deletion method according to claim 5, characterized in that In the decide-prepare phase, specifically: receive the decide-prepare message from the master node with the original cluster credentials and the original cluster credentials after addition and deletion processing. If the credential verification is all legal, submit the transitional configuration information, and form a block with the submitted information and append it to the end of the blockchain; at the same time, feedback the signed prepare-vote message to the master node for voting.

9. A multi-node dynamic addition and deletion method, characterized in that, It includes a multi-node dynamic addition and deletion method as described in any one of claims 1-4 applied to the original cluster master node in the blockchain system and a multi-node dynamic addition and deletion method as described in any one of claims 5-8 applied to the nodes to be added and deleted and other nodes in the original cluster except the master node.

10. A multi-node dynamic addition and deletion system, characterized in that, It includes a master node, nodes to be added and deleted, and other nodes in the original cluster except the master node. Among them, the master node executes a multi-node dynamic addition and deletion method as described in any one of claims 1-4 applied to the original cluster master node in the blockchain system; the nodes to be added and deleted and other nodes in the original cluster except the master node execute a multi-node dynamic addition and deletion method as described in any one of claims 5-8 applied to the nodes to be added and deleted and other nodes in the original cluster except the master node.

Images