A consensus node fault-tolerant method, device and system in blockchain

Abstract

The application discloses a consensus node fault-tolerant method, device and system in a blockchain, wherein the method comprises the following steps: a first backup node detects whether there is a faulty consensus node in a plurality of consensus nodes in the blockchain; the first backup node is any backup node in a plurality of backup nodes outside the blockchain; the plurality of backup nodes comprise the first backup node and each second backup node; the plurality of backup nodes are used for backing up the faulty consensus node in the plurality of consensus nodes; if the first backup node is the first to determine that a first consensus node is faulty in the plurality of backup nodes, the first backup node is used as the first consensus node; and the plurality of consensus nodes comprise the first consensus node and each second consensus node. When the method is applied to Fintech, a consensus node fault-tolerant scheme with high node utilization and flexibility is provided.

Description

Technical Field

[0001] The present invention relates to the field of blockchain in the field of financial technology (Fintech), and in particular to a consensus node fault tolerance method, device and system in a blockchain. Background Art

[0002] With the development of computer technology, more and more technologies are being applied in the financial sector. Traditional finance is gradually shifting towards Fintech. However, the security and real-time requirements of the financial industry also place higher demands on technology. With the continuous development and popularization of blockchain-related technologies, more and more enterprises and institutions are beginning to use blockchain to improve collaboration efficiency and strengthen trust in multi-party collaboration scenarios.

[0003] However, consensus nodes in a blockchain may crash or fail, necessitating the use of backup nodes to replace them. Current solutions assign multiple backup nodes to each consensus node, with these backup nodes prioritized for succession. However, this approach not only wastes a significant amount of backup node resources but also limits the flexibility of backup nodes due to the fixed backup strategy. Therefore, a consensus node fault-tolerance solution with high node utilization and flexibility is urgently needed. Summary of the Invention

[0004] The present invention provides a consensus node fault tolerance method, device and system in a blockchain, which solves the problem in the prior art of lacking a consensus node fault tolerance solution with high node utilization and flexibility.

[0005] In a first aspect, the present invention provides a consensus node fault tolerance method in a blockchain, comprising: a first alternative node detects whether there is a faulty consensus node among multiple consensus nodes in the blockchain; the first alternative node is any one of multiple alternative nodes outside the blockchain; the multiple alternative nodes include the first alternative node and each second alternative node; the multiple alternative nodes are used to back up the faulty consensus nodes among the multiple consensus nodes; if the first alternative node first determines that the first consensus node is faulty among the multiple alternative nodes, the first alternative node is used as the first consensus node; the multiple consensus nodes include the first consensus node and each second consensus node.

[0006] In the above method, the multiple candidate nodes are used to back up the failed consensus nodes among the multiple consensus nodes. Then, there is a many-to-many relationship between the multiple candidate nodes and the multiple consensus nodes, which avoids the waste of resources caused by one candidate node serving as a backup for only one consensus node. Moreover, among the multiple candidate nodes, the node that first determines that the first consensus node has failed in an adaptive manner is used as the first consensus node, thereby providing a consensus node fault-tolerant solution with high node utilization and flexibility.

[0007] Optionally, the first candidate node determines that the first consensus node has failed in the following manner: if the first candidate node determines that the heartbeat test with the first consensus node has timed out, it determines the suspected fault information of the first consensus node and counts the total number of suspected fault information of the first consensus node; the suspected fault information of the first consensus node includes: the suspected fault information determined by the first candidate node and the suspected fault information from each of the second candidate nodes; if within a preset time period, the first candidate node determines that the total number of information is greater than a preset threshold, it determines that the first consensus node has failed.

[0008] In the above method, when the first candidate node determines that the heartbeat test with the first consensus node has timed out, it does not directly determine that the first consensus node has failed, but rather counts the total number of suspected failure information of the first consensus node. If within a preset time period, the first candidate node determines that the total number of information is greater than a preset threshold, it determines that the first consensus node has failed. In this way, the first candidate node will not misjudge the failure status of the first consensus node due to the misjudgment of the first candidate node's heartbeat test timeout by the first consensus node, and the failure of the first consensus node can be determined more accurately.

[0009] Optionally, the preset duration is positively correlated with the total number of the multiple consensus nodes; the preset threshold is determined based on the total number of the multiple consensus nodes and a preset ratio.

[0010] In the above method, the preset time length is positively correlated with the total number of the multiple consensus nodes, so that feedback from more consensus nodes can be received within the preset time length, and the preset threshold is determined based on the total number of the multiple consensus nodes and the preset ratio, so that a preset threshold that adapts to the total number of the multiple consensus nodes can be obtained.

