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 traffic, and comprises the steps of obtaining a first block height of a local node and a second block height of a target node in the block chain; when a difference value between the second block height and the first block height is greater than a preset threshold value, sending a block request for a to-be-synchronized block to a node meeting a first height condition in a block chain; when a response message for the block request is received, verifying a block head in the response message, and when the verification is passed, storing a block containing the block head in a local account book, and updating a first block height of the local node; and when the updated first block height is consistent with the second block height, adding to a block chain consensus process. By adopting the method, the consensus efficiency of the block chain and the processing performance 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, since the communication between nodes is carried out through the network, there are network anomalies in some cases. Although the current blockchain consensus algorithm itself also takes into account the node network anomalies, if the abnormal network node is the master node in this round of consensus, the node cannot actually participate in the consensus normally. At this time, for other nodes in the blockchain, they need to wait for a certain timeout period before the next node will be rotated as the master node. As a result, during the entire consensus process of the blockchain, although other nodes can continue to reach consensus, their performance is compromised, which leads to low consensus efficiency of the entire blockchain. Summary of the invention

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

[0005] In the first aspect, the present application provides a blockchain consensus method. The method includes: obtaining a first block height of a local node and a second block height of a target node in a blockchain; when the difference between the second block height and the first block height is greater than a preset threshold, sending a block request for a block to be synchronized to a node in the blockchain that meets the first height condition; when receiving a response message for the block request, verifying the block header in the response message, and when the verification passes, storing the block containing the block header in a local account book, and updating the first block height of the local node; when the updated first block height is consistent with the second block height, adding it to the blockchain consensus process.

[0006] In the second aspect, the present application also provides a blockchain consensus device. The device includes: an acquisition module for acquiring the first block height of the local node and the second block height of the target node in the blockchain; a sending module for sending a block request for the block to be synchronized to the node that meets the first height condition in the blockchain when the difference between the second block height and the first block height is greater than a preset threshold; an update module for verifying the block header in the response message when receiving a response message for the block request, and when the verification is passed, storing the block containing the block header in the local account book and updating the first block height of the local node; and a joining module for joining the blockchain consensus process when the updated first block height is consistent with the second block height.

