Consensus method and device in block chain system

Abstract

The invention discloses downtime detection in a block chain system. The downtime detection comprises the following steps: determining whether a consensus proposal initiated by a main node is not received within a preset timeout duration or not; if the consensus proposal initiated by the master node is not received within a preset timeout duration, timeout messages are broadcasted and sent to other slave nodes, and the timeout messages broadcasted and sent by the other slave nodes are collected; in response to the fact that the Quorum overtime messages are collected, a proof used for indicating that the main node crashes is generated on the basis of the collected Quorum overtime messages; and sending the proof to other slave nodes in a broadcast manner, so that the other slave nodes perform validity verification on the proof, and removing the master node from a consensus node list participating in consensus after the proof passes the validity verification, and consensus processing is continued on the basis of the consensus nodes in the consensus node list from which the main node is removed.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of blockchain technology, and more particularly to a consensus method and device in a blockchain system. Background Art

[0002] In the blockchain system, different participants can establish a distributed blockchain network through deployed nodes. The decentralized (or multi-centralized) distributed ledger constructed using the chain 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 solve the problem of consistency and correctness of the ledger data on multiple decentralized (or multi-centralized) nodes. Blockchain programs are running on each node. Under certain fault tolerance requirements, the consensus mechanism is used to ensure that all loyal nodes have the same transactions, thereby ensuring that all loyal nodes have consistent execution results for the same transaction, and the transactions and execution results are packaged to generate blocks.

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

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

[0005] However, in actual applications, this type of master-node-driven consensus protocol usually ignores the situation where the consensus nodes participating in the consensus go down. Once a consensus node (especially the master node) goes down, it may destroy the activity of the consensus network, causing the system to freeze and fail to respond normally 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 a plurality of slave nodes; the method is applied to any slave node in the blockchain system, and the method includes:

[0007] Determining whether a consensus proposal initiated by the master node is not received within a preset timeout period;

[0008] If the consensus proposal initiated by the master node is not received within the preset timeout period, a timeout message is broadcast to other slave nodes, and the timeout messages broadcasted by other slave nodes are collected; wherein the timeout message includes the node identifier of the master node;

[0009] In response to collecting a Quorum of the timeout messages, generating a certificate indicating that the master node has crashed based on the collected Quorum of the timeout messages;

[0010] The proof is broadcasted to other slave nodes so that the other slave nodes can verify the validity of the proof, and after the proof passes the validity verification, the master node is removed from the list of consensus nodes participating in the consensus, and consensus processing is continued based on the consensus nodes in the consensus node list from which the master node has been removed.

[0011] Optionally, the timeout message includes a digital signature of the slave node that sent the timeout message;

[0012] In response to collecting a Quorum of the timeout messages, before generating a certificate indicating that an abnormality has occurred in the master node based on the collected Quorum of the timeout messages, the method further includes:

[0013] Verify the digital signature contained in the received timeout message;

[0014] If the digital signature verification of the received timeout message passes, further verify whether the message content of the timeout message is the same as the message content of other received timeout messages;

[0015] If the message content included in the timeout message is the same as the message content included in other received timeout messages, the timeout message is saved as a valid timeout message.

[0016] Optionally, in response to collecting a Quorum of the timeout messages, generating a certificate indicating that an abnormality has occurred in the master node based on the collected Quorum of the timeout messages includes:

[0017] In response to collecting a Quorum of the valid timeout messages, a certificate indicating that the master node has crashed is generated based on the collected Quorum of the valid timeout messages.

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

[0019] Optionally, the method further includes:

[0020] Receive proof broadcasted by other slave nodes indicating that the master node has crashed;

[0021] The proof is validated, and after the proof passes the validity verification, the master node is removed from the list of consensus nodes participating in the consensus, and consensus processing is continued based on the consensus nodes in the consensus node list from which the master node has been removed.

[0022] Optionally, broadcasting the certificate to other slave nodes includes:

[0023] Broadcasting the proof to other slave nodes based on a reliable broadcast protocol;

[0024] Receive proofs broadcasted by other slave nodes, including:

[0025] Receive proofs broadcasted by other slave nodes based on the reliable broadcast protocol in operation.

[0026] Optionally, removing the master node from the list of consensus nodes participating in the consensus includes:

[0027] The master node is removed from the locally maintained list of consensus nodes participating in the consensus.

[0028] Optionally, the proof is a set of digital signatures consisting of digital signatures contained in a Quorum of the timeout messages collected;

[0029] Generating a certificate indicating that an abnormality has occurred in the master node based on the collected Quorum timeout messages, including:

[0030] Creating a digital signature set based on the digital signatures included in the collected Quorum timeout messages, as proof for indicating that an abnormality has occurred in the master node;

[0031] Verify the validity of the certificate, including:

[0032] Verifying the digital signatures included in the digital signature set;

[0033] If at least a Quorum of digital signatures included in the digital signature set pass verification, it is determined that the proof passes validity verification.

[0034] Optionally, each slave node in the blockchain system holds a private key shard obtained by splitting the master private key; the digital signature included in the timeout message is a partial signature obtained by each slave node signing the timeout message based on the private key shard held; the proof is a threshold signature generated by aggregating the collected Quorum partial signatures included in the timeout message;

[0035] Generating a certificate indicating that an abnormality has occurred in the master node based on the collected Quorum timeout messages, including:

[0036] Aggregate the local signatures contained in the collected Quorum timeout messages to generate a threshold signature as proof for indicating that an abnormality has occurred in the master node;

[0037] Verify the validity of the certificate, including:

[0038] Verifying the threshold signature based on a master public key corresponding to the master private key;

[0039] If the threshold signature verification passes, it is determined that the proof passes the validity verification.

[0040] Optionally, continuing consensus processing based on the consensus nodes in the consensus node list from which the master node has been removed includes:

[0041] A new master node is re-determined from the consensus node list from which the master node has been removed, and consensus messages are exchanged with other consensus nodes in the consensus node list to continue consensus processing on the consensus proposal initiated by the new master node.

[0042] Optionally, re-determining a new master node from the consensus node list from which the master node has been removed includes:

[0043] Execute the master node determination rule customized by the user for the blockchain system, and re-determine a new master node from the consensus node list from which the master node has been removed.

[0044] Optionally, re-determining a new master node from the consensus node list from which the master node has been removed includes:

[0045] Any target consensus node specified by the user from the consensus node list from which the master node has been removed is re-determined as the new master node for this round of consensus, so as to replace the master node that has gone down with the new master node.

[0046] Optionally, the consensus protocol run by the consensus nodes in the blockchain system supports re-determining a new master node through explicit message interaction by other consensus nodes except the master node after the master node goes down;

[0047] Re-determining a new master node from the consensus node list from which the master node has been removed includes:

[0048] The message interaction is performed with other consensus nodes in the consensus node list from which the master node is removed, so as to re-elect a new master node from the consensus node list from which the master node is removed.

[0049] Optionally, the consensus protocol run by the consensus nodes in the blockchain system is the PBFT protocol;

