Blockchain transaction pool implementation method, device, computer equipment and storage medium

Abstract

The present application relates to a method, device, computer equipment and storage medium for implementing a blockchain transaction pool. The method includes: receiving transaction data, generating a transaction block containing summary information and transaction attribute information of the transaction data; broadcasting the transaction block to other consensus nodes in the blockchain system, instructing other consensus nodes to verify the transaction block; receiving transaction block confirmation information fed back by other consensus nodes, generating an arbitration certificate containing transaction block confirmation information; broadcasting the arbitration certificate to other consensus nodes, and receiving arbitration certificates generated by other consensus nodes in the transaction validity proof process of this round, until the number of received arbitration certificates reaches a preset number, determining that the transaction validity proof of this round in the blockchain system is over, and triggering the generation process of the next round of transaction blocks. This method is used to reduce the pressure on the bandwidth and memory consumption of consensus nodes and improve the efficiency of transaction consensus.

Description

Technical Field

[0001] The present application relates to the field of network communication technology, and in particular to a method, device, computer equipment and storage medium for implementing a blockchain transaction pool. Background Art

[0002] In the blockchain system, the consensus node master node packages the transaction data received from the client into transaction blocks and initiates a transaction consensus proposal so that other consensus nodes in the blockchain system except the consensus node master node can verify the transaction data and complete the transaction consensus.

[0003] In the traditional transaction consensus method, after receiving the transaction block broadcast by the consensus master node, other consensus nodes obtain the corresponding transaction data in the local transaction pool based on the transaction information contained in the transaction block, and verify the transaction data to complete the transaction consensus among the consensus nodes.

[0004] However, in the traditional transaction consensus method, the transaction consensus proposal needs to be initiated by a unique consensus master node, and if the transaction data is missing from the transaction pool of other consensus nodes during the transaction consensus process, other consensus nodes also need to re-pull the transaction data from the unique consensus master node. The heavy reliance on the consensus master node leads to high bandwidth pressure on the consensus master node and low consensus efficiency. Summary of the invention

[0005] Based on this, it is necessary to provide a blockchain transaction pool implementation method, device, computer equipment and storage medium to address the above technical problems.

[0006] A method for implementing a blockchain transaction pool, the method being applied to any consensus node of a blockchain system, the method comprising:

[0007] Receiving transaction data, and generating a transaction block including summary information and transaction attribute information of the transaction data;

[0008] Broadcasting the transaction block to other consensus nodes in the blockchain system, and instructing the other consensus nodes to verify the transaction block;

[0009] Receive the transaction block confirmation information fed back by the other consensus nodes, and generate an arbitration certificate containing the transaction block confirmation information;

[0010] The arbitration certificate is broadcast to the other consensus nodes, and arbitration certificates generated by the other consensus nodes in the transaction validity proof process of this round are received, until the number of the received arbitration certificates reaches a preset number, it is determined that the transaction validity proof of this round in the blockchain system is completed, triggering the generation process of the next round of transaction blocks.

[0011] In one embodiment, the receiving transaction data and generating a transaction block including summary information and transaction attribute information of the transaction data includes:

[0012] Receive transaction data sent from the client, and store the transaction data in batches into a local transaction pool;

[0013] The pre-stored transaction attribute information of the current transaction round and the transaction summary of the transaction data in the local transaction pool are read to generate a transaction block including the transaction summary and the transaction attribute information.

[0014] In one embodiment, the receiving the transaction block confirmation information fed back by the other consensus nodes and generating an arbitration certificate including the transaction block confirmation information includes:

[0015] Receive transaction confirmation information, each of which is a signature message fed back by the other consensus nodes after the transaction block is verified;

[0016] When the number of the received transaction confirmation information meets a preset number threshold, an arbitration certificate including the preset number of the transaction confirmation information is generated.

[0017] In one of the embodiments, the preset number threshold is determined by the total number of consensus nodes and the number of malicious nodes included in the blockchain system according to a preset attribute relationship; the malicious node is a node in the consensus node that has malicious attack behavior.

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

[0019] Receiving a transaction block to be verified sent by other transaction block creation nodes; the other transaction block creation nodes are other consensus nodes that create transaction blocks in the blockchain system;

[0020] Determining the validity of the transaction block according to a preset validity verification rule;

[0021] If the transaction block is valid, read the transaction information contained in the transaction summary list in the transaction block, obtain the transaction data corresponding to the transaction information in the local transaction pool, and verify the transaction data;

[0022] When the transaction data is verified, transaction confirmation information is fed back to the other transaction block creation nodes, and the transaction confirmation information is a signed message.

[0023] In one embodiment, determining the validity of the transaction block according to a preset validity check rule includes:

[0024] Reading the transaction attribute information in the transaction block, and determining the consistency between the transaction round number in the transaction attribute information and the current transaction round;

[0025] Identify whether the transaction attribute information carries the signature information of the node creating the other transaction blocks and the arbitration certificate of the previous round;

[0026] Determining whether the transaction block is the first transaction block of the current transaction round;

[0027] If the transaction round number is consistent with the current transaction round, the transaction attribute information carries the signature information of the node that created the other transaction blocks and the arbitration certificate of the previous round, and the transaction block is the first transaction block of the current transaction round, then the transaction block is determined to be valid.

[0028] In one embodiment, before acquiring the transaction data corresponding to the transaction information in the local transaction pool, the method further includes:

[0029] According to the transaction information, identifying transaction data corresponding to the transaction information in a local transaction pool;

[0030] If the transaction data corresponding to the transaction information is not identified in the local transaction pool, the transaction data is determined as missing transaction data;

[0031] Send a missing transaction data request to the other transaction block creation node or other verification node to obtain the missing transaction data from the transaction pool of the other transaction block creation node or the other verification node; the other verification node is a consensus node that has verified the transaction block.

