Blockchain consensus method, node equipment, system and storage medium

Abstract

The embodiment of the present application provides a consensus method, node device, system and storage medium of a blockchain, receiving a first confirmation message sent by other nodes, wherein the first confirmation message is obtained by other nodes according to a first request message, determining the nodes in the new blockchain system according to the first confirmation message, and generating a second request message according to the nodes in the new blockchain system, and sending the second request message to other nodes, so that other nodes update the identifiers of the nodes stored in the local consensus node list. This scheme updates the consensus node list according to the nodes in the new blockchain system, so that the new block system after partitioning continues to reach consensus, realizes rapid recovery of consensus after a failure, and avoids the occurrence of a single node completing consensus, thereby improving the credibility of the blockchain system.

Description

Technical Field

[0001] The embodiments of the present application relate to the fields of financial technology (Fintech) and blockchain technology, and in particular to a consensus method, node device, system and storage medium of a blockchain. Background Art

[0002] Blockchain is a decentralized distributed ledger system. As a part of blockchain technology, the consensus mechanism can ensure that the latest blocks are accurately added to the blockchain, and that the blockchain information stored by the nodes is consistent and not forked, and can even resist malicious attacks.

[0003] In the prior art, nodes in a blockchain network verify the generated new blocks. After completing the verification of the new blocks, each node needs to broadcast the verification results to other nodes in the blockchain network. Each node can determine the validity of the new block only after receiving the verification results from other nodes, and then reach a consensus. When the blockchain network is partitioned due to network communication failure, the success rate of reaching consensus is reduced. When encountering the above problem, the prior art usually generates and sends multiple verification results by one node, and then determines whether a consensus is reached based on the number of verification results to improve the success rate of consensus.

[0004] However, in the existing technology, it is easy for a single node to complete consensus, resulting in a decrease in the credibility of the blockchain. Summary of the invention

[0005] The embodiments of the present application provide a consensus method, node device, system and storage medium of a blockchain to improve the consensus success rate of the blockchain system when there is a network communication failure and ensure the credibility of the blockchain system.

[0006] In a first aspect, the present application provides a blockchain consensus method, which is applied to a master node, and the method includes:

[0007] Receiving a first confirmation message sent by other nodes, wherein the first confirmation message is obtained by the other nodes according to the first request message;

[0008] Determine a node in the new blockchain system according to the first confirmation message, and generate a second request message according to the node in the new blockchain system;

[0009] A second request message is sent to other nodes so that other nodes update the identifiers of the nodes in the consensus node list stored locally.

[0010] Optionally, a second request message is generated according to a node in the new blockchain system, specifically including:

[0011] Counting a first number of first confirmation messages;

[0012] When it is determined that the ratio of the first number to the total number of nodes in the new blockchain system meets the preset master node condition, a second request message is generated according to the nodes in the new blockchain system.

[0013] Optionally, counting the first number of first confirmation messages specifically includes:

[0014] After sending the first request message to other nodes, generating a first start signal, wherein the first start signal is used to start a first timer;

[0015] When an expiration signal of the first timer is obtained, a first number of first confirmation messages is counted.

[0016] Optionally, before receiving the first confirmation message sent by other nodes, the method further includes:

[0017] Get the first round of values ​​and neighbor node identifiers stored locally;

[0018] Generate a first request message according to the first round value, the identifier of the neighbor node and the identifier of the master node;

[0019] A first request message is sent to other nodes.

[0020] Optionally, sending the first request message to other nodes specifically includes:

[0021] Obtaining state data of a locally stored blockchain, wherein the state data includes an update time of block data in the blockchain or an update time of view data of the blockchain;

[0022] When the state data indicates that the blockchain is in an abnormal state, generating a second start signal, wherein the second start signal is used to start a second timer;

[0023] When the expiration signal of the second timer is obtained, a first request message is sent to other nodes.

[0024] In the second aspect, the present application provides a blockchain consensus method, which is applied to other nodes, and the method includes:

[0025] Receiving a first request message sent by the master node;

[0026] Processing the first request message to generate a first confirmation message;

[0027] Sending a first confirmation message to the master node, so that the master node determines the node in the new blockchain system according to the first confirmation message, and generates and sends a second request message according to the node in the new blockchain system;

[0028] Update the node identifier in the locally stored consensus node list according to the second request message sent by the master node.

[0029] Optionally, performing verification processing on the first request message to obtain the first confirmation message specifically includes:

[0030] Obtain a first timing state of a first timer and a first round value in a first request message;

[0031] Compare the first round value with the second round value stored locally to obtain a comparison result;

[0032] A first confirmation message is generated according to the first timing state and the comparison result.

[0033] Optionally, determining whether to generate a first confirmation message according to the first timing state and the comparison result specifically includes:

[0034] If the first timing state indicates that timing is in progress, and the comparison result indicates that the first round value is greater than or equal to the second round value, a first confirmation message is generated;

[0035] If the first timing state indicates that timing is stopped, and the comparison result indicates that the first round value is greater than the second round value, a first confirmation message is generated.

[0036] Optionally, after obtaining a comparison result of the first round value and the second round value stored locally, the method further includes:

[0037] If the comparison result indicates that the first round value is greater than or equal to the second round value, update the second round value with the first round value; and / or

[0038] If the comparison result indicates that the first round value is greater than or equal to the second round value, the identifier of the node that generates the first request message is stored locally.

[0039] Optionally, generating a first confirmation message specifically includes:

[0040] Compare the identifier of the first neighbor node with the identifier of the second neighbor node stored locally to obtain the identifier of the newly added neighbor node;

[0041] A first confirmation message is generated according to the identifier of the newly added neighbor node, the first round value, and the identifier of the node that generates the first request message.

[0042] Optionally, after verifying the first request message to obtain the first confirmation message, the method further includes:

[0043] Send a first request message to the newly added neighbor node.

[0044] Optionally, updating the identifier of the node in the locally stored consensus node list according to the second request message specifically includes:

[0045] Decrypt the second request message according to the public key of the master node to obtain the first round value and the nodes in the new blockchain system;

[0046] When the second round value is equal to the first round value, a second confirmation message is generated.

[0047] Receive a second confirmation message sent by other nodes and the master node;

[0048] When the number of second confirmation messages meets the preset consensus condition, the identifiers of the nodes in the locally stored consensus node list are updated according to the nodes in the new blockchain system.

[0049] In a third aspect, the present application provides a node device, including:

[0050] Memory, used to store programs;

[0051] A processor is used to execute a program stored in a memory. When the program is executed, the processor is used to execute the consensus method of the blockchain involved in the first aspect and the optional scheme.

[0052] In a fourth aspect, the present application provides a node device, including:

[0053] Memory, used to store programs;

[0054] A processor is used to execute a program stored in a memory. When the program is executed, the processor is used to execute the consensus method of the blockchain involved in the second aspect and the optional solution.

[0055] In a fifth aspect, the present application provides a blockchain system, including the master node involved in the third aspect and the other nodes involved in the fourth aspect.

[0056] In a sixth aspect, the present application provides a computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are executed by a processor, they are used to implement the consensus method of the blockchain involved in the first aspect and the optional scheme.

[0057] The embodiment of the present application provides a consensus method, node device, system and storage medium of a blockchain. When a network communication failure occurs in a blockchain system, resulting in system partition, at least one blockchain system in the formed new blockchain system can meet the consensus condition, that is, the number of Byzantine nodes f satisfies 2f+1≤n, and n represents the total number of nodes in the new blockchain system. In the present application, the main consensus node sends a first request message to other nodes, and the other nodes verify the first request message to generate a first confirmation message, and send the first confirmation message to the main node. So that the main node determines the nodes in the new blockchain system according to the first confirmation message, and generates a second request message according to the nodes in the new blockchain system. The main node then sends a second request message to other nodes so that other nodes update the identifiers of the nodes stored in the local consensus node list. That is, the consensus node list is updated according to the nodes in the new blockchain system, so that the new block system after partitioning continues to reach a consensus, and quickly recovers the consensus after a failure, and avoids the occurrence of a single node completing the consensus, thereby improving the credibility of the blockchain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] Figure 1 A schematic diagram of the structure of a blockchain system provided in one embodiment of the present application;

[0059] Figure 2 A schematic diagram of a blockchain consensus method provided by another embodiment of the present application;

[0060] Figure 3 A schematic diagram of partitioning of a blockchain system provided in another embodiment of the present application;

[0061] Figure 4 A schematic diagram of the principle of electing a master node according to another embodiment of the present application;

[0062] Figure 5 A schematic diagram of the structure of a consensus device provided in another embodiment of the present application;

[0063] Figure 6 A schematic diagram of the structure of a consensus device provided in another embodiment of the present application;

[0064] Figure 7 A schematic diagram of the structure of a consensus node provided in another embodiment of the present application. DETAILED DESCRIPTION

[0065] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0066] Blockchain is a distributed storage system that is maintained and trusted by multiple nodes. The bottom layer of blockchain is a chain composed of a series of blocks. In addition to recording the data of the current block, each block also records the hash value of the previous block, forming a chain data structure in this way. A block consists of a block header and a block body. The block header defines important fields such as the block height and the hash value of the previous block, while the block body mainly stores transaction data. Blockchain uses cryptography to ensure the security of data transmission and access, and uses a chain structure to ensure that the data on the chain cannot be tampered with.

[0067] like Figure 1 As shown, the blockchain system provided by an embodiment of the present application includes multiple node servers 102 and terminal devices 101. The node server 102 is a node in the blockchain system. The node has a complete copy of the ledger and has the ability to participate in the blockchain consensus and maintain the ledger.

[0068] The terminal device 101 is a user terminal and can be any one of a mobile phone, a tablet computer, a laptop computer, a PDA, a mobile Internet device (Mobile Internet Device, MID for short), a wearable device, and the like.

[0069] When transaction data needs to be uploaded to the blockchain system, a request is made to the blockchain system to package the uploaded data into block data and write it into the blockchain. After the terminal device uploads data to the blockchain network, a node that packages the transaction data into new block data can be selected from the blockchain network. The node that packages the transaction data into new block data is called the master node, and the other nodes are called replica nodes.

[0070] New block data needs to be added to the blockchain after consensus. After the master node generates new block data, it needs to broadcast the new block data to the rest of the nodes in the blockchain system so that each node can verify the new block.

[0071] Taking the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm as an example, nodes can be further divided into Byzantine nodes and non-Byzantine nodes according to whether they are malicious nodes. Byzantine nodes refer to malicious nodes and cannot participate in consensus normally. Non-Byzantine nodes are honest nodes and can participate in consensus normally. When the total number of nodes in the blockchain system is 3f+1 and the number of non-Byzantine nodes reaches 2f+1, the blockchain system can reach a normal consensus. When the number of Byzantine nodes exceeds f, the blockchain system cannot reach a normal consensus. In other words, the maximum number of fault-tolerant nodes of a blockchain using the PBFT consensus algorithm is f. If the blockchain system is partitioned due to network failure, and the number of node servers in a faulty state exceeds f, the blockchain will not be able to reach a consensus.

[0072] The existing technology mainly generates multiple verification results by a single node, and then determines whether a consensus is reached based on the number of verification results to improve the consensus success rate. However, in the existing technology, it is easy for a single node to complete the consensus, resulting in a decrease in the credibility of the blockchain.