[0050] Determining whether a consensus proposal initiated by the master node is not received within a preset timeout period includes:

[0051] Determine whether a Pre-Prepare message included in the PBFT protocol broadcasted by the master node is not received within a preset timeout period;

[0052] Re-determining a new master node from the consensus node list from which the master node has been removed includes:

[0053] The view change process of the PBFT protocol is triggered, and View-Change messages and New-View messages are interacted with other consensus nodes in the consensus node list from which the master node is removed, so as to re-elect a new master node from the consensus node list from which the master node is removed.

[0054] Optionally, the consensus protocol run by the consensus nodes in the blockchain system supports implicitly executing a unified master node determination rule on other consensus nodes except the master node after the master node goes down, so as to re-determine a new master node;

[0055] Re-determining a new master node from the consensus node list from which the master node has been removed includes:

[0056] The unified master node determination rule is executed to re-determine a new master node from the consensus node list from which the master node has been removed.

[0057] Optionally, the consensus protocol run by the consensus nodes in the blockchain system is the HotStuff protocol;

[0058] Determining whether a consensus proposal initiated by the master node is not received within a preset timeout period includes:

[0059] Determine whether the prepare message included in the HotStuff protocol broadcasted by the master node is not received within a preset timeout period.

[0060] Re-determining a new master node from the consensus node list from which the master node has been removed includes:

[0061] Triggering the execution view switch, switching the current round of consensus to a new round of consensus, and executing the unified master node determination rule, re-determining a new master node for the new round of consensus from the consensus node list from which the master node has been removed.

[0062] This specification also 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 a plurality of 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, and the method includes:

[0063] Determining whether a consensus proposal initiated by the master node is not received within a preset timeout period;

[0064] If the consensus proposal initiated by the master node is not received within the preset timeout period, a timeout message is broadcast to other slave nodes, and the timeout messages broadcasted by other slave nodes are collected; wherein the timeout message includes the node identifier of the master node;

[0065] In response to collecting a Quorum of the timeout messages, generating a certificate indicating that the master node has crashed based on the collected Quorum of the timeout messages, calling the exception handling logic included in the smart contract based on the generated certificate, verifying the validity of the certificate, and after the certificate passes the validity verification, removing the master node from the consensus node list maintained by the smart contract;

[0066] Continue consensus processing based on the consensus nodes in the consensus node list from which the master node has been removed.

[0067] Optionally, the smart contract is a system smart contract deployed in the blockchain by an operator of a blockchain service platform corresponding to the blockchain system; wherein the system smart contract supports implicit calls based on instructions;

[0068] Calling the exception handling logic contained in the smart contract based on the generated proof includes:

[0069] Constructing a call instruction for the system smart contract based on the generated proof;

[0070] Based on the calling instruction, a contract call for the system smart contract is implicitly initiated to execute the exception handling logic contained in the system smart contract.

[0071] Optionally, the smart contract is a general smart contract that supports explicit calls based on transactions;

[0072] Calling the exception handling logic contained in the smart contract based on the generated proof includes:

[0073] Constructing a contract call transaction for the smart contract based on the generated proof;

[0074] The contract call transaction is added to the target block to be executed that has been agreed upon, and the contract call transaction contained in the target block is executed to initiate a contract call for the smart contract to execute the exception handling logic contained in the smart contract.

[0075] Optionally, continuing consensus processing based on the consensus nodes in the consensus node list from which the master node has been removed includes:

[0076] A new master node is re-determined from the consensus node list from which the master node has been removed, and consensus messages are exchanged with other consensus nodes in the consensus node list to continue consensus processing on the consensus proposal initiated by the new master node.

[0077] Optionally, re-determining a new master node from the consensus node list from which the master node has been removed includes:

[0078] Execute the master node determination rule customized by the user for the blockchain system, and re-determine a new master node from the consensus node list from which the master node has been removed.

[0079] Optionally, re-determining a new master node from the consensus node list from which the master node has been removed includes:

[0080] Any target consensus node specified by the user from the consensus node list from which the master node has been removed is re-determined as the new master node for this round of consensus, so as to replace the master node that has gone down with the new master node.

[0081] Optionally, the consensus protocol run by the consensus nodes in the blockchain system supports re-determining a new master node through explicit message interaction by other consensus nodes except the master node after the master node goes down;

[0082] Re-determining a new master node from the consensus node list from which the master node has been removed includes:

[0083] The message interaction is performed with other consensus nodes in the consensus node list from which the master node is removed, so as to re-elect a new master node from the consensus node list from which the master node is removed.

[0084] Optionally, the consensus protocol run by the consensus nodes in the blockchain system is the PBFT protocol;

[0085] Determining whether a consensus proposal initiated by the master node is not received within a preset timeout period includes:

[0086] Determine whether a Pre-Prepare message included in the PBFT protocol broadcasted by the master node is not received within a preset timeout period;

[0087] Re-determining a new master node from the consensus node list from which the master node has been removed includes:

[0088] The view change process of the PBFT protocol is triggered, and View-Change messages and New-View messages are interacted with other consensus nodes in the consensus node list from which the master node is removed, so as to re-elect a new master node from the consensus node list from which the master node is removed.

[0089] Optionally, the consensus protocol run by the consensus nodes in the blockchain system supports implicitly executing a unified master node determination rule on other consensus nodes except the master node after the master node goes down, so as to re-determine a new master node;

[0090] Re-determining a new master node from the consensus node list from which the master node has been removed includes:

[0091] The unified master node determination rule is executed to re-determine a new master node from the consensus node list from which the master node has been removed.

[0092] Optionally, the consensus protocol run by the consensus nodes in the blockchain system is the HotStuff protocol;

[0093] Determining whether a consensus proposal initiated by the master node is not received within a preset timeout period includes:

[0094] Determine whether the prepare message included in the HotStuff protocol broadcasted by the master node is not received within a preset timeout period;

[0095] Re-determining a new master node from the consensus node list from which the master node has been removed includes:

[0096] Triggering the view switch of the HotStuff protocol, switching the current round of consensus to a new round of consensus, and executing the unified master node determination rule, re-determining a new master node for the new round of consensus from the consensus node list from which the master node has been removed.

[0097] 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 a plurality of slave nodes; the device is applied to any slave node in the blockchain system, and the device includes:

[0098] A determination module determines whether a consensus proposal initiated by the master node is not received within a preset timeout period;

[0099] The first sending module, if the consensus proposal initiated by the master node is not received within a preset timeout period, broadcasts a timeout message to other slave nodes, and collects the timeout messages broadcasted by the other slave nodes; wherein the timeout message includes the node identifier of the master node;

[0100] A generating module, in response to collecting a Quorum of the timeout messages, generating a certificate indicating that the master node has crashed based on the collected Quorum of the timeout messages;