[0032] In one of the embodiments, when the consensus node is determined to be a consensus protocol master node in the blockchain system, the method further includes:

[0033] Obtaining a target arbitration certificate, where the target arbitration certificate is the arbitration certificate with the highest transaction round number stored locally;

[0034] Broadcasting the target arbitration certificate to the other consensus nodes, and instructing the other consensus nodes to verify the target arbitration certificate;

[0035] If arbitration certificate confirmation information fed back by a preset number of the other consensus nodes is received, a transaction block is generated from the transaction list in all transaction blocks corresponding to the target arbitration certificate, and the transaction block is submitted to the blockchain system.

[0036] In one embodiment, generating a transaction block from the transaction lists in all transaction blocks corresponding to the target arbitration certificate, and submitting the transaction block to the blockchain system includes:

[0037] Obtaining the transaction reference relationship contained in the arbitration certificate, identifying the transaction block in the reference relationship and the historical transaction block in the historical validity proof process corresponding to the transaction block;

[0038] According to the transaction information in the transaction list contained in the transaction block and the historical transaction block, de-duplicate sorting is performed to obtain a total transaction list with a unique sorting standard, and the total transaction list is submitted to the blockchain system as a transaction block.

[0039] A blockchain transaction pool implementation device, the device comprising:

[0040] A first receiving module, configured to receive transaction data and generate a transaction block including summary information and transaction attribute information of the transaction data;

[0041] A broadcast module, used to broadcast the transaction block to other consensus nodes in the blockchain system, and instruct the other consensus nodes to verify the transaction block;

[0042] A second receiving module is used to receive the transaction block confirmation information fed back by the other consensus nodes, and generate an arbitration certificate containing the transaction block confirmation information;

[0043] A generation module is used to broadcast the arbitration certificate to the other consensus nodes, and receive arbitration certificates generated by the other consensus nodes in the transaction process of this round, until the number of the received arbitration certificates reaches a preset number, it is determined that the validity proof of this round of transactions in the blockchain system is completed, and the generation process of the next round of transaction blocks is triggered.

[0044] A computer device comprises a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0045] Receiving transaction data, and generating a transaction block including summary information and transaction attribute information of the transaction data;

[0046] Broadcasting the transaction block to other consensus nodes in the blockchain system, and instructing the other consensus nodes to verify the transaction block;

[0047] Receive the transaction block confirmation information fed back by the other consensus nodes, and generate an arbitration certificate containing the transaction block confirmation information;

[0048] The arbitration certificate is broadcast to the other consensus nodes, and arbitration certificates generated by the other consensus nodes in the transaction validity proof process of this round are received, until the number of the received arbitration certificates reaches a preset number, it is determined that the transaction validity proof of this round in the blockchain system is completed, triggering the generation process of the next round of transaction blocks.

[0049] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the following steps:

[0050] Receiving transaction data, and generating a transaction block including summary information and transaction attribute information of the transaction data;

[0051] Broadcasting the transaction block to other consensus nodes in the blockchain system, and instructing the other consensus nodes to verify the transaction block;

[0052] Receive the transaction block confirmation information fed back by the other consensus nodes, and generate an arbitration certificate containing the transaction block confirmation information;

[0053] The arbitration certificate is broadcast to the other consensus nodes, and arbitration certificates generated by the other consensus nodes in the transaction validity proof process of this round are received, until the number of the received arbitration certificates reaches a preset number, it is determined that the transaction validity proof of this round in the blockchain system is completed, triggering the generation process of the next round of transaction blocks.

[0054] The above-mentioned blockchain transaction pool implementation method, device, computer equipment and storage medium, the method is applied to any consensus node of the blockchain system, the consensus node is called a transaction block creation node, the method includes: receiving transaction data, generating a transaction block containing summary information and transaction attribute information of the transaction data; broadcasting the transaction block to other consensus nodes in the blockchain system, instructing the other consensus nodes to verify the transaction block; receiving the transaction block confirmation information fed back by the other consensus nodes, generating an arbitration certificate containing the transaction block confirmation information; broadcasting the arbitration certificate to the other consensus nodes, and receiving the arbitration certificate generated by the other consensus nodes in the transaction validity proof process of this round, until the number of the received arbitration certificates reaches a preset number, determining that the transaction validity proof of this round in the blockchain system is over, triggering the generation process of the next round of transaction blocks. With this method, any consensus node in the blockchain system can create a transaction block and initiate a transaction validity proof proposal. After the proposal, the validity proof of the transaction data is realized by generating an arbitration certificate containing the signature information of other consensus nodes, reducing the pressure of node bandwidth and memory consumption in the blockchain system, and improving the transaction consensus efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] Figure 1 This is an application environment diagram of a method for implementing a blockchain transaction pool in an embodiment;

[0056] Figure 2 A flowchart of a method for implementing a blockchain transaction pool in one embodiment;

[0057] Figure 3 A schematic diagram of the structure of a transaction block generated by a consensus node in each transaction round in one embodiment;

[0058] Figure 4 A schematic diagram of a flow chart of steps for generating a transaction block in one embodiment;

[0059] Figure 5 A schematic diagram of a flow chart of steps for generating an arbitration certificate in one embodiment;

[0060] Figure 6 A schematic diagram of a flow chart of a step of verifying a transaction block in one embodiment;

[0061] Figure 7 A schematic diagram of a flow chart of a step of verifying the validity of a transaction block in an embodiment;

[0062] Figure 8 A flowchart of a transaction synchronization step in a transaction block validity proof process in one embodiment;

[0063] Fig. 9 A schematic diagram of a process of consensus on arbitration certificates in one embodiment;

[0064] Fig.10 A schematic diagram of a flow chart of an arbitration certificate verification step in an embodiment;