[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: obtaining the first block height of the local node and the second block height of the target node in the blockchain; when the difference between the second block height and the first block height is greater than a preset threshold, sending a block request for the block to be synchronized to the node that meets the first height condition in the blockchain; when receiving a response message for the block request, verifying the block header in the response message, and when the verification is passed, storing the block containing the block header in the local account book, and updating the first block height of the local node; when the updated first block height is consistent with the second block height, adding it to the blockchain consensus process.

[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: obtaining a first block height of a local node and a second block height of a target node in a blockchain; when the difference between the second block height and the first block height is greater than a preset threshold, sending a block request for a block to be synchronized to a node in the blockchain that meets the first height condition; when receiving a response message for the block request, verifying the block header in the response message, and when the verification passes, storing the block containing the block header in a local account book, and updating the first block height of the local node; when the updated first block height is consistent with the second block height, adding it to the blockchain consensus process.

[0009] In the 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: obtaining the first block height of a local node and the second block height of a target node in the blockchain; when the difference between the second block height and the first block height is greater than a preset threshold, sending a block request for the block to be synchronized to the node that meets the first height condition in the blockchain; when receiving a response message for the block request, verifying the block header in the response message, and when the verification passes, storing the block containing the block header in the local account book, and updating the first block height of the local node; when the updated first block height is consistent with the second block height, adding it to the blockchain consensus process.

[0010] The above-mentioned blockchain consensus method, apparatus, computer equipment, storage medium and computer program product obtain the first block height of the local node and the second block height of the target node in the blockchain. When the difference between the second block height and the first block height is greater than a preset threshold, a block request for the block to be synchronized is sent to the node that meets the first height condition in the blockchain; when a response message for the block request is received, the block header in the response message is verified, and when the verification passes, the block containing the block header is stored in the local account book, and the first block height of the local node is updated; when the updated first block height is consistent with the second block height, it is added to the blockchain consensus process. Since the difference is the difference between the first block height of the local node and the second block height of the target node, when the difference is greater than the preset threshold, it triggers the sending of a block request for the block to be synchronized to the node that meets the height condition in the blockchain, so that when a response message for the block to be synchronized is received, the block header in the response message can be quickly verified, and when the verification of the block header is passed, the block containing the block header is stored in the local ledger, and the first block height of the local node is updated, so that the first block height of the local node reaches the specified second block height as soon as possible, and is added to the consensus process of the blockchain as soon as possible. Compared with the method of synchronizing the entire block, the overall performance in the blockchain is several orders of magnitude higher, which allows nodes to quickly participate in the consensus, effectively improving the consensus efficiency of the blockchain while improving 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 3A flowchart of a blockchain consensus method in one embodiment;

[0014] Figure 4 A schematic diagram of a method for a lagging node to obtain blocks in one embodiment;

[0015] Figure 5 A schematic diagram of determining the maximum block height in a blockchain in one embodiment;

[0016] Figure 6 A schematic diagram of adding custom parameters in an embodiment;

[0017] Figure 7 A schematic diagram of a processing flow of a lagging node in a blockchain in one embodiment;

[0018] Figure 8 A schematic diagram of the format of a block request and response message in one embodiment;

[0019] Fig. 9 A schematic diagram of an embodiment in which a lagging slave node cannot participate in consensus in a traditional manner;

[0020] Fig.10 A schematic diagram of an embodiment in which a lagging master node cannot participate in consensus in a traditional manner;

[0021] Fig.11 This is a schematic diagram of the overall process of a blockchain fast consensus solution in one embodiment;

[0022] Fig.12 This is a schematic diagram of the structure of a block header in one embodiment;

[0023] Fig.13 A schematic diagram of a processing flow of a lagging node obtaining block heights of other nodes in one embodiment;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0041] Step 302, obtaining the first block height of the local node and the second block height of the target node in the blockchain.

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

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

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

[0045] The first block height of the local node refers to the maximum block height maintained by a node in the node cluster. For example, taking node A in the node cluster as an example, node A can obtain the block height maintained by itself as d1, then the first block height of the local node is d1.

[0046] The second block height of the target node refers to the maximum block height maintained by the target node in the node cluster. For example, taking nodes B and C in the node cluster as the target nodes, node B can obtain the maximum block height maintained by itself as d2, and node C can obtain the maximum block height maintained by itself as d2. Then the second block height of the target node is d2.

[0047] It can be understood that the number of target nodes in the present application can be multiple. When the number of target nodes is multiple, the maximum block height reached by multiple target nodes can be used as the second block height of the target node, that is, the second block height of the target node in the present application can also refer to the maximum block height reached by each target node in the node cluster. For example, taking node B and node C in the node cluster as target nodes, node B obtains the maximum block height maintained by itself as 110, and node C obtains the maximum block height maintained by itself as 101. Since both node B and node C have reached the block height of 101, the maximum block height reached by each target node is 101, and the second block height of the target node is 101.

[0048] It can be understood that the first block height and the second block height in the present application are only used to distinguish the block heights of different nodes. For example, the first block height may be 7 and the second block height may be 13; or the first block height may be 7 and the second block height may also be 7.

[0049] 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 in the local blockchain maintained by itself, and use the maximum block height as the first block height; further, each node in the node cluster can periodically trigger the automatic generation of a message request for obtaining the maximum block height, and broadcast the message request for obtaining the maximum block height to other nodes in the node cluster, so that other nodes return a response message containing the maximum block height in response to the message request, then each node in the node cluster can select a target node from the response messages returned by other nodes, obtain the maximum block height reached by all target nodes, and use the obtained maximum block height reached by all target nodes as the second block height.

[0050] For example, after a newly created blockchain is started, it is assumed that node A in the node cluster of the blockchain system obtains the maximum block height H0 in the local blockchain maintained by itself, and uses the maximum block height H0 as the first block height; further, node A can generate a message request for obtaining the maximum block height, and broadcast the message request for obtaining the maximum block height to other nodes in the node cluster, so that other nodes return a reply message containing the maximum block height in response to the message request; when node A receives the reply message returned by other nodes in response to the message request, node A can determine the number of trusted nodes from other nodes according to the reply messages returned by other nodes, and select trusted nodes based on the number of trusted nodes; further, node A can obtain the maximum block height of each trusted node, and determine the second block height based on the maximum block height of each trusted node. For example, node A determines that the number of trusted nodes is 2 according to the node fault tolerance condition, and selects the trusted nodes as nodes B and C based on the number of trusted nodes; further, node A can obtain the maximum block height of nodes B and C. Assuming that the maximum block height in the response message returned by node B is 101, and the maximum block height in the response message returned by node C is also 101, node A can determine that the second block height is 101 based on the maximum block height of nodes B and C.

[0051] Step 304: When the difference between the second block height and the first block height is greater than a preset threshold, a block request for the block to be synchronized is sent to a node in the blockchain that meets the first height condition.

[0052] The difference refers to the difference between the second block height and the first block height. In some cases, the difference in this application may also be the absolute value of the difference between the second block height and the first block height.

[0053] Specifically, after the node cluster in the blockchain system obtains the first block height of the local node and the second block height of the target node in the blockchain, the node cluster can determine the difference between the first block height and the second block height. For example, each node in the node cluster can compare the first block height with the second block height to obtain a comparison result; when the comparison result indicates that the first block height is less than the second block height, each node in the node cluster can calculate the difference between the second block height and the first block height, and use the difference as the difference between the second block height and the first block height.

[0054] For example, assuming that node A in the node cluster of the blockchain system obtains that the first block height in the local blockchain maintained by itself is H0 and the second block height of the target node is H1, node A can compare the first block height H0 with the second block height H1 to obtain a comparison result; when the comparison result indicates that the first block height is less than the second block height, node A can calculate the difference between the second block height H1 and the first block height H0, that is, H1-H0=d, and use the difference d as the difference between the second block height and the first block height.

[0055] Among them, the preset threshold refers to the threshold used to screen the difference between the second block height and the first block height. For example, the preset threshold in the present application can be 0 or 2. In addition, the parameters used to screen the difference between the second block height and the first block height in the present application can also include a block height difference range. The block height difference range can also be called a block height difference range condition, which can be represented by the configuration parameter RangeHeight. The block height difference range condition: describes the range of the difference between the block height of a node and other nodes. When only synchronizing the block header data is adopted, for example, the value of RangeHeight is set to 10, then when the difference between the second block height and the first block height is greater than the preset threshold 0 and less than or equal to RangeHeight, that is, the difference between the block height of the current node and the other nodes is greater than the preset threshold 0 and less than or equal to RangeHeight, it means that the difference is within the preset block height difference range. At this time, the current node only needs to synchronize the block header to complete the block synchronization and participate in the consensus process in time.

[0056] The first height condition refers to the height condition used to filter nodes. For example, the first height condition in the present application may be: greater than the first block height of the local node, that is, when the maximum block height maintained by a node in the node cluster is greater than the first block height of the current node, it means that the first height condition is met.

[0057] The block request for the block to be synchronized refers to: a request for obtaining the block to be synchronized. For example, the block request for the block to be synchronized Block8 in the present application includes the identification information of the block to be synchronized Block8, so that other nodes return a response message for the block to be synchronized Block8.

[0058] Specifically, after the node cluster in the blockchain system determines the difference between the second block height and the first block height, when the difference is greater than a preset threshold, each node in the node cluster can send a block request for the block to be synchronized to the node that meets the first height condition in the blockchain, that is, after the node cluster in the blockchain system determines the difference between the second block height and the first block height, the node cluster can determine whether the difference is within a preset block height difference range. For example, each node in the node cluster can compare the difference with a preset threshold and a configuration parameter RangeHeight. When the difference is greater than the preset threshold 0 and less than or equal to the value of the configuration parameter RangeHeight, it indicates that the difference is within the preset block height difference range. Then, each node in the node cluster can send a block request for the block to be synchronized to the node that meets the first height condition in the blockchain to obtain a response message for the block to be synchronized returned by the node that meets the height condition.

[0059] For example, suppose that node A in the node cluster of the blockchain system calculates the difference between the second block height H1 and the first block height H0=5 as H1-H0=d=3, and uses the difference d as the difference between the second block height and the first block height; further, node A can compare the difference d with the preset threshold and the configuration parameter RangeHeight=10. Since d(3) is greater than the preset threshold 0 and less than RangeHeight(10), that is, when the difference d(3) is greater than the preset threshold 0 and less than the configuration parameter RangeHeight(10), it means that the If the difference d is within the preset block height difference range, node A can obtain the block heights of other nodes in the node cluster, and compare the first block height maintained by itself with the block heights of other nodes to obtain a comparison result; when the comparison result indicates that the first block height is less than the block height of node B, node A can send a block request for the block to be synchronized and for obtaining a block that does not contain a transaction set (only a block header) to node B that meets the first height condition in the blockchain, so as to obtain a response message for the block to be synchronized and does not contain a transaction set (only a block header) returned by node B that meets the first height condition.

[0060] Step 306: When a response message is received for a block request, the block header in the response message is verified. When the verification passes, the block containing the block header is stored in the local ledger, and the first block height of the local node is updated.

[0061] Among them, the response message refers to the message in response to the block request for the block to be synchronized. For example, node A sends block request 1 for block Block8 to be synchronized to node B in the blockchain, and node B will return a response message for block request 1 for block Block8 to be synchronized.

[0062] It can be understood that the response message received in response to the block request in the present application may be a response message that does not include a transaction set, or may be a response message that includes a transaction set.

[0063] A response message that does not contain a transaction set means that the response message does not contain a transaction set. A response message that does not contain a transaction set can also be understood as a response message that only contains a block header. A transaction set refers to a set consisting of transaction tasks, that is, a transaction set can contain one or more specific transaction tasks. It can be understood that the transaction tasks in this application can also be referred to as transactions in some cases.

[0064] A response message containing a transaction set means that the response message contains a transaction set. A response message containing a transaction set can also be understood as a response message containing both a block header and a block body (the block body contains a transaction set), that is, a response message containing a complete block.

[0065] The block header refers to the block header in the block. A block consists of two parts: the block header and the block body. The block header stores the header information of the block, including the hash value (PreHash) of the previous block, the hash value (Hash) of the current block body, and the timestamp (TimeStamp). The block body stores the detailed data (Data) of this block. This data contains several lines of records, which can be transaction information or other information. The block and the block Hash (block hash value) are one-to-one corresponding, and the block Hash (block hash value) can be regarded as the unique identifier of the block.

[0066] The block header in the response message refers to the block header carried in the response message returned by the node that meets the first height condition. For example, node A sends block request 1 for block Block8 to be synchronized to node B in the blockchain, then node B will return response message 1 for block request 1 for block Block8 to be synchronized, and the response message 1 includes the block header of the synchronized block Block8.

[0067] Verification refers to verifying the legitimacy of the block header in the response message. For example, the verification in this application may include: verifying the legitimacy of the block hash value of the block header in the response message.

[0068] A block containing a block header refers to a block that only contains a block header, that is, the block only contains a block header and does not contain a block body. Normally, a block consists of two parts: a block header and a block body.

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

[0070] Step 308: When the updated first block height is consistent with the second block height, it is added to the blockchain consensus process.

[0071] Among them, the updated first block height refers to the block height in the local blockchain maintained by itself. For example, node A obtains the block height of 7 in the blockchain (local account book) maintained by itself. After node A stores the block Block8 containing the block header in the local account book, node A can update the block height in the blockchain (local account book) maintained by itself to 7+1=8.

[0072] The first block height is consistent with the second block height means that the first block height is the same as the second block height. For example, the second block height H1=8, then when the updated first block height H0=8=H1, it means that the first block height is consistent with the second block height.

[0073] The blockchain consensus process refers to the process of whether the nodes in the blockchain have reached a consensus on a certain block. The consensus efficiency of a blockchain system is one of the important indicators of its performance. For example, the consensus process of the blockchain in this application at least includes: submitting transactions or data, verifying transactions or data, executing consensus algorithms, and updating the blockchain (local ledger) after reaching consensus.

[0074] Specifically, after each node in the node cluster sends a block request for the block to be synchronized and for obtaining a block that does not contain a transaction set (i.e., only a block header) to the node that meets the first height condition in the blockchain, each node in the node cluster can receive a response message for the block to be synchronized and does not contain a transaction set returned by the node that meets the first height condition, that is, the response message received by each node in the node cluster does not contain a transaction set but only contains a block header for the block to be synchronized. Then, each node in the node cluster can verify the legitimacy of the block header in the response message, and when the legitimacy verification passes, each node stores the block containing the block header in the local account book, that is, after each node completes the synchronization of the block to be synchronized (block header), it automatically updates the first block height of the local node maintained by itself.

[0075] In addition, in some cases, after each node in the node cluster sends a block request for the block to be synchronized and for obtaining a block containing a transaction set to the node that meets the first height condition in the blockchain, each node in the node cluster can receive a response message for the block to be synchronized and containing a transaction set returned by the node that meets the first height condition, that is, the response message received by each node in the node cluster contains both a transaction set and a block header for the block to be synchronized, then each node in the node cluster can extract the block header of the block to be synchronized from the response message, and only perform legitimacy verification on the block header of the block to be synchronized in the response message, and when the legitimacy verification of the block header passes, each node stores the block containing the block header in the local ledger, that is, after each node completes the synchronization of the block to be synchronized (block header), it automatically updates the first block height of the local node maintained by itself.

[0076] When the updated first block height is consistent with the second block height, each node can join the consensus process for the new block to be agreed upon. That is, if a node in the node cluster lags behind other nodes for some reason, then when the lagging node comes back online, it will not be able to participate in the consensus in time, because the block height of the lagging node is inconsistent with other nodes. Even if the lagging node sends a proposal to other nodes, other nodes will not recognize it (because the block height of the proposal has been agreed upon). Therefore, if the lagging node wants to participate in the consensus, it can only wait for the lagging node to synchronize the block height to be completely consistent with other nodes before it can participate in the consensus process normally.

[0077] It can be understood that the block header in this application contains parameters such as block Hash, transaction Merkle root, transaction ID Merkle root, etc. When each node verifies the legitimacy of the block header in the response message, it can be for the block hash value (i.e., block Hash) in the block header in each response message. When the legitimacy of the block hash value is verified, each node can also verify the node signature of the block to be synchronized carried in the response message to verify whether there are enough nodes to recognize the block to be synchronized, that is, verify the block Hash contained in the block header and verify the node signature to complete the verification of the block header. In addition, when each node verifies the legitimacy of the block header in the response message, it can be for the block hash value (i.e., block Hash) in the block header in each response message. It can also be for the transaction Merkle root, transaction ID Merkle root and other parameters in the block header in each response message. The legitimacy is not specifically limited here.

[0078] For example, suppose that node A in the node cluster sends a block request for a block to be synchronized to node B in the blockchain to obtain a response message for the block to be synchronized returned by node B that meets the first height condition, for example, Figure 4 As shown in the figure, it is a schematic diagram of the way in which the lagging node obtains blocks. Node A can send a block request 1 for the block to be synchronized Block8 to node B in the blockchain in the format of Figure 4 As shown in (1), the block request in this application includes at least 4 fields, namely: BlockHeight (block height), lncludeTxs (true / false) (whether to include a transaction list), lncludeTxIDs (true / false) (whether to include a transaction ID list), and PushTxs (true / false) (whether to push transactions). Among them, the value of lncludeTxs (true / false) (whether to include a transaction list) can be set to true or false. When the value of lncludeTxs (false) is set to false, it indicates that the returned response message does not include a transaction list; the value of lncludeTxIDs (true / false) (whether to include a transaction ID list) can be set to true or false. When the value of lncludeTxIDs (false) is set to false, it indicates that the returned response message does not include a transaction ID list; the value of PushTxs (true / false) (whether to push transactions) can be set to true or false. When the value of PushTxs (false) is set to true, it indicates that other nodes will automatically push the transaction tasks included in the block.

[0079] Further, when node B receives the signal sent by node A, Figure 4 When the block request 1 for the block to be synchronized Block8 shown in (1) is sent, node B returns a response message 1 containing BlockHeight (block height), transaction ID list, but not transaction list to node A based on the following 4 field values ​​BlockHeight (block height), lncludeTxs (false), lncludeTxIDs (true), and PushTxs (true) contained in the block request 1, so that node A receives the response message 1 for the block to be synchronized Block8. 8 and does not contain a transaction set (transaction list), node A verifies the block header (block hash value) in the response message 1, and when the verification passes, node A stores the block Block8 containing the block header (block hash value, block height) in the local account book, and updates the first block height H0=7 of the local node to H0=7+1=8, that is, after node A stores the block Block8 containing the block header (block hash value, block height) in the local account book, the block height maintained by node A itself is updated to H0=8.

[0080] Further, assuming that the second block height H1=8 of the target node, that is, when the updated first block height H0=8 is consistent with the second block height H1=8, node A can join the consensus process for the new block Block9 currently awaiting consensus, that is, the original block height of node A is H0=7, which lags behind the maximum block height H1=8 agreed upon by other nodes in the node cluster, so node A cannot participate in the normal consensus process. When node A synchronizes the block height it maintains to be consistent with the block height H1=8 of other nodes, node A can join the consensus process for the new block Block9 currently awaiting consensus. For example, node A can join the consensus process for the new block Block9 currently awaiting consensus as a master node or a slave node.

[0081] In this embodiment, by obtaining the first block height of the local node and the second block height of the target node in the blockchain, when the difference between the second block height and the first block height is greater than a preset threshold, a block request for the block to be synchronized is sent to the node that meets the first height condition in the blockchain; when a response message for the block request is received, the block header in the response message is verified, and when the verification passes, the block containing the block header is stored in the local account book, and the first block height of the local node is updated; when the updated first block height is consistent with the second block height, it is added to the blockchain consensus process. Since the difference is the difference between the first block height of the local node and the second block height of the target node, when the difference is greater than the preset threshold, it triggers the sending of a block request for the block to be synchronized to the node that meets the first height condition in the blockchain, so that when a response message for the block to be synchronized is received, the block header in the response message can be quickly verified, and when the block header is verified, the block containing the block header is stored in the local account book, and the first block height of the local node is updated, so that the first block height of the local node reaches the specified second block height as soon as possible, and is added to the consensus process of the blockchain as soon as possible. Compared with the method of synchronizing the entire block, the overall performance in the blockchain is several orders of magnitude higher, which allows nodes to quickly participate in the consensus, effectively improving the consensus efficiency of the blockchain while improving the processing performance of the entire blockchain.

[0082] In one embodiment, the step of obtaining a first block height of a local node and a second block height of a target node in a blockchain includes:

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

[0084] Send a message request to other nodes in the blockchain to obtain the node block height;

[0085] When receiving each response message for the message request, obtaining the node block height in each response message;

[0086] According to the preset security screening conditions, the second block height of the target node is determined from the block heights of each node.

[0087] Among them, other nodes refer to nodes in the node cluster other than the current node. For example, taking node A in the node cluster as an example, after node A obtains the first block height in the blockchain maintained by itself, node A can send a message request for obtaining the node block height to other nodes in the blockchain (nodes other than node A).

[0088] The preset security screening condition refers to the pre-set security screening condition for the node. The preset security screening condition in the present application can be a node fault tolerance condition. For example, the node fault tolerance condition is set to: the block height recognized by f+1 nodes, where f refers to the maximum number of fault-tolerant nodes allowed in the blockchain system, i.e., the maximum number of fault-tolerant nodes. For example, taking a blockchain system with 4 nodes as an example, under the Byzantine consensus algorithm, 1 fault-tolerant node is allowed, i.e., in a blockchain system with 4 nodes, f=1. The preset security screening condition can be set to: f+1=1+1=the block height recognized by 2 nodes.

[0089] Specifically, a blockchain system with 4 nodes is used as an example. Assume that node A in the node cluster of the blockchain system obtains the maximum block height H0 in the local blockchain maintained by itself, and uses the maximum block height H0 as the first block height; further, node A can generate a message request for obtaining the maximum block height (node ​​block height), and broadcast the message request to other nodes in the node cluster, so that other nodes return a reply message containing the maximum block height in response to the message request; when node A receives a reply message returned by other nodes to the message request, node A can obtain the maximum block height (node ​​block height) in each reply message, and according to the preset security screening condition: f+1=the maximum block height recognized by 2 nodes, determine the second block height of the target node from the maximum block height (node ​​block height) in each reply message, for example, Figure 5 As shown in the figure, it is a schematic diagram for determining the maximum block height in the blockchain. Assume that node A obtains the maximum block height (node ​​block height) in the response message returned by the other three nodes. Figure 5, 110, 99, and 110 are shown in the figure respectively. Then, node A can determine the maximum block height recognized by both nodes as 110 from the maximum block height (node ​​block height) in each response message according to the preset security screening condition: f+1=the maximum block height recognized by both nodes, and use the maximum block height 110 as the second block height of the target node. As a result, the maximum block height reached by other nodes in the blockchain can be quickly and accurately determined. At the same time, the block header in the response message is verified, and when the verification of the block header is passed, the block containing the block header is placed in the local account book, so that the first block height of the local node reaches the specified maximum block height as soon as possible, which can enable the lagging nodes to quickly participate in the consensus, thereby effectively improving the consensus efficiency of the blockchain.

[0090] In one embodiment, according to a preset security screening condition, the step of determining the second block height of the target node from the block heights of each node includes:

[0091] Determine the number of trusted nodes based on node fault tolerance conditions;

[0092] Among other nodes, nodes whose node block heights meet the second height condition are selected as trusted nodes according to the number of trusted nodes;

[0093] When the node block heights of the nodes in the trusted nodes are the same, the node block height of any node in the trusted nodes is determined as the second block height of the target node;

[0094] When the node block heights of each node in the trusted node are different, the node block height that meets the third height condition is selected from the node block heights of each node in the trusted node as the second block height of the target node.

[0095] Among them, the node fault tolerance condition refers to the maximum fault-tolerant node condition allowed in the blockchain system. For example, the node fault tolerance condition in the present application can be the maximum number of fault-tolerant nodes allowed in the blockchain system. Taking a blockchain system with 4 nodes as an example, under the Byzantine consensus algorithm, 1 fault-tolerant node is allowed, that is, in a blockchain system with 4 nodes, f=1, and the node fault tolerance condition can be set to: f+1=the block height recognized by 2 nodes.

[0096] The number of trusted nodes refers to the number of trusted nodes determined based on the maximum number of fault-tolerant nodes allowed in the blockchain system. For example, the method for determining the number of trusted nodes in the present application can be obtained by the formula f+1, that is, the number of trusted nodes = f+1, where f refers to the maximum number of fault-tolerant nodes allowed in the blockchain system, and f is the maximum number of fault-tolerant nodes.

[0097] The second height condition is to select the block heights that meet the node trust quantity after sorting them in descending order. For example, after sorting the node block heights returned by each node in descending order, the sequence is: 110 (node ​​B), 110 (node ​​C), x (unknown), then select the nodes corresponding to the block height 110 that meets the node trust quantity 2 as node B and node C, that is, node B and node C are regarded as trustworthy nodes.

[0098] It can be understood that in this application, if a node does not return the node block height or returns an error, or the returned node block height is unknown, the node block height of the node is deemed to be unknown and will not be selected.

[0099] The third height condition refers to selecting the maximum block height that all trusted nodes have reached from the block heights of the trusted nodes. For example, if the node block heights of nodes B and C in the trusted nodes are 110 and 101 respectively, the maximum block height that both nodes B and C have reached is 101. Since the node block height of node B is 110, it means that node B has reached the block height 101, but the node block height of node C is 101, which means that the maximum block height that node C has reached is 101, and it has not reached 110 yet. Therefore, the maximum block height that both nodes B and C have reached is 101.

[0100] Specifically, a 4-node blockchain system is used as an example. Figure 5 As shown in the figure, it is a schematic diagram for determining the maximum block height in the blockchain. Assume that node A obtains the maximum block height (node ​​block height) in the response message returned by the other three nodes. Figure 5 , 110, 99, and 110, respectively. Node A can determine the node trust quantity L=f+1=2 according to the node fault tolerance condition: the block height recognized by f+1 nodes; further, node A sorts the node block heights returned by other nodes in order from large to small according to the block height to obtain a sequence: 110 (node ​​B), 110 (node ​​D), 99 (node ​​C), and then selects the nodes corresponding to the block heights 110 and 110 that meet the node trust quantity 2 as nodes B and D, that is, nodes B and D are used as trusted nodes. Further, node A can determine whether the node block heights of each node in the trusted node are the same. Since 110 (node ​​B) is equal to 110 (node ​​D), when the node block heights of each node in the trusted node are the same, node A can determine the node block height 110 (node ​​B) or 110 (node ​​D) of any node in the trusted node as the second block height of the target node, that is, the second block height is 110.

[0101] In addition, suppose that node A obtains the maximum block height (node ​​block height) in the response messages returned by the other three nodes as follows: Figure 5 As shown in , they are 110, 99, and 101 respectively. Node A sorts the node block heights returned by other nodes in descending order of block heights to obtain a sequence: 110 (node ​​B), 101 (node ​​D), 99 (node ​​C), and then selects the nodes corresponding to the block heights 110 and 101 that meet the node trust quantity 2 as nodes B and D, that is, nodes B and D are used as trusted nodes. Further, node A can determine whether the node block heights of each node in the trusted node are the same. Since 110 (node ​​B) is not equal to 101 (node ​​D), when the node block heights of each node in the trusted node are different, node A can select the maximum block height 101 reached by all trusted nodes from the node block heights of each node in the trusted node as the second block height of the target node, that is, the second block height is 101.

[0102] In this embodiment, based on the preset node fault tolerance conditions, the maximum block height reached by other nodes in the blockchain can be quickly and accurately determined. At the same time, the block header in the response message is verified, and when the block header is verified, the block containing the block header is stored in the local ledger, that is, the block header is synchronized. The method is adopted to make the first block height of the local node reach the specified maximum block height as soon as possible, so that the lagging nodes can quickly participate in the consensus, thereby effectively improving the consensus efficiency of the blockchain.

[0103] In one embodiment, after obtaining the first block height of the local node and the second block height of the target node in the blockchain, the method further includes:

[0104] When the first block height is less than the second block height, determining a difference between the second block height and the first block height;

[0105] When the difference is within the preset block height difference range, a block request for the block to be synchronized is sent to the node in the blockchain that meets the first height condition.

[0106] Among them, the preset block height difference range refers to the block height difference range condition, which can be represented by the configuration parameter RangeHeight. For example, if the value of RangeHeight is set to 10, the block height difference range is: less than or equal to RangeHeight, that is, when the difference in block height between the current node and other nodes is less than or equal to RangeHeight, it means that the difference satisfies the preset block height difference range, that is, the difference is within the preset block height difference range. At this time, the current node only needs to synchronize the block header to quickly complete the block synchronization and promptly participate in the consensus process for the new block.

[0107] Specifically, after the node cluster in the blockchain system obtains the first block height of the local node and the second block height of the target node in the blockchain, the node cluster can determine the difference between the second block height and the first block height. For example, each node in the node cluster can compare the first block height with the second block height to obtain a comparison result; when the comparison result indicates that the first block height is less than the second block height, each node in the node cluster can calculate the difference between the second block height and the first block height, and use the difference as the difference between the second block height and the first block height.

[0108] Further, each node in the node cluster can determine whether the calculated difference is within the preset block height difference range. For example, each node in the node cluster can determine whether the calculated difference d=5 is within the preset block height difference range RangeHeight=10. Since d=5 is less than RangeHeight=10, that is, when the difference d=5 is within the block height difference range RangeHeight=10, each node in the node cluster sends a block request for the block to be synchronized to the node that meets the first height condition in the blockchain. As a result, based on the relationship between the block heights of the lagging node and other nodes, other nodes in the blockchain that are higher than the block height of the lagging node can be quickly and accurately determined, and by sending a block request for obtaining a block that does not contain a transaction set to a node whose block height is higher than the block height of the lagging node, the block to be synchronized can be quickly and accurately synchronized, so that the first block height of the local node reaches the specified maximum block height as soon as possible, so that the lagging node can quickly participate in the consensus, thereby effectively improving the consensus efficiency of the blockchain.

[0109] In one embodiment, when the difference between the second block height and the first block height is greater than a preset threshold, the step of sending a block request for the block to be consensus to a node that meets the first height condition in the blockchain includes:

[0110] When the difference between the second block height and the first block height is greater than a preset threshold, the first block height is compared with each node block height to obtain a comparison result;

[0111] When the comparison result indicates that the first block height is less than the node block height, a block request for the block to be synchronized is sent to the node corresponding to the node block height.

[0112] Among them, the node that meets the first height condition refers to the node whose node block height is greater than the first block height. For example, taking node A in the node cluster as an example, assuming that node A obtains the maximum block height H0=5 in the local blockchain maintained by itself, and uses the maximum block height H0=5 as the first block height, then the node that meets the first height condition refers to the node whose node block height is greater than the first block height H0=5. For example, the block height of node B is 6, then the node that meets the first height condition can be node B.

[0113] Specifically, node A in the node cluster of the blockchain system is used as an example for explanation. After node A determines the difference d=5 between the second block height and the first block height H0=5, node A can determine whether the obtained difference d=5 is greater than the preset threshold 0. Since d=5 is greater than the preset threshold 0, node A can compare the first block height H0=5 with the node block height of each node in the node cluster to obtain a comparison result; when the comparison result indicates that the first block height H0=5 is less than the node block height H2=6, node A can send a block request for the block to be synchronized to node B corresponding to the node block height H2=6; in addition, after node A determines whether the obtained difference d=5 is greater than the preset threshold 0, it can further determine whether the difference d=5 is within the preset threshold 0. Assuming that the block height difference range is within, for example, node A can determine whether the difference d=5 is within the preset block height difference range RangeHeight=10. Since d=5 is greater than the preset threshold value 0 and less than RangeHeight=10, that is, when the difference d=5 is within the preset block height difference range RangeHeight=10, node A can compare the first block height H0=5 with the node block height of each node in the node cluster to obtain a comparison result; when the comparison result indicates that the first block height H0=5 is less than the node block height H2=6, node A can send a block request for the block to be synchronized to node B corresponding to the node block height H2=6. As a result, lagging nodes can send block requests to other nodes, and other nodes will return data for the block request. The selection of peer nodes (other nodes) can be distinguished by the node block height obtained by the current node. That is, if the block height value of the selected peer node is larger than the maximum block height value maintained by itself, the information of the block to be synchronized can be obtained through this node, thereby achieving fast and accurate synchronization of blocks, and also effectively improving the efficiency of synchronization of blocks.

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

[0115] Get the transaction collection field of the first value and the push transaction field of the second value;

[0116] The sending a block request for a block to be synchronized to a node in the blockchain that meets the first height condition includes:

[0117] A block request including a transaction set field and a push transaction field is sent to a node in the blockchain that meets the first height condition, so that the node returns a response message that does not include a transaction set based on the transaction set field, and automatically pushes a transaction task for the block to be synchronized based on the push transaction field.

[0118] Among them, the transaction set field refers to a field used to indicate whether a transaction list is included, and the value of this field includes true or false. For example, the transaction set field in this application can be represented by lncludeTxs.

[0119] The push transaction field is used to indicate whether to push the transaction. The value of this field includes true or false. For example, Figure 6 As shown in the figure, it is a schematic diagram of adding custom parameters. The push transaction field in this application can be used as follows Figure 6 It is represented by the PushTxs shown in .

[0120] The transaction set field of the first value may be lncludeTxs(false), that is, the value of the transaction set field is false, indicating that the returned response message does not contain a transaction list.

[0121] The second value of the push transaction field can be PushTxs(true), that is, the value of the push transaction field is true, indicating that other nodes will automatically push the transaction tasks contained in the block to be synchronized.

[0122] The first value in the present application may be false, and the second value may be true. It can be understood that the first value and the second value in the present application are only used to distinguish different field values.

[0123] Specifically, take node A in the node cluster of the blockchain system as an example. After node A determines the difference d=5 between the second block height and the first block height H0=5, node A can determine whether the obtained difference d=5 is within the preset block height difference range. When the difference d=5 is within the preset block height difference range RangeHeight=10, node A can compare the first block height H0=5 with the node block height of each node in the node cluster to obtain a comparison result; when the comparison result indicates that the first block height H0=5 is less than the node block height H2=6, node A can obtain the transaction set field lncludeTxs(false) of the first value and the push transaction field PushTxs(true) of the second value, and send a message to the node block height. Node B corresponding to degree H2=6 sends a block request 1 including BlockHeight (block height), lncludeTxs(false), and PushTxs(true); further, when node B receives a block request 1 including BlockHeight (block height), lncludeTxs(false), and PushTxs(true) sent by node A, node B returns a response message that does not include a transaction set based on lncludeTxs(false) carried in block request 1, and node B can automatically push transaction tasks for the block to be synchronized based on PushTxs(true) at idle time. Thus, by setting different values ​​of configuration parameters, it is possible to quickly and accurately synchronize the synchronized blocks by synchronizing the block header, so that the first block height of the local node reaches the specified maximum block height as soon as possible, and the lagging nodes can quickly participate in the consensus, thereby effectively improving the consensus efficiency of the blockchain.

[0124] In one embodiment, after sending a block request including a get transaction set field and a push transaction field to a node that meets the first height condition in the blockchain, the method further includes:

[0125] Get the transaction collection field of the second value;

[0126] A block request including a transaction set field is sent to a node in the blockchain that meets the first height condition, so that the node returns a response message including a transaction set based on the transaction set field.

[0127] The transaction set field of the second value refers to lncludeTxs(true), that is, the value of the transaction set field is true, indicating that the returned response message contains a transaction list.

[0128] Specifically, take node A in the node cluster of the blockchain system as an example. Node A sends a block request 1 containing BlockHeight (block height), lncludeTxs(false), and PushTxs(true) to node B, and receives a response message from node B that does not contain a transaction set based on lncludeTxs(false) carried in block request 1. If node A does not receive a transaction task for the block to be synchronized that is automatically pushed by node B based on PushTxs(true), node A can reuse block request 1. For example, Figure 4 (1) shows the block request 1 sent by node A to node B. Node A can reuse block request 1 and send Figure 4 After lncludeTxs(false) in the block request 1 shown in (1) is changed to lncludeTxs(true), node A can send a block request 2 containing the transaction set field to node B again at an appropriate time (such as an idle period). That is, node A sends a block request 2 containing the transaction set field to node B as shown in Figure 4 The block request 2 including lncludeTxs(ture) shown in (3) above enables node B to return a response message including a transaction set based on lncludeTxs(ture) carried in the block request 2.

[0129] In this embodiment, in order to solve the problem that backward nodes in the blockchain system must completely synchronize all blocks before they can participate in the consensus process, a fast consensus joining solution is proposed by utilizing the characteristic that backward nodes only need to synchronize block headers to verify them. That is, when actually synchronizing blocks, backward nodes can first synchronize block headers, and then adopt an asynchronous processing method, that is, transaction tasks can be synchronized later by reusing block requests, so that backward nodes can quickly participate in the consensus process, thereby effectively improving the consensus efficiency of the entire blockchain.

[0130] In one embodiment, after obtaining the first block height of the local node and the second block height of the target node in the blockchain, the method further includes:

[0131] When the difference between the second block height and the first block height is zero, determining the block height of the block to be consensus based on the first block height;

[0132] When the block height of the block to be consensus meets the block generation conditions, the transaction task is obtained from the transaction pool and encapsulated into a proposal message of the block to be consensus;

[0133] Broadcast the proposal message to other nodes in the blockchain so that other nodes can reach consensus on the consensus block based on the transaction tasks.

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

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

[0136] The block generation condition refers to the condition used to trigger the block generation. For example, the block generation condition can be set to the block height being greater than a preset threshold, and the preset threshold can be 1. Block generation means that the node can encapsulate the transaction task into a block.

[0137] A proposal message is a communication message between nodes in a blockchain. For example, a communication message may also include a consensus message, a voting message, etc. A proposal message in this application refers to a message carrying a proposal. For example, a proposal message carries proposal 1, and proposal 1 is generated for the newly generated block 8 to be agreed upon.

[0138] Specifically, node A in the node cluster of the blockchain system is used as an example for explanation. Under the underlying blockchain model based on the BFT consensus, after node A determines the difference between the second block height and the first block height maintained by itself, when the difference is zero, it means that the first block height maintained by node A itself is the same as the second block height, then node A can directly participate in the consensus process of the current round of consensus blocks in the blockchain, that is, node A can determine the block height of the consensus block based on the first block height. 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 first block height H0 = 5; further, node A can determine whether the block height of the consensus block Block (6) to be H1 = 6 meets the block generation condition. For example, the block generation condition in this application can be set to that the block height is greater than a preset threshold, and the preset threshold can be 1. The node that generates the block is qualified to encapsulate the transaction task into a proposal message of the consensus block. When the block height of the consensus block Block (6) meets the block generation condition, node A becomes the master node. Node A can obtain transaction tasks from the local transaction pool, and encapsulate the transaction tasks into a proposal message 1 of the consensus block Block (6), and broadcast the proposal message 1 to other nodes in the blockchain, so that other nodes can reach a consensus on the consensus block Block (6) based on the transaction tasks in the proposal message 1. In this way, each node in the node cluster can quickly and accurately determine whether the node is a lagging node based on the difference between the block height maintained by itself and the maximum block height in the blockchain. If the node is not a lagging node, that is, when the difference is zero, the node can participate in this round of consensus process normally.

[0139] In one embodiment, after determining the block height of the block to be consensus based on the first block height, the method further includes:

[0140] When the block height of the block to be consensus does not meet the block generation conditions and a proposal message for the block to be consensus is received from the master node, the proposal message is verified, and when the verification passes, the transaction task in the proposal message is executed to obtain the execution result of the transaction task;

[0141] When the execution result is inconsistent with the target execution result carried in the proposal message, an affirmative vote or a negative vote is generated, and the affirmative vote or the negative vote is broadcast to other nodes in the blockchain.

[0142] Among them, the slave node needs to verify the legitimacy of each transaction task contained in the proposal message broadcast by the master node, that is, the legitimacy verification refers to verifying the legitimacy of all transaction tasks in the consensus block carried by the proposal message. For example, in this application, when each slave node verifies whether the transaction task is legal: it can use the method of comparing execution results. For example, the execution result A of the current slave node on transaction task 1 can be compared with the execution result B of the master node carrying the proposal message to execute the transaction task 1. If the two execution results are consistent, that is, when it is determined that the execution result A and the execution result B are consistent (the same), then the current slave node can determine that the transaction task 1 is a legal transaction task, and the verification result is used to indicate that the transaction task 1 is a legal transaction task; if the two execution results are inconsistent, that is, when it is determined that the execution result A and the execution result B are inconsistent (not the same), then the current slave node can determine that the transaction task 1 is an illegal transaction task, and the verification result is used to indicate that the transaction task 1 is an illegal transaction task. That is, the legitimacy of the transaction task in this application is determined by whether the execution results of the transaction task are consistent.

[0143] Specifically, we take node A in the node cluster of the blockchain system as an example. Under the underlying blockchain model based on BFT consensus, Figure 7 As shown in the figure, it is a schematic diagram of the processing flow of backward nodes in the blockchain. Figure 7 In the process shown in , when node A determines that the difference between the second block height and the first block height maintained by itself is zero, it means that the first block height maintained by node A itself is the same as the second block height, then node A can directly participate in the consensus process of the block to be agreed upon in this round in the blockchain, that is, node A can determine the block height of the next block to be agreed upon based on the first block height. For example, node A can determine the block height of the block to be agreed upon Block(6) to be H1=H0+1=5+1=6 based on the first block height H0=5; further, node A can determine whether the block height of the block to be agreed upon Block(6) to be H1=6 satisfies the condition Block condition: When the block height of the consensus block Block(6) does not meet the block condition, node A, as a slave node, needs to wait for the master node in the blockchain to send a proposal message for the consensus block Block(6). When node A receives the proposal message for the consensus block Block(6) sent by the master node, it verifies the proposal message. If the verification of the proposal message passes, node A executes each transaction task included in the proposal message and obtains the execution result of each transaction task. If node A verifies the proposal message and obtains a verification result indicating that the verification of the proposal message fails, node A can discard the proposal message.

[0144] Furthermore, after node A executes each transaction task included in the proposal message and obtains the execution result of each transaction task, node A can compare the execution result of each transaction task obtained by itself with the target execution result of each transaction task carried in the proposal message to obtain a comparison result; when the comparison result indicates that the execution result obtained by itself is consistent with the target execution result carried in the proposal message, node A can generate an affirmative vote and broadcast the affirmative vote to other nodes in the blockchain; when the comparison result indicates that the execution result obtained by itself is inconsistent (not the same) with the target execution result carried in the proposal message, node A can automatically generate an affirmative vote or a negative vote, and broadcast the affirmative vote or the negative vote to other nodes in the blockchain, so that other nodes in the blockchain can quickly receive the voting message of node A and quickly complete the consensus process for the block to be consensus without timeout waiting, so that other nodes can quickly collect votes, thereby improving the performance and consensus efficiency of the entire blockchain.

[0145] For example, Figure 6 The newly configured parameter NotEqualPolicy shown in the figure, that is, NotEqualPolicy is the pre-set processing strategy for inconsistent execution results (inconsistent data). NotEqualPolicy refers to how to deal with the situation when the execution results of the local node and other nodes are inconsistent. You can choose: 1. Vote against; 2. Vote in favor; 3. Timeout and no vote; that is, when the comparison result indicates that the execution result obtained by itself is inconsistent (not the same) with the target execution result carried in the proposal message, node A can automatically generate a vote in favor or against, and broadcast the vote in favor or against to other nodes in the blockchain, so that other nodes in the blockchain can quickly receive the voting message of node A and quickly complete the consensus process for the block to be agreed upon. It should be emphasized that the reason for adding the configuration parameter NotEqualPolicy is that in the technical solution provided by the embodiment of the present application, when the difference between the second block height and the first block height is greater than the preset threshold or within the preset block height difference range, this node (node ​​A) only synchronizes the block header. Although statistically speaking, the probability of different transactions operating the same key within a period of time is relatively low, there is still such a possibility, that is, it is not ruled out that some business systems will frequently modify the key of a certain transaction task. Therefore, there may be a situation where the execution results of a certain transaction task executed by this node (node ​​A) and other nodes are inconsistent. Therefore, when the execution results of a transaction task are inconsistent, node A can be processed according to the configured policy (NotEqualPolicy), generally using the processing method of automatically generating negative votes or automatically generating positive votes, because timeout and failure to vote may cause other nodes to collect votes more slowly, thereby affecting the performance and consensus efficiency of the entire blockchain.

[0146] It can be understood that the NotEqualPolicy proposed in this application does not affect the consensus result itself. For example, if the voting result is a negative vote, but other nodes vote in favor, then the consensus block will still reach a consensus. Correspondingly, due to the existence of the vote of node A, the operation process of other nodes will be accelerated, especially when node A serves as the master node (because other nodes no longer need to wait for timeout, other nodes can generate negative votes, and negative votes are also processed faster than timeouts).

[0147] In this embodiment, when the comparison result indicates that the execution result obtained by itself is inconsistent (not the same) as the target execution result carried in the proposal message, the node can also automatically generate an affirmative vote or a negative vote based on the newly added configuration parameter NotEqualPolicy, and broadcast the affirmative vote or the negative vote to other nodes in the blockchain, so that other nodes in the blockchain can quickly receive the voting message of node A and quickly complete the consensus process for the block to be agreed upon, thereby accelerating the consensus processing process of the entire blockchain, and achieving effective improvement of the consensus efficiency of the blockchain while effectively improving the processing performance of the entire blockchain.

[0148] In one embodiment, after obtaining the first block height of the local node and the second block height of the target node in the blockchain, the method further includes:

[0149] When the difference between the second block height and the first block height is not greater than a preset threshold, sending a block request for obtaining a transaction set to other nodes in the blockchain;

[0150] When receiving a response message containing a transaction set returned in response to a block request containing a transaction set, verifying the block header and the transaction set in the response message containing the transaction set;

[0151] When the verification is passed, the block header and transaction set are stored in the local ledger, and the first block height of the local node is updated.

[0152] Specifically, we take node A in the node cluster of the blockchain system as an example. Under the underlying blockchain model based on BFT consensus, Figure 7 As shown in the figure, it is a schematic diagram of the processing flow of backward nodes in the blockchain. Figure 7According to the process shown in , after node A determines the difference between the second block height and the first block height maintained by itself, node A can determine whether the difference is greater than a preset threshold or within a preset block height difference range. When the difference is not greater than the preset threshold or is not within the preset block height difference range, node A can send a block request for obtaining a transaction set to other nodes in the blockchain; when node A receives a response message containing a transaction set returned by other nodes in response to the block request, node A can verify the block header and transaction set in the response message containing the transaction set, that is, under normal circumstances, when node A synchronizes the block 1 to be synchronized, it is necessary to verify the block header and transaction tasks in the block body of the block 1 to be synchronized, and only when the block header and the transaction tasks in the block body are verified, node A can store the block header and transaction set (each transaction task in the block body) in the local account book and update the first block height of the local node. As a result, each node in the node cluster can determine whether it is a lagging node through the block height. If it is not a lagging node, the synchronization process between nodes can be executed normally; if it is a lagging node, an accelerated synchronization method can be used to enable the lagging node to quickly participate in the consensus, thereby improving the consensus efficiency of the entire blockchain.

[0153] In one embodiment, the step of verifying the block header in the response message includes:

[0154] Verify the legitimacy of the block hash value of the block header in the response message;

[0155] The method further comprises: when the legitimacy verification of the block hash value passes, verifying the node signature of the block to be synchronized;

[0156] When the node signature is verified, the transaction identification list in the response message is obtained, and the hash value of the transaction identification list is determined;

[0157] When the hash value of the transaction identifier list is consistent with the hash value in the response message, the transaction set containing the transaction identifier list in the local transaction pool is deleted, and the transaction task in the local transaction pool is updated;

[0158] When the hash value of the transaction identification list is inconsistent with the hash value in the response message, the response message is discarded.

[0159] Among them, the block hash value refers to the hash value (Hash) of the block body. The block and the block Hash (block hash value) are one-to-one corresponding. The block Hash (block hash value) can be regarded as the unique identifier of the block.

[0160] The transaction identifier list refers to the transaction identifier list field of the block to be synchronized carried in the response message, for example Figure 8As shown in the figure, it is a schematic diagram of the format of block request and response messages. The transaction identification list can be as follows Figure 8 The transaction ID list shown in is represented by TxlDs.

[0161] The hash value of the transaction ID list refers to the Merkle root of the transaction ID list, that is, the transaction ID Merkle root, which can be used as follows Figure 8 It is represented by the TxIDRoot (transaction ID Merkle root) shown in .

[0162] Specifically, we take node A in the node cluster of the blockchain system as an example. Under the underlying blockchain model based on BFT consensus, Figure 7 As shown in the figure, it is a schematic diagram of the processing flow of backward nodes in the blockchain. Figure 7 According to the process shown in , after node A sends a block request for the block to be synchronized and for obtaining a block that does not contain a transaction set to node B that meets the first height condition in the blockchain, node A can receive a response message B from node B for the block to be synchronized Block (6) that does not contain a transaction set (only contains a block header). Node A can verify the legitimacy of the block hash value in the block header in the response message B. When the legitimacy verification of the block hash value in the block header in the response message B passes, node A can further verify the node signature of the block to be synchronized. When the verification of the node signature passes, node A can obtain the transaction identification list TxIDs in the response message B and calculate the hash value TxIDRoot of the transaction identification list. Node A can compare the TxIDRoot calculated by itself with the TxIDRoot carried in the block header of the response message B. When the TxIDRoot calculated by itself is consistent (the same) with the TxIDRoot carried in the block header of the response message B, node A can delete the transaction tasks in the transaction identification list TxIDs in the local transaction pool (for example, including TxID1 and TxID2), and update the transaction tasks in the local transaction pool, that is, by deleting the old transaction tasks TxID1 and TxID2 that have reached consensus in the local transaction pool, obtaining new transaction tasks so that the transaction tasks in the local transaction pool are updated and consistent with the transaction tasks in the local transaction pools of other nodes as much as possible, so as to improve the accuracy of block consensus.

[0163] In addition, when the TxIDRoot calculated by itself is inconsistent (not the same) with the TxIDRoot in the response message B, node A can discard the response message. As a result, by setting different values ​​of the configuration parameters, it is possible to quickly and accurately synchronize the synchronization block by synchronizing the block header, so that the first block height of the local node reaches the specified maximum block height as soon as possible, and the lagging nodes can quickly participate in the consensus, thereby effectively improving the consensus efficiency of the blockchain; at the same time, by deleting the old transaction tasks that have reached consensus in the local transaction pool, the transaction tasks in the local transaction pool are updated and as consistent as possible with the transaction tasks in the local transaction pools of other nodes, which can improve the accuracy of voting during the block consensus process, thereby improving the accuracy of subsequent block consensus.

[0164] In one embodiment, the steps of joining the blockchain consensus process include:

[0165] When the updated first block height is consistent with the second block height, the block height of the block to be agreed upon is determined based on the updated first block height;

[0166] When the block height of the block to be consensus meets the block generation conditions, the transaction task is obtained from the transaction pool and encapsulated into a proposal message of the block to be consensus; the proposal message is broadcast to other nodes in the blockchain so that other nodes can reach consensus on the block to be consensus based on the transaction task;

[0167] When the block height of the block to be consensus does not meet the block generation conditions, the master node in the blockchain waits for sending a proposal message for the block to be consensus, and consensus is reached on the block to be consensus based on the transaction tasks in the proposal message.

[0168] Specifically, we take node A in the node cluster of the blockchain system as an example. Under the underlying blockchain model based on BFT consensus, Figure 7 As shown in the figure, it is a schematic diagram of the processing flow of backward nodes in the blockchain. Figure 7According to the process shown in , when node A stores the block including the block header in the local ledger and completes the synchronization of the block to be synchronized, node A can automatically update the first block height of the local node maintained by itself. When the updated first block height is consistent with the second block height, node A can join the consensus process for the new block to be agreed upon in this round, that is, node A can determine the block height of the block to be agreed upon based on the updated first block height; when the block height of the block to be agreed upon meets the block generation condition, node A becomes the master node, node A can obtain transaction tasks from the local transaction pool, and encapsulate the transaction tasks into a proposal message of the block to be agreed upon; further, node A can broadcast the proposal message to other nodes in the blockchain so that other nodes can reach a consensus on the block to be agreed upon based on the transaction tasks contained in the proposal message; or, when the block height of the block to be agreed upon does not meet the block generation condition, node A becomes a slave node, waiting for the master node in the blockchain to send a proposal message for the block to be agreed upon, and reaches a consensus on the block to be agreed upon based on the transaction tasks in the proposal message received from the master node. As a result, the condition for synchronizing blocks is adjusted to synchronizing block headers. After the lagging node has synchronized the block header, it can quickly reach a consensus with the block height of other nodes, so that the lagging node can quickly participate in this round of consensus, thereby improving the overall consensus efficiency.

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

[0170] When the abnormal node (backward node) is back online, the above-mentioned blockchain consensus method can be adopted, that is, in the blockchain system, after the backward node in the node cluster obtains the first block height maintained locally and the second block height of the target node, the backward node in the node cluster can determine the difference between the second block height and the first block height; when the difference is greater than the preset threshold or within the preset block height difference range, the backward node can send a block request for the block to be synchronized to the node that meets the first height condition in the blockchain; when the backward node receives a response message for the block request, the backward node can verify the block header in the response message, and when the verification is passed, the block containing the block header is stored in the local account book, and the first block height of the local node is updated; when the updated first block height is consistent with the second block height (the same), the backward node can be added to the blockchain consensus process. Therefore, by disassembling the block, using the method of verifying the block header and only synchronizing the block header, the backward node can quickly reach the specified height and participate in the consensus process, thereby improving the overall consensus efficiency. That is, the blockchain fast consensus solution proposed in this application has the advantages of high resource utilization, security, and high performance. By adjusting the condition of synchronizing blocks to synchronizing block headers, when a node synchronizes the block header and reaches an agreement with other nodes, it can participate in the overall consensus. Since the content contained in the block header is much smaller than the block itself, and there is no need to execute transactions (verify transactions), if only the block header is synchronized, the performance will be several orders of magnitude higher than synchronizing the entire block itself, allowing nodes to quickly participate in the consensus, thereby improving the efficiency of the consensus.

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

[0172] In traditional blockchains, block synchronization is handled by fully synchronizing to a block scheme that is highly consistent with other nodes. In terms of node types, there are two types: slave nodes and master nodes. First, slave nodes: Fig. 9 As shown in the figure, it is a schematic diagram of the backward slave nodes in the traditional way that cannot participate in the consensus, that is, Fig. 9 As shown in , when other nodes are at consensus Block 11, the lagging slave nodes cannot participate in the consensus and must wait for local synchronization to Block 10.

[0173] The second is the master node: Fig.10 As shown in the figure, it is a schematic diagram of the traditional method where the lagging master node cannot participate in the consensus. Fig.10As shown in , similarly, when the lagging node determines that it is the master node of Block11, it will create a proposal for Block11 based on its local ledger, but it is obvious that its proposal to create Block11 cannot be agreed upon by other nodes, because other nodes believe that the next block should be Block14, so other nodes will be limited to timeout waiting. If the lagging master node wants to participate in the consensus, it must also reach the same block height as other nodes.

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

[0175] 1) When a node lags behind, it must reach the same block height as other nodes before it can participate in the consensus. During the synchronization process, it will affect the consensus process of other nodes and reduce their processing efficiency;