[0011] Optionally, the taking of the first candidate node as the first consensus node includes: for any second consensus node among the second consensus nodes, the first candidate node sends the first identity certificate to the second consensus node, and obtains the second identity certificate from the second consensus node; the first candidate node sends the first master public key and the first random value to the second consensus node, and obtains the second master public key and the second random value from the second consensus node; the first candidate node generates a first temporary private key and a first temporary public key based on the first master public key, the first random value, the second master public key and the second random value according to the elliptic curve algorithm, and signs the first temporary public key with the first temporary private key to obtain a first signature; the first candidate node sends the first temporary public key and the first signature to the second consensus node; the first candidate node obtains the second temporary public key and the second signature from the second consensus node, and verifies that the second signature is passed; the first candidate node obtains the first encrypted information from the second consensus node, decrypts the first encrypted information with a shared key, and obtains the first random value; the first candidate node encrypts the second random value with the shared key, obtains second encrypted information, and sends the second encrypted information to the second consensus node.

[0012] Under the above method, the first candidate node and the second consensus node exchange identity certificates to complete identity authentication, and verify the legitimacy of the first candidate node joining the blockchain through the circular curve algorithm interactive signature and random value. Even if the first consensus node fails, sensitive information such as the private key of the first consensus node will not be leaked, thereby improving the security of the consensus node backup.

[0013] Optionally, if the first candidate node first determines that the first consensus node has failed among the multiple candidate nodes, the first candidate node sends a backup declaration message to each of the second candidate nodes after determining that the first consensus node has failed; the backup declaration message is used to declare that the first candidate node is a candidate node for backing up the first consensus node; after the first candidate node uses the first candidate node as the first consensus node, it also includes: the first candidate node sends a successful backup message to each of the second candidate nodes; the successful backup message is used to declare that the first candidate node has successfully backed up the first consensus node.

[0014] Under the above method, after determining that the first consensus node has failed, the first candidate node sends a backup declaration message to each of the second candidate nodes, and after the first candidate node uses the first candidate node as the first consensus node, it sends a successful backup message to each of the second candidate nodes, thereby transmitting status messages during backup or failure and synchronizing them in the blockchain in a timely manner.

[0015] In a second aspect, the present invention provides a consensus node fault-tolerant device in a blockchain, comprising: a detection module for detecting whether there is a faulty consensus node among multiple consensus nodes in the blockchain; the first alternative node is any one of the multiple alternative nodes outside the blockchain; the multiple alternative nodes include the first alternative node and each second alternative node; the multiple alternative nodes are used to back up the faulty consensus nodes among the multiple consensus nodes; a processing module for using the first alternative node as the first consensus node if the first alternative node first determines that the first consensus node is faulty among the multiple alternative nodes; the multiple consensus nodes include the first consensus node and each second consensus node.

[0016] Optionally, the processing module is specifically used to: if it is determined that the heartbeat test with the first consensus node has timed out, determine the suspected fault information of the first consensus node, and count the total number of suspected fault information of the first consensus node; the suspected fault information of the first consensus node includes: the suspected fault information determined by the first alternative node and the suspected fault information from each second alternative node; if within a preset time length, it is determined that the total number of information is greater than a preset threshold, then it is determined that the first consensus node is faulty.

[0017] Optionally, the preset duration is positively correlated with the total number of the multiple consensus nodes; the preset threshold is determined based on the total number of the multiple consensus nodes and a preset ratio.

[0018] Optionally, the processing module is specifically used to: for any second consensus node among the second consensus nodes, send the first identity certificate to the second consensus node, and obtain the second identity certificate from the second consensus node; send the first master public key and the first random value to the second consensus node, and obtain the second master public key and the second random value from the second consensus node; based on the first master public key, the first random value, the second master public key and the second random value, generate a first temporary private key and a first temporary public key according to the elliptic curve algorithm, and sign the first temporary public key with the first temporary private key to obtain a first signature; send the first temporary public key and the first signature to the second consensus node; the first candidate node obtains the second temporary public key and the second signature from the second consensus node, and verifies that the second signature passes; obtains the first encrypted information from the second consensus node, decrypts the first encrypted information with the shared key to obtain the first random value; encrypts the second random value with the shared key to obtain second encrypted information, and sends the second encrypted information to the second consensus node.

[0019] Optionally, the processing module is also used to: if the first consensus node is first determined to be faulty among the multiple alternative nodes, after determining that the first consensus node is faulty, send a backup declaration message to each of the second alternative nodes; the backup declaration message is used to declare that the first alternative node is an alternative node for backing up the first consensus node; the processing module is also used to: send a successful backup message to each of the second alternative nodes; the successful backup message is used to declare that the first alternative node has successfully backed up the first consensus node.

[0020] The beneficial effects of the above-mentioned second aspect and each optional device of the second aspect can refer to the beneficial effects of the above-mentioned first aspect and each optional method of the first aspect, and will not be repeated here.