[0101] The second sending module broadcasts the proof to other slave nodes so that the other consensus nodes verify the validity of the proof, and after the proof passes the validity verification, removes the master node from the list of consensus nodes participating in the consensus, and continues consensus processing based on the consensus nodes in the consensus node list from which the master node has been removed.

[0102] 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 a plurality of 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 device is applied to any slave node in the blockchain system, and the device includes:

[0103] A second determination module determines whether a consensus proposal initiated by the master node is not received within a preset timeout period;

[0104] The third sending module, if the consensus proposal initiated by the master node is not received within a preset timeout period, broadcasts a timeout message to other slave nodes, and collects the timeout messages broadcasted by the other slave nodes; wherein the timeout message includes the node identifier of the master node;

[0105] A second generation module, in response to collecting a Quorum of the timeout messages, generates a certificate indicating that the master node has crashed based on the collected Quorum of the timeout messages, and calls the exception handling logic included in the smart contract based on the generated certificate to verify the validity of the certificate, and after the certificate passes the validity verification, removes the master node from the consensus node list maintained by the smart contract;

[0106] The consensus module continues to perform consensus processing based on the consensus nodes in the consensus node list from which the master node has been removed.

[0107] In the above embodiment, by introducing a downtime detection mechanism for the master node in the master node-driven consensus protocol, when the master node fails to initiate a proposal in time, the master node can be promptly removed from the list of consensus nodes participating in the consensus as a downtime node, thereby avoiding the situation where the blockchain system cannot respond normally for a long time due to the downtime of the master node, thereby improving the activity of the consensus network and ensuring the stability of the blockchain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0108] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for use 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 ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0109] Figure 1 It is a flowchart of a consensus method in a blockchain system shown in an embodiment of this specification;

[0110] Figure 2 It is a flowchart of another consensus method in a blockchain system shown in an embodiment of this specification;

[0111] Figure 3 is a schematic structural diagram of an electronic device shown in an embodiment of this specification;

[0112] Figure 4 It is a block diagram of a consensus device in a blockchain system shown in an embodiment of this specification;

[0113] Figure 5It is a block diagram of another consensus device in a blockchain system shown in one embodiment of this specification. DETAILED DESCRIPTION

[0114] In order 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 in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0115] The purpose of the specification is to propose a technical solution that introduces a real-time downtime detection mechanism for the master node in the master node-driven consensus protocol, so as to improve the activity of the consensus network and ensure the stability of the blockchain system.

[0116] See also Figure 1 , Figure 1 This is a flowchart of downtime detection in a blockchain system 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:

[0117] Step 102: Determine whether a consensus proposal initiated by the master node is not received within a preset timeout period;

[0118] The consensus protocol run by the consensus nodes participating in the consensus in the above blockchain system may specifically include a consensus protocol driven by a master node. Based on this type of consensus protocol, the consensus nodes participating in the consensus in the blockchain system may generally include an elected master node and several slave nodes.

[0119] For example, in some examples, the master node-driven consensus protocol mentioned above may specifically include the PBFT protocol and the HotStuff protocol. Of course, in practical applications, the master node-driven consensus protocol mentioned above may specifically be other types of consensus protocols that support the election of a master node and several slave nodes in a round of consensus, in addition to the PBFT protocol and the HotStuff protocol, and is not specifically limited in this specification.

[0120] In the master node driven consensus protocol, the master node can be responsible for initiating a consensus proposal and broadcasting the consensus proposal to each slave node participating in the consensus in the blockchain system. The slave nodes participating in the consensus in the blockchain system can receive the consensus proposal broadcasted by the master node and exchange consensus messages with other slave nodes to process the received consensus proposal.

[0121] In a masternode-driven consensus protocol, since the masternode is usually the core of each round of consensus, once the masternode goes down, it will usually destroy the activity of the consensus network, causing the system to freeze and fail to respond normally for a long time.

[0122] Based on this, in the consensus protocol driven by the master node, a real-time downtime detection mechanism for the master node can be introduced on each slave node, so that when the slave nodes participating in the consensus in the blockchain system receive the consensus proposal broadcast by the master node, if they do not receive the consensus proposal initiated by the master node for a long time, they can determine whether the waiting time for not receiving the consensus proposal initiated by the master node reaches the preset timeout period, so as to confirm whether the master node has been down. Among them, the preset timeout period can be a custom threshold, and its specific value can be flexibly set based on actual needs.

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

[0124] For example, in one embodiment shown, the above-mentioned master node-driven consensus protocol is taken as the PBFT consensus protocol as an example. Based on the PBFT consensus protocol, in a round of consensus, the messages exchanged between the master node and the slave node usually include Pre-Prepare messages, Pre-Prepare and Commit messages, etc. Among them, the Pre-Prepare message is used to initiate a consensus proposal, and the master node can carry the initiated consensus protocol in the Pre-Prepare message and broadcast it to each slave node. In this case, in the process of receiving the consensus proposal broadcast by the master node, each slave node can confirm whether the master node has crashed by determining whether the Pre-Prepare message broadcast by the master node is not received within the preset timeout period.

[0125] In one embodiment shown, the HotStuff protocol is used as an example of the consensus protocol driven by the master node. Based on the HotStuff protocol, in one round of consensus, the messages exchanged between the master node and the slave nodes may generally include prepare messages, prepare-vote messages, pre-commit messages, pre-commit-vote messages, commit messages, commit-vote messages, and the like. Among them, the prepare message is used to initiate a consensus proposal, and the master node may carry the initiated consensus protocol in the Prepare message and broadcast it to each slave node. In this case, in the process of receiving the consensus proposal broadcast by the master node, each slave node may confirm whether the master node has crashed by determining whether the Prepare message broadcast by the master node is not received within the preset timeout period. Step 104: If the consensus proposal initiated by the master node is not received within the preset timeout period, a timeout message is broadcast to other slave nodes, and the timeout message broadcast by other slave nodes is collected; wherein the timeout message includes the node identifier of the master node;

[0126] If any slave node participating in the consensus in the blockchain system does not receive a consensus proposal initiated by the master node within a preset timeout period in a round of consensus, 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. The timeout message is specifically used to confirm the event of the master node crashing, and the timeout message can specifically include the node identifier of the master node that crashed.

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

[0128] For example, in one embodiment shown, the message format of the timeout message can be expressed as<TIMEOUT,ID,seq> TIMEOUT is a type identifier indicating that the message is a timeout message; ID indicates the node identifier of the master node where the downtime occurs; and seq indicates the proposal identifier of the consensus proposal that the master node where the downtime occurs did not propose.

[0129] It should be explained that the consensus proposal that the master node did not propose is usually the consensus proposal that the master node should have initiated in the current round of consensus; for example, assuming that the current consensus round is for consensus on block N, the master node should usually broadcast block N created based on the collected transactions as a consensus proposal to each slave node without downtime. At this time, the consensus proposal that the master node should have initiated in this round of consensus is block N. Correspondingly, the proposal identifier of the consensus proposal that the master node did not propose is the block identifier of block N.