[0176] 2) When there are a large number of transactions in the blockchain, the entire synchronization process is very slow, and the corresponding time range for other nodes to be affected will be very large, causing the overall blockchain performance to be relatively low for a relatively long period of time, unless someone manually participates in removing the lagging node.

[0177] That is, the consensus algorithm is the core of a blockchain system. The purpose of the consensus algorithm is to reach a consensus on blocks between nodes without forking. The consensus efficiency of a blockchain system is one of the important indicators of its performance. In a blockchain system, communication between nodes must be carried out through the network, so there must be network anomalies. The traditional blockchain consensus algorithm itself also takes into account network anomalies. For BFT consensus algorithms, when some nodes (less than the fault-tolerant range) are abnormal, the system can still operate normally. However, this normal operation comes at a price. In the BFT consensus algorithm, there is usually a distinction between master nodes and slave nodes. An honest node can only be one of them (slave node or master node) at the same time. For fairness considerations, the usual BFT consensus algorithm will adopt a rotating master node solution. If the master node that takes its turn cannot participate in the consensus normally for some reason, then for other nodes, the other nodes will wait for a certain timeout, and then reach a consensus after waiting for a certain period of time (no blocks are generated in this round of consensus), and then replace the next node as the master node.

[0178] In the above situation, if a node lags behind other nodes for some reason, then when it (the lagging node) comes back online, it will not be able to participate in the consensus in time, because its (the lagging node) block height is inconsistent with other nodes, and the proposal it (the lagging node) sends is not recognized by other nodes (because the block height of the proposal has been agreed upon). Then, if it (the lagging node) wants to participate in the consensus, it can only wait for the local node to synchronize the block to be completely consistent with other nodes, and in the whole process, although other nodes are also in consensus, their performance is discounted, that is, the performance of the entire blockchain is poor, and the consensus efficiency of the blockchain is also poor.

