Node consensus method, device, equipment and medium in blockchain system

Abstract

The present application relates to a node consensus method, apparatus, device and medium in a blockchain system. In this method, each node locally stores a node transaction linked list corresponding to each node. Any batch package in any node transaction linked list is obtained by packaging multiple transactions in a transaction pool by the node corresponding to the node transaction linked list after the voting information of each node on the previous batch package meets the preset requirements. This allows the consensus master node to accurately determine the last batch package whose voting information meets the preset requirements from the locally stored node transaction linked lists as the target batch package, and only packages the target batch package of each node transaction linked list into a consensus message package, without having to package all transactions, thereby improving packaging efficiency. The consensus message package is broadcasted, so that the consensus sub-nodes in the blockchain system can reach consensus on the target batch package of each node transaction linked list contained in the consensus message package, without having to reach consensus on each transaction, thereby further improving the node consensus efficiency in the blockchain system.

Description

Technical Field

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

[0002] Each node in a blockchain network uses an algorithm to confirm a batch of transactions and ensure that all nodes have consistent confirmation results for this batch of data. This algorithm is the blockchain's consensus algorithm. Blockchain nodes include: A consensus leader (Leader), which packages multiple transactions from the transaction pool into blocks and broadcasts them to every remaining node in the blockchain. Each consensus round has only one leader. To prevent the leader from forging blocks, the leader switches after each round. Each node in the blockchain, excluding the leader, is a replica node, responsible for verifying and voting on the blocks broadcast by the leader and broadcasting the voting information. If multiple nodes receive multiple votes within a preset time, consensus is reached on the transactions within the block. Each consensus round has multiple replica nodes, and each replica node undergoes a similar process.

[0003] If a consensus master node fails or a network timeout occurs—meaning that multiple nodes fail to receive multiple votes within a preset timeframe—a view switch occurs. This process continues until all nodes in the blockchain reach a consistent view. The switch succeeds, and a new consensus master node is elected based on the new view. After the view switch, transactions in the previously packaged block are released back into the transaction pool, and the new consensus master node re-executes the steps required to retrieve the transaction-packaged block from the transaction pool. Because only the consensus master node can package blocks, and each view switch requires repackaging, node consensus in the blockchain system is inefficient and time-consuming.

[0004] Therefore, how to improve the efficiency of node consensus in the blockchain system has become a technical problem that needs to be solved urgently. Summary of the Invention

[0005] The present application provides a node consensus method, apparatus, device, and medium in a blockchain system, which are used to improve the efficiency of node consensus in the blockchain system.

[0006] In a first aspect, an embodiment of the present application provides a node consensus method in a blockchain system, the method comprising:

[0007] The consensus master node determines the last batch package whose voting information meets the preset requirements from the locally stored transaction chain tables of each node as the target batch package, and packages the target batch package into a consensus message package. Each node transaction chain table corresponds to a node in the blockchain system, and each node locally stores the transaction chain table of each node. Any batch package in any node transaction chain table is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction chain table after the voting information of each node for the previous batch package meets the preset requirements.

[0008] The consensus master node broadcasts the consensus message package so that the consensus slave nodes in the blockchain system reach a consensus on the consensus message package.

[0009] In one possible implementation, the method further includes:

[0010] If a view switch occurs during the consensus process, the new consensus master node re-executes the step of determining that the last batch package whose voting information meets the preset requirements is the target batch package.

[0011] In one possible implementation, any batch package in any node's transaction linked list is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction linked list after the voting information of each node on the previous batch package meets the preset requirements, including:

[0012] After obtaining voting information from each node on the first batch and verifying that it meets the preset requirements, the first node packages multiple transactions in the transaction pool into a second batch and saves the second batch to the local first node transaction list; the first batch is the previous batch of the second batch in the first node transaction list;

[0013] The first node broadcasts the second batch package, so that the second node verifies the second batch package. After the verification is successful, the second node saves the second batch package to the local transaction list of the first node and sends voting information for the second batch package to the first node.

[0014] The first node receives and saves the voting information of the second node on the second batch package.

[0015] In one possible implementation, the batch package includes the location information of the batch package in the transaction list of the node to which it belongs, the voting information of the previous batch package in the transaction list of the node to which it belongs, the hash value of the batch package, and the node signature of the node to which it belongs;

[0016] The second node verifies the second batch packet, including:

[0017] The second node determines, based on the hash value and the node signature of the batch package contained in the second batch package, a transaction linked list of the node to which the second batch package belongs;

[0018] If the node transaction linked list to which the second batch packet belongs is the first node transaction linked list, the second node determines whether the position information of the last batch packet in the first node transaction linked list stored locally by the second node is the previous position of the position information contained in the second batch packet;

[0019] If so, determining whether the number of votes for the first batch package included in the voting information of the second batch package meets the preset requirement;

[0020] If yes, the verification is successful; if any of the above results is no, the verification is unsuccessful.

[0021] In one possible implementation, the batch package further includes a historical hash value of the previous batch package in the transaction list of the node to which it belongs, and transaction information of multiple transactions included in the batch package;

[0022] The process of verifying the second batch package further includes at least one of the following:

[0023] Determine whether the historical hash value included in the second batch package is consistent with the hash value of the last batch package in the transaction chain list of the first node stored locally by the second node;

[0024] Determine whether a hash value of the first batch package is accurate based on transaction information of multiple transactions included in the first batch package.

[0025] In a possible implementation, if the second node fails to verify the second batch packet, the method further includes:

[0026] The second node does not save the second batch package in the first node transaction chain list, and does not send voting information for the second batch package to the first node.

[0027] In one possible implementation, the process of consensus secondary nodes in the blockchain system reaching consensus on the consensus message package includes:

[0028] Any consensus secondary node in the blockchain system determines whether the node that sent the consensus message packet is the current consensus primary node; if so, for each target batch packet in the consensus message packet, determines whether the locally stored transaction linked list of each node contains the target batch packet;

[0029] If included, verification passes.

[0030] In a possible implementation, if it is determined that the locally stored transaction linked list of each node does not contain the target batch package, the method further includes:

[0031] Send a request message to the consensus master node, where the request message is used to obtain the missing batch package;

[0032] Receive the missing batch package sent by the consensus master node;

[0033] Determine whether the voting information of the previous batch package contained in any of the missing batch packages received meets the preset requirements.

[0034] In a second aspect, an embodiment of the present application provides a node consensus device in a blockchain system, the device being located at any node in the blockchain system, the device comprising:

[0035] A packaging module is used to determine the last batch package whose voting information meets the preset requirements from the locally stored transaction chain tables of each node as the target batch package, and package the target batch package into a consensus message package; wherein, each node transaction chain table corresponds to a node in the blockchain system, and each node locally stores the transaction chain table of each node; any batch package in any node transaction chain table is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction chain table after the voting information of each node for the previous batch package meets the preset requirements;

[0036] The consensus module is used to broadcast the consensus message package so that the consensus sub-nodes in the blockchain system can reach a consensus on the consensus message package.

[0037] In a possible implementation, the consensus module is further configured to re-execute the step of determining the last batch package whose voting information meets preset requirements as the target batch package if a view switch occurs during the consensus process.

[0038] In one possible implementation, the packaging module is specifically configured to, after obtaining voting information of each node on the first batch package that meets the preset requirements, package multiple transactions in the transaction pool into a second batch package, and save the second batch package to a local first-node transaction linked list; the first batch package is the previous batch package of the second batch package in the first-node transaction linked list; broadcast the second batch package so that the second node verifies the second batch package, and after the second node passes the verification, save the second batch package to the local first-node transaction linked list and send voting information on the second batch package to the first node; and receive and save the voting information of the second node on the second batch package.

[0039] In one possible implementation, the batch package includes the location information of the batch package in the transaction list of the node to which it belongs, the voting information of the previous batch package in the transaction list of the node to which it belongs, the hash value of the batch package, and the node signature of the node to which it belongs;

[0040] The packaging module is specifically configured to determine, based on the hash value and node signature of the batch package contained in the second batch package, the node transaction linked list to which the second batch package belongs; if the node transaction linked list to which the second batch package belongs is the first node transaction linked list, the second node determining whether the position information of the last batch package in the first node transaction linked list locally stored by the second node is the previous digit of the position information contained in the second batch package; if so, determining whether the number of votes for the first batch package contained in the voting information of the second batch package meets a preset requirement; if so, verification is successful; if any of the above results is no, verification is unsuccessful.

[0041] In one possible implementation, the batch package also includes a historical hash value of a previous batch package in a transaction list of the node to which it belongs and transaction information of multiple transactions included in the batch package. The packaging module is specifically used to verify the second batch package, and the process further includes at least one of the following: determining whether the historical hash value included in the second batch package is consistent with the hash value of the last batch package in the transaction list of the first node stored locally by the second node; and determining whether the hash value of the first batch package is accurate based on the transaction information of multiple transactions included in the first batch package.

[0042] In a possible implementation, the packaging module is further configured to not save the second batch package in the first node transaction linked list, and not send voting information for the second batch package to the first node.

[0043] In one possible implementation, the consensus module is specifically configured to determine whether the node that sends the consensus message packet is the current consensus master node; if so, for each target batch packet in the consensus message packet, determine whether the locally stored transaction list of each node contains the target batch packet; if so, the verification is successful.

[0044] In one possible implementation, the consensus module is further configured to send a request message to the consensus master node, wherein the request message is used to obtain the missing batch packages; receive the missing batch packages sent by the consensus master node; and determine whether the voting information of the previous batch package contained in any received missing batch package meets preset requirements.

[0045] In a third aspect, an embodiment of the present application further provides an electronic device, which includes at least a processor and a memory, and the processor is used to implement the steps of any method described in the first aspect when executing a computer program stored in the memory.

[0046] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium storing a computer program, which implements the steps of any method described in the first aspect when executed by a processor.

[0047] In a fifth aspect, an embodiment of the present application provides a computer program product, which includes: a computer program code, which, when executed on a computer, enables the computer to execute the steps of any method described in the first aspect.

[0048] In an embodiment of the present application, each node locally stores a node transaction linked list corresponding to each node. Any batch package in any node transaction linked list is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction linked list after the voting information of each node for the previous batch package meets the preset requirements, so that the consensus master node can accurately determine the last batch package whose voting information meets the preset requirements from the locally stored node transaction linked list as the target batch package, and only package the target batch package of each node transaction linked list into a consensus message package, without having to package all transactions, thereby improving the packaging efficiency, and broadcasting the consensus message package, so that the consensus sub-nodes in the blockchain system can reach a consensus on the target batch package of each node transaction linked list contained in the consensus message package, without having to reach a consensus on each transaction, thereby further improving the node consensus efficiency in the blockchain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the implementation methods in the embodiments of the present application or related technologies, the following is a brief introduction to the drawings required for use in the embodiments or related technology descriptions. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0050] Figure 1 A schematic diagram of a node consensus process in a blockchain system provided for some embodiments of the present application;

[0051] Figure 2 A schematic diagram of a node transaction chain provided for some embodiments of the present application;

[0052] Figure 3 A schematic diagram of broadcast voting for a batch package provided in some embodiments of the present application;

[0053] Figure 4 A schematic diagram of a consensus master node transaction pool provided for some embodiments of the present application;

[0054] Figure 5 A schematic diagram of the three-stage consensus process provided for some embodiments of the present application;

[0055] Figure 6 A schematic diagram of blockchain system view switching provided for some embodiments of the present application;

[0056] Figure 7 A schematic diagram of view switching packaging provided for some embodiments of the present application;

[0057] Figure 8 A schematic diagram of the data structure of a batch package provided for some embodiments of the present application;

[0058] Figure 9 A schematic diagram of a node consensus process in a blockchain system provided for some embodiments of the present application;

[0059] Figure 10 A schematic structural diagram of an electronic device provided for some embodiments of the present application. DETAILED DESCRIPTION

[0060] To make the purpose, technical solutions, and advantages of this application more clear, this application will be further described in detail below with reference to the accompanying drawings. Obviously, the embodiments described in this application are only some of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0061] It should be noted that the brief descriptions of terms in this application are only for the purpose of facilitating the understanding of the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise specified, these terms should be understood according to their ordinary and usual meanings.

[0062] In the specification and claims of this application and the accompanying drawings, the terms "first," "second," "third," etc. are used to distinguish similar or similar objects or entities, and are not necessarily intended to limit a particular order or sequence, unless otherwise noted. It should be understood that the terms used in this manner are interchangeable under appropriate circumstances.

[0063] The terms "comprise," "include," and "have," and any variations thereof, are intended to cover but not exclude inclusion; for example, a product or device comprising a list of components is not necessarily limited to all the components expressly listed but may include other components not expressly listed or inherent to such product or device.

[0064] The term "module" refers to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functionality associated with that element.

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

[0066] Before introducing the node consensus method in the blockchain system provided by the embodiment of the present application, in order to facilitate understanding, the professional terms and technical background of the embodiment of the present application are first introduced.

[0067] Consensus algorithm: Each node in the blockchain peer-to-peer network uses an algorithm to confirm a batch of transactions and ensure that all nodes have consistent confirmation results for this batch of data. This algorithm is the blockchain consensus algorithm.

[0068] Byzantine Fault Tolerance (BFT): It is used to solve the problem of different computers communicating and exchanging information in distributed computing, reaching a consensus and acting according to the same set of collaborative strategies.

[0069] Each node in a blockchain network uses an algorithm to confirm a batch of transactions and ensure that all nodes have consistent confirmation results for this batch of data. This algorithm is the blockchain's consensus algorithm. Blockchain nodes include: A consensus master node, which packages multiple transactions from the transaction pool into blocks and broadcasts them to every remaining node in the blockchain. Each consensus round has only one consensus master node. To prevent the consensus master node from forging blocks, the consensus master node switches after each round. Each node in the blockchain, excluding the consensus master node, is a replica node, responsible for verifying and voting on the blocks broadcast by the consensus master node and broadcasting the voting information. If multiple nodes receive multiple votes within a preset time, consensus is reached on the transactions within the block. Each consensus round has multiple replica nodes, and each replica node undergoes a similar process.

[0070] If a consensus master node fails or a network timeout occurs—meaning that multiple nodes fail to receive multiple votes within a preset timeframe—a view switch occurs. This process continues until all nodes in the blockchain reach a consistent view. The switch succeeds, and a new consensus master node is elected based on the new view. After the view switch, transactions in the previously packaged block are released back into the transaction pool, and the new consensus master node re-executes the steps required to retrieve the transaction-packaged block from the transaction pool. Because only the consensus master node can package blocks, and each view switch requires repackaging, node consensus in the blockchain system is inefficient and time-consuming.

[0071] Based on this, in order to improve the efficiency of node consensus in a blockchain system, embodiments of the present application provide a node consensus method, apparatus, device, medium, and computer program product in a blockchain system. In this method, a consensus master node determines the last batch package whose voting information meets preset requirements from the locally stored transaction chain tables of each node as the target batch package, and packages the target batch package into a consensus message package; wherein each node transaction chain table corresponds to a node in the blockchain system, and each node locally stores each node transaction chain table; any batch package in any node transaction chain table is obtained by packaging multiple transactions in the transaction pool corresponding to the node transaction chain table after each node's voting information for the previous batch package meets the preset requirements; the consensus master node broadcasts the consensus message package so that the consensus slave nodes in the blockchain system reach consensus on the consensus message package.

[0072] Example 1:

[0073] Figure 1 A schematic diagram of a node consensus process in a blockchain system provided for some embodiments of this application. Figure 1 As shown, the process includes the following steps:

[0074] S101: The consensus master node determines the last batch package whose voting information meets the preset requirements from the locally stored transaction chain lists of each node as the target batch package, and packages the target batch package into a consensus message package; wherein, each node transaction chain list corresponds to a node in the blockchain system, and each node locally stores the transaction chain list of each node; any batch package in any node transaction chain list is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction chain list after the voting information of each node for the previous batch package meets the preset requirements.

[0075] The node consensus method in the blockchain system in the embodiment of the present application is applied to electronic devices located in the same blockchain system, where the electronic devices can be servers, PCs and other devices.

[0076] To improve the efficiency of node consensus in a blockchain system, in an embodiment of the present application, the transaction pool of each node in the blockchain system is modified from a list-like structure to a chain-like block structure, hereinafter referred to as a node transaction list. Each node transaction list corresponds to a node in the blockchain system, and each node's local transaction pool stores each node's transaction list. Each node transaction list contains multiple batches. Each batch in any node transaction list is obtained by packaging multiple transactions in the transaction pool of the node corresponding to the node transaction list, based on the voting information of each node for the previous batch meeting a preset requirement. The preset requirement can be that the number of votes is greater than a preset value. For example, if there are 3f nodes in the blockchain system, the preset value is f+1.

[0077] Specifically, Figure 2 A node transaction chain diagram is provided for some embodiments of the present application. Figure 2 As shown in the figure, the blockchain system contains four nodes. The first node (Replica1, R1) packages multiple transactions in the transaction pool according to the preset time interval to obtain the first batch package p1, that is, Figure 2 In r1-p1, p1 is saved to the first node transaction list (Replica1 batch list), and p1 is broadcast to the other three nodes in the blockchain system. Specifically, Figure 3 A schematic diagram of a broadcast voting of a batch package is provided for some embodiments of the present application. Figure 3 As shown, Replica1 broadcasts a message package containing p1 (Propose p1 batch transactions) to the second node (Replica2, R2), the third node (Replica3, R3) and the fourth node (Replica4, R4) respectively. The second node receives p1 and verifies the information contained in p1. If it passes the verification, p1 is saved to the local Replica1batch list of the second node, and a vote for p1 (Vote of p1) is sent to the first node. The processing of the third and fourth nodes can refer to the second node and will not be repeated here. After the first node obtains the votes of each node on p1, if it determines that the voting information meets the preset requirements, for example, the number of votes is greater than 2, and the identification information of the voting nodes contained in the voting information includes the identification information of the first node, then the multiple transactions in the transaction pool are packaged into the second batch package, i.e. Figure 2The first node stores r1-p2 in the first node's local transaction list after p1. The proof of p1 votes of each node can be stored in p2. The proof of p1 votes includes the identification information of each voting node and the total number of votes.

[0078] Since each node locally stores its own transaction list, and each batch in the transaction list is generated by packaging multiple transactions in the transaction pool by the node corresponding to the node's transaction list after each node's voting information for the previous batch meets the preset requirements, the consensus packaging module of the consensus master node can determine that the last Proof of Last Votes (PoV) batch in each transaction list whose voting information meets the preset requirements is the target batch, and each batch before the target batch is a batch whose voting information meets the preset requirements.

[0079] Specifically, the last batch package whose voting information in each transaction chain list meets the preset requirements can be determined as the target batch package based on the voting information of the previous batch package stored in each batch package in the transaction chain list of each node. Figure 4 A schematic diagram of a consensus master node transaction pool provided for some embodiments of this application. Figure 4 As shown, the R1 node is the consensus master node. The R1 consensus packaging module determines the last batch package in each node transaction list whose voting information meets the preset requirements as the target batch package based on the locally stored transaction list of each node. For example, the last batch package of the R1 node transaction list is r1-p4. Since there is no batch package after r1-p4, it is impossible to determine whether the voting information of r1-p4 meets the preset requirements. However, based on the voting information of each node on the previous batch package r1-p3 stored in r1-p4, it can be determined that the voting information of r1-p3 meets the preset requirements. Then the target batch package of the R1 node transaction list is determined to be r1-p3. Similarly, the target batch package of the R2 node transaction list is r2-p3, the target batch package of the R3 node transaction list is r3-p2, and the target batch package of the R4 node transaction list is r4-p1. The target batch packages of each node transaction list, namely r1-p3, r2-p3, r3-p2 and r4-p1, are packaged into a consensus message package (New Proposal).

[0080] During each round of consensus, any node in the blockchain system is determined as the consensus master node, and the other nodes are consensus slave nodes. The node consensus process generally includes four stages: the block packaging stage, the pre-prepare stage, the prepare stage, and the commit stage. In the block packaging stage of the node consensus process in the embodiment of the present application, the consensus master node can use the above-mentioned method to determine the target batch package in the transaction list of each node, and package the target batch package in the transaction list of each node into a consensus message package, without packaging all the batch packages, further improving the packaging efficiency and consensus efficiency.

[0081] S102: The consensus master node broadcasts the consensus message package, so that the consensus slave nodes in the blockchain system reach a consensus on the consensus message package.

[0082] After the consensus master node broadcasts the consensus message package, the consensus sub-nodes in the blockchain system reach a consensus on the target batch package in each transaction list in the consensus message package.

[0083] Specifically, Figure 5 Schematic diagram of the three-stage consensus process provided for some embodiments of this application. Figure 5 As shown in the figure, the three-phase consensus includes the Pre-Prepare phase, the Prepare phase, and the Commit phase.

[0084] During the Pre-Prepare phase of the consensus process, the consensus master node, Replica 1, broadcasts a consensus message package, enabling all consensus replicas within the blockchain system to reach consensus on the target batch packages within each transaction list within the consensus message package. During the Prepare phase, the consensus replicas verify the target batch packages within each transaction list within the consensus message package. This involves comparing the target batch packages within each transaction list within the consensus message package with the batch packages contained in each node's locally stored transaction list. Specifically, for any target batch package, the node to which the target batch package belongs and its corresponding node transaction list can be determined based on the node signature contained within the target batch package. Furthermore, the node's locally stored transaction list can be used to determine whether the target batch package exists within the batch packages contained within that node's locally stored transaction list. If so, a match is determined. If it is determined that each target batch package within the consensus message package matches a batch package within the locally stored node transaction list, the signature information for the consensus message package is verified and broadcast. During the Commit phase, if any node in the blockchain system receives more than a preset number of signatures for the consensus message within a preset time, it is determined that the transactions in the target batch of each node's transaction list and the batches preceding each target batch have reached consensus. The preset number can be determined based on the number of nodes in the blockchain system. For example, if the blockchain system contains 3f nodes, the preset number is 2f + 1.

[0085] In an embodiment of the present application, each node locally stores a node transaction linked list corresponding to each node. Any batch package in any node transaction linked list is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction linked list after the voting information of each node for the previous batch package meets the preset requirements. Therefore, the consensus master node can quickly and accurately determine the last batch package whose voting information meets the preset requirements from the locally stored node transaction linked list as the target batch package, and only package the target batch package of each node transaction linked list into a consensus message package. There is no need to package all transactions, which improves the packaging efficiency, and broadcasts the consensus message package, so that the consensus sub-nodes in the blockchain system can reach a consensus on the target batch package of each node transaction linked list contained in the consensus message package, without having to reach a consensus on each transaction, thereby further improving the node consensus efficiency in the blockchain system.

[0086] Example 2:

[0087] In order to further improve the node consensus efficiency in the blockchain system, based on the above embodiment, in the embodiment of the present application, the method further includes:

[0088] If a view change occurs during the consensus process, the new consensus master node re-executes the step of determining that the last batch package whose voting information meets the preset requirements is the target batch package.

[0089] In related technologies, after a view switch, the new consensus master node abandons the previously packaged block and re-enters the block packaging phase. Between the repackaging phase and the final consensus, no transactions are ultimately uploaded to the blockchain, increasing transaction latency. Furthermore, when verifying the block packaged by the new consensus master node, the consensus replica node must verify every transaction in the block, which takes a long time. If the transaction pool has a transaction count of TN, then the computational complexity required for verification is O(TN).