[0130] It should be emphasized that the message content contained 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 above-mentioned master node, and the proposal identifier of the consensus proposal not proposed by the above-mentioned master node, can be flexibly expanded based on specific needs in actual applications, and will not be listed one by one in this manual.

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

[0132] In one embodiment shown, the above timeout message may specifically include a digital signature of the slave node that sends the timeout message; for example, in one example, the message format of the above timeout message may specifically represent where σ i Indicates the digital signature of the slave node that sent the timeout message.

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

[0134] Step 106: In response to collecting a Quorum of the timeout messages, generating a certificate indicating that the master node has crashed based on the collected Quorum of the timeout messages;

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

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

[0137] It should be noted that Quorum usually refers to a threshold number of consensus nodes that can represent the majority of the blockchain. For example, when the number of consensus nodes participating in the consensus in the blockchain is n3f+1, the value of Quorum is nf, that is, 2f+1. In this way, for a distributed system with 4 nodes, any 3 nodes can form a Quorum. f refers to the number of Byzantine nodes (that is, malicious nodes) that the blockchain can tolerate.

[0138] In one embodiment shown, the proof generated by any slave node in the blockchain system based on the collected Quorum timeout messages can specifically be a set of digital signatures consisting of digital signatures contained in the collected Quorum timeout messages. In this case, when any slave node in the blockchain system generates the proof based on the collected Quorum timeout messages, it can create a set of digital signatures based on the digital signatures contained in the collected Quorum timeout messages as a proof for indicating that the master node has an abnormality.

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

[0140] In one embodiment shown, a threshold signature technology can also be used to generate proof. Based on the threshold signature technology, each slave node in the blockchain system can hold a private key fragment obtained by splitting the master private key; the digital signature contained in the above timeout message can be a local signature obtained by each slave node signing the timeout message based on the private key fragment held. 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 local signatures contained in the collected Quorum timeout messages.

[0141] 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), and based on the number of slave nodes in the blockchain system, a threshold value Quorum of the number of slave nodes that can represent the majority of the blockchain is calculated, and then the Quorum is set as the threshold value for generating an aggregate signature.

[0142] Then, the master private key can be split into n private key shards according to the number n of slave nodes in the blockchain system, and the n private key shards can be distributed to the n slave nodes respectively. When the master private key is split, a secret sharing-based algorithm (such as Shamir secret sharing algorithm) can be used to split the private key, thereby ensuring that the master private key can only be recovered when at least a quorum of private key shards are combined together.

[0143] When each slave node in the blockchain system signs a timeout message, it can use the private key shard 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 shard it holds to sign the timeout message.

[0144] In this case, 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 as a proof to indicate that an abnormality has occurred in the master node.

[0145] Step 108: Broadcast the certificate to other slave nodes so that the other slave nodes can verify the validity of the certificate. After the certificate passes the validity verification, remove the master node from the list of consensus nodes participating in the consensus, and continue the consensus processing based on the consensus nodes in the consensus node list from which the master node has been removed.

[0146] Any slave node in the blockchain system, 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 proofs broadcasted by other slave nodes indicating that the master node has crashed.

[0147] Furthermore, after receiving the proof broadcasted by other slave nodes to indicate that the master node has crashed, the validity of the proof can also be verified.

[0148] For example, in one embodiment shown, if the proof is a digital signature set consisting of digital signatures contained in a quorum of collected timeout messages, in this case, the digital signatures contained in the digital signature set can be verified separately; if at least a quorum of digital signatures contained in the digital signature set are verified, it can be determined that the proof has passed the validity verification.

[0149] In another embodiment shown, if the proof is a threshold signature generated by aggregating the local signatures contained in the collected Quorum timeout messages, in this case, the threshold signature can be verified based on the master public key corresponding to the above master private key; if the threshold signature verification passes, it can be determined that the proof has passed the validity verification. If the proof passes the validity verification, there is no need to continue waiting for the master node to initiate a consensus proposal, but the master node that has crashed can be removed from the consensus node list participating in the consensus, and then the consensus processing can be continued based on the consensus nodes in the consensus node list from which the master node has been removed.

[0150] 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.

[0151] In another embodiment 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.

[0152] In this way, for any slave node, after receiving the proof broadcast by other slave nodes and verifying the proof, it can directly operate in 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.

[0153] For example, the consensus node list may specifically be a node identifier list of consensus nodes participating in the consensus, and the slave node may remove the node identifier of the master node from the node identifier list.

[0154] Among them, it should be noted that each slave node in the blockchain system broadcasts the generated proof to other slave nodes by running the RBC protocol, and receives the specific implementation details broadcast by other slave nodes through the running RBC protocol. These details will not be described in detail in this manual, and those skilled in the art can refer to the records in the relevant technology.

[0155] After each slave node in the blockchain system removes the downed master node from the consensus node list participating in the consensus maintained locally, each slave node can continue consensus processing based on the consensus nodes in the consensus node list from which the master node has been removed.

[0156] In this way, it is possible to avoid the situation where the blockchain system cannot respond normally for a long time due to the downtime of the main node, thereby improving the activity of the consensus network and ensuring the stability of the blockchain system.

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

[0158] It should be noted that each slave node re-determines a new master node from the consensus node list from which the master node has been removed. The specific strategy adopted can be flexibly customized by the user based on specific needs in actual applications and is not specifically limited in this manual.

[0159] In one embodiment shown, the user can customize a unified master node determination rule for the blockchain system. In this case, when each slave node in the blockchain system redetermines a new master node from the consensus node list from which the master node is removed, the unified master node determination rule customized by the user for the blockchain system can be executed to redetermine a new master node from the consensus node list from which the master node is removed.

[0160] For instance, in one example, the master node determination rule may specifically include re-designating a new master node from a consensus node list by a user. In this case, the user may designate any target consensus node from the consensus node list from which the master node has been removed as the new master node for this round of consensus based on specific needs. When each slave node redetermines a new master node from the consensus node list from which the master node has been removed, it may obtain the target consensus node designated by the user from the consensus node list, and then redetermine the target consensus node as the new master node for this round of consensus, and replace the master node that has gone down with the new master node.

[0161] In this way, after determining that the master node of a round of consensus has crashed, the master node that has crashed can be replaced in time based on the new master node re-designated by the user, thereby avoiding the situation where the blockchain system cannot respond normally for a long time due to the crash of the master node.

[0162] It should be emphasized that since most consensus protocols also support re-determining a new master node after the master node goes down, in actual applications, the above-mentioned master node downtime detection mechanism can also be combined with the consensus protocol-supported mechanism for re-determining a new master node after the master node goes down, so as to achieve compatibility with most consensus protocols. At present, most consensus protocols support mechanisms for re-determining a new master node after the master node goes down, which usually include re-determining a new master node through explicit message interaction and re-determining a new master node through implicit execution of unified master node determination rules.