[0179] Therefore, in order to solve the above problems, this application proposes a fast consensus solution, which utilizes the characteristics that blockchain nodes only need to synchronize block headers to verify them, and the characteristics that the probability of transactions operating the same state data within a period of time is relatively low, so that lagging nodes can reach the specified height as soon as possible and participate in the consensus, thereby improving the overall consensus efficiency.

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

[0181] In order to solve the problem of low consensus efficiency when blockchain nodes lag behind, the characteristics of blockchain nodes only needing to synchronize block headers to verify them, as well as the low probability of transactions operating the same state data within a period of time, are used to enable lagging nodes to reach the specified height as soon as possible and participate in the consensus, thereby improving the overall consensus efficiency. In addition, this application also provides a solution when the execution results of transactions executed by lagging nodes are inconsistent with the execution results of other nodes due to incomplete synchronization data.

[0182] On the product side, the method provided in this application can be applied to the actual development of blockchain underlying software, and can also be used as a method of external publicity.

[0183] On the technical side, 1.1 improved overall process

[0184] The core point of this application is to optimize the traditional process in which backward nodes must synchronize blocks to reach consensus before participating in the consensus, and adjust the condition of synchronizing blocks to synchronizing block headers. After the backward node synchronizes the block header and reaches consensus with other nodes, the backward node can participate in the overall consensus.