[0065] Fig.11 A schematic diagram of all transaction blocks on an arbitration certificate reference path in one embodiment;

[0066] Fig.12 It is a structural block diagram of a blockchain transaction pool implementation device in one embodiment;

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

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

[0069] The blockchain transaction pool implementation method provided in this application can be applied to Figure 1 In any consensus node (e.g., consensus node 102) of the blockchain system 100 shown. Among them, the consensus nodes in the blockchain system communicate through the network. Consensus node 102 receives the transaction data sent by the client and generates a transaction block containing summary information and transaction attribute information of the transaction data. Then the consensus node 102 broadcasts the transaction block to other consensus nodes 104 in the blockchain system, instructing other consensus nodes 104 to verify the transaction block. Receive the transaction block confirmation information fed back by other consensus nodes 104, and generate an arbitration certificate containing the transaction block confirmation information. Finally, the consensus node 102 broadcasts the arbitration certificate to other consensus nodes 104, and receives the arbitration certificates generated by other consensus nodes 104 in the transaction validity proof process of this round, until the number of received arbitration certificates reaches the preset number, it is determined that the transaction validity proof of this round in the blockchain system is over, and the generation process of the next round of transaction blocks is triggered.

[0070] Among them, the consensus nodes in the blockchain system can be but are not limited to various personal computers, laptops, smart phones, tablets, etc., and can also be implemented as independent servers or server clusters composed of multiple servers, which is not limited in the embodiments of the present application.

[0071] In one embodiment, Figure 2 As shown, a method for implementing a blockchain transaction pool is provided, which is described by taking the method applied to any consensus node in a blockchain system as an example, and includes the following steps:

[0072] Step 202: Receive transaction data and generate a transaction block including summary information and transaction attribute information of the transaction data.

[0073] Specifically, the blockchain system contains multiple consensus nodes, and each consensus node can prove and verify the validity of transaction data. Therefore, in the blockchain system, any consensus node can initiate a transaction validity proof proposal based on the transaction data in the local transaction pool.

[0074] In practice, each consensus node in the blockchain system receives transaction data sent by its own client, and then the consensus nodes transmit transaction data through network communication to achieve initial synchronization of transaction data in the transaction pool of each consensus node. For example, after receiving the transaction data sent by the client, each consensus node stores the transaction data in the local transaction pool and broadcasts the transaction data to other consensus nodes to complete the initial synchronization of transaction data.

[0075] Then, based on the transaction data after initial synchronization, any consensus node in the blockchain system proposes a transaction validity proof proposal based on the transaction data in the local transaction pool, that is, generates a transaction block containing summary information and transaction attribute information of the transaction data in the local transaction pool. Figure 3 As shown, the data structure of the transaction block contains transaction attribute information, which may include but is not limited to: the signature S of the creator of the transaction block, the number of current transaction rounds r, the transaction list of the transaction block and the arbitration certificate list of the previous round. In order to further reduce bandwidth, the transaction list of the transaction block only contains the transaction hash summary (referred to as the transaction summary). Figure 3 These are the transaction blocks created by consensus nodes a, b, c, and d in rounds r-1, r, and r+1, respectively. A non-malicious consensus node will only create one transaction block in each round of transaction validity proof proposal.

[0076] Optionally, each consensus node is not limited to the resources of a single computer, and multiple working nodes can be enabled to receive transaction data from the client. Therefore, each consensus node can be divided into multiple working nodes. The multiple working nodes enabled by a consensus node include a working master node and other working nodes. Based on this, when multiple working nodes of the consensus node receive transaction data, the transaction data can be separated into metadata and transaction value data. The working master node in the consensus node is responsible for receiving the metadata blocks submitted by other working nodes, and packaging the metadata blocks into transaction metadata blocks and broadcasting them to other consensus nodes in the blockchain. The working master node among the multiple working nodes of other consensus nodes is responsible for receiving the transaction metadata blocks and synchronizing the transaction metadata blocks.

[0077] When the working master node of other consensus nodes is missing relevant transaction data (metadata and transaction value data), the working master node in the consensus node instructs its other working nodes to pull complete transaction data from the working node of the transaction block creator through the synchronized transaction metadata block.

[0078] This method ensures that transaction data is evenly distributed among the working nodes of each consensus node through a responsible balancing mechanism, further reducing the bandwidth and memory consumption of the working master node within each consensus node.

[0079] Step 204, broadcast the transaction block to other consensus nodes in the blockchain system, and instruct other consensus nodes to verify the transaction block.

[0080] In implementation, the consensus node that creates the transaction block (for ease of description, it can be called consensus node A) broadcasts the transaction block to other consensus nodes in the blockchain system, instructing other consensus nodes to verify the transaction block to complete the transaction block validity proof based on the transaction pool protocol.

[0081] Step 206: Receive transaction block confirmation information fed back by other consensus nodes, and generate an arbitration certificate containing the transaction block confirmation information.

[0082] The transaction block confirmation information may include but is not limited to signature messages from other consensus nodes.

[0083] In implementation, other consensus nodes in the blockchain system verify the transaction blocks sent by consensus node A. After verification, they will feedback transaction block confirmation information to consensus node A. When consensus node A receives the target number of transaction block confirmation information, consensus node A generates an arbitration certificate (also called Quorum Cert, QC certificate) containing the transaction block confirmation information.

[0084] Step 208, broadcast the arbitration certificate to other consensus nodes, and receive arbitration certificates generated by other consensus nodes in the transaction validity proof process of this round, until the number of received arbitration certificates reaches a preset number, it is determined that the transaction validity proof of this round in the blockchain system is completed, triggering the generation process of the next round of transaction blocks.

