Consensus in blockchain system

Abstract

A method for downtime detection in a blockchain system, comprising: determining whether no consensus proposal initiated by a master node has been received within a preset timeout duration; if no consensus proposal initiated by the master node has been received within the preset timeout duration, broadcasting a timeout message to other slave nodes, and collecting timeout messages broadcast by other slave nodes; in response to collecting Quorum timeout messages, generating, on the basis of the collected Quorum timeout messages, a proof for indicating that the master node has undergone downtime; and broadcasting the proof to other slave nodes, so that other slave nodes perform validity verification on the proof, and once the proof has passed the validity verification, removing the master node from a list of consensus nodes participating in consensus, and on the basis of consensus nodes in the list of consensus nodes from which the master node has been removed, continuing to perform consensus processing.

Description

Consensus in blockchain systems Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a consensus method and apparatus in a blockchain system. Background Technology

[0002] In a blockchain system, different participants can establish a distributed blockchain network through deployed nodes. A decentralized (or multi-centralized) distributed ledger, constructed using a chain-like block structure, is stored on each node (or most nodes, such as consensus nodes) in the distributed blockchain network. Such a blockchain system needs to address the consistency and correctness of the ledger data across multiple decentralized (or multi-centralized) nodes. Each node runs a blockchain program, and under a certain fault-tolerance design, a consensus mechanism ensures that all loyal nodes have the same transactions, thereby guaranteeing consistent execution results for the same transactions across all loyal nodes. The transactions and execution results are then packaged into blocks.

[0003] Current mainstream consensus protocols include: POW (Proof of Work), POS (Proof of Stake), DPOS (Delegated Proof of Stake), PBFT (Practical Byzantine Fault Tolerance), HoneyBadgerBFT (HoneyBadger Byzantine Fault Tolerance), HotStuff, and others.

[0004] Among these consensus protocols, there is a type of consensus protocol driven by a master node. For this type of consensus protocol, there is usually only one master node in each round of consensus, and the master node initiates the consensus proposal. For example, the PBFT protocol and the HotStuff protocol are this type of consensus protocol driven by a master node.

[0005] However, in practical applications, these master node-driven consensus protocols usually ignore the situation where consensus nodes participating in the consensus process go down. Once a consensus node (especially the master node) goes down, it may disrupt the activity of the consensus network, causing the system to freeze and become unresponsive for a long time. Summary of the Invention

[0006] This specification proposes a consensus method in a blockchain system, wherein the consensus nodes participating in the consensus in the blockchain system include an elected master node and several slave nodes. The method is applied to any slave node in the blockchain system and includes: determining whether a consensus proposal initiated by the master node has not been received within a preset timeout period; if no consensus proposal initiated by the master node has been received within the preset timeout period, broadcasting a timeout message to other slave nodes and collecting the timeout messages broadcast by the other slave nodes; wherein the timeout message contains the node identifier of the master node; in response to the collection of a quorum of timeout messages, generating a proof indicating that the master node has crashed based on the collected quorum of timeout messages; broadcasting the proof to other slave nodes for the other slave nodes to verify the validity of the proof, and after the proof passes the validity verification, removing the master node from the consensus node list participating in the consensus, and continuing consensus processing based on the consensus nodes in the consensus node list after the master node has been removed.

[0007] Optionally, the timeout message includes a digital signature of the slave node that sent the timeout message; in response to the collection of a Quorum number of the timeout messages, before generating a proof indicating that the master node has encountered an anomaly based on the collected Quorum number of the timeout messages, the method further includes: verifying the digital signature contained in the received timeout message; if the digital signature contained in the received timeout message passes the verification, further verifying whether the message content contained in the timeout message is the same as the message content contained in other received timeout messages; if the message content contained in the timeout message is the same as the message content contained in other received timeout messages, then the timeout message is saved as a valid timeout message.

[0008] Optionally, in response to the collection of Quorum timeout messages, a proof indicating that the master node has encountered an anomaly is generated based on the collected Quorum timeout messages, including: in response to the collection of Quorum valid timeout messages, a proof indicating that the master node has crashed is generated based on the collected Quorum valid timeout messages.

[0009] Optionally, the message content of the timeout message includes a type identifier indicating that the message is a timeout message, the node identifier of the master node, and a proposal identifier indicating that the master node has not proposed a consensus proposal.

[0010] Optionally, the method further includes: receiving a proof broadcast by other slave nodes indicating that the master node has crashed; verifying the validity of the proof; and after the proof has passed the validity verification, removing the master node from the consensus node list participating in the consensus, and continuing consensus processing based on the consensus nodes in the consensus node list after the master node has been removed.

[0011] Optionally, broadcasting the proof to other slave nodes includes: broadcasting the proof to other slave nodes based on an operating reliable broadcast protocol; receiving proofs broadcast by other slave nodes includes: receiving proofs broadcast by other slave nodes based on an operating reliable broadcast protocol.

[0012] Optionally, removing the master node from the consensus node list includes: removing the master node from the locally maintained consensus node list.

[0013] Optionally, the proof is a set of digital signatures composed of the digital signatures contained in the collected Quorum timeout messages; generating proof indicating that the master node has an anomaly based on the collected Quorum timeout messages includes: creating a set of digital signatures based on the digital signatures contained in the collected Quorum timeout messages as proof indicating that the master node has an anomaly; validating the proof includes: verifying the digital signatures contained in the set of digital signatures; if at least Quorum digital signatures contained in the set of digital signatures pass the verification, the proof is determined to have passed the validity verification.

[0014] Optionally, each slave node in the blockchain system holds a private key fragment obtained by splitting the master private key; the digital signature contained in the timeout message is a partial signature obtained by each slave node signing the timeout message based on the private key fragment it holds; the proof is a threshold signature generated by aggregating the partial signatures contained in the collected Quorum timeout messages; generating a proof to indicate that the master node has an anomaly based on the collected Quorum timeout messages includes: aggregating the partial signatures contained in the collected Quorum timeout messages to generate a threshold signature as proof to indicate that the master node has an anomaly; validating the proof includes: verifying the threshold signature based on the master public key corresponding to the master private key; if the threshold signature verification passes, the proof is determined to have passed the validity verification.

[0015] Optionally, consensus processing can continue based on consensus nodes in the consensus node list that have had the master node removed, including: re-determining a new master node from the consensus node list that has had the master node removed, and interacting with the other consensus nodes in the consensus node list to continue processing consensus proposals initiated by the new master node.

[0016] Optionally, determining a new master node from the consensus node list where the master node has been removed includes: executing a user-defined master node determination rule for the blockchain system to determine a new master node from the consensus node list where the master node has been removed.

[0017] Optionally, a new master node is determined from the list of consensus nodes from which the master node has been removed, including: re-determining any target consensus node specified by the user from the list of consensus nodes from which the master node has been removed as the new master node for this round of consensus, so as to replace the master node that has crashed with the new master node.

[0018] Optionally, the consensus protocol running on the consensus nodes in the blockchain system supports the determination of a new master node by other consensus nodes besides the master node through explicit message interaction after the master node fails. Determining a new master node from the list of consensus nodes that have removed the master node includes: engaging in the message interaction with other consensus nodes in the list of consensus nodes that have removed the master node to re-elect a new master node from the list of consensus nodes that have removed the master node.

[0019] Optionally, the consensus protocol run by the consensus nodes in the blockchain system is the PBFT protocol; determining whether a consensus proposal initiated by the master node has not been received within a preset timeout period includes: determining whether a Pre-Prepare message contained in the PBFT protocol broadcast by the master node has not been received within the preset timeout period; re-determining a new master node from the consensus node list that has removed the master node includes: triggering the PBFT protocol's view change process, interacting with other consensus nodes in the consensus node list that has removed the master node using View-Change and New-View messages, so as to re-elect a new master node from the consensus node list that has removed the master node.