[0163] Among them, it needs to be explained that redetermining the new master node through explicit message interaction refers to a method in which each slave node redetermines the new master node by sending messages to each other; and redetermining the new master node through implicit execution of a unified master node determination rule means that when redetermining the new master node, each slave node does not need to send messages to each other, but redetermines the new master node by executing a unified master node determination rule locally.

[0164] In one embodiment shown, if the consensus protocol run by the consensus nodes in the blockchain system supports re-determining a new master node through explicit message interaction by consensus nodes other than the master node after the master node goes down, in this case, when each slave node re-determines a new master node from the consensus node list from which the master node has been removed, it can specifically interact with other consensus nodes in the consensus node list from which the master node has been removed, so as to re-elect a new master node from the consensus node list from which the master node has been removed.

[0165] For example, if the consensus protocol run by the consensus nodes in the blockchain system is the PBFT protocol, the view change supported by the PBFT protocol is a mechanism in which, after the master node goes down, other consensus nodes other than the master node re-determine a new master node through explicit message interaction. Among them, based on the view change mechanism, the messages exchanged by each slave node usually include View-Change messages and New-View messages.

[0166] In this scenario, when each slave node redetermines a new master node from the consensus node list from which the master node has been removed, it can trigger the view change process of executing the PBFT protocol, and interact with other consensus nodes in the consensus node list from which the master node has been removed through View-Change messages and New-View messages, so as to redetermine a new master node from the consensus node list from which the master node has been removed.

[0167] For example, based on the view change process of the PBFT protocol, after determining that the master node is down, each slave node can broadcast a View-Change message to other slave nodes. When any slave node receives at least a quorum (for example, 2f+1) of valid View-Change messages, it can determine whether it has been elected as the new master node through calculation. If so, it can broadcast a New-View message to other slave nodes as the new master node to open a new view.

[0168] In one embodiment shown, if the consensus protocol run by the consensus nodes in the blockchain system supports implicitly executing a unified master node determination rule on other consensus nodes except the master node to re-determine a new master node after the master node goes down, in this case, when each slave node re-determines a new master node from the consensus node list from which the master node has been removed, it can specifically execute the unified master node determination rule locally to re-determine a new master node from the consensus node list from which the master node has been removed.

[0169] For example, the consensus protocol run by the consensus nodes in the blockchain system is the HotStuff protocol. The HotStuff protocol also supports a view switching mechanism similar to the pbft protocol, but unlike pbft, the HotStuff protocol supports forced view switching every time a new round of consensus is started; for example, assuming that the view of the current round of consensus is view1, then when a new round of consensus is started, the view will be switched from view1 to view2; and the HotStuff protocol also supports re-determining a new master node in each round of view. In addition, the HotStuff protocol also simplifies the view switching process, omitting the message interaction process, and instead adopts a new master node to be re-determined by implicitly executing a unified master node determination rule.

[0170] In this scenario, when each slave node redetermines a new master node from the consensus node list from which the above master node has been removed, it can trigger the view switching of the HotStuff protocol, switch the current round of consensus to a new round of consensus, and then each slave node can execute a unified master node determination rule locally, and redetermine a new master node for the new round of consensus from the consensus node list from which the above master node has been removed.

[0171] It should be noted that the specific master node determination rule used to determine the new master node from the consensus node list can be used as a part of the consensus protocol or can be independent of the consensus protocol in practical applications. The so-called existence independent of the consensus protocol means that in practical applications, the master node determination rule can be flexibly customized based on the actual needs on the basis of the consensus protocol, and then the master node determination rule can be used as a supplement to the consensus protocol and combined with the consensus protocol.

[0172] For example, taking the pbft consensus protocol as an example, in the pbft consensus protocol, it is stipulated that the master node of each round of consensus can be determined in the following way:

[0173] p=v mod|R|

[0174] Among them, the parameter p in the above formula: represents the number of the master node determined in each round of consensus; the parameter v: represents the view number corresponding to this round of consensus; the parameter |R|: represents the number of consensus nodes participating in the consensus in the blockchain system.

[0175] For another example, taking the HotStuff consensus protocol as an example, the HotStuff consensus protocol does not specify a specific strategy for determining the master node for each round of consensus. That is, for the HotStuff consensus protocol, the determination rules for determining the master node for each round of consensus can exist independently of the HotStuff consensus protocol. In practical applications, users can flexibly customize the determination rules of the master node based on actual needs and combine them with the HotStuff consensus protocol. For example, in one example, for the HotStuff consensus protocol, the determination rules of the master node specified in the above-mentioned pbft consensus protocol can also be adopted.

[0176] It can be seen that by combining the above-mentioned downtime detection mechanism for the master node with the existing rules of most consensus protocols for re-determining the master node after the master node goes down, these consensus protocols can be further optimized so that these consensus protocols can also have the ability to perform real-time downtime detection on the master node, thereby further improving and supplementing the existing consensus protocols.

[0177] See also Figure 2 , Figure 2 This is a flowchart of downtime detection in another blockchain system shown in this specification, wherein the consensus nodes participating in the consensus in the blockchain system 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, and the method includes the following execution process:

[0178] Step 202: Determine whether a consensus proposal initiated by the master node is not received within a preset timeout period;

[0179] In this embodiment, in the consensus protocol driven by the master node, a real-time downtime detection mechanism for the master node can be introduced on each slave node, so that when the slave nodes participating in the consensus in the blockchain system receive the consensus proposal broadcast by the master node, if they do not receive the consensus proposal initiated by the master node for a long time, they can determine whether the waiting time for not receiving the consensus proposal initiated by the master node reaches the preset timeout time, so as to confirm whether the master node has crashed.

[0180] The preset timeout duration may be a user-defined threshold, and its specific value may be flexibly set based on actual needs.

[0181] For different master-node driven consensus protocols, there may be certain differences in the confirmation methods used by slave nodes to confirm whether the master node has crashed.

[0182] For example, in one embodiment shown, the above-mentioned master node-driven consensus protocol is taken as the PBFT consensus protocol as an example. Based on the PBFT consensus protocol, in a round of consensus, the messages exchanged between the master node and the slave node usually include Pre-Prepare messages, Pre-Prepare and Commit messages, etc. Among them, the Pre-Prepare message is used to initiate a consensus proposal, and the master node can carry the initiated consensus protocol in the Pre-Prepare message and broadcast it to each slave node. In this case, in the process of receiving the consensus proposal broadcast by the master node, each slave node can confirm whether the master node has crashed by determining whether the Pre-Prepare message broadcast by the master node is not received within the preset timeout period.

[0183] In one embodiment shown, the HotStuff protocol is used as an example of the consensus protocol driven by the master node. Based on the HotStuff protocol, in one round of consensus, the messages exchanged between the master node and the slave node may generally include prepare messages, prepare-vote messages, pre-commit messages, pre-commit-vote messages, commit messages, commit-vote messages, etc. Among them, the prepare message is used to initiate a consensus proposal, and the master node may carry the initiated consensus protocol in the Prepare message and broadcast it to each slave node. In this case, in the process of receiving the consensus proposal broadcast by the master node, each slave node can confirm whether the master node has crashed by determining whether the Prepare message broadcast by the master node is not received within the preset timeout period.

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