[0021] In a third aspect, the present invention provides a consensus node fault-tolerant system in a blockchain, comprising: multiple alternative nodes and multiple consensus nodes; the multiple alternative nodes are used to back up faulty consensus nodes among the multiple consensus nodes; a first alternative node is used to detect whether there is a faulty consensus node among the multiple consensus nodes; the first alternative node is any one of the multiple alternative nodes; the multiple alternative nodes include the first alternative node and each second alternative node; the first alternative node is used to use the first alternative node as the first consensus node if the first consensus node is first determined to be faulty among the multiple alternative nodes; the multiple consensus nodes include the first consensus node and each second consensus node.

[0022] Optionally, for any second consensus node among the second consensus nodes, a heartbeat test is maintained between the first candidate node and the second consensus node; for any second candidate node among the second candidate nodes, a heartbeat test is maintained between the first candidate node and the second candidate node.

[0023] In a fourth aspect, the present invention provides a computer device, comprising a program or instructions, which, when executed, is used to execute the above-mentioned first aspect and each optional method of the first aspect.

[0024] In a fifth aspect, the present invention provides a computer-readable storage medium comprising a program or instructions, which, when executed, is used to execute the above-mentioned first aspect and each optional method of the first aspect.

[0025] These and other aspects of the present invention will become more readily apparent from the following description of the embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0027] Figure 1 A schematic diagram of a process flow of a consensus node fault-tolerant system in a blockchain provided by an embodiment of the present invention;

[0028] Figure 2 A schematic diagram of the system architecture corresponding to a consensus node fault tolerance method in a blockchain provided by an embodiment of the present invention;

[0029] Figure 3 A schematic diagram of the structure of a consensus node fault-tolerant device in a blockchain provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0030] To make the objectives, technical solutions, and advantages of the present invention more apparent, the present invention will be further described in detail below with reference to the accompanying drawings. It is apparent that the embodiments described are only some, not all, of the present invention. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present invention without creative effort are intended to fall within the scope of protection of the present invention.

[0031] First, the nouns that appear in this application are listed.

[0032] Backup node: used to replace the failed node when the consensus node fails or crashes. The backup node synchronizes the data and network information of the consensus node to which it is connected.

[0033] Public key system: Keys are generated in pairs, each consisting of a public key and a private key. In practical applications, the private key is kept by the owner, while the public key needs to be made public.

[0034] Private key: The private key is the only credential of a blockchain account and is used to sign transactions.

[0035] ECDH: A key agreement algorithm that defines how two parties can securely generate and exchange keys.

[0036] Transaction signature: The transaction signature is similar to a stamp, which is used to ensure the ownership verification of the transaction. After receiving the transaction broadcast, the node will verify the transaction. If it passes, it will be included in the memory and packaged into the block. Otherwise, it will be discarded.

[0037] Digital certificate: refers to a digital certificate that marks the identity information of the communicating parties in Internet communication. People can use it to identify each other's identities online.

[0038] In the process of financial institutions (banking institutions, insurance institutions or securities institutions) conducting business (such as bank loan business, deposit business, etc.), more and more companies and institutions have begun to use blockchain to improve collaboration efficiency and enhance trust relationships. However, the consensus nodes in the blockchain may crash or fail, and then it is necessary to replace the consensus nodes with alternative nodes. In the current solution, the backup of consensus nodes is limited to a fixed alternative strategy, which makes the replacement of consensus nodes by alternative nodes not flexible enough. There is an urgent need for a consensus node fault-tolerant solution with high node utilization and flexibility. This situation does not meet the needs of financial institutions such as banks and cannot guarantee the efficient operation of various businesses of financial institutions. For this reason, Figure 1 As shown, the present invention provides a consensus node fault tolerance method in a blockchain.

[0039] Step 101: The first candidate node detects whether there is a faulty consensus node among multiple consensus nodes in the blockchain.

[0040] Step 102: If the first candidate node first determines that the first consensus node is faulty among the multiple candidate nodes, the first candidate node is used as the first consensus node.

[0041] The first candidate node is any candidate node among multiple candidate nodes outside the blockchain; the multiple candidate nodes include the first candidate node and each second candidate node; the multiple candidate nodes are used to back up failed consensus nodes among the multiple consensus nodes; the multiple consensus nodes include the first consensus node and each second consensus node.