[0073] The embodiment of the present application provides a consensus method, node device, system and storage medium of a blockchain, which is intended to improve the consensus success rate of the blockchain system when there is a network communication failure and ensure the credibility of the blockchain system. The inventive concept of the present application is: when there is a network communication anomaly in the blockchain, the blockchain system is partitioned, that is, a blockchain is divided into multiple blockchains, and at least one of the new blockchains formed meets the consensus condition, that is, the number of Byzantine nodes f satisfies 2f+1≤n, and n represents the total number of nodes in the new blockchain system. When a system partition occurs, the nodes in the new blockchain system are determined, and then the nodes in the consensus node list stored by each node are updated according to the nodes in the new blockchain system, so that the new blockchain system continues to reach consensus, improves the consensus success rate, and can avoid the problem of a single node completing consensus in the prior art, and ensure the credibility of the blockchain.

[0074] like Figure 2 As shown, another embodiment of the present application provides a consensus method of blockchain, which is applied to a blockchain system and includes the following steps:

[0075] S201. The master node sends a first request message to other nodes.

[0076] The first request message is used to obtain the nodes of the new blockchain system after the original blockchain system is partitioned, and is also used to determine the master node in the new blockchain system. The first request message includes the identifier of the neighbor node of the master node, the first round value stored in the master node, and the identifier of the master node.

[0077] The master node stores the first round value, which is initially 0. Each time a request message is sent, the first round value increases accordingly. The master node determines the identification information of the neighbor node based on the network connection with other nodes. The neighbor node's identification, the first round value, and the master node's identification are then signed to generate the first request message.

[0078] Other nodes also store the second round value locally, and the initial value of the second round value is also 0. Before the master node is determined in the new blockchain system after partitioning, other nodes will also send the first request message to nodes other than themselves to strive to become the master node. Each time other nodes send a request message, the second round value will increase accordingly.

[0079] The following is an example: Figure 3 As shown, the original blockchain system I includes seven node servers, marked as node A to node G in sequence. Each node in the network can receive / send verification results of new blocks from other nodes, and the entire blockchain system reaches normal consensus.

[0080] A network communication failure occurs between nodes C and E, and a network communication failure occurs between nodes D and F, causing the original blockchain system to be divided into two new blockchain systems, marked as blockchain system II and blockchain system III. Blockchain system II includes nodes A, B, C, and D, and blockchain system III includes nodes E, F, and G. Assume that the new blockchain system II can continue to reach consensus after the partition.

[0081] Node A, Node B, Node C, and Node D all store round values, and the initial values ​​of the round values ​​in the four nodes are all 0. Node A is used as the master node, and the round value stored in Node A is recorded as the first round value. Node B, Node C, and Node D are other nodes, and the round values ​​stored in them are recorded as the second round values.

[0082] The neighbor nodes of the master node A include node B and node C, and the identifiers of the neighbor nodes are the identifier of node B and the identifier of node C. The first request message includes the identifier of node B, the identifier of node C, the first round value of 0, and the identifier of node A.

[0083] S202: Other nodes process the first request message to obtain a first confirmation message.

[0084] The processing of the first request message specifically includes parsing the first confirmation message to obtain the first round value, and then comparing the first round value with the second round value stored locally to obtain a comparison result. When the first round value is higher than or equal to the second round value, the other nodes determine the neighbor nodes of the other nodes based on the nodes with which they have network connections, and then generate the first confirmation message based on the neighbor nodes of the other nodes.

[0085] Continue with Figure 3 Taking the new blockchain system II shown as an example, after node B receives the first request message sent by node A, node B parses the first request message to obtain the first round value stored by node A, and node B compares the second round value stored locally with the first round value of node A. After determining that the first round value of node A is higher than or equal to the second round value of node B, node B obtains its own neighbor nodes, namely node A and node D, and signs the identifier of node A and the identifier of node D to generate a first confirmation message.

[0086] When node C or node B receives the first request message, it will also forward the first request message to node D. Node D and node C process the first request message in the same way as node D, which will not be repeated here.

[0087] S203: The master node receives a first confirmation message sent by other nodes.

[0088] S204. The master node determines a node in the new blockchain system according to the first confirmation message, and generates a second request message according to the identifier of the node in the new blockchain system.

[0089] The master node parses the first confirmation message to obtain neighbor nodes of other nodes, and the neighbor nodes of other nodes and the neighbor nodes of the master node constitute the node after the system partitions. Then the identifier of the node after the system partitions is signed to generate a second request message.

[0090] Continue with Figure 3 Taking the new blockchain system II shown as an example, after node A receives the first confirmation message sent by node B, node C and node D, it means that node A is elected as the main node by node B, node C and node D, then node A generates a second request message.

[0091] Node A parses the second request message sent by node B, node C and node D, obtains the neighbor nodes of node B, node C and node D, and then determines that the new blockchain system II includes node A, node B, node C and node D, and then generates a second request message according to the identifiers of all nodes in the new blockchain system II.

[0092] S205. The master node sends a second request message to other nodes.

[0093] S206. Other nodes update the identifiers of the nodes in the local consensus node list according to the second request message.

[0094] Among them, updating the node identification in the consensus node list specifically includes the following process: parsing the second request message to obtain all nodes of the new blockchain system after the system partition, and using all nodes of the new blockchain system after the system partition to update the node identification stored in the local consensus node list.

[0095] After the blockchain system is partitioned, at least one of the multiple new blockchain systems can continue to reach consensus. By using all nodes in the new blockchain system after the system is partitioned to update the node identifiers in the consensus node list, the new blockchain system can continue to reach consensus after the system is partitioned.

[0096] Continue with Figure 3 Taking the new blockchain system II shown as an example, the consensus nodes in the original consensus list of node B include seven nodes: node A, node B, node C, node D, node E, node F to node G. After node B receives the second request message, the consensus nodes in the consensus list are updated to four nodes: node A, node B, node C and node D, and the new blockchain system II can continue to reach consensus.

[0097] The following explains the principle that after a blockchain system is partitioned and multiple new blockchain systems are formed, at least one blockchain system can continue to reach consensus:

[0098] There is the following proposition: Let the total number of nodes in the original blockchain system be n, the number of Byzantine nodes be f, and the original blockchain system can normally perform PBFT consensus, satisfying the relationship 3f+1≤n. When partitions appear in the original blockchain system, k new blockchain systems that are not connected to each other are formed, where 2≤k≤n.