[0185] If any slave node participating in the consensus in the blockchain system determines that it has not received a consensus proposal initiated by the master node within the preset timeout period in a round of consensus, 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. Among them, the timeout message is specifically used to confirm the event of the master node crashing, and the timeout message can specifically include the node identifier of the master node that crashed. It should be noted that the message format of the above-mentioned timeout message is not specifically limited in this specification, and can be flexibly defined based on needs in actual applications.

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

[0187] The implementation details of validating the timeout message will not be described in detail in this embodiment, and reference may be made to the description of the previous embodiments.

[0188] Step 206: In response to collecting a Quorum of the timeout messages, generating a certificate indicating that the master node has crashed based on the collected Quorum of the timeout messages, calling the exception handling logic included in the smart contract based on the generated certificate, verifying the validity of the certificate, and after the certificate passes the validity verification, removing the master node from the consensus node list maintained by the smart contract;

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

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

[0191] The implementation details of generating the above-mentioned proof based on the collected Quorum timeout messages will not be repeated in this embodiment, and reference may be made to the records of the previous embodiments.

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

[0193] 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, the generated proof can be used as a call parameter to call the exception handling logic contained in the smart contract, and the smart contract will verify the validity of the proof. After the proof passes the validity verification, the master node that has crashed will be removed from the above-mentioned consensus node list maintained by the smart contract.

[0194] The specific implementation details of verifying the validity of the certificate will not be repeated in this embodiment, and reference may be made to the description of the previous embodiments.

[0195] In one embodiment shown, the above-mentioned smart contract can 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 the so-called system smart contract usually refers to a special type of smart contract used to implement system-level functions (such as account management, authority control, internal logic of the consensus mechanism, etc.). For this type of smart contract, compared with the general smart contract in the blockchain field, it is no longer supported to make explicit calls based on transactions, but to support implicit calls based on instructions.

[0196] In this case, when any slave node in the blockchain system calls the exception handling logic contained in the smart contract based on the generated proof, it can specifically construct a call instruction for the system smart contract based on the generated proof, and then implicitly initiate 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, verify the validity of the proof, and after the proof passes the validity verification, remove the master node that has crashed from the above-mentioned consensus node list maintained by the smart contract.

[0197] It should be noted that when a smart contract is explicitly called by sending a contract call transaction, the contract call transaction usually needs to wait for at least one round of consensus, and the contract call transaction can only be executed normally after it is passed by consensus; therefore, this means that if a smart contract is explicitly called by sending a contract call transaction, it is usually necessary to wait for at least one round of consensus before the main node that has crashed can be removed from the consensus node list. Obviously, there is a problem that the main node that has crashed cannot be removed from the consensus node list in time.

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

[0199] By implicitly calling the system smart contract through instructions, since the instructions themselves can be executed in real time without consensus processing, this method is used to initiate a contract call for the system smart contract. Obviously, the main node that has crashed can be removed from the consensus node list in a timely manner.

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

[0201] In this case, when any slave node in the blockchain system calls the exception handling logic contained in the smart contract based on the generated proof, it can specifically construct a contract call transaction for the smart contract based on the generated proof, and directly add the contract call transaction to the target block to be executed that has been agreed upon. For example, in one example, in order to avoid affecting the execution of the original transaction contained in the target block, the contract call transaction can be specifically added to the target block as the last transaction contained in the target block.

[0202] Then, in the process of executing 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 for the smart contract, execute the exception handling logic contained in the smart contract, verify the validity of the proof, and after the proof passes the validity verification, remove the master node that has crashed from the above-mentioned consensus node list maintained by the smart contract.

[0203] For example, in a blockchain system, the consensus process for block N is usually started immediately after the consensus for block N-1 is passed and the execution phase of the transactions contained in block N-1 is entered. If, during the consensus process for block N, it is determined that the master node of this round of consensus has crashed, then the contract call transaction for the above-mentioned smart contract constructed based on the generated proof can be added to the block N-1 to be executed, so that the master node that has crashed can be removed from the consensus node list in time when the consensus for block N has not been completed, thereby avoiding the impact on the consensus process for block N due to the failure to remove the master node that has crashed in time.

[0204] Step 208: Continue consensus processing based on the consensus nodes in the consensus node list from which the master node has been removed.

[0205] After the smart contract removes the down 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 consensus processing based on the consensus nodes in the consensus node list maintained by the smart contract after the master node is removed.

[0206] For example, in one example, the consensus node list participating in the consensus can be specifically stored in the state data maintained by the smart contract. Each slave node in the blockchain system can synchronize the consensus node list with the master node removed from the state data maintained by the smart contract to the local storage, and then continue the consensus processing based on the consensus nodes in the consensus node list with the master node removed from the local storage.

[0207] In one embodiment shown, when the blockchain continues to perform consensus processing based on the consensus nodes in the consensus node list from which the above-mentioned master node has been removed, it can specifically re-determine a new master node from the consensus node list from which the master node has been removed, and then interact with other consensus nodes in the consensus node list through consensus messages to continue to perform consensus processing on the consensus proposal initiated by the new master node.

[0208] It should be noted that each slave node re-determines a new master node from the consensus node list from which the master node has been removed. The specific strategy adopted can be flexibly customized by the user based on specific needs in actual applications and is not specifically limited in this manual.

[0209] In one embodiment shown, the user can customize a unified master node determination rule for the blockchain system. In this case, when each slave node in the blockchain system redetermines a new master node from the consensus node list from which the master node is removed, the unified master node determination rule customized by the user for the blockchain system can be executed to redetermine a new master node from the consensus node list from which the master node is removed.

[0210] For instance, in one example, the master node determination rule may specifically include re-designating a new master node from a consensus node list by a user. In this case, the user may designate any target consensus node from the consensus node list from which the master node has been removed as the new master node for this round of consensus based on specific needs. When each slave node redetermines a new master node from the consensus node list from which the master node has been removed, it may obtain the target consensus node designated by the user from the consensus node list, and then redetermine the target consensus node as the new master node for this round of consensus, and replace the master node that has gone down with the new master node.

[0211] In this way, after determining that the master node of a round of consensus has crashed, the master node that has crashed can be replaced in time based on the new master node re-designated by the user, thereby avoiding the situation where the blockchain system cannot respond normally for a long time due to the crash of the master node.

[0212] It should be emphasized that since most consensus protocols also support re-determining a new master node after the master node goes down, in actual applications, the above-mentioned master node downtime detection mechanism can also be combined with the consensus protocol-supported mechanism for re-determining a new master node after the master node goes down, so as to achieve compatibility with most consensus protocols. At present, most consensus protocols support mechanisms for re-determining a new master node after the master node goes down, which usually include re-determining a new master node through explicit message interaction and re-determining a new master node through implicit execution of unified master node determination rules.