[0042] In steps 101 and 102, for example, there are multiple consensus nodes in the blockchain: consensus node 1, consensus node 2, ..., consensus node 10; and multiple candidate nodes outside the blockchain: candidate node 1, candidate node 2, ..., candidate node 10. Candidate nodes 1-10 are used to back up consensus nodes 1-10. It should be noted that the mapping relationship between candidate nodes and consensus nodes can be flexibly configured based on the specific scenario, for example, candidate nodes 1-5 are used to back up consensus nodes 1 and 2; candidate nodes 2-6 are used to back up consensus nodes 3 and 4; ...; candidate nodes 5-9 are used to back up consensus nodes 9 and 10; and candidate node 10 is used to back up consensus nodes 1-10. Clearly, in the above example, candidate nodes can be reused, and through a many-to-many mapping relationship, many-to-many node backup can be achieved.

[0043] The multiple candidate nodes can detect whether there is a faulty consensus node among the multiple consensus nodes, such as by taking a heartbeat test or a remote login access method.

[0044] Taking the first alternative node as an example, if the first alternative node first determines that the first consensus node has failed among the multiple alternative nodes, the first alternative node will be used as the first consensus node. That is to say, the alternative node (the first alternative node) that first determines that the first consensus node has failed will be used as the first consensus node, that is, the first alternative node will take over the work of the first consensus node in the blockchain.

[0045] In addition, it should be noted that, when the first candidate node first determines that the first consensus node has failed among the multiple candidate nodes, there may be multiple ways to determine that the first candidate node is "the candidate node that first determines that the first consensus node has failed among the multiple candidate nodes." For example, it may be agreed that after determining that the first consensus node has failed, a fault indication message is sent with a timestamp, and the order of "determining the failure of the first consensus node" is determined by comparing the timestamps. For another example, if the first candidate node does not receive a fault indication message from any other second candidate node before determining that the first consensus node has failed, then it is determined that the first candidate node is the first among the multiple candidate nodes to determine that the first consensus node has failed.

[0046] In an optional implementation, the first candidate node determines that the first consensus node is faulty in the following manner:

[0047] Step (1-1): If the first candidate node determines that the heartbeat test with the first consensus node has timed out, it determines the suspected fault information of the first consensus node and counts the total number of pieces of suspected fault information of the first consensus node.

[0048] The suspected fault information of the first consensus node includes: the suspected fault information determined by the first candidate node and the suspected fault information from each of the second candidate nodes.

[0049] Step (1-2): If within a preset time period, the first candidate node determines that the total number of the information is greater than a preset threshold, it is determined that the first consensus node is faulty.

[0050] For example, after determining that the heartbeat test with the first consensus node has timed out, the first candidate node determines the suspected fault information of the first consensus node, that is, the first consensus node is suspected to have a fault, but it has not yet been determined whether a fault has actually occurred. At this time, the total number of suspected fault information of the first consensus node Count1=1. In addition, the first candidate node can also send the suspected fault information of the first consensus node to each of the second candidate nodes.

[0051] At this time, the other second candidate nodes may also determine that the heartbeat test with the first consensus node has timed out, and determine the suspected fault information of the first consensus node. Then, within the preset time period, the first candidate node may also receive suspected fault information from the second candidate nodes. Obviously, within the preset time period, the more the total number of suspected fault information of the first consensus node is, the more credible the fault of the first consensus node is.

[0052] For example, the preset time duration is 5 minutes, and the total number of suspected fault information of the first consensus node within 5 minutes is Count1 = 9. The preset threshold is 8, and the first candidate node determines that the first consensus node is faulty.

[0053] In the implementation of steps (1-1) to (1-2), the following settings can be made:

[0054] The preset duration is positively correlated with the total number of the plurality of consensus nodes; the preset threshold is determined based on the total number of the plurality of consensus nodes and a preset ratio.

[0055] Obviously, the larger the scale of the blockchain, the more backup nodes are needed, the longer the time it takes for the backup nodes to collect suspected fault information, and the larger the required preset threshold. Therefore, setting the preset time and the preset threshold can be adapted to the scale of the blockchain.

[0056] For example, the preset ratio is 1 / 2. If the first candidate node determines that more than half of the candidate nodes also determine the suspected fault information of the first consensus node, then the first consensus node is determined to be faulty.

[0057] In step 102, an optional scenario for using the first candidate node as the first consensus node is:

[0058] Step (2-1): For any second consensus node among the second consensus nodes, the first candidate node sends the first identity certificate to the second consensus node, and obtains the second identity certificate from the second consensus node.

[0059] Step (2-2): The first candidate node sends the first master public key and the first random value to the second consensus node, and obtains the second master public key and the second random value from the second consensus node.

[0060] Step (2-3): The first candidate node generates a first temporary private key and a first temporary public key based on the first master public key, the first random value, the second master public key and the second random value according to the elliptic curve algorithm, and signs the first temporary public key with the first temporary private key to obtain a first signature.

[0061] Step (2-4): The first candidate node sends the first temporary public key and the first signature to the second consensus node; the first candidate node obtains the second temporary public key and the second signature from the second consensus node, and verifies that the second signature passes.