[0085] In implementation, consensus node A broadcasts the arbitration certificate to other consensus nodes, so that the whole network blockchain can perform global validity proof of the validity proof result of the transaction block pointed to by the arbitration certificate. At the same time, since any consensus node in the blockchain system can initiate a transaction block validity proof proposal, in the same transaction validity proof round, other consensus nodes in the whole network blockchain system except consensus node A also initiated a transaction block validity proof proposal, and then generated the corresponding arbitration certificate and broadcast it to the whole network. Therefore, consensus node A receives arbitration certificates from other consensus nodes in this round until the number of arbitration certificates received reaches the preset number (quorum, legal number of people), indicating that most of the consensus nodes in the whole network blockchain system have completed the validity proof of this round of transactions, and consensus node A determines that its own transaction validity proof of this round has ended, triggering the generation process of the next round of transaction blocks.

[0086] In the above-mentioned blockchain transaction pool implementation method, any consensus node in the blockchain system can create a transaction block and initiate a transaction validity proof proposal. After the proposal, the validity proof of the transaction data is realized by generating an arbitration certificate containing the signature information of other consensus nodes, thereby reducing the pressure on node bandwidth and memory consumption in the blockchain system and improving transaction consensus efficiency.

[0087] In one embodiment, Figure 4 As shown, the specific processing process of consensus nodes generating transaction blocks in step 202 includes the following steps:

[0088] Step 402, receiving transaction data sent from the client, and storing the transaction data in batches into a local transaction pool.

[0089] In implementation, consensus node A maintains transaction attribute information under the current transaction round r locally, where the counting principle of the current transaction round r is the accumulation of natural numbers (for example, 0, 1, 2, 3...), and the transaction round number starts from the initial transaction round number 0. Each time a new round of transaction data validity proof is carried out, the transaction round number is accumulated. At the same time, consensus node A receives the transaction data of this round sent from the client, and stores the transaction data in batches in the local transaction pool.

[0090] Optionally, consensus node A sends the transaction data of this round stored in the local transaction pool to other consensus nodes through the network, and stores it in the transaction pools corresponding to other consensus nodes to achieve initial synchronization of transaction data. In the subsequent process of proving the validity of transaction blocks, if the transaction data is missing, secondary synchronization of transaction data is performed.

[0091] Step 404, read the pre-stored transaction attribute information of the current transaction round and the transaction summary of the transaction data in the local transaction pool, and generate a transaction block including the transaction summary and the transaction attribute information.

[0092] In implementation, consensus node A reads the transaction attribute information of the current transaction round maintained in the local transaction pool and the transaction summary (digest hash value) of the transaction data in the local transaction pool, and generates a transaction block containing the transaction summary (digest hash value) and transaction attribute information. Among them, the transaction attribute information is used to identify the transaction block, and the transaction summary is used to generate the corresponding transaction list in the transaction block.

[0093] In order to reduce bandwidth, only the hash value of the transaction summary is stored in the transaction list. Optionally, the transaction hash list can be replaced by calculating the root hash through Merkle Tree to reduce the size of the new transaction block submitted by the main working node. Each consensus node can enable multiple working nodes to increase the transaction data throughput, and then generate the root hash of multiple batches of transactions in batches and combine them into transaction blocks.

[0094] In one embodiment, Figure 5 As shown, the specific processing process of step 206 includes:

[0095] Step 502, receiving transaction confirmation information.

[0096] Among them, each transaction confirmation information is the signature message fed back by other consensus nodes after the transaction block is verified.

[0097] In implementation, consensus node A receives transaction confirmation information for the transaction block from other consensus nodes.

[0098] Step 504: When the number of received transaction confirmation information meets a preset number threshold, an arbitration certificate including the preset number of transaction confirmation information is generated.

[0099] In implementation, when the number of received transaction confirmation information meets a preset number threshold (quorum), it means that the vast majority (quorum) of consensus nodes in the blockchain system have verified and passed the transaction block, and then, the preset number threshold of transaction confirmation information received is used to generate an arbitration certificate for the current round r.

[0100] In one embodiment, the preset number threshold is determined by the total number of consensus nodes and the number of malicious nodes included in the blockchain system according to a preset attribute relationship.

[0101] Among them, malicious nodes are nodes in the consensus nodes that have malicious attack behaviors.

[0102] In implementation, the preset number threshold (quorum) of transaction confirmation information and the preset number of arbitration certificates mentioned in the above embodiment, wherein the calculation formula of the preset number (quorum) is as follows:

[0103]

[0104] Where N represents the total number of nodes, f represents the number of malicious nodes, N ≥ 3f + 1, therefore, quorum ≥ 2f + 1.

[0105] In one embodiment, Figure 6 As shown, the method also includes:

[0106] Step 602: Receive the transaction block to be verified sent by other transaction block creation nodes.

[0107] Among them, other transaction block creation nodes are other consensus nodes that create transaction blocks in the blockchain system.

[0108] In implementation, consensus node A receives the transaction block to be verified sent by other transaction block creation nodes to verify the transaction block. Specifically, since any consensus node in the blockchain system can initiate a transaction block validity proof proposal, during a round of transaction validity proof, while consensus node A creates a transaction block and initiates a transaction block validity proof, other consensus nodes in the blockchain system also create transaction blocks and initiate transaction block validity proof. Therefore, consensus node A can not only act as the creator of the transaction block, but also as the verifier of the transaction block.

[0109] Step 604, determining the validity of the transaction block according to the preset validity verification rules.

[0110] In implementation, consensus node A determines the validity of the transaction block according to the preset validity verification rules. The validity verification rules are established based on transaction attribute information and are used to determine the validity of the transaction block, so as to verify the content of subsequent transaction blocks if the transaction block is valid.