[0090] In an embodiment of the present application, if a view switch occurs during the consensus process, since each node in the blockchain system locally stores a transaction list of each node, the new consensus node can directly enter the Pre-prepare stage and re-execute the last batch package whose voting information meets the preset requirements as the target batch package. There is no need to repeatedly execute the block packaging stage, that is, there is no need to re-package transactions, and there is no need for replica nodes to re-verify the batch package. The verification calculation complexity during consensus can be reduced from a positive correlation with the number of transactions to a positive correlation with the number of nodes, where the number of transactions is much larger than the number of nodes, greatly improving the consensus efficiency.

[0091] Specifically, Figure 6 A schematic diagram of a blockchain system view switching provided for some embodiments of this application. Figure 6 As shown in the figure, when nodes R1 to R3 find that the consensus master node R4 has timed out in view 0, that is, view=0, they will enter the view change phase, and each node will actively broadcast the view change message packet of view+1. After collecting more than the preset number of viewchange message packets of view+1, they will enter the new view (new view) phase and determine the new consensus master node R1. The new consensus master node R1 will broadcast the message packet, and at this time all nodes will switch their views to view Figure 1 That is, view = 1. For example, a blockchain system contains 3f nodes, with a preset number of 2f + 1. During the Pre-Prepare phase with view = 1, node R1 will re-execute the steps to determine the last batch whose voting information meets the preset requirements as the target batch, accurately determining the target batch for each node's transaction list. Figure 7 A schematic diagram of view switching packaging is provided for some embodiments of the present application. Figure 7As shown in the figure, when view is 0, the original consensus masternode R4 packages B1. The new consensus masternode R1 packages the target batch of each node's transaction list into B2. The transactions in B2 include the transactions in B1 packaged by the original consensus masternode R4. This eliminates the need to release the transactions in B1 to the transaction pool for repackaging. This greatly accelerates the consensus process and effectively reduces overall transaction latency. The optimized transaction pool and packaging method can effectively reduce transaction latency during consensus view switching, thereby improving the overall performance of the blockchain system.

[0092] In an embodiment of the present application, if a view switch occurs during the consensus process, the new consensus master node only needs to re-execute the step of determining that the last batch package whose voting information meets the preset requirements is the target batch package. There is no need to re-execute the block packaging stage, nor is there any need to broadcast the batch package so that each node can verify the batch package, which greatly improves the node consensus efficiency in the blockchain system.

[0093] Example 3:

[0094] In order to further improve the node consensus efficiency in the blockchain system, based on the above embodiments, in the embodiment of the present application, any batch package in the transaction chain list of any node is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction chain list after the voting information of each node on the previous batch package meets the preset requirements, including:

[0095] After obtaining voting information from each node on the first batch and verifying that it meets the preset requirements, the first node packages multiple transactions in the transaction pool into a second batch and saves the second batch to the local first node transaction list; the first batch is the previous batch of the second batch in the first node transaction list;

[0096] The first node broadcasts the second batch package, so that the second node verifies the second batch package. After the verification is successful, the second node saves the second batch package to the local transaction list of the first node and sends voting information for the second batch package to the first node.

[0097] The first node receives and saves the voting information of the second node on the second batch package.

[0098] In order to further improve the node consensus efficiency in the blockchain system, any node in the blockchain system, i.e., the first node, after obtaining the voting information of each node on the first batch package that meets the preset requirements, packages multiple transactions in the transaction pool into a second batch package and saves the second batch package to the local first node transaction list; wherein the first batch package is the previous batch package of the second batch package in the first node transaction list; the first node broadcasts the second batch package so that any node among the remaining nodes, i.e., the second node, verifies the second batch package. After the verification is passed, the second node saves the second batch package to the local first node transaction list and sends the voting information for the second batch package to the first node; the first node receives and saves the voting information of the second node on the second batch package.

[0099] Specifically, for example, the blockchain system contains four nodes, namely Replica 1, Replica 2, Replica 3 and Replica 4.

[0100] Replica1 broadcasts a message packet containing the first batch (p1) to Replica2, Replica3, and Replica4. Replica2 receives p1 and verifies the information contained in p1. If verification passes, it saves p1 to Replica2's local Replica1 batch list and sends a vote for p1 (Vote of p1) to Replica1. The processing for Replica3 and Replica4 is similar to that for Replica2 and will not be repeated here. After obtaining each node's vote for p1, if Replica1 determines that the votes meet preset requirements (for example, the total number of votes exceeds 2), it packages multiple transactions from the transaction pool into a second batch (p2) and saves p2 after p1 in Replica1's local Replica1 batch list. p2 can store each node's vote for p1, including the identification information of each voting node and the total number of votes.

[0101] Replica1 continues to broadcast the message packet containing p2 to Replica2, Replica3, and Replica4. Replica2 receives p2 and verifies the information contained in p2. If it passes verification, it saves p2 to Replica1's local batch list and sends a vote for p2 (Vote of p1) to Replica1. The processing of Replica3 and Replica4 is similar to that of Replica2 and will not be repeated here. Replica1 receives and saves each node's vote for p2. Specifically, after obtaining each node's vote for p2, if Replica1 determines that the voting information meets preset requirements, such as the total number of votes exceeding 2, it packages multiple transactions in the transaction pool into a third batch (p3) and saves p3 to Replica1's local batch list after p1. p3 can store each node's vote for p2, including the identification information of each voting node and the total number of votes.

[0102] In an embodiment of the present application, any batch package in the transaction chain list of any node is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the transaction chain list of the node after the voting information of each node on the previous batch package meets the preset requirements, thereby ensuring that the voting information of each batch package stored in the transaction chain list meets the preset requirements. Each node can accurately determine that the last batch package whose voting information meets the preset requirements is the target batch package. Even if the view is switched and a new consensus master node is re-determined, there is no need to re-package, further improving the packaging efficiency.

[0103] Example 4:

[0104] In order to further improve the accuracy and efficiency of node consensus in the blockchain system, based on the above embodiments, in the embodiment of the present application, the batch package contains the position information of the batch package in the transaction list of the node to which it belongs, the voting information of the previous batch package in the transaction list of the node to which it belongs, the hash value of the batch package and the node signature of the node to which it belongs;

[0105] The second node verifies the second batch packet, including:

[0106] The second node determines, based on the hash value and the node signature of the batch package contained in the second batch package, a transaction linked list of the node to which the second batch package belongs;

[0107] If the node transaction linked list to which the second batch packet belongs is the first node transaction linked list, the second node determines whether the position information of the last batch packet in the first node transaction linked list stored locally by the second node is the previous position of the position information contained in the second batch packet;

[0108] If so, determining whether the number of votes for the first batch package included in the voting information of the second batch package meets the preset requirement;

[0109] If yes, the verification is successful; if any of the above results is no, the verification is unsuccessful.

[0110] In order to further improve the accuracy and efficiency of node consensus in the blockchain system, in an embodiment of the present application, the batch package may include the position information (pos) of the batch package in the transaction list of the node to which it belongs, the voting information (proof of votes) of the previous batch package in the transaction list of the node to which it belongs, the hash value (batch hash) of the batch package, and the node signature of the node to which it belongs. Figure 8 A data structure diagram of a batch package provided in some embodiments of the present application. Figure 8 As shown, the information contained in the first batch package r1-p1 of the first node's transaction list may include r1-p1's POS, each node's voting information for the previous batch package p0, proof of p0 votes, and r1-p1's batch hash. It may also include the node signature of the node to which it belongs.

[0111] In one possible implementation, if the first batch package is the first batch package in the first node transaction list in this round of consensus, that is, p0 does not exist in the first node transaction list, then the voting information of each node on the previous batch package contained in the first batch package can be the voting information of the last batch package in the first node transaction list in the previous round of consensus.

[0112] The second node's verification process for the second batch package includes: recovering the public key based on the hash value and node signature contained in the second batch package, determining the node to which the second bath package belongs, and then determining the node transaction linked list corresponding to the node, that is, the node transaction linked list to which the second batch package belongs.