[0062] Step (2-5): The first candidate node obtains the first encrypted information from the second consensus node, decrypts the first encrypted information using a shared key, and obtains the first random value; the first candidate node encrypts the second random value using the shared key, obtains the second encrypted information, and sends the second encrypted information to the second consensus node.

[0063] In the manner of steps (2-1) to (2-5), the first candidate node and the second consensus node exchange identity certificates to complete identity authentication, and verify the legitimacy of the first candidate node joining the blockchain through the circular curve algorithm interactive signature and random value. Even if the first consensus node fails, sensitive information such as the private key of the first consensus node will not be leaked, thereby improving the security of the consensus node backup, so that when a consensus node fails, the failed node can be switched and upgraded more safely and quickly, making the switching more efficient and safer.

[0064] In an optional implementation, if the first candidate node first determines that the first consensus node has failed among the multiple candidate nodes, the first candidate node sends a backup declaration message to each of the second candidate nodes after determining that the first consensus node has failed.

[0065] The backup declaration message is used to declare the first candidate node as a candidate node to back up the first consensus node.

[0066] In the above manner, the first candidate node sends a backup declaration message to each of the second candidate nodes, thereby declaring the first candidate node as a candidate node to be backed up for the first consensus node. Then, each of the second candidate nodes no longer needs to try to transmit suspected fault information and other actions, thereby keeping the status of the entire candidate nodes consistent.

[0067] Furthermore, in an optional implementation manner, after the first candidate node uses the first candidate node as the first consensus node, the following steps may be further performed:

[0068] The first candidate node sends a successful backup message to each of the second candidate nodes.

[0069] The successful backup message is used to declare that the first candidate node has successfully backed up the first consensus node.

[0070] In the above manner, the first candidate node sends a successful backup message to each of the second candidate nodes, thereby declaring the first candidate node as the candidate node for backing up the first consensus node. Then, each of the second candidate nodes does not need to try to replace the first consensus node, thereby keeping the status of the entire candidate nodes consistent.

[0071] Accordingly, the present application provides a consensus node fault-tolerant system in a blockchain, comprising multiple candidate nodes and multiple consensus nodes; the multiple candidate nodes are used to back up failed consensus nodes among the multiple consensus nodes;

[0072] A first candidate node is configured to detect whether there is a faulty consensus node among the multiple consensus nodes; the first candidate node is any one of the multiple candidate nodes; the multiple candidate nodes include the first candidate node and each second candidate node; the first candidate node is configured to use the first candidate node as the first consensus node if a fault of the first consensus node is first determined among the multiple candidate nodes; the multiple consensus nodes include the first consensus node and each second consensus node.

[0073] Optionally, the first candidate node is further used to: maintain a heartbeat test between the first candidate node and the second consensus node for any second consensus node among the second consensus nodes; maintain a heartbeat test between the first candidate node and the second candidate node for any second candidate node among the second candidate nodes.

[0074] Specifically, one architecture of the above system can be as follows Figure 2 As shown below, combined Figure 2 ,by Figure 2 Taking the system architecture shown as an example, the consensus node fault tolerance method in the blockchain provided by the present invention is further described in detail.

[0075] Preparation stage:

[0076] Participating institutions on the blockchain add N (N is a positive integer, N is greater than or equal to 3) candidate nodes and assign them identity certificates. The candidate nodes connect to the consensus nodes within the participating institutions and regularly synchronize the network configuration data, access credentials, block data, etc. of the consensus nodes.