[0185] The content contained in the block header is much smaller than the block itself, and no transactions need to be executed. If only the block header is synchronized, the performance will be several orders of magnitude higher than synchronizing the block itself.

[0186] like Fig.11 As shown in FIG. 1 , it is a schematic diagram of the overall process of the blockchain fast consensus solution provided by this application, as Fig.11 In the overall illustration shown in , when the lagging consensus node synchronizes blocks B11, B12, and B13, the method of synchronizing only the block header proposed in this application is adopted, so that the lagging consensus node can quickly reach the same block height as other normal consensus nodes and participate in the consensus process for block B14. Fig.12 As shown in the figure, it is a schematic diagram of the structure of the block header. Fig.12 The structure of the block header and the set of node signatures attached to the block shown in the figure can be used to verify the legitimacy of the block header by verifying the node signature to determine whether it has been recognized by the majority of other nodes.

[0187] 1.2 Important Configuration

[0188] In order to improve the blockchain fast consensus solution designed in this application, it is recommended to add the following to the implementation plan: Figure 6 The parameters shown in , where it is important to explain that the reason for adding the configuration parameter NotEqualPolicy is that in the technical solution provided by the embodiment of the present application, when the difference between the second block height and the first block height is greater than the preset threshold or within the preset block height difference range, this node (i.e., node A) only synchronizes the block header. Although statistically speaking, the probability of different transactions operating the same key within a period of time is relatively low, there is still such a possibility, that is, it is not ruled out that some business systems will frequently modify the key of a certain transaction task. Therefore, there may be a situation where the execution results of a certain transaction task performed by this node (node ​​A) and other nodes are inconsistent. Therefore, when the execution results of a transaction task are inconsistent, node A can be processed according to the configured policy (NotEqualPolicy), and generally adopts the processing method of automatically generating negative votes or automatically generating positive votes, because timeout and failure to vote may cause other nodes to collect votes slowly, thereby affecting the performance and consensus efficiency of the entire blockchain.

