Node consensus method and device in block chain system, equipment and medium

Abstract

The invention relates to a node consensus method and device in a block chain system, equipment and a medium, in the method, a node transaction chain table corresponding to each node is locally stored in each node, and any batch packet in any node transaction chain table is obtained after voting information of the previous batch packet based on each node meets a preset requirement. The method is characterized in that a plurality of transactions in a transaction pool are packaged by a node corresponding to a node transaction chain table, so that a consensus main node accurately determines the last batch packet of which voting information meets a preset requirement as a target batch packet from each node transaction chain table stored locally, and only the target batch packet of each node transaction chain table is packaged into a consensus message packet; according to the method, all transactions do not need to be packaged, the packaging efficiency is improved, and the consensus message packet is broadcasted, so that the consensus auxiliary node in the block chain system can perform consensus on the target batch packet of each node transaction chain table contained in the consensus message packet, consensus does not need to be performed on each transaction, and the node consensus efficiency in the block chain system is further improved.

Description

Technical Field

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

[0002] Each node in the blockchain network confirms a batch of transactions through an algorithm and ensures that all nodes have consistent confirmation results for this batch of data. This algorithm is the consensus algorithm of the blockchain. Among them, the nodes in the blockchain include: the consensus master node (Leader), which is used to package multiple transactions in the transaction pool into blocks and broadcast them to each remaining node in the blockchain. There is only one consensus master node in each round of consensus. In order to prevent the consensus master node from forging blocks, the consensus master node will be switched after each round of consensus; each node in the blockchain except the consensus master node is a replica node (Replica), which is used to verify and vote on the blocks broadcast by the consensus master node and broadcast the voting information; if multiple nodes receive multiple voting information within the preset time, it is determined that the transactions in the block have reached a consensus. There are multiple replica nodes in each round of consensus, and the processing process of each replica node is similar.

[0003] When the consensus master node fails or the network times out, that is, multiple nodes do not receive multiple voting information within the preset time, a view switch will occur until multiple nodes of the entire blockchain reach a consistent view. The view switch is successful, and a new consensus master node is selected based on the new view. After the view switch, the transactions in the previously packaged blocks will be released back to the transaction pool; the new consensus master node re-executes the steps of obtaining the transaction packaged blocks in the transaction pool. Since only the consensus master node can package blocks, and each view switch requires repackaging of blocks, the 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, device, equipment 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 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 lists 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;

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

[0009] In a 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 a possible implementation, 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:

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

[0013] The first node broadcasts the second batch package, so that the second node verifies the second batch package. After the verification is passed, the second node saves the second batch package to the local transaction chain 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 a possible implementation, the batch package includes the position information of the batch package in the transaction chain list of the node to which it belongs, the voting information of the previous batch package in the transaction chain 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 package, including:

[0017] The second node determines, according to the hash value and the node signature of the batch package contained in the second batch package, a node transaction chain list 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 locally stored by the second node is the previous position information included in the second batch packet;

[0019] If yes, 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 a possible implementation, the batch package also includes a historical hash value of a previous batch package in the transaction list of the corresponding node 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 the hash value of the first batch package is accurate based on the transaction information of the multiple transactions included in the first batch package.

[0025] In a possible implementation manner, 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 linked list, and does not send voting information for the second batch package to the first node.

[0027] In a possible implementation, the process of consensus sub-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 sends the consensus message package is the current consensus primary node; if so, for each target batch package in the consensus message package, determines whether the locally stored transaction list of each node contains the target batch package;

[0029] If included, verification passes.

[0030] In a possible implementation, 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:

[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, and the device comprising:

[0035] The packaging module is used to determine 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 package 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 each node transaction chain list; 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;

[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 a possible implementation, the packaging module is specifically used to package multiple transactions in the transaction pool into a second batch package after obtaining voting information of each node on the first batch package to meet the preset requirements, 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 the second node saves the second batch package to the local first node transaction list after the verification is passed, and sends the voting information of the second batch package to the first node; receive and save the voting information of the second node on the second batch package.

[0039] In a possible implementation, the batch package includes the position information of the batch package in the transaction chain list of the node to which it belongs, the voting information of the previous batch package in the transaction chain 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 used to determine the node transaction linked list to which the second batch package belongs according to the hash value and the node signature of the batch package contained in the second batch package; 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 digit of the position information contained in the second batch package; if so, determine whether the number of votes for the first batch package contained in the voting information of the second batch package meets the preset requirements; if so, the verification is passed; if any of the above results is no, the verification is failed.

[0041] In a 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 also includes at least one of the following items, including: 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 locally stored 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 list, and not send voting information for the second batch package to the first node.

[0043] In a possible implementation, the consensus module is specifically used 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 contained, the verification is passed.

[0044] In a possible implementation, the consensus module is further used to send a request message to the consensus master node, where 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 of the received missing batch packages meets the 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, when executed by a processor, implements the steps of any method described in the first aspect.

[0047] In a fifth aspect, an embodiment of the present application provides a computer program product, which includes: a computer program code, when the computer program code is run 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 based on the node corresponding to the node transaction linked list packaging multiple transactions in the transaction pool 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 the need 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 the need 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 the related technologies, the following is a brief introduction to the drawings required for use in the embodiments or the related technology descriptions. Obviously, the drawings described below are some embodiments of the present application, and a person skilled in the art can also obtain other drawings 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 node transaction chain representation schematic provided for some embodiments of the present application;

[0052] Figure 3 A schematic diagram of broadcast voting for a batch package provided for 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 a three-stage consensus process provided for some embodiments of the present application;

[0055] Figure 6 A schematic diagram of a 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 a data structure of a batch package provided for some embodiments of the present application;

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

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

[0060] In order to make the purpose, technical solutions and advantages of this application clearer, this application will be further described in detail below in conjunction with the accompanying drawings. Obviously, the embodiments described in this application are only part of the embodiments of this application, rather than all the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

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

[0062] The terms "first", "second", "third", etc. in the specification and claims of this application and the above drawings are used to distinguish similar or similar objects or entities, and do not necessarily mean to limit a specific order or sequence, unless otherwise noted. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances.

[0063] The terms "comprises," "comprising," and "having," 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 functions 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 it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

[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 confirms a batch of transactions through an algorithm and ensures that all nodes have consistent confirmation results for this batch of data. This algorithm is the consensus algorithm of the blockchain.

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

[0069] Each node in the blockchain network confirms a batch of transactions through an algorithm and ensures that all nodes have consistent confirmation results for this batch of data. This algorithm is the consensus algorithm of the blockchain. Among them, the nodes in the blockchain include: the consensus master node, which is used to package multiple transactions in the transaction pool into blocks and broadcast them to each remaining node in the blockchain. There is only one consensus master node in each round of consensus. In order to prevent the consensus master node from forging blocks, the consensus master node will be switched after each round of consensus; each node in the blockchain except the consensus master node is a replica node, which is used to verify and vote on the blocks broadcast by the consensus master node and broadcast the voting information; if multiple nodes receive multiple voting information within the preset time, it is determined that the transactions in the block have reached a consensus. There are multiple replica nodes in each round of consensus, and the processing process of each replica node is similar.

[0070] When the consensus master node fails or the network times out, that is, multiple nodes do not receive multiple voting information within the preset time, a view switch will occur until multiple nodes of the entire blockchain reach a consistent view. The view switch is successful, and a new consensus master node is selected based on the new view. After the view switch, the transactions in the previously packaged blocks will be released back to the transaction pool; the new consensus master node re-executes the steps of obtaining the transaction packaged blocks in the transaction pool. Since only the consensus master node can package blocks, and each view switch requires repackaging of blocks, the node consensus in the blockchain system is inefficient and time-consuming.

[0071] Based on this, in order to improve the node consensus efficiency in the blockchain system, the embodiment of the present application provides a node consensus method, device, equipment, medium and computer program product in the blockchain system. In this method, the consensus master node determines the last batch package whose voting information meets the preset requirements from the locally stored transaction chain list 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 each node transaction chain list; 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; the consensus master node broadcasts the consensus message package so that the consensus sub-nodes in the blockchain system reach a consensus on the consensus message package.

[0072] Embodiment 1:

[0073] Figure 1 A schematic diagram of a node consensus process in a blockchain system provided for some embodiments of the present 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 linked lists of each node as the target batch package, and packages the target batch package into a consensus message package; wherein each node transaction linked list corresponds to a node in the blockchain system, and each node locally stores each node transaction linked list; 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.

[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] In order to improve the node consensus efficiency in the blockchain system, in an embodiment of the present application, the transaction pool of each node in the blockchain system is modified from a list structure to a chain 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 transaction list. Each node transaction list contains multiple batch packages. Any batch package in any node transaction list is based on the node corresponding to the node transaction list packaging multiple transactions in the transaction pool after the voting information of each node for the previous batch package meets the preset requirements. Among them, the preset requirement can be that the number of votes is greater than the preset value. For example, there are 3f nodes in the blockchain system, and 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 FIG. 1 , the blockchain system includes four nodes. The first node (Replica 1, R1) packages multiple transactions in the transaction pool at a preset time interval to obtain the first batch package p1, that is, Figure 2 In the example, p1 is saved in 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 process 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 is determined 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 multiple transactions in the transaction pool are packaged into the second batch package, i.e. Figure 2r1-p2 in the first node, and save p2 after p1 in the first node's local transaction list. Among them, the voting information of each node on p1 (proof of p1 votes) can be saved in p2, and the voting information includes the identification information of each voting node and the total number of votes.

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

[0079] Specifically, the last batch package whose voting information meets the preset requirements in each transaction chain list can be determined as the target batch package according to 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 the present application. Figure 4 As shown, the R1 node is the consensus master node. The R1 consensus packaging module determines the last batch package whose voting information meets the preset requirements in each node transaction list according to the locally stored transaction list of each node as the target batch package. 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, according to the voting information of each node on the previous batch package r1-p3 saved in r1-p4, it can be determined that the voting information of r1-p3 meets the preset requirements, and 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] In each round of consensus, any node in the blockchain system is determined as the consensus master node, and the other nodes are consensus sub-nodes. The node consensus process generally includes four stages, namely, the block packaging stage, the pre-preparation (Prepare) stage, the preparation (Prepare) stage, and the submission (Commit) stage. In the block packaging stage of the node consensus process of the embodiment of the present application, the consensus master node can use the above 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, to further improve the packaging efficiency and consensus efficiency.

[0081] S102: The consensus master node broadcasts the consensus message package so that the consensus sub-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 consensus on the target batch package in each transaction list in the consensus message package.

[0083] Specifically, Figure 5 A schematic diagram of the three-stage consensus process provided for some embodiments of the present 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] In the Pre-Prepare stage of the consensus process, the consensus master node Replica1 broadcasts the consensus message package so that each consensus sub-node in the blockchain system can reach a consensus on the target batch package in each transaction chain list in the consensus message package. In the Prepare stage, the consensus sub-node verifies the target batch package in each transaction chain list in the consensus message package, that is, compares the target bath package in each transaction chain list in the consensus message package with the batch package contained in the locally saved transaction chain list of each node to see if it matches. Specifically, for any target batch package, the node to which the target batch package belongs and its corresponding node transaction chain list can be determined based on the node signature contained in the target batch package, and then it can be determined whether the target batch package exists in the batch package contained in the locally saved node transaction chain list. If it exists, a match is determined. If it is determined that each target batch package in the consensus message package matches the batch package in the locally saved node transaction chain list, the signature information of the consensus message package is verified and broadcast. In the Commit phase, if any node in the blockchain system receives more than a preset number of signatures for the consensus message package within a preset time, it is determined that the target batch package of each node's transaction list and the transactions in the batch package before each target batch package have reached consensus. The value of the preset number can be determined according to the number of nodes included in the blockchain system. For example, if the blockchain system contains 3f nodes in total, the preset number is 2f+1.

[0085] In the 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 based on the node corresponding to the node transaction linked list packaging multiple transactions in the transaction pool 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 as the target batch package from the locally stored node transaction linked lists. Only the target batch package of each node transaction linked list is packaged into a consensus message package, without the need to package all transactions, thereby improving the packaging efficiency. The consensus message package is broadcasted 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 the need to reach a consensus on each transaction, thereby further improving the node consensus efficiency in the blockchain system.

[0086] Embodiment 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 the related art, after the view is switched, the new consensus master node will abandon the previously packaged blocks and re-enter the block packaging stage. During the period from repackaging the blocks to the final consensus, no transactions will be finally uploaded to the chain, that is, the transaction latency will increase. In addition, when the consensus replica node verifies the new consensus master node's packaged blocks, it needs to verify each transaction in the block, and the transaction verification takes a long time. If the number of transactions in the transaction pool is 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 the transaction, and there is no need for the replica node 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 the present application. Figure 6 As shown in the figure, when R1~R3 ​​nodes 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, determine the new consensus master node R1, and the new consensus master node R1 will broadcast the message packet. At this time, all nodes switch their views to view Figure 1 That is, view = 1. For example, the blockchain system contains 3f nodes in total, and the preset number is 2f+1. In the Pre-Prepare stage of view = 1, the R1 node will re-execute the step of determining the last batch package whose voting information meets the preset requirements as the target batch package, and accurately determine the target batch package of 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 the view is 0, the original consensus master node R4 packages B1. The new consensus master node R1 packages the target batch package of each node transaction list into B2, where the transactions in B2 include the transactions in B1 packaged by the original consensus master node R4. There is no need to release the transactions in B1 to the transaction pool for repackaging, which greatly speeds up the consensus process and can effectively reduce the overall transaction delay. The optimization method of transaction pool and packaging can effectively reduce the transaction delay when the consensus view is switched, 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 a 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] Embodiment 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 list of any node is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the node transaction list after the voting information of each node for the previous batch package meets the preset requirements, including:

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

[0096] The first node broadcasts the second batch package, so that the second node verifies the second batch package. After the verification is passed, the second node saves the second batch package to the local transaction chain 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 to meet 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, and the second node saves the second batch package to the local first node transaction list after the verification is passed, and sends the voting information on 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 includes four nodes, namely Replica 1, Replica 2, Replica 3 and Replica 4.

[0100] Replica1 broadcasts a message package containing the first batch package (p1) to Replica2, Replica3, and Replica4 respectively. Replica2 receives p1 and verifies the information contained in p1. If the verification is passed, p1 is saved to the Replica1 batch list of Replica2 and a vote for p1 (Vote of p1) is sent to Replica1. The processing of Replica3 and Replica4 can refer to Replica2 and will not be repeated here. After Replica1 obtains the votes of each node for p1, if it is determined that the voting information meets the preset requirements, such as the total number of votes exceeds 2, multiple transactions in the transaction pool are packaged into the second batch package (p2) and p2 is saved after p1 in the Replica1 batch list of Replica1. Among them, the voting information of each node for p1 can be saved in p2, and the voting information includes the identification information of each voting node and the total number of votes.

[0101] Replica1 continues to broadcast the message package containing p2 to Replica2, Replica3 and Replica4 respectively. Replica2 receives p2 and verifies the information contained in p2. If the verification is passed, p2 is saved to the Replica1 batch list in the local Replica2, and a vote for p2 (Vote of p1) is sent to Replica1. The processing of Replica3 and Replica4 can refer to Replica2, which will not be repeated here. Replica1 receives and saves the votes of each node for p2. Specifically, after obtaining the votes of each node for p2, if Replica1 determines that the voting information meets the preset requirements, such as the total number of votes exceeds 2, multiple transactions in the transaction pool are packaged into the third batch package (p3), and p3 is saved after p1 in the Replica1 batch list in the local Replica1. Among them, the voting information of each node for p2 can be saved in p3, and the voting information includes 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 list of any node is obtained by packaging multiple transactions in the transaction pool by the node corresponding to the transaction list of the node after the voting information of each node for the previous batch package meets the preset requirements, thereby ensuring that the voting information of each batch package stored in the transaction 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, thereby further improving the packaging efficiency.

[0103] Embodiment 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 package, including:

[0106] The second node determines, according to the hash value and the node signature of the batch package contained in the second batch package, a node transaction chain list 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 locally stored by the second node is the previous position information included in the second batch packet;

[0108] If yes, 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 transaction chain list may include the POS of r1-p1, the voting information proof of p0 votes of each node for the previous batch package p0, and the batch hash of r1-p1. It may also include the node signature of the node to which it belongs.

[0111] In a 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 according to 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 a batch packet sent by the first node, if it is determined that the node transaction chain list to which the second batch packet belongs is the first node transaction chain list, it means that the preliminary verification has passed. If it is determined that the node transaction chain list to which the second batch belongs is not the first node transaction chain list, it means that the preliminary verification has failed, and the second batch packet is likely to be a batch packet forged by a malicious node.

[0114] If the preliminary verification is passed, the second node determines whether the position information contained in the last batch package in the first node transaction list stored in the local transaction pool is the previous position of the position information contained in the second batch package. For example, if the position information of the second batch package is 2, it is determined whether the position information contained in the last batch package in the first node 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 transaction list is the first batch package. If so, it means that the second batch package is the batch package after the first batch package in the first node transaction list. If not, for example, the position information contained in the last batch package in the first node transaction list is 0, it means that the first batch package may not have been received, and the second batch package can be cached separately until the first batch package is received and then the second batch package is verified. For another example, if the position information contained in the last batch package in the first node transaction list is 2, it means that the second batch package verification fails, and it may be a batch package 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 further determine 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, determine 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 above two determination results 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 the verification.

[0116] In an embodiment of the present application, the second node determines whether the node transaction list to which the second batch package belongs is the first node that broadcasts the second batch package based on the hash value and the node signature contained in the second batch package; if so, it determines whether the position information of the last batch package in the first node transaction list locally stored 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 node transaction lists, and further improving the accuracy and efficiency of the node consensus.

[0117] Embodiment 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 the hash value of the first batch package is accurate based on the transaction information of the 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 a 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 transaction list locally stored by the second node, namely, 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 a 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 also further determine whether the second batch package is the next batch package in the first node 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 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] Embodiment 6:

[0132] In order to further improve the accuracy and efficiency of node consensus, based on the above embodiments, in the 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 linked list, and does not send voting information for the second batch package to the first node.

[0134] According to the verification process in the above embodiments, if any determination result of the second node for the second batch package is negative, it means that the verification fails, and the second batch package is not saved in the locally saved transaction list of the first node, and the voting information for the second batch package is not sent to the first node, so as to further ensure 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] Embodiment 7:

[0137] In order to further improve the consistency of node consensus in the blockchain system, on the basis of the above embodiments, in the embodiment of the present application, the process of consensus sub-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 sends the consensus message package is the current consensus primary node; if so, for each target batch package in the consensus message package, determines whether the locally stored transaction list of each node contains the target batch package;

[0139] If included, verification passes.

[0140] Any consensus sub-node in the blockchain system can determine whether the node sending the consensus message package is the current consensus master node based on the node signature contained in the consensus message package. If not, it means that there is a problem in the current consensus process and a view switch can be initiated. If yes, the node transaction list corresponding to the node to which the target batch package belongs is determined for the node signature contained in any target batch package contained in the consensus message package, and then determine whether the target batch package is included in the node transaction list stored locally. If it is included, it means that the verification is passed.

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

[0142] Embodiment 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 last 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 node transaction list of any target batch package according to the signature information contained in the target batch package, if the locally stored node transaction list does not contain the target batch package. The consensus replica node can send a request message to the consensus master node, the request message contains the information of the last batch package contained in the locally stored node transaction list of the target batch package; and receive each batch package after the last batch package in the node transaction list of the target batch package sent by the consensus master node; according to the position information of each received batch package, determine in turn 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, it is determined that the transactions in the target batch package and the batch packages before each target batch package have reached consensus.

