Block chain consensus method and device, computer equipment and storage medium

Abstract

The invention relates to a block chain consensus method and device, computer equipment, a storage medium and a computer program product. The method can be applied to the fields of block chains and smart transportation, and comprises the following steps: determining the block height of a to-be-consensus block in the block chain; determining an offset based on the block height and a preset block height threshold; determining a main node index value of the to-be-consensus block based on the offset, the number of consensus rounds of the to-be-consensus block and the number of nodes in the block chain; and when the main node index value of the to-be-consensus block is the same as the index value of the local node, broadcasting a proposal message of the to-be-consensus block to other nodes in the block chain, so that the other nodes consensus the to-be-consensus block based on a transaction task in the proposal message. By adopting the method, the consensus efficiency of the block chain can be effectively improved, and meanwhile, the processing performance of the whole block chain can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a blockchain consensus method, apparatus, computer device, storage medium, and computer program product. Background Art

[0002] Blockchain is a new decentralized distributed ledger technology that can safely store transactions or other data. The characteristics of the information stored on the blockchain are that it cannot be forged or tampered with. The blockchain consensus algorithm drives each node on the blockchain to participate in the transaction verification process, ensuring that transactions on the blockchain are confirmed and credible. The consensus algorithm is the core of a blockchain system. The purpose of the consensus algorithm is to reach a consensus on the block between nodes without forking.

[0003] However, in the current blockchain consensus method, due to network or node downtime or restart, some nodes in the blockchain network may crash or become abnormal. In this case, the traditional blockchain consensus process will poll and select abnormal nodes to become the master node, but abnormal nodes cannot generate proposals. Therefore, when the abnormal node becomes the master node, other nodes need to wait for a period of time before they can time out and cast empty votes, and then switch to the next node to become the master node. Although this ensures the continued operation of the consensus process, the performance of the blockchain is very low, which leads to low consensus efficiency of the entire blockchain. Summary of the invention

[0004] Based on this, it is necessary to provide a blockchain consensus method, device, computer equipment, computer-readable storage medium and computer program product to address the above-mentioned technical problems, which can effectively improve the consensus efficiency of the blockchain while improving the processing performance of the entire blockchain.

[0005] In the first aspect, the present application provides a blockchain consensus method. The method includes: determining the block height of a block to be consensus in a blockchain; determining an offset based on the block height and a preset block height threshold; determining a master node index value of the block to be consensus based on the offset, the number of consensus rounds of the block to be consensus, and the number of nodes in the blockchain; when the master node index value of the block to be consensus is the same as the index value of the local node, broadcasting a proposal message of the block to be consensus to other nodes in the blockchain, so that the other nodes reach a consensus on the block to be consensus based on the transaction tasks in the proposal message.

[0006] In the second aspect, the present application also provides a blockchain consensus device. The device includes: a determination module for determining the block height of the block to be consensus in the blockchain; determining the offset based on the block height and a preset block height threshold; determining the master node index value of the block to be consensus based on the offset, the number of consensus rounds of the block to be consensus and the number of nodes in the blockchain; a broadcast module for broadcasting the proposal message of the block to be consensus to other nodes in the blockchain when the master node index value of the block to be consensus is the same as the index value of the local node, so that the other nodes can reach a consensus on the block to be consensus based on the transaction tasks in the proposal message.

[0007] In a third aspect, the present application also provides a computer device. The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the following steps when executing the computer program: determining the block height of the block to be consensus in the blockchain; determining the offset based on the block height and a preset block height threshold; determining the master node index value of the block to be consensus based on the offset, the number of consensus rounds of the block to be consensus, and the number of nodes in the blockchain; when the master node index value of the block to be consensus is the same as the index value of the local node, broadcasting the proposal message of the block to be consensus to other nodes in the blockchain, so that the other nodes reach consensus on the block to be consensus based on the transaction tasks in the proposal message.

[0008] In a fourth aspect, the present application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the following steps are implemented: determining the block height of the block to be consensus in the blockchain; determining the offset based on the block height and a preset block height threshold; determining the master node index value of the block to be consensus based on the offset, the number of consensus rounds of the block to be consensus, and the number of nodes in the blockchain; when the master node index value of the block to be consensus is the same as the index value of the local node, broadcasting the proposal message of the block to be consensus to other nodes in the blockchain, so that the other nodes can reach a consensus on the block to be consensus based on the transaction tasks in the proposal message.

[0009] In a fifth aspect, the present application also provides a computer program product. The computer program product includes a computer program, which implements the following steps when executed by a processor: determining the block height of the block to be agreed upon in the blockchain; determining the offset based on the block height and a preset block height threshold; determining the master node index value of the block to be agreed upon based on the offset, the number of consensus rounds of the block to be agreed upon, and the number of nodes in the blockchain; when the master node index value of the block to be agreed upon is the same as the index value of the local node, broadcasting the proposal message of the block to be agreed upon to other nodes in the blockchain, so that the other nodes reach a consensus on the block to be agreed upon based on the transaction tasks in the proposal message.

[0010] The above-mentioned blockchain consensus method, device, computer equipment, storage medium and computer program product determine the block height of the block to be agreed upon in the blockchain, and determine the offset based on the block height and the preset block height threshold; determine the master node index value of the block to be agreed upon based on the offset, the number of consensus rounds of the block to be agreed upon and the number of nodes in the blockchain; when the master node index value of the block to be agreed upon is the same as the index value of the local node, broadcast the proposal message of the block to be agreed upon to other nodes in the blockchain, so that other nodes can reach a consensus on the block to be agreed upon based on the transaction task in the proposal message. Since the offset is determined based on the two parameters of the block height of the block to be agreed upon and the preset block height threshold, the master node index value of the block to be agreed upon determined based on the offset, the number of consensus rounds of the block to be agreed upon and the number of nodes in the blockchain is more in line with the characteristics of the blockchain consensus process, and can increase the number of times each node becomes the master node continuously. In the case of abnormal nodes in the blockchain, the processing performance of the blockchain consensus is greatly improved, thereby effectively improving the consensus efficiency of the entire blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 This is an optional structural diagram of a distributed system 100 applied to a blockchain system in an embodiment;

[0012] Figure 2 An optional schematic diagram of a block structure in an embodiment;

[0013] Figure 3 An application environment diagram of a blockchain consensus method in one embodiment;

[0014] Figure 4 A schematic diagram of a node set sorting result in one embodiment;

[0015] Figure 5 A schematic diagram of a consensus situation in an embodiment;

[0016] Figure 6A schematic diagram of a Byzantine consensus process in a blockchain in one embodiment;

[0017] Figure 7 A schematic diagram of a consensus situation in a traditional manner in one embodiment;

[0018] Figure 8 A schematic diagram of the time consumption in a traditional method in one embodiment;

[0019] Fig. 9 A schematic diagram of the time consumption of a Byzantine process optimization solution in one embodiment;

[0020] Fig.10 It is a structural block diagram of a blockchain consensus device in one embodiment;

[0021] Fig.11 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0022] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0023] It should be noted that in the following description, the terms "first, second and third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first, second and third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0024] The system involved in the embodiment of the present invention may be a distributed system formed by connecting a client and multiple nodes (computing devices of any form in an access network, such as a server and a user terminal) through network communication.

[0025] Take the distributed system as the blockchain system as an example, see Figure 1 , Figure 1It is an optional structural diagram of the distributed system 100 provided by the embodiment of the present invention applied to the blockchain system, which is formed by multiple nodes (any form of computing devices in the access network, such as servers, user terminals) and clients, and a peer-to-peer network is formed between the nodes. The Peer To Peer protocol is an application layer protocol running on the Transmission Control Protocol (TCP). In a distributed system, any machine such as a server or a terminal can join and become a node, and the node includes a hardware layer, an intermediate layer, an operating system layer, and an application layer.

[0026] See also Figure 1 The functions of each node in the blockchain system shown include:

[0027] 1) Routing: a basic function of a node, used to support communication between nodes.

[0028] In addition to the routing function, the node can also have the following functions:

[0029] 2) Applications are deployed in the blockchain to implement specific businesses based on actual business needs, record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system for other nodes to add the record data to a temporary block when they successfully verify the source and integrity of the record data.

[0030] For example, the services implemented by the application include:

[0031] 2.1) Wallet, used to provide the function of conducting electronic currency transactions, including initiating transactions (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system. After the other nodes successfully verify the transaction, as a response to acknowledge the validity of the transaction, the transaction record data is stored in the temporary block of the blockchain; of course, the wallet also supports querying the remaining electronic currency in the electronic currency address;

[0032] 2.2) Shared ledger, which is used to provide functions such as storage, query and modification of account data. The record data of the operation on the account data is sent to other nodes in the blockchain system. After other nodes verify the validity, as a response to acknowledging the validity of the account data, the record data is stored in a temporary block, and a confirmation can also be sent to the node that initiated the operation.

[0033] 2.3) Smart contracts are computerized protocols that can execute the terms of a contract. They are implemented by deploying code on a shared ledger that is executed when certain conditions are met. The code is used to complete automated transactions based on actual business needs, such as querying the logistics status of the goods purchased by the buyer and transferring the buyer's electronic currency to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions, but can also execute contracts for processing received information.

[0034] 3) Blockchain, including a series of blocks that are connected to each other in the order of their generation. Once a new block is added to the blockchain, it will not be removed. The block records the record data submitted by the nodes in the blockchain system.

[0035] See also Figure 2 , Figure 2 This is an optional schematic diagram of the block structure provided by an embodiment of the present invention. Each block includes the hash value of the transaction record stored in this block (the hash value of this block) and the hash value of the previous block. Each block is connected by the hash value to form a blockchain. In addition, the block can also include information such as the timestamp when the block was generated. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains relevant information for verifying the validity of its information (anti-counterfeiting) and generating the next block.

[0036] In one embodiment, Figure 3 As shown, a blockchain consensus method is provided, which is applied to Figure 1 The node cluster in the blockchain system in the example is used to illustrate, including the following steps:

[0037] Step 302, determine the block height of the block to be agreed upon in the blockchain.

[0038] Among them, blockchain is a chain composed of blocks. Each block stores certain information, and they are connected into a chain in the order of their generation. This chain is stored in all servers. As long as there is a server in the entire system that can work, the entire blockchain is safe. These servers are called nodes in the blockchain system, and they provide storage space and computing power support for the entire blockchain system. If you want to modify the information in the blockchain, you must obtain the consent of more than half of the nodes and modify the information in all nodes. These nodes are usually in the hands of different entities, so it is extremely difficult to tamper with the information in the blockchain. Compared with traditional networks, blockchain has two core characteristics: one is that data is difficult to tamper with, and the other is decentralization. Based on these two characteristics, the information recorded in the blockchain is more authentic and reliable, which can help solve the problem of people's distrust of each other. The types of blockchains include public chains, joint chains, private chains, etc. The blockchain system in this application can be a consortium chain system. Blockchain is a distributed system. The number of nodes in this system will have a huge impact on the overall performance. As the number of nodes increases, network communication often becomes one of the bottlenecks of the entire blockchain performance. The blockchain consensus algorithm itself also takes into account network anomalies. For example, for BFT (Byzantine Fault Tolerance) consensus algorithms, when some nodes (less than the tolerable range) are abnormal, the entire blockchain system can still operate normally. However, when a node has a network anomaly, the node cannot actually participate in the consensus normally. At this time, for other nodes in the blockchain, it is necessary to wait for a certain timeout period. For the node with the network anomaly, it cannot participate in the consensus process of the current block normally, which will cause the block maintained by the node to lag behind other nodes in the blockchain.

[0039] The consensus environment of the blockchain in this application can be a blockchain underlying model based on BFT consensus. Under the blockchain underlying model based on BFT consensus, there are usually master nodes and slave nodes. The master node is responsible for generating proposals for new blocks, which are verified by the slave nodes to confirm whether the blocks in the proposal can reach a consensus. Among them, BFT (Byzantine Fault Tolerance), that is, Byzantine Fault Tolerance, is a consensus mechanism. For example, under the blockchain underlying model based on BFT consensus, after a newly created blockchain is started, when a new block is generated in the newly created blockchain, each node in the node cluster can determine whether it is a master node. For example, each node in the node cluster can determine whether the block generation conditions are met based on the parameters in the block maintained by itself; when a node determines that it meets the block generation conditions, the node becomes the master node.

[0040] A block to be agreed upon refers to a block that has not been agreed upon by the blockchain network. For example, a new block is produced after the genesis block of blockchain 1. Before the newly generated block is verified by the slave nodes and consensus is reached, the block is a block to be agreed upon. For example, in the underlying blockchain model based on BFT consensus, there are usually master nodes and slave nodes. When a new block is generated in the blockchain, the master node is responsible for generating a proposal for the new block, and other slave nodes verify the block to confirm whether the block can reach a consensus. In this application, a block to be agreed upon can be a newly generated block that has not yet reached a consensus. For example, a new block is produced after the genesis block of blockchain 1. The newly generated block can be used as a block to be agreed upon.

[0041] Block height refers to the height of a block, which refers to the number of blocks between it and the genesis block in the blockchain. Block height is the identifier of the block. In some cases, the block height in this application can also be referred to as the block height value.

[0042] The block height of the block to be agreed upon refers to the block height of the new block to be agreed upon. For example, if the maximum block height in the local ledger maintained by node A in the node cluster is 6, then node A can obtain the next new block to be agreed upon, that is, the block height of the block to be agreed upon is 7.

[0043] Specifically, after a newly created blockchain is started, the node cluster in the blockchain system can obtain the first block height of the local node in the blockchain, that is, each node in the node cluster can obtain the maximum block height (current height) in the local blockchain maintained by itself, and use the maximum block height as the first block height; further, each node in the node cluster can determine the block height of the new block to be agreed upon based on the maximum block height in the local blockchain maintained by itself, that is, determine the block height of the block to be agreed upon.

[0044] For example, let's take node A in the node cluster of the blockchain system as an example. Under the underlying blockchain model based on the BFT consensus, assume that node A in the node cluster obtains the current maximum block height H0 in the local blockchain maintained by itself, and uses the maximum block height H0 as the first block height; further, node A can determine the block height of the next new block to be agreed upon based on the first block height. For example, node A can determine the block height of the block to be agreed upon Block (6) as H1=H0+1=5+1=6 based on the first block height H0=5.

[0045] Step 304: Determine the offset based on the block height and a preset block height threshold.

[0046] Among them, the preset block height threshold refers to the preset interval value of the block height. For example, the preset block height threshold in the present application can be set to 1000, that is, 1000 heights are taken as an interval. According to the method provided in the present application, the master nodes in this interval (0-1000) are all the same node (such as node A), that is, a node (node ​​A) will be the master node for 1000 consecutive heights, and the next node (such as node B) will be switched as the master node until the height is 1001.

[0047] The offset refers to the offset for the master node index value. The offset in this application can be the offset of the pointer to the master node index value of the consensus block. For example, the master node index value of the previous block height is preProposerIndex, then the offset proposerOffset is the offset of the master node index value for the consensus block determined based on preProposerIndex, for example, proposerOffset = preProposerIndex + 1, or proposerOffset = preProposerIndex.

[0048] Specifically, after each node in the node cluster determines the block height of the block to be agreed upon, each node in the node cluster can determine the offset of the master node index value for the block to be agreed upon based on the determined block height and the preset block height threshold. For example, each node in the node cluster can determine the offset of the master node index value of the block to be agreed upon based on a reference value between the determined block height and the preset block height threshold.

[0049] For example, node A in the node cluster of the blockchain system is used as an example for explanation. Under the underlying blockchain model based on the BFT consensus, assuming that node A in the node cluster determines that the block height of the consensus block Block (6) is H1 = H0 + 1 = 5 + 1 = 6, node A can obtain the preset block height threshold L = 1000, then node A can determine the offset proposerOffset of the master node index value for the consensus block Block (6) based on the determined block height H1 = 6 and the preset block height threshold L = 1000. For example, node A can calculate the reference value between the determined block height H1 = 6 and the preset block height threshold L = 1000 as 6, and determine the offset proposerOffset = preProposerIndex of the master node index value of the consensus block Block (6) based on the determined reference value 6, where preProposerIndex represents the master node index value of the previous height, that is, the master node index value of the previous block of the consensus block.

[0050] Step 306, based on the offset, the number of consensus rounds of the block to be agreed upon, and the number of nodes in the blockchain, determine the master node index value of the block to be agreed upon.

[0051] The number of consensus rounds refers to the number of times consensus is performed on a consensus block. For example, when consensus is performed on consensus block Block(6) for the first time, the number of consensus rounds is 0; when consensus is performed on consensus block Block(6) for the second time, the number of consensus rounds is 1.

[0052] The number of consensus rounds for a block to be agreed upon refers to the number of consensus rounds for the new block to be agreed upon.

[0053] The number of nodes in a blockchain refers to the number of nodes participating in the consensus in the blockchain, that is, the total number of consensus nodes in the blockchain. In some cases, the number of nodes in a blockchain in this application can also be referred to as the total number of consensus nodes. For example, if a blockchain system contains 4 consensus nodes, the number of nodes in the blockchain is 4.

[0054] The master node index value refers to the index value of the master node, which is used to determine which specific node becomes the master node in this round of consensus. For example, if the master node index value proposerIndex is 0, then based on the master node index value proposerIndex=0, the master node can be found to be node A, because the index value of node A is 0, which is the same as the master node index value proposerIndex=0.

[0055] The master node index value of the block to be agreed upon refers to the master node index value of the block to be agreed upon in this round of consensus. For example, the master node index value of the block to be agreed upon in this round of consensus is 0.

[0056] Specifically, after each node in the node cluster determines the offset of the master node index value of the block to be agreed upon in this round of consensus based on the determined block height and the preset block height threshold, each node in the node cluster can determine the number of consensus rounds of the block to be agreed upon and the number of nodes in the blockchain, and determine the master node index value of the block to be agreed upon in this round of consensus based on the determined offset, the number of consensus rounds of the block to be agreed upon and the number of nodes in the blockchain. For example, each node in the node cluster can perform a modulo operation based on the number of consensus rounds of the block to be agreed upon and the number of nodes in the blockchain to obtain a second operation result, and calculate the sum between the determined offset and the second operation result; further, each node in the node cluster can determine the master node index value of the block to be agreed upon in this round of consensus based on the sum and the number of nodes in the blockchain.

[0057] For example, let's take node A in the node cluster of the blockchain system as an example. Under the underlying blockchain model based on the BFT consensus, assume that node A in the node cluster calculates the reference value between the block height H1=6 and the preset block height threshold L=1000 as 6, and based on the determined reference value 6, determines the offset of the master node index value of the consensus block Block(6) as proposerOffset=preProposerIndex=0, then node A can calculate the remainder between the consensus round number round of the consensus block and the number of nodes N in the blockchain, that is, node A can calculate the calculation result d of round%N, and calculate the sum between the determined offset proposerOffset=preProposerIndex=0 and the calculation result d, that is, proposerOffset+(round%N)=proposerOffset+d; further, each node in the node cluster can determine the master node index value proposerIndex of the consensus block based on the sum (proposerOffset+d) and the number of nodes N in the blockchain.

[0058] In one embodiment, node A can calculate the primary node index value proposerIndex of the block to be agreed upon according to the following formula (1):

[0059] proposerIndex = (proposerOffset + (round % N)) % N (1)

[0060] Wherein, proposerIndex in formula (1) represents the index value of the consensus node (i.e., the master node index value); proposerOffset represents an offset; round represents the current round number; and N represents the total number of consensus nodes.

[0061] Step 308, when the master node index value of the block to be agreed upon is the same as the index value of the local node, the proposal message of the block to be agreed upon is broadcast to other nodes in the blockchain, so that other nodes can reach a consensus on the block to be agreed upon based on the transaction tasks in the proposal message.

[0062] The local node refers to a node in the node cluster, and the local node in this application may refer to the current node, that is, the current execution subject. For example, taking node A in the node cluster as an example, assuming that node A is the execution subject, the local node refers to node A.

[0063] The index value of the local node refers to the index value corresponding to a node in the node cluster. For example, taking node A in the node cluster as an example, node A can obtain its own corresponding index value as d1, then the index value of the local node is d1.

[0064] A proposal message is a communication message between nodes in a blockchain. For example, a communication message may also include a voting message. A proposal message in this application refers to a message that carries a proposal. For example, a proposal message carries Proposal 1, which is generated for the newly generated consensus block Block(6).

[0065] A proposal message for a block to be agreed upon refers to a proposal message generated for a block to be agreed upon. For example, a proposal message carries Proposal 1, which is generated for the newly generated block to be agreed upon Block(6).

[0066] Other nodes refer to nodes in the node cluster other than the current node (local node). For example, taking node A in the node cluster as an example, when the master node index value of the block to be agreed upon is the same as the index value corresponding to node A itself, node A becomes the master node, and node A can broadcast the proposal message of the block to be agreed upon to other nodes in the blockchain (nodes other than node A).

[0067] Consensus refers to the consensus on the newly generated block (block to be agreed upon). Only when the newly generated block is verified by the nodes and consensus is reached, can the block be uploaded to the blockchain, and each node can store the consensus block in the local ledger.

[0068] Specifically, after each node in the node cluster determines the master node index value of the block to be agreed upon, each node in the node cluster can compare the determined master node index value of the block to be agreed upon with the local node, that is, its own index value. When the master node index value of the block to be agreed upon is the same as the index value of the local node, it indicates that the local node can become the master node in this round of consensus, that is, the master node in the node cluster can obtain transaction tasks from the local transaction pool, encapsulate the transaction tasks into proposal messages of the block to be agreed upon, and broadcast the proposal messages of the block to be agreed upon to other nodes in the blockchain, so that other nodes can reach consensus on the block to be agreed upon based on the transaction tasks in the proposal message.

[0069] In addition, each node in the node cluster compares the determined master node index value of the block to be agreed upon with the local node, i.e., its own index value. When the master node index value of the block to be agreed upon is different from the index value of the local node, it indicates that the local node is not the master node in this round of consensus, and the local node acts as a slave node in this round of consensus, i.e., each node (slave node) in the node cluster waits for the node (master node) corresponding to the master node index value of the block to be agreed upon in the blockchain to send a proposal message of the block to be agreed upon; when the slave node receives the proposal message, the slave node can reach a consensus on the block to be agreed upon based on the transaction task in the received proposal message; or,

[0070] When the slave node does not receive the proposal message within the preset timeout period, it automatically generates a timeout voting message, i.e., an empty voting message, for the block to be agreed upon, and broadcasts the timeout voting message to other nodes in the blockchain, so that other nodes can perform the next round of consensus on the block to be agreed upon based on the timeout voting message.

[0071] For example, let's take node A in the node cluster of the blockchain system as an example. Under the underlying blockchain model based on BFT consensus, assuming that node A in the node cluster determines that the master node index value proposerIndex of the consensus block Block(6) is 0, node A can obtain the index value of the local node, that is, its own, as 0. For example, assuming that there are 4 consensus nodes in the node cluster of the current blockchain system, node A can obtain the node sequence of the 4 consensus nodes according to the dictionary sorting: node A (index value 0) - node B (index value 1) - node C (index value 2) - node D (index value 3), then node A can determine the local node, that is, its own index value as 0 based on the above node sequence; further, node A can determine the master node index value proposerIndex of the consensus block Block(6) poserIndex=0 is compared with the local node, i.e., its own index value 0. Since proposerIndex=0=node A (index value 0), that is, when the master node index value proposerIndex=0 of the consensus block Block(6) is the same as the local node index value 0, node A becomes the master node. Node A can obtain transaction tasks from the local transaction pool, encapsulate the transaction tasks into proposal message 1 of the consensus block Block(6), and broadcast the proposal message 1 of the consensus block Block(6) to other nodes in the blockchain (for example, node B, node C, and node D), so that other nodes can reach consensus on the consensus block Block(6) based on the transaction tasks in the proposal message 1.

[0072] In this embodiment, the block height of the block to be agreed upon in the blockchain is determined, and the offset is determined based on the block height and the preset block height threshold; the master node index value of the block to be agreed upon is determined based on the offset, the number of consensus rounds of the block to be agreed upon, and the number of nodes in the blockchain; when the master node index value of the block to be agreed upon is the same as the index value of the local node, the proposal message of the block to be agreed upon is broadcast to other nodes in the blockchain, so that other nodes can reach a consensus on the block to be agreed upon based on the transaction task in the proposal message. Since the offset is determined based on the two parameters of the block height of the block to be agreed upon and the preset block height threshold, the master node index value of the block to be agreed upon determined based on the offset, the number of consensus rounds of the block to be agreed upon, and the number of nodes in the blockchain is more in line with the characteristics of the blockchain consensus process, and can increase the number of times each node becomes the master node continuously. In the case of abnormal nodes in the blockchain, the processing performance of the blockchain consensus is greatly improved, thereby effectively improving the consensus efficiency of the entire blockchain.

[0073] In one embodiment, before determining the block height of the block to be agreed upon in the blockchain, the method further includes:

[0074] Get the consensus node set in the blockchain;

[0075] Based on the node identifier of each node in the consensus node set, the index value of each node is determined; wherein there is a binding relationship between the node identifier and the index value.

[0076] Among them, the consensus node set refers to a set of node identifiers used to store consensus nodes in the blockchain. For example, the consensus node set in this application can be represented by NodeList, and the node identifiers in the NodeList set are all node identifiers of consensus nodes.

[0077] The node identifier is used to identify a unique node. The node identifier in this application can be represented by nodeID. For example, the node identifier of node A is node0.

[0078] The index value refers to the value used to index the node. In the present application, the index value can be determined based on the node identifier of each node. For example, after node A in the node cluster sorts the nodes in the blockchain according to the sorting rule, the node sequence obtained is: node A (node0) - node B (node1) - node C (node2) - node D (node3). Then node A can determine that the index value is 0 based on the node identifier in the above node sequence, that is, node0. The final node sequence is: node A (index value 0) - node B (index value 1) - node C (index value 2) - node D (index value 3). Then node A can determine its own index value as 0 based on the above node sequence. There is an association between the node identifier (node0) of node A and the index value 0.

[0079] Specifically, Figure 4 As shown in FIG. 1 , it is a schematic diagram of the node set sorting result. Take node 1 in the node cluster of the blockchain system as an example for explanation. Under the underlying blockchain model based on BFT consensus, before node 1 in the node cluster determines the block height of the consensus block Block(6), node 1 in the node cluster can obtain the consensus node set in the blockchain. Assuming that the consensus node set NodeList in the blockchain obtained by node 1 contains a total of 4 nodes, node 1 can sort the node IDs of the 4 nodes contained in the consensus node set NodeList according to the preset sorting strategy, and obtain the consensus node set sorting result as shown in FIG. Figure 4 As shown in Figure 4 The sorted node identifier (node0) shown in the figure is ranked first, and the node identifier of node 1 is node0, so node 1 can get the following Figure 4 The node sequence shown in is: node 1 (node0) - node 2 (node1) - node 3 (node2) - node 4 (node3); further, node 1 can be based on Figure 4 The node identifier of each node in the node sequence shown in , and the index value of each node are determined, and the node sequence of the four consensus nodes is obtained as follows: node 1 (index value 0) - node 2 (index value 1) - node 3 (index value 2) - node 4 (index value 3). Among them, there is a binding relationship between the node identifier (such as node0) and the index value (0).

[0080] In this embodiment, by establishing the relationship between each node identifier and the index value, the master node corresponding to each height can be quickly and accurately indexed through the master node index value, which greatly improves the processing performance when there are abnormal nodes in the blockchain, thereby effectively improving the consensus efficiency of the entire blockchain.

[0081] In one embodiment, the step of determining the index value of each node based on the node identifier of each node in the consensus node set includes:

[0082] Sort the nodes in the consensus node set to obtain a node sequence;

[0083] Determine the node number of each node based on the node identifier of each node in the node sequence;

[0084] The node number of each node is used as the index value of each node.

[0085] Among them, the node sequence refers to the sequence obtained by sorting each node in the consensus node set according to the specified sorting method. For example, the consensus node set NodeList contains the node IDs of 4 nodes, then each node in the blockchain node cluster can sort the node IDs of the 4 nodes contained in the NodeList according to the preset sorting method, and the sorting result of the NodeList obtained is the sorted node sequence. It can be understood that at the beginning of each consensus, the consensus list of each node is the same, and the sorting method is the same, so each node in the node cluster can get the same NodeList sorting result.

[0086] The node number refers to the number of each node in the node sequence, for example Figure 4 The node number of the node identifier node0 located at the first position in the node sequence shown in can be set to 0 in the node sequence.

[0087] Specifically, Figure 4 As shown in FIG. 1 , it is a schematic diagram of the node set sorting result. Node 1 in the node cluster of the blockchain system is used as an example for explanation. Under the underlying blockchain model based on BFT consensus, before node 1 in the node cluster determines the block height of the consensus block Block (6), assuming that the consensus node set NodeList in the blockchain obtained by node 1 contains a total of 4 nodes, node 1 can sort the node IDs of the 4 nodes contained in the consensus node set NodeList according to the preset sorting strategy. For example, when node 1 sorts the consensus node set NodeList, the sorting method adopted can be to sort the node IDs according to the dictionary. The so-called dictionary sorting is to form a sequence from small to large in alphabetical order or numerical order. For example, the first letter of "iloveyou" is "i", and the first letter of "baray" is "b". In the alphabet, "i" is ranked before "b", so "ilove" should be ranked before "baray". That is, node 1 can sort the node IDs of each node in the consensus node set NodeList according to the dictionary, and the following can be obtained: Figure 4 The sorted node identifiers NodeID shown in ; further, node 1 can use the sorted NodeID index as the node number of the consensus node, for example, Figure 4 The sorted node identifier (node0) shown in FIG is ranked first, and the index of the node identifier (node0) is 0, and 0 is used as the node number of the node, so node 1 can be obtained as follows Figure 4The node sequence shown is: node 1 (index value 0) - node 2 (index value 1) - node 3 (index value 2) - node 4 (index value 3). Among them, there is a binding relationship between the node identifier (such as node0) and the index value (0). Therefore, by establishing the relationship between each node identifier and the index value, the master node corresponding to each height can be quickly and accurately indexed through the master node index value, which greatly improves the processing performance when there are abnormal nodes in the blockchain, thereby effectively improving the consensus efficiency of the entire blockchain.

[0088] In one embodiment, the step of determining the block height of the block to be agreed upon in the blockchain includes:

[0089] Get the first block height of the local node in the blockchain;

[0090] The block height of the block to be agreed upon in the blockchain is determined based on the first block height.

[0091] Among them, the first block height of the local node refers to the maximum block height maintained by a node in the node cluster. For example, taking node A in the node cluster as an example, the maximum block height that node A can obtain that it maintains is d1, then the first block height of the local node is d1.

[0092] Specifically, take node A in the node cluster of the blockchain system as an example for explanation. Under the underlying blockchain model based on BFT consensus, when node A participates in the consensus of the consensus block in this round in the blockchain, it is assumed that node A in the node cluster obtains the maximum block height H0=5 in the local blockchain maintained by itself, and uses the maximum block height H0=5 as the first block height; further, node A can determine the block height of the consensus block based on the first block height H0=5. For example, node A can determine the block height of the consensus block Block(6) based on the first block height H0=5 as H1=H0+1=5+1=6; further, node A can determine the block height of the consensus block Block(6) as H1=H0+1=5+1=6 based on the block height of the consensus block Block(6) as H1=6 and the preset block height threshold. The master node index value of the block to be consensus Block (6) is determined based on the value, the number of consensus rounds of the block to be consensus Block (6) and the number of nodes in the blockchain, and the master node index value of the block to be consensus Block (6) is determined, and based on the determined master node index value, it is determined whether it can become the master node. That is, when the master node index value of the block to be consensus Block (6) is the same as the index value of the local node, that is, node A, node A becomes the master node, and node A can obtain transaction tasks from the local transaction pool, and encapsulate the transaction tasks into a proposal message 1 of the block to be consensus Block (6), and broadcast the proposal message 1 to other nodes in the blockchain, so that other nodes can reach a consensus on the block to be consensus Block (6) based on the transaction tasks in the proposal message 1. In this way, the number of times each node can become the master node continuously can be increased, and in the case of abnormal nodes in the blockchain, the processing performance of the blockchain consensus is greatly improved, thereby effectively improving the consensus efficiency of the entire blockchain.

[0093] In one embodiment, the method further comprises:

[0094] Get the first master node index value of the first block height;

[0095] The determining the offset based on the block height and a preset block height threshold includes:

[0096] Determine a reference value based on the block height and a preset block height threshold;

[0097] When the reference value is the first value, determining the offset based on the first master node index value;

[0098] When the reference value is not the first value, the first master node index value is used as the offset.

[0099] Among them, the first master node index value refers to the master node index value of the block at the first block height. In the present application, the first master node index value may refer to the master node index value of the previous block of the block to be agreed upon. For example, if the block to be agreed upon is Block(6), then the master node index value of Block(5), the previous block of the block to be agreed upon Block(6), is the first master node index value.

[0100] It can be understood that the first master node index value and the master node index value of the block to be agreed upon in this application are only used to distinguish the master node index values ​​corresponding to different blocks. The master node index values ​​corresponding to different blocks can be the same or different. For example, the master node index value of the previous block Block(5) of the block to be agreed upon, i.e., the first master node index value, is 0, and the master node index value of the block to be agreed upon, Block(6), can also be 0.

[0101] The reference value refers to reference data determined based on the block height of the block to be consensus and a preset block height threshold. For example, the reference value in this application can be the result of a modulo operation between the block height and the preset block height threshold, that is, the node cluster can perform a modulo operation based on the block height and the preset block height threshold to obtain a modulo operation result, and use the modulo operation result as a reference value.

[0102] The first value refers to a specific numerical value. For example, the first value in this application can be set to 0.

[0103] Specifically, take node 1 in the node cluster of the blockchain system as an example for explanation. Under the underlying blockchain model based on BFT consensus, when node 1 participates in the consensus of the consensus block in this round in the blockchain, it is assumed that node 1 in the node cluster obtains the maximum block height H0=2 in the local blockchain maintained by itself, and uses the maximum block height H0=2 as the first block height; node 1 can determine the block height of the consensus block Block(3) as H1=H0+1=2+1=3 based on the first block height H0=2; further, node 1 can obtain the first block height H0=2, that is, the first master node index value of block Block(2) is preProposerIndex=0, that is, when the block height H1=3, the index value of the master node of the previous height, that is, the master node of height H0=2, is 0, and node 1 can determine the block height of the consensus block Block(3) as H1=H0+1=2+1=3 based on the first block height H0=2; further, node 1 can obtain the first block height H0=2, that is, the first master node index value of block Block(2) is preProposerIndex=0, that is, when the block height H1=3, the index value of the master node of the previous height, that is, the master node of height H0=2, is 0, and node 1 can determine the block height of the consensus block Block(3) as H1=H0+1=2+1=3 based on the first block height H0=2. Figure 4The node sequence shown is: node 1 (index value 0) - node 2 (index value 1) - node 3 (index value 2) - node 4 (index value 3). It is determined that the node corresponding to the first master node index value preProposerIndex=0 of block Block(2) is node 1, that is, the master node with height H0=2 is node 1; further, node 1 can determine that the reference value between block height H1=3 and preset block height threshold L=1000 is 3 based on the block height H1=3 of the consensus block Block(3) and the preset block height threshold L=1000; assuming that the first value is set to 0, since the reference value 3 is not equal to 0, when the reference value (3) is not the first value (0), node 1 can directly use the first master node index value preProposerIndex=0 as the offset proposerOffset, that is, the offset proposerOffset=preProposerIndex=0.

[0104] In this embodiment, since the master node index value of the block to be agreed upon determined based on the offset, the number of consensus rounds of the block to be agreed upon and the number of nodes in the blockchain has a certain correlation with the preset block height threshold, the master node index value of the block to be agreed upon determined based on the offset, the number of consensus rounds of the block to be agreed upon and the number of nodes in the blockchain is more in line with the characteristics of the blockchain consensus process, can increase the number of times each node becomes the master node continuously, optimizes the method of selecting the master node, and enables the processing performance of the blockchain consensus to be greatly improved in the face of abnormal nodes in the blockchain, thereby effectively improving the consensus efficiency of the entire blockchain.

[0105] In one embodiment, the step of determining the reference value based on the block height and a preset block height threshold includes:

[0106] Performing a modulo operation based on the block height and a preset block height threshold to obtain a first operation result;

[0107] The first operation result is used as a reference value.

[0108] Among them, the remainder operation can also be called the modular operation, which can be represented by the symbol "%", for example, 5%2=1, which means that the remainder of 5 divided by 2 is 1.

[0109] Specifically, take node 1 in the node cluster of the blockchain system as an example for explanation. Under the underlying blockchain model based on the BFT consensus, when node 1 participates in the consensus of the consensus block in this round in the blockchain, it is assumed that node 1 in the node cluster obtains the maximum block height H0=2 in the local blockchain maintained by itself, and uses the maximum block height H0=2 as the first block height; node 1 can determine the block height of the consensus block Block(3) as H1=H0+1=2+1=3 based on the first block height H0=2; further, node 1 can perform a modulo operation based on the block height H1=3 of the consensus block Block(3) and the preset block height threshold L=1000, that is, node 1 can calculate the operation result of H1%L, and obtain the operation result: H1%L=3%1000=3, then node 1 can use the result 3 of the modulo operation as the reference value between the block height H1=3 and the preset block height threshold L=1000, that is, the reference value is 3. This can increase the number of times each node becomes the master node consecutively, optimize the method of selecting the master node, and greatly improve the processing performance of the blockchain consensus when faced with abnormal nodes in the blockchain, thereby effectively improving the consensus efficiency of the entire blockchain.

[0110] In one embodiment, the step of determining the offset based on the first master node index value includes:

[0111] Determine the sum of the first master node index value and the preset value, and use the sum as an offset.

[0112] The preset value refers to a preset value, for example, the preset value in this application may be 1.

[0113] Specifically, take node 1 in the node cluster of the blockchain system as an example for explanation. Under the underlying blockchain model based on BFT consensus, when node 1 participates in the consensus of the consensus block in this round in the blockchain, it is assumed that node 1 in the node cluster obtains the maximum block height H0=999 in the local blockchain maintained by itself, and uses the maximum block height H0=999 as the first block height; node 1 can determine the block height of the consensus block Block(1000) based on the first block height H0=999 as H1=H0+1=999+1=1000; further, node 1 can obtain the first block height H0=999, that is, the first master node index value of block Block(999) is preProposerIndex=0, that is, when the block height H1=1000, the index value of the master node of the previous height, that is, the master node of height H0=999 is 0, and node 1 can determine the block height of the consensus block Block(1000) based on the first block height H0=999 as H1=H0+1=999+1=1000; further, node 1 can obtain the first block height H0=999, that is, the first master node index value of block Block(999) is preProposerIndex=0, that is, when the block height H1=1000, the index value of the master node of the previous height, that is, the master node of height H0=999 is 0, and node 1 can determine the block height of the consensus block Block(1000) based on the first block height H0=999 as H1=H0+1=999+1=1000. Figure 4The node sequence shown is: node 1 (index value 0) - node 2 (index value 1) - node 3 (index value 2) - node 4 (index value 3), and it is determined that the node corresponding to the first master node index value preProposerIndex=0 of block Block(999) is node 1, that is, the master node with height H0=999 is node 1; further, node 1 can determine that the reference value between block height H1=1000 and preset block height threshold L=1000 is 0 based on the block height H1=1000 of the consensus block Block(1000) and the preset block height threshold L=1000; assuming that the first value is set to 0, since the reference value 0 is equal to the first value 0, when the reference value (0) is the first value (0) , node 1 can determine the offset proposerOffset based on the first master node index value preProposerIndex=0 of the previous height H0=999. For example, node 1 can calculate the sum of the first master node index value preProposerIndex=0 and the preset value 1, and the calculation result is: preProposerIndex+1=0+1=1, and the sum of the first master node index value preProposerIndex=0 and the preset value 1 is used as the offset proposerOffset, that is, proposerOffset=preProposerIndex+1=0+1=1. As a result, the determination method of the master node is optimized by increasing the offset, thereby increasing the number of times each node becomes the master node continuously, so that in the face of abnormal nodes in the blockchain, the processing performance of the blockchain consensus can be greatly improved, thereby effectively improving the consensus efficiency of the entire blockchain.

[0114] In one embodiment, after determining the offset based on the block height and a preset block height threshold, the method further includes:

[0115] Determine the number of consensus rounds for the block to be agreed upon;

[0116] The determining the master node index value of the block to be agreed upon based on the offset, the number of consensus rounds of the block to be agreed upon, and the number of nodes in the blockchain includes:

[0117] Perform a modulo operation based on the number of consensus rounds of the block to be agreed upon and the number of nodes in the blockchain to obtain a second operation result;

[0118] Determine a target value based on the offset and the second operation result;

[0119] Based on the target value and the number of nodes in the blockchain, the master node index value of the block to be consensus is determined.

[0120] Among them, the target value refers to the value determined based on the offset and the second operation result. The target value in this application can be the operation result obtained by operating the offset and the second operation result. For example, the operation result obtained after the modulo operation based on the offset and the second operation result is d, then the operation result d is used as the target value.

[0121] Specifically, take node 1 in the node cluster of the blockchain system as an example. Under the underlying blockchain model based on the BFT consensus, when node 1 participates in the consensus of the consensus block Block(1000) in this round in the blockchain, node 1 determines the offset proposerOffset=preProposerIndex+1=0+1=1 based on the first master node index value preProposerIndex=0 of the previous height H0=999. After that, node 1 can obtain the consensus round number round=0 for the consensus block Block(1000), and perform a modulo operation based on the consensus round number round=0 of the consensus block Block(1000) and the number of nodes N=4 in the blockchain, that is, node 1 calculates round% N=0, the second operation result is 0; further, node 1 performs operation based on the offset proposerOffset=1 and the second operation result 0, and obtains the operation result 1, and uses the operation result 1 as the target value; further, node 1 can determine the main node index value proposerIndex of the block to be agreed upon Block(1000) based on the target value 1 and the number of nodes in the blockchain N=4. For example, node 1 can calculate the main node index value proposerIndex of the block to be agreed upon Block(1000) based on the above formula (1): (proposerOffset+(round%N))%N=(1+0)%4=1. Further, node 1 can calculate the main node index value proposerIndex of the block to be agreed upon Block(1000) based on the above formula (1): Figure 4 The node sequence shown: Node 1 (index value 0) - Node 2 (index value 1) - Node 3 (index value 2) - Node 4 (index value 3), determines that the node corresponding to the main node index value preProposerIndex=1 of block Block(1000) is Node 2, that is, the main node with height H0=1000 is Node 2.

[0122] For example, Figure 5 As shown in the figure, it is a schematic diagram of the consensus situation. Take the example of a blockchain system with 4 consensus nodes in its node cluster. In the underlying blockchain model based on BFT consensus, it is assumed that there are 4 nodes in the blockchain network, of which node 2 fails, and nodes 1, 3, and 4 are normal nodes. The consensus situation in the blockchain can be obtained by using the blockchain consensus method provided in the embodiment of the present application. Figure 5As shown in, it is assumed that node 1 in the node cluster calculates the master node index value of the consensus block Block(1000) based on the above formula (1): proposerIndex=(proposerOffset+(round%N))%N=(1+0)%4=1, and according to Figure 4 The node sequence shown is: node 1 (index value 0) - node 2 (index value 1) - node 3 (index value 2) - node 4 (index value 3). It is determined that the node corresponding to the master node index value preProposerIndex = 1 of block Block (1000) is node 2, that is, the master node of height H0 = 1000 is node 2. Since node 2 is a faulty node, it cannot participate in the consensus and cannot generate a proposal message for the block to be consensus Block (1000). Therefore, no consensus is reached on the block to be consensus Block (1000) in this round (round number is 0). After each node in the node cluster times out and votes, it automatically enters the next round (round number is 1) of consensus on the block to be consensus Block (1000); when the round number is 1, node 3 becomes the master node to reach a consensus on the block to be consensus Block (1000). Therefore, the master node of the previous height Block (1000) of height 1001 is node 3, and the index value of node 3 is 2. At this time, each node calculates that the modulo operation result of the height (1001) and 1000 is not equal to 0, so its offset proposerOffset is equal to the master node index value of the height 1000, which is equal to 2; each node can calculate the master node index value of the height 1001 and round 0 according to the master node calculation formula shown in the above formula (1), and it is still 2, that is, the master node of the height 1001 and round 0 is still node 3. Similarly, Figure 5 The master nodes at heights 1001-1999 shown in the figure are all nodes 3. Therefore, through the master node calculation method and Figure 5 The consensus situation shown can extend the number of times each node becomes the master node in succession. When there is 1 faulty node and 3 normal nodes among 4 nodes, the method provided in the present application can ensure normal proposal voting for 3000 consecutive blocks. Only after 3000 blocks are generated, node 2 becomes a faulty node and cannot generate proposals. The other three normal nodes need to wait for a period of time and cast empty votes. The next node is switched to be the master node. Therefore, the master node determination method provided in the embodiment of the present application can greatly improve the blockchain processing performance when there are abnormal nodes, thereby effectively improving the consensus efficiency of the blockchain.

[0123] In one embodiment, the step of determining the target value based on the offset and the second operation result includes:

[0124] Take the sum of the offset and the second operation result as the target value;

[0125] The determining the master node index value of the block to be reached based on the target value and the number of nodes in the blockchain includes:

[0126] A modulo operation is performed based on the target value and the number of nodes in the blockchain to obtain a third operation result, and the third operation result is used as the main node index value of the block to be agreed upon.

[0127] Specifically, take node 1 in the node cluster of the blockchain system as an example. Under the underlying blockchain model based on BFT consensus, when node 1 participates in the consensus of the consensus block Block(1000) in this round in the blockchain, node 1 determines the offset proposerOffset=preProposerIndex+1=0+1=1 based on the first master node index value preProposerIndex=0 of the previous height H0=999. After that, node 1 can obtain the consensus round number round=0 for the consensus block Block(1000), and based on the consensus round number rou nd=0 and the number of nodes in the blockchain N=4 perform a modulo operation, that is, node 1 calculates round%N=0, and the second operation result is 0; further, node 1 calculates the sum of the offset proposerOffset=1 and the second operation result 0 as 1, and the sum 1 is used as the target value; further, node 1 can perform a modulo operation based on the target value 1 and the number of nodes in the blockchain N=4, that is, node 1 calculates the target value 1%4=1, and the operation result is 1, and determines that the master node index value proposerIndex of the consensus block Block(1000) is 1. Therefore, the above-mentioned master node index value determination method provided in the embodiment of the present application can greatly improve the blockchain processing performance when there are abnormal nodes, thereby effectively improving the consensus efficiency of the blockchain.

[0128] In one embodiment, after determining the master node index value of the block to be agreed upon, the method further includes:

[0129] When the master node index value of the block to be agreed upon is different from the index value of the local node, wait for the node corresponding to the master node index value in the blockchain to send a proposal message for the block to be agreed upon;

[0130] When a proposal message is received, consensus is reached on the consensus block based on the transaction tasks in the received proposal message;

[0131] When no proposal message is received within the preset timeout period, a timeout voting message for the consensus block is generated and broadcast to other nodes in the blockchain so that other nodes can perform the next round of consensus on the consensus block based on the timeout voting message.

[0132] The preset timeout time refers to the preset timeout time. For example, the preset timeout time can be set to 30s. If node A does not receive the proposal message sent by the master node within 30s, node A can automatically generate a timeout voting message for the consensus block.

[0133] A timeout voting message refers to an empty voting message that is automatically generated after a timeout. That is, the timeout voting message is used to end this round of consensus and enter the next round of consensus process for the consensus block.

[0134] Specifically, node 1 in the node cluster of the blockchain system is used as an example for explanation. Under the underlying blockchain model based on the BFT consensus, when node 1 participates in the consensus of the consensus block Block(1000) in this round in the blockchain, after node 1 in the node cluster determines the master node index value of the consensus block Block(1000), node 1 can compare the determined master node index value of the consensus block Block(1000) with the index value of the local node, i.e., itself. When the master node index value of the consensus block Block(1000) is different from the index value of the local node, i.e., itself, it indicates that the local node is not the master node in this round of consensus (round number is 0), and the local node acts as a slave node in this round of consensus (round number is 0), i.e., node 1 (slave node) in the node cluster waits for the node (master node) corresponding to the master node index value of the consensus block Block(1000) in the blockchain to send a proposal message of the consensus block.

[0135] When node 1 (slave node) receives the proposal message of the consensus block Block (1000) sent by the master node, node 1 can reach consensus on the consensus block Block (1000) based on the transaction task in the received proposal message; or,

[0136] When node 1 (slave node) does not receive the proposal message within the preset timeout period, node 1 automatically generates a timeout voting message, i.e., an empty voting message, for the consensus block Block (1000), and broadcasts the timeout voting message to other nodes in the blockchain, so that other nodes can reach a consensus on the consensus block Block (1000) in the next round (round number is 1) based on the timeout voting message. Thus, by adopting the master node calculation method provided in the embodiment of the present application, the number of times each normal node becomes the master node continuously can be increased, and in the case of abnormal nodes, the performance of the Byzantine consensus is greatly improved, thereby effectively improving the consensus efficiency of the blockchain.

[0137] In one embodiment, before broadcasting the proposal message of the block to be agreed upon to other nodes in the blockchain, the method further includes:

[0138] Determine the expired transaction tasks in the transaction cleanup tree maintained by itself;

[0139] Grab a preset number of target trading tasks from the trading pool;

[0140] A proposal message of the block to be agreed upon is generated based on the expired transaction task and the target transaction task; the proposal message carries identification information of the expired transaction task, so that the other nodes can reach a consensus on the block to be agreed upon, and perform data cleanup based on the identification information after reaching a consensus.

[0141] Among them, the transaction cleanup tree refers to a structure used to store identification information of expired transaction tasks that need to be cleaned up. For example, the transaction cleanup tree in this application can be a prefix tree structure, and the prefix tree is a multi-branch tree structure.

[0142] An expired transaction task refers to a transaction task that meets the preset expiration time. In some cases, the transaction task in this application can also be called a transaction, and an expired transaction task is called an expired transaction. For example, a user can set an expiration time for each transaction task (either an absolute time or a relative time). When the expiration time is reached, the transaction task is an expired transaction task. For example, the expiration time T set for transaction task A is 13:30 on July 16, 2023. When the time T is reached, for example, the current time is 13:31 on July 16, 2023, then the transaction task A is an expired transaction task.

[0143] The preset number refers to the number of transaction tasks that need to be encapsulated in the new block. For example, the preset number may be 100.

[0144] The target transaction task refers to the transaction task selected by the master node from the transaction pool. For example, the target transaction task in this application can be the transaction task selected by the master node from the transaction pool in order from high to low according to the processing priority corresponding to the contract of the transaction task.

[0145] Identification information refers to the identification information corresponding to the expired transaction task. The identification information corresponding to the expired transaction task in this application may include at least two types of identification information. For example, the identification information corresponding to the expired transaction task in this application may include an expired transaction identification set and an expired transaction hash value.

[0146] Specifically, take node 1 in the node cluster of the blockchain system as an example for explanation. Under the underlying blockchain model based on the BFT consensus, when node 1 participates in the consensus of the consensus block Block(1000) in this round in the blockchain, after node 1 in the node cluster determines the master node index value of the consensus block Block(1000), node 1 can compare the determined master node index value of the consensus block Block(1000) with the local node, i.e., its own index value. When the master node index value of the consensus block Block(1000) is the same as the local node, i.e., its own index value, it indicates that the local node becomes the master node in this round of consensus (round number is 0), i.e., node 1 in the node cluster determines itself. After becoming the master node, the master node generates a block. Node 1 can obtain expired transaction tasks from the transaction cleanup tree maintained by itself, and grab a preset number of target transaction tasks from the local transaction pool; Node 1 can generate a proposal message 1 for the consensus block Block (1000) based on the expired transaction tasks and the target transaction tasks, and broadcast the proposal message 1 to other nodes in the blockchain; the proposal message 1 carries the identification information of the expired transaction task, so that other nodes can reach a consensus on the consensus block Block (1000) based on the target transaction task in the proposal message 1, and perform data cleanup based on the identification information of the expired transaction task after reaching a consensus. Since the proposal message of the consensus block is generated based on the expired transaction tasks and the target transaction tasks, after the consensus block is reached, data cleanup can be automatically performed based on the identification information of the expired transaction tasks carried in the proposal message. The entire data cleanup process is through consensus and will be written in the blockchain. The data cleanup process can be completed at the same time as the consensus, which has high security and traceability. At the same time, the level of data cleanup in the blockchain can also be controlled to the transaction level, so that there is no problem even if the same chain is shared between businesses. The technical effect of ensuring the security of the entire blockchain while effectively improving the performance of the entire blockchain is achieved.

[0147] In one embodiment, the step of determining expired transaction tasks in a transaction expiration tree maintained by itself includes:

[0148] Get the first time when constructing the consensus block;

[0149] Based on the first time, determine the expired transaction tasks in the transaction cleanup tree maintained by itself.

[0150] Among them, the first time refers to the time when the block is generated, which can also be called the proposal time. For example, when the master node constructs a new block, the master node can obtain the current timestamp as t1, and t1 is the first time.

[0151] Specifically, under the underlying blockchain model based on BFT consensus, after a node (node ​​1) in the node cluster determines itself as the master node, the master node generates a block and starts this round of consensus, that is, the master node is responsible for generating proposals for the block to be consensused. When the master node (node ​​1) constructs a new block (block to be consensused), the master node (node ​​1) can obtain the current timestamp as t1: 12-01-01:01, and based on t1, search for expired transaction tasks that meet the time t1 from the transaction cleanup tree maintained by itself, that is, the master node can search for the identification information of the transaction tasks to be cleaned up to the time t1 from the transaction cleanup tree maintained by itself, which at least includes: Tx(1) and Tx(n). As a result, the expired transaction tasks to be cleaned up can be determined according to the proposal time, and the level of blockchain data cleanup can be controlled to the transaction level, so that even if the same chain is shared between businesses, there is no problem, which effectively improves the accuracy of data cleanup.

[0152] In one embodiment, the present application also provides an application scenario, which applies the above-mentioned blockchain consensus method. Specifically, the application of the blockchain consensus method in this application scenario is as follows:

[0153] When there are abnormal nodes in the blockchain, the above-mentioned blockchain consensus method can be adopted, that is, in the blockchain system, after each node in the node cluster determines the block height of the block to be agreed upon in the blockchain, each node in the node cluster can determine the offset based on the block height of the block to be agreed upon and the preset block height threshold, and determine the master node index value of the block to be agreed upon based on the offset, the number of consensus rounds of the block to be agreed upon and the number of consensus nodes in the blockchain; further, when the master node index value of the block to be agreed upon is the same as the index value of the local node, it means that the local node can become the master node in this round of consensus, that is, the master node in the node cluster can obtain the transaction task from the local transaction pool, encapsulate the transaction task into a proposal message of the block to be agreed upon, and broadcast the proposal message of the block to be agreed upon to other nodes (slave nodes) in the blockchain, so that other nodes (slave nodes) can reach consensus on the block to be agreed upon based on the transaction task in the proposal message. Therefore, through the determination method of the master node index value proposed in this application, the number of times each node becomes the master node continuously can be increased, and the performance of the Byzantine consensus is greatly improved in the case of abnormal nodes in the blockchain, thereby improving the overall consensus efficiency. That is, the blockchain consensus solution proposed in this application can solve the problem of low blockchain performance when the traditional blockchain Byzantine consensus faces abnormal nodes.

[0154] The method provided in the embodiment of the present application can be applied to various blockchain scenarios. The following is an example of a blockchain scenario based on a blockchain underlying model of a BFT-type consensus to illustrate the blockchain consensus method provided in the embodiment of the present application.

[0155] In traditional blockchain, Figure 6 As shown in Figure 1, it is a schematic diagram of the Byzantine consensus process in the blockchain. That is, the Byzantine consensus process in the blockchain system is as follows: Figure 6 As shown in the , consensus includes three stages: Proposal, Prevote, and Precommit (second round of voting) (different Byzantine algorithms may have different names, but their core processing flow is these three stages). The core points of consensus are:

[0156] 1. The master node packages and generates a proposal, and then broadcasts the proposal to the slave node for verification. The slave node will set a timeout waiting time to wait for the master node to package and generate a proposal. If there is no transaction in the blockchain at this time or the master node is down, the master node will not package and generate a proposal;

[0157] 2. The slave node receives a proposal or does not receive a proposal due to timeout, and enters the prevote stage (the master node enters the prevote stage after sending a proposal to the slave node), and then initiates a prevote vote (if the master node does not generate a proposal, or the slave node does not receive a proposal, an empty proposal vote is initiated), and broadcasts it to other nodes at the same time;

[0158] 3. If a node receives more than 2 / 3 of the prevote votes (which may be prevote votes for an empty proposal), it enters the precommit phase, generates a precommit vote (which may be a precommit vote for an empty proposal), and broadcasts it to other nodes at the same time;

[0159] 4. If a node receives more than 2 / 3 of the precommit votes, it will commit. If it finds that the consensus vote result reached before is an empty proposal, that is, the current consensus is an empty proposal, then the empty proposal will not be committed.

[0160] 5. If the consensus reached in step 4 is an empty proposal, then after the consensus is reached, each node will not increase its height by 1, but will take round+1 operation, enter a new round, switch the next node to become the master node, and start the consensus of step 1 again until a non-empty proposal consensus is reached at the current height. If a non-empty consensus is reached, the consensus will increase its height by 1 to enter a new height, and then continue the consensus from round 0 based on this height.

[0161] According to the above consensus process analysis, if a node is faulty or down, it will not generate a proposal, and other nodes will wait for a while because they have not received the proposal, and according to the above consensus process, a consensus of an empty proposal will be reached. The traditional Byzantine consensus adopts that if a consensus of an empty proposal is reached, the height will not be +1, but the round will be round+1. The purpose of this is to switch a node to become the master node, which will package and generate the proposal, so that the consensus will not be stuck due to abnormalities of some nodes.

[0162] Although the consensus process described above will not be stuck due to abnormal nodes, the master node is polled and the next node will be switched to become the master node after consensus is reached. In this way, abnormal nodes will often become the master node. This will cause other nodes to wait for the proposal to time out before casting a blank vote when the abnormal node becomes the master node, thus switching to a normal node to become the master node. Therefore, when there are faulty nodes in the blockchain network, how to improve the performance of the blockchain has become an urgent problem to be solved.

[0163] The shortcomings of traditional technology are obvious, including:

[0164] When there are abnormal nodes in the blockchain network, because the master node is polled, when the abnormal node becomes the master node, other nodes need to wait for a while before timing out and casting empty votes, and then round+1 switches a node to become the master node. Although this ensures the continued operation of the consensus, the performance of the blockchain is very low.

[0165] The traditional method of selecting the master node is calculated as follows:

[0166] proposerIndex=(height+(round%N))%N

[0167] Among them, height is the current height (the height of the block to be agreed upon), round is the round, N represents the number of consensus nodes, and the result proposerIndex is the index value of the consensus node. Through this calculation method, the Byzantine blockchain can achieve round+1 by casting a blank vote when facing a faulty node, and then use the above calculation method to obtain another node as the master node. Although this master node calculation method ensures that the Byzantine blockchain will not cause consensus to get stuck and continue to run when facing a faulty node, its problem is obvious, that is, if a faulty node occurs, it will greatly affect the performance of the entire blockchain.

[0168] like Figure 7 As shown in the figure, it is a schematic diagram of the consensus situation in the traditional method. If there are 4 consensus nodes in a blockchain network, they are sorted by node ID: node 1 (index value 0), node 2 (index value 1), node 3 (index value 2), node 4 (index value 3), among which consensus node 3 fails, and nodes 1, 2, and 4 are all normal nodes. Then the consensus situation obtained by the traditional method is as follows: Figure 7 As shown in Figure 7 As shown in the chart, it can be found that every time a consensus of 4 heights is reached, because node 3 is a faulty node, nodes 1, 2 and 4 cannot receive the proposal generated by node 3 in round 0. Nodes 1, 2 and 4 will wait for a period of time to time out before casting a blank vote (the general Byzantine consensus waiting time is 30s) and entering round 1, so that a normal node can be switched as the master node and consensus can be reached in round 1. The problem brought about by this is that as long as there are abnormal nodes in the blockchain network, the performance will be greatly affected, because every 4 heights, it will wait for a period of time to time out, resulting in poor performance of the entire blockchain, which will also lead to low consensus efficiency of the entire blockchain.

[0169] Therefore, in order to solve the above problems, this application proposes a consensus process optimization scheme for blockchain Byzantine consensus, that is, a scheme for optimizing the performance of faulty nodes under blockchain Byzantine consensus. In view of the problems existing in the traditional Byzantine consensus processing process, a scheme for optimizing the selection rules of nodes to continuously become master nodes is proposed, so as to reduce the situation where abnormal nodes become master nodes as much as possible, thereby improving the performance of Byzantine consensus. At the same time, after the faulty node returns to normal, the consensus performance can return to normal, and the risks that may exist in the scheme are processed in the process, so that when facing the existence of faulty nodes, the situation that the blockchain consensus performance is greatly reduced due to the factors of faulty nodes is reduced, and finally the purpose of improving the Byzantine consensus performance when facing abnormal nodes is achieved, and then the overall consensus efficiency of the blockchain can be effectively improved.

[0170] The key issues solved by the technical solution provided in this application include:

[0171] In view of the fact that some nodes in the blockchain network are down or abnormal due to network or node downtime or restart, in this case, according to the traditional Byzantine consensus process, the abnormal node will be selected as the master node in a round-robin manner, but the abnormal node cannot generate a proposal, so it will greatly affect the consensus performance of the blockchain. In view of this situation, a Byzantine process optimization scheme is proposed in the embodiment of the present application. By continuously generating blocks through consensus nodes, the situation where the abnormal node becomes the master node is reduced, thereby greatly improving the performance of the Byzantine blockchain in the face of node abnormalities. At the same time, the scheme provided by this application also designs a scheme for the problems that may exist under the scheme, forming a set of schemes that can fully improve the speed of blockchain consensus, which can effectively improve the overall consensus efficiency of the blockchain.

[0172] On the product side, the method provided in this application can be used as a solution to improve blockchain performance when facing abnormal nodes, and can be appropriately promoted to the outside world. It can also be implemented at the code level according to the solution in this application, and the corresponding blockchain underlying code can be optimized. It can be applied to the actual development of blockchain underlying software, and can also be used as a method of external publicity.

[0173] On the technical side, the main process is as follows:

[0174] The core of the solution provided by this application is to use 1000 heights as an interval (1000 is an empirical value, and other larger values ​​can also achieve the same effect). Using the method provided by this application, under normal circumstances, a node will be the master node for 1000 consecutive heights, and the next node will not be switched to the master node until the height of 1001. If an abnormality occurs in the node during this period, then the next node will be switched to the master node, and this node will become the master node for the remaining heights of this 1000 interval. For example, in the interval of 2001-3000, node 1 is the master node. When 2500, node 1 has an abnormality and cannot generate a proposal, then other nodes will wait for 30s and then cast a blank vote. The consensus enters the next round, and node 2 is switched to become the master node. If node 2 is a normal node, then node 2 becomes the master node for the 500 heights from 2500 to 3000. But if node 2 has an abnormality at the height of 2600, then node 3 becomes the master node for the 400 heights from 2600 to 3000.

[0175] Therefore, the improved master node calculation method provided in the embodiment of the present application is:

[0176] proposerIndex = (proposerOffset + (round % N)) % N (1)

[0177] proposerOffset=IF(height%1000=0, preProposerIndex+1, preProposerIndex)(2)

[0178] Among them, preProposerIndex represents the index value of the master node at the previous height; proposerOffset represents an offset, which is calculated based on preProposerIndex; height represents the current height (the height of the block to be agreed upon); round represents the current round; N represents the total number of consensus nodes, and the resulting proposerIndex is the index value of the consensus node.

[0179] Formula (2) means: IF height%1000=0, preProposerIndex+1, if the height reaches the interval of 1000 (ie height%1000=0), the offset is equal to preProposerIndex+1; IF height%1000≠0, preProposerIndex, if the height does not reach the interval of 1000 (ie height%1000≠0), the offset is equal to preProposerIndex. Through the above method, i.e. formula (1) and formula (2), the performance of the blockchain can be greatly improved when there are abnormal nodes.

[0180] Assume that there are 4 consensus nodes in a blockchain network, among which consensus node 2 fails, and nodes 1, 3, and 4 are normal nodes, then the consensus situation in the blockchain can be as follows: Figure 5 As shown in Figure 5 As shown in the chart, the above master node calculation method extends the number of times each node can become a master node. When there is one faulty node and three normal nodes among the four nodes, the proposal voting can be normal for 3,000 consecutive blocks. Only after generating 3,000 blocks, when node 2 becomes a faulty node and cannot generate proposals, the other three normal nodes need to wait for a period of time to cast empty votes and switch to the next node as the master node. This new master node calculation method greatly improves the processing performance of the blockchain when facing abnormal nodes.

[0181] Therefore, we still take 4 consensus nodes and node 2 as a faulty node as an example to explain the key process of selecting the improved consensus master node as follows:

[0182] 1. Determine the index values ​​of all consensus nodes:

[0183] The consensus node set NodeList is sorted by sorting the node IDs in a dictionary order. The so-called dictionary order is to form a sequence in alphabetical order or numerical order from small to large. Figure 4 As shown in , the NodeID index after the nodes are sorted is the consensus node number.

[0184] At the beginning of each consensus, the consensus list of each consensus node is the same, and the sorting method is the same, so all nodes can get the same node set sorting result. According to the index number, each node can get the same node id from its sorted node list.

[0185] Assume that the node sequence of the four consensus nodes obtained according to the dictionary sorting is: node 1 (index value 0) - node 2 (index value 1) - node 3 (index value 2) - node 4 (index value 3).

[0186] 2. Master node selection at height 1:

[0187] The first block is special because it is the first block. The previous height is 0 and there is no master node. Therefore, the master node index value of the previous height is set to 0. Therefore, at height 1 and round 0, the offset proposerOffset in formula (2) is equal to 0. According to formula (1), the index value proposerIndex of the master node at the current height 1 and round 0 is 0, which is node 1. Therefore, at height 1, the round starts at 0. At this time, the master node is node 1. It is a normal node that can generate proposals. At height 1 and round 0, it can reach a consensus and generate blocks normally.

[0188] 3. Selection of master nodes with height 2-999:

[0189] At height 2, the master node of the previous height, that is, the master node of height 1, is node 1. According to the master node calculation formula, that is, the aforementioned formula (1) and formula (2), the remainder of height (2) and 1000 is not equal to 0, so its offset proposerOffset is equal to the master node index value of height 1, that is, 0. According to formula (2), the index value proposerIndex of the master node of the current height 2 round 0 is 0, which is still node 1. Similarly, we can get that at heights 2-999, the calculated master node index values ​​are all 0, that is, the master nodes are all node 1.

[0190] 4. Selection of the master node with a height of 1000:

[0191] Height 1000 is a special height. At this time, the master node at height 999 is node 1, and the index value is 0. According to the above formula (2), the remainder of height (1000) and 1000 is equal to 0, so its offset proposerOffset is equal to the master node index value of height 999 + 1, which is equal to 1. Therefore, according to formula (1), the master node index value proposerIndex of height 1000 and round 0 is 1, which is node 2. However, because node 2 is a faulty node, it cannot generate proposals. The other three nodes need to wait for a period of time to time out and cast empty votes, so that the round of height 1000 can enter 1 to continue consensus. At this time, the offset proposerOffset is equal to 1, and the round is 1. According to the master node calculation method, the master node index value of height 1000 and round 1 is 2, which is node 3. Node 3 is a normal node and can generate proposals to reach consensus.

[0192] 5. Selection of master nodes at heights 1001-1999:

[0193] At the height of 1000, since node 2 is a faulty node, no consensus was reached at height 1000 and round 0, but the consensus was reached at round 1 when node 3 was the master node. Therefore, the master node at the previous height of 1001 is node 3, and the index value of node 3 is 2. At this time, according to the aforementioned formula (2), the remainder of the height (1001) and 1000 is not equal to 0, so its offset proposerOffset is equal to the master node index value of height 1000, which is equal to 2. According to the master node calculation formula (1), it is calculated that the master node at height 1001 and round 0 is still node 3. Similarly, the master nodes from 1001 to 1999 are all node 3.

[0194] 6. Selection of the master node with a height of 4000:

[0195] After a period of operation, the height has reached 4000. The master nodes in the height series of 1001-3999 are all normal nodes. When it reaches the height of 4000, at this time in round 0, the master node is node 2, which is a faulty node. The process at this time is the same as at the height of 1000. In round 0, other nodes time out and cast blank votes to enter round 1, and then the normal node 3 is replaced as the master node to reach a consensus.

[0196] 7. Performance analysis and comparison:

[0197] If there are 4 consensus nodes, and one of them is a faulty node, and the faulty node is the master node, the voting timeout of other nodes is 30s (generally, the timeout for waiting for proposals in the first stage of Byzantine consensus is 30s). The traditional master node selection method is compared with the improved master node selection method:

[0198] like Figure 8 As shown in the figure, it is a schematic diagram of the time consumption in the traditional method, that is, using the traditional master node selection method, the following can be obtained: Figure 8 The time consumption shown in: Figure 8 As shown in , in the traditional method, when faced with abnormal nodes, there will be a 30-second waiting time for every 4 blocks. During these 30 seconds, the entire blockchain will not reach a consensus on blocks, which has a great impact on the performance of the entire blockchain.

[0199] like Fig. 9 As shown, it is a schematic diagram of the time consumption of the Byzantine process optimization solution provided by this application. Through the new master node selection method, the following can be obtained: Fig. 9 The time consumption shown in the figure shows that when the new master node selection method faces abnormal nodes, the waiting time of 30s will appear every 3000 blocks. Figure 8 The time consumption of the traditional method shown in the figure greatly improves the performance of the blockchain.

[0200] The beneficial effects of the technical solution of this application include:

[0201] 1. This application proposes an optimization scheme for selecting the master node of the blockchain Byzantine consensus. Through a new master node calculation method, the number of times each node becomes the master node continuously can be increased. In the face of abnormal nodes, the performance of the Byzantine consensus is greatly improved.

[0202] 2. Provides a set of specific solutions to solve the problem of low blockchain performance when there are abnormal nodes in the traditional blockchain Byzantine consensus.

[0203] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0204] Based on the same inventive concept, the embodiment of the present application also provides a blockchain consensus device for implementing the blockchain consensus method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more blockchain consensus device embodiments provided below can refer to the limitations of the blockchain consensus method above, and will not be repeated here.

[0205] In one embodiment, Fig.10 As shown, a blockchain consensus device is provided, including: a determination module 1002 and a broadcast module 1004, wherein:

[0206] The determination module 1002 is used to determine the block height of the block to be agreed upon in the blockchain; determine the offset based on the block height and a preset block height threshold; and determine the master node index value of the block to be agreed upon based on the offset, the number of consensus rounds of the block to be agreed upon, and the number of nodes in the blockchain.

[0207] The broadcast module 1004 is used to broadcast the proposal message of the block to be agreed upon to other nodes in the blockchain when the master node index value of the block to be agreed upon is the same as the index value of the local node, so that the other nodes can reach a consensus on the block to be agreed upon based on the transaction tasks in the proposal message.

[0208] In one embodiment, the device also includes: an acquisition module, used to obtain a consensus node set in the blockchain; the determination module is also used to determine the index value of each node based on the node identifier of each node in the consensus node set; wherein there is a binding relationship between the node identifier and the index value.

[0209] In one embodiment, the device also includes: a sorting module, used to sort each node in the consensus node set to obtain a node sequence; the determination module is also used to determine the node number of each node based on the node identifier of each node in the node sequence; and use the node number of each node as the index value of each node.

[0210] In one embodiment, the acquisition module is further used to acquire the first block height of the local node in the blockchain; the determination module is further used to determine the block height of the block to be consensus in the blockchain based on the first block height.

[0211] In one embodiment, the acquisition module is also used to acquire the first master node index value of the first block height; the determination module is also used to determine a reference value based on the block height and a preset block height threshold; when the reference value is a first value, the offset is determined based on the first master node index value; when the reference value is not the first value, the first master node index value is used as the offset.

[0212] In one embodiment, the device further includes: a calculation module, configured to perform a modulo calculation based on the block height and a preset block height threshold to obtain a first calculation result; and use the first calculation result as the reference value.

[0213] In one embodiment, the determination module is further used to determine the sum of the first master node index value and a preset value, and use the sum as the offset.

[0214] In one embodiment, the determination module is further used to determine the number of consensus rounds for the block to be agreed upon; the calculation module is further used to perform a modulo operation based on the number of consensus rounds for the block to be agreed upon and the number of nodes in the blockchain to obtain a second calculation result; the determination module is further used to determine a target value based on the offset and the second calculation result; and determine the master node index value of the block to be agreed upon based on the target value and the number of nodes in the blockchain.

[0215] In one embodiment, the device further includes: a waiting module, which is used to wait for the node corresponding to the master node index value in the blockchain to send a proposal message of the block to be agreed upon when the master node index value of the block to be agreed upon is different from the index value of the local node; a consensus module, which is used to reach a consensus on the block to be agreed upon based on the transaction task in the received proposal message when the proposal message is received; a generation module, which is used to generate a timeout voting message for the block to be agreed upon when the proposal message is not received within a preset timeout period; and a broadcast module is also used to broadcast the timeout voting message to other nodes in the blockchain, so that the other nodes can reach a next round of consensus on the block to be agreed upon based on the timeout voting message.

[0216] In one embodiment, the determination module is also used to determine the expired transaction tasks in the transaction cleanup tree maintained by itself; the device also includes: a capture module, used to capture a preset number of target transaction tasks from the transaction pool; the generation module is also used to generate a proposal message of the block to be agreed upon based on the expired transaction tasks and the target transaction tasks; the proposal message carries the identification information of the expired transaction task, so that the other nodes can reach a consensus on the block to be agreed upon, and perform data cleanup based on the identification information after reaching a consensus.

[0217] In one embodiment, the acquisition module is further used to acquire the first time when constructing the block to be agreed upon; the determination module is further used to determine the expired transaction tasks in the transaction clearing tree maintained by itself based on the first time.

[0218] Each module in the above blockchain consensus device can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute the operations corresponding to each module above.

[0219] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Fig.11 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store blockchain consensus data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a blockchain consensus method is implemented.

[0220] Those skilled in the art will understand that Fig.11 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0221] In one embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above-mentioned method embodiments when executing the computer program.

[0222] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0223] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0224] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0225] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0226] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0227] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A blockchain consensus method, characterized in that: The method comprises: Determine the block height of the block to be agreed upon in the blockchain; Determining an offset based on the block height and a preset block height threshold; Determine the master node index value of the block to be agreed upon based on the offset, the number of consensus rounds of the block to be agreed upon, and the number of nodes in the blockchain; When the master node index value of the block to be agreed upon is the same as the index value of the local node, the proposal message of the block to be agreed upon is broadcast to other nodes in the blockchain, so that the other nodes can reach a consensus on the block to be agreed upon based on the transaction tasks in the proposal message.

2. The method according to claim 1, characterized in that Before determining the block height of the block to be agreed upon in the blockchain, the method further includes: Obtain a consensus node set in the blockchain; Based on the node identifier of each node in the consensus node set, an index value of each node is determined; wherein there is a binding relationship between the node identifier and the index value.

3. The method according to claim 2, characterized in that The determining the index value of each node based on the node identifier of each node in the consensus node set includes: Sort the nodes in the consensus node set to obtain a node sequence; Determining a node number of each node based on a node identifier of each node in the node sequence; The node number of each node is used as the index value of each node.

4. The method according to claim 1, characterized in that Determining the block height of the block to be agreed upon in the blockchain includes: Obtaining the first block height of the local node in the blockchain; The block height of the block to be agreed upon in the blockchain is determined based on the first block height.

5. The method according to claim 4, characterized in that The method further comprises: Obtain the first master node index value of the first block height; The determining the offset based on the block height and a preset block height threshold includes: Determining a reference value based on the block height and a preset block height threshold; When the reference value is a first value, determining the offset based on the first master node index value; When the reference value is not the first value, the first master node index value is used as the offset.

6. The method according to claim 5, characterized in that The determining of a reference value based on the block height and a preset block height threshold comprises: Performing a modulo operation based on the block height and a preset block height threshold to obtain a first operation result; The first operation result is used as the reference value.

7. The method according to claim 5, characterized in that The determining the offset based on the first master node index value includes: Determine the sum of the first master node index value and a preset value, and use the sum as the offset.

8. The method according to claim 1, characterized in that After determining the offset based on the block height and the preset block height threshold, the method further includes: Determine the number of consensus rounds for the block to be agreed upon; The determining the master node index value of the block to be agreed upon based on the offset, the number of consensus rounds of the block to be agreed upon, and the number of nodes in the blockchain includes: Perform a modulo operation based on the number of consensus rounds of the block to be agreed upon and the number of nodes in the blockchain to obtain a second operation result; Determining a target value based on the offset and the second operation result; Based on the target value and the number of nodes in the blockchain, the master node index value of the block to be agreed upon is determined.

9. The method according to claim 1, characterized in that: After determining the master node index value of the block to be agreed upon, the method further includes: When the master node index value of the block to be agreed upon is different from the index value of the local node, wait for the node corresponding to the master node index value in the blockchain to send a proposal message of the block to be agreed upon; When the proposal message is received, consensus is performed on the block to be agreed upon based on the transaction task in the received proposal message; When the proposal message is not received within the preset timeout period, a timeout voting message for the block to be agreed upon is generated, and the timeout voting message is broadcast to other nodes in the blockchain, so that the other nodes can perform the next round of consensus on the block to be agreed upon based on the timeout voting message.

10. The method according to claim 1, characterized in that Before broadcasting the proposal message of the block to be agreed upon to other nodes in the blockchain, the method further includes: Determine the expired transaction tasks in the transaction cleanup tree maintained by itself; Grab a preset number of target trading tasks from the trading pool; A proposal message of the block to be agreed upon is generated based on the expired transaction task and the target transaction task; the proposal message carries identification information of the expired transaction task, so that the other nodes can reach a consensus on the block to be agreed upon, and perform data cleanup based on the identification information after reaching a consensus.

11. The method according to claim 10, characterized in that The determining of expired transaction tasks in the transaction expiration tree maintained by itself includes: When constructing the block to be agreed upon, obtaining the first time; Based on the first time, determine the expired transaction tasks in the transaction cleanup tree maintained by itself.

12. A blockchain consensus device, characterized in that: The device comprises: A determination module is used to determine the block height of the block to be agreed upon in the blockchain; determine the offset based on the block height and a preset block height threshold; determine the master node index value of the block to be agreed upon based on the offset, the number of consensus rounds of the block to be agreed upon, and the number of nodes in the blockchain; The broadcast module is used to broadcast the proposal message of the block to be agreed upon to other nodes in the blockchain when the master node index value of the block to be agreed upon is the same as the index value of the local node, so that the other nodes can reach a consensus on the block to be agreed upon based on the transaction tasks in the proposal message.

13. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 11 are implemented.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 11 are implemented.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 11 are implemented.

Images