[0113] Since the second batch packet is sent by the first node, if the transaction list of the node to which the second batch packet belongs is determined to be the transaction list of the first node, then the preliminary verification has passed. If the transaction list of the node to which the second batch packet belongs is determined not to be the transaction list of the first node, then the preliminary verification has failed and the second batch packet is likely to be a forged batch packet by a malicious node.

[0114] If the preliminary verification passes, the second node determines whether the position information contained in the last batch packet in the first node's transaction list stored in the local transaction pool is the previous position of the position information contained in the second batch packet. For example, if the position information of the second batch packet is 2, it is determined whether the position information contained in the last batch packet in the first node's transaction list currently stored in the local transaction pool is 1, that is, it is determined whether the current last batch in the first node's transaction list is the first batch packet. If so, it means that the second batch packet is the batch packet located after the first batch packet in the first node's transaction list. If not, for example, if the position information contained in the last batch packet in the first node's transaction list is 0, it means that the first batch packet may not have been received yet. The second batch packet can be cached separately until the first batch packet is received and then verified. For another example, if the position information contained in the last batch packet in the first node's transaction list is 2, it means that the second batch packet failed verification and may be a batch packet forged by a malicious node.

[0115] If the second batch package is the last batch currently saved in the transaction chain list of the first node and is the first batch package, then it is further determined whether the voting information contained in the second batch package for the previous batch package in the transaction chain list of the node to which it belongs meets the preset requirements, that is, whether the number of votes in the voting information for the first batch package contained in the second batch package is greater than the preset value, and whether the identification information of the voting node contained in the voting information contains the identification information of the second node. If the results of the above two determinations are both yes, it means that the verification of the second batch package is passed, and the second batch package can be saved to the next position of the first batch package in the transaction chain list of the first node. If the identification information of the voting node does not contain the identification information of the second node, it means that the second node has not voted for the previous batch package of the second batch package, and it is impossible to save the previous batch package of the second batch package in the local transaction chain list of the first node, which means that the verification of the second batch package has failed. If the number of votes in the voting information is less than or equal to the preset value, it means that the previous batch package of the first batch package is the last batch package in the first node transaction list whose voting information meets the preset requirements. In this case, there is no need to save the second batch package in the first node transaction list, and the second batch package fails verification.

[0116] In an embodiment of the present application, the second node determines whether the transaction list of the node to which the second batch package belongs is the first node that broadcasts the second batch package based on the hash value and node signature contained in the second batch package; if so, it determines whether the position information of the last batch package in the transaction list of the first node stored locally by the second node is the previous digit of the position information contained in the second batch package; if so, it further determines whether the voting information for the previous batch package contained in the second batch package meets the preset requirements. If so, it determines that the verification of the second batch package is passed, thereby ensuring the accuracy of the batch packages in the locally stored transaction lists of each node, and further improving the accuracy and efficiency of the node consensus.

[0117] Example 5:

[0118] In order to further improve the accuracy and efficiency of node consensus, based on the above embodiments, in the embodiment of the present application, the batch package also includes the historical hash value of the previous batch package in the transaction list of the node to which it belongs, and the transaction information of multiple transactions contained in the batch package;

[0119] The process of verifying the second batch package further includes at least one of the following:

[0120] Determine whether the historical hash value included in the second batch package is consistent with the hash value of the last batch package in the transaction chain list of the first node stored locally by the second node;

[0121] Determine whether a hash value of the first batch package is accurate based on transaction information of multiple transactions included in the first batch package.

[0122] In order to further improve the accuracy and efficiency of node consensus, the batch package can also include the historical hash value of the previous batch package in the transaction list of the node to which it belongs and the transaction information of multiple transactions contained in the batch package.

[0123] Specifically, as mentioned above Figure 8 As shown, r1-p1 may also include the historical hash value of the previous batch package (prevbatch hash) and the transaction information of multiple transactions packaged in the batch package (batch transactions). In one possible implementation, if r1-p1 is the first batch package in the first node transaction list in this round of consensus, that is, p0 does not exist in the first node transaction list, then the historical hash value contained in r1-p1 may be the hash value of the last batch package in the first node transaction list in the previous round of consensus.

[0124] The second node can further determine whether the second batch package is the next batch package after the first batch based on whether the historical hash value included in the second batch package is consistent with the hash value of the last batch package in the first node's transaction list stored locally by the second node, that is, the first batch package.

[0125] The second node may also determine whether the hash value of the first batch package is accurate based on the transaction information of the multiple transactions in the first batch package, wherein the hash value of each batch package is determined based on the transaction information of the multiple transactions included in the batch package.

[0126] In one possible implementation, the hash value can also be determined based on the position information of the batch package in the transaction list of the node to which it belongs, the historical hash value of the previous batch package in the transaction list of the node to which it belongs, and the transaction information of multiple transactions included in the batch package. Specifically, the hash value can be calculated according to the following formula:

[0127] batch hash=hash(pos|prev bacth hash|batch transactions)

[0128] Among them, pos is the position information of the batch package in the transaction list of the node to which it belongs, prev batch hash is the historical hash value of the previous batch package in the transaction list of the node to which it belongs, and batch transactions is the transaction information of multiple transactions contained in the batch package, such as the transaction values ​​of multiple transactions.

[0129] The second node determines whether the hash value of the first batch package is accurate based on the transaction information of multiple transactions included in the first batch package, and further determines the authenticity of the second batch package.

[0130] In an embodiment of the present application, the second node can further determine whether the second batch package is the next batch package in the first node's transaction list by determining whether the historical hash value contained in the second batch package is consistent with the hash value of the last batch package in the first node's transaction list locally stored by the second node; the second node can also determine whether the hash value of the first batch package is accurate based on the transaction information of multiple transactions contained in the first batch package, and further determine the authenticity of the second batch package.

[0131] Example 6:

[0132] In order to further improve the accuracy and efficiency of node consensus, based on the above embodiments, in this embodiment of the present application, if the second node fails to verify the second batch package, the method further includes:

[0133] The second node does not save the second batch package in the first node transaction chain list, and does not send voting information for the second batch package to the first node.

[0134] According to the verification process in each of the above embodiments, if the second node determines any of the second batch packages as negative, it indicates that the verification fails, and the second batch package is not saved in the locally stored transaction list of the first node, and the voting information for the second batch package is not sent to the first node, further ensuring the accuracy and efficiency of the node consensus.

[0135] In an embodiment of the present application, if the second node fails to verify the second batch package, the second batch package is not saved in the locally stored transaction list of the first node, and there is no need to send voting information for the second batch package to the first node, thereby further improving the accuracy and efficiency of node consensus.

[0136] Example 7:

[0137] In order to further improve the consistency of node consensus in the blockchain system, based on the above embodiments, in the embodiment of the present application, the process of consensus secondary nodes in the blockchain system reaching consensus on the consensus message package includes:

[0138] Any consensus secondary node in the blockchain system determines whether the node that sent the consensus message packet is the current consensus primary node; if so, for each target batch packet in the consensus message packet, determines whether the locally stored transaction linked list of each node contains the target batch packet;

[0139] If included, verification passes.

[0140] Any consensus secondary node within the blockchain system can determine whether the node sending the consensus message packet is the current consensus primary node based on the node signature contained in the consensus message packet. If not, it indicates a problem with the current consensus process and can initiate a view switch. If it is, the node signature contained in any target batch packet included in the consensus message packet is used to determine the node transaction list corresponding to the node to which the target batch packet belongs. Furthermore, the node transaction list stored locally for that node is then checked to determine whether the target batch packet is included in the node's transaction list. If so, verification is successful.

[0141] In an embodiment of the present application, any consensus sub-node in the blockchain determines whether the node sending the consensus message package is the current consensus master node based on the signature information contained in the consensus message package. If so, it further determines for each target batch package contained in the consensus message package whether the locally stored node transaction list to which the target batch package belongs contains the target bath package, and the verification is passed, thereby further ensuring the consistency of the node consensus in the blockchain system.