[0020] Optionally, the consensus protocol running on the consensus nodes in the blockchain system supports implicitly executing a unified master node determination rule on other consensus nodes besides the master node after the master node crashes, in order to re-determine a new master node; re-determining a new master node from the list of consensus nodes from which the master node was removed includes: executing the unified master node determination rule to re-determine a new master node from the list of consensus nodes from which the master node was removed.

[0021] Optionally, the consensus protocol run by the consensus nodes in the blockchain system is the HotStuff protocol; determining whether a consensus proposal initiated by the master node has not been received within a preset timeout period includes: determining whether a prepare message contained in the HotStuff protocol has not been broadcast by the master node within the preset timeout period.

[0022] Determining a new master node from the consensus node list that has removed the master node includes: triggering an execution view switch to switch the current consensus to a new consensus, and executing the unified master node determination rule to determine a new master node for the new consensus from the consensus node list that has removed the master node.

[0023] This specification also proposes a consensus method in a blockchain system, wherein the consensus nodes participating in the consensus include an elected master node and several slave nodes; a smart contract for anomaly management of the master node is deployed on the blockchain; the smart contract maintains a list of consensus nodes participating in the consensus; the method is applied to any slave node in the blockchain system, and the method includes: determining whether a consensus proposal initiated by the master node has not been received within a preset timeout period; if no consensus proposal initiated by the master node has been received within the preset timeout period, broadcasting a timeout message to other slave nodes, and collecting information from the other slave nodes. The node broadcasts the timeout message; wherein the timeout message contains the node identifier of the master node; in response to the collection of a quorum of the timeout messages, a proof indicating that the master node has crashed is generated based on the collected quorum of the timeout messages, and the exception handling logic contained in the smart contract is invoked based on the generated proof to verify the validity of the proof, and after the proof passes the validity verification, the master node is removed from the consensus node list maintained by the smart contract; consensus processing continues based on the consensus nodes in the consensus node list after the master node has been removed.

[0024] Optionally, the smart contract is a system smart contract deployed in the blockchain by the operator of the blockchain service platform corresponding to the blockchain system; wherein, the system smart contract supports implicit invocation based on instructions; invoking the exception handling logic contained in the smart contract based on the generated proof includes: constructing a call instruction for the system smart contract based on the generated proof; implicitly initiating a contract call for the system smart contract based on the call instruction to execute the exception handling logic contained in the system smart contract.

[0025] Optionally, the smart contract is a general smart contract that supports explicit calls based on transactions; calling the exception handling logic contained in the smart contract based on the generated proof includes: constructing a contract call transaction for the smart contract based on the generated proof; adding the contract call transaction to a target block that has passed consensus and to be executed, and executing the contract call transaction contained in the target block to initiate a contract call for the smart contract to execute the exception handling logic contained in the smart contract.

[0026] Optionally, consensus processing can continue based on consensus nodes in the consensus node list that have had the master node removed, including: re-determining a new master node from the consensus node list that has had the master node removed, and interacting with the other consensus nodes in the consensus node list to continue processing consensus proposals initiated by the new master node.

[0027] Optionally, determining a new master node from the consensus node list where the master node has been removed includes: executing a user-defined master node determination rule for the blockchain system to determine a new master node from the consensus node list where the master node has been removed.

[0028] Optionally, a new master node is determined from the list of consensus nodes from which the master node has been removed, including: re-determining any target consensus node specified by the user from the list of consensus nodes from which the master node has been removed as the new master node for this round of consensus, so as to replace the master node that has crashed with the new master node.

[0029] Optionally, the consensus protocol running on the consensus nodes in the blockchain system supports the determination of a new master node by other consensus nodes besides the master node through explicit message interaction after the master node fails. Determining a new master node from the list of consensus nodes that have removed the master node includes: engaging in the message interaction with other consensus nodes in the list of consensus nodes that have removed the master node to re-elect a new master node from the list of consensus nodes that have removed the master node.

[0030] Optionally, the consensus protocol run by the consensus nodes in the blockchain system is the PBFT protocol; determining whether a consensus proposal initiated by the master node has not been received within a preset timeout period includes: determining whether a Pre-Prepare message contained in the PBFT protocol broadcast by the master node has not been received within the preset timeout period; re-determining a new master node from the consensus node list that has removed the master node includes: triggering the PBFT protocol's view change process, interacting with other consensus nodes in the consensus node list that has removed the master node using View-Change and New-View messages, so as to re-elect a new master node from the consensus node list that has removed the master node.

[0031] Optionally, the consensus protocol running on the consensus nodes in the blockchain system supports implicitly executing a unified master node determination rule on other consensus nodes besides the master node after the master node crashes, in order to re-determine a new master node; re-determining a new master node from the list of consensus nodes from which the master node was removed includes: executing the unified master node determination rule to re-determine a new master node from the list of consensus nodes from which the master node was removed.

[0032] Optionally, the consensus protocol run by the consensus nodes in the blockchain system is the HotStuff protocol; determining whether a consensus proposal initiated by the master node has not been received within a preset timeout period includes: determining whether a prepare message contained in the HotStuff protocol has not been broadcast by the master node within the preset timeout period; re-determining a new master node from the consensus node list that has removed the master node includes: triggering a view switch to execute the HotStuff protocol, switching the current consensus to a new consensus, and executing the unified master node determination rule to re-determine a new master node for the new consensus from the consensus node list that has removed the master node.

[0033] This specification also proposes a consensus device in a blockchain system, wherein the consensus nodes participating in the consensus in the blockchain system include an elected master node and several slave nodes; the device is applied to any slave node in the blockchain system, and the device includes: a determining module, which determines whether a consensus proposal initiated by the master node has not been received within a preset timeout period; a first sending module, which, if no consensus proposal initiated by the master node has been received within the preset timeout period, broadcasts a timeout message to other slave nodes and collects the timeout messages broadcast by the other slave nodes; wherein the timeout message contains the node identifier of the master node; a generating module, which, in response to the collection of a quorum of timeout messages, generates a proof indicating that the master node has crashed based on the collected quorum of timeout messages; and a second sending module, which broadcasts the proof to other slave nodes so that the other consensus nodes can verify the validity of the proof, and after the proof passes the validity verification, removes the master node from the consensus node list participating in the consensus, and continues consensus processing based on the consensus nodes in the consensus node list after the master node has been removed.

[0034] This specification also proposes a consensus device in a blockchain system, wherein the consensus nodes participating in the consensus include an elected master node and several slave nodes; a smart contract for anomaly management of the master node is deployed on the blockchain; the smart contract maintains a list of consensus nodes participating in the consensus; the device is applied to any slave node in the blockchain system, and the device includes: a second determining module, which determines whether a consensus proposal initiated by the master node has not been received within a preset timeout period; and a third sending module, which, if no consensus proposal initiated by the master node has been received within the preset timeout period, broadcasts a timeout message to other slave nodes and collects information from the other slave nodes. The timeout message broadcast by the node; wherein the timeout message contains the node identifier of the master node; the second generation module, in response to collecting a quorum of the timeout messages, generates a proof indicating that the master node has crashed based on the collected quorum of the timeout messages, and calls the exception handling logic contained in the smart contract based on the generated proof to verify the validity of the proof, and removes the master node from the consensus node list maintained by the smart contract after the proof passes the validity verification; the consensus module continues to perform consensus processing based on the consensus nodes in the consensus node list after the master node has been removed.