[0077] Furthermore, each candidate node locally maintains a list of consensus node information and uses a heartbeat mechanism to detect the running status of the consensus node. When connecting to a consensus node, the identities of both parties must be verified based on the identity certificate (Verify(cert). If the verification is successful, the key agreement algorithm (ECDH) is used to generate a shared key SKey, and the shared key SKey is used for encrypted communication to ensure the security of data transmission between nodes.

[0078] The method for establishing encrypted communication using the shared key SK is as follows:

[0079] (1) The interacting nodes exchange public keys PK and a random value R.<PK,R> .

[0080] (2) Both nodes randomly generate a set of temporary key pairs (PubK, PriK) through the elliptic curve algorithm, and then sign the temporary public key PubK with their own private keys and exchange them.

[0081] (3) Both parties can verify the signature using their own public keys and obtain a temporary public key for this connection. Using a temporary public key can improve the security of data transmission and prevent leakage.

[0082] (4) Both parties use SK as the read-write key, and use SK to encrypt the received random value R using the AES algorithm and send it to the other party. The receiver uses SK to decrypt and verify whether R is the random value sent in step (1).

[0083] It should be noted that the above-mentioned encrypted communication method is applicable not only between candidate nodes and consensus nodes, but also between consensus nodes. The present invention adopts a method based on shared negotiation keys between different nodes, such as between consensus nodes and candidate nodes, and between candidate nodes, to ensure the secure transmission of data between nodes and prevent the leakage of information on the chain.

[0084] In the above communication method, each candidate node maintains a candidate node information list internally, and a heartbeat test (keep-alive) is maintained between the candidate nodes. When a candidate is added or removed, the list information is updated by broadcasting.

[0085] After the preparation phase, the fault detection phase begins:

[0086] When the first candidate node (e.g., CNodeA) detects a failure in the first consensus node (e.g., SNode), the following fault detection process is triggered:

[0087] Step 1: The first candidate node CNodeA starts to collect suspected fault information of the first consensus node SNode. The first candidate node locally counts the number of suspected fault information collected from the first consensus node SNode and marks it as G, and records the statistical start time T1.

[0088] Step 2: The first candidate node broadcasts the suspected failure information Fail-msg of the consensus node SNode to the remaining second candidate nodes.

[0089] Furthermore, when each candidate node receives SNode suspected failure information from other candidate nodes, it will accumulate the number G of consensus node SNode suspected failure information counted locally.

[0090] After each accumulation is completed, the difference between the current time T2 and the start time T1 is calculated to determine whether it exceeds the preset statistical time t. The calculation logic of time t is: t = 20s (seconds) + N * 5 (if the current number of nodes N = 3, the statistical timeout is 35 seconds. The preset time is positively correlated with the number of nodes). Whether it has timed out is determined as follows:

[0091] T2-T1>=t;

[0092] When the preset time t is reached, it indicates that the statistics have timed out. At this time, the fault statistics information of the current node SNode will be abandoned. After waiting for a certain period of time, the next cycle of fault detection statistics will be started.

[0093] Step 3: If the count has not timed out, the system then determines whether the current node count G exceeds N / 2 nodes, that is, whether messages from more than half of the nodes have been received. If so, it confirms that node SNode has indeed failed, triggering the replacement and upgrade mechanism for the current backup node (such as CNodeB). It should be further explained that the majority rule in the network topology ensures the consistency of cluster information.

[0094] Obviously, in the above steps, when a consensus node fails, the replacement mechanism is triggered only when more than half of the candidate nodes have detected the node failure, achieving the purpose of confirming the failure. The priority of the candidate node replacement is determined by election within the observation node group. The candidate node that first collects half of the failure information is selected as the replacement node and upgraded.

[0095] Step 4: The first candidate node CNodeA sends the backup declaration message Replace-msg to the remaining second candidate nodes. After receiving the backup declaration message, the remaining second candidate nodes stop counting the suspected fault information of SNode and remove the candidate node that first sent the Replace-msg from the candidate list. The specific operation statement can be:

[0096] Receive(Repalce-msg)-->RemoveCandidateNode(CNodeA);

[0097] At the same time, the first candidate node is used as a replacement node to start replacing the failed first consensus node.

[0098] Step 5: The first candidate node CNodeA will obtain the identity certificate information SNode.cert of the consensus node SNode from the local computer and try to join the blockchain.

[0099] In step 5, the first candidate node CNodeA performs identity authentication with each second consensus node. After passing the authentication, it starts encrypted communication with the remaining second consensus nodes and officially becomes the new consensus node.

[0100] Step 6: After the first candidate node CNodeA becomes the new consensus node, it broadcasts the successful backup message Success-msg to the candidate nodes.

[0101] After receiving the Success-msg message from node CNodeA, the candidate node adds the new consensus node to the consensus node list. The specific operation statement is as follows:

[0102] Receive(Success-msg)-->AddConsensusNode(CNodeA);

[0103] At the same time, start monitoring the new consensus node CNodeA and synchronize the node data of CNodeA.

[0104] At this point, the faulty consensus node SNode has completed automatic replacement and upgrade, and the first candidate node CNodeA has become the new consensus node and started to participate in the consensus on the blockchain.

[0105] The present invention proposes to replace faulty consensus nodes with alternative nodes. These alternative nodes will synchronize the block data and network status of the consensus nodes on the chain at any time. In addition, the observation nodes within a single organization are shared and can be used as alternatives to replace all the nodes participating in the consensus of the organization, greatly saving node resources.

[0106] like Figure 3 As shown, the present invention provides a consensus node fault-tolerant device in a blockchain, including: a detection module 301, used to detect whether there is a faulty consensus node among multiple consensus nodes in the blockchain; the first candidate node is any candidate node among multiple candidate nodes outside the blockchain; the multiple candidate nodes include the first candidate node and each second candidate node; the multiple candidate nodes are used to back up the faulty consensus nodes among the multiple consensus nodes; a processing module 302, used to use the first candidate node as the first consensus node if the first candidate node first determines that the first consensus node is faulty among the multiple candidate nodes; the multiple consensus nodes include the first consensus node and each second consensus node.

[0107] Optionally, the processing module 302 is specifically used to: if it is determined that the heartbeat test with the first consensus node has timed out, determine the suspected fault information of the first consensus node, and count the total number of suspected fault information of the first consensus node; the suspected fault information of the first consensus node includes: the suspected fault information determined by the first candidate node and the suspected fault information from each second candidate node; if it is determined that the total number of information is greater than a preset threshold within a preset time length, it is determined that the first consensus node is faulty.

[0108] Optionally, the preset duration is positively correlated with the total number of the multiple consensus nodes; the preset threshold is determined based on the total number of the multiple consensus nodes and a preset ratio.

[0109] Optionally, the processing module 302 is specifically used to: for any second consensus node among the second consensus nodes, send the first identity certificate to the second consensus node, and obtain the second identity certificate from the second consensus node; send the first master public key and the first random value to the second consensus node, and obtain the second master public key and the second random value from the second consensus node; based on the first master public key, the first random value, the second master public key and the second random value, generate a first temporary private key and a first temporary public key according to the elliptic curve algorithm, and sign the first temporary public key with the first temporary private key to obtain a first signature; send the first temporary public key and the first signature to the second consensus node; the first candidate node obtains the second temporary public key and the second signature from the second consensus node, and verifies that the second signature passes; obtains the first encrypted information from the second consensus node, decrypts the first encrypted information with the shared key to obtain the first random value; encrypts the second random value with the shared key to obtain second encrypted information, and sends the second encrypted information to the second consensus node.

[0110] Optionally, the processing module 302 is further used to: if the first consensus node is first determined to be faulty among the multiple alternative nodes, after determining that the first consensus node is faulty, send a backup declaration message to each of the second alternative nodes; the backup declaration message is used to declare that the first alternative node is an alternative node for backing up the first consensus node; the processing module 302 is further used to: send a successful backup message to each of the second alternative nodes; the successful backup message is used to declare that the first alternative node has successfully backed up the first consensus node.

[0111] Based on the same inventive concept, an embodiment of the present invention further provides a computer device, including a program or instruction. When the program or instruction is executed, the consensus node fault tolerance method in the blockchain provided by the embodiment of the present invention and any optional method are executed.

[0112] Based on the same inventive concept, an embodiment of the present invention further provides a computer-readable storage medium, including a program or instructions. When the program or instructions are executed, the consensus node fault tolerance method in the blockchain provided by the embodiment of the present invention and any optional method are executed.

[0113] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0114] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0115] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0116] Obviously, those skilled in the art may make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if such changes and modifications fall within the scope of the claims and their equivalents, the present invention is intended to include such changes and modifications.

