An Emergency Method for Consensus Failure on a Consortium Blockchain

Abstract

An emergency method for consensus failure on a consortium blockchain, which distinguishes the consensus private key and the business private key to facilitate effectively controlling the security boundary of backing up the corresponding private key in the emergency plan; the consortium blockchain system is deployed in a dual-center manner, and partial consensus private keys of each server center are mutually backed up in each server center, so that the number of consensus private keys stored in the normal application server nodes and backup nodes of each server center can meet the consensus requirements, thereby reducing the storage and efficiency burden caused by completely cloning the source node; the present invention designs a lightweight recovery method for faulty nodes, which does not require reconstructing and copying data, only some simple cryptographic calculations, avoiding the large delay consumption of copying data, and at the same time does not require occupying additional physical resources to reconstruct faulty nodes, enabling the faulty nodes to be restored in seconds and supporting the system to resume consensus.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain, and particularly to an emergency method for consensus failure on a consortium blockchain. Background Art

[0002] A consortium blockchain is a system form between a public blockchain and a private blockchain. It is often controlled by multiple centers and jointly maintained by several organizations. The use of this blockchain must be restricted by permissions, and relevant information will be protected, such as supply chain institutions or banking alliances. The consortium blockchain is controlled by multiple nodes formulated by organizations, and these nodes manage and operate the entire system according to a consensus mechanism; each node of the consortium blockchain usually has a corresponding entity organization, and only with the approval of the consortium can it join or exit the system. Each institution and organization interested in the benefits cooperate closely on the blockchain and jointly maintain the healthy and stable development of the system.

[0003] Consortium blockchains are widely used in China. However, due to physical equipment reasons, most institutions deploy consortium blockchains in one or two computer rooms. The original distributed characteristics of the blockchain are inhibited. Deploying in one computer room cannot form a disaster recovery system; when deployed in two computer rooms, once an entire computer room fails, most existing consensus mechanisms will not work properly. For example, common consensus mechanisms in consortium blockchains such as raft, pbft, and pos need to develop new emergency methods on the existing system; when the consortium blockchain is deployed in two computer rooms, it is a common dual-center deployment. A common emergency method is to back up the information of all nodes in this center at the other center. When a single center fails, start the disaster recovery plan for emergency at the other center, and use the backup information to reconstruct blockchain nodes locally to restore the existing network consensus. However, reconstructing blockchain nodes requires completely cloning the source nodes, including copying blockchain data, etc., which greatly consumes storage resources and also affects the efficiency of network recovery. Summary of the Invention

[0004] The purpose of the present invention is to provide an emergency method for consensus failure on a consortium blockchain, so as to solve the foregoing problems existing in the prior art.

[0005] In order to achieve the above purpose, the technical solution adopted by the present invention is as follows:

[0006] An emergency method for consensus failure on a consortium blockchain includes the following steps:

[0007] S1. In the consortium blockchain system, distinguish the consensus process and the business process, respectively declare the consensus public key and the business public key, and correspondingly set the consensus private key and the business private key;

[0008] S2. Deploy the consensus private keys to two different server centers respectively, and set a backup node in each server center. Part of the consensus private keys of the other server center are backed up and stored in the backup node, so that each of the server centers is deployed with the consensus private keys that can meet the consensus requirements;

[0009] S3. During the operation of the above-mentioned consortium blockchain system, when the administrator determines that there is an abnormality in the consortium blockchain network and finds out the server center that fails, the server center that fails is called the faulty center, and the server center that operates normally is called the normal center;

[0010] S4. Use the consensus private keys backed up and stored by the backup nodes of the normal center to simulate and calculate the data that the faulty node needs to generate, and at the same time generate corresponding data with the original consensus private keys of the normal center; send all the data obtained by the normal center to the corresponding business processes;

[0011] S5. Execute data processing through the business private key to obtain the original data of the transaction business;

[0012] S6. Send the original data obtained in step S5 to the receiving party, thus completing the emergency measure for the consensus failure on the consortium blockchain.

[0013] Preferably, when a certain server center in the consortium blockchain system described in steps S1 - S2 fails, the emergency process includes the following steps:

[0014] S41. The administrator sends an emergency instruction to the backup node of the normal center;