[0035] In the above embodiments, by introducing a failure detection mechanism for the master node in the master node-driven consensus protocol, the master node can be removed from the consensus node list as a failure node in a timely manner if it fails to initiate a proposal. This can prevent the blockchain system from becoming unresponsive for a long time due to the failure of the master node, thereby improving the activity of the consensus network and ensuring the stability of the blockchain system. Attached Figure Description

[0036] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0037] Figure 1 is a flowchart illustrating a consensus method in a blockchain system according to an embodiment of this specification.

[0038] Figure 2 is a flowchart illustrating a consensus method in another blockchain system according to one embodiment of this specification.

[0039] Figure 3 is a schematic structural diagram of an electronic device shown in one embodiment of this specification.

[0040] Figure 4 is a block diagram of a consensus device in a blockchain system shown in one embodiment of this specification.

[0041] Figure 5 is a block diagram of a consensus device in another blockchain system shown in one embodiment of this specification. Detailed Implementation

[0042] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0043] The specification aims to propose a technical solution that introduces a real-time failure detection mechanism for master nodes in a master node-driven consensus protocol, thereby improving the activity of the consensus network and ensuring the stability of the blockchain system.

[0044] Please refer to Figure 1, which is a flowchart of a downtime detection method in a blockchain system as shown in this specification. The consensus nodes participating in the consensus in the blockchain system include an elected master node and several slave nodes. The method is applied to any slave node in the blockchain system, and the method includes the following execution process.

[0045] Step 102: Determine whether a consensus proposal initiated by the master node has not been received within the preset timeout period.

[0046] The consensus protocol run by the consensus nodes participating in the consensus process in the aforementioned blockchain system can specifically include a master node-driven consensus protocol. Based on this type of consensus protocol, the consensus nodes participating in the consensus process in the blockchain system typically include an elected master node and several slave nodes.

[0047] For example, in some cases, the master-node-driven consensus protocols mentioned above can specifically include the PBFT protocol and the HotStuff protocol. Of course, in practical applications, the master-node-driven consensus protocols mentioned above can also be other types of consensus protocols besides the PBFT and HotStuff protocols that support the election of a master node and several slave nodes in a single consensus round, and this specification does not impose any special limitations.

[0048] In a master-node driven consensus protocol, the master node is responsible for initiating a consensus proposal and broadcasting it to all participating slave nodes in the blockchain system. The slave nodes then receive the consensus proposal broadcast by the master node and interact with other slave nodes to process the received proposal.

[0049] In master node-driven consensus protocols, since the master node is usually the core of each round of consensus, once the master node goes down, it will usually disrupt the activity of the consensus network, causing the system to freeze and become unresponsive for a long time.

[0050] Based on this, a real-time failure detection mechanism for the master node can be introduced on each slave node in a master node-driven consensus protocol. This allows a slave node participating in the consensus process to determine whether the waiting time for a consensus proposal broadcast by the master node has reached a preset timeout if it hasn't received one after a prolonged period. This preset timeout can be a custom threshold, and its specific value can be flexibly set based on actual needs.

[0051] It should be noted that the specific methods by which the master node initiates consensus proposals to each slave node often differ for different master node-driven consensus protocols. For example, the message types and formats used when broadcasting consensus proposals usually differ significantly for different master node-driven consensus protocols. Therefore, the confirmation methods used by slave nodes to confirm whether the master node has crashed may also differ.

[0052] For example, in one embodiment shown, taking the PBFT consensus protocol as an example, based on the master node-driven consensus protocol, in a round of consensus, the messages exchanged between the master node and slave nodes typically include Pre-Prepare messages, Pre-Prepare and Commit messages, etc. The Pre-Prepare message is used to initiate a consensus proposal. The master node can carry the initiated consensus protocol in the Pre-Prepare message and broadcast it to each slave node. In this case, during the process of receiving the consensus proposal broadcast by the master node, each slave node can determine whether the master node has crashed by checking whether it has not received the Pre-Prepare message broadcast by the master node within a preset timeout period.

[0053] In one implementation shown, taking the HotStuff protocol, a master-node driven consensus protocol, as an example, in a consensus round based on the HotStuff protocol, the messages exchanged between the master node and slave nodes typically include prepare messages, prepare-vote messages, pre-commit messages, pre-commit-vote messages, commit messages, commit-vote messages, etc. Among these, the prepare message is used to initiate a consensus proposal. The master node can carry the initiated consensus protocol in the Prepare message and broadcast it to each slave node. In this case, during the process of receiving the consensus proposal broadcast by the master node, each slave node can determine whether the master node has crashed by checking whether it has not received the Prepare message broadcast by the master node within a preset timeout period. Step 104: If no consensus proposal initiated by the master node is received within the preset timeout period, a timeout message is broadcast to other slave nodes, and the timeout messages broadcast by the other slave nodes are collected; wherein, the timeout message contains the node identifier of the master node; if any slave node participating in the consensus in the blockchain system determines in a consensus round that it has not received a consensus proposal initiated by the master node within the preset timeout period, it can be confirmed that the master node may have crashed. At this time, a timeout message can be further broadcast to other consensus nodes participating in the consensus in the blockchain system. Specifically, the timeout message is used to confirm the event of the master node crashing, and the timeout message may specifically contain the node identifier of the crashed master node.

[0054] It should be noted that the message format of the above timeout message is not specifically limited in this specification, and can be flexibly defined based on requirements in actual applications.

[0055] For example, in one embodiment shown, the message format of the timeout message can be represented as follows:<TIMEOUT,ID,seq> Here, TIMEOUT is a type identifier indicating that the message is a timeout message; ID represents the node identifier of the master node that crashed; and seq represents the proposal identifier of the consensus proposal that the crashed master node did not propose.

[0056] It's important to clarify that a consensus proposal not initiated by the master node is typically one that the master node should have initiated in the current consensus round. For example, assuming the current consensus round is for the Nth block, the master node, assuming no downtime, should typically broadcast block N, created based on the collected transactions, as a consensus proposal to all slave nodes. In this case, the consensus proposal that the master node should have initiated in this round is block N. Correspondingly, the proposal identifier for this uninitiated consensus proposal is the block identifier for block N.

[0057] It should be emphasized that the message content included in the message format of the timeout message, in addition to the type identifier indicating that the message is a timeout message, the node identifier of the master node, and the proposal identifier of the consensus proposal that the master node has not proposed, can be flexibly extended according to specific needs in practical applications, and will not be listed one by one in this specification.

[0058] In a blockchain system, in addition to broadcasting a timeout message to other consensus nodes participating in the consensus process after confirming that the master node has crashed, slave nodes can also collect timeout messages broadcast by other slave nodes and verify the validity of the collected timeout messages in practical applications.

[0059] In one embodiment shown, the timeout message may specifically include the digital signature of the slave node that sent the timeout message; for example, in one example, the message format of the timeout message may specifically represent Where σ i This represents the digital signature of the slave node that sent the timeout message.

[0060] In a blockchain system, after receiving a timeout message broadcast by other slave nodes, a slave node can, on the one hand, verify the digital signature contained in the received timeout message; if the verification fails, the timeout message can be discarded as invalid. On the other hand, if the digital signature verification passes, the node can further verify whether the message content of the received timeout message is the same as the message content of other received timeout messages; for example, verifying whether the message format of the received timeout messages is consistent with other received timeout messages.<TIMEOUT,ID,seq> If the message content of the timeout message is the same as that of other received timeout messages, it can be saved as a valid timeout message. Otherwise, it can be discarded as an invalid timeout message.

[0061] Step 106: In response to the collection of Quorum timeout messages, generate a proof indicating that the master node has crashed based on the collected Quorum timeout messages.

[0062] After collecting a Quorum number of timeout messages, any slave node in the blockchain system can generate a proof indicating that the aforementioned master node has crashed based on the collected Quorum number of timeout messages.

[0063] For example, in one embodiment shown, any slave node in the blockchain system can generate a proof indicating that the master node has crashed based on the collected Quorum valid timeout messages after collecting Quorum valid timeout messages.

[0064] It's important to note that Quorum typically refers to a threshold number of consensus nodes that represent a majority in a blockchain. For example, if the number of consensus nodes (n) participating in the consensus is 3f+1, the Quorum value is nf, or 2f+1. Thus, for a distributed system with 4 nodes, any 3 nodes can constitute a Quorum. f refers to the number of Byzantine nodes (i.e., malicious nodes) that the blockchain can tolerate.

[0065] In one embodiment shown, the proof generated by any slave node in the blockchain system based on a collection of quorum timeout messages can specifically be a set of digital signatures composed of the digital signatures contained in the quorum timeout messages. In this case, when generating the proof based on the quorum timeout messages, any slave node in the blockchain system can create a set of digital signatures based on the digital signatures contained in the quorum timeout messages, as proof indicating that the master node has encountered an anomaly.

[0066] Of course, in practical applications, the proof generated by any slave node in the blockchain system based on the collected Quorum timeout messages can also be a message set composed of the collected Quorum timeout messages, which is not specifically limited in this specification.

[0067] In one embodiment shown, threshold signature technology can also be used to generate proofs. Based on threshold signature technology, each slave node in the blockchain system can hold a private key fragment obtained by dividing the master private key; the digital signature contained in the timeout message can be a partial signature obtained by each slave node signing the timeout message based on its held private key fragment. The proof generated by any slave node in the blockchain system based on the collected Quorum timeout messages can specifically be a threshold signature generated by aggregating the partial signatures contained in the collected Quorum timeout messages.

[0068] For example, in practical applications, a master private key and a corresponding master public key can be generated in advance using a certain encryption algorithm (such as the Elliptic Curve Cryptography ECC algorithm). Based on the number of slave nodes in the blockchain system, a threshold value, Quorum, representing the majority of slave nodes in the blockchain can be calculated. Then, Quorum is set as the threshold value for generating aggregate signatures.

[0069] Then, the master private key can be divided into n private key fragments according to the number n slave nodes in the blockchain system, and these n private key fragments can be distributed to the n slave nodes respectively. When splitting the master private key, a secret-sharing-based algorithm (such as the Shamir secret-sharing algorithm) can be used to ensure that the master private key can only be recovered when at least Quorum private key fragments are combined.

[0070] When signing a timeout message, each slave node in the blockchain system can use the private key fragment it holds to sign the timeout message. At this time, the digital signature contained in each timeout message is a partial signature obtained by each slave node based on the private key fragment it holds to sign the timeout message.

[0071] In this scenario, when any slave node in the blockchain system generates the proof based on the collected Quorum timeout messages, it can aggregate the local signatures contained in the collected Quorum timeout messages to generate a threshold signature, which serves as proof indicating that the master node has encountered an anomaly.

[0072] Step 108: Broadcast the proof to other slave nodes so that the other slave nodes can verify the validity of the proof. After the proof passes the validity verification, remove the master node from the consensus node list and continue consensus processing based on the consensus nodes in the consensus node list that have removed the master node.

[0073] In a blockchain system, any slave node, after generating a proof indicating that the master node has crashed based on the collected Quorum timeout messages, can broadcast the proof to other slave nodes and receive other slave nodes broadcasting proofs indicating that the master node has crashed.

[0074] Furthermore, after receiving proof from other slave nodes broadcasting an indication that the master node has crashed, the validity of that proof can be verified.

[0075] For example, in one embodiment shown, if the proof is based on a set of digital signatures consisting of the digital signatures contained in the collected Quorum timeout messages, then each of the digital signatures contained in the set can be verified individually; if at least the Quorum digital signatures contained in the set pass the verification, then the proof can be determined to have passed the validity verification.

[0076] In another implementation shown, if the proof is a threshold signature generated by aggregating the local signatures contained in the collected Quorum timeout messages, then the threshold signature can be verified based on the master public key corresponding to the aforementioned master private key. If the threshold signature verification passes, the proof is considered valid. If the proof passes validity verification, it is no longer necessary to wait for the master node to initiate a consensus proposal. Instead, the failed master node can be removed from the consensus node list, and consensus processing can continue based on the consensus nodes in the list after the master node has been removed.

[0077] In this way, it can be ensured that all honest slave nodes in the blockchain system can successfully receive the proofs broadcast by other slave nodes.

[0078] In another implementation shown, if each slave node in the blockchain system broadcasts the generated proof to other slave nodes by running the RBC protocol, and receives broadcasts from other slave nodes by running the RBC protocol, then each slave node in the blockchain system can also maintain a list of consensus nodes participating in the consensus locally.

[0079] In this way, once any slave node receives a proof broadcast by another slave node and verifies the proof, it can directly operate on the locally maintained list of consensus nodes participating in the consensus, and promptly remove the master node from the locally maintained list of consensus nodes.

[0080] For example, the consensus node list mentioned above can specifically be a list of node identifiers of consensus nodes participating in the consensus process, and a slave node can remove the master node's node identifier from this list of node identifiers.

[0081] It should be noted that the specific implementation details of how each slave node in the blockchain system broadcasts the generated proof to other slave nodes by running the RBC protocol, and how it receives broadcasts from other slave nodes through the running RBC protocol, will not be detailed in this specification. Those skilled in the art can refer to the records in relevant technologies.

[0082] Once each slave node in the blockchain system removes the failed master node from its locally maintained list of consensus nodes participating in consensus, each slave node can continue consensus processing based on the consensus nodes in the list of consensus nodes that have removed the master node.

[0083] In this way, the blockchain system can avoid prolonged periods of unresponsiveness due to master node downtime, thereby improving the activity of the consensus network and ensuring the stability of the blockchain system.

[0084] In one embodiment shown, after each slave node in the blockchain system removes the failed master node from its locally maintained list of consensus nodes participating in consensus, each slave node can re-determine a new master node from the list of consensus nodes from which the master node was removed, and then interact with the other consensus nodes in the list to continue processing the consensus proposal initiated by the new master node.

[0085] It should be noted that the specific strategy adopted by each slave node to re-determine a new master node from the consensus node list that removed the master node can be flexibly customized by the user based on specific needs in actual applications, and is not specifically limited in this specification.

[0086] In one implementation, a user can define a unified master node determination rule for the blockchain system. In this case, when each slave node in the blockchain system determines a new master node from the list of consensus nodes that have removed the aforementioned master node, it can execute the unified master node determination rule defined by the user for the blockchain system to determine a new master node from the list of consensus nodes that have removed the aforementioned master node.

[0087] For example, in one instance, the aforementioned master node determination rule could specifically include allowing the user to re-designate a new master node from the consensus node list. In this case, the user can designate any target consensus node from the consensus node list that has removed the aforementioned master node as the new master node for this round of consensus based on specific needs. When each slave node re-determines a new master node from the consensus node list that has removed the aforementioned master node, it can obtain the target consensus node designated by the user from that consensus node list, then re-determine that target consensus node as the new master node for this round of consensus, and replace the master node that has crashed with the new master node.

[0088] In this way, after a consensus master node fails, the failed master node can be promptly replaced by a new master node designated by the user, thus avoiding a prolonged period of unresponsiveness in the blockchain system due to master node failure.

[0089] It is important to emphasize that, since most consensus protocols inherently support the re-determination of a new master node after a master node failure, in practical applications, the aforementioned master node failure detection mechanisms can be combined with the consensus protocol's mechanism for re-determinating a new master node after a failure to achieve compatibility with most consensus protocols. Currently, most consensus protocols support two main mechanisms for re-determinating a new master node after a failure: explicit message interaction and implicit execution of a unified master node determination rule.

[0090] It is important to clarify that re-determining a new master node through explicit message interaction means that each slave node re-determines a new master node by sending messages to each other; while re-determining a new master node by implicitly executing a unified master node determination rule means that each slave node does not need to send messages to each other when re-determining a new master node, but instead executes the unified master node determination rule locally to re-determine a new master node.

[0091] In one embodiment shown, if the consensus protocol running by the consensus nodes in the blockchain system supports the determination of a new master node by other consensus nodes besides the master node through explicit message interaction after the master node goes down, in this case, when each slave node determines a new master node from the list of consensus nodes that removed the master node, it can specifically interact with other consensus nodes in the list of consensus nodes that removed the master node to re-elect a new master node from the list of consensus nodes that removed the master node.

[0092] For example, taking the PBFT protocol, which runs on consensus nodes in a blockchain system, as an example, the view change mechanism supported by the PBFT protocol is a mechanism in which, after the master node fails, other consensus nodes, besides the master node, explicitly exchange messages to determine a new master node. Based on the view change mechanism, the messages exchanged between slave nodes typically include View-Change messages and New-View messages.

[0093] In this scenario, when each slave node determines a new master node from the consensus node list that has removed the aforementioned master node, it can trigger the PBFT protocol's view change process. This process involves interacting with other consensus nodes in the consensus node list that has removed the aforementioned master node using View-Change and New-View messages, in order to determine a new master node from the consensus node list that has removed the aforementioned master node.

[0094] For example, in a view change process based on the PBFT protocol, after each slave node determines that the master node has failed, it can broadcast a View-Change message to other slave nodes. When any slave node receives at least a quorum (e.g., 2f+1) of valid View-Change messages, it can calculate whether it has been elected as the new master node. If so, it can broadcast a New-View message to all other slave nodes to start a new view.

[0095] In one embodiment shown, if the consensus protocol running on the consensus nodes in the blockchain system supports implicitly executing a unified master node determination rule on other consensus nodes besides the master node after the master node goes down, in order to re-determine a new master node, then when each slave node re-determines a new master node from the list of consensus nodes from which the aforementioned master node was removed, it can specifically execute the unified master node determination rule locally to re-determine a new master node from the list of consensus nodes from which the master node was removed.

[0096] For example, taking the HotStuff protocol, which runs on consensus nodes in a blockchain system, as an example, HotStuff also supports a view switching mechanism similar to PBFT. However, unlike PBFT, HotStuff forces a view switch every time a new round of consensus is initiated. For instance, assuming the current consensus view is view1, the view will switch from view1 to view2 when a new round of consensus is initiated. Furthermore, HotStuff also supports re-determining a new master node in each view round. In addition, HotStuff simplifies the view switching process by omitting message interaction and instead using an implicit, unified master node determination rule to re-determine the new master node.

[0097] In this scenario, when each slave node re-determines a new master node from the consensus node list that has removed the aforementioned master node, it can trigger a view switch to execute the HotStuff protocol, switching the current consensus to a new consensus. Then, each slave node can execute a unified master node determination rule locally to re-determine a new master node for this new consensus from the consensus node list that has removed the aforementioned master node.

[0098] It should be noted that the specific master node determination rules used to select a new master node from the consensus node list can, in practice, be part of the consensus protocol or independent of it. Being independent of the consensus protocol means that, in practice, the master node determination rules can be flexibly customized based on actual needs, building upon the consensus protocol, and then used as a supplement to the consensus protocol, integrated with it.

[0099] For example, taking the PBFT consensus protocol as an example, the PBFT consensus protocol stipulates that the master node for each round of consensus can be determined in the following way: p = v mod |R|

[0100] In the above formula, parameter p represents the number of the master node determined for each round of consensus; parameter v represents the view number corresponding to this round of consensus; and parameter |R| represents the number of consensus nodes participating in the consensus in the blockchain system.

[0101] For example, taking the HotStuff consensus protocol as an example, the HotStuff consensus protocol does not specify a particular strategy for determining the master node in each round of consensus. That is, the rules for determining the master node in each round of consensus can exist independently of the HotStuff consensus protocol. In practical applications, users can flexibly customize the master node determination rules based on their actual needs and combine them with the HotStuff consensus protocol. For instance, in one example, the master node determination rules specified in the PBFT consensus protocol could also be used for the HotStuff consensus protocol.

[0102] It is evident that by combining the aforementioned master node failure detection mechanism with the existing rules of most consensus protocols for re-determining the master node after a failure, these consensus protocols can be further optimized, enabling them to also have the ability to perform real-time master node failure detection, thereby further improving and supplementing existing consensus protocols.

[0103] Please refer to Figure 2, which is a flowchart of a failure detection process in another blockchain system illustrated in this specification. The consensus nodes participating in the consensus process in this blockchain system include an elected master node and several slave nodes. A smart contract for managing the master node's anomalies is deployed on the blockchain. The smart contract maintains a list of consensus nodes participating in the consensus process. The method is applied to any slave node in the blockchain system, and the method includes the following execution process:

[0104] Step 202: Determine whether a consensus proposal initiated by the master node has not been received within the preset timeout period.

[0105] In this embodiment, a real-time failure detection mechanism for the master node can be introduced on each slave node in the master node-driven consensus protocol. This allows the slave nodes participating in the consensus in the blockchain system to determine whether the waiting time for not receiving the consensus proposal initiated by the master node has reached a preset timeout period if they do not receive the consensus proposal broadcast by the master node for a long time. This helps to confirm whether the master node has failed.

[0106] The preset timeout duration can be a custom threshold, and its specific value can be flexibly set based on actual needs.

[0107] For different master-node driven consensus protocols, the confirmation methods used by slave nodes to confirm whether the master node has crashed may differ.

[0108] For example, in one embodiment shown, taking the PBFT consensus protocol as an example, based on the master node-driven consensus protocol, in a round of consensus, the messages exchanged between the master node and slave nodes typically include Pre-Prepare messages, Pre-Prepare and Commit messages, etc. The Pre-Prepare message is used to initiate a consensus proposal. The master node can carry the initiated consensus protocol in the Pre-Prepare message and broadcast it to each slave node. In this case, during the process of receiving the consensus proposal broadcast by the master node, each slave node can determine whether the master node has crashed by checking whether it has not received the Pre-Prepare message broadcast by the master node within a preset timeout period.

[0109] In one implementation shown, taking the HotStuff protocol, a master-node driven consensus protocol, as an example, in a consensus round based on the HotStuff protocol, the messages exchanged between the master node and slave nodes typically include prepare messages, prepare-vote messages, pre-commit messages, pre-commit-vote messages, commit messages, commit-vote messages, etc. Among these, the prepare message is used to initiate a consensus proposal. The master node can carry the initiated consensus protocol in the Prepare message and broadcast it to each slave node. In this case, during the process of receiving the consensus proposal broadcast by the master node, each slave node can determine whether the master node has crashed by checking whether it has not received the Prepare message broadcast by the master node within a preset timeout period.