[0189] It can be understood that the NotEqualPolicy proposed in this application does not affect the consensus result itself. For example, if the voting result is a negative vote, but other nodes vote in favor, then the consensus block will still reach a consensus, but correspondingly, due to the existence of the vote of node A, the operation process of other nodes will be accelerated, especially when node A serves as the master node (because other nodes no longer need to wait for timeout, other nodes can generate negative votes, and negative votes are also processed faster than timeouts).

[0190] 1.3 Maximum height of other nodes

[0191] In the solution provided by this application, the lagging node must first reach the same block height as other nodes, so how to determine the block height of other nodes? Combined with the rule that BFT consensus can tolerate f nodes, the following can be used Figure 5 The strategy shown in . Fig.13 As shown, it is a schematic diagram of the processing flow of the lagging node obtaining the block height of other nodes, that is, if the lagging node wants to reach the same block height as other nodes, the processing flow of how to obtain the block height of other nodes is shown in 13.

[0192] 1.4 Synchronize block information

[0193] When the block is actually synchronized, the block header will be synchronized first, but it does not mean that the block body will not be synchronized. Instead, an asynchronous processing method will be adopted, that is, the transaction tasks in the block body will be slowly synchronized later. For example, two methods of asynchronous synchronization transaction collection are described in the embodiments of the present application: the method of automatically pushing transactions by the peer node later, or the method of actively pulling transactions by the node. That is, when asynchronously synchronizing the transaction tasks in the block body later, the node will verify the transaction tasks one by one, and after the transaction tasks are verified, each transaction task will be stored in the local account book.