Claims

1. A consensus node fault tolerance method in a blockchain, characterized in that: include: The first candidate node detects whether there is a faulty consensus node among multiple consensus nodes in the blockchain; The first candidate node is any candidate node among multiple candidate nodes outside the blockchain; the multiple candidate nodes include the first candidate node and each second candidate node; the multiple candidate nodes are used to back up a failed consensus node among the multiple consensus nodes; If the first candidate node first determines that the first consensus node is faulty among the multiple candidate nodes, the first candidate node is used as the first consensus node; the multiple consensus nodes include the first consensus node and each second consensus node; The first candidate node first determines that the first consensus node is faulty among the multiple candidate nodes, including: each candidate node sends a fault indication message carrying a timestamp after determining that the first consensus node is faulty, and the timestamp carried in the fault indication message sent by the first candidate node is the earliest; and / or, the first candidate node does not receive any fault indication message from any other second candidate node before determining that the first consensus node is faulty; If the first candidate node first determines that the first consensus node is faulty among the multiple candidate nodes, the first candidate node sends a backup declaration message to each of the second candidate nodes after determining that the first consensus node is faulty; the backup declaration message is used to declare that the first candidate node is a candidate node to back up the first consensus node; After the first candidate node uses the first candidate node as the first consensus node, the method further includes: the first candidate node sending a successful backup message to each of the second candidate nodes; the successful backup message is used to declare that the first candidate node has successfully backed up the first consensus node.

2. The method according to claim 1, wherein The first candidate node determines that the first consensus node is faulty in the following manner: If the first candidate node determines that the heartbeat test with the first consensus node has timed out, the first candidate node determines suspected fault information of the first consensus node, and counts the total number of pieces of suspected fault information of the first consensus node; The suspected fault information of the first consensus node includes: the suspected fault information determined by the first candidate node and the suspected fault information from each of the second candidate nodes; If, within a preset time period, the first candidate node determines that the total number of the information is greater than a preset threshold, it is determined that the first consensus node is faulty.