[0110] Step 204: If no consensus proposal initiated by the master node is received within the preset timeout period, a timeout message is broadcast to other slave nodes, and the timeout messages broadcast by the other slave nodes are collected; wherein, the timeout message contains the node identifier of the master node.

[0111] In a blockchain system, if any slave node participating in consensus does not receive a consensus proposal initiated by the master node within a preset timeout period during a consensus round, it can be confirmed that the master node may have crashed. In this case, a timeout message can be broadcast to the other consensus nodes participating in the blockchain system. This timeout message specifically confirms the master node crash and may include the node identifier of the crashed master node. It should be noted that the message format of the aforementioned timeout message is not specifically limited in this specification and can be flexibly defined based on requirements in practical applications.

[0112] In a blockchain system, in addition to broadcasting a timeout message to other consensus nodes participating in the consensus process after confirming that the master node has crashed, slave nodes can also collect timeout messages broadcast by other slave nodes and verify the validity of the collected timeout messages in practical applications.

[0113] The implementation details of validating timeout messages will not be repeated in this embodiment, but can be found in previous embodiments.

[0114] Step 206: In response to the collection of Quorum timeout messages, generate a proof indicating that the master node has crashed based on the collected Quorum timeout messages, and call the exception handling logic contained in the smart contract based on the generated proof to verify the validity of the proof. After the proof passes the validity verification, remove the master node from the consensus node list maintained by the smart contract.

[0115] After collecting a Quorum number of timeout messages, any slave node in the blockchain system can generate a proof indicating that the aforementioned master node has crashed based on the collected Quorum number of timeout messages.

[0116] For example, in one embodiment shown, any slave node in the blockchain system can generate a proof indicating that the master node has crashed based on the collected Quorum valid timeout messages after collecting Quorum valid timeout messages.

[0117] The implementation details of generating the above proof based on the collected Quorum timeout messages will not be repeated in this embodiment, but can be found in the previous embodiments.

[0118] In this embodiment, a smart contract for managing anomalies of the master node can be deployed on the blockchain. This smart contract can specifically maintain a list of consensus nodes participating in the consensus process; for example, in one instance, the list of consensus nodes participating in the consensus process can be stored in the state data (usually referred to as the world state) maintained by the smart contract.

[0119] After any slave node in the blockchain system generates a proof indicating that the master node has crashed based on the collected Quorum timeout messages, it no longer needs to broadcast the proof to other slave nodes. Instead, it can use the generated proof as a call parameter to invoke the exception handling logic contained in the smart contract. The smart contract will then verify the validity of the proof and remove the crashed master node from the consensus node list maintained by the smart contract after the proof passes the validity verification.

[0120] The specific implementation details for validating the proof are not repeated in this embodiment, but can be found in the previous embodiments.

[0121] In one embodiment shown, the aforementioned smart contract can specifically be a system smart contract deployed in the blockchain by the operator of the blockchain service platform corresponding to the blockchain system. It should be noted that a system smart contract typically refers to a special type of smart contract used to implement system-level functions (such as account management, access control, internal logic of consensus mechanisms, etc.). Compared to general smart contracts in the blockchain field, this type of smart contract no longer supports explicit calls based on transactions, but instead supports implicit calls based on instructions.

[0122] In this scenario, when any slave node in the blockchain system invokes the exception handling logic contained in the smart contract based on the generated proof, it can specifically construct a call instruction for the smart contract based on the generated proof, and then implicitly initiate a contract call for the smart contract based on the call instruction to execute the exception handling logic contained in the smart contract, verify the validity of the proof, and remove the master node that crashed from the consensus node list maintained by the smart contract after the proof has passed the validity verification.

[0123] It should be noted that when explicitly invoking a smart contract by sending a contract call transaction, the transaction typically needs to wait for at least one round of consensus before it can be executed normally. Therefore, this means that if a smart contract is explicitly invoked by sending a contract call transaction, at least one round of consensus is usually required to remove the downed master node from the consensus node list. Obviously, there is a problem that the downed master node cannot be removed from the consensus node list in a timely manner.

[0124] For example, assuming that the consensus in this round is for block N, the contract call transaction can only be approved and executed in the next round of consensus, that is, when consensus is reached for block N+1. This means that at least one round of consensus needs to be waited before the downtime master node can be removed from the consensus node list.

[0125] By implicitly invoking the system's smart contract through instructions, since the instructions themselves can be executed in real time without consensus processing, this method of initiating contract calls for the system's smart contract can obviously remove the downed master node from the consensus node list in a timely manner.

[0126] In another embodiment shown, the aforementioned smart contract may specifically be a general smart contract deployed on a blockchain that supports explicit calls based on transactions.

[0127] In this scenario, when any slave node in the blockchain system invokes the exception handling logic contained in the smart contract based on the generated proof, it can specifically construct a contract invocation transaction for the smart contract based on the generated proof and directly add this transaction to the target block that has passed consensus and is awaiting execution. For example, in one instance, to avoid affecting the execution of existing transactions contained in the target block, the contract invocation transaction can be added to the target block as the last transaction in that block.

[0128] Then, during the execution of the transactions contained in the target block, the slave node can execute the contract call transaction contained in the target block, initiate a contract call against the smart contract, execute the exception handling logic contained in the smart contract, verify the validity of the proof, and remove the master node that crashed from the consensus node list maintained by the smart contract after the proof has passed the validity verification.

[0129] For example, in a blockchain system, consensus for block N-1 typically begins immediately after consensus on block N-1 is reached and the execution phase of transactions within block N-1 commences. If, during the consensus process for block N, it is determined that the master node for this round of consensus has crashed, the contract call transaction for the aforementioned smart contract, constructed based on the generated proof, can be added to the block N-1 awaiting execution. This allows the crashed master node to be removed from the consensus node list before consensus on block N is completed, thus preventing the failure to remove the crashed master node in a timely manner from affecting the consensus process for block N.

[0130] Step 208: Continue consensus processing based on the consensus nodes in the consensus node list that have had the master node removed.

[0131] After the smart contract removes the crashed master node from the consensus node list maintained by the smart contract by calling the exception handling logic contained in the smart contract, each slave node in the blockchain system can continue to perform consensus processing based on the consensus nodes in the consensus node list maintained by the smart contract after the master node has been removed.

[0132] For example, in one scenario, the list of consensus nodes participating in the consensus process can be stored in the state data maintained by the smart contract. Each slave node in the blockchain system can synchronize the list of consensus nodes that have had their master node removed from the state data stored in the smart contract to its local storage, and then continue the consensus process based on the locally stored list of consensus nodes that have had their master node removed.

[0133] In one embodiment shown, when the blockchain continues consensus processing based on consensus nodes in the consensus node list that have removed the aforementioned master node, it can specifically determine a new master node from the consensus node list that has removed the master node, and then interact with the other consensus nodes in the consensus node list to continue processing the consensus proposal initiated by the new master node.

[0134] It should be noted that the specific strategy adopted by each slave node to re-determine a new master node from the consensus node list that removed the master node can be flexibly customized by the user based on specific needs in actual applications, and is not specifically limited in this specification.

[0135] In one implementation, a user can define a unified master node determination rule for the blockchain system. In this case, when each slave node in the blockchain system determines a new master node from the list of consensus nodes that have removed the aforementioned master node, it can execute the unified master node determination rule defined by the user for the blockchain system to determine a new master node from the list of consensus nodes that have removed the aforementioned master node.