[0194] The general implementation often adopts the request / response method, that is, the lagging node sends a request to obtain the block to other normal nodes, and the normal nodes will return the data. For the selection of the peer node, the lagging node can distinguish it by obtaining the block height of other nodes. In short, under normal circumstances, the block height of the peer node is greater than the block height maintained by itself, that is, the block information to be synchronized can be obtained through this node.

[0195] Considering the configuration and retrieval methods, the request and response formats can be as follows Figure 8 As shown in , for lagging nodes, it is generally as follows Figure 4 There are two ways to request (or obtain) blocks as shown in (1) and (2).

[0196] 1.5 The entire processing flow of lagging nodes

[0197] From the perspective of lagging nodes, the detailed processing flow is as follows: Figure 7 as shown in .

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

[0199] 1. In view of the problem that backward nodes in traditional technologies must fully synchronize all blocks before they can participate in consensus, a fast synchronization solution is proposed that only synchronizes block headers to participate in consensus, taking advantage of the fact that blockchain nodes only need to synchronize block headers to verify them, and the fact that the probability of transactions operating the same state data within a period of time is relatively low;

[0200] 2. The solution provided in this application only synchronizes the block header. Compared with synchronizing the entire block, its performance is several orders of magnitude higher, which allows nodes to quickly participate in the consensus and improve the efficiency of the consensus. In addition, this application also provides a solution when the node execution result is inconsistent with other nodes due to incomplete synchronization data. Although this solution may cause the consensus to fail to reach an agreement, it will not affect the efficiency of the consensus.

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

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

[0203] In one embodiment, Fig.14 As shown, a blockchain consensus device is provided, including: an acquisition module 1402, a sending module 1404, an update module 1406 and a joining module 1408, wherein:

[0204] The acquisition module 1402 is used to obtain the first block height of the local node and the second block height of the target node in the blockchain.

[0205] The sending module 1404 is used to send a block request for the block to be synchronized to the node that meets the first height condition in the blockchain when the difference between the second block height and the first block height is greater than a preset threshold.

[0206] The update module 1406 is used to verify the block header in the response message when receiving the response message for the block request, and when the verification passes, store the block including the block header in the local ledger and update the first block height of the local node.

[0207] The adding module 1408 is used to add the updated first block height to the blockchain consensus process when the updated first block height is consistent with the second block height.

[0208] In one embodiment, the acquisition module is also used to acquire the first block height of the local node in the blockchain; the sending module is also used to send a message request for acquiring the node block height to other nodes in the blockchain; the acquisition module is also used to acquire the node block height in each response message when receiving each response message for the message request; the device also includes: a determination module, which is used to determine the second block height of the target node from each of the node block heights according to a preset security screening condition.

[0209] In one embodiment, the determination module is also used to determine the number of trusted nodes according to the node fault tolerance condition; the device also includes: a selection module, which is used to select the node whose node block height meets the second height condition among the other nodes according to the number of trusted nodes as a trusted node; the determination module is also used to determine the node block height of any node among the trusted nodes as the second block height of the target node when the node block heights of each node in the trusted nodes are the same; the selection module is also used to select the node block height that meets the third height condition among the node block heights of each node in the trusted nodes as the second block height of the target node when the node block heights of each node in the trusted nodes are different.