3. The method according to claim 2, wherein The preset duration is positively correlated with the total number of the plurality of consensus nodes; the preset threshold is determined based on the total number of the plurality of consensus nodes and a preset ratio.

4. The method according to any one of claims 1 to 3, wherein The using the first candidate node as the first consensus node includes: For any second consensus node among the second consensus nodes, the first candidate node sends the first identity certificate to the second consensus node, and obtains the second identity certificate from the second consensus node; The first candidate node sends the first master public key and the first random value to the second consensus node, and obtains the second master public key and the second random value from the second consensus node; The first candidate node generates a first temporary private key and a first temporary public key based on the first master public key, the first random value, the second master public key, and the second random value according to an elliptic curve algorithm, and signs the first temporary public key with the first temporary private key to obtain a first signature; The first candidate node sends the first temporary public key and the first signature to the second consensus node; the first candidate node obtains the second temporary public key and the second signature from the second consensus node, and verifies that the second signature passes; The first candidate node obtains the first encrypted information from the second consensus node, decrypts the first encrypted information using a shared key, and obtains the first random value; the first candidate node encrypts the second random value using the shared key, obtains the second encrypted information, and sends the second encrypted information to the second consensus node.

5. A consensus node fault-tolerant system in a blockchain, characterized in that: include: Multiple candidate nodes and multiple consensus nodes; The multiple candidate nodes are used to back up failed consensus nodes among the multiple consensus nodes; A first candidate node is used to detect whether there is a faulty consensus node among the multiple consensus nodes; The first candidate node is any candidate node among multiple candidate nodes; the multiple candidate nodes include the first candidate node and each second candidate node; The first candidate node is configured to use the first candidate node as the first consensus node if the first consensus node is first determined to be faulty among the multiple candidate nodes; the multiple consensus nodes include the first consensus node and each second consensus node; The first candidate node is further configured to first determine, among the multiple candidate nodes, that the first consensus node is faulty, including: after determining that the first consensus node is faulty, each candidate node sends a fault indication message carrying a timestamp, the timestamp carried in the fault indication message sent by the first candidate node being the earliest; and / or, before determining that the first consensus node is faulty, the first candidate node does not receive any fault indication message from any other second candidate node; The first candidate node is further configured to, if it is determined that the first consensus node is faulty among the multiple candidate nodes, send a backup declaration message to each of the second candidate nodes after determining that the first consensus node is faulty; the backup declaration message is used to declare the first candidate node as a candidate node to back up the first consensus node; The first candidate node is further configured to send a successful backup message to each of the second candidate nodes after the first candidate node is used as the first consensus node; the successful backup message is used to declare that the first candidate node has successfully backed up the first consensus node.

6. The system according to claim 5, wherein: The first candidate node is further configured to: For any second consensus node among the second consensus nodes, a heartbeat test is maintained between the first candidate node and the second consensus node; For any second candidate node among the second candidate nodes, a heartbeat test is maintained between the first candidate node and the second candidate node.

7. A consensus node fault-tolerant device in a blockchain, characterized in that: include: A detection module, used to detect whether there is a faulty consensus node among multiple consensus nodes in the blockchain; The first candidate node is any candidate node among multiple candidate nodes outside the blockchain; the multiple candidate nodes include the first candidate node and each second candidate node; the multiple candidate nodes are used to back up a failed consensus node among the multiple consensus nodes; a processing module, configured to use the first candidate node as the first consensus node if the first candidate node first determines that the first consensus node is faulty among the multiple candidate nodes; the multiple consensus nodes include the first consensus node and each second consensus node; wherein the first candidate node first determines that the first consensus node is faulty among the multiple candidate nodes, including: each candidate node sending a fault indication message carrying a timestamp after determining that the first consensus node is faulty, the timestamp carried in the fault indication message sent by the first candidate node being the earliest; and / or, the first candidate node not receiving any fault indication message from any other second candidate node before determining that the first consensus node is faulty; The processing module is further configured to, if the first candidate node first determines that the first consensus node is faulty among the multiple candidate nodes, send a backup declaration message to each of the second candidate nodes after the first candidate node determines that the first consensus node is faulty; the backup declaration message is used to declare the first candidate node as a candidate node to back up the first consensus node; The processing module is further configured to, after the first candidate node uses the first candidate node as the first consensus node, send a successful backup message to each of the second candidate nodes; the successful backup message is used to declare that the first candidate node has successfully backed up the first consensus node.

8. A computer device, characterized in that: The method comprises a program or an instruction, and when the program or the instruction is executed, the method according to any one of claims 1 to 4 is performed.

9. A computer-readable storage medium, characterized in that The method comprises a program or an instruction, and when the program or the instruction is executed, the method according to any one of claims 1 to 4 is performed.

Images