[0136] For example, in one instance, the aforementioned master node determination rule could specifically include allowing the user to re-designate a new master node from the consensus node list. In this case, the user can designate any target consensus node from the consensus node list that has removed the aforementioned master node as the new master node for this round of consensus based on specific needs. When each slave node re-determines a new master node from the consensus node list that has removed the aforementioned master node, it can obtain the target consensus node designated by the user from that consensus node list, then re-determine that target consensus node as the new master node for this round of consensus, and replace the master node that has crashed with the new master node.

[0137] In this way, after a consensus master node fails, the failed master node can be promptly replaced by a new master node designated by the user, thus avoiding a prolonged period of unresponsiveness in the blockchain system due to master node failure.

[0138] It is important to emphasize that, since most consensus protocols inherently support the re-determination of a new master node after a master node failure, in practical applications, the aforementioned master node failure detection mechanisms can be combined with the consensus protocol's mechanism for re-determinating a new master node after a failure to achieve compatibility with most consensus protocols. Currently, most consensus protocols support two main mechanisms for re-determinating a new master node after a failure: explicit message interaction and implicit execution of a unified master node determination rule.

[0139] In one embodiment shown, if the consensus protocol running by the consensus nodes in the blockchain system supports the determination of a new master node by other consensus nodes besides the master node through explicit message interaction after the master node goes down, in this case, when each slave node determines a new master node from the list of consensus nodes that removed the master node, it can specifically interact with other consensus nodes in the list of consensus nodes that removed the master node to re-elect a new master node from the list of consensus nodes that removed the master node.

[0140] For example, taking the PBFT protocol, which runs on consensus nodes in a blockchain system, as an example, the view change mechanism supported by the PBFT protocol is a mechanism in which, after the master node fails, other consensus nodes, besides the master node, explicitly exchange messages to determine a new master node. Based on the view change mechanism, the messages exchanged between slave nodes typically include View-Change messages and New-View messages.

[0141] In this scenario, when each slave node determines a new master node from the consensus node list that has removed the aforementioned master node, it can trigger the PBFT protocol's view change process. This process involves interacting with other consensus nodes in the consensus node list that has removed the aforementioned master node using View-Change and New-View messages, in order to determine a new master node from the consensus node list that has removed the aforementioned master node.

[0142] For example, in a view change process based on the PBFT protocol, after each slave node determines that the master node has failed, it can broadcast a View-Change message to other slave nodes. When any slave node receives at least a quorum (e.g., 2f+1) of valid View-Change messages, it can calculate whether it has been elected as the new master node. If so, it can broadcast a New-View message to all other slave nodes to start a new view.

[0143] In one embodiment shown, if the consensus protocol running on the consensus nodes in the blockchain system supports implicitly executing a unified master node determination rule on other consensus nodes besides the master node after the master node goes down, in order to re-determine a new master node, then when each slave node re-determines a new master node from the list of consensus nodes from which the aforementioned master node was removed, it can specifically execute the unified master node determination rule locally to re-determine a new master node from the list of consensus nodes from which the master node was removed.

[0144] For example, taking the HotStuff protocol, which runs on consensus nodes in a blockchain system, as an example, HotStuff also supports a view switching mechanism similar to PBFT. However, unlike PBFT, HotStuff forces a view switch every time a new round of consensus is initiated. For instance, assuming the current consensus view is view1, the view will switch from view1 to view2 when a new round of consensus is initiated. Furthermore, HotStuff also supports re-determining a new master node in each view round. In addition, HotStuff simplifies the view switching process by omitting message interaction and instead using an implicit, unified master node determination rule to re-determine the new master node.

[0145] In this scenario, when each slave node re-determines a new master node from the consensus node list that has removed the aforementioned master node, it can trigger a view switch to execute the HotStuff protocol, switching the current consensus to a new consensus. Then, each slave node can execute a unified master node determination rule locally to re-determine a new master node for this new consensus from the consensus node list that has removed the aforementioned master node.

[0146] It should be noted that the specific master node determination rules used to determine a new master node from the consensus node list can be part of the consensus protocol or independent of it in practical applications, and will not be elaborated in this embodiment.

[0147] In the above technical solutions, by introducing a failure detection mechanism for the master node in the master node-driven consensus protocol, the master node can be removed from the consensus node list as a failure node in a timely manner if it fails to initiate a proposal. This can prevent the blockchain system from becoming unresponsive for a long time due to the failure of the master node, thereby improving the activity of the consensus network and ensuring the stability of the blockchain system.

[0148] Corresponding to the embodiments of the foregoing methods, this specification also provides embodiments of apparatus, electronic devices, and storage media.

[0149] Figure 3 is a schematic structural diagram of an electronic device provided in an exemplary embodiment. Referring to Figure 3, at the hardware level, the device includes a processor 302, an internal bus 304, a network interface 306, memory 308, and non-volatile memory 310, and may also include other necessary hardware. One or more embodiments of this specification can be implemented in software, for example, the processor 302 reads the corresponding computer program from the non-volatile memory 310 into memory 308 and then runs it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0150] As shown in Figure 4, which is a block diagram of a consensus device in a blockchain system according to an exemplary embodiment of this specification, the device can be applied to the electronic device shown in Figure 3 to implement the technical solution of this specification. The consensus nodes participating in the consensus in the blockchain system include an elected master node and several slave nodes; the device is applied to any slave node in the blockchain system; the device 400 includes: a first determining module 401, which determines whether a consensus proposal initiated by the master node has not been received within a preset timeout period; a first sending module 402, which, if no consensus proposal initiated by the master node has been received within the preset timeout period, broadcasts a timeout message to other slave nodes and collects the timeout messages broadcast by the other slave nodes; wherein the timeout message contains the node identifier of the master node; a first generating module 403, which, in response to the collection of a Quorum number of timeout messages, generates a proof indicating that the master node has crashed based on the collected Quorum number of timeout messages; and a second sending module 404, which broadcasts the proof to other slave nodes so that the other consensus nodes can verify the validity of the proof, and after the proof passes the validity verification, removes the master node from the consensus node list participating in the consensus, and continues consensus processing based on the consensus nodes in the consensus node list after the master node has been removed.

[0151] Figure 5 is a block diagram of a consensus device in a blockchain system according to an exemplary embodiment of this specification. This device can also be applied to the electronic device shown in Figure 3 to implement the technical solution of this specification. In the blockchain system, the consensus nodes participating in the consensus include an elected master node and several slave nodes; a smart contract for abnormal management of the master node is deployed on the blockchain; the smart contract maintains a list of consensus nodes participating in the consensus; the method is applied to any slave node in the blockchain system; the device 500 includes: a second determining module 501, which determines whether a consensus proposal initiated by the master node has not been received within a preset timeout period; and a third sending module 502, which, if no consensus proposal initiated by the master node is received within the preset timeout period, broadcasts a timeout message to other slave nodes and collects the messages broadcast by the other slave nodes. The timeout message; wherein the timeout message contains the node identifier of the master node; the second generation module 503, in response to collecting a quorum of the timeout messages, generates a proof indicating that the master node has crashed based on the collected quorum of the timeout messages, and calls the exception handling logic contained in the smart contract based on the generated proof to verify the validity of the proof, and removes the master node from the consensus node list maintained by the smart contract after the proof passes the validity verification; the consensus module 504 continues to perform consensus processing based on the consensus nodes in the consensus node list after the master node has been removed.

[0152] Accordingly, this specification also provides an electronic device including a processor; a memory for storing processor-executable instructions; wherein the processor is configured to implement all the steps in the previously described method flow.

[0153] Accordingly, this specification also provides a computer-readable storage medium having stored thereon executable computer program instructions; wherein, when executed by a processor, the instructions implement all the steps in the previously described method flow.