[0099] It needs to be proved that there is at least one new blockchain system with a total number of nodes n i and the number of Byzantine nodes f i , satisfying the relation 3f i +1≤n i , where 1≤i≤k.

[0100] The proof process is as follows: Assuming that the new blockchain systems formed after partitioning do not satisfy the above relationship, then for any i, there are 3f i +1>n i .

[0101] There exists an m i ≥1, satisfying the following formula (1):

[0102] 3f i +1=n i +m i (1)

[0103] Summing formula (1) yields the following formula (2):

[0104]

[0105] Transforming formula (2) to obtain formula (3)

[0106]

[0107] There is also a relationship between formula (4) and formula (5),

[0108]

[0109]

[0110] The following formula (6) can be derived:

[0111]

[0112] And m i ≥1, that is, 3f≥n, and the condition 3f+1≤n, the two contradict each other, and the above proposition is proved.

[0113] In the blockchain consensus method provided in the embodiment of the present application, when a blockchain system is partitioned to form a new blockchain system, the nodes in the new blockchain system after the partition are obtained, and then the consensus node list of each node in the new blockchain system after the partition is updated according to the nodes in the new blockchain system, so that the new blockchain system can continue to reach consensus, improve the consensus success rate, and avoid the problem of a single node completing consensus in the prior art, thereby ensuring the credibility of the blockchain.

[0114] Another embodiment of the present application provides a consensus method of blockchain, which is applied to a blockchain system and includes the following steps:

[0115] S301. The master node sends a first request message to other nodes.

[0116] Wherein, a first timer and a second timer are set in the master node, the first timer is used to trigger the master node to count the first confirmation message, and the second timer is used to trigger the master node to send the first request message.

[0117] The master node obtains the status data of the blockchain stored locally, and the status data of the blockchain is used to indicate whether the blockchain is producing blocks normally. The status data includes the update time of the block data in the blockchain or the update time of the view data of the blockchain.

[0118] When the time interval between the update time of the block data in the blockchain and the current time exceeds the preset time length, or the time interval between the update time of the view data of the blockchain and the current time exceeds the preset time length, it indicates that an abnormality has occurred in the blockchain block generation.

[0119] When the state data indicates that the blockchain is in an abnormal state, a second start signal is generated. The second start signal is used to start a second timer. When an expiration signal of the second timer is obtained, a first request message is sent to other nodes.

[0120] The first request message is used to determine the nodes in the new blockchain after the partition in the blockchain, and is also used to determine the master node. That is, before the master node of the new blockchain is determined, each node will send the first request message, and each node is equipped with a second timer to trigger the sending of the first request message. The start condition of each second timer is also the status data of the blockchain indicating that the blockchain cannot produce blocks normally.

[0121] The process of generating the first request message has been described in detail in the previous embodiment and will not be repeated here.

[0122] Continue with Figure 3 Taking the new blockchain system II as an example, timer 1 and timer 2 are provided in nodes A to D. Timer 2 is used to trigger the node where the timer is located to generate the first sending request information. Timer 1 triggers the node where the timer is located to count the first confirmation information.

[0123] Node A is running for the master node. Node A continuously monitors the status data of the original blockchain system, for example, whether the update time of the block data is too long or whether the update time of the view data is in progress. When it is determined that the status data of the original blockchain system indicates an abnormality, Node A generates a signal to trigger Timer 2, Timer 2 stops timing, and sends a first request message to Node B, Node C, and Node D. The process of generating the first request message has been described and will not be repeated here.

[0124] S302: Other nodes send a first request message to the newly added neighbor node.

[0125] The newly added neighbor nodes are obtained by comparing the neighbor nodes of the other nodes with the neighbor nodes of the main node. The other nodes mark their own neighbor nodes as second neighbor nodes and mark the neighbor identifier of the main node as the first neighbor node.

[0126] For each second neighbor node identifier, the identifier of the first neighbor node in the first request message is compared with the identifier of the second neighbor node to determine the identifier of the newly added neighbor node. In other words, it is determined whether there is a first neighbor node with the same identifier as the second neighbor node. If not, the identifier of the second neighbor node is used as the newly added neighbor node.

[0127] For the neighbor nodes common to the master node and other nodes, the first request message sent by the master node has been received, and other nodes only need to send the first request message to the newly added neighbor nodes.

[0128] Continue with Figure 3 Taking the new blockchain system II as an example, node A is running for the master node, and node B is another node. The first neighbor nodes of node A include node B and node C, and the second neighbor nodes of node B include node C and node D. The second neighbor node D is not a neighbor node of node A, and node D is a newly added node of node B.

[0129] S303: Other nodes verify the first request message to obtain a first confirmation message.

[0130] Wherein, obtaining the first confirmation message specifically includes: obtaining the first timing state of the first timer and the first round value in the first request message, and comparing the first round value in the first request message with the second round value stored locally to obtain a comparison result. The first confirmation message is generated according to the first timing state and the comparison result.

[0131] like Figure 4 As shown, determining to generate a first confirmation message according to the first timing state and the comparison result specifically includes:

[0132] S3001, other nodes obtain the first timing state of the local first timer, and determine whether the first timing state indicates that timing is in progress. If so, proceed to S3002, otherwise proceed to S3005.

[0133] S3002: If the first timing state indicates that timing is in progress, then continue to determine whether the comparison result indicates that the first round value is greater than or equal to the second round value. If so, proceed to S3003; otherwise, proceed to S3004.

[0134] S3003. If the comparison result indicates that the first round value is greater than or equal to the second round value, a first confirmation message is generated.

[0135] If the comparison result indicates that the first round value is greater than or equal to the second round value, the second round value is updated with the first round value, and / or the node generating the first request message is stored locally.

[0136] S3004. If the comparison result indicates that the first round value is smaller than the second round value, discard the first request message.