[0148] For example, any consensus replica node is the third node. For any target batch package p3, it is determined 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 saved second node transaction list is p2, that is, r2-p2, that is, 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. The request message is used to obtain the missing batch package. The consensus master node receives Q1, and according to r2-p2 contained in Q1, it determines that the missing batch packages are r2-p3 and r2-p4, and 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 the related art, when a replica node verifies a block, if there is a missing transaction, it needs to determine the missing transaction and synchronize it locally through the network. If the number of transactions in a block is TB, then the number of network requests is TB times in the worst case and 0 times in the best case. Each transaction requested for synchronization requires a signature verification, and the computational complexity is O(TB).

[0150] In the embodiment of the present application, if any consensus replica node determines that any node transaction chain list saved locally does not contain the corresponding target batch package, it sends a request message to the consensus master node to obtain the missing batch package, and verifies the voting information contained in the missing batch package according to the missing batch package sent by the received consensus master node, so as to further ensure the consistency of the node consensus. In the embodiment of the present application, if there is a lack of transaction, that is, a missing target batch package, it is only necessary to synchronize the missing batch package from the consensus master node once, and the number of network requests is reduced from the positive correlation of the number of transactions to the positive correlation of the number of nodes, and the number of verifications is also reduced from the positive correlation of the number of transactions to the positive correlation of the number of batch packages, where the number of transactions is much larger than the number of nodes, and also much larger than the number of batch packages, so the batch package synchronization process in the embodiment of the present application greatly improves the efficiency of node consensus.

[0151] Embodiment 9:

[0152] Based on the same technical concept, on the basis of the above embodiments, in the embodiments 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. Fig. 9 A schematic diagram of a node consensus process in a blockchain system provided for some embodiments of the present application. Fig. 9 As shown, the device comprises:

[0153] The packaging module 901 is used to determine 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 package 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 each node transaction chain list; 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;

[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 a possible implementation, the packaging module 901 is specifically used to package multiple transactions in the transaction pool into a second batch package after obtaining voting information of each node on the first batch package to meet the preset requirements, 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 the second node saves the second batch package to the local first node transaction list after the verification is passed, and sends the voting information of 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 a possible implementation, the batch package includes the position information of the batch package in the transaction chain list of the node to which it belongs, the voting information of the previous batch package in the transaction chain 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 used to determine the node transaction linked list to which the second batch package belongs according to the hash value and the node signature of the batch package contained in the second batch package; 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 digit of the position information contained in the second batch package; if so, determine whether the number of votes for the first batch package contained in the voting information of the second batch package meets the preset requirements; if so, the verification is passed; if any of the above results is no, the verification is failed.

[0159] In a possible implementation, the batch package also includes a historical hash value of a previous batch package in the transaction list of the corresponding node 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 contained 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 contained in the first batch package.

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

[0162] In a possible implementation, the consensus module 902 is specifically used 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 contained, the verification is passed.

[0163] In a possible implementation, the consensus module 902 is further used to send a request message to the consensus master node, where 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 of the received missing batch packages meets the 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 based on the node corresponding to the node transaction linked list packaging multiple transactions in the transaction pool 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 the need 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 the need to reach a consensus on each transaction, thereby further improving the node consensus efficiency in the blockchain system.

[0165] Embodiment 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 function of any node in the blockchain system described above. Fig.10 A schematic diagram of the structure of an electronic device provided in some embodiments of the present application. Fig.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, determine the last batch package whose voting information meets the preset requirements as the target batch package, and package the target batch package 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 lists 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 can reach a consensus on the consensus message package.

[0170] In a possible implementation, the processor 1001 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.

[0171] In a possible implementation, the processor 1001 is further used to package multiple transactions in the transaction pool into a second batch package and save the second batch package to a local first node transaction list after obtaining voting information of each node on the first batch package to meet the preset requirements; 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 the second node verifies the second batch package, and the second node saves the second batch package to the local first node transaction list after the verification is passed, and sends voting information on the second batch package to the first node; the voting information of the second node on the second batch package is received and saved.

[0172] In a possible implementation, the batch package includes the position information of the batch package in the transaction chain list of the node to which it belongs, the voting information of the previous batch package in the transaction chain 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 the 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, determine 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, the verification is successful; if any of the above results is no, the verification is unsuccessful.

[0174] In a possible implementation, the batch package also includes a historical hash value of a previous batch package in the transaction list of the corresponding node 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 the hash value of the first batch package is accurate based on the transaction information of the 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 a possible implementation, the processor 1001 is further used to determine whether the node sending 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 contained, the verification is successful.

[0180] In a possible implementation, the processor 1001 is further used to send a request message to the consensus master node if it is determined that the locally stored transaction list of each node does not contain the target batch package, and 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 of the received missing batch packages meets the preset requirements.

[0181] The communication bus mentioned in the above electronic device can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or 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 a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0184] The above-mentioned processor can be a general-purpose processor, including a central processing unit, a network processor (Network Processor, NP), etc.; it can also be a digital signal processing processor (Digital Signal Processing, 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 based on the node corresponding to the node transaction linked list packaging multiple transactions in the transaction pool 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 the need 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 the need to reach a consensus on each transaction, thereby further improving the node consensus efficiency in the blockchain system.

[0186] Embodiment 11:

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

[0188] 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 lists 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;

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

[0190] In a 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 a possible implementation, 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:

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

[0194] The first node broadcasts the second batch package, so that the second node verifies the second batch package. After the verification is passed, the second node saves the second batch package to the local transaction chain 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 a possible implementation, the batch package includes the position information of the batch package in the transaction chain list of the node to which it belongs, the voting information of the previous batch package in the transaction chain 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 package, including:

[0198] The second node determines, according to the hash value and the node signature of the batch package contained in the second batch package, a node transaction chain list 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 locally stored by the second node is the previous position information included in the second batch packet;

[0200] If yes, 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 a possible implementation, the batch package also includes a historical hash value of a previous batch package in the transaction list of the corresponding node 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 the hash value of the first batch package is accurate based on the transaction information of the multiple transactions included in the first batch package.

[0206] In a possible implementation manner, 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 linked list, and does not send voting information for the second batch package to the first node.

[0208] In a possible implementation, the process of consensus sub-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 sends the consensus message package is the current consensus primary node; if so, for each target batch package in the consensus message package, determines whether the locally stored transaction list of each node contains the target batch package;

[0210] If included, verification passes.

[0211] In a possible implementation, 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:

[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 CD, DVD, BD, HVD, etc., and semiconductor storage such as ROM, EPROM, EEPROM, non-volatile memory (NANDFLASH), solid-state drive (SSD), 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 based on the node corresponding to the node transaction linked list packaging multiple transactions in the transaction pool 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 the need 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 the need 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, the embodiment of the present application also provides a computer program product, which includes: computer program code, when the computer program code is run on a computer, the computer executes the node consensus method in any blockchain system discussed above. Since the principle of solving the problem by the above computer program product is similar to the node consensus method in the blockchain system, the implementation of the above computer program product can refer to the implementation of the method, and the repeated parts 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 based on the node corresponding to the node transaction linked list packaging multiple transactions in the transaction pool 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 the need 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 the need 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 may be provided as methods, systems, or computer program products. Therefore, the present application may 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 may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include 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 box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes 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 capable of directing a computer or other programmable data processing device to operate 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 A 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 instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0223] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also 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 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 lists 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; The consensus master node broadcasts the consensus message package so that the consensus sub-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 the voting information of each node on the first batch package that meets the preset requirements, the first node packages multiple transactions in the transaction pool into a second batch package, and saves the second batch package to the local first node transaction chain list; the first batch package is the previous batch package of the second batch package in the first node transaction chain list; The first node broadcasts the second batch package, so that the second node verifies the second batch package. After the verification is passed, the second node saves the second batch package to the local transaction chain 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 includes 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; The second node verifies the second batch package, including: The second node determines, according to the hash value and the node signature of the batch package contained in the second batch package, a node transaction chain list 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 locally stored by the second node is the previous position information included in the second batch packet; If yes, 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 chain list of the node to which it belongs, and the transaction information of multiple transactions contained 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 the hash value of the first batch package is accurate based on the transaction information of the 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 linked 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 sends the consensus message package is the current consensus primary node; if so, for each target batch package in the consensus message package, determines whether the locally stored transaction list of each node contains the target batch package; 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: The packaging module is used to determine 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 package 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 each node transaction chain list; 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; 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 used to call the program instructions stored in the memory, and execute the steps included in any one of the methods of claims 1-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, and when the program instructions are executed by a computer, the computer executes 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 enabled to execute the method according to any one of claims 1 to 8.

Images