[0154] Accordingly, this specification also provides a computer program product having executable computer program instructions stored thereon; wherein, when the computer program instructions are executed by a processor, they implement all the steps in the previously described method flow.

[0155] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0156] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0157] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0158] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0159] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0160] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations 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, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0161] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0162] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0163] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0164] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0165] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0166] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0167] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0168] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0169] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A consensus method in a blockchain system, wherein the consensus nodes participating in the consensus in the blockchain system include an elected master node and several slave nodes; The method is applied to any slave node in the blockchain system, and the method includes: Determine whether a consensus proposal initiated by the master node has not been received within the preset timeout period; If no consensus proposal initiated by the master node is received within the preset timeout period, a timeout message is broadcast to other slave nodes, and the timeout messages broadcast by the other slave nodes are collected; wherein, the timeout message contains the node identifier of the master node; In response to the collection of Quorum timeout messages, a proof indicating that the master node has crashed is generated based on the collected Quorum timeout messages; The proof is broadcast to other slave nodes for validity verification. After the proof passes the validity verification, the master node is removed from the consensus node list. Consensus processing continues based on the consensus nodes in the consensus node list after the master node has been removed.

2. The method of claim 1, further comprising: Receive proof broadcast by other slave nodes indicating that the master node has failed; The proof is validated, and after the proof passes the validation, the master node is removed from the consensus node list, and consensus processing continues based on the consensus nodes in the consensus node list after the master node has been removed.

3. The method of claim 2, wherein broadcasting the proof to other slave nodes comprises: The proof is broadcast to other slave nodes based on the running reliable broadcast protocol; Receive proofs broadcast by other slave nodes, including: The system receives proofs broadcast by other slave nodes based on a reliable broadcast protocol.

4. The method of claim 2, wherein the proof is a set of digital signatures based on the digital signatures contained in the collected Quorum of the timeout messages; Based on the collected Quorum timeout messages, a proof is generated to indicate that the master node has encountered an anomaly, including: A set of digital signatures is created based on the digital signatures contained in the collected Quorum timeout messages, as proof indicating that the master node has encountered an anomaly; Validating the proof includes: Verify the digital signatures contained in the digital signature set; If at least 1000 digital signatures in the digital signature set pass verification, then the proof is deemed to have passed validity verification.

5. The method as described in claim 1, wherein consensus processing continues based on consensus nodes in the consensus node list after the master node has been removed, comprising: A new master node is determined from the list of consensus nodes from which the master node was removed, and consensus messages are exchanged with the other consensus nodes in the list to continue processing consensus proposals initiated by the new master node.

6. The method as described in claim 5, wherein the consensus protocol running on the consensus nodes in the blockchain system supports the determination of a new master node by other consensus nodes besides the master node through explicit message interaction after the master node crashes; From the list of consensus nodes from which the master node was removed, a new master node is determined, including: The message interaction is performed with other consensus nodes in the consensus node list that have removed the master node, in order to re-elect a new master node from the consensus node list that has removed the master node.

7. The method as described in claim 6, wherein the consensus protocol run by the consensus nodes in the blockchain system is the PBFT protocol; Determining whether a consensus proposal initiated by the master node has not been received within a preset timeout period includes: Determine whether the Pre-Prepare message contained in the PBFT protocol broadcast by the master node has not been received within the preset timeout period; From the list of consensus nodes from which the master node was removed, a new master node is determined, including: Trigger the PBFT protocol's view change process, and interact with other consensus nodes in the consensus node list that have removed the master node to exchange View-Change and New-View messages, so as to re-elect a new master node from the consensus node list that has removed the master node.

8. The method as described in claim 5, wherein the consensus protocol running on the consensus nodes in the blockchain system supports implicitly executing a unified master node determination rule on other consensus nodes besides the master node after the master node crashes, in order to re-determine a new master node; From the list of consensus nodes from which the master node was removed, a new master node is determined, including: The unified master node determination rule is executed to re-determine a new master node from the consensus node list that has removed the master node.

9. The method as described in claim 8, wherein the consensus protocol run by the consensus nodes in the blockchain system is the HotStuff protocol; Determining whether a consensus proposal initiated by the master node has not been received within a preset timeout period includes: Determine whether the master node has not broadcast the prepare message contained in the HotStuff protocol within the preset timeout period; From the list of consensus nodes from which the master node was removed, a new master node is determined, including: Trigger the view switch of the HotStuff protocol to switch the current consensus to a new consensus, and execute the unified master node determination rule to re-determine a new master node for the new consensus from the consensus node list that has removed the master node.

10. A consensus method in a blockchain system, wherein the consensus nodes participating in the consensus in the blockchain system include an elected master node and several slave nodes; and a smart contract for anomaly management of the master node is deployed on the blockchain. The smart contract maintains a list of consensus nodes participating in the consensus process; The method is applied to any slave node in the blockchain system, and the method includes: Determine whether a consensus proposal initiated by the master node has not been received within the preset timeout period; If no consensus proposal initiated by the master node is received within the preset timeout period, a timeout message is broadcast to other slave nodes, and the timeout messages broadcast by the other slave nodes are collected; wherein, the timeout message contains the node identifier of the master node; In response to the collection of Quorum timeout messages, a proof indicating that the master node has crashed is generated based on the collected Quorum timeout messages. The exception handling logic contained in the smart contract is invoked based on the generated proof to verify the validity of the proof. After the proof passes the validity verification, the master node is removed from the consensus node list maintained by the smart contract. Consensus processing continues based on the consensus nodes in the consensus node list that have had the master node removed.

11. A consensus device in a blockchain system, wherein the consensus nodes participating in the consensus in the blockchain system include an elected master node and several slave nodes; The device is applied to any slave node in the blockchain system, and the device includes: The first determining module determines whether a consensus proposal initiated by the master node has not been received within a preset timeout period; The first sending module, if it does not receive a consensus proposal initiated by the master node within a preset timeout period, broadcasts a timeout message to other slave nodes and collects the timeout messages broadcast by the other slave nodes; wherein, the timeout message contains the node identifier of the master node; The first generation module, in response to the collection of Quorum timeout messages, generates a proof indicating that the master node has crashed based on the collected Quorum timeout messages; The second sending module broadcasts the proof to other slave nodes so that other consensus nodes can verify the validity of the proof. After the proof passes the validity verification, the master node is removed from the consensus node list participating in the consensus, and consensus processing continues based on the consensus nodes in the consensus node list that have removed the master node.

12. A consensus device in a blockchain system, wherein the consensus nodes participating in the consensus in the blockchain system include an elected master node and several slave nodes; and a smart contract for anomaly management of the master node is deployed on the blockchain. The smart contract maintains a list of consensus nodes participating in the consensus process; The device is applied to any slave node in the blockchain system, and the device includes: The second determining module determines whether a consensus proposal initiated by the master node has not been received within a preset timeout period; The third sending module, if it does not receive a consensus proposal initiated by the master node within a preset timeout period, broadcasts a timeout message to other slave nodes and collects the timeout messages broadcast by the other slave nodes; wherein, the timeout message contains the node identifier of the master node; The second generation module, in response to the collection of Quorum timeout messages, generates a proof indicating that the master node has crashed based on the collected Quorum timeout messages, and calls the exception handling logic contained in the smart contract to verify the validity of the proof based on the generated proof. After the proof passes the validity verification, the master node is removed from the consensus node list maintained by the smart contract. The consensus module continues consensus processing based on the consensus nodes in the consensus node list that have had the master node removed.

13. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 10.

14. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method of any one of claims 1 to 10.

15. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method of any one of claims 1 to 10.

Images