[0137] S3005: If the first timing state indicates that the timing is stopped, continue to determine whether the comparison result indicates that the first round value is greater than the second round value. If so, proceed to S3006; otherwise, proceed to S3007.

[0138] S3006. If the comparison result indicates that the first round value is greater than the second round value, generate a first confirmation message.

[0139] If the comparison result indicates that the first round value is greater than the second round value, the second round value is updated with the first round value, and / or the node generating the first request message is stored locally.

[0140] S3007. If the comparison result indicates that the first-round value is less than or equal to the second-round value, discard the first request message.

[0141] Preferably, in order to simplify the information in the first confirmation message, the identifier of the first neighbor node of the master node is compared with the identifier of the second neighbor node of the own node to obtain the newly added neighbor node. Among them, the process of obtaining the newly added neighbor node has been described in detail in S303 and will not be repeated here. Other nodes generate the first confirmation message according to the identifier of the newly added neighbor node, the first round value and the identifier of the node that generates the first request message.

[0142] Continue with Figure 3 Taking the new blockchain system II shown as an example, node A is running for the master node, and node B receives the first request information sent by node A. Node B determines whether its own timer No. 2 is timing. When node B confirms that timer No. 2 is timing, it parses the first request information to obtain the first round value stored in node A. Node B determines whether the first round value stored in node A is greater than or equal to the second round value stored locally. If so, node B generates the first confirmation information, and uses the first round value stored in node A to update the second round value stored locally, and stores the identifier of node A locally. No, node B discards the first confirmation information.

[0143] When Node B confirms that timer No. 2 has stopped timing, Node B parses the first request information to obtain the first round value stored in Node A. Node B determines whether the first round value stored in Node A is greater than the second round value stored locally. If so, Node B generates a first confirmation message, and uses the first round value stored in Node A to update the second round value stored locally, and stores the identifier of Node A locally. No, Node B discards the first confirmation message.

[0144] When node B generates the first confirmation information, it compares the neighbor nodes of node A with its own neighbor nodes to obtain the newly added node as node D. Node B generates the first confirmation information according to the identification information of node D, the identification information of node B and the first round of values.

[0145] The process of generating the first confirmation information by node C and node D is the same as that by node B, and will not be described again here.

[0146] S304: The master node receives a first confirmation message sent by other nodes.

[0147] S305. The master node determines the nodes in the new blockchain system according to the first confirmation message, and generates a second request message according to the nodes in the new blockchain system.

[0148] Wherein, after the master node sends the first request message to other nodes, a first start signal is generated. Wherein, the first start signal is used to start a first timer. When the expiration signal of the first timer is obtained, the first number of first confirmation messages is counted. When it is determined that the ratio of the first number to the total number of nodes in the new blockchain system meets the preset master node condition, a second request message is generated according to the nodes in the new blockchain system.

[0149] The preset master node condition includes that when the ratio of the first number to the total number of nodes in the new blockchain system exceeds one-half, the node is set as the master node. If multiple nodes meet the preset master node condition, any node can be randomly selected as the master node. After determining that the node is the master node, a second request message is generated according to the nodes in the new blockchain system.

[0150] Continue with Figure 3 Taking the new blockchain system II shown as an example, node A runs for the master node. After timer No. 1 of node A expires, the number of first confirmation messages received is counted. The total number of nodes in the new blockchain system is 4, that is, when the number of first confirmation messages exceeds 2, it is determined that node A has successfully run for the master node.

[0151] S306: The master node sends a second request message to other nodes.

[0152] S307. Other nodes update the identifiers of the nodes in the local consensus node list according to the second request message.

[0153] Among them, updating the identification of the node in the local consensus node list specifically includes the following process: decrypting the second request message according to the public key of the master node to obtain the first round value and the node in the new blockchain system. When the second round value is equal to the first round value, a second confirmation message is generated. Receiving the second confirmation message sent by other nodes except itself, when the number of second confirmation messages meets the preset consensus condition, updating the identification of the node in the locally stored consensus node list according to the node in the new blockchain system.

[0154] The preset consensus condition refers to the PBFT consensus condition being met, and the ratio of the number of second confirmation messages to the total number of nodes in the new blockchain is greater than (2f+1) / (3f+1), where f is the total number of Byzantine nodes.

[0155] Continue with Figure 3Taking the new blockchain system II as an example, node A successfully runs for the master node. Master node A sends a second request message to node B and node C, and node B or node C forwards the second request message to node D. Node B, node C and node D verify the second request message. Taking node B as an example, when node B generates the first confirmation message, it records the identification information of node A locally, that is, records node A as the master node. At the same time, the first round value of node A is also used to update the second round value stored locally. Node B determines the public key used to decrypt the second request message based on the master node identification stored locally, decrypts the second request message to obtain the first round value of node A, and compares the first round value of node A with the second round value stored locally. If they are determined to be the same, a second confirmation message can be generated. And send a second confirmation message to node A and node D, and node D or node A forwards the second confirmation message to node C. The process of generating the second confirmation message by node A, node C and node D is the same as that of node B, which will not be repeated here.

[0156] Node B counts the number of second confirmation messages received. When the number of second confirmation messages received by node B is greater than or equal to 3, the node identifier in the locally stored consensus node list is updated according to the node in the new blockchain system.

[0157] In the blockchain consensus method provided in the embodiment of the present application, the round value in the received first request message is compared with the locally stored round value to verify the first request message, and then the master node is elected. The master node then initiates a second request message to update the consensus node list of each node in the new blockchain system after partitioning, so that the new blockchain system after partitioning can continue to reach consensus without introducing a situation where a single node completes the consensus, thereby improving the credibility of the consensus.

[0158] The following is a specific example to illustrate the consensus method of blockchain provided by another embodiment of the present application.

[0159] Another embodiment of the present application provides a consensus method of blockchain, which is applied to a blockchain system and includes the following steps:

[0160] S401. The master node sends a first request message to other nodes.

[0161] When each node in the original blockchain system 1 determines that a consensus anomaly occurs in the blockchain system, that is, when the original blockchain system does not produce a block or the view cannot be switched normally, a start signal is generated to start the second timer. The time of the second timer is randomly set to between 0 and 5 seconds, and a round value with an initial value of 0 is stored inside the node.

[0162] When the second timer of a node expires, it sends a first request message to the neighboring node directly connected to the node. The first request message includes the round value recorded by itself and the identifier of the neighboring node of the node. After sending the first request message, the node starts the first timer, and the time is also randomly set to between 0 and 3 seconds.

[0163] The four nodes, Node A, Node B, Node C and Node D, detect the consensus anomaly at the same time, start the second timer, and set the timeout time of Node A, Node B, Node C and Node D to 2s, 2.1s, 3.5s and 3.8s respectively.

[0164] The second timer of node A expires first, and the node A sends a first request message to directly connected node B and node C. The first request message includes the first round value of 0, neighbor node B and neighbor node C. Node B, node C and node D send the first request message in sequence.

[0165] S402: Other nodes send a first request message to the newly added neighbor node.

[0166] S403: Other nodes verify the first request message to obtain a first confirmation message.

[0167] After receiving the first request message, other nodes compare the first round value in the first request message with the second round value stored locally.

[0168] Preferably, the first round value in the first request message is compared with the second round value stored locally, and it is confirmed whether the second timer stored locally has expired. If the second timer stored locally has not expired and the first round value is higher than or equal to the second round value, the following three operations are performed:

[0169] (1) Stop the second timer stored in the node to count. That is, the node no longer sends the first request message to other nodes in this round.

[0170] (2) Update the source node of the first request message and the second round value stored in the node.

[0171] (3) Generate a first confirmation message based on the newly added neighbor node and the first round value, and send the first confirmation message to the source node of the first request message. As a preferred solution, use the node private key to sign the first round value and the newly added neighbor identifier to generate the first confirmation message.

[0172] If the second timer stored locally has expired or been paused, and the first round value is higher than the second round value, perform operations (2) and (3). If the second timer stored locally has expired or been paused, and the first round value is lower than or equal to the second round value, discard the first request message.

[0173] Assume that the first request message of node A reaches node B and node C after 0.2s, at this time the timer of node B has expired, and when the second round value stored in node B is equal to the first round value in the first request message, node B discards the first request message.

[0174] At this time, the timer of node C has not expired yet, and it receives a message packet with the same number of rounds as its own record, and performs the following operations:

[0175] (1) Stop the second timer stored internally, that is, stop sending the first request message to other nodes, that is, node C will not be selected as the master node.

[0176] (2) Update the second round value stored locally to 0, and update the source node A of the first request message stored locally.

[0177] (3) The neighbor node identifiers stored in the first request message are nodes B and C, and the neighbor node identifiers stored locally are nodes A, B, and D. It is determined that the newly added neighbor node is D. The newly added neighbor node D and the round value are encrypted using the private key to generate a first confirmation message.

[0178] Node D receives the first request message sent by node A. The verification process is the same as that of node C. The first request message will not be sent to other nodes, that is, node D will not be selected as the main node. A first confirmation message will also be generated and forwarded to node A through node C.

[0179] The second timer in node B will not be suspended before expiration, that is, node B will send a first request message, and the round value of the first request message is also 0, but the second timer has been suspended at this time, and the round value sent by node B is not higher than the round value stored in node A, node C and node D. Node A, node C and node D discard the first request message, that is, node B will not receive the first confirmation message.

[0180] S404: The master node receives a first confirmation message sent by other nodes.

[0181] S405. The master node determines the nodes in the new blockchain system according to the first confirmation message, and generates a second request message according to the nodes in the new blockchain system.

[0182] Among them, for the node that has sent the first request message, the first confirmation message received before the expiration of the second timer and the total number of nodes in the new blockchain system are counted. And the ratio of the number of first confirmation messages to the total number of nodes in the new blockchain system is calculated. If the ratio meets the preset consensus condition, the node is selected as the master node. If multiple nodes meet the consensus condition, one node is selected as the master node from the multiple nodes. If no node meets the consensus condition, S201 is continued to be executed, and the round value is increased by 1.

[0183] Both node A and node B send the first request message. For node A, it can be statistically obtained that the new blockchain system III includes four nodes, its own node A, neighbor nodes B and C, node C feedback that it can connect to node D, and node C and node D are received at the same time, meeting the preset consensus conditions. Node A serves as the master node, and node B has not received any first confirmation message, and the authentication of the master node fails.

[0184] Assume that node A receives the first confirmation message from node C, node B receives the first confirmation message from node D, and the number of first confirmation messages received by node A and node B is less than half, the round number of each node is increased by 1, and S201 is continued.

[0185] S406: The master node sends a second request message to other nodes.

[0186] Among them, the master node generates a second request message as transaction data, which is sent to other nodes in the new blockchain system through the normal transaction process. The second request message includes the first round of values ​​stored inside the master node, the nodes of the new blockchain network, and the signature information of the node sending the first confirmation message.

[0187] S407. Other nodes update the identifiers of the nodes in the local consensus node list according to the second request message.

[0188] Among them, the public key corresponding to the source node of the first request message stored locally is used to decrypt the second request message, obtain the first round value stored inside the master node and the node of the new blockchain network, and then determine whether the first round value is the same as the second round value stored locally. If they are the same, a second verification result is generated and sent to other nodes except itself. The master node also generates a second verification result and sends the second verification result to other nodes.

[0189] After other nodes have counted and received a certain number of second verification results, that is, after other nodes have received only 3 second verification results, they can confirm that the second request message is valid, and use the nodes of the new blockchain network in the second request message to update the node identifiers in the locally stored consensus node list, that is, the consensus node list is updated from node A to node G to node A to node D. Only 3 verification results need to be received to reach a consensus. The consensus list of each node in the blockchain system II is negotiated and updated to function. The consensus nodes are updated from seven to four, and subsequent transactions and block verifications proceed normally.

[0190] The second request message sent by node A includes: the first round value with a value of 0, node A to node D, and the signatures of node A, node C, and node D. After nodes B, C, and D pass the verification, they update the consensus node lists recorded by each.

[0191] In the blockchain consensus method provided in the embodiment of the present application, when a blockchain system is partitioned to form a new blockchain system, the nodes in the new blockchain system after the partition are obtained, and then the consensus node list of each node in the new blockchain system after the partition is updated according to the nodes in the new blockchain system, so that the new blockchain system can continue to reach consensus, improve the consensus success rate, and avoid the problem of a single node completing consensus in the prior art, thereby ensuring the credibility of the blockchain.

[0192] like Figure 5 As shown, the present application provides a consensus device of blockchain, which is applied to a master node. The device 500 includes:

[0193] A first receiving module 501 is configured to receive a first confirmation message sent by other nodes, wherein the first confirmation message is obtained by the other nodes according to the first request message;

[0194] A first processing module 502, configured to determine a node in the new blockchain system according to the first confirmation message, and generate a second request message according to the node in the new blockchain system;

[0195] The first sending module 503 is used to send a second request message to other nodes so that other nodes update the identifier of the node stored in the local consensus node list.

[0196] Optionally, the first processing module 502 is specifically configured to:

[0197] Counting a first number of first confirmation messages;

[0198] When it is determined that the ratio of the first number to the total number of nodes in the new blockchain system meets the preset master node condition, a second request message is generated according to the nodes in the new blockchain system.

[0199] Optionally, the first processing module 502 is specifically configured to:

[0200] After sending the first request message to other nodes, generating a first start signal, wherein the first start signal is used to start a first timer;

[0201] When an expiration signal of the first timer is obtained, a first number of first confirmation messages is counted.

[0202] Optionally, the first processing module 502 is further used to obtain the first round of values ​​and identifiers of neighboring nodes stored locally;

[0203] The first processing module 502 is further configured to generate a first request message according to the first round value, the identifier of the neighbor node and the identifier of the master node;

[0204] The first sending module 503 is further configured to send a first request message to other nodes.

[0205] Optionally, the first processing module 502 is further used to obtain state data of the blockchain stored locally, wherein the state data includes an update time of block data in the blockchain or an update time of view data of the blockchain;

[0206] The first processing module 502 is further configured to generate a second start signal when the state data indicates that the blockchain is in an abnormal state, wherein the second start signal is used to start a second timer;

[0207] The first sending module 503 is further configured to send a first request message to other nodes when obtaining an expiration signal of the second timer.

[0208] like Figure 6 As shown, the present application provides a consensus device 600 of a blockchain, which is applied to other nodes. The device 600 includes:

[0209] The second receiving module 601 is used to receive a first request message sent by the master node;

[0210] The second processing module 602 is used to process the first request message to generate a first confirmation message;

[0211] The second sending module 603 is used to send a first confirmation message to the master node, so that the master node determines the node in the new blockchain system according to the first confirmation message, and generates and sends a second request message according to the node in the new blockchain system;

[0212] The second processing module 602 is further used to update the identifier of the node in the locally stored consensus node list according to the second request message of the master node.

[0213] Optionally, the second processing module 602 is specifically configured to:

[0214] Obtaining a first timing state of a first timer and a first round value in a first confirmation message;

[0215] Compare the first round value with the second round value stored locally to obtain a comparison result;

[0216] A first confirmation message is generated according to the first timing state and the comparison result.

[0217] Optionally, the second processing module 602 is specifically configured to:

[0218] If the first timing state indicates that timing is in progress, and the comparison result indicates that the first round value is greater than or equal to the second round value, a first confirmation message is generated;

[0219] If the first timing state indicates that timing is stopped, and the comparison result indicates that the first round value is greater than the second round value, a first confirmation message is generated.

[0220] Optionally, the second processing module 602 is further configured to:

[0221] If the comparison result indicates that the first round value is greater than or equal to the second round value, update the second round value with the first round value; and / or

[0222] If the comparison result indicates that the first round value is greater than or equal to the second round value, the identifier of the node that generates the first request message is stored locally.

[0223] Optionally, the second processing module 602 is further configured to:

[0224] Compare the identifier of the first neighbor node with the identifier of the second neighbor node stored locally to obtain the identifier of the newly added neighbor node;

[0225] A first confirmation message is generated according to the identifier of the newly added neighbor node, the first round value, and the identifier of the node that generates the first request message.

[0226] Optionally, the second sending module 603 is further used for:

[0227] Send a first request message to the newly added neighbor node.

[0228] Optionally, the second processing module 602 is further configured to:

[0229] Decrypt the second request message according to the public key of the master node to obtain the first round value and the nodes in the new blockchain system;

[0230] When the second round value is equal to the first round value, a second confirmation message is generated.

[0231] Receive a second confirmation message sent by other nodes and the master node;

[0232] When the number of second confirmation messages meets the preset consensus condition, the identifiers of the nodes in the locally stored consensus node list are updated according to the nodes in the new blockchain system.

[0233] like Figure 7 As shown, a node device 700 provided in another embodiment of the present application includes: a transmitter 701, a receiver 702, a memory 703 and a processor 704.

[0234] A transmitter 701, used for sending instructions and data;

[0235] Receiver 702, for receiving instructions and data;

[0236] Memory 703, used to store computer-executable instructions;

[0237] The processor 704 is used to execute the computer-executable instructions stored in the memory to implement the various steps performed by the consensus method of the blockchain in the above embodiment. For details, please refer to the relevant description in the above blockchain consensus method embodiment.

[0238] Optionally, the memory 703 can be independent or integrated with the processor 704. When the memory 703 is independently provided, the node device further includes a bus for connecting the memory 703 and the processor 704.

[0239] Another embodiment of the present application provides a blockchain system, comprising a plurality of consensus nodes, wherein each consensus node comprises a memory and a server;

[0240] Memory, used to store programs;