[0210] In one embodiment, the device further includes: a comparison module, which is used to compare the first block height with each of the node block heights to obtain a comparison result when the difference between the second block height and the first block height is greater than a preset threshold; the sending module is also used to send a block request for the block to be synchronized to the node corresponding to the node block height when the comparison result indicates that the first block height is less than the node block height.

[0211] In one embodiment, the acquisition module is further used to acquire a transaction set field of a first value and a push transaction field of a second value; the sending module is further used to send a block request containing the transaction set field and the push transaction field to a node in the blockchain that meets the first height condition, so that the node returns a response message that does not contain a transaction set based on the transaction set field, and automatically pushes a transaction task for the block to be synchronized based on the push transaction field.

[0212] In one embodiment, the acquisition module is further used to obtain a transaction set field of the second value; the sending module is further used to send a block request containing the transaction set field to a node in the blockchain that meets the first height condition, so that the node returns a response message containing a transaction set based on the transaction set field.

[0213] In one embodiment, the determination module is also used to determine the block height of the block to be consensus based on the first block height when the difference between the second block height and the first block height is zero; the device also includes: an encapsulation module, which is used to obtain a transaction task from the transaction pool when the block height of the block to be consensus meets the block generation condition, and encapsulate the transaction task into a proposal message of the block to be consensus; a broadcast module, which is used to broadcast the proposal message to other nodes in the blockchain, so that the other nodes can reach a consensus on the block to be consensus based on the transaction task.

[0214] In one embodiment, the device further includes: a verification module, which is used to verify the proposal message when the block height of the block to be agreed upon does not meet the block generation condition and the proposal message for the block to be agreed upon sent by the master node is received; an execution module, which is used to execute the transaction task in the proposal message when the verification is passed and obtain the execution result of the transaction task; the broadcast module is also used to generate an affirmative vote or a negative vote when the execution result is inconsistent with the target execution result carried in the proposal message, and broadcast the affirmative vote or the negative vote to other nodes in the blockchain.

[0215] In one embodiment, the sending module is also used to send a block request for obtaining a transaction set to other nodes in the blockchain when the difference between the second block height and the first block height is not greater than a preset threshold; the verification module is also used to verify the block header and transaction set in the response message containing the transaction set when receiving a response message containing the transaction set returned in response to the block request containing the transaction set; the device also includes: a storage module, which is used to store the block header and the transaction set in a local ledger when the verification is passed, and the update module is also used to update the first block height of the local node.

[0216] In one embodiment, the verification module is also used to verify the legitimacy of the block hash value of the block header in the response message; when the legitimacy verification of the block hash value passes, the node signature of the block to be synchronized is verified; the determination module is also used to obtain the transaction identification list in the response message and determine the hash value of the transaction identification list when the verification of the node signature passes; the device also includes: a deletion module, which is used to delete the transaction set containing the transaction identification list in the local transaction pool when the hash value is consistent with the hash value in the response message, and the update module is also used to update the transaction tasks in the local transaction pool; a discard module is used to discard the response message when the hash value is inconsistent with the hash value in the response message.

[0217] In one embodiment, the determination module is also used to determine the block height of the block to be agreed upon based on the updated first block height when the updated first block height is consistent with the second block height; the encapsulation module is also used to obtain the transaction task from the transaction pool when the block height of the block to be agreed upon meets the block generation condition, and encapsulate the transaction task into a proposal message of the block to be agreed upon; the broadcast module is also used to broadcast the proposal message to other nodes in the blockchain so that the other nodes reach a consensus on the block to be agreed upon based on the transaction task; the device also includes: a consensus module, which is used to wait for the master node in the blockchain to send the proposal message for the block to be agreed upon when the block height of the block to be agreed upon does not meet the block generation condition, and reach a consensus on the block to be agreed upon based on the transaction task in the proposal message.

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

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

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

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

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

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

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

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

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

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

Claims

1. A blockchain consensus method, characterized in that: The method comprises: Get the first block height of the local node and the second block height of the target node in the blockchain; When the difference between the second block height and the first block height is greater than a preset threshold, sending a block request for the block to be synchronized to the node that meets the first height condition in the blockchain; When receiving a response message for the block request, verifying the block header in the response message, and when the verification passes, storing the block containing the block header in the local ledger, and updating the first block height of the local node; When the updated first block height is consistent with the second block height, it is added to the blockchain consensus process.

2. The method according to claim 1, characterized in that The obtaining of the first block height of the local node and the second block height of the target node in the blockchain includes: Get the first block height of the local node in the blockchain; Sending a message request for obtaining the node block height to other nodes in the blockchain; When receiving each response message for the message request, obtaining the node block height in each response message; According to the preset security screening condition, the second block height of the target node is determined from the block heights of each of the nodes.

3. The method according to claim 2, characterized in that The determining the second block height of the target node from the block heights of each node according to the preset security screening condition includes: Determine the number of trusted nodes based on node fault tolerance conditions; Among the other nodes, the node whose node block height meets the second height condition is selected as a trusted node according to the trusted number of nodes; When the node block heights of the nodes in the trusted nodes are the same, the node block height of any node in the trusted nodes is determined as the second block height of the target node; When the node block heights of each node in the trusted nodes are different, among the node block heights of each node in the trusted nodes, a node block height that satisfies a third height condition is selected as the second block height of the target node.

4. The method according to claim 2, characterized in that: When the difference between the second block height and the first block height is greater than a preset threshold, sending a block request for the block to be agreed upon to a node in the blockchain that meets the first height condition includes: When the difference between the second block height and the first block height is greater than a preset threshold, comparing the first block height with each of the node block heights to obtain a comparison result; When the comparison result indicates that the first block height is less than the node block height, a block request for the block to be synchronized is sent to the node corresponding to the node block height.

5. The method according to claim 1, characterized in that The method further comprises: Get the transaction collection field of the first value and the push transaction field of the second value; The sending a block request for a block to be synchronized to a node in the blockchain that meets the first height condition includes: Sending a block request including the transaction set field and the pushed transaction field to a node in the blockchain that meets the first height condition, so that the node returns a response message that does not include a transaction set based on the transaction set field, and automatically pushes a transaction task for the block to be synchronized based on the pushed transaction field.

6. The method according to claim 5, characterized in that After sending the block request including the obtain transaction set field and the push transaction field to the node that meets the first height condition in the blockchain, the method further includes: Get the transaction collection field of the second value; Sending a block request including the transaction set field to a node in the blockchain that meets the first height condition, so that the node returns a response message including the transaction set based on the transaction set field.

7. The method according to claim 1, characterized in that After obtaining the first block height of the local node and the second block height of the target node in the blockchain, the method further includes: When the difference between the second block height and the first block height is zero, determining the block height of the block to be agreed upon based on the first block height; When the block height of the block to be agreed upon meets the block generation condition, a transaction task is obtained from the transaction pool, and the transaction task is encapsulated into a proposal message of the block to be agreed upon; The proposal message is broadcast to other nodes in the blockchain so that the other nodes can reach a consensus on the block to be agreed upon based on the transaction task.

8. The method according to claim 7, characterized in that After determining the block height of the block to be agreed upon based on the first block height, the method further includes: When the block height of the block to be agreed upon does not meet the block generation condition and the proposal message for the block to be agreed upon is received from the master node, the proposal message is verified, and when the verification passes, the transaction task in the proposal message is executed to obtain the execution result of the transaction task; When the execution result is inconsistent with the target execution result carried in the proposal message, an affirmative vote or a negative vote is generated, and the affirmative vote or the negative vote is broadcast to other nodes in the blockchain.

9. The method according to claim 1, characterized in that: After obtaining the first block height of the local node and the second block height of the target node in the blockchain, the method further includes: When the difference between the second block height and the first block height is not greater than a preset threshold, sending a block request for obtaining a transaction set to other nodes in the blockchain; When receiving a response message containing a transaction set returned in response to the block request containing the transaction set, verifying the block header and the transaction set in the response message containing the transaction set; When the verification is passed, the block header and the transaction set are stored in the local ledger, and the first block height of the local node is updated.

10. The method according to claim 1, characterized in that The verifying the block header in the response message includes: Verify the legitimacy of the block hash value of the block header in the response message; The method further comprises: when the legitimacy verification of the block hash value passes, verifying the node signature of the block to be synchronized; When the verification of the node signature passes, obtaining the transaction identification list in the response message, and determining the hash value of the transaction identification list; When the hash value is consistent with the hash value in the response message, the transaction set including the transaction identifier list in the local transaction pool is deleted, and the transaction task in the local transaction pool is updated; When the hash value is inconsistent with the hash value in the response message, the response message is discarded.

11. The method according to any one of claims 1 to 10, characterized in that: The process of joining the blockchain consensus includes: When the updated first block height is consistent with the second block height, determining the block height of the block to be agreed upon based on the updated first block height; When the block height of the block to be agreed upon meets the block generation condition, a transaction task is obtained from the transaction pool, and the transaction task is encapsulated into a proposal message of the block to be agreed upon; the proposal message is broadcast to other nodes in the blockchain, so that the other nodes reach a consensus on the block to be agreed upon based on the transaction task; When the block height of the block to be agreed upon does not meet the block generation condition, the master node in the blockchain is waited for to send the proposal message for the block to be agreed upon, and consensus is reached on the block to be agreed upon based on the transaction task in the proposal message.

12. A blockchain consensus device, characterized in that: The device comprises: An acquisition module, used to acquire the first block height of the local node and the second block height of the target node in the blockchain; A sending module, configured to send a block request for a block to be synchronized to a node in the blockchain that meets a first height condition when the difference between the second block height and the first block height is greater than a preset threshold; An update module, configured to verify the block header in the response message when receiving a response message for the block request, and when the verification passes, store the block containing the block header in a local ledger, and update the first block height of the local node; A joining module is used to join the blockchain consensus process when the updated first block height is consistent with the second block height.

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