[0015] S42. Use the consensus private keys of the faulty center backed up and stored in the backup node to simulate the nodes corresponding to the faulty center participating in the consensus, and simulate and calculate to generate corresponding data through the backed-up consensus private keys; at the same time, use the original consensus private keys deployed in the normal center to continue the data calculation process before the failure to obtain corresponding data;

[0016] S43. Send all the data obtained by the normal center in step S42 to the corresponding business processes.

[0017] Preferably, each of the server centers includes more than one server node and a backup node; each server node stores and only stores one consensus private key, and the backup node backs up and stores more than one consensus private key.

[0018] Preferably, the consensus public key and the consensus private key are only applied in the consensus process to verify whether the transaction initiator can pass the consensus of the consortium blockchain system; the business public key and the business private key are only applied in the transaction business process to determine whether the transaction initiator is legal.

[0019] The beneficial effects of the present invention are as follows: The present invention discloses an emergency method for consensus failure on a consortium blockchain, which distinguishes the consensus private key and the business private key, facilitating the effective control of the security boundary for backing up the corresponding private keys in the emergency plan; the consortium blockchain system is deployed in a dual-center manner, and a part of the consensus private keys of each server center are mutually backed up in each server center, so that the number of consensus private keys stored in the normal application server nodes and backup nodes of each server center can meet the consensus requirements, thereby reducing the storage and efficiency burden caused by completely cloning the source node; the present invention designs a lightweight recovery method for faulty nodes, which does not require data reconstruction or copying, only some simple cryptographic calculations, avoiding the large delay consumption of copying data, and at the same time does not require additional physical resources to reconstruct faulty nodes, enabling the faulty nodes to be restored in seconds and supporting the system to resume consensus. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 is the flow chart of the emergency method for consensus failure on the consortium blockchain;

[0021] Figure 2 is the flow chart of emergency handling after a failure occurs;

[0022] Figure 3 is the flow chart of the PBFT protocol. DETAILED DESCRIPTION OF THE INVENTION

[0023] In order to make the objectives, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0024] An emergency method for consensus failure on a consortium blockchain distinguishes the consensus process and the business process in the consortium blockchain, declares the consensus public key and the business public key; and deploys the consensus private key in two server centers, and backs up a part of the consensus private keys of the other server center in each server center, so that the consensus private keys stored in one server center can meet the consensus requirements; when a server center fails, the server center that has not failed independently completes consensus identification, and transmits the data processed by the consensus private key to the corresponding business process, and completes data processing through the business private key. Specifically as Figure 1 shown, it includes the following steps:

[0025] S1. Distinguish the consensus process and the business process in the consortium blockchain system, respectively declare the consensus public key and the business public key, and correspondingly set the consensus private key and the business private key; the consensus public key and the consensus private key are only applied to the consensus process to verify whether the transaction initiator can pass the consensus of the consortium blockchain system, and the business public key and the business private key are only applied to the transaction business process to determine whether the transaction initiator is legal;

[0026] S2. Deploy the consensus private key to two different server centers respectively, and set a backup node in each server center. A part of the consensus private key of the other server center is backup stored in the backup node, so that each server center is deployed with the consensus private key that can meet the consensus requirements;

[0027] For example, if the consortium blockchain system reaches a consensus following the majority principle, the number of consensus private keys saved by the nodes in each server center should exceed half; if the consortium blockchain system reaches a consensus following the Byzantine fault tolerance principle, the number of consensus private keys saved by the nodes in each server center should exceed 2 / 3 of the total. Specifically, if the consortium blockchain system applies the PBFT consensus mechanism, there are 15 nodes in each of the two server centers, a total of 30 nodes. Consensus requires more than 2 / 3 of the nodes to work properly, that is, at least 21 nodes need to work properly. Therefore, each server center needs to back up 6 nodes in the other server center to meet the consensus requirements.

[0028] S3. During the operation of the above consortium blockchain system, when the administrator determines that there is an abnormality in the consortium blockchain network and finds out the server center where the fault occurs, the server center where the fault occurs is called the faulty center, and the server center that operates normally is called the normal center;

[0029] S4. Use the consensus private key backup stored by the backup node in the normal center to simulate and calculate the data that the faulty node needs to generate, and at the same time continue to perform corresponding data calculations with the original consensus private key in the normal center to obtain the corresponding data;

[0030] Among them, the emergency method when a certain server center in the consortium blockchain system described in steps S1 - S2 fails is as Figure 2 shown, including the following steps:

[0031] S41. The administrator sends an emergency instruction to the backup node in the normal center;

[0032] S42. Simulate the failed center through the consensus private key of the failed center stored in the backup node of the backup node, and simulate and calculate corresponding data through the backup consensus private key; at the same time, use the original consensus private key deployed in the normal center to continue the data calculation process before the computer failure to obtain corresponding data;

[0033] S43. Send all the data obtained through the consensus private key in step S42 to the corresponding business process;

[0034] S5. Execute data processing through the service private key to obtain the original data of the transaction service;

[0035] S6. Send the original data obtained in step S5 to the receiving party, thereby completing the emergency measure for the consensus failure on the consortium blockchain.

[0036] Embodiment 1. Application of the raft consensus mechanism in the consortium blockchain system

[0037] When the raft consensus mechanism in the consortium blockchain system works normally, the workflow for selecting a new leader node through the raft consensus mechanism includes the following steps:

[0038] i-1) Increase the local currentTerm value in the server nodes storing the consensus private key in each server center, and switch the server nodes to the candidate state;

[0039] i-2) The server nodes perform data processing through the consensus private keys stored respectively, and each consensus private key generates a leader vote information;

[0040] i-3) The server nodes storing the consensus private key vote for themselves and send an RPC message named RequestVote to other server nodes to request votes;

[0041] i-4) The server nodes wait for messages from other server nodes.

[0042] When the consortium blockchain system cannot produce blocks normally and the consensus cannot elect a leader, the raft consensus mechanism fails. At this time, the emergency process for selecting a leader node includes the following steps:

[0043] i-1) Confirm the failed center and send an emergency instruction to the backup node of the normal center;

[0044] i-2) Increase the local currentTerm value in each node of the normal center and switch each node to the candidate state;

[0045] i-3) All nodes of the normal center perform data processing through the consensus private key, and each generates a leader voting message by using the stored consensus private key;

[0046] i-4) Each of the consensus private keys votes the leader voting message to the server node stored by itself, and votes the votes of the consensus private keys backed up in the backup nodes to the server node stored by itself, and sends an RPC message named RequestVote to other server nodes in the normal center to request a vote; i-5) The server node waits for messages from other server nodes.

[0047] As can be seen from the working process of the consortium blockchain system that follows the raft consensus mechanism above, when a server center fails, since half or more of the server nodes in the consortium blockchain system cannot participate in the consensus process, the leader node cannot be normally elected; in response to this situation, by using the consensus private keys backed up in the normal center, the number of consensus private keys participating in the consensus process can meet the consensus requirements, and the consensus result is equivalent to the consensus where all nodes participate in the consensus, thereby restoring the raft protocol and achieving the emergency goal.

[0048] Example 2. Application of the PBFT consensus mechanism in the consortium blockchain system is as Figure 3 shown

[0049] When the PBFT consensus mechanism in the consortium blockchain system works normally, the consensus process through the PBFT consensus mechanism includes the following steps:

[0050] i-1) Pre-Prepare stage: The primary node is responsible for verifying the request message and generating a corresponding pre-prepare message, and then broadcasts the pre-prepare message to all nodes participating in the consensus. After receiving the pre-prepare message, the nodes verify the legality of the pre-prepare message and broadcast the corresponding prepare message;

[0051] i-2) Prepare stage: The nodes collect the prepare messages. After collecting 2f + 1 prepare messages, they start to broadcast the commit message;

[0052] i-3) Commit stage: Responsible for collecting the commit messages. After a certain node collects 2f + 1 commit messages, it directly processes the original request message cached locally and changes the corresponding system state, that is, the consensus is completed.

[0053] When the number of collected prepare messages is insufficient, the PBFT consensus mechanism fails. The emergency process for selecting the leader node at this time includes the following steps:

[0054] i-1) Identify the failure center and send an emergency instruction to the backup node of the normal center;

[0055] i-2) Pre-Prepare phase: The primary node is responsible for verifying the request message, generating the corresponding pre-prepare message, and then broadcasting the pre-prepare message to the server nodes and backup nodes of the normal center. After receiving the pre-prepare message, the nodes verify the legality of the pre-prepare message; at the server nodes of the normal center, the corresponding prepare message is generated using the consensus private key stored therein; at the backup nodes of the normal center, the corresponding prepare message is generated using the backup consensus private key, and all the prepare messages generated by the normal center are broadcast;