[0213] In one embodiment shown, if the consensus protocol run by the consensus nodes in the blockchain system supports re-determining a new master node through explicit message interaction by consensus nodes other than the master node after the master node goes down, in this case, when each slave node re-determines a new master node from the consensus node list from which the master node has been removed, it can specifically interact with other consensus nodes in the consensus node list from which the master node has been removed, so as to re-elect a new master node from the consensus node list from which the master node has been removed.

[0214] For example, if the consensus protocol run by the consensus nodes in the blockchain system is the PBFT protocol, the view change supported by the PBFT protocol is a mechanism in which, after the master node goes down, other consensus nodes other than the master node re-determine a new master node through explicit message interaction. Among them, based on the view change mechanism, the messages exchanged by each slave node usually include View-Change messages and New-View messages.

[0215] In this scenario, when each slave node redetermines a new master node from the consensus node list from which the master node has been removed, it can trigger the view change process of executing the PBFT protocol, and interact with other consensus nodes in the consensus node list from which the master node has been removed through View-Change messages and New-View messages, so as to redetermine a new master node from the consensus node list from which the master node has been removed.

[0216] For example, based on the view change process of the PBFT protocol, after determining that the master node is down, each slave node can broadcast a View-Change message to other slave nodes. When any slave node receives at least a quorum (for example, 2f+1) of valid View-Change messages, it can determine whether it has been elected as the new master node through calculation. If so, it can broadcast a New-View message to other slave nodes as the new master node to open a new view.

[0217] In one embodiment shown, if the consensus protocol run by the consensus nodes in the blockchain system supports implicitly executing a unified master node determination rule on other consensus nodes except the master node to re-determine a new master node after the master node goes down, in this case, when each slave node re-determines a new master node from the consensus node list from which the master node has been removed, it can specifically execute the unified master node determination rule locally to re-determine a new master node from the consensus node list from which the master node has been removed.

[0218] For example, the consensus protocol run by the consensus nodes in the blockchain system is the HotStuff protocol. The HotStuff protocol also supports a view switching mechanism similar to the pbft protocol, but unlike pbft, the HotStuff protocol supports forced view switching every time a new round of consensus is started; for example, assuming that the view of the current round of consensus is view1, then when a new round of consensus is started, the view will be switched from view1 to view2; and the HotStuff protocol also supports re-determining a new master node in each round of view. In addition, the HotStuff protocol also simplifies the view switching process, omitting the message interaction process, and instead adopts a new master node to be re-determined by implicitly executing a unified master node determination rule.

[0219] In this scenario, when each slave node redetermines a new master node from the consensus node list from which the above master node has been removed, it can trigger the view switching of the HotStuff protocol, switch the current round of consensus to a new round of consensus, and then each slave node can execute a unified master node determination rule locally, and redetermine a new master node for the new round of consensus from the consensus node list from which the above master node has been removed.

[0220] It should be noted that the specific master node determination rule used to determine the new master node from the consensus node list can be used as part of the consensus protocol or independent of the consensus protocol in practical applications, and will not be repeated in this embodiment.

[0221] In the above technical solution, by introducing a downtime detection mechanism for the master node in the master node-driven consensus protocol, when the master node fails to initiate a proposal in time, the master node can be promptly removed from the list of consensus nodes participating in the consensus as a downtime node, thereby avoiding the situation where the blockchain system cannot respond normally for a long time due to the downtime of the master node, thereby improving the activity of the consensus network and ensuring the stability of the blockchain system.

[0222] Corresponding to the embodiments of the aforementioned method, this specification also provides embodiments of an apparatus, an electronic device, and a storage medium.

[0223] Figure 3 is a schematic structural diagram of an electronic device provided by an exemplary embodiment. Figure 3 At the hardware level, the device includes a processor 302, an internal bus 304, a network interface 306, a memory 308, and a non-volatile memory 310, and may also include other required hardware. One or more embodiments of this specification may be implemented based on software, such as the processor 302 reading the corresponding computer program from the non-volatile memory 310 into the memory 308 and then running it. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0224] like Figure 4 As shown, Figure 4 This is a block diagram of a consensus device in a blockchain system according to an exemplary embodiment of the present specification. The device can be applied to Figure 3 The electronic device shown in the figure is used 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:

[0225] The first determination module 401 determines whether a consensus proposal initiated by the master node is not received within a preset timeout period;

[0226] The first sending module 402, if no consensus proposal initiated by the master node is received within a preset timeout period, broadcasts a timeout message to other slave nodes, and collects the timeout messages broadcasted by the other slave nodes; wherein the timeout message includes a node identifier of the master node;

[0227] A first generating module 403, in response to collecting a Quorum of the timeout messages, generates a certificate indicating that the master node has crashed based on the collected Quorum of the timeout messages;

[0228] The second sending module 404 broadcasts the proof to other slave nodes so that the other consensus nodes verify the validity of the proof, and after the proof passes the validity verification, removes the master node from the list of consensus nodes participating in the consensus, and continues consensus processing based on the consensus nodes in the consensus node list from which the master node has been removed.

[0229] like Figure 5 As shown, Figure 5 This is a block diagram of another consensus device in a blockchain system according to an exemplary embodiment of the present specification. The device can also be applied to Figure 3 In the electronic device shown, the technical solution of this specification is implemented. The consensus nodes participating in the consensus in the blockchain system 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:

[0230] The second determination module 501 determines whether a consensus proposal initiated by the master node is not received within a preset timeout period;

[0231] The third sending module 502, if the consensus proposal initiated by the master node is not received within a preset timeout period, broadcasts a timeout message to other slave nodes, and collects the timeout messages broadcasted by the other slave nodes; wherein the timeout message includes the node identifier of the master node;

[0232] The second generation module 503, in response to collecting the Quorum of the timeout messages, generates a certificate indicating that the master node has crashed based on the collected Quorum of the timeout messages, and calls the exception handling logic included in the smart contract based on the generated certificate to verify the validity of the certificate, and after the certificate passes the validity verification, removes the master node from the consensus node list maintained by the smart contract;

[0233] The consensus module 504 continues to perform consensus processing based on the consensus nodes in the consensus node list from which the master node has been removed.

[0234] Accordingly, the present specification also provides an electronic device, which includes a processor; a memory for storing instructions executable by the processor; wherein the processor is configured to implement the steps in all the method flows described above.

[0235] Accordingly, the present specification also provides a computer-readable storage medium on which executable computer program instructions are stored; wherein, when the instructions are executed by a processor, the steps in all the method flows described above are implemented.

[0236] Accordingly, the present 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, the steps in all the method flows described above are implemented.

[0237] In the 1990s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the method flow). However, with the development of technology, many improvements to the method flow today can be regarded as direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, 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, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0238] The controller can be implemented in any appropriate manner, for example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) that can be executed by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in a purely computer-readable program code manner, the controller can be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be regarded as structures within the hardware component. Or even, the devices for implementing various functions can be regarded as both software modules for implementing the method and structures within the hardware component.

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