[0111] Step 606: If the transaction block is valid, read the transaction information contained in the transaction summary list in the transaction block, obtain the transaction data corresponding to the transaction information in the local transaction pool, and verify the transaction data.

[0112] In implementation, if the verification transaction block is valid, consensus node A reads the transaction information contained in the transaction summary list in the transaction block, obtains the transaction original data corresponding to the transaction information in the local transaction pool (i.e., the transaction data stored in the local transaction pool after initial synchronization), and then verifies the transaction data.

[0113] Step 608: When the transaction data is verified, the transaction confirmation information is fed back to other transaction block creation nodes.

[0114] Among them, the transaction confirmation information is a signed message.

[0115] In implementation, when the transaction data is verified, consensus node A feeds back transaction confirmation information to other transaction block creation nodes, and the transaction confirmation information indicates that the transaction data corresponding to the transaction block has been verified.

[0116] In one embodiment, Figure 7 As shown, the specific processing process of verifying the validity of the transaction block based on the validity verification rule in step 604 includes:

[0117] Step 702, read the transaction attribute information in the transaction block, and determine whether the transaction round number in the transaction attribute information is consistent with the current transaction round.

[0118] In implementation, consensus node A reads the transaction attribute information in the transaction block and determines the consistency between the transaction round number contained in the transaction attribute information and the current transaction round. For example, if the transaction round number contained in the transaction attribute information of the transaction block is r, and the current transaction round in the blockchain system of the entire network is also r, it means that the transaction round number in the transaction block is correct. Otherwise, the current transaction block is determined to be invalid.

[0119] Step 704, identifying whether the transaction attribute information carries signature information of other transaction block creation nodes and the arbitration certificate of the previous round.

[0120] In implementation, since the transaction block creation process requires the transaction block creation node to perform signature authentication and the arbitration certificate of the previous round of transactions needs to be accumulated into the new transaction block to ensure the reference relationship between the arbitration certificates of each round of transactions in the transaction block, the consensus node A, which currently serves as a validator, can identify whether the transaction attribute information of the transaction block carries the signature information of other consensus nodes (as the transaction block creation node) and the arbitration certificate of the previous round.

[0121] Step 706, determining whether the transaction block is the first transaction block of the current transaction round.

[0122] In implementation, since non-malicious nodes in the blockchain system only create one transaction block in a round of transaction validity proof, the consensus node A currently acting as a validator can determine whether the transaction block is the first transaction block in the current transaction round, thereby determining the validity of the transaction block.

[0123] Optionally, since a non-malicious node only creates one transaction block in one round of transaction validity proof, the transaction block validity verification rule corresponding to the transaction condition can also be formulated as having one and only one transaction block within a preset time, so as to verify the validity of the current transaction block.

[0124] Step 708: If the transaction round number is consistent with the current transaction round, the transaction attribute information carries the signature information of other transaction block creation nodes and the arbitration certificate of the previous round, and the transaction block is the first transaction block of the current transaction round, then the transaction block is determined to be valid.

[0125] In implementation, the above validity verification rules are used for verification. Specifically, if the transaction round number is consistent with the transaction round of the current blockchain system, the transaction attribute information of the transaction block carries the signature information of the creator of the transaction block and the arbitration certificate generated by the validity proof of the previous round of transactions, and the transaction block is also the first transaction block of the transaction round in which its transaction block creation node is currently located, then the transaction block is determined to be valid.

[0126] In one embodiment, Figure 8 As shown, before acquiring the transaction data corresponding to the transaction information in the local transaction pool in step 606, the method further includes:

[0127] Step 802: According to the transaction information, transaction data corresponding to the transaction information is identified in the local transaction pool.

[0128] In practice, the transaction pool of consensus node A stores not only the transaction data sent by its own client, but also the transaction data broadcasted by other consensus nodes during the initial synchronization process. Therefore, when consensus node A, as a transaction validator, needs to verify the received transaction block, consensus node A searches for the transaction data corresponding to the identified transaction information in the local transaction pool based on the transaction information in the transaction block.

[0129] If consensus node A recognizes the corresponding transaction data in the local transaction pool, it indicates that during the initial synchronization of transaction data, the transaction data synchronization between consensus node A and the transaction block creation node is completed. Then consensus node A performs verification based on the transaction data in the local transaction pool.

[0130] Step 804: If the transaction data corresponding to the transaction information is not identified in the local transaction pool, the transaction data is determined as missing transaction data.

[0131] In implementation, if the transaction data corresponding to the transaction information is not identified in the local transaction pool, indicating that the transaction data was not synchronized during the initial synchronization of the transaction data, consensus node A determines the transaction data corresponding to the transaction information as missing transaction data.

[0132] Step 806: Send missing transaction data requests to other transaction block creation nodes or other verification nodes to obtain missing transaction data from the transaction pools of other transaction block creation nodes or other verification nodes.

[0133] Among them, other verification nodes are consensus nodes that have verified the transaction blocks.

[0134] In implementation, in the blockchain system, since any consensus node (i.e., the transaction block creation node) can broadcast the transaction block it created and initiate proof of transaction block validity, a consensus node initiates a proposal for proof of transaction block validity for the transaction block it created, and other consensus nodes also initiate proposals for proof of validity for the transaction block they created. Furthermore, the consensus nodes act as each other's transaction block verifiers to verify the transaction blocks received from other consensus nodes (i.e., other transaction block creation nodes). When consensus node A verifies the transaction blocks from other transaction block creation nodes, since the transaction data corresponding to the transaction information in the transaction block is missing in the transaction pool of consensus node A, consensus node A can send a missing transaction data request to the creator of the transaction block to obtain the original transaction data, or send a missing transaction data request to the verification node in the blockchain system that has verified the transaction block (other consensus nodes that act as verifiers in the blockchain system) to pull the missing transaction data from its transaction pool.

[0135] In one embodiment, Fig. 9As shown, the transaction pool protocol will prove the validity of the transaction blocks submitted by the quorum consensus nodes in each round, thereby generating a complete directed acyclic graph (DAG) structure. In order to ensure the consistent arrangement of transactions, the consensus protocol needs to reach a consensus on the unique path of the directed acyclic graph. Therefore, the consensus protocol master node is first determined according to a preset algorithm. When the consensus node (consensus node A) is determined as the consensus protocol master node in the blockchain system, the method also includes:

[0136] Step 902: Obtain the target arbitration certificate.

[0137] The target arbitration certificate is the arbitration certificate with the highest transaction round number stored locally.

[0138] In implementation, the consensus protocol master node (consensus node A) queries and obtains the target arbitration certificate in the local transaction pool. The target arbitration certificate should be the certificate of the current transaction round. Therefore, the current transaction round of the target arbitration certificate should be the one with the highest transaction round number among all arbitration certificates. Therefore, the transaction round number in the certificate can be used as the screening condition for selecting the target arbitration certificate.

[0139] Step 904, broadcast the target arbitration certificate to other consensus nodes, and instruct other consensus nodes to verify the target arbitration certificate.

[0140] In implementation, the consensus protocol master node initiates a validity proof proposal based on the target arbitration certificate, that is, broadcasts the target arbitration certificate to other consensus nodes, instructs other consensus nodes to verify the target arbitration certificate, so that other consensus nodes can know the validity proof result of the transaction block pointed to by the target arbitration certificate.

[0141] Step 906: If arbitration certificate confirmation information fed back by a preset number of other consensus nodes is received, a transaction list in all transaction blocks corresponding to the target arbitration certificate is generated into a transaction block, and the transaction block is submitted to the blockchain system.

[0142] In implementation, if arbitration certificate confirmation information of the target arbitration certificate is received from a preset number (quorum) of other consensus nodes, the consensus protocol master node identifies all transaction blocks (all transaction blocks include transaction blocks and historical transaction blocks) on the reference path of the target arbitration certificate based on the reference relationship in the target arbitration certificate, generates a transaction block from the transaction list in all transaction blocks corresponding to the target arbitration certificate, and submits the transaction block to the blockchain system.

[0143] Optionally, in addition to using arbitration certificates to prove the validity of transactions across the entire network, you can also use secure shared random numbers (instead of arbitration certificates) to achieve validity proof, so as to ensure that the consensus protocol remains active in an asynchronous network (i.e., the random number is updated once in each transaction round). Each consensus node in the current transaction round can sign with a shared key and include it in the transaction block created by the current round. After the consensus node collects quorum signatures from the transaction block of the current round, it aggregates them to generate a deterministic threshold signature, thereby calculating a secure and shareable random number, and using the random number to determine the submitted transaction block.

[0144] In one embodiment, Fig.10 As shown, the specific process of generating a transaction block from the transaction list in all transaction blocks corresponding to the arbitration certificate and submitting the transaction block to the blockchain system in step 906 includes:

[0145] Step 1002, obtaining the transaction reference relationship contained in the target arbitration certificate, identifying the transaction block in the reference relationship and the historical transaction block in the historical validity proof process corresponding to the transaction block.

[0146] In implementation, the consensus protocol master node obtains the transaction reference relationship (also called reference path) contained in the target arbitration certificate, identifies the transaction block in the reference relationship and the historical transaction block in the aforementioned historical validity proof process corresponding to the transaction block. Fig.11 As shown, if the current transaction is round r+1, then based on the arbitration certificate of round r+1 (target arbitration certificate QC r+1,a ), obtain the reference path corresponding to the arbitration certificate, which contains the transaction block pointed to by the current r+1 round arbitration certificate (B r+1,a ), and also includes the historical transaction blocks pointed to by the transaction certificates in round r, round r-1, etc. (B r,a , B r,b , B r,d , B r-1,a , B r-1,b …).

[0147] Step 1004, perform de-duplication sorting processing based on the transaction information in the transaction list contained in the transaction block and the historical transaction block, obtain a total transaction list with a unique sorting standard, and submit the total transaction list as a transaction block to the blockchain system.

[0148] During implementation, the consensus protocol master node performs de-duplication and sorting based on the transaction summary information corresponding to the transaction block and the historical transaction block, that is, deletes the duplicate transaction information between the transaction lists, arranges them in the preset order of the transaction information, obtains a uniquely sorted and marked total transaction list, and submits the total transaction list as the transaction block of this round to the blockchain system.

[0149] It should be understood that although Figure 2 , Figures 4 to 10 The steps in the flowchart are shown in sequence as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Moreover, Figure 2 , Figures 4 to 10 At least part of the steps may include multiple steps or multiple stages. These steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed in turn or alternately with other steps or at least part of the steps or stages in other steps.

[0150] In one embodiment, Fig.12 As shown, a blockchain transaction pool implementation device 1200 is provided, including: a first receiving module 1210, a broadcasting module 1220, a second receiving module 1230 and a generating module 1240, wherein:

[0151] The first receiving module 1210 is used to receive transaction data and generate a transaction block including summary information and transaction attribute information of the transaction data;

[0152] A broadcast module 1220, used to broadcast the transaction block to other consensus nodes in the blockchain system, instructing other consensus nodes to verify the transaction block;

[0153] The second receiving module 1230 is used to receive transaction confirmation information fed back by other consensus nodes and generate an arbitration certificate containing transaction block confirmation information;

[0154] The generation module 1240 is used to broadcast the arbitration certificate to other consensus nodes and receive arbitration certificates generated by other consensus nodes in the transaction validity proof process of this round, until the number of received arbitration certificates reaches a preset number, it is determined that the transaction validity proof of this round in the blockchain system is completed, and the generation process of the next round of transaction blocks is triggered.

[0155] By adopting the device 1200, any consensus node in the blockchain system can create a transaction block and initiate a transaction validity proof proposal. After the proposal, the validity proof of the transaction data is achieved by generating an arbitration certificate containing the signature information of other consensus nodes, thereby reducing the pressure on node bandwidth and memory consumption in the blockchain system and improving transaction consensus efficiency.

[0156] In one embodiment, the first receiving module 1210 is specifically used to receive transaction data sent from the client, and store the transaction data in batches into a local transaction pool;

[0157] Read the pre-stored transaction attribute information of the current transaction round and the transaction summary of the transaction data in the local transaction pool, and generate a transaction block containing the transaction summary and transaction attribute information.

[0158] In one embodiment, the second receiving module 1230 is specifically used to receive transaction confirmation information, each transaction confirmation information is a signature message fed back by other consensus nodes after the transaction block is verified;

[0159] When the number of received transaction confirmation information meets a preset number threshold, an arbitration certificate including the preset number of transaction confirmation information is generated.

[0160] In one of the embodiments, the preset number threshold is determined by the total number of consensus nodes and the number of malicious nodes included in the blockchain system according to a preset attribute relationship; a malicious node is a node in the consensus node that has malicious attack behavior.

[0161] In one embodiment, the apparatus 1200 further includes:

[0162] A receiving module, used to receive a transaction block to be verified sent by other transaction block creation nodes; wherein other transaction block creation nodes are other consensus nodes that create transaction blocks in the blockchain system;

[0163] A determination module, used to determine the validity of a transaction block according to a preset validity verification rule;

[0164] The verification module is used to read the transaction information contained in the transaction summary list in the transaction block if the transaction block is valid, obtain the transaction data corresponding to the transaction information in the local transaction pool, and verify the transaction data;

[0165] The feedback module is used to feedback transaction confirmation information to other transaction block creation nodes when the transaction data verification is passed. The transaction confirmation information is a signed message.

[0166] In one embodiment, the determination module is specifically used to read the transaction attribute information in the transaction block, and determine the consistency between the transaction round number in the transaction attribute information and the current transaction round;

[0167] Identify whether the transaction attribute information carries the signature information of other transaction block creation nodes and the arbitration certificate of the previous round;

[0168] Determine whether the transaction block is the first transaction block of the current transaction round;

[0169] If the transaction round number is consistent with the current transaction round, the transaction attribute information carries the signature information of other transaction block creation nodes and the arbitration certificate of the previous round, and the transaction block is the first transaction block of the current transaction round, then the transaction block is determined to be valid.

[0170] In one embodiment, the apparatus 1200 further includes:

[0171] An identification module, used to identify transaction data corresponding to the transaction information in a local transaction pool according to the transaction information;

[0172] A determination module, configured to determine the transaction data as missing transaction data if the transaction data corresponding to the transaction information is not identified in the local transaction pool;

[0173] The sending module is used to send missing transaction data requests to other transaction block creation nodes or other verification nodes to obtain missing transaction data from the transaction pools of other transaction block creation nodes or other verification nodes. Among them, other verification nodes are consensus nodes that have verified the transaction blocks.

[0174] In one embodiment, the apparatus 1200 further includes:

[0175] An acquisition module is used to acquire a target arbitration certificate, where the target arbitration certificate is the arbitration certificate with the highest transaction round number stored locally;

[0176] A broadcast module, used to broadcast the target arbitration certificate to other consensus nodes, instructing other consensus nodes to verify the target arbitration certificate;

[0177] The submission module is used to generate a transaction block from the transaction list in all transaction blocks corresponding to the target arbitration certificate if the arbitration certificate confirmation information fed back by a preset number of other consensus nodes is received, and submit the transaction block to the blockchain system.

[0178] In one embodiment, the generating submission module is specifically used to obtain the transaction reference relationship contained in the arbitration certificate, identify the transaction block in the reference relationship and the historical transaction block in the historical validity proof process corresponding to the transaction block;

[0179] According to the transaction information in the transaction list contained in the transaction block and the historical transaction block, de-duplicate sorting is performed to obtain a total transaction list with a unique sorting standard, and the total transaction list is submitted to the blockchain system as a transaction block.

[0180] For the specific definition of the transaction data validity proof device, please refer to the definition of the transaction data validity proof method above, which will not be repeated here. Each module in the above transaction data validity proof device can be implemented in whole or in part by software, hardware and their combination. The above modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0181] In one embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as follows: Fig.13 As shown. The computer device includes a processor, a memory, a communication interface, a display screen and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be achieved through WIFI, an operator network, NFC (near field communication) or other technologies. When the computer program is executed by the processor, a method for proving the validity of transaction data is implemented. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a key, trackball or touchpad set on the computer device housing, or an external keyboard, touchpad or mouse, etc.

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

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

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

[0185] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory or optical memory, etc. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

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

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

Claims

