CN114944913A - Emergency method for consensus failure on alliance chain - Google Patents
Emergency method for consensus failure on alliance chain Download PDFInfo
- Publication number
- CN114944913A CN114944913A CN202210533149.0A CN202210533149A CN114944913A CN 114944913 A CN114944913 A CN 114944913A CN 202210533149 A CN202210533149 A CN 202210533149A CN 114944913 A CN114944913 A CN 114944913A
- Authority
- CN
- China
- Prior art keywords
- consensus
- center
- private key
- server
- node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
- H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
Abstract
An emergency method for consensus failure on a alliance chain is characterized in that a consensus private key and a service private key are distinguished, so that the safety boundary of the corresponding private key can be effectively controlled and backed up in an emergency scheme; the alliance chain system is deployed in a double-center mode, partial consensus private keys capable of being used in the server center are mutually backed up in each server center, the number of the consensus private keys stored in the server nodes and the backup nodes normally applied by each server center can meet the consensus requirement, and therefore storage and efficiency burden caused by complete cloning of source nodes is reduced; the invention designs a recovery mode of the light-weight fault node, does not need to rebuild and copy data, only needs some simple cryptographic calculation, avoids a large amount of delay consumption of the copy data, does not need to occupy extra physical resources to rebuild the fault node, enables the fault node to be recovered in a second level, and supports the recovery consensus of the system.
Description
Technical Field
The invention relates to the technical field of block chains, in particular to an emergency method for consensus failure on a alliance chain.
Background
The alliance chain is a system form between a public chain and a private chain, is usually controlled by a plurality of centers, and is cooperatively maintained by a plurality of organizations, the use of the block chain needs to be limited access with authority, and related information can be protected, such as a supply chain organization or a bank alliance. The alliance chain is controlled by a plurality of nodes formulated by an organization, and the nodes manage and send the whole system according to a consensus mechanism; each node of a federation chain typically has a corresponding entity authority that can join or leave the system only if approved by the federation. Organization of various interest-related organizations develop close cooperation on block chains and jointly maintain the development of system health and stability
The alliance chain is widely applied in China, but is limited by physical equipment reasons, most enterprises deploy the alliance chain in one or two machine rooms, the distributed characteristic of the original block chain is inhibited, and the original block chain cannot form a disaster recovery system when deployed in one machine room; once a certain machine room is wholly failed, most of the existing consensus can not work normally, for example, consensus such as raft, pbft, pos and the like common in a alliance chain needs to be developed on an existing system; when the alliance chain is deployed in two machine rooms, the alliance chain is a common double-center deployment. A common emergency method is that the information of all nodes in the center of the opposite side is backed up. When the single center fails, the disaster recovery backup plan is started for emergency at the other center, and the block chain nodes are rebuilt locally by using the backup information to recover the existing network consensus. However, the reconstruction of the blockchain node requires complete cloning of the source node, including copying of blockchain data and the like, which greatly consumes storage resources and also affects the efficiency of network recovery.
Disclosure of Invention
The invention aims to provide an emergency method for consensus failure on a alliance chain, so as to solve the problems in the prior art.
In order to achieve the purpose, the technical scheme adopted by the invention is as follows:
an emergency method for consensus failure on a alliance chain comprises the following steps:
s1, distinguishing the consensus process and the service process in the alliance chain system, respectively declaring a consensus public key and a service public key, and correspondingly setting a consensus private key and a service private key;
s2, the consensus private keys are respectively deployed in two different server centers, each server center is provided with a backup node, partial consensus private key of the other server center is stored in the backup node in a backup mode, and each server center is enabled to be deployed with the consensus private key capable of meeting the consensus requirement;
s3, in the operation process of the alliance chain system, when the administrator judges that the alliance chain network is abnormal, finding out a server center with a fault, and calling the server center with the fault as a fault center and the server center with normal operation as a normal center;
s4, simulating and calculating the data needed to be generated by the fault node by the consensus private key stored in the backup node of the normal center, and generating corresponding data by the original consensus private key of the normal center; all data obtained by the normal center are sent to the corresponding business process;
s5, performing data processing through the service private key to obtain the original data of the transaction service;
and S6, sending the original data obtained in the step S5 to a receiver, thereby completing emergency measures of consensus failure on the alliance chain.
Preferably, when a server center in the federation chain system fails in steps S1-S2, the emergency process includes the following steps:
s41, an administrator sends an emergency instruction to the backup node of the normal center;
s42, simulating nodes corresponding to the fault center and participating in consensus through the consensus private key of the fault center stored in the backup node in a backup mode, and generating corresponding data through simulation calculation of the consensus private key of the backup node; meanwhile, the original consensus private key deployed in the normal center is utilized to continue the data calculation process before the fault, so that corresponding data are obtained;
and S43, sending all the data obtained by the normal center in the step S42 to the corresponding business process.
Preferably, each server center comprises more than one server node and one backup node; each server node is stored with only one common private key, and the backup node is stored with more than one common private key in a backup mode.
Preferably, the consensus public key and the consensus private key are only applied to the consensus process and used for verifying whether the transaction initiator can pass the consensus of the alliance chain system; the business public key and the business private key are only applied to the business process of the transaction, and whether a transaction initiator is legal or not is judged.
The invention has the beneficial effects that: the invention discloses an emergency method for consensus failure on a alliance chain, which distinguishes a consensus private key and a service private key, and is convenient for effectively controlling and backing up the safety boundary of the corresponding private key in an emergency scheme; the alliance chain system is deployed in a double-center mode, partial consensus private keys capable of being in the server center are mutually backed up in each server center, and the number of the consensus private keys stored in the server nodes and the backup nodes normally applied by each server center can meet the requirement of consensus, so that storage and efficiency burden caused by completely cloning source nodes is reduced; the invention designs a recovery mode of the light-weight fault node, does not need to rebuild and copy data, only needs some simple cryptographic calculation, avoids a large amount of delay consumption of the copy data, does not need to occupy extra physical resources to rebuild the fault node, enables the fault node to be recovered in a second level, and supports the recovery consensus of the system.
Drawings
FIG. 1 is a flow diagram of an emergency method of consensus failure on a federation chain;
FIG. 2 is a flow chart of post-failure emergency processing;
fig. 3 is a PBFT protocol flow diagram.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is further described in detail below with reference to the accompanying drawings. It should be understood that the detailed description and specific examples, while indicating the invention, are intended for purposes of illustration only and are not intended to limit the scope of the invention.
An emergency method for consensus failure on a alliance chain is characterized in that a consensus process and a service process in the alliance chain are distinguished, and a consensus public key and a service public key are declared; deploying the consensus private keys in the two server centers, and backing up part of the consensus private keys of the server center of the other side in each server center, so that the consensus private keys stored in one server center can meet the consensus requirement; when one server center fails, the server center without the failure independently completes the consensus identification, transmits the data processed by the consensus private key to the corresponding service process, and completes the data processing through the service private key. As shown in fig. 1, the method comprises the following steps:
s1, distinguishing the consensus process and the business process in the alliance chain system, respectively declaring a consensus public key and a business public key, and correspondingly setting a consensus private key and a business private key; the common public key and the common private key are only applied to the common process and used for verifying whether a transaction initiator can pass the common identification of the alliance chain system, and the service public key and the service private key are only applied to the transaction service process and used for judging whether the transaction initiator is legal;
s2, the consensus private keys are respectively deployed in two different server centers, each server center is provided with a backup node, partial consensus private key of the other server center is stored in the backup node in a backup mode, and each server center is enabled to be deployed with the consensus private key capable of meeting the consensus requirement;
for example, if the federation chain system agrees to agree following most principles, the number of agreed-upon private keys held by each of the server-centric nodes should exceed half; if the federation chain system agrees to comply with Byzantine fault tolerance principles, the number of consensus private keys held by each of the server center nodes should exceed 2/3 of the total number. Specifically, if the federation chain system applies the PBFT consensus mechanism, 15 nodes and 30 nodes are respectively provided in two server centers, and the consensus needs to exceed 2/3 nodes to work normally, that is, at least 21 nodes need to work normally, so that each server center needs to backup 6 nodes in the server center of the other server center to meet the consensus requirement.
S3, in the operation process of the alliance chain system, when the administrator judges that the alliance chain network is abnormal, finding out a server center with a fault, and calling the server center with the fault as a fault center and the server center with normal operation as a normal center;
s4, simulating and calculating the data required to be generated by the fault node by the consensus private key stored in the backup node of the normal center, and meanwhile, continuing to perform corresponding data calculation by the original consensus private key of the normal center to obtain corresponding data;
fig. 2 shows an emergency method after a failure occurs in a server center in the federation chain system from step S1 to step S2, which includes the following steps:
s41, an administrator sends an emergency instruction to the backup node of the normal center;
s42, simulating the fault center through the consensus private key of the fault center backed up and stored in the backup node, and generating corresponding data through the simulation calculation of the consensus private key backed up; meanwhile, the original consensus private key deployed by the normal center is utilized to continue the data calculation process before the computer fails, and corresponding data are obtained;
s43, sending all the data obtained by the consensus private key in the step S42 to the corresponding business process;
s5, performing data processing through the service private key to obtain the original data of the transaction service;
and S6, sending the original data obtained in the step S5 to a receiver, thereby completing emergency measures of consensus failure on the alliance chain.
Embodiment 1, application of raft consensus mechanism in alliance chain system
When a raft consensus mechanism in a alliance chain system works normally, the workflow of selecting a new leader node through the raft consensus mechanism comprises the following steps:
i-1) adding a local currentTerm value in each server node with the server center storing the consensus private key, and switching the server node into a candidate state;
i-2) the server nodes perform data processing through the respective stored consensus private keys, and the consensus private keys respectively generate leader voting information;
i-3) the server nodes which store the consensus private key cast the leader voting information to the server nodes, and send RPC messages named RequestVote to other server nodes to request voting;
i-4) the server node waits for messages of other server nodes.
And when the alliance chain system cannot normally produce the block and consensus cannot select the leader, the raft consensus mechanism fails, and the emergency flow for selecting the leader node at the moment comprises the following steps:
i-1) confirming a fault center and sending an emergency instruction to a backup node of a normal center;
i-2) adding a currentTerm value of the local in each node of the normal center, and switching each node into a candidate state;
i-3) all nodes of the normal center perform data processing through the consensus private key, and generate leader voting information by using the stored consensus private key respectively;
i-4) each consensus private key throws the leader voting information to a server node stored by the consensus private key, throws the votes of the consensus private key backed up in the backup node to the server node stored by the consensus private key, and sends RPC messages named RequestVote to other server nodes of the normal center to request voting; i-5) the server node waits for messages of other server nodes.
As can be seen from the above workflow of the alliance chain system conforming to the raft consensus mechanism, when one server center fails, half or more server nodes in the alliance chain system cannot participate in the consensus process, so that a leader node cannot be normally elected; for the situation, the number of the consensus private keys participating in the consensus process can meet the consensus requirement by using the consensus private key backed up in the normal center, and the consensus result is equal to the consensus that all the nodes participate in the consensus, so that the raft protocol is recovered, and the emergency goal is achieved.
Embodiment 2, application of PBFT consensus mechanism in Federation chain System is shown in FIG. 3
When the PBFT consensus mechanism in the alliance chain system works normally, the consensus process through the PBFT consensus mechanism comprises the following steps:
i-1) Pre-Prepare stage: the main node is responsible for verifying the request message and generating a corresponding pre-preamble message, then broadcasting the pre-preamble message to all nodes participating in the consensus, and after receiving the pre-preamble message, the nodes verify the legality of the pre-preamble message and broadcast the corresponding preamble message;
i-2) Premate stage: collecting the prefix information by the node, and starting broadcasting the commit information after collecting the prefix information which is full of 2f + 1;
i-3) Commit phase: and the node is responsible for collecting commit messages, directly processes the original request messages cached locally and changes the corresponding system state after collecting the commit messages of 2f +1, namely, the consensus is completed.
And when the collection quantity of the prefix messages is insufficient, the PBFT consensus mechanism fails, and the emergency flow for selecting the leader node at the moment comprises the following steps:
i-1) confirming a fault center and sending an emergency instruction to a backup node of a normal center;
i-2) Pre-Prepare stage: the main node is responsible for verifying the request message and generating a corresponding pre-prefix message, then broadcasting the pre-prefix message to the server node and the backup node of the normal center, and after receiving the pre-prefix message, the node verifies the validity of the pre-prefix message; in a server node of a normal center, generating a corresponding prefix message by using a common identification private key stored in the server node; at a backup node of a normal center, generating a corresponding prefix message by using a backup consensus private key, and broadcasting all the prefix messages generated by the normal center;
i-2) Prepare stage: collecting the prefix information by a node, generating a corresponding commit information by using all the consensus private keys of the normal center after collecting the prefix information with 2f +1, wherein the commit information comprises the corresponding commit information generated by the consensus private key of the original server node of the normal center and the corresponding prefix information generated by the consensus private key backed up in the backup node of the normal center, and starting to broadcast the commit information; (ii) a
i-3) Commit phase: and the node is responsible for collecting the commit message, directly processes the original request message of the local cache and changes the corresponding system state after collecting the commit message of 2f +1, thereby completing consensus.
As can be seen from the above working flow of the federation chain system conforming to the PBFT consensus mechanism, when a server center fails, since half or more server nodes in the federation chain system cannot participate in the consensus flow, a sufficient number of prepare messages and commit messages cannot be generated; aiming at the situation, the number of the common identification private keys participating in the common identification process in the alliance chain system meets the common identification requirement by using the common identification private key backed up in the normal center, and enough preamble messages and commit messages are generated, so that the PBFT protocol is recovered, and the emergency goal is achieved.
By adopting the technical scheme disclosed by the invention, the following beneficial effects are obtained:
the invention discloses an emergency method for consensus failure on a alliance chain, which distinguishes a consensus private key and a service private key, and is convenient for effectively controlling and backing up the safety boundary of the corresponding private key in an emergency scheme; the alliance chain system is deployed in a double-center mode, partial consensus private keys capable of being in the server center are mutually backed up in each server center, and the number of the consensus private keys stored in the server nodes and the backup nodes normally applied by each server center can meet the requirement of consensus, so that storage and efficiency burden caused by completely cloning source nodes is reduced; the invention designs a recovery mode of the light-weight fault node, does not need to rebuild and copy data, only needs some simple cryptographic calculation, avoids a large amount of delay consumption of the copy data, does not need to occupy extra physical resources to rebuild the fault node, enables the fault node to be recovered in a second level, and supports the recovery consensus of the system.
The foregoing is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, various modifications and improvements can be made without departing from the principle of the present invention, and such modifications and improvements should also be considered within the scope of the present invention.
Claims (4)
1. An emergency method for consensus failure on a alliance chain is characterized by comprising the following steps:
s1, distinguishing the consensus process and the business process in the alliance chain system, respectively declaring a consensus public key and a business public key, and correspondingly setting a consensus private key and a business private key;
s2, the consensus private keys are respectively deployed in two different server centers, each server center is provided with a backup node, partial consensus private key of the other server center is stored in the backup node in a backup mode, and each server center is enabled to be deployed with the consensus private key capable of meeting the consensus requirement;
s3, in the operation process of the alliance chain system, when the administrator judges that the alliance chain network is abnormal, finding out a server center with a fault, and calling the server center with the fault as a fault center and the server center with normal operation as a normal center;
s4, simulating and calculating the data needed to be generated by the fault node by the consensus private key stored in the backup node of the normal center, and generating corresponding data by the original consensus private key of the normal center; all data obtained by the normal center are sent to the corresponding business process;
s5, executing data processing through the service private key to obtain the original data of the transaction service;
and S6, sending the original data obtained in the step S5 to a receiver, thereby completing the emergency measures of consensus failure on the alliance chain.
2. The method of claim 1, wherein when a server center in the federation chain system fails in step S1-step S2, the emergency process comprises the following steps:
s41, an administrator sends an emergency instruction to the backup node of the normal center;
s42, simulating nodes corresponding to the fault center and participating in consensus through the consensus private key of the fault center stored in the backup node in a backup mode, and generating corresponding data through simulation calculation of the consensus private key of the backup node; meanwhile, the original consensus private key deployed in the normal center is utilized to continue the data calculation process before the fault, so that corresponding data are obtained;
and S43, sending all the data obtained by the normal center in the step S42 to the corresponding business process.
3. An emergency method for alliance-link consensus failure as claimed in claim 1 wherein each of said server centers comprises more than one server node and a backup node; each server node is stored with only one common private key, and the backup node is stored with more than one common private key in a backup mode.
4. The method for emergent consensus failure on a federation chain as claimed in claim 1, wherein the consensus public key and the consensus private key are only applied in the consensus process for verifying whether the transaction initiator can pass the consensus of the federation chain system; the business public key and the business private key are only applied to the business process of the transaction, and whether a transaction initiator is legal or not is judged.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210533149.0A CN114944913A (en) | 2022-05-12 | 2022-05-12 | Emergency method for consensus failure on alliance chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210533149.0A CN114944913A (en) | 2022-05-12 | 2022-05-12 | Emergency method for consensus failure on alliance chain |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114944913A true CN114944913A (en) | 2022-08-26 |
Family
ID=82907948
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210533149.0A Pending CN114944913A (en) | 2022-05-12 | 2022-05-12 | Emergency method for consensus failure on alliance chain |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114944913A (en) |
-
2022
- 2022-05-12 CN CN202210533149.0A patent/CN114944913A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| TWI724678B (en) | Consensus system downtime recovery | |
| AU2019203861B2 (en) | System and method for ending view change protocol | |
| TWI729609B (en) | Consensus system downtime recovery | |
| US20180308091A1 (en) | Fairness preserving byzantine agreements | |
| US7197632B2 (en) | Storage system and cluster maintenance | |
| AU2019203862B2 (en) | System and method for ending view change protocol | |
| CN109688012A (en) | A kind of method of alliance's chain node hot standby switch | |
| US7065674B2 (en) | Computer system fault recovery using distributed fault-recovery information | |
| US10938750B2 (en) | Consensus system downtime recovery | |
| WO2018192534A1 (en) | Node device running method, working state switching device, node device, and medium | |
| CN110635941A (en) | Database node cluster fault migration method and device | |
| CN111582845A (en) | Cross-chain transaction method and device of block chain and electronic equipment | |
| US20230004465A1 (en) | Distributed database system and data disaster backup drilling method | |
| US20040024807A1 (en) | Asynchronous updates of weakly consistent distributed state information | |
| WO2018076696A1 (en) | Data synchronization method and out-of-band management device | |
| CN112019380A (en) | Right excitation-based block chain consensus method combining Raft and PBFT algorithm | |
| CN114944913A (en) | Emergency method for consensus failure on alliance chain | |
| KR20190078451A (en) | Server and Recovery server for performing failure recovery of service server using block chain, Method for controlling the server | |
| CN113064768A (en) | Method and device for switching fragment nodes in block chain system | |
| KR102294048B1 (en) | Method and system for replicating blockchain application service | |
| AU2019101612A4 (en) | Consensus system downtime recovery | |
| AU2019101610A4 (en) | Consensus system downtime recovery | |
| CN116633699B (en) | Product anti-counterfeiting traceability information trusted processing method and system based on block chain | |
| JP2003242014A (en) | Database system and duplicating method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |