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: when entering a consensus round for a to-be-consensus block of a first block height in a block chain, searching a proposal message corresponding to the first block height from a cache mapping table, and generating a first pre-voting message based on the proposal message; searching a cache mapping table for a second pre-voting message corresponding to the first block height; when the first pre-voting message and the second pre-voting message meet a preset voting threshold value, generating a first voting message, and searching a cache mapping table for a second voting message corresponding to the first block height; and when the first voting message and the second voting message meet a preset voting threshold value, storing the to-be-consensus block of the first block height into a local account book. By adopting the method, the consensus efficiency of the block chain can be effectively 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 reasons such as network or node downtime or restart, the consensus status of some nodes in the blockchain network lags behind other normal nodes. In the traditional blockchain consensus process, when the lagging node receives a consensus message from other nodes that is higher than the current consensus status of the node, it will directly ignore or discard the message that does not belong to the current consensus step. After the node enters the corresponding consensus state, it will wait for other nodes to resend the required consensus message to the node. Although this ensures the continuation of the consensus process, the performance of the blockchain is very low. This waiting process will affect the consensus performance of the blockchain, and thus lead 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: when entering the consensus round for a consensus block of a first block height in the blockchain, searching a proposal message corresponding to the first block height from a cache mapping table, and generating a first pre-voting message based on the proposal message; searching a second pre-voting message corresponding to the first block height from the cache mapping table; when the first pre-voting message and the second pre-voting message meet a preset voting threshold, generating a first voting message, and searching a second voting message corresponding to the first block height from the cache mapping table; wherein the second pre-voting message and the second voting message are sent by other nodes in the blockchain; when the first voting message and the second voting message meet the preset voting threshold, storing the consensus block of the first block height in the local account book.

[0006] In the second aspect, the present application also provides a blockchain consensus device. The device includes: a search module, which is used to search for a proposal message corresponding to the first block height from the cache mapping table when entering the consensus round for the consensus block to be agreed upon at the first block height in the blockchain; a generation module, which is used to generate a first pre-voting message based on the proposal message; the search module is also used to search for a second pre-voting message corresponding to the first block height from the cache mapping table; the generation module is also used to generate a first voting message when the first pre-voting message and the second pre-voting message meet a preset voting threshold; the search module is also used to search for a second voting message corresponding to the first block height from the cache mapping table; wherein the second pre-voting message and the second voting message are sent by other nodes in the blockchain; a storage module, which is used to store the consensus block to be agreed upon at the first block height in the local account book when the first voting message and the second voting message meet the preset voting threshold.

[0007] In the 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: when entering the consensus round for the consensus block to be reached at the first block height in the blockchain, find the proposal message corresponding to the first block height from the cache mapping table, and generate a first pre-voting message based on the proposal message; find the second pre-voting message corresponding to the first block height from the cache mapping table; when the first pre-voting message and the second pre-voting message meet the preset voting threshold, generate a first voting message, and find the second voting message corresponding to the first block height from the cache mapping table; wherein the second pre-voting message and the second voting message are sent by other nodes in the blockchain; when the first voting message and the second voting message meet the preset voting threshold, store the consensus block to be reached at the first block height in the local account book.

[0008] In a fourth aspect, the present application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, and when the computer program is executed by a processor, the following steps are implemented: when entering the consensus round for the consensus block to be reached at the first block height in the blockchain, find the proposal message corresponding to the first block height from the cache mapping table, and generate a first pre-voting message based on the proposal message; find the second pre-voting message corresponding to the first block height from the cache mapping table; when the first pre-voting message and the second pre-voting message meet the preset voting threshold, generate a first voting message, and find the second voting message corresponding to the first block height from the cache mapping table; wherein the second pre-voting message and the second voting message are sent by other nodes in the blockchain; when the first voting message and the second voting message meet the preset voting threshold, store the consensus block to be reached at the first block height in the local account book.

[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: when entering the consensus round for a block to be consensused at a first block height in a blockchain, searching a proposal message corresponding to the first block height from a cache mapping table, and generating a first pre-voting message based on the proposal message; searching a second pre-voting message corresponding to the first block height from the cache mapping table; when the first pre-voting message and the second pre-voting message meet a preset voting threshold, generating a first voting message, and searching a second voting message corresponding to the first block height from the cache mapping table; wherein the second pre-voting message and the second voting message are sent by other nodes in the blockchain; when the first voting message and the second voting message meet a preset voting threshold, storing the block to be consensused at the first block height in a local ledger.

[0010] The above-mentioned blockchain consensus method, apparatus, computer equipment, storage medium and computer program product, when entering the consensus round for the consensus block to be agreed upon at the first block height in the blockchain, searches for a proposal message corresponding to the first block height from the cache mapping table, and generates a first pre-voting message based on the proposal message; searches for a second pre-voting message corresponding to the first block height from the cache mapping table; when the first pre-voting message and the second pre-voting message meet the preset voting threshold, generates a first voting message, and searches for a second voting message corresponding to the first block height from the cache mapping table; wherein the second pre-voting message and the second voting message are sent by other nodes in the blockchain; when the first voting message and the second voting message meet the preset voting threshold, stores the consensus block to be agreed upon at the first block height in the local account book. Since proposal messages, pre-voting messages and voting messages corresponding to different block heights can be cached in the cache mapping table, when entering the consensus round for the consensus block to be reached at the first block height in the blockchain, the proposal message corresponding to the first block height can be preferentially searched from the cache mapping table. After generating the first pre-voting message based on the proposal message, the second pre-voting message corresponding to the first block height can also be preferentially searched from the cache mapping table. After generating the first voting message, the second voting message corresponding to the first block height can also be preferentially searched from the cache mapping table. That is, in the process of consensus on the consensus block, the required messages can be quickly collected in each consensus step, so that the next consensus stage can be entered as soon as possible, thereby effectively improving the consensus speed, and then effectively improving the consensus efficiency of the blockchain, and at the same time, it can also improve the processing performance 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 the structure of a cache mapping table for caching consensus messages in one embodiment;

[0015] Figure 5 A schematic diagram of a processing flow when a node receives a consensus message of a future height in one embodiment;

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

[0017] Figure 7 A schematic diagram of the consensus process of a blockchain Byzantine consensus message caching solution in one embodiment;

[0018] Figure 8 A schematic diagram of a process of clearing cache of a node in one embodiment;

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

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

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

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

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

[0024] Take the distributed system as the blockchain system as an example, see Figure 1 , Figure 1 It 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.

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

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

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

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

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

[0030] 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;

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

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

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

[0034] See also Figure 2 , Figure 2This 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.

[0035] 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:

[0036] Step 302, when entering the consensus round for the consensus block to be reached at the first block height in the blockchain, search the cache mapping table for a proposal message corresponding to the first block height, and generate a first pre-voting message based on the proposal message.

[0037] 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. The blockchain, or blockchain system, is a distributed system in which the number of nodes 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 fault-tolerant range) are abnormal, the entire blockchain system can still operate normally, but some consensus nodes in the blockchain lag behind other normal nodes due to network anomalies or slow consensus message processing. At this time, the lagging node receives a consensus message from other nodes that is higher than the current consensus state of the node. The traditional Byzantine consensus will directly ignore or discard the message that does not belong to the current consensus step, wait for the node to enter the corresponding consensus state, and then wait for other nodes to resend the consensus message required for the current consensus step to itself (this node). Therefore, the solution provided in the present application is mainly aimed at the problem that when a lagging node receives a consensus message from other nodes with a higher consensus status than its own (this node) and the consensus message is not yet needed in the current consensus step, how should the lagging node handle the consensus message to avoid affecting the consensus efficiency? This solution is proposed to optimize the Byzantine consensus process.

[0038] 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 consensus. Among them, BFT (Byzantine Fault Tolerance), that is, Byzantine Fault Tolerance, is a consensus mechanism.

[0039] A pending consensus block refers to a block that has not been agreed upon by the blockchain network. For example, a new block is generated 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 pending consensus block.

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

[0041] The block to be agreed upon of the first block height refers to the block to be agreed upon with the first block height as the block height. 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, i.e., the block to be agreed upon with a block height of 7. Then the block to be agreed upon of the first block height refers to the block to be agreed upon with a block height of 7.

[0042] The consensus round refers to the round of consensus on the consensus block. For example, when consensus is reached on consensus block Block(6) for the first time, the round of consensus is 0; when consensus is reached on consensus block Block(6) for the second time, the round of consensus is 1.

[0043] The cache mapping table refers to a table used to cache consensus messages required for the future consensus stage. For example, the structure of the cache mapping table in this application can be similar to a map mapping table. In this cache mapping table, the height is used as the key, and the value is a structure that stores consensus messages. This structure contains consensus messages such as the proposal propsoal, prevote, and precommit of this height. Figure 4 As shown in FIG. 1 , it is a schematic diagram of the structure of the cache mapping table used to cache consensus messages. Figure 4 As shown in the figure, the block height (height) is used as the key, and the value corresponding to each block height (key) is a structure that stores consensus messages. This structure contains consensus messages at different consensus stages, such as the proposal message propsoal, pre-voting message prevote, and pre-commit voting message (also called voting message) precommit for each height.

[0044] A proposal message is a communication message between nodes in a blockchain. For example, a communication message may also include a voting message, a pre-voting message, etc. 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).

[0045] The proposal message corresponding to the first block height refers to the proposal message for the consensus-pending block at the first block height. For example, when the consensus-pending block at the first block height is consensus-pending block Block(6), the proposal message corresponding to the first block height refers to the proposal message for consensus-pending block Block(6) at block height 6.

[0046] The first pre-voting message refers to the pre-voting message generated by this node based on the proposal message. In some cases, the pre-voting message in this application can also be called a prevote vote.

[0047] 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; further, each node in the node cluster can determine the first block height of the 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, and enter the consensus round for the block to be agreed upon with the first block height in the blockchain, that is, each node in the node cluster starts the process of consensus on the block to be agreed upon with the first block height in the blockchain. When each node in the node cluster enters the consensus round for the consensus block to be reached at the first block height in the blockchain, each node in the node cluster can preferentially search for the proposal message corresponding to the first block height from the cache mapping table maintained by itself. If each node in the node cluster finds the proposal message corresponding to the first block height from the cache mapping table maintained by itself, then each node in the node cluster can directly enter the next stage of the consensus process, that is, enter the prevote stage in the consensus process, and each node in the node cluster can generate a first pre-voting message based on the found proposal message; if each node in the node cluster does not find the proposal message corresponding to the first block height from the cache mapping table maintained by itself, then each node in the node cluster needs to wait for the master node in the node cluster to send a proposal message for the consensus block to be reached at the first block height.

[0048] 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 it maintains, and determines the first block height of the next consensus block to be H1 based on the block height H0. For example, node A can determine the block height of the consensus block Block (6) to be H1=H0+1=5+1=6 based on the current maximum block height H0=5. Furthermore, when node A enters the consensus round for the consensus block Block(6) with a block height of 6 in the blockchain, node A can preferentially search for the proposal message corresponding to the block height H1=6 from the cache mapping table maintained by itself. If node A finds the proposal message A corresponding to the block height H1=6 from the cache mapping table maintained by itself, node A can directly enter the next consensus stage, namely the prevote stage, and generate a first pre-voting message based on the found proposal message A. If node A does not find the proposal message A corresponding to the block height H1=6 from the cache mapping table maintained by itself, node A needs to wait for the master node in the node cluster to send the proposal message A for the consensus block Block(6) with a block height H1=6. When node A receives the proposal message A for the consensus block Block(6) with a block height H1=6 sent by the master node in the node cluster, it can enter the next stage of the consensus process, namely, node A can enter the prevote stage.

[0049] Step 304: search the cache mapping table for a second pre-voting message corresponding to the first block height.

[0050] The second pre-voting message refers to the pre-voting message generated by other nodes in the node cluster except the current node based on the proposal message. It can be understood that the first pre-voting message and the second pre-voting message in this application are only used to distinguish the pre-voting messages generated by different nodes.

[0051] The second pre-voting message corresponding to the first block height refers to the pre-voting message generated by the other nodes in the node cluster except the current node for the proposal message of the block to be agreed upon at the first block height. For example, when the block to be agreed upon at the first block height is the block to be agreed upon Block(6), the second pre-voting message corresponding to the first block height refers to the pre-voting message generated by the other nodes in the node cluster except the current node based on the proposal message of the block to be agreed upon Block(6) at the block height 6.

[0052] Specifically, after each node in the node cluster finds the proposal message corresponding to the first block height from the cache mapping table maintained by itself and generates the first pre-voting message based on the found proposal message, each node in the node cluster can continue to search for the second pre-voting message corresponding to the first block height from the cache mapping table maintained by itself, that is, each node in the node cluster can preferentially search for the second pre-voting message sent by other nodes corresponding to the first block height from the cache mapping table maintained by itself. If each node in the node cluster finds the second pre-voting message corresponding to the first block height from the cache mapping table maintained by itself, then each node in the node cluster can calculate the total number of the first pre-voting messages and the second pre-voting messages obtained, and determine whether the total number meets the preset voting threshold. In this way, the technical effect of advancing the consensus process faster can be achieved, accelerating the overall consensus processing performance of the blockchain, and thereby improving the consensus efficiency of the entire blockchain.

[0053] In addition, if each node in the node cluster fails to find the second pre-voting message corresponding to the first block height from the cache mapping table maintained by itself, or when each node in the node cluster determines that the total number of the first pre-voting messages and the second pre-voting messages obtained does not meet the preset voting threshold, then each node in the node cluster needs to wait for other nodes to send (reissue) the second pre-voting message for the first block height until each node in the node cluster determines that the total number of the first pre-voting messages and the second pre-voting messages obtained meets the preset voting threshold before entering the next stage of the consensus process, that is, entering the precommit stage.

[0054] 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, when node A enters the consensus round for the consensus block Block (6) with a block height of 6 in the blockchain, and node A finds the proposal message A corresponding to the block height H1=6 from the cache mapping table maintained by itself, node A can directly enter the prevote stage, and generate a first pre-voting message based on the found proposal message A; further, node A can preferentially find the second pre-voting message sent by other nodes corresponding to the block height 6 from the cache mapping table maintained by itself. If node A finds the second pre-voting message corresponding to the block height 6 from the cache mapping table maintained by itself, node A can calculate the total number of the first pre-voting message and the second pre-voting message obtained, and determine whether the total number meets the preset voting threshold; if the total number meets the preset voting threshold, node A can directly enter the next stage of the consensus process, that is, enter the precommit stage. Otherwise, node A needs to wait for other nodes to send (reissue) the second pre-voting message for block height 6 until the total number of the first pre-voting message and the second pre-voting message obtained by node A meets the preset voting threshold before entering the next stage of the consensus process, that is, entering the precommit stage.

[0055] Step 306: When the first pre-voting message and the second pre-voting message meet the preset voting threshold, a first voting message is generated, and a second voting message corresponding to the first block height is searched from the cache mapping table; wherein the second pre-voting message and the second voting message are sent by other nodes in the blockchain.

[0056] Among them, the preset voting threshold refers to a preset threshold for screening the number of voting messages in different consensus stages. For example, the preset voting threshold in the present application can be set to: more than 2 / 3 of the number of nodes, that is, when the total number of pre-voting messages (or voting messages) received by each node in the node cluster exceeds 2 / 3 of the number of nodes in the blockchain, it means that the total number of the first pre-voting message and the second pre-voting message meets the preset voting threshold.

[0057] The second voting message refers to the pre-voting message generated by other nodes in the node cluster except the current node based on the proposal message. It can be understood that the first pre-voting message and the second pre-voting message in this application are only used to distinguish the pre-voting messages generated by different nodes.

[0058] Other nodes refer to nodes other than the current node in the node cluster. For example, if the current node is node A, other nodes refer to nodes other than node A in the node cluster.

[0059] Specifically, after each node in the node cluster searches for the second pre-voting message corresponding to the first block height from the cache mapping table, each node in the node cluster can calculate the total number of the first pre-voting messages and the second pre-voting messages that have been obtained, and determine whether the total number meets the preset voting threshold; when the total number meets the preset voting threshold, each node in the node cluster can directly enter the next stage of the consensus process, that is, enter the precommit stage, each node in the node cluster can generate a first voting message, and search for the second voting message corresponding to the first block height from the cache mapping table; if each node in the node cluster finds the second pre-voting message corresponding to the first block height from the cache mapping table, Voting message, each node in the node cluster can calculate the total number of the first voting message and the second voting message obtained (total number = the number of the first voting message + the number of the second voting message), and determine whether the total number meets the preset voting threshold; if each node in the node cluster does not find the second voting message corresponding to the first block height from the cache mapping table, then each node in the node cluster needs to wait for other nodes to send (reissue) the second voting message for the first block height, until each node in the node cluster determines that the total number of the first voting message and the second voting message obtained meets the preset voting threshold, the consensus block of the first block height can be stored in the local account book of each node. Among them, the second pre-voting message and the second voting message in this application are voting messages sent by other nodes in the blockchain except this node. In this application, the pre-voting message can be understood as the voting message of the first round, and the voting message can be understood as the voting message of the second round.

[0060] In addition, when the total number does not meet the preset voting threshold, each node in the node cluster needs to wait for other nodes to send a second pre-voting message for the first block height until each node in the node cluster determines that the total number of the first pre-voting messages and the second pre-voting messages obtained meets the preset voting threshold. Only then can the consensus block to be held at the first block height be stored in the local ledger of each node.

[0061] 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, when node A enters the consensus round for the consensus block Block(6) with a block height of 6 in the blockchain and node A enters the precommit stage, node A can generate a first voting message and preferentially search for the second voting message sent by other nodes corresponding to block height 6 from the cache mapping table; if node A finds the second voting message sent by other nodes corresponding to block height 6 from the cache mapping table, node A can calculate the total number of the first voting messages and the second voting messages obtained, and determine whether the total number meets the preset voting threshold; if node A does not find the second voting message sent by other nodes corresponding to block height 6 from the cache mapping table, node A needs to wait for other nodes to send (or resend) the second voting message for block height 6, until node A determines that the total number of the first voting messages and the second voting messages obtained meets the preset voting threshold, then node A can store the consensus block Block(6) with block height 6 in the local account book of node A.

[0062] Step 308: When the first voting message and the second voting message meet the preset voting threshold, the consensus block at the first block height is stored in the local account book.

[0063] Among them, the local ledger refers to the local ledger of a node in the node cluster. In this application, the local ledger can also be understood as the local blockchain maintained by each node itself.

[0064] Specifically, after each node in the node cluster generates a first voting message and searches for a second voting message corresponding to the first block height from a cache mapping table maintained by itself, each node in the node cluster can calculate the total number of first voting messages and second voting messages obtained, and determine whether the total number meets the preset voting threshold. When the total number meets the preset voting threshold, it means that the first voting message and the second voting message meet the preset voting threshold, and a consensus is reached on the consensus block of the first block height. Each node in the node cluster can store the consensus block of the first block height in a local ledger maintained by itself.

[0065] For example, let’s take node A in the node cluster of the blockchain system as an example. In the underlying blockchain model based on the BFT consensus, when node A enters the consensus round for the consensus block Block(6) with a block height of 6 in the blockchain and node A enters the precommit stage, node A can generate a first voting message and preferentially search for the second voting message sent by other nodes corresponding to the block height 6 from the cache mapping table; if node A finds the second voting message sent by other nodes corresponding to the block height 6 from the cache mapping table, node A can calculate the total number of the first voting messages and the second voting messages obtained, and determine whether the total number meets the preset voting threshold; if node A does not find the second voting message sent by other nodes corresponding to the block height 6 from the cache mapping table, node A needs to wait for other nodes to send (or resend) the second voting message for the block height 6, until node A determines that the total number of the first voting messages and the second voting messages obtained meets the preset voting threshold, indicating that the consensus block with the first block height has reached a consensus, that is, node A can store the consensus block Block(6) with the block height 6 in the local account book maintained by itself.

[0066] In this embodiment, when entering the consensus round for the consensus block to be reached at the first block height in the blockchain, a proposal message corresponding to the first block height is searched from the cache mapping table, and a first pre-voting message is generated based on the proposal message; a second pre-voting message corresponding to the first block height is searched from the cache mapping table; when the first pre-voting message and the second pre-voting message meet the preset voting threshold, a first voting message is generated, and the second voting message corresponding to the first block height is searched from the cache mapping table; wherein the second pre-voting message and the second voting message are sent by other nodes in the blockchain; when the first voting message and the second voting message meet the preset voting threshold, the consensus block to be reached at the first block height is stored in the local account book. Since proposal messages, pre-voting messages and voting messages corresponding to different block heights can be cached in the cache mapping table, when entering the consensus round for the consensus block to be reached at the first block height in the blockchain, the proposal message corresponding to the first block height can be preferentially searched from the cache mapping table. After generating the first pre-voting message based on the proposal message, the second pre-voting message corresponding to the first block height can also be preferentially searched from the cache mapping table. After generating the first voting message, the second voting message corresponding to the first block height can also be preferentially searched from the cache mapping table. That is, in the process of consensus on the consensus block, the required messages can be quickly collected in each consensus step, so that the next consensus stage can be entered as soon as possible, thereby effectively improving the consensus speed, and then effectively improving the consensus efficiency of the blockchain, and at the same time, it can also improve the processing performance of the entire blockchain.

[0067] In one embodiment, before entering into a consensus round for a block to be agreed upon at a first block height in a blockchain, the method further includes:

[0068] When entering the consensus round for the consensus block to be agreed upon at the second block height in the blockchain and receiving a consensus message sent by other nodes in the blockchain, comparing the second block height with the message height carried by the consensus message; wherein the second block height is less than the first block height, and the consensus message includes a proposal message, a second pre-voting message, and a second voting message;

[0069] When the second block height is less than the message height, the consensus message is stored in the cache mapping table so that the consensus message can be obtained from the cache mapping table when consensus is reached on the block to be agreed upon with the same height as the message.

[0070] Among them, the block to be agreed upon of the second block height refers to the block to be agreed upon whose block height is the second block height. It can be understood that the block to be agreed upon of the first block height and the block to be agreed upon of the second block height in this application are only used to distinguish the blocks to be agreed upon of different heights.

[0071] The message height carried by the consensus message is used to identify the block height for which the consensus message is targeted. For example, the message height carried in consensus message 1 is 6, indicating that consensus message 1 is a consensus message in the consensus process for the consensus block to be reached at block height 6.

[0072] The second block height is less than the first block height, indicating that the block to be agreed upon at the second block height in the present application is a previous block of the block to be agreed upon at the first block height. For example, the block to be agreed upon at the second block height is Block(5), and the block to be agreed upon at the first block height is Block(6). Block(5) is the previous block of Block(6), i.e., the previous block.

[0073] Specifically, take node A in the node cluster of the blockchain system as an example. Under the underlying blockchain model based on the BFT consensus, before node A enters the consensus round for the consensus block Block(6) with a block height of 6 in the blockchain, node A will first reach a consensus on the consensus block Block(5) with a block height of 5. That is, when node A enters the consensus round for the consensus block Block(5) with a block height of 5 in the blockchain and receives a consensus message sent by other nodes in the blockchain, Figure 5As shown in FIG. 1 , it is a schematic diagram of the processing flow when a node receives a consensus message of a future height. Node A can compare the second block height with the message height carried by the received consensus message; wherein the consensus message can be at least one of a proposal message, a second pre-voting message, or a second voting message; assuming that the message height carried by a consensus message A sent by other nodes in the blockchain received by node A is 6, as shown in FIG. Figure 5 In the processing flow shown in , when the second block height (5) is less than the message height (6), node A can store the consensus message A in the cache mapping table maintained by itself, so that when node A reaches consensus on the block to be agreed upon Block (6) with the same message height (6), node A can directly obtain the consensus message A from the cache mapping table without waiting for other nodes to resend the consensus message A.

[0074] In this embodiment, consensus messages that may be needed in the future are cached to avoid message discard and waste, and the lag effect caused by the resending of consensus messages is effectively reduced, thereby improving the performance of the Byzantine consensus and reducing the occupancy of network bandwidth. While effectively improving the consensus efficiency of the blockchain, it can also effectively improve the processing performance of the entire blockchain.

[0075] In one embodiment, after comparing the second block height with the message height carried by the consensus message, the method further includes:

[0076] When the second block height is greater than the message height, the consensus message is discarded.

[0077] Specifically, take node A in the node cluster of the blockchain system as an example. Under the underlying blockchain model based on the BFT consensus, before node A enters the consensus round for the consensus block Block(6) with a block height of 6 in the blockchain, node A will first reach a consensus on the consensus block Block(5) with a block height of 5. That is, when node A enters the consensus round for the consensus block Block(5) with a block height of 5 in the blockchain and receives a consensus message sent by other nodes in the blockchain, Figure 5 As shown in FIG. 1 , it is a schematic diagram of the processing flow when a node receives a consensus message of a future height. Node A can compare the second block height with the message height carried by the received consensus message; wherein, the consensus message can be at least one of a proposal message, a second pre-voting message, or a second voting message; assuming that the message height carried by a consensus message B sent by other nodes in the blockchain received by node A is 4, as shown in FIG. Figure 5In the processing flow shown in , when the block height (5) is greater than the message height (4), node A can discard the consensus message B, that is, node A will not store the consensus message B in the cache mapping table maintained by itself. Therefore, by caching the consensus messages that may be needed in the future and discarding the consensus messages that are not needed in the future, it is possible to effectively avoid the discarding and waste of messages, reduce the lag caused by the re-issuance of consensus messages, thereby improving the performance of the Byzantine consensus and reducing the occupation of network bandwidth. While effectively improving the consensus efficiency of the blockchain, it can also effectively improve the processing performance of the entire blockchain.

[0078] In one embodiment, the step of storing the consensus message in the cache mapping table includes:

[0079] Based on the message height carried by the consensus message, a key-value pair structure corresponding to the message height is constructed in the cache mapping table;

[0080] The message height carried by the consensus message is used as the key and the consensus message is used as the value to store them in the key-value pair structure of the cache mapping table.

[0081] Among them, in the technical solution of this application, each node in the node cluster uses the height as the key in the key-value pair structure and the consensus message as the value in the key-value pair structure for storage, such as Figure 4 As shown in , the key-value pair structure constructed for different heights includes a structure for storing the height and a structure for storing consensus messages at different stages corresponding to the height.

[0082] Specifically, take node A in the node cluster of the blockchain system as an example. Under the underlying blockchain model based on BFT consensus, when node A enters the consensus round for the consensus block Block(5) with block height 5 in the blockchain and receives a consensus message A sent by other nodes in the blockchain, node A can compare the block height (5) with the message height (6) carried by the received consensus message A. When the block height (5) is less than the message height (6), node A can store the consensus message A in the cache mapping table maintained by itself, that is, node A can store the consensus message A in the cache mapping table maintained by itself based on the message height (6) carried by the consensus message. Figure 4 In the cache mapping table shown in FIG. 1 , a key-value pair structure corresponding to the message height (6) is constructed, and the message height (6) carried by the consensus message is used as the key and the specific content of the consensus message is used as the value. Figure 4In the key-value pair structure of the height (6) in the cache mapping table shown in . As a result, by constructing the key-value pair structure corresponding to different heights in the cache mapping table, the consensus message of each height can be cached. When a message not needed at the current height is received, it can be placed in the corresponding cache according to the height of the consensus message. When entering a new height, each consensus step can first obtain the message from the cache mapping table to see if there is a cached consensus message. If there is one in the cache mapping table, it can be used directly, which effectively avoids the discarding and waste of messages and reduces the lag caused by the re-issuance of consensus messages, thereby improving the performance of the Byzantine consensus and reducing the occupation of network bandwidth. While effectively improving the consensus efficiency of the blockchain, it can also effectively improve the processing performance of the entire blockchain.

[0083] In one embodiment, after comparing the second block height with the message height carried by the consensus message, the method further includes:

[0084] When the second block height is equal to the message height, determine the first consensus stage at the current moment and the second consensus stage corresponding to the consensus message;

[0085] When the second consensus stage is after the first consensus stage, the consensus message structure corresponding to the second block height is searched from the cache mapping table;

[0086] Storing the consensus message in a target location in the consensus message structure so that the consensus message can be obtained from the cache mapping table when entering the second consensus phase for the consensus block to be reached at the second block height;

[0087] Among them, the second block height is used as the key and the consensus message structure corresponding to the second block height is stored in the cache mapping table as the value.

[0088] Among them, the first consensus stage refers to the consensus stage of the consensus process currently in progress, and the second consensus stage refers to the consensus stage corresponding to the received consensus message. It can be understood that the first consensus stage and the second consensus stage in this application are only used to distinguish the consensus stage of the consensus process currently in progress and the consensus stage corresponding to the consensus message. The first consensus stage and the second consensus stage can be the same stage or different stages. For example, the first consensus stage of the current consensus process can be the precommit stage, and the second consensus stage corresponding to the consensus message can also be the precommit stage.

[0089] The consensus message structure refers to the structure used to store the specific content of the consensus message. For example, the consensus message structure in this application can be Figure 4In the structure within the rectangular box corresponding to each height shown in , the consensus message structure stores the consensus message corresponding to the height according to different consensus stages. For example, the consensus message belonging to the proposal stage is stored in the first position, the consensus message belonging to the prevote stage is stored in the second position, and the consensus message belonging to the precommit stage is stored in the third position.

[0090] Specifically, take node A in the node cluster of the blockchain system as an example. Under the underlying blockchain model based on BFT consensus, when node A enters the consensus round for the consensus block Block(5) with block height 5 in the blockchain and receives consensus message A sent by other nodes in the blockchain, node A can compare the block height (5) with the message height (5) carried by the received consensus message A. When the block height (5) is equal to the message height (5), node A can further compare the relationship between the first consensus stage at the current moment and the second consensus stage corresponding to the consensus message A. That is, when the block height (5) is equal to the message height (5), node A can further determine the first consensus stage at the current moment and the second consensus stage corresponding to the consensus message A. Assuming that the second consensus stage (precommit stage) is after the first consensus stage (prevote stage), indicating that the consensus message A is a message that will be used in the next stage (precommit stage), node A can use the message height (5) maintained by itself to determine the relationship between the first consensus stage and the second consensus stage corresponding to the consensus message A. Figure 4 The cache mapping table shown in FIG. 1 is used to search for the consensus message structure corresponding to the block height (5), and the consensus message A is stored in the second position of the consensus message structure corresponding to the block height (5) for storing the precommit stage consensus message, so that when node A enters the second consensus stage (precommit stage) for the block to be consensused at the block height (5), node A can directly use the consensus message structure maintained by itself. Figure 4 The consensus message A is obtained in the cache mapping table shown in FIG. 1 , where the block height (5) is used as the key and the consensus message structure corresponding to the block height (5) is stored as the value in FIG. Figure 4 The cache mapping table is shown.

[0091] In this embodiment, by constructing a key-value pair structure corresponding to different heights in the cache mapping table, consensus messages at each height can be cached. When a message that is not needed at the current height is received, it can be placed in the corresponding cache according to the height of the consensus message. When entering a new height, each consensus step can preferentially obtain messages from the cache mapping table to see if there are cached consensus messages. If there are cached consensus messages, they can be used directly, effectively avoiding the discarding and waste of messages and reducing the lag caused by the resending of consensus messages, thereby improving the performance of the Byzantine consensus and reducing the occupancy of network bandwidth. While effectively improving the consensus efficiency of the blockchain, it can also effectively improve the processing performance of the entire blockchain.

[0092] In one embodiment, after determining the first consensus stage at the current moment and the second consensus stage corresponding to the consensus message, the method further includes:

[0093] When the second consensus stage is the same as the first consensus stage, the consensus message is processed to enter the next consensus stage for the consensus block to be reached at the second block height.

[0094] Specifically, take node A in the node cluster of the blockchain system as an example. Under the underlying blockchain model based on BFT consensus, when node A enters the consensus round for the consensus block Block(5) with block height 5 in the blockchain and receives the consensus message A sent by other nodes in the blockchain, node A can compare the block height (5) with the message height (5) carried by the received consensus message A. When the block height (5) is equal to the message height (5), node A can further compare the relationship between the first consensus stage at the current moment and the second consensus stage corresponding to the consensus message A. That is, when the block height (5) is equal to the message height (5), node A can further determine the relationship between the first consensus stage at the current moment and the second consensus stage corresponding to the consensus message A. The first consensus stage at the node and the second consensus stage corresponding to the consensus message A, assuming that the second consensus stage (Prevote stage) is the same consensus stage as the first consensus stage (Prevote stage), indicating that the consensus message A is the message that will be used in the current stage (Prevote stage), then node A can process the consensus message A, that is, node A can obtain the second pre-voting information contained in the consensus message A, so that node A can quickly collect the pre-voting information that meets the preset voting threshold, and enter the next consensus stage (i.e., precommit stage) for the consensus block Block (5). Since each consensus message carries a height, by comparing the consensus message height with the node height, if the received consensus message height is lower than the current height, then the message is directly discarded; if it is consistent with the current height, then it is the message required by the current consensus stage, and the normal consensus process can be followed to push the consensus forward, so that the consensus can be promoted as soon as possible, thereby improving the speed of consensus processing.

[0095] In one embodiment, after searching the cache mapping table for a proposal message corresponding to the first block height, the method further includes:

[0096] When no proposal message corresponding to the first block height is found in the cache mapping table, wait for other nodes in the blockchain to send proposal messages;

[0097] When a proposal message sent by other nodes in the blockchain is received, a first pre-voting message is generated based on the proposal message.

[0098] Specifically, we take node A in the node cluster of the blockchain system as an example. In the underlying blockchain model based on BFT consensus, when node A enters the consensus round for the block to be agreed upon Block(6) at block height 6 in the blockchain, node A can use the node A maintained by itself to Figure 4 The proposal message corresponding to block height 6 is searched in the cache mapping table shown in . When node A finds the proposal message corresponding to block height 6 from the cache mapping table maintained by itself, Figure 4When the proposal message corresponding to the block height 6 is not found in the cache mapping table shown in , node A needs to wait for other nodes (master nodes) in the blockchain to send proposal messages for the block to be consensus Block(6); when node A receives proposal messages for the block to be consensus Block(6) sent by other nodes (master nodes) in the blockchain, node A generates the first pre-voting message based on the received proposal message for the block to be consensus Block(6). As a result, if the cache mapping table does not store the messages required for the current consensus stage, the normal consensus process can be followed to push the consensus forward, which can also promote the consensus as soon as possible, thereby improving the speed of consensus processing.

[0099] In one embodiment, after searching the cache mapping table for the second pre-voting message corresponding to the first block height, the method further includes:

[0100] When the second pre-voting message corresponding to the first block height is not found in the cache mapping table, wait for other nodes in the blockchain to send the second pre-voting message;

[0101] When a second pre-voting message sent by other nodes in the blockchain is received and the first pre-voting message and the second pre-voting message meet a preset voting threshold, a first voting message is generated.

[0102] Specifically, we take node A in the node cluster of the blockchain system as an example. In the underlying blockchain model based on the BFT consensus, when node A enters the consensus round for the block to be agreed upon Block(6) at block height 6 in the blockchain, and node A uses the consensus data maintained by itself to Figure 4 After searching the cache mapping table shown in FIG. 1 for the second pre-voting message corresponding to block height 6, when node A obtains the second pre-voting message corresponding to block height 6 from the cache mapping table maintained by itself, Figure 4 When the second pre-voting message corresponding to the block height 6 is not found in the cache mapping table shown in , node A needs to wait for other nodes in the blockchain to send the second pre-voting message for the block height 6; when node A receives the second pre-voting message for the block height 6 sent by other nodes in the blockchain, and the total number of the first pre-voting message and the second pre-voting message meets the preset voting threshold, node A can generate the first voting message. As a result, if the message required for the current consensus stage is not stored in the cache mapping table, the normal consensus process can be followed to push the consensus forward, which can also promote the consensus as soon as possible, thereby improving the speed of consensus processing, while effectively improving the consensus efficiency of the blockchain, and improving the processing performance of the entire blockchain.

[0103] In one embodiment, after searching the cache mapping table for the second voting message corresponding to the first block height, the method further includes:

[0104] When the second voting message corresponding to the first block height is not found in the cache mapping table, wait for other nodes in the blockchain to send the second voting message;

[0105] When a second voting message sent by other nodes in the blockchain is received and the first voting message and the second voting message meet the preset voting threshold, the consensus block at the first block height is stored in the local account book.

[0106] Specifically, we take node A in the node cluster of the blockchain system as an example. In the underlying blockchain model based on the BFT consensus, when node A enters the consensus round for the block to be agreed upon Block(6) at block height 6 in the blockchain, and node A uses the consensus data maintained by itself to Figure 4 After searching the cache mapping table shown in FIG. 1 for the second voting message corresponding to block height 6, when node A obtains the second voting message corresponding to block height 6 from the cache mapping table maintained by itself, Figure 4 When the second voting message corresponding to the block height 6 is not found in the cache mapping table shown in , node A needs to wait for other nodes in the blockchain to send the second voting message for the block height 6; when node A receives the second voting message for the block height 6 sent by other nodes in the blockchain, and the total number of the first voting message and the second voting message meets the preset voting threshold, it means that the consensus block Block (6) has reached a consensus, and node A can store the consensus block Block (6) with a block height of 6 in the local account book. As a result, if the cache mapping table does not store the message required for the current consensus stage, the normal consensus process can be followed to promote the consensus forward, which can also promote the consensus as soon as possible, thereby improving the speed of consensus processing, while effectively improving the consensus efficiency of the blockchain, and improving the processing performance of the entire blockchain.

[0107] In one embodiment, after storing the consensus block at the first block height in the local ledger, the method further includes:

[0108] Determining a reference value based on the first block height and a preset threshold;

[0109] When the reference value is the first value, determining the consensus message to be cleared based on the first block height, and deleting the consensus message to be cleared from the cache mapping table;

[0110] When the reference value is not the first value, a consensus round is entered for a block to be agreed upon at a third block height in the blockchain; wherein the third block height is greater than the first block height.

[0111] The preset threshold refers to a preset block height threshold for cleaning data. For example, the preset threshold can be set to 10.

[0112] The reference value refers to a value obtained by performing a certain operation on the first block height and a preset threshold, for example, performing a modulo operation based on the first block height and the preset threshold to obtain an operation result, and using the operation result as a reference value.

[0113] Specifically, after each node in the node cluster stores the consensus block of the first block height into the local account book, each node in the node cluster can perform a modulo operation based on the first block height and a preset threshold to obtain an operation result, and use the operation result as a reference value; when the reference value is the first value, each node in the node cluster can determine the consensus message to be cleared based on the first block height, and delete the consensus message to be cleared from the cache mapping table maintained by itself; when the reference value is not the first value, each node in the node cluster can enter the consensus round for the consensus block of the third block height in the blockchain, where the third block height is greater than the first block height. That is, each node in the node cluster can enter the consensus round for the next consensus block in the blockchain.

[0114] 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, when node A enters the consensus round for the consensus block Block (6) at the block height 6 in the blockchain, and node A determines that the consensus block Block (6) has reached a consensus and stores the consensus block Block (6) in the local account book, node A can perform a remainder operation based on the block height 6 and the preset threshold 10, and obtain the operation result d = 6% 10 = 6, and use the operation result 6 as a reference value; assuming that the first value in this application is set to 0, when the reference value 6 is not 0, it means that there is no need to perform a cleanup operation, and node A enters the consensus round for the consensus block Block (7) at the next height 7 in the blockchain. For another example, when node A enters the consensus round for the consensus block Block (10) with a block height of 10 in the blockchain, and node A determines that the consensus block Block (10) has reached a consensus and stores the consensus block Block (10) in the local account book, node A can perform a remainder operation based on the block height 10 and the preset threshold 10 to obtain an operation result d=10%10=0, and use the operation result 0 as a reference value; assuming that the first value in the present application is set to 0, when the reference value is 0, it indicates that a cleanup operation needs to be performed, and node A determines that the consensus message to be cleaned is the consensus message corresponding to the block height 1-10 based on the block height 10, and deletes the consensus message corresponding to the block height 1-10 from the cache mapping table maintained by itself, that is, the method provided in the embodiment of the present application, at each height that is a multiple of 10, each node in the node cluster will automatically clean up the cache of 10 historical heights containing the current height, so that each node's cache mapping table has at most 10 consensus messages of height, and will not occupy too many system resources.

[0115] In this embodiment, by improving the processing flow of consensus messages in the Byzantine consensus process, a caching mechanism is adopted for messages of future heights. When a new height is needed, the required consensus messages are directly obtained from the cache according to the consensus stage steps. At the same time, the consensus messages in the cache are cleaned up to ensure that the cache does not occupy too many resources, thereby achieving performance improvement of the Byzantine consensus and effectively avoiding the network bandwidth occupied by message retransmission, thereby improving the processing performance of the entire blockchain.

[0116] In one embodiment, the step of determining the consensus message to be cleared based on the first block height and deleting the consensus message to be cleared from the cache mapping table includes:

[0117] Determine the height of the block to be cleared based on the first block height and a preset threshold;

[0118] Determine the consensus messages to be cleared based on the height of the block to be cleared;

[0119] The cache mapping table is locked, and each consensus message to be cleared is deleted from the locked cache mapping table.

[0120] Specifically, take node A in the node cluster of the blockchain system as an example. Under the underlying blockchain model based on the BFT consensus, when node A enters the consensus round for the consensus block Block (10) with a block height of 10 in the blockchain, and node A determines that the consensus block Block (10) has reached a consensus and stores the consensus block Block (10) in the local account book, node A can perform a remainder operation based on the block height 10 and the preset threshold 10, and obtain the operation result d = 10% 10 = 0, and use the operation result 0 as a reference value; assuming that the first value in this application is set to 0, then when the reference value is 0, it means that the consensus block Block (10) needs to be updated. To perform the cleaning operation, node A can determine that the block height to be cleaned is 1-10 based on the block height 10 and the preset threshold 10, and determine that the consensus message to be cleaned is the consensus message corresponding to the block height 1-10 based on the block height 1-10 to be cleaned; further, node A can lock the cache mapping table maintained by itself, and delete the consensus message corresponding to the block height 1-10 from the locked cache mapping table. After node A deletes the consensus message corresponding to the block height 1-10 from the locked cache mapping table, node A releases the lock on the cache mapping table.

[0121] In this embodiment, the cache mapping table is locked when the cache data is cleaned, which can ensure the data security when cleaning the data, and at the same time ensure that the cache does not occupy too many resources, thereby achieving the performance improvement of the Byzantine consensus, and at the same time effectively avoiding the network bandwidth occupied by message retransmission, thereby improving the processing performance of the entire blockchain.

[0122] 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:

[0123] When there are abnormal nodes or backward nodes in the blockchain, the above-mentioned blockchain consensus method can be adopted, that is, in the blockchain system, when the node enters the consensus round for the consensus block of the first block height in the blockchain, the node preferentially searches for the proposal message corresponding to the first block height from the cache mapping table, and generates the first pre-voting message based on the found proposal message; the node can preferentially search for the second pre-voting message corresponding to the first block height from the cache mapping table; when the first pre-voting message and the second pre-voting message meet the preset voting threshold, the node generates the first voting message, and preferentially searches for the second voting message corresponding to the first block height from the cache mapping table; wherein, the second pre-voting message and the second voting message are sent by other nodes in the blockchain; when the first voting message and the second voting message meet the preset voting threshold, the node stores the consensus block of the first block height in the local account book. Therefore, through the cache mechanism of the consensus message proposed in this application, the speed of collecting consensus messages in each consensus step can be improved, and the next stage of consensus can be entered as soon as possible, which effectively improves the consensus speed and thus improves the overall consensus efficiency. That is, the blockchain consensus solution proposed in this application can also solve the problem of low blockchain performance when the traditional blockchain Byzantine consensus faces abnormal nodes or backward nodes.

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

[0125] In the scenario where the consensus state of a blockchain consensus node lags behind other normal nodes due to reasons such as slow network or consensus message processing, the lagging node receives a consensus message from other nodes that is higher than the current consensus state of the node. The traditional Byzantine consensus process will directly ignore or discard messages that do not belong to the current consensus step, wait for itself (this node) to enter the corresponding consensus state, and then wait for other nodes to resend the required consensus message to itself (this node).

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

[0127] 1. The master node packages and generates a proposal, and then broadcasts the proposal to the slave node for verification. This stage is the first stage of the Byzantine consensus (proposal stage).

[0128] 2. The slave node receives the proposal and enters the prevote phase, then initiates a prevote vote and broadcasts its own prevote vote to other nodes. The slave node starts collecting prevote votes from this phase. This phase is the second phase of the Byzantine consensus (prevote phase).

[0129] 3. When each node receives prevote votes from more than 2 / 3 of the nodes, it enters the precommit phase, generates a precommit vote, and broadcasts its own precommit vote to other nodes. This is the third phase (precommit phase) of the Byzantine consensus.

[0130] 4. When each node receives precommit votes from 2 / 3 of the nodes, it commits.

[0131] 5. After Commit, the height is increased by 1, and the process of step 1 is continued to start a new consensus of height.

[0132] According to the above consensus process analysis, the consensus state is driven by consensus messages. Each stage needs to collect enough consensus messages to enter the next stage. Each time a new consensus stage is entered, it is necessary to collect messages based on this stage. For example, if the consensus of a node is in the prevote stage, then the node needs to collect prevote votes from 2 / 3 of the nodes to enter the precommit stage.

[0133] In the consensus process described above, consensus messages are the most important. How to quickly collect the corresponding messages in each consensus step can quickly enter the next stage, thereby improving the consensus speed. In the Byzantine consensus process, when the consensus enters a corresponding stage (proposal stage, prevote stage, precommit stage), a corresponding consensus message (voting message or proposal message) will be generated and then sent to other consensus nodes. If the other node does not receive the consensus message or receives the consensus message but does not process it during this process, the node needs to resend the consensus message to the node where the message is missing. This mechanism is implemented in every Byzantine consensus applied to engineering. In the traditional Byzantine consensus, if a node is in a certain stage and receives a message that is higher than the current state, the so-called high-state message is a message that is not needed now and is needed to enter the future consensus state. For example, the node is now at height 10, and the consensus stage is the proposal stage. If it receives a prevote message of height 10 sent by other nodes, then this consensus message is a temporarily unnecessary consensus message for the node, so the node will discard this consensus message and wait until the node enters the prevote stage, and then other nodes will resend the prevote message.

[0134] This so-called future consensus message can actually be saved and cached, waiting for the node to enter the prevote phase, and then the consensus message can be retrieved from the cache for use, instead of waiting for other nodes to resend the message. The message resending will be slow and will also affect the consensus performance, and the message resending will also occupy the network bandwidth. Therefore, in order to improve the efficiency of consensus, how to handle proposals or voting messages from the future has become a key to improving the performance of the Byzantine consensus. Therefore, in the case of abnormal nodes in the blockchain network, how to improve the performance of the blockchain has become an urgent problem to be solved.

[0135] Disadvantages of traditional technologies include:

[0136] The traditional Byzantine consensus handles consensus messages as mentioned above. If a node is in a consensus stage, it will only process the consensus messages required for the current consensus stage. If it receives a message higher than the current stage, or any message with a higher height than itself, the node will directly discard these messages and continue to wait for the consensus message of the current stage, waiting to enter a new stage. If other nodes have sent the consensus message of this stage to the node before, then other nodes will wait for a period of time before resending it to the node. Therefore, this waiting process affects the performance of the consensus and will also occupy unnecessary network bandwidth, which will lead to poor performance of the entire blockchain and low consensus efficiency of the entire blockchain.

[0137] Therefore, in order to solve the above problems, this application proposes a cache solution for blockchain Byzantine consensus messages. Aiming at the problems existing in the traditional Byzantine consensus processing process, that is, the situation where the backward node receives a consensus message sent by other nodes that is higher than its own consensus status and is not needed temporarily, the Byzantine consensus process is optimized. By creating a consensus message cache mechanism, when the node receives a consensus message that is not needed temporarily but may be needed in the future, it is no longer directly discarded, but cached first, waiting for the node to enter a new consensus step, and first checking from the cache whether it has received the consensus message required for the current step, instead of waiting for other nodes to resend messages to itself (this node) as in the traditional way. At the same time, the solution provided by this application has also been designed for the problems that may exist under this solution, forming a feasible and reliable Byzantine consensus process optimization solution, which can fully improve the blockchain consensus speed, thereby effectively improving the overall consensus efficiency of the blockchain.

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

[0139] This application proposes a solution to the problems existing in the traditional Byzantine consensus processing flow: when a consensus node enters a certain consensus stage, if it receives consensus messages required for the future consensus state, it does not directly discard or not process these consensus messages, but caches them and waits until it enters a new consensus stage, and preferentially obtains the consensus messages required for the current consensus stage from the cache.

[0140] To address this problem, this application designs a structure for caching consensus messages required for the future consensus phase. This structure is similar to a map mapping table, where the key is the height and the value is a structure for storing consensus messages, which contains the proposal propsoal, prevote, and precommit of this height. That is, if the consensus message received by the node is greater than the current height through comparison, then it is stored in the map mapping table according to the height of the consensus message, and the consensus process of the current height continues. When the consensus reaches a new height, the current height is followed as the key from the cache structure (map mapping table), and the corresponding cached message is obtained according to the current consensus step. For example, if the first stage of the new height is the proposal stage, then the proposal of the new height in the cache is obtained. If it is available, it can be used directly instead of waiting for other nodes to resend it. If the consensus enters the second stage, the prevote stage, the prevote vote of the current height is obtained from the cache first. Similarly, the third stage precommit is the same. The precommit vote is obtained from the cache first. In this way, the consensus messages that are not currently needed can be cached first and used when needed, which effectively avoids the waste of messages, thereby improving the consensus efficiency and reducing the network bandwidth usage.

[0141] The above describes the storage and use of future consensus messages. Another problem is that it is necessary to clean up consensus messages that are no longer needed to avoid occupying memory and other resources. However, if each height is cleaned up from the mapping table, it will also affect the consensus efficiency, because the operation of the mapping table requires locking to protect resources. If the consensus process of each height is over, the cache mapping table is operated to clear the consensus messages that are no longer needed, then the consensus efficiency will still be affected to a certain extent. Therefore, the present application proposes that the cache mapping table is operated only when the height is an integer multiple of 10 and the consensus of this height is over. For example, at heights of 10, 20, and 30, the cache mapping table needs to be locked to protect all the consensus messages cached from the current height to 10 heights ago. For example, at the end of height 10, the consensus message caches of the 10 heights 1-10 need to be deleted from the cache mapping table; at the end of height 20, the consensus message caches of the 10 heights 10-20 are deleted from the cache mapping table. In this way, the waste of consensus messages can be avoided. At the same time, nodes can quickly obtain the required consensus messages, reducing the message retransmission of other nodes, thereby avoiding the waste of network bandwidth and achieving the technical effect of improving consensus efficiency.

[0142] On the product side, the method provided in this application can be used as a process optimization solution for Byzantine consensus, 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 to optimize the corresponding underlying blockchain code. It can be applied to the actual development of underlying blockchain software, and can also be used as a form of external publicity.

[0143] On the technical side,

[0144] 1.1 The main process is as follows:

[0145] In the mainstream solution, if a consensus message that is not needed by the current consensus is received, that is, the so-called consensus message of the future height, it is directly discarded. After other nodes send their own consensus messages, if they find that other nodes have not received the consensus message for various reasons, they will choose to resend it. Therefore, when a node is at a lower height and receives a consensus message of a higher height from other nodes, it will not process these consensus messages, and can only resend them through other nodes after a period of time. Frequent message resending will affect the consensus efficiency, causing the node to fail to obtain the required consensus message in time. Since other nodes have sent it once before, it can only be resent. Regardless of which resending mechanism is adopted (the common method is state synchronization, that is, the nodes will broadcast their own consensus status to each other, and the nodes will choose to resend the message according to the consensus status of other nodes received), it will cause the consensus message to lag, which will cause the lagging nodes to have no way to receive the required consensus message in time, and the resending of the message will also affect the network bandwidth, especially the proposal message in the first stage, which contains transaction information and is usually large.

[0146] According to the scheme described above, it is necessary to cache the consensus messages of future heights so that when the consensus reaches the corresponding height, the previously cached messages can be used immediately, so that the consensus processing process can be promoted more quickly. Figure 4 All cache structures are used to cache future consensus messages.

[0147] This cache structure can be a mapping table map, the key is the future height, and the value stores a consensus message structure. The consensus message structure contains the proposal, prevote voting set, and precommit voting set of the corresponding height.

[0148] The cache structure described above can cache consensus messages at each height. When a message that is not needed at the current height is received, it can be placed in the corresponding cache structure according to the height of the consensus message. When entering a new height, each consensus step will first obtain messages from the cache to see if there are previously cached consensus messages. If there are, they can be used directly. At the same time, at the end of the consensus at each height, after entering a new height, the cache needs to be cleaned up. For example, the solution provided in this application can be cleaned up every 10 heights, that is, the cached consensus messages of the 10 historical heights before the current height are cleaned up, so as to achieve the purpose of not occupying system resources.

[0149] According to the solution provided by this application, the improved Byzantine blockchain process can cache and utilize future highly consensus messages, thereby improving consensus performance. Therefore, the improved consensus key process is as follows:

[0150] Take the example of a blockchain system with 4 consensus nodes. Assume that node 4 is slow to receive or process consensus messages due to network or system resources, and node 4 lags behind other nodes. According to the principle of the Byzantine consensus algorithm, since the total number of nodes is 4, the three consensus nodes 1, 2, and 3 can continue to reach consensus. If the height of node 4 is 10 and the heights of the other three consensus nodes are 11, the core consensus process of node 4 includes:

[0151] 1. Receive votes for future heights:

[0152] Node 4 is now at a height of 10, and receives a proposal, prevote, or precommit vote with a height of 11 from other nodes. The specific process is as follows Figure 5 As shown in . Node 4 receives a consensus message, whether it is a proposal message or a voting message. Since each consensus message carries a height, node 4 can compare the consensus message height with the height of this node. If the received consensus message height is lower than the current node height, the message is discarded directly. If the received consensus message height is consistent with the current node height, then it is the message required for the current consensus stage, and the normal consensus process can be followed to push the consensus forward. If the received consensus message height is greater than the current node consensus height, it means that this node may need to use this consensus message at a future height, so node 4 can store this consensus message in the cache mapping table it maintains.

[0153] 2. Entering a new height:

[0154] like Figure 7As shown in FIG. 1 , it is a consensus process diagram of the blockchain Byzantine consensus message caching solution provided by this application. Node 4 is at height 10 and receives consensus messages sent by other nodes. When the height reaches 11, the consensus process of node 4 is as follows: Figure 7 As shown in:

[0155] That is, when node 4 enters the consensus height of 11, it first enters the first stage of consensus, namely the proposal stage. Node 4 first obtains the proposal with a height of 11 from the cache. If there is one in the cache, it means that the previous height has received the future proposal, and it can directly enter the second stage, namely the prevote stage. If there is no propsoal with a height of 11 in the cache, the normal consensus process will continue to wait for other nodes to send proposals. Later, when node 4 receives the proposal, it will enter the second stage. After the consensus enters the second stage, node 4 first obtains all prevote votes with a height of 11 from the cache. If more than 2 / 3+1 prevote votes are obtained from the cache, the consensus can directly enter the precommit stage. If it does not reach 2 / 3+1 prevote votes, node 4 executes the normal consensus process, that is, node 4 continues to collect prevote votes from other nodes. When it reaches 2 / 3+1 prevote votes, node 4 can enter the third stage, namely the precommit stage. The third stage is actually the same as the second stage. It also first obtains all precommit votes with a height of 11 from the cache. If the obtained precommit votes reach 2 / 3+1, node 4 directly enters the commit stage. If it does not reach 2 / 3+1, it continues to wait for precommit votes to be collected until the precommit votes collected by node 4 reach 2 / 3+1, and then enters the commit stage.

[0156] 3. After the consensus height is completed, clean up the cache:

[0157] like Figure 8 The figure below is a flowchart of node cache cleaning. Before a node completes submission and enters a new height, it is also necessary to clear the cached consensus message. It is not necessary to clean up the cache after each submission, but to clean up the cache at a height that is a multiple of 10. Each cleanup includes the cache of 10 historical heights of the current height. The flowchart of cache cleaning is as follows: Figure 8 As shown in . That is, for every multiple of 10 heights, the cache of the previous 10 historical heights is cleared, so that there are only consensus message caches of 10 heights at most in the cache, which will not occupy too many system resources.

[0158] 1.2 Impact of the solution on the consensus process:

[0159] From the above analysis, we can know that by improving the processing flow of consensus messages in the Byzantine consensus, a cache mechanism is adopted for future height messages. When a new height is needed, the required consensus messages can be directly obtained from the cache according to the consensus stage steps. At the same time, the consensus messages in the cache are cleaned up to ensure that the cache does not occupy too many resources. Finally, the solution provided by this application achieves the improvement of the Byzantine consensus performance, and also avoids the network bandwidth occupied by message retransmission.

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

[0161] 1. A process optimization scheme for blockchain Byzantine consensus is proposed. By caching future high consensus messages, the discarding and waste of messages is avoided, the lag effect caused by the re-issuance of consensus messages is reduced, and the network bandwidth usage is reduced, thereby improving the performance of Byzantine consensus.

[0162] 2. In response to the above scheme, a set of specific solutions is provided to solve the problem of low performance caused by not processing future consensus messages in the traditional blockchain Byzantine consensus.

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

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

[0165] In one embodiment, Fig. 9 As shown, a blockchain consensus device is provided, including: a search module 902, a generation module 904 and a storage module 906, wherein:

[0166] The search module 902 is used to search for a proposal message corresponding to the first block height in the blockchain from the cache mapping table when entering the consensus round for the consensus block to be reached at the first block height in the blockchain.

[0167] The generating module 904 is used to generate a first pre-voting message based on the proposal message.

[0168] The search module 902 is further configured to search the cache mapping table for a second pre-voting message corresponding to the first block height.

[0169] The generating module 904 is further configured to generate a first voting message when the first pre-voting message and the second pre-voting message meet a preset voting threshold.

[0170] The search module 902 is also used to search the cache mapping table for a second voting message corresponding to the first block height; wherein the second pre-voting message and the second voting message are sent by other nodes in the blockchain.

[0171] The storage module 906 is used to store the consensus block of the first block height into the local account book when the first voting message and the second voting message meet the preset voting threshold.

[0172] In one embodiment, the device further includes: a comparison module, which is used to compare the second block height with the message height carried by the consensus message when entering the consensus round for the block to be agreed upon with the second block height in the blockchain and receiving a consensus message sent by other nodes in the blockchain; wherein the second block height is less than the first block height, and the consensus message includes the proposal message, the second pre-voting message and the second voting message; the storage module is also used to store the consensus message in the cache mapping table when the second block height is less than the message height, so that the consensus message can be obtained from the cache mapping table when consensus is reached on the block to be agreed upon with the same message height.

[0173] In one embodiment, the device further includes: a discarding module, configured to discard the consensus message when the second block height is greater than the message height.

[0174] In one embodiment, the device also includes: a construction module, which is used to construct a key-value pair structure corresponding to the message height in the cache mapping table based on the message height carried by the consensus message; the storage module is also used to store the message height carried by the consensus message as the key and the consensus message as the value into the key-value pair structure of the cache mapping table.

[0175] In one embodiment, the device further includes: a determination module, which is used to determine the first consensus stage at the current moment and the second consensus stage corresponding to the consensus message when the second block height is equal to the message height; the search module is also used to search the consensus message structure corresponding to the second block height from the cache mapping table when the second consensus stage is after the first consensus stage; the storage module is also used to store the consensus message in the target position in the consensus message structure, so that the consensus message is obtained from the cache mapping table when entering the second consensus stage of the consensus block to be agreed upon for the second block height; wherein the second block height is used as a key and the consensus message structure corresponding to the second block height is used as a value and is stored in the cache mapping table.

[0176] In one embodiment, the device further includes: a processing module, configured to process the consensus message when the second consensus stage is the same consensus stage as the first consensus stage, so as to enter the next consensus stage for the block to be agreed upon at the second block height.

[0177] In one embodiment, the device further includes: a waiting module, which is used to wait for other nodes in the blockchain to send the proposal message when the proposal message corresponding to the first block height is not found in the cache mapping table; the generation module is also used to generate the first pre-voting message based on the proposal message when the proposal message sent by other nodes in the blockchain is received.

[0178] In one embodiment, the device further includes: a waiting module, which is used to wait for other nodes in the blockchain to send the second pre-voting message when the second pre-voting message corresponding to the first block height is not found in the cache mapping table; the generating module is also used to generate the first voting message when the second pre-voting message sent by other nodes in the blockchain is received and the first pre-voting message and the second pre-voting message meet a preset voting threshold.

[0179] In one embodiment, the device further includes: a waiting module, which is used to wait for other nodes in the blockchain to send the second voting message when the second voting message corresponding to the first block height is not found in the cache mapping table; the storage module is also used to store the consensus block of the first block height into the local account book when the second voting message sent by other nodes in the blockchain is received and the first voting message and the second voting message meet a preset voting threshold.

[0180] In one embodiment, the device also includes: a determination module, used to determine a reference value based on the first block height and a preset threshold; when the reference value is a first value, determining a consensus message to be cleared based on the first block height; a deletion module, used to delete the consensus message to be cleared from the cache mapping table; a processing module, used to enter a consensus round for a consensus block to be reached at a third block height in the blockchain when the reference value is not the first value; wherein the third block height is greater than the first block height.

[0181] In one embodiment, the device also includes: a determination module is also used to determine the height of the block to be cleaned based on the first block height and the preset threshold; determine each consensus message to be cleaned based on the height of the block to be cleaned; the deletion module is also used to lock the cache mapping table and delete each consensus message to be cleaned from the locked cache mapping table.

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

[0183] 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.10 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.

[0184] Those skilled in the art will understand that Fig.10The 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.

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

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

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

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

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

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

[0191] 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: When entering the consensus round for a block to be agreed upon at a first block height in the blockchain, searching the cache mapping table for a proposal message corresponding to the first block height, and generating a first pre-voting message based on the proposal message; Searching the cache mapping table for a second pre-voting message corresponding to the first block height; When the first pre-voting message and the second pre-voting message meet a preset voting threshold, a first voting message is generated, and a second voting message corresponding to the first block height is searched from the cache mapping table; wherein the second pre-voting message and the second voting message are sent by other nodes in the blockchain; When the first voting message and the second voting message meet a preset voting threshold, the consensus block at the first block height is stored in the local account book.

2. The method according to claim 1, characterized in that: Before entering into the consensus round for the block to be agreed upon at the first block height in the blockchain, the method further includes: When entering the consensus round for the block to be agreed upon at the second block height in the blockchain and receiving a consensus message sent by other nodes in the blockchain, comparing the second block height with the message height carried by the consensus message; wherein the second block height is less than the first block height, and the consensus message includes the proposal message, the second pre-voting message, and the second voting message; When the second block height is less than the message height, the consensus message is stored in the cache mapping table so that the consensus message is obtained from the cache mapping table when consensus is reached on a block to be agreed upon with the same height as the message.

3. The method according to claim 2, characterized in that After comparing the second block height with the message height carried by the consensus message, the method further includes: When the second block height is greater than the message height, the consensus message is discarded.

4. The method according to claim 2, characterized in that: The storing the consensus message into the cache mapping table includes: Based on the message height carried by the consensus message, constructing a key-value pair structure corresponding to the message height in the cache mapping table; The message height carried by the consensus message is used as a key and the consensus message is used as a value to store them in the key-value pair structure of the cache mapping table.

5. The method according to claim 2, characterized in that: After comparing the second block height with the message height carried by the consensus message, the method further includes: When the second block height is equal to the message height, determining the first consensus stage at the current moment and the second consensus stage corresponding to the consensus message; When the second consensus stage is after the first consensus stage, searching the cache mapping table for a consensus message structure corresponding to the second block height; Storing the consensus message in a target location in the consensus message structure, so that the consensus message is obtained from the cache mapping table when entering the second consensus phase for the block to be consensus at the second block height; Among them, the second block height is used as a key, and the consensus message structure corresponding to the second block height is stored in the cache mapping table as a value.

6. The method according to claim 5, characterized in that After determining the first consensus stage at the current moment and the second consensus stage corresponding to the consensus message, the method further includes: When the second consensus stage is the same consensus stage as the first consensus stage, the consensus message is processed to enter the next consensus stage for the consensus-to-be block at the second block height.

7. The method according to claim 1, characterized in that After searching the cache mapping table for the proposal message corresponding to the first block height, the method further includes: When no proposal message corresponding to the first block height is found in the cache mapping table, waiting for other nodes in the blockchain to send the proposal message; When the proposal message sent by other nodes in the blockchain is received, the first pre-voting message is generated based on the proposal message.

8. The method according to claim 1, characterized in that: After searching the cache mapping table for the second pre-voting message corresponding to the first block height, the method further includes: When the second pre-voting message corresponding to the first block height is not found in the cache mapping table, waiting for other nodes in the blockchain to send the second pre-voting message; When the second pre-voting message sent by other nodes in the blockchain is received and the first pre-voting message and the second pre-voting message meet a preset voting threshold, the first voting message is generated.

9. The method according to claim 1, characterized in that: After searching the cache mapping table for a second voting message corresponding to the first block height, the method further includes: When the second voting message corresponding to the first block height is not found in the cache mapping table, waiting for other nodes in the blockchain to send the second voting message; When the second voting message sent by other nodes in the blockchain is received and the first voting message and the second voting message meet the preset voting threshold, the consensus block to be reached at the first block height is stored in the local account book.

10. The method according to claim 1, characterized in that After storing the consensus block at the first block height in the local account book, the method further includes: Determining a reference value based on the first block height and a preset threshold; When the reference value is the first value, determining a consensus message to be cleared based on the first block height, and deleting the consensus message to be cleared from the cache mapping table; When the reference value is not the first value, entering into a consensus round for a block to be agreed upon at a third block height in the blockchain; wherein the third block height is greater than the first block height.

11. The method according to claim 10, characterized in that The determining the consensus message to be cleared based on the first block height, and deleting the consensus message to be cleared from the cache mapping table, includes: Determine the height of the block to be cleared based on the first block height and the preset threshold; Determine each of the consensus messages to be cleared based on the height of the block to be cleared; The cache mapping table is locked, and each consensus message to be cleared is deleted from the locked cache mapping table.

12. A blockchain consensus device, characterized in that: The device comprises: A search module, configured to search a proposal message corresponding to a first block height in a blockchain from a cache mapping table when entering a consensus round for a block to be agreed upon at the first block height in the blockchain; A generating module, configured to generate a first pre-voting message based on the proposal message; The search module is further used to search the cache mapping table for a second pre-voting message corresponding to the first block height; The generating module is further configured to generate a first voting message when the first pre-voting message and the second pre-voting message meet a preset voting threshold; The search module is further used to search the cache mapping table for a second voting message corresponding to the first block height; wherein the second pre-voting message and the second voting message are sent by other nodes in the blockchain; The storage module is used to store the consensus block of the first block height into the local account book when the first voting message and the second voting message meet a preset voting threshold.

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