[0056] i-3) Prepare phase: The nodes collect the prepare messages. After collecting 2f + 1 prepare messages, the corresponding commit messages are generated using all the consensus private keys of the normal center. The commit messages include the corresponding commit messages generated using the consensus private keys of the original server nodes of the normal center, and also include the corresponding prepare messages generated using the backup consensus private keys in the backup nodes of the normal center, and start broadcasting the commit messages;

[0057] i-4) Commit phase: Responsible for collecting the commit messages. After a certain node collects 2f + 1 commit messages, the original request message cached locally is directly processed and the corresponding system state is changed, thus completing the consensus.

[0058] From the working process of the consortium blockchain system that follows the PBFT consensus mechanism above, it can be seen that when a server center fails, since half or more of the server nodes in the consortium blockchain system cannot participate in the consensus process, sufficient prepare messages and commit messages cannot be generated; for this situation, using the backup consensus private keys in the normal center enables the number of consensus private keys participating in the consensus process in the consortium blockchain system to meet the consensus requirements, generating sufficient prepare messages and commit messages, thereby restoring the PBFT protocol and achieving the emergency goal.

[0059] By adopting the above technical solutions disclosed in the present invention, the following beneficial effects are obtained:

[0060] The present invention discloses an emergency method for consensus failure on a consortium blockchain, which distinguishes consensus private keys from business private keys to effectively control the security boundaries for backing up corresponding private keys in the emergency plan; the consortium blockchain system is deployed in a dual-center manner, and partial consensus private keys of each server center are mutually backed up in each server center, so that the number of consensus private keys stored in the normal application server nodes and backup nodes of each server center can meet the consensus requirements, thereby reducing the storage and efficiency burdens caused by completely cloning source nodes; the present invention designs a lightweight recovery method for faulty nodes, which does not require data reconstruction or copying, only some simple cryptographic calculations, avoiding the large delay consumption of copying data, and also does not require additional physical resources to reconstruct faulty nodes, enabling faulty nodes to be recovered in seconds and supporting the system to resume consensus.

[0061] The above are only the preferred embodiments of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present invention.

Claims

1. An emergency method for consensus failure on a consortium blockchain, characterized in that, it includes the following steps: S1. In the consortium blockchain system, distinguish the consensus process and the business process, respectively declare the consensus public key and the business public key, and correspondingly set the consensus private key and the business private key; S2. Deploy the consensus private keys to two different server centers respectively, and set a backup node in each server center. Part of the consensus private keys of the other server center are backup stored in the backup node, so that each server center is deployed with the consensus private keys that can meet the consensus requirements; Each server center includes more than one server node and a backup node; only one consensus private key is stored in each server node, and more than one consensus private key is backup stored in the backup node; S3. During the operation of the above consortium blockchain system, when the administrator determines that there is an abnormality in the consortium blockchain system and finds out the server center where the failure occurs, the server center where the failure occurs is called the failure center, and the normally operating server center is called the normal center; S4. The consensus private keys backup stored by the backup nodes of the normal center simulate and calculate the data that the failure center needs to generate. At the same time, the corresponding data is generated by the original consensus private keys of the normal center; all the data obtained by the normal center is sent to the corresponding business process; S5. Execute data processing through the business private key to obtain the original data of the transaction business; S6. Send the original data obtained in step S5 to the receiving party, thereby completing the emergency measure for consensus failure on the consortium blockchain.

2. The emergency method for consensus failure on a consortium blockchain according to claim 1, characterized in that, when a certain server center in the consortium blockchain system described in steps S1 - S2 fails, the emergency process includes the following steps: S41. The administrator sends an emergency instruction to the backup node of the normal center; S42. The backup node uses the consensus private keys of the failure center backup stored in it to simulate the nodes corresponding to the failure center participating in the consensus, and simulates and calculates to generate the corresponding data through the backup consensus private keys; at the same time, continue the data calculation process before the failure using the original consensus private keys deployed in the normal center to obtain the corresponding data; S43. Send all the data obtained by the normal center in step S42 to the corresponding business process.

3. The emergency method for consensus failure on a consortium blockchain according to claim 1, characterized in that, the consensus public key and the consensus private key are only applied to the consensus process to verify whether the transaction initiator can pass the consensus of the consortium blockchain system; the business public key and the business private key are only applied to the transaction business process to determine whether the transaction initiator is legal.

Images