[0142] Example 8:

[0143] In order to further improve the accuracy and efficiency of node consensus in the blockchain system, based on the above embodiments, in the embodiment of the present application, if it is determined that the locally stored transaction list of each node does not contain the target batch package, the method further includes:

[0144] Send a request message to the consensus master node, where the request message is used to obtain the missing target batch package;

[0145] Receive the missing target batch package sent by the consensus master node;

[0146] Determine whether the voting information of the previous batch package in the received missing target batch package meets the preset requirements.

[0147] Any consensus replica node in the blockchain system can determine the transaction list of the node to which any target batch package belongs based on the signature information contained in the target batch package. If the locally stored transaction list of the node to which the target batch package belongs does not contain the target batch package, the consensus replica node can send a request message to the consensus master node, the request message containing the information of the last batch package contained in the locally stored transaction list of the node to which the target batch package belongs; and receive each batch package in the transaction list of the node to which the target batch package belongs sent by the consensus master node that is located after the last batch package; based on the position information of each received batch package, determine in sequence whether the voting information of the previous batch package contained in each received batch package meets the preset requirements; if it is determined that the number of votes contained in the voting information contained in the target batch package meets the preset value, then it is determined that the transactions in the target batch package and the batch packages located before each target batch package have reached consensus.

[0148] For example, if any consensus replica node is the third node, for any target batch package p3, it determines that the node transaction list to which p3 belongs is the second node transaction list. The third node determines that the last batch package contained in the locally stored second node transaction list is p2, namely r2-p2. In other words, the second node transaction list does not contain r2-p3, that is, the missing target batch package r2-p3. Then, a request message Q1 containing r2-p2 can be sent to the consensus master node. This request message is used to obtain the missing batch package. The consensus master node receives Q1 and, based on r2-p2 contained in Q1, determines that the missing batch packages are r2-p3 and r2-p4. It then returns a response message (Response) package containing the missing batch package to the third node. The third node receives the Response package sent by the consensus master node, and further determines whether the voting information of the previous batch package r2-p2 contained in the missing batch package r2-p3 meets the preset requirements, that is, whether the identification information of the voting node contained in the voting information includes the identification information of the third node, and whether the number of votes contained in the voting information is greater than the preset value; if so, it can be further determined whether the voting information of r2-p3 contained in r2-p4 meets the preset requirements. If so, it can be determined that the transactions in r2-p3 and each batch package before each r2-p3 have reached consensus, further ensuring the consistency of node consensus in the blockchain system.

[0149] In related technologies, when replica nodes verify a block, if there are missing transactions, they need to determine the missing transactions and synchronize them locally over the network. If a block contains terabytes of transactions, the worst-case scenario is terabytes of network requests, and the best-case scenario is zero. Each transaction requested for synchronization requires signature verification, with a computational complexity of O(TB).

[0150] In an embodiment of the present application, if any consensus replica node determines that the corresponding target batch package is not included in the locally stored transaction list of any node, it sends a request message to the consensus master node to obtain the missing batch package. Based on the missing batch package received from the consensus master node, the voting information contained in the missing batch package is verified to further ensure the consistency of the node consensus. In the embodiment of the present application, if there is a missing transaction, that is, a missing target batch package, it is only necessary to synchronize the missing batch package from the consensus master node once. The number of network requests is reduced from a positive correlation with the number of transactions to a positive correlation with the number of nodes, and the number of verifications is also reduced from a positive correlation with the number of transactions to a positive correlation with the number of batch packages. The number of transactions is much larger than the number of nodes, and also much larger than the number of batch packages. Therefore, the batch package synchronization process in the embodiment of the present application greatly improves the efficiency of node consensus.

[0151] Example 9:

[0152] Based on the same technical concept, on the basis of the above embodiments, in an embodiment of the present application, a node consensus device in a blockchain system is also provided, and the device is located at any node in the blockchain system. Figure 9 A schematic diagram of a node consensus process in a blockchain system provided for some embodiments of this application. Figure 9 As shown, the device includes:

[0153] Packaging module 901 is used to determine the last batch package whose voting information meets the preset requirements from the locally stored transaction chain tables of each node as the target batch package, and package the target batch package into a consensus message package. Each node transaction chain table corresponds to a node in the blockchain system, and each node locally stores the transaction chain table of each node. Any batch package in any node transaction chain table is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction chain table after the voting information of each node for the previous batch package meets the preset requirements.

[0154] The consensus module 902 is used to broadcast the consensus message package so that the consensus sub-nodes in the blockchain system can reach a consensus on the consensus message package.

[0155] In a possible implementation, the consensus module 902 is further configured to re-execute the step of determining the last batch package whose voting information meets preset requirements as the target batch package if a view switch occurs during the consensus process.

[0156] In one possible implementation, the packaging module 901 is specifically configured to, after obtaining voting information of each node on the first batch package that meets the preset requirements, package multiple transactions in the transaction pool into a second batch package, and save the second batch package to the local first node transaction list; the first batch package is the previous batch package of the second batch package in the first node transaction list; broadcast the second batch package so that the second node verifies the second batch package, and after the second node verifies the second batch package, save the second batch package to the local first node transaction list and send voting information on the second batch package to the first node; receive and save the voting information of the second node on the second batch package.

[0157] In one possible implementation, the batch package includes the location information of the batch package in the transaction list of the node to which it belongs, the voting information of the previous batch package in the transaction list of the node to which it belongs, the hash value of the batch package, and the node signature of the node to which it belongs;

[0158] The packaging module 901 is specifically configured to determine, based on the hash value and node signature of the batch package contained in the second batch package, the node transaction linked list to which the second batch package belongs; if the node transaction linked list to which the second batch package belongs is the first node transaction linked list, the second node determines whether the position information of the last batch package in the first node transaction linked list locally stored by the second node is the previous position of the position information contained in the second batch package; if so, determines whether the number of votes for the first batch package contained in the voting information of the second batch package meets a preset requirement; if so, verification is successful; if any of the above results are negative, verification fails.

[0159] In one possible implementation, the batch package further includes a historical hash value of the previous batch package in the transaction list of the node to which it belongs, and transaction information of multiple transactions included in the batch package;

[0160] The packaging module 901 is specifically used to verify the second batch package, and the process also includes at least one of the following: determining whether the historical hash value included in the second batch package is consistent with the hash value of the last batch package in the transaction list of the first node stored locally by the second node; and determining whether the hash value of the first batch package is accurate based on transaction information of multiple transactions included in the first batch package.

[0161] In a possible implementation, the packaging module 901 is further configured to not save the second batch package in the first node transaction linked list, and not send voting information for the second batch package to the first node.

[0162] In one possible implementation, the consensus module 902 is specifically configured to determine whether the node that sends the consensus message packet is the current consensus master node; if so, for each target batch packet in the consensus message packet, determine whether the locally stored transaction list of each node contains the target batch packet; if so, the verification is successful.

[0163] In one possible implementation, the consensus module 902 is further configured to send a request message to the consensus master node, where the request message is used to obtain missing batch packages; receive the missing batch packages sent by the consensus master node; and determine whether the voting information of the previous batch package contained in any received missing batch package meets preset requirements.

[0164] In an embodiment of the present application, each node locally stores a node transaction linked list corresponding to each node. Any batch package in any node transaction linked list is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction linked list after the voting information of each node for the previous batch package meets the preset requirements, so that the consensus master node can accurately determine the last batch package whose voting information meets the preset requirements from the locally stored node transaction linked list as the target batch package, and only package the target batch package of each node transaction linked list into a consensus message package, without having to package all transactions, thereby improving the packaging efficiency, and broadcasting the consensus message package, so that the consensus sub-nodes in the blockchain system can reach a consensus on the target batch package of each node transaction linked list contained in the consensus message package, without having to reach a consensus on each transaction, thereby further improving the node consensus efficiency in the blockchain system.

[0165] Example 10:

[0166] Based on the same inventive concept, on the basis of the above embodiments, in an embodiment of the present application, an electronic device is provided, which can realize the functions of any node in the blockchain system described above. Figure 10 This is a schematic diagram of the structure of an electronic device provided in some embodiments of the present application. Figure 10 As shown, the electronic device includes: a processor 1001, a communication interface 1002, a memory 1003 and a communication bus 1004, wherein the processor 1001, the communication interface 1002, and the memory 1003 communicate with each other through the communication bus 1004;

[0167] The memory 1003 stores a computer program. When the program is executed by the processor 801, the processor 1001 performs the following steps:

[0168] From the locally stored transaction linked lists of each node, the last batch package whose voting information meets the preset requirements is determined as the target batch package, and the target batch package is packaged into a consensus message package; wherein each node transaction linked list corresponds to a node in the blockchain system, and each node locally stores the transaction linked list of each node; any batch package in any node transaction linked list is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction linked list after the voting information of each node for the previous batch package meets the preset requirements;

[0169] The consensus message package is broadcasted so that the consensus sub-nodes in the blockchain system reach a consensus on the consensus message package.

[0170] In a possible implementation, the processor 1001 is further configured to, if a view switch occurs during the consensus process, re-execute the step of determining the last batch package whose voting information meets preset requirements as the target batch package.

[0171] In one possible implementation, the processor 1001 is further configured to, after obtaining voting information of each node on the first batch package that meets the preset requirements, package multiple transactions in the transaction pool into a second batch package, and save the second batch package to a local first-node transaction linked list; the first batch package is the previous batch package of the second batch package in the first-node transaction linked list; the first node broadcasts the second batch package so that the second node verifies the second batch package; the second node saves the second batch package to the local first-node transaction linked list after verification, and sends voting information on the second batch package to the first node; and receives and saves the voting information of the second node on the second batch package.

[0172] In one possible implementation, the batch package includes the location information of the batch package in the transaction list of the node to which it belongs, the voting information of the previous batch package in the transaction list of the node to which it belongs, the hash value of the batch package, and the node signature of the node to which it belongs;

[0173] The processor 1001 is further configured to determine, based on the hash value and node signature of the batch package contained in the second batch package, the node transaction linked list to which the second batch package belongs; if the node transaction linked list to which the second batch package belongs is the first node transaction linked list, the second node determining whether the position information of the last batch package in the first node transaction linked list locally stored by the second node is the previous digit of the position information contained in the second batch package; if so, determining whether the number of votes for the first batch package contained in the voting information of the second batch package meets a preset requirement; if so, verification is successful; if any of the above results is no, verification is unsuccessful.

[0174] In one possible implementation, the batch package further includes a historical hash value of the previous batch package in the transaction list of the node to which it belongs, and transaction information of multiple transactions included in the batch package;

[0175] The processor 1001 is further configured to verify the second batch package, wherein the process further includes at least one of the following:

[0176] Determine whether the historical hash value included in the second batch package is consistent with the hash value of the last batch package in the transaction chain list of the first node stored locally by the second node;

[0177] Determine whether a hash value of the first batch package is accurate based on transaction information of multiple transactions included in the first batch package.

[0178] In a possible implementation, the processor 1001 is further configured to, if the verification of the second batch package fails, cause the second node to not save the second batch package in the transaction linked list of the first node and not send voting information for the second batch package to the first node.

[0179] In one possible implementation, the processor 1001 is further configured to determine whether the node that sends the consensus message packet is the current consensus master node; if so, for each target batch packet in the consensus message packet, determine whether the locally stored transaction list of each node contains the target batch packet; if so, the verification is successful.

[0180] In one possible implementation, the processor 1001 is further configured to, if it is determined that the locally stored transaction linked list of each node does not contain the target batch package, send a request message to the consensus master node, wherein the request message is used to obtain the missing batch package; receive the missing batch package sent by the consensus master node; and determine whether the voting information of the previous batch package contained in any received missing batch package meets the preset requirements.

[0181] The communication bus mentioned in the electronic device mentioned above may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is used in the figure, but this does not mean that there is only one bus or only one type of bus.

[0182] The communication interface 1002 is used for communication between the electronic device and other devices.

[0183] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk memory. Alternatively, the memory may be at least one storage device located away from the processor.

[0184] The above-mentioned processor can be a general-purpose processor, including a central processing unit, a network processor (NP), etc.; it can also be a digital signal processing processor (DSP), an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, etc.

[0185] In an embodiment of the present application, each node locally stores a node transaction linked list corresponding to each node. Any batch package in any node transaction linked list is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction linked list after the voting information of each node for the previous batch package meets the preset requirements, so that the consensus master node can accurately determine the last batch package whose voting information meets the preset requirements from the locally stored node transaction linked list as the target batch package, and only package the target batch package of each node transaction linked list into a consensus message package, without having to package all transactions, thereby improving the packaging efficiency, and broadcasting the consensus message package, so that the consensus sub-nodes in the blockchain system can reach a consensus on the target batch package of each node transaction linked list contained in the consensus message package, without having to reach a consensus on each transaction, thereby further improving the node consensus efficiency in the blockchain system.

[0186] Example 11:

[0187] Based on the same inventive concept and on the basis of the above embodiments, in an embodiment of the present application, a computer-readable storage medium is provided, which stores a computer program executable by a processor. When the program runs on the processor, the processor implements the following node consensus steps of any node in the blockchain system:

[0188] The consensus master node determines the last batch package whose voting information meets the preset requirements from the locally stored transaction chain tables of each node as the target batch package, and packages the target batch package into a consensus message package. Each node transaction chain table corresponds to a node in the blockchain system, and each node locally stores the transaction chain table of each node. Any batch package in any node transaction chain table is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction chain table after the voting information of each node for the previous batch package meets the preset requirements.

[0189] The consensus master node broadcasts the consensus message package so that the consensus slave nodes in the blockchain system reach a consensus on the consensus message package.

[0190] In one possible implementation, the method further includes:

[0191] If a view switch occurs during the consensus process, the new consensus master node re-executes the step of determining that the last batch package whose voting information meets the preset requirements is the target batch package.

[0192] In one possible implementation, any batch package in any node's transaction linked list is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction linked list after the voting information of each node on the previous batch package meets the preset requirements, including:

[0193] After obtaining voting information from each node on the first batch and verifying that it meets the preset requirements, the first node packages multiple transactions in the transaction pool into a second batch and saves the second batch to the local first node transaction list; the first batch is the previous batch of the second batch in the first node transaction list;

[0194] The first node broadcasts the second batch package, so that the second node verifies the second batch package. After the verification is successful, the second node saves the second batch package to the local transaction list of the first node and sends voting information for the second batch package to the first node.

[0195] The first node receives and saves the voting information of the second node on the second batch package.

[0196] In one possible implementation, the batch package includes the location information of the batch package in the transaction list of the node to which it belongs, the voting information of the previous batch package in the transaction list of the node to which it belongs, the hash value of the batch package, and the node signature of the node to which it belongs;

[0197] The second node verifies the second batch packet, including:

[0198] The second node determines, based on the hash value and the node signature of the batch package contained in the second batch package, a transaction linked list of the node to which the second batch package belongs;

[0199] If the node transaction linked list to which the second batch packet belongs is the first node transaction linked list, the second node determines whether the position information of the last batch packet in the first node transaction linked list stored locally by the second node is the previous position of the position information contained in the second batch packet;

[0200] If so, determining whether the number of votes for the first batch package included in the voting information of the second batch package meets the preset requirement;

[0201] If yes, the verification is successful; if any of the above results is no, the verification is unsuccessful.

[0202] In one possible implementation, the batch package further includes a historical hash value of the previous batch package in the transaction list of the node to which it belongs, and transaction information of multiple transactions included in the batch package;

[0203] The process of verifying the second batch package further includes at least one of the following:

[0204] Determine whether the historical hash value included in the second batch package is consistent with the hash value of the last batch package in the transaction chain list of the first node stored locally by the second node;