[0240] Although one or more embodiments of the present specification provide method operation steps as described in the embodiments or flow charts, more or less operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps, and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "include", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such a process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any specific order.

[0241] For the convenience of description, the above devices are described in various modules according to their functions. Of course, when implementing one or more of the present specification, the functions of each module can be implemented in the same or more software and / or hardware, or the module implementing the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0243] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0244] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

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

[0246] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0247] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. 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 technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0248] It should be understood by those skilled in the art that one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present 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.

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

[0250] Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the description of the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples without contradiction.

[0251] The above description is only an example of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. For those skilled in the art, one or more embodiments of this specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in 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 a plurality of slave nodes; 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 is not received within a preset timeout period; If the consensus proposal initiated by the master node is not received within the preset timeout period, a timeout message is broadcast to other slave nodes, and the timeout messages broadcasted by other slave nodes are collected; wherein the timeout message includes the node identifier of the master node; In response to collecting a Quorum of the timeout messages, generating a certificate indicating that the master node has crashed based on the collected Quorum of the timeout messages; The proof is broadcasted to other slave nodes so that the other slave nodes can verify the validity of the proof, and after the proof passes the validity verification, the master node is removed from the list of consensus nodes participating in the consensus, and consensus processing is continued based on the consensus nodes in the consensus node list from which the master node has been removed.

2. The method of claim 1, further comprising: Receive proof broadcasted by other slave nodes indicating that the master node has crashed; The proof is validated, and after the proof passes the validity verification, the master node is removed from the list of consensus nodes participating in the consensus, and consensus processing is continued based on the consensus nodes in the consensus node list from which the master node has been removed.

3. The method of claim 2, wherein the proof broadcast is sent to other slave nodes, comprising: Broadcasting the proof to other slave nodes based on a reliable broadcast protocol; Receive proofs broadcasted by other slave nodes, including: Receive proofs broadcasted by other slave nodes based on the reliable broadcast protocol in operation.

4. The method according to claim 2, wherein the proof is a set of digital signatures consisting of digital signatures contained in a quorum of the timeout messages collected; Generating a certificate indicating that an abnormality has occurred in the master node based on the collected Quorum timeout messages, including: Creating a digital signature set based on the digital signatures included in the collected Quorum timeout messages, as proof for indicating that an abnormality has occurred in the master node; Verify the validity of the certificate, including: Verifying the digital signatures included in the digital signature set; If at least a Quorum of digital signatures included in the digital signature set pass verification, it is determined that the proof passes validity verification.

5. The method of claim 1, continuing consensus processing based on the consensus nodes in the consensus node list from which the master node has been removed, comprises: A new master node is re-determined from the consensus node list from which the master node has been removed, and consensus messages are exchanged with other consensus nodes in the consensus node list to continue consensus processing on the consensus proposal initiated by the new master node.

6. The method according to claim 5, wherein the consensus protocol run by the consensus nodes in the blockchain system supports re-determining a new master node through explicit message interaction by other consensus nodes except the master node after the master node goes down; Re-determining a new master node from the consensus node list from which the master node has been removed includes: The message interaction is performed with other consensus nodes in the consensus node list from which the master node is removed, so as to re-elect a new master node from the consensus node list from which the master node is removed.

7. The method according to 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 is not received within a preset timeout period includes: Determine whether a Pre-Prepare message included in the PBFT protocol broadcasted by the master node is not received within a preset timeout period; Re-determining a new master node from the consensus node list from which the master node has been removed includes: The view change process of the PBFT protocol is triggered, and View-Change messages and New-View messages are interacted with other consensus nodes in the consensus node list from which the master node is removed, so as to re-elect a new master node from the consensus node list from which the master node is removed.

8. The method as claimed in claim 5, wherein the consensus protocol run by the consensus nodes in the blockchain system supports implicitly executing a unified master node determination rule on other consensus nodes except the master node after the master node goes down, so as to re-determine a new master node; Re-determining a new master node from the consensus node list from which the master node has been removed includes: The unified master node determination rule is executed to re-determine a new master node from the consensus node list from which the master node has been removed.

9. The method according to 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 is not received within a preset timeout period includes: Determine whether the prepare message included in the HotStuff protocol broadcasted by the master node is not received within a preset timeout period; Re-determining a new master node from the consensus node list from which the master node has been removed includes: Triggering the view switch of the HotStuff protocol, switching the current round of consensus to a new round of consensus, and executing the unified master node determination rule, re-determining a new master node for the new round of consensus from the consensus node list from which the master node has been removed.

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 a plurality of 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, and the method includes: Determining whether a consensus proposal initiated by the master node is not received within a preset timeout period; If the consensus proposal initiated by the master node is not received within the preset timeout period, a timeout message is broadcast to other slave nodes, and the timeout messages broadcasted by other slave nodes are collected; wherein the timeout message includes the node identifier of the master node; In response to collecting a Quorum of the timeout messages, generating a certificate indicating that the master node has crashed based on the collected Quorum of the timeout messages, calling the exception handling logic included in the smart contract based on the generated certificate, verifying the validity of the certificate, and after the certificate passes the validity verification, removing the master node from the consensus node list maintained by the smart contract; Continue consensus processing based on the consensus nodes in the consensus node list from which the master node has been 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 a plurality of slave nodes; The device is applied to any slave node in the blockchain system, and the device includes: A first determination module determines whether a consensus proposal initiated by the master node is not received within a preset timeout period; The first sending module, if the consensus proposal initiated by the master node is not received within a preset timeout period, broadcasts a timeout message to other slave nodes, and collects the timeout messages broadcasted by the other slave nodes; wherein the timeout message includes the node identifier of the master node; A first generating module, in response to collecting a Quorum of the timeout messages, generates a certificate indicating that the master node has crashed based on the collected Quorum of the timeout messages; The second sending module broadcasts the proof to other slave nodes so that the other consensus nodes verify the validity of the proof, and after the proof passes the validity verification, removes the master node from the list of consensus nodes participating in the consensus, and continues consensus processing based on the consensus nodes in the consensus node list from which the master node has been removed.

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 a plurality of 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 device is applied to any slave node in the blockchain system, and the device includes: A second determination module determines whether a consensus proposal initiated by the master node is not received within a preset timeout period; The third sending module, if the consensus proposal initiated by the master node is not received within a preset timeout period, broadcasts a timeout message to other slave nodes, and collects the timeout messages broadcasted by the other slave nodes; wherein the timeout message includes the node identifier of the master node; A second generation module, in response to collecting a Quorum of the timeout messages, generates a certificate indicating that the master node has crashed based on the collected Quorum of the timeout messages, and calls the exception handling logic included in the smart contract based on the generated certificate to verify the validity of the certificate, and after the certificate passes the validity verification, removes the master node from the consensus node list maintained by the smart contract; The consensus module continues to perform consensus processing based on the consensus nodes in the consensus node list from which the master node has been 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, the steps of the method according to any one of claims 1 to 10 are implemented.

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

15. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.

Images