1. A method for implementing a blockchain transaction pool, characterized in that: The method is applied to any consensus node of a blockchain system, and the method includes: Receiving transaction data, and generating a transaction block including summary information and transaction attribute information of the transaction data; Broadcasting the transaction block to other consensus nodes in the blockchain system, and instructing the other consensus nodes to verify the transaction block; Receive the transaction block confirmation information fed back by the other consensus nodes, and generate an arbitration certificate containing the transaction block confirmation information; Broadcasting the arbitration certificate to the other consensus nodes, and receiving arbitration certificates generated by the other consensus nodes in the transaction process of this round, until the number of the received arbitration certificates reaches a preset number, determining that the validity proof of this round of transactions in the blockchain system is completed, triggering the generation process of the next round of transaction blocks; When the consensus node is determined to be a consensus protocol master node in the blockchain system, the method further includes: Obtaining a target arbitration certificate, where the target arbitration certificate is the arbitration certificate with the highest transaction round number stored locally; Broadcasting the target arbitration certificate to the other consensus nodes, and instructing the other consensus nodes to verify the target arbitration certificate; If confirmation information of arbitration certificates fed back by a preset number of the other consensus nodes is received, a transaction list in all transaction blocks corresponding to the target arbitration certificate is generated into a transaction block, and the transaction block is submitted to the blockchain system; The step of generating a transaction block from the transaction lists in all transaction blocks corresponding to the target arbitration certificate, and submitting the transaction block to the blockchain system includes: Obtaining the transaction reference relationship contained in the arbitration certificate, identifying the transaction block in the reference relationship and the historical transaction block in the historical validity proof process corresponding to the transaction block; According to the transaction information in the transaction list contained in the transaction block and the historical transaction block, de-duplicate sorting is performed to obtain a total transaction list with a unique sorting standard, and the total transaction list is submitted to the blockchain system as a transaction block.

2. The method according to claim 1, characterized in that The receiving of transaction data and generating a transaction block including summary information and transaction attribute information of the transaction data comprises: Receive transaction data sent from the client, and store the transaction data in batches into a local transaction pool; The pre-stored transaction attribute information of the current transaction round and the transaction summary of the transaction data in the local transaction pool are read to generate a transaction block including the transaction summary and the transaction attribute information.

3. The method according to claim 1, characterized in that The receiving the transaction block confirmation information fed back by the other consensus nodes and generating an arbitration certificate containing the transaction block confirmation information includes: Receive transaction confirmation information, each of which is a signature message fed back by the other consensus nodes after the transaction block is verified; When the number of the received transaction confirmation information meets a preset number threshold, an arbitration certificate including the preset number of the transaction confirmation information is generated.

4. The method according to claim 1, characterized in that The preset number threshold is determined by the total number of consensus nodes and the number of malicious nodes included in the blockchain system according to a preset attribute relationship; the malicious node is a node in the consensus node that has malicious attack behavior.

5. The method according to claim 1, characterized in that: The method further comprises: Receiving a transaction block to be verified sent by other transaction block creation nodes; the other transaction block creation nodes are other consensus nodes that create transaction blocks in the blockchain system; Determining the validity of the transaction block according to a preset validity verification rule; If the transaction block is valid, read the transaction information contained in the transaction summary list in the transaction block, obtain the transaction data corresponding to the transaction information in the local transaction pool, and verify the transaction data; When the transaction data is verified, transaction confirmation information is fed back to the other transaction block creation nodes, and the transaction confirmation information is a signed message.

6. The method according to claim 5, characterized in that Determining the validity of the transaction block according to a preset validity verification rule includes: Reading the transaction attribute information in the transaction block, and determining the consistency between the transaction round number in the transaction attribute information and the current transaction round; Identify whether the transaction attribute information carries the signature information of the node creating the other transaction blocks and the arbitration certificate of the previous round; Determining whether the transaction block is the first transaction block of the current transaction round; If the transaction round number is consistent with the current transaction round, the transaction attribute information carries the signature information of the node that created the other transaction blocks and the arbitration certificate of the previous round, and the transaction block is the first transaction block of the current transaction round, then the transaction block is determined to be valid.

7. The method according to claim 5, characterized in that Before acquiring the transaction data corresponding to the transaction information in the local transaction pool, the method further includes: According to the transaction information, identifying transaction data corresponding to the transaction information in a local transaction pool; If the transaction data corresponding to the transaction information is not identified in the local transaction pool, the transaction data is determined as missing transaction data; Send a missing transaction data request to the other transaction block creation node or other verification node to obtain the missing transaction data from the transaction pool of the other transaction block creation node or the other verification node; the other verification node is a consensus node that has verified the transaction block.

8. A blockchain transaction pool implementation device, characterized in that: The device is applied to any consensus node of the blockchain system, and the device includes: A first receiving module, configured to receive transaction data and generate a transaction block including summary information and transaction attribute information of the transaction data; A broadcast module, used to broadcast the transaction block to other consensus nodes in the blockchain system, and instruct the other consensus nodes to verify the transaction block; A second receiving module is used to receive the transaction confirmation information fed back by the other consensus nodes, and generate an arbitration certificate containing the transaction block confirmation information; A generation module, used to broadcast the arbitration certificate to the other consensus nodes, and receive arbitration certificates generated by the other consensus nodes in the transaction validity proof process of this round, until the number of received arbitration certificates reaches a preset number, determine that the transaction validity proof of this round in the blockchain system is completed, and trigger the generation process of the next round of transaction blocks; When the consensus node is determined to be a consensus protocol master node in the blockchain system, the device further includes: An acquisition module, used to acquire a target arbitration certificate, where the target arbitration certificate is the arbitration certificate with the highest transaction round number stored locally; A broadcast module, used to broadcast the target arbitration certificate to the other consensus nodes, and instruct the other consensus nodes to verify the target arbitration certificate; A generation submission module is used to generate a transaction block from the transaction list in all transaction blocks corresponding to the target arbitration certificate if confirmation information of the arbitration certificate fed back by a preset number of the other consensus nodes is received, and submit the transaction block to the blockchain system; The generation submission module is specifically used to obtain the transaction reference relationship contained in the arbitration certificate, identify the transaction block in the reference relationship and the historical transaction block in the historical validity proof process corresponding to the transaction block; According to the transaction information in the transaction list contained in the transaction block and the historical transaction block, de-duplicate sorting is performed to obtain a total transaction list with a unique sorting standard, and the total transaction list is submitted to the blockchain system as a transaction block.

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

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

Images