[0241] The processor is used to execute the program stored in the memory. When the program is executed, the processor is used to execute the consensus method of the blockchain executed by the above-mentioned node device.

[0242] Another embodiment of the present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When the processor executes the computer-executable instructions, the consensus method of the blockchain executed by the above-mentioned node device is implemented.

[0243] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0244] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A consensus method for blockchain, characterized in that: Applied to the master node, the methods include: Receive a first confirmation message sent by other nodes, wherein the generation process of the first confirmation message includes: the other node obtains a first timing state of a first timer and a first round value in a first request message; compares the first round value with a second round value stored locally to generate a comparison result; when the first timing state indicates that timing is in progress and the comparison result indicates that the first round value is greater than or equal to the second round value, the first confirmation message is generated; or when the first timing state indicates that timing is stopped and the comparison result indicates that the first round value is greater than the second round value, the first confirmation message is generated; Determine, according to the first confirmation message, nodes in the new blockchain system after the system partition, and count a first number of the first confirmation messages; When it is determined that the ratio of the first number to the total number of nodes in the new blockchain system meets the preset master node condition, a second request message is generated according to the node in the new blockchain system; the preset master node condition includes that when the ratio of the first number to the total number of nodes in the new blockchain system exceeds one half, the node is set as the master node; Send a second request message to the other nodes, so that the other nodes execute: decrypt the second request message according to the public key of the master node to obtain the first round value and the nodes in the new blockchain system; generate a second confirmation message when the second round value is equal to the first round value; receive the second confirmation message sent by other nodes other than itself; when the number of the second confirmation messages meets the preset consensus condition, update the node identification in the locally stored consensus node list according to the nodes in the new blockchain system; the preset consensus condition refers to satisfying the PBFT consensus condition, and the ratio of the number of the second confirmation messages to the total number of nodes in the new blockchain is greater than ,in is the total number of Byzantine nodes.

2. The method according to claim 1, characterized in that Counting the first number of the first confirmation messages specifically includes: After sending the first request message to the other node, generating a first start signal, wherein the first start signal is used to start a first timer; When an expiration signal of the first timer is obtained, a first number of the first confirmation messages is counted.

3. The method according to any one of claims 1 to 2, characterized in that Before receiving the first confirmation message sent by other nodes, the method further includes: Get the first round of values ​​and neighbor node identifiers stored locally; Generate the first request message according to the first round value, the identifier of the neighbor node and the identifier of the master node; A first request message is sent to the other node.

4. The method according to claim 3, characterized in that: Sending a first request message to the other node specifically includes: Obtaining state data of a locally stored blockchain, wherein the state data includes an update time of block data in the blockchain or an update time of view data of the blockchain; When the state data indicates that the blockchain is in an abnormal state, generating a second start signal, wherein the second start signal is used to start a second timer; When the expiration signal of the second timer is obtained, a first request message is sent to the other node.

5. A consensus method for blockchain, characterized in that: Applied to other nodes except the master node, the method includes: Receiving a first request message sent by the master node; Obtain a first timing state of a first timer and a first round value in the first request message; Compare the first round value with the second round value stored locally to generate a comparison result; When the first timing state indicates that timing is in progress, and the comparison result indicates that the first round value is greater than or equal to the second round value, generating a first confirmation message; Alternatively, when the first timing state indicates that timing is stopped, and the comparison result indicates that the first round value is greater than the second round value, the first confirmation message is generated; Sending the first confirmation message to the master node, so that the master node determines the nodes in the new blockchain system according to the first confirmation message, and counts the first number of the first confirmation messages; when it is determined that the ratio of the first number to the total number of nodes in the new blockchain system meets the preset master node condition, generating and sending a second request message according to the nodes in the new blockchain system; the preset master node condition includes that when the ratio of the first number to the total number of nodes in the new blockchain system exceeds one half, the node is set as the master node; Decrypting the second request message according to the public key of the master node to obtain the first round value and the node in the new blockchain system; When the second round value is equal to the first round value, a second confirmation message is generated; Receiving the second confirmation message sent by other nodes except itself; When the number of the second confirmation messages meets the preset consensus condition, the identifier of the node in the locally stored consensus node list is updated according to the node in the new blockchain system; the preset consensus condition refers to satisfying the PBFT consensus condition, the ratio of the number of the second confirmation messages to the total number of nodes in the new blockchain is greater than ,in is the total number of Byzantine nodes.

6. The method according to claim 5, characterized in that After comparing the first round value with the locally stored second round value to generate a comparison result, the method further includes: If the comparison result indicates that the first round value is greater than or equal to the second round value, updating the second round value with the first round value; and / or If the comparison result indicates that the first round value is greater than or equal to the second round value, the identifier of the node that generates the first request message is stored locally.

7. The method according to claim 5, characterized in that Generating the first confirmation message specifically includes: Compare the identifier of the first neighbor node with the identifier of the second neighbor node stored locally to obtain the identifier of the newly added neighbor node; The first confirmation message is generated according to the identifier of the newly added neighbor node, the first round value, and the identifier of the node that generates the first request message.

8. The method according to claim 7, characterized in that After verifying the first request message to obtain a first confirmation message, the method further includes: Send the first request message to the newly added neighbor node.

9. A node device, characterized in that: include: Memory, used to store programs; A processor, configured to execute the program stored in the memory; when the program is executed, the processor is configured to execute the consensus method of the blockchain as described in any one of claims 1 to 4.

10. A node device, characterized in that: include: Memory, used to store programs; A processor, configured to execute the program stored in the memory; when the program is executed, the processor is configured to execute the consensus method of the blockchain as described in any one of claims 5 to 8.

11. A blockchain system, characterized in that: It comprises the master node as claimed in claim 9 and the other nodes as claimed in claim 10.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions; Wherein, when the computer-executable instructions are executed by the processor, they are used to implement the consensus method of the blockchain as described in any one of claims 1 to 4 or any one of 5 to 8.

Images