[0205] Determine whether a hash value of the first batch package is accurate based on transaction information of multiple transactions included in the first batch package.

[0206] In a possible implementation, if the second node fails to verify the second batch packet, the method further includes:

[0207] The second node does not save the second batch package in the first node transaction chain list, and does not send voting information for the second batch package to the first node.

[0208] In one possible implementation, the process of consensus secondary nodes in the blockchain system reaching consensus on the consensus message package includes:

[0209] Any consensus secondary node in the blockchain system determines whether the node that sent the consensus message packet is the current consensus primary node; if so, for each target batch packet in the consensus message packet, determines whether the locally stored transaction linked list of each node contains the target batch packet;

[0210] If included, verification passes.

[0211] In a possible implementation, if it is determined that the locally stored transaction linked list of each node does not contain the target batch package, the method further includes:

[0212] Send a request message to the consensus master node, where the request message is used to obtain the missing batch package;

[0213] Receive the missing batch package sent by the consensus master node;

[0214] Determine whether the voting information of the previous batch package contained in any of the missing batch packages received meets the preset requirements.

[0215] The above-mentioned computer-readable storage medium can be any available medium or data storage device that can be accessed by the processor in the electronic device, including but not limited to magnetic storage such as floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc., optical storage such as CDs, DVDs, BDs, HVDs, etc., and semiconductor storage such as ROMs, EPROMs, EEPROMs, non-volatile memories (NANDFLASH), solid-state drives (SSDs), etc.

[0216] In an embodiment of the present application, each node locally stores a node transaction linked list corresponding to each node. Any batch package in any node transaction linked list is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction linked list after the voting information of each node for the previous batch package meets the preset requirements, so that the consensus master node can accurately determine the last batch package whose voting information meets the preset requirements from the locally stored node transaction linked list as the target batch package, and only package the target batch package of each node transaction linked list into a consensus message package, without having to package all transactions, thereby improving the packaging efficiency, and broadcasting the consensus message package, so that the consensus sub-nodes in the blockchain system can reach a consensus on the target batch package of each node transaction linked list contained in the consensus message package, without having to reach a consensus on each transaction, thereby further improving the node consensus efficiency in the blockchain system.

[0217] Based on the same inventive concept, embodiments of the present application further provide a computer program product comprising: computer program code that, when executed on a computer, causes the computer to execute the node consensus method in any blockchain system discussed above. Because the principles underlying the problems solved by the computer program product are similar to those of the node consensus method in a blockchain system, the implementation of the computer program product can be referenced to the implementation of the method, and any repetitions will not be repeated.

[0218] In an embodiment of the present application, each node locally stores a node transaction linked list corresponding to each node. Any batch package in any node transaction linked list is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction linked list after the voting information of each node for the previous batch package meets the preset requirements, so that the consensus master node can accurately determine the last batch package whose voting information meets the preset requirements from the locally stored node transaction linked list as the target batch package, and only package the target batch package of each node transaction linked list into a consensus message package, without having to package all transactions, thereby improving the packaging efficiency, and broadcasting the consensus message package, so that the consensus sub-nodes in the blockchain system can reach a consensus on the target batch package of each node transaction linked list contained in the consensus message package, without having to reach a consensus on each transaction, thereby further improving the node consensus efficiency in the blockchain system.

[0219] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

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

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

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

[0223] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A node consensus method in a blockchain system, characterized in that: The method comprises: The consensus master node determines the last batch package whose voting information meets the preset requirements from the locally stored transaction chain tables of each node as the target batch package, and packages the target batch package into a consensus message package. Each node transaction chain table corresponds to a node in the blockchain system, and each node locally stores the transaction chain table of each node. Any batch package in any node transaction chain table is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction chain table after the voting information of each node for the previous batch package meets the preset requirements. The consensus master node broadcasts the consensus message package so that the consensus slave nodes in the blockchain system reach a consensus on the consensus message package.

2. The method according to claim 1, characterized in that The method further comprises: If a view switch occurs during the consensus process, the new consensus master node re-executes the step of determining that the last batch package whose voting information meets the preset requirements is the target batch package.

3. The method according to claim 1, characterized in that Any batch package in the transaction chain list of any node is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction chain list after the voting information of each node on the previous batch package meets the preset requirements, including: After obtaining voting information from each node on the first batch and verifying that it meets the preset requirements, the first node packages multiple transactions in the transaction pool into a second batch and saves the second batch to the local first node transaction list; the first batch is the previous batch of the second batch in the first node transaction list; The first node broadcasts the second batch package, so that the second node verifies the second batch package. After the verification is successful, the second node saves the second batch package to the local transaction list of the first node and sends voting information for the second batch package to the first node. The first node receives and saves the voting information of the second node on the second batch package.

4. The method according to claim 3, characterized in that The batch package contains the location information of the batch package in the transaction list of the node to which it belongs, the voting information of the previous batch package in the transaction list of the node to which it belongs, the hash value of the batch package and the node signature of the node to which it belongs; The second node verifies the second batch packet, including: The second node determines, based on the hash value and the node signature of the batch package contained in the second batch package, a transaction linked list of the node to which the second batch package belongs; If the node transaction linked list to which the second batch packet belongs is the first node transaction linked list, the second node determines whether the position information of the last batch packet in the first node transaction linked list stored locally by the second node is the previous position of the position information contained in the second batch packet; If so, determining whether the number of votes for the first batch package included in the voting information of the second batch package meets the preset requirement; If yes, the verification is successful; if any of the above results is no, the verification is unsuccessful.

5. The method according to claim 4, characterized in that The batch package also includes the historical hash value of the previous batch package in the transaction list of the node to which it belongs, and the transaction information of multiple transactions included in the batch package; The process of verifying the second batch package further includes at least one of the following: Determine whether the historical hash value included in the second batch package is consistent with the hash value of the last batch package in the transaction chain list of the first node stored locally by the second node; Determine whether a hash value of the first batch package is accurate based on transaction information of multiple transactions included in the first batch package.

6. The method according to claim 4 or 5, characterized in that If the second node fails to verify the second batch packet, the method further includes: The second node does not save the second batch package in the first node transaction chain list, and does not send voting information for the second batch package to the first node.

7. The method according to claim 1, characterized in that The process of consensus sub-nodes in the blockchain system reaching consensus on the consensus message package includes: Any consensus secondary node in the blockchain system determines whether the node that sent the consensus message packet is the current consensus primary node; if so, for each target batch packet in the consensus message packet, determines whether the locally stored transaction linked list of each node contains the target batch packet; If included, verification passes.

8. The method according to claim 7, characterized in that If it is determined that the locally stored transaction chain list of each node does not contain the target batch package, the method further includes: Send a request message to the consensus master node, where the request message is used to obtain the missing batch package; Receive the missing batch package sent by the consensus master node; Determine whether the voting information of the previous batch package contained in any of the missing batch packages received meets the preset requirements.

9. A node consensus device in a blockchain system, characterized in that: The device comprises: A packaging module is used to determine the last batch package whose voting information meets the preset requirements from the locally stored transaction chain tables of each node as the target batch package, and package the target batch package into a consensus message package; wherein, each node transaction chain table corresponds to a node in the blockchain system, and each node locally stores the transaction chain table of each node; any batch package in any node transaction chain table is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction chain table after the voting information of each node for the previous batch package meets the preset requirements; The consensus module is used to broadcast the consensus message package so that the consensus sub-nodes in the blockchain system can reach a consensus on the consensus message package.

10. An electronic device, characterized in that: include: a memory for storing program instructions; A processor is configured to call the program instructions stored in the memory and execute the steps of the method according to any one of claims 1 to 8 according to the obtained program instructions.

11. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program includes program instructions. When the program instructions are executed by a computer, the computer is caused to perform the method according to any one of claims 1 to 8.

12. A computer program product, characterized in that The computer program product comprises: a computer program code, and when the computer program code is run on a computer, the computer is caused to execute the method according to any one of claims 1 to 8.

Images