Transaction processing method and device, electronic equipment and storage medium

Abstract

The invention discloses a transaction processing method and device, electronic equipment and a storage medium. The embodiment of the invention relates to the technical field of block chains and the like. The method comprises the following steps: acquiring at least one to-be-processed data group from a transaction pool of a node; generating a target transaction block according to the transaction related data in the at least one data group and the signature information corresponding to the sub-transaction pool from which each data group is sourced; performing consensus on the target transaction block to obtain a consensus result; and if the consensus result indicates that the target transaction block passes the consensus, carrying out uplink on the target transaction block. According to the application, the storage of repeated signature information is reduced, so that the storage space occupied by data in the transaction pool is reduced, the transaction storage amount in the transaction pool can be increased, and the problems of transaction delay and congestion caused by the fact that the transaction pool reaches the upper capacity limit are effectively reduced; therefore, the processing capability of batch transactions and the overall performance of the block chain can be improved.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and more specifically, to a transaction processing method, device, electronic device and storage medium. Background Art

[0002] In blockchain technology, the transaction pool of the nodes in the blockchain system will receive transactions sent by the client and broadcast the valid transactions to other nodes in the blockchain system. Other nodes will perform consensus processing based on the received valid transactions to obtain consensus results. Finally, each node in the blockchain system will determine whether the valid transactions need to be processed on the chain based on the consensus results.

[0003] When a large number of transactions flood into the blockchain system, the transaction pool of the node may quickly accumulate a large amount of transaction data to be processed, causing the transaction pool to reach its capacity limit, thereby causing transaction delays and congestion problems. Summary of the invention

[0004] In view of this, the embodiments of the present application propose a transaction processing method, device, electronic device and storage medium.

[0005] In a first aspect, an embodiment of the present application provides a transaction processing method for a node in a blockchain system, wherein each sub-transaction pool of the node is used to temporarily store transaction-related data of transactions corresponding to signature information corresponding to the sub-transaction pool; a sub-transaction pool corresponds one-to-one to a signature information; transaction-related data of a transaction refers to other data related to the transaction in the transaction data of the transaction except the signature information; the method comprises: obtaining at least one data group to be processed from the transaction pool of the node; the transaction-related data in a data group originates from a sub-transaction pool in the transaction pool of the node; generating a target transaction block according to the transaction-related data in at least one data group and the signature information corresponding to the sub-transaction pool from which each data group originates; wherein the target transaction block comprises at least one packaging result, and a packaging result comprises multiple transaction-related data from the same sub-transaction pool and the signature information corresponding to the sub-transaction pool; consensus is reached on the target transaction block to obtain a consensus result; if the consensus result indicates that the target transaction block passes the consensus, the target transaction block is put on the chain.

[0006] In a second aspect, an embodiment of the present application provides a transaction processing device, which is used for a node in a blockchain system, and each sub-transaction pool of the node is used to temporarily store transaction-related data of transactions corresponding to signature information corresponding to the sub-transaction pool; a sub-transaction pool corresponds one-to-one to a signature information; the transaction-related data of a transaction refers to other data related to the transaction in the transaction data of the transaction except the signature information; the device includes: an acquisition module, which is used to acquire at least one data group to be processed from the transaction pool of the node; the transaction-related data in a data group comes from a sub-transaction pool in the transaction pool of the node; a block generation module, which is used to generate a target transaction block according to the transaction-related data in at least one data group and the signature information corresponding to the sub-transaction pool from which each data group comes; wherein the target transaction block includes at least one packaging result, and a packaging result includes multiple transaction-related data from the same sub-transaction pool and the signature information corresponding to the sub-transaction pool; a consensus module, which is used to reach a consensus on the target transaction block and obtain a consensus result; and a chain module, which is used to chain the target transaction block if the consensus result indicates that the target transaction block passes the consensus.

[0007] Optionally, the device also includes a storage module, which is used to receive target transaction data of the target transaction, the target transaction data including target transaction-related data corresponding to the target transaction and target signature information; temporarily storing the target transaction-related data in a target sub-transaction pool in the transaction pool of the node; the target sub-transaction pool refers to the sub-transaction pool corresponding to the target signature information.

[0008] Optionally, the block generation module is further used to perform transaction pre-execution on each transaction-related data in at least one data group, and add the transaction result obtained by the transaction pre-execution to the corresponding transaction-related data; package the transaction-related data in each data group in the at least one data group in batches with the signature information corresponding to the sub-transaction pool from which the data group is derived, to obtain at least one packaging result; and obtain the target transaction block based on the at least one packaging result.

[0009] Optionally, the acquisition module is also used to acquire at least one data group to be processed from the transaction pool of the node if the block generation condition is met; the block generation condition includes at least one of the following: the number of transaction-related data in any sub-transaction pool in the node reaches a first quantity threshold, the interval between the signing times of the digital signatures of the transactions corresponding to the two latest created transaction-related data in any sub-transaction pool in the node reaches a first duration threshold, the interval between the creation time of the previous block reaches a second duration threshold, and the total number of transaction-related data in all sub-transaction pools of the node reaches a second quantity threshold.

[0010] Optionally, the acquisition module is further used to, if there is a first sub-transaction pool in the node whose number of transaction-related data reaches a first quantity threshold, acquire and aggregate multiple transaction-related data from the first sub-transaction pool to obtain a data group corresponding to the first sub-transaction pool; if there is a second sub-transaction pool in the node whose interval between the signing times of the digital signatures of the transactions corresponding to the two latest created transaction-related data reaches a first duration threshold, acquire and aggregate multiple transaction-related data from the second sub-transaction pool to obtain a data group corresponding to the second sub-transaction pool; if the interval between the creation time of the previous block reaches a second duration threshold, acquire multiple first transaction-related data from at least one sub-transaction pool of the node, and aggregate the first transaction-related data from the same sub-transaction pool to obtain a data group corresponding to the sub-transaction pool; if the total number of transaction-related data in all sub-transaction pools of the node reaches a second quantity threshold, acquire multiple second transaction-related data from at least one sub-transaction pool of the node, and aggregate the second transaction-related data from the same sub-transaction pool to obtain a data group corresponding to the sub-transaction pool.

[0011] Optionally, the storage module is also used to verify the target transaction data; if the target transaction data passes the verification, the target transaction related data is temporarily stored in the cache queue of the target sub-transaction pool of the node.

[0012] Optionally, the storage module is further configured to delete transaction-related data in a corresponding data group from a sub-transaction pool corresponding to each data group in the at least one data group.

[0013] Optionally, the consensus module is also used to broadcast a consensus verification request including a target transaction block to other nodes in the blockchain system except the node; receive verification results returned by other nodes in the blockchain system except the node in response to the consensus verification request; and determine the consensus result of the target transaction block based on the verification results returned by other nodes.

[0014] Optionally, the device also includes a verification module, which is used to receive a consensus request including a block to be verified sent by a consensus initiating node in the blockchain system; the block to be verified is generated based on at least one data group to be verified obtained from a sub-transaction pool included in the transaction pool of the consensus initiating node and the signature information corresponding to the sub-transaction pool from which each data group to be verified comes from; the transaction-related data in a data group to be verified comes from a sub-transaction pool in the transaction pool of the consensus initiating node; the block to be verified includes at least one packaged result to be verified, and a packaged result to be verified includes multiple transaction-related data from the same sub-transaction pool and the signature information corresponding to the sub-transaction pool; transaction verification is performed on each transaction-related data in the block to be verified to obtain a transaction verification result of each transaction-related data in the block to be verified; the verification result of the block to be verified is determined based on the transaction verification results of all transaction-related data in the block to be verified; and the verification result of the block to be verified is sent to the consensus initiating node.

[0015] Optionally, the verification module is also used to, for each transaction-related data in the block to be verified, if the transaction-related data is included in the node's sub-transaction pool, compare the transaction hash in the transaction-related data in the block to be verified with the transaction hash in the transaction-related data in the node's sub-transaction pool to determine a transaction verification result of the transaction-related data; or, if the transaction-related data is not included in the node's sub-transaction pool, perform transaction verification based on the transaction-related data in the block to be verified and the signature information of the transaction corresponding to the transaction-related data to obtain a transaction verification result of the transaction-related data.

[0016] Optionally, the verification module is also used to perform verification based on the transaction-related data in the block to be verified and multiple signatures in the signature information of the transaction corresponding to the transaction-related data, if the transaction-related data is not included in the node's sub-transaction pool, and the number of signatures in the signature information of the transaction corresponding to the transaction-related data reaches the required number of signatures of the transaction corresponding to the transaction-related data, to obtain the transaction verification result of the transaction-related data.

[0017] In a third aspect, an embodiment of the present application provides an electronic device, including a processor and a memory; the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the above method is implemented.

[0018] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium on which computer-readable instructions are stored. When the computer-readable instructions are executed by a processor, the above-mentioned method is implemented.

[0019] In a fifth aspect, an embodiment of the present application provides a computer program product or a computer program including computer instructions, which implement the above method when executed by a processor.

[0020] A transaction processing method, device, electronic device and storage medium provided by an embodiment of the present application. In the present application, the transaction pool of a node of a blockchain system includes at least one sub-transaction pool, each sub-transaction pool is used to temporarily store transaction-related data of transactions corresponding to signature information corresponding to the sub-transaction pool, one sub-transaction pool corresponds one to one signature information, and the transaction-related data of a transaction refers to other data related to the transaction in the transaction data of the transaction except the signature information. Therefore, for transactions with the same signature information, the sub-transaction pool only stores one signature information and the transaction-related data of each transaction that shares the signature information, and does not need to store the same signature information multiple times, reducing the storage of duplicate signature information, thereby reducing the storage space occupied by data in the transaction pool, and can increase the transaction storage capacity in the transaction pool, effectively reducing the transaction delays and congestion problems caused by the transaction pool reaching the capacity limit, thereby improving the processing capacity of batch transactions and the overall performance of the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0022] Figure 1 A schematic diagram of the architecture of a blockchain system applicable to an embodiment of the present application is shown;

[0023] Figure 2 A schematic diagram of a data structure of a blockchain applicable to an embodiment of the present application is shown;

[0024] Figure 3 A schematic diagram of a new block generation process applicable to an embodiment of the present application is shown;

[0025] Figure 4 A flow chart of a transaction processing method proposed in one embodiment of the present application is shown;

[0026] Figure 5 A schematic diagram of a transaction pool in an embodiment of the present application is shown;

[0027] Figure 6 A schematic diagram showing a process of generating a target transaction block in an embodiment of the present application is shown;

[0028] Figure 7 A flow chart showing a process of generating a target transaction block in an embodiment of the present application is shown;

[0029] Figure 8A schematic diagram showing a consensus process of a target transaction block in an embodiment of the present application is shown;

[0030] Fig. 9 Shows Figure 4 The steps after step S140 of the corresponding embodiment are a flowchart of an embodiment;

[0031] Fig.10 A schematic diagram of a target transaction block in an embodiment of the present application is shown;

[0032] Fig.11 A block diagram of a transaction processing device proposed in one embodiment of the present application is shown;

[0033] Fig.12 A structural block diagram of an electronic device for executing a transaction processing method according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0034] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. According to the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0035] In the following description, the terms "first\second" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0036] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0037] It should be noted that the "multiple" mentioned in this article refers to two or more. "And / or" describes the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the associated objects before and after are in an "or" relationship.

[0038] The present application discloses a transaction processing method, device, electronic device and storage medium, which relate to blockchain technology.

[0039] The explanations of the non-common abbreviations or self-defined terms in the embodiments of the present application are as follows:

[0040] Transaction pool module: The function of the transaction pool module is to receive transactions sent by other consensus nodes (also referred to as nodes) and transactions sent directly by the client. In the transaction pool module, the transactions sent by the client will be broadcast to other consensus nodes. The purpose of broadcasting transactions is to ensure the consistency of transactions between consensus nodes as much as possible, so as to facilitate the rapid verification of the validity of blocks and transactions in the subsequent consensus process.

[0041] Core engine module: The core scheduling module in the consensus node. This module mainly plays the role of central scheduling. When the consensus node is the master node, the consensus engine module of the master node will notify the core engine module to construct blocks and execute transactions, and finally give the constructed blocks to the consensus engine module. Then the consensus engine module will construct proposals based on the blocks and broadcast the proposals to other slave nodes. After the slave node receives the proposal and verifies its validity, it will let its core engine module verify the validity of the block and execute the transaction. If the transaction execution result of the slave node is consistent with that of the master node, the block is considered valid.

[0042] Transaction structure data: usually includes transaction identification (transaction ID) for viewing and referencing in the blockchain, transaction fees for incentivizing miners to verify and package transactions, timestamps for recording transaction creation, and signatures for verifying the legitimacy of transactions and preventing tampering. It may also include other custom fields for specific functions and parameter settings, such as contract address, function name, parameter value, etc. The naming and structure of specific transaction fields may vary depending on different blockchain platforms, protocols, and application scenarios. Developers should refer to relevant documents and specifications to obtain accurate transaction structure information.

[0043] See also Figure 1 The blockchain system shown, the blockchain system 100 refers to a blockchain network system for sharing data between nodes, and the blockchain system 100 may include multiple nodes 101. Each node 101 can receive input information when performing normal work, and maintain the shared data in the blockchain based on the received input information. In order to ensure the information intercommunication within the blockchain, there can be an information connection between each node 101 in the blockchain, and information can be transmitted between the nodes 101 through the above information connection. For example, when any node 101 in the blockchain receives input information, other nodes 101 in the blockchain obtain the input information according to the consensus algorithm, and store the input information as data in the shared data, so that the data stored on all nodes 101 in the blockchain are consistent.

[0044] Each node 101 in the blockchain has a corresponding node identifier, and each node 101 in the blockchain can store the node identifiers of other nodes 101 in the blockchain, so that the generated blocks can be broadcast to other nodes 101 in the blockchain according to the node identifiers of other nodes 101. Each node 101 can maintain a node identifier list as shown in the following table, and store the node name and node identifier in the node identifier list accordingly. Among them, the node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address and any other information that can be used to identify the node. Table 1 only uses the IP address as an example for explanation.

[0045] Node Name Node ID Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.789.258

[0046] Each node 101 in the blockchain system stores an identical blockchain. The blockchain consists of multiple blocks. Figure 2 The blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the input information characteristic value, version number, timestamp and difficulty value, and the block body stores the input information; the next block of the genesis block takes the genesis block as the parent block, and the next block also includes a block header and a block body. The block header stores the input information characteristic value of the current block, the block header characteristic value, version number, timestamp and difficulty value of the parent block, and so on, so that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block.

[0047] When generating each block in the blockchain, see Figure 3 , when receiving the input information, the node 101 where the blockchain is located verifies the input information. After completing the verification, the input information is stored in the memory pool, and the hash tree used to record the input information is updated; then, the update timestamp is updated to the time when the input information is received, and different random numbers are tried, and the eigenvalue calculation is performed multiple times, so that the calculated eigenvalue can satisfy the following formula:

[0048] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x))<TARGET

[0049] Among them, SHA256 is the eigenvalue algorithm used to calculate the eigenvalue; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header eigenvalue of the parent block of the current block; merkle_root is the eigenvalue of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value within a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the eigenvalue threshold, which can be determined based on nbits.

[0050] In this way, when the random number that satisfies the above formula is calculated, the information can be stored accordingly, the block header and the block body can be generated, and the current block can be obtained. Subsequently, the node 101 where the blockchain is located sends the newly generated block to other nodes in the blockchain where it is located according to the node identifiers of other nodes in the blockchain, and the other nodes verify the newly generated block and add the newly generated block to the blockchain stored in it after the verification is completed.

[0051] See also Figure 4 , Figure 4 A flowchart of a transaction processing method proposed in an embodiment of the present application is shown. The method may be applied to a node in a blockchain system, and the node may be the aforementioned node 101. The method includes:

[0052] S110. Obtain at least one data group to be processed from the transaction pool of the node.

[0053] Among them, the transaction-related data in a data group comes from a sub-transaction pool in the transaction pool of the node; each sub-transaction pool of the node is used to temporarily store the transaction-related data of the transaction corresponding to the signature information corresponding to the sub-transaction pool; a sub-transaction pool corresponds to a signature information one-to-one; the transaction-related data of a transaction refers to other data related to the transaction in the transaction data of the transaction except the signature information. For example, the transaction-related data may include information such as the transaction identifier, transaction parameters, transaction fees, and timestamp (usually the time when the transaction was created) corresponding to the transaction. The signature information refers to the signature (digital signature) of the transaction. It can be understood that for a transaction, the signature required by the transaction can be one or more. In the case where the signature required by the transaction is one, the signature information of the transaction includes one signature; in the case where the signature required by the transaction is multiple, the signature information of the transaction includes multiple signatures.

[0054] A transaction pool is provided on the node, and the transaction pool includes at least one sub-transaction pool. Each sub-transaction pool may be provided with a cache queue (also called a queue). The transaction-related data of the transaction corresponding to the signature information corresponding to each sub-transaction pool is temporarily stored in the sub-transaction pool, which can also be understood as being temporarily stored in the cache queue of the sub-transaction pool, so that the transaction-related data first stored in the future can be processed first. At least one data group to be processed can be obtained from the cache queue corresponding to each sub-transaction pool included in the transaction pool of the node. The sub-transaction pool corresponds to the signature information one by one, that is, the signature information of the transaction corresponding to different transaction-related data stored in a sub-transaction pool is the same. The signature information corresponding to the sub-transaction pool can be used to distinguish different sub-transaction pools. For example, the signature information can be used as the transaction pool identifier of the sub-transaction pool to distinguish different sub-transaction pools, and at the same time, the sub-transaction pool can also realize the storage of signature information by using the signature information as its own transaction pool identifier.

[0055] like Figure 5 As shown, the transaction pool includes sub-transaction pool jc1 and sub-transaction pool jc2. Sub-transaction pool jc1 uses signature information q1 as its own sub-transaction pool identifier, and sub-transaction pool jc2 uses signature information q2 as its own sub-transaction pool identifier. Sub-transaction pool jc1 temporarily stores transaction-related data g1 corresponding to transaction 1 with signature information q1, transaction-related data g2 corresponding to transaction 2, and transaction-related data g3 corresponding to transaction 3. Sub-transaction pool jc2 temporarily stores transaction-related data g4 corresponding to transaction 4 with signature information q2, and transaction-related data g5 corresponding to transaction 5.

[0056] The transaction data of a transaction is also the transaction structure data mentioned above. The transaction data of a transaction may include the signature information of the transaction and the transaction-related data corresponding to the transaction. It is worth mentioning that the transactions involved in this application do not only refer to transactions in a business context. In view of the conventional use of the term "transaction" in blockchain technology, the embodiments of the present invention follow this practice. For example, a transaction may include a deployment transaction and an invoke transaction. The deployment transaction is used to deploy the smart contract to the node of the blockchain system and prepare it to be invoked; the invoke transaction is used to query the status database in the ledger (i.e., read operation) or update operation (i.e., write operation, including addition, deletion and modification).

[0057] At least one node in the blockchain system can be connected to the client for communication. The client can send target transaction data of a target transaction to be processed to the node in the blockchain system. The target transaction data includes target transaction-related data and target signature information corresponding to the target transaction. The node receives the target transaction data of the target transaction. The target transaction-related data is obtained from the target transaction data, and the target transaction-related data is temporarily stored in a target sub-transaction pool in the transaction pool of the node. The target sub-transaction pool refers to a sub-transaction pool corresponding to the target signature information.

[0058] If the target sub-transaction pool corresponding to the target signature information already exists in the node, the target transaction related data will be directly temporarily stored in the target sub-transaction pool in the node's transaction pool. If the target sub-transaction pool corresponding to the target signature information does not exist in the node, a new sub-transaction pool can be created, and the corresponding relationship between the target signature information and the new sub-transaction pool can be established, and the target transaction related data will be temporarily stored in the target sub-transaction pool in the node's transaction pool.

[0059] In the present application, after receiving the target transaction data of the target transaction to be processed, the node in the blockchain system does not directly temporarily store the target transaction data in the transaction pool of the node. On the basis of dividing the transaction pool into sub-transaction pools according to the signature information, other data (i.e., target transaction-related data) other than the signature information (i.e., target signature information) of the target transaction is obtained from the target transaction data, and the target transaction-related data is temporarily stored in the target sub-transaction pool corresponding to the target signature information of the node. In this way, in each sub-transaction pool, for multiple transactions with the same signature information, only one signature information needs to be stored, and the same signature information does not need to be repeatedly stored. In this way, compared with the related art in which the full amount of transaction data (i.e., including signature information and other transaction-related data other than signature information) is stored in the transaction pool for each transaction, the signature information is separated from the transaction-related data, and multiple transactions with the same signature information store one signature information. In this way, the storage space occupied in the transaction pool can be reduced, and when the number of transactions that need to be stored in the transaction pool is large, the storage pressure of the transaction pool can be effectively alleviated.

[0060] As mentioned above, each sub-transaction pool corresponds to its own cache queue, and the target transaction-related data can be temporarily stored in the cache queue corresponding to the target sub-transaction pool in the node's transaction pool.

[0061] Optionally, each sub-transaction pool corresponds to its own cache queue; before temporarily storing the target transaction related data in the target sub-transaction pool in the transaction pool of the node, the method also includes: verifying the target transaction data; temporarily storing the target transaction related data in the target sub-transaction pool in the transaction pool of the node, including: if the target transaction data passes the verification, temporarily storing the target transaction related data in the cache queue corresponding to the target sub-transaction pool in the transaction pool of the node.

[0062] Verification of transaction data may include transaction validity screening and anti-duplicate checks, wherein validity screening may verify whether the transaction identifier of the transaction complies with specifications, whether the timestamp of the transaction is expired, and whether the signature information of the transaction is valid; anti-duplicate screening refers to determining whether a transaction is a duplicate transaction, and whether the transaction identifier of the transaction is the same as the transaction identifier of the previous transaction may be used to determine whether the transaction is a duplicate transaction: if the transaction identifier of the transaction is different from the transaction identifier of the previous transaction, it is determined that it is not a duplicate transaction; if the transaction identifier of the transaction is the same as the transaction identifier of a previous transaction, it is determined that it is a duplicate transaction.

[0063] The transaction identifiers of transactions in different transaction scenarios may correspond to their own specifications. Users may select the corresponding specifications based on their needs. This application does not limit this. Whether the transaction time is expired may refer to whether the timestamp of the transaction matches the time of verifying the transaction (matching means that the time difference is within a preset range, for example, the preset range may refer to one day, one hour or one minute, etc.), and whether the signature information of the transaction is valid may refer to whether the signature information of the transaction is successfully verified.

[0064] Among them, the sender of the transaction can use his own private key to sign the transaction and obtain the signature information of the transaction. The node verifies the signature information based on the public key.

[0065] If the validity screening is valid and the anti-duplicate check is not a duplicate transaction, the target transaction data is determined to have passed the verification, otherwise the target transaction data has not passed the verification. Among them, the validity screening is valid, which means that the transaction identifier of the transaction complies with the specification, the timestamp of the transaction has not expired, and the signature information of the transaction is valid. When the target transaction data passes the verification, the target transaction related data is temporarily stored in the cache queue corresponding to the target sub-transaction pool in the transaction pool of the node. When the target transaction data fails to pass the verification, the target transaction data is directly discarded.

[0066] As an implementation method, S110 may include: if a block generation condition is met, obtaining at least one data group to be processed from the transaction pool of the node; wherein the block generation condition includes at least one of the following: the number of transaction-related data in any sub-transaction pool in the node reaches a first quantity threshold, the interval between the signing times of the digital signatures of the transactions corresponding to the two last created transaction-related data in any sub-transaction pool in the node reaches a first duration threshold, the interval between the creation time of the previous block reaches a second duration threshold, and the total number of transaction-related data in each sub-transaction pool of the node reaches a second quantity threshold.

[0067] In the case where the block generation condition includes that the number of transaction-related data in any sub-transaction pool in the node reaches a first quantity threshold, if there is a first sub-transaction pool in the node whose number of transaction-related data reaches the first quantity threshold, multiple transaction-related data are obtained and aggregated from the first sub-transaction pool to obtain a data group corresponding to the first sub-transaction pool. In this case, the number of at least one data group to be processed is one, that is, a data group formed by multiple transaction-related data obtained from the first sub-transaction pool. The first quantity threshold can be set based on the scenario, and this application does not limit it.

[0068] For the sake of distinction, a sub-transaction pool in which the amount of transaction-related data in a node reaches a first quantity threshold is called a first sub-transaction pool.

[0069] Generally speaking, the capacity of a block is limited, and the number of transaction-related data that can be contained in a generated block does not exceed the upper limit threshold of the block (the upper limit threshold of the block can be determined based on the scenario), and the upper limit threshold of the block is the maximum number of transactions that can be packaged in a block. After determining the first sub-transaction pool, multiple transaction-related data with a previous transaction time can be obtained from the cache queue of the first sub-transaction pool. Specifically, if the total number of transaction-related data in the cache queue of the first sub-transaction pool is less than the upper limit threshold of the block, all transaction-related data in the cache queue of the first sub-transaction pool can be used as a data group; if the total number of transaction-related data in the cache queue of the first sub-transaction pool is not less than the upper limit threshold of the block, the number of transaction-related data indicated by the upper limit threshold of the block is obtained from the cache queue of the first sub-transaction pool as a data group. Thus, the number of transaction-related data packaged into a block does not exceed the upper limit threshold of the block. If there is a second sub-transaction pool in the node, in which the interval between the signing times of the digital signatures of the transactions corresponding to the two latest created transaction-related data reaches the first duration threshold, multiple transaction-related data are obtained and summarized from the second sub-transaction pool to obtain the data group corresponding to the second sub-transaction pool. Among them, the first duration threshold can be set based on the scene, and this application does not limit it.

[0070] If the interval between the creation time of the previous block reaches the second time threshold, multiple first transaction related data are obtained from at least one sub-transaction pool of the node, and the first transaction related data from the same sub-transaction pool are aggregated to obtain the data group corresponding to the sub-transaction pool. The second time threshold can be set based on the scenario, which is not limited in this application.

[0071] If the interval between the creation time of the previous block reaches the second time threshold, and the number of transaction-related data in all sub-trading pools exceeds the block upper limit threshold, the number of transaction-related data indicated by the block upper limit threshold can be obtained from the cache queues of all sub-trading pools in the order of the time when the transaction-related data arrives at the node according to the first-come-first-served principle, as multiple first transaction-related data; if the interval between the creation time of the previous block reaches the second time threshold, and the number of transaction-related data in all sub-trading pools does not exceed the block upper limit threshold, all transaction-related data in the cache queues of all sub-trading pools can be obtained as multiple first transaction-related data; then, the first transaction-related data in the cache queues from the same sub-trading pool are aggregated to obtain the data group corresponding to the sub-trading pool; one sub-trading pool corresponds to one data group. It can be understood that in this case, the data group determined for generating a block can be one or more.

[0072] If the total amount of transaction-related data in all the sub-transaction pools of the node reaches the second quantity threshold, multiple second transaction-related data are obtained from at least one sub-transaction pool of the node, and the second transaction-related data from the same sub-transaction pool are aggregated to obtain the data group corresponding to the sub-transaction pool. The second quantity threshold can be set based on the scenario, which is not limited in this application. The second quantity threshold can be higher than the first quantity threshold, and the second quantity threshold is not lower than the upper limit of the amount of transaction-related data that the block can accommodate (the upper limit is the block upper limit threshold mentioned above).

[0073] If the total number of transaction-related data in all the sub-transaction pools of the node reaches the second quantity threshold, and the number of transaction-related data in all the sub-transaction pools exceeds the block upper limit threshold, the number of transaction-related data indicated by the block upper limit threshold can be obtained from the cache queues of all the sub-transaction pools in the order of the time when the transaction-related data arrives at the node according to the principle of first come first served, as multiple second transaction-related data; then, the second transaction-related data in the cache queue from the same sub-transaction pool is aggregated to obtain the data group corresponding to the sub-transaction pool; one sub-transaction pool corresponds to one data group. Similarly, in this case, the data group determined for generating a block can be one or more.

[0074] It is understandable that the set block generation condition can be one or more of the above-listed conditions. When the set block generation condition includes the four above-listed conditions, when any one of the above four block generation conditions is triggered, the process of generating blocks can be triggered, and at least one data group to be processed can be obtained from the transaction pool of the node. Therefore, by reasonably setting the first duration threshold, the first quantity threshold, the second duration threshold, and the second quantity threshold, while increasing the number of related transaction data under the same signature information, the time interval between blocks and the number of transaction-related data in the transaction pool can be taken into account, and the problem of block delay or transaction accumulation caused by the excessive first quantity threshold corresponding to the transaction-related data under the same signature information can be avoided, thereby ensuring the stable operation of the blockchain system.

[0075] S120: Generate a target transaction block according to the transaction-related data in at least one data group and the signature information corresponding to the sub-transaction pool from which each data group comes.

[0076] The target transaction block includes at least one packaging result, and a packaging result includes multiple transaction-related data from the same sub-transaction pool and the signature information corresponding to the sub-transaction pool. In this way, it can be ensured that multiple transactions with the same signature information in the target transaction block share one signature information, avoiding duplicate signature information in the target transaction block, reducing the amount of data in the target transaction block, and then, in the subsequent process of block transmission, reducing the network resources occupied by block transmission.

[0077] For example, the obtained data group includes data group a1, data group a2 and data group a3, data group a1 comes from sub-transaction pool b1, data group a2 comes from sub-transaction pool b2 and data group a3 comes from sub-transaction pool b3, the signature information corresponding to sub-transaction pool b1 is c1, the signature information corresponding to sub-transaction pool b2 is c2 and the signature information corresponding to sub-transaction pool b3 is c3, at this time, all transaction-related data in data group a1 can be packaged with signature information c1 to obtain packaging result d1, that is, the packaging result d1 includes all transaction-related data in data group a1 and a copy of signature information c1. All transaction-related data in data group a2 are packaged with signature information c2 to obtain packaging result d2, and all transaction-related data in data group a3 are packaged with signature information c3 to obtain packaging result d3. The packaging results d1, d2 and d3 can be summarized to obtain the target block, that is, the target block includes packaging results d1, d2 and d3.

[0078] As an implementation method, S120 may include: performing transaction pre-execution on each transaction-related data in at least one data group, and adding the transaction result obtained by the transaction pre-execution to the corresponding transaction-related data; packaging the transaction-related data batches in each data group in at least one data group with the signature information corresponding to the sub-transaction pool from which the data group originates, to obtain at least one packaging result; and obtaining a target transaction block based on at least one packaging result.

[0079] It is understandable that after performing transaction pre-execution on each transaction-related data in at least one data group, the transaction-related data in each data group in the obtained at least one data group is increased with the transaction result after performing transaction pre-execution according to the transaction-related data. For example, before performing transaction pre-execution, the transaction-related data may include the transaction identifier, transaction parameters, transaction fee and timestamp corresponding to the transaction, and after performing transaction pre-execution, the transaction-related data may include the transaction identifier, transaction parameters, transaction fee, timestamp and transaction result corresponding to the transaction.

[0080] like Figure 6 As shown, the transaction pool includes sub-transaction pool jc1 and sub-transaction pool jc2. Sub-transaction pool jc1 uses signature information q1 as its own sub-transaction pool identifier, and sub-transaction pool jc2 uses signature information q2 as its own sub-transaction pool identifier. Sub-transaction pool jc1 temporarily stores transaction-related data g1 corresponding to transaction 1 with signature information q1, transaction-related data g2 corresponding to transaction 2, and transaction-related data g3 corresponding to transaction 3. Sub-transaction pool jc2 temporarily stores transaction-related data g4 corresponding to transaction 4 with signature information q2, and transaction-related data g5 corresponding to transaction 5.

[0081] When the block generation conditions are met, the transaction-related data g1 corresponding to transaction 1 and the transaction-related data g2 corresponding to transaction 2 are taken out from the sub-transaction pool jc1. At the same time, the transaction-related data g4 corresponding to transaction 4 is taken out from the sub-transaction pool jc2. The transaction pre-execution is performed according to the taken-out transaction-related data to obtain the transaction-related data g11 corresponding to transaction 1 (including the transaction result corresponding to transaction 1 and the transaction-related data g1), the transaction-related data g21 corresponding to transaction 2 (including the transaction result corresponding to transaction 2 and the transaction-related data g2), and the transaction-related data g41 corresponding to transaction 4 (including the transaction result corresponding to transaction 4 and the transaction-related data g4), and the transaction-related data g11 corresponding to transaction 1 and the transaction-related data g21 corresponding to transaction 2 are packaged with the signature information q1 to obtain the packaged result b1, and the transaction-related data g41 corresponding to transaction 4 is packaged with the signature information q2 to obtain the packaged result b2. The target transaction block is obtained according to the packaged results b1 and the packaged results b2. In the batch packaging process, only one signature information is retained for one packaged result.

[0082] The above process of generating the target transaction block is as follows: Figure 7 As shown, the node starts proposing blocks through the core engine module to determine whether the number of transaction-related data in the transaction pool reaches the first quantity threshold, whether the interval between the signing times of the digital signatures of the transactions corresponding to the two latest created transaction-related data in the sub-transaction pool reaches the first duration threshold, whether the interval with the creation time of the previous block reaches the second duration threshold, and whether the total number of transaction-related data in all sub-transaction pools reaches the second quantity threshold. If so, determine whether the node is a proposal node. If the node is a proposal node, the core engine module of the node obtains a data group from the cache queue of the sub-transaction pool of the transaction pool according to the block upper limit threshold corresponding to the block, and generates a target transaction block according to the data group. If the node is not a proposal node, the node restarts the process of generating the target transaction block through the core engine module.

[0083] S130, consensus is reached on the target transaction block to obtain a consensus result.

[0084] The node can broadcast a consensus verification request including a target transaction block to other nodes in the blockchain system except the node; receive verification results returned by other nodes in the blockchain system except the node in response to the consensus verification request; and determine the consensus result of the target transaction block based on the verification results returned by other nodes.

[0085] Other nodes can verify each transaction according to the transaction-related data and signature information corresponding to each transaction in the target transaction block, obtain the transaction verification result of each transaction, and obtain the verification result according to the transaction verification results of all transactions in the target transaction block, wherein verifying the transaction may refer to performing the aforementioned validity screening and anti-duplicate check on the transaction; if the validity screening of the transaction is valid and the anti-duplicate check is not a duplicate transaction, the transaction verification result is determined to be passed, otherwise, the transaction verification result is determined to be failed. And if the transaction verification results of each transaction in the target transaction block are all passed, the verification result is determined to be passed, and if there is at least one transaction in the target transaction block whose transaction verification result is a verification step passed, the verification result is determined to be failed.

[0086] When the ratio of the number of other nodes that return verification results as passed to the number of other nodes that return verification results reaches the ratio threshold, the consensus result of the target transaction block is determined to be that the target transaction block has passed the consensus; when the ratio of the number of other nodes that return verification results as passed to the number of other nodes that return verification results does not reach the ratio threshold, the consensus result of the target transaction block is determined to be that the target transaction block has not passed the consensus.

[0087] Figure 6 The consensus process of the target transaction block shown is as follows Figure 8 As shown, the target transaction block includes packaging result b1 and packaging result b2. Packaging result b1 includes transaction-related data g11 corresponding to transaction 1, transaction-related data g21 corresponding to transaction 2, and signature information q1. Packaging result b2 includes transaction-related data g41 corresponding to transaction 4, and signature information q2. The node broadcasts a consensus verification request including the target transaction block to other nodes 1, other nodes 2, and other nodes 3. Other nodes 1, other nodes 2, and other nodes 3 perform verification according to the target transaction block in the consensus verification request to obtain the verification result. Then, other nodes 1, other nodes 2, and other nodes 3 return their respective verification results to the node. The node determines that the consensus result is passed according to the verification result of other node 1, the verification result of other node 2, and the verification result of other node 3.

[0088] S140. If the consensus result indicates that the target transaction block has passed the consensus, the target transaction block is put on the chain.

[0089] When the consensus result is that the target transaction block passes the consensus, the node processes the target transaction block on the chain to store the transaction data of the target transaction (including transaction-related data generated in the client, signature information, and transaction results obtained by the node's pre-execution of the transaction) on the blockchain.

[0090] When the consensus result is that the target transaction block has not passed the consensus, a transaction error prompt message can be output to prompt the user that the target transaction block has not passed the consensus.

[0091] In this embodiment, the transaction pool of the node of the blockchain system includes at least one sub-transaction pool, each sub-transaction pool is used to temporarily store transaction-related data of transactions corresponding to the signature information corresponding to the sub-transaction pool, one sub-transaction pool corresponds to one signature information one-to-one, and the transaction-related data of a transaction refers to other data related to the transaction in the transaction data of the transaction except the signature information. Therefore, for transactions with the same signature information, the sub-transaction pool only stores one signature information and the transaction-related data of each transaction that shares the signature information, and does not need to store the same signature information multiple times, reducing the storage of duplicate signature information, thereby reducing the storage space occupied by data in the transaction pool, and can increase the transaction storage capacity in the transaction pool, effectively reducing the transaction delays and congestion problems caused by the transaction pool reaching the capacity limit, thereby improving the batch transaction processing capability and the overall performance of the blockchain.

[0092] At the same time, the transaction-related information of multiple transactions with the same signature information in the target transaction block is packaged in batches with one signature information. The transaction-related information of multiple transactions with the same signature information in the target transaction block only needs to retain one signature information, and there is no need to store the corresponding signature information for the transaction-related information of multiple transactions with the same signature information, which reduces the data volume of the target transaction block. When consensus is reached on the target transaction block, the data volume of the target transaction block transmitted to other nodes is small, which reduces the transmission bandwidth occupation and improves the transmission efficiency of the target transaction block. Since the same signature information will not be stored repeatedly, the number of transactions that can be stored in the transaction pool can be increased, and the processing capacity of batch transactions can be improved, thereby effectively improving the overall performance of the blockchain system.

[0093] In some embodiments, after S110, the method further includes: deleting transaction-related data in the corresponding data group from the sub-transaction pool corresponding to each data group in the at least one data group.

[0094] The transaction-related data in the corresponding data group may be deleted from the sub-transaction pool corresponding to each data group in the at least one data group, so as to reduce the amount of transaction-related data in the sub-transaction pool and release storage space of the sub-transaction pool.

[0095] As mentioned above, the transaction-related data in the sub-trading pool is temporarily stored in the cache queue corresponding to the sub-trading pool. After the data group is obtained, the transaction-related data in the corresponding data group can be deleted from the cache queue of the sub-trading pool corresponding to each data group in at least one data group to release the storage space of the cache queue of the sub-trading pool.

[0096] In one embodiment, if Fig. 9 As shown, after S140, the method may further include:

[0097] S210, receiving a consensus request including a block to be verified sent by a consensus initiating node in the blockchain system.

[0098] Among them, the consensus initiating node can be any node that issues a consensus request in the blockchain system. For example, when the consensus nodes in the blockchain system are divided into master and slave nodes, the master consensus node has the authority to generate blocks and the authority to verify blocks, and the slave consensus node has the authority to verify blocks but not the authority to generate blocks. In this case, if the current block is a slave consensus node, the slave consensus node can receive a consensus request initiated by the master consensus node for the block to be verified, that is, in this case, the consensus initiating node is the master consensus node.

[0099] The transaction pool of the consensus node includes at least one sub-transaction pool. The block to be verified is generated based on at least one data group to be verified obtained from the sub-transaction pool included in the transaction pool of the consensus initiating node and the signature information corresponding to the sub-transaction pool from which each data group to be verified comes; the transaction-related data in a data group to be verified comes from a sub-transaction pool in the transaction pool of the consensus initiating node; the block to be verified includes at least one packaged result to be verified, and a packaged result to be verified includes multiple transaction-related data from the same sub-transaction pool and the signature information corresponding to the sub-transaction pool.

[0100] The process of determining the data group to be verified from the consensus initiating node refers to the process of determining the data group from the node above, and will not be repeated here. After determining at least one data group to be verified, pre-execute the transaction related data in the at least one data group to be verified, and add the transaction result obtained by the pre-execution to the corresponding transaction related data; package the transaction related data in each data group to be verified in the at least one data group to be verified with the signature information corresponding to the sub-transaction pool from which the data group to be verified comes, and obtain at least one packaging result to be verified, and obtain the block to be verified based on all the packaging results to be verified.

[0101] It can be understood that after pre-transaction execution is performed on each transaction-related data in at least one data group to be verified, the transaction-related data in each data group to be verified in the at least one data group to be verified is increased with the transaction result after pre-transaction execution is performed on the transaction-related data.

[0102] S220: Perform transaction verification on each transaction-related data in the block to be verified, and obtain a transaction verification result of each transaction-related data in the block to be verified.

[0103] The block to be verified includes multiple transaction-related data. For each transaction-related data in the block to be verified, if the sub-transaction pool of the node includes the transaction-related data, the transaction hash in the transaction-related data in the block to be verified and the transaction hash in the transaction-related data in the sub-transaction pool of the node are compared to determine the transaction verification result of the transaction-related data. The transaction hash in the transaction-related data may refer to the operation result obtained by performing a hash operation on the transaction-related data without adding the transaction result.

[0104] It can be that when the consensus initiating node generates a block to be verified, the transaction-related data without the transaction result is hashed to obtain the transaction hash corresponding to the transaction-related data, and the transaction hash corresponding to the transaction-related data is stored in the block to be verified. The node's sub-transaction pool performs a hash operation on the stored transaction-related data to obtain the transaction hash corresponding to the transaction-related data, and stores the transaction hash corresponding to the transaction-related data. When the node determines that the sub-transaction pool of the node includes the transaction-related data, the transaction hash in the transaction-related data in the block to be verified and the transaction hash in the sub-transaction pool of the node are directly compared. If they are the same, it is determined that the transaction verification result of the transaction-related data has passed the verification. If they are different, it is determined that the transaction verification result of the transaction-related data has not passed the verification.

[0105] For each transaction-related data in the block to be verified, if the transaction-related data is not included in the node's sub-transaction pool, transaction verification is performed based on the transaction-related data in the block to be verified and the signature information of the transaction corresponding to the transaction-related data to obtain the transaction verification result of the transaction-related data.

[0106] It is possible to verify whether the transaction-related data is valid and whether the signature information is successfully verified. If the transaction-related data is valid and the signature information is successfully verified, the transaction verification result of the transaction-related data is determined to be passed, otherwise the transaction verification result of the transaction-related data is determined to be failed. Among them, verifying whether the transaction-related data is valid may include verifying whether the transaction identifier in the transaction-related data complies with the specification, whether the timestamp of the transaction is expired, etc.

[0107] Optionally, if the transaction-related data is not included in the sub-transaction pool of the node, transaction verification is performed according to the transaction-related data in the block to be verified and the signature information of the transaction corresponding to the transaction-related data, and a transaction verification result of the transaction-related data is obtained, including: if the transaction-related data is not included in the sub-transaction pool of the node, the signature information of the transaction corresponding to the transaction-related data includes multiple signatures, and the number of signatures in the signature information of the transaction corresponding to the transaction-related data reaches the required number of signatures of the transaction corresponding to the transaction-related data, verification is performed according to the transaction-related data in the block to be verified and the multiple signatures in the signature information of the transaction corresponding to the transaction-related data, and the transaction verification result of the transaction-related data is obtained.

[0108] For each transaction, when there are multiple signatures corresponding to it, that is, the signature information of the transaction includes multiple signatures, for different transactions, the number of required signatures corresponds to each. When the number of signatures in the signature information of the transaction corresponding to the transaction-related data reaches the required number of signatures of the transaction corresponding to the transaction-related data, it is determined that the signature information of the transaction corresponding to the transaction-related data is legal, and the transaction verification result of the transaction-related data can be obtained by continuing to verify the transaction-related data in the block to be verified and the multiple signatures in the signature information of the transaction corresponding to the transaction-related data; when the number of signatures in the signature information of the transaction corresponding to the transaction-related data does not reach the required number of signatures of the transaction corresponding to the transaction-related data, it is determined that the signature information of the transaction corresponding to the transaction-related data is illegal, and the transaction verification result of the transaction-related data is directly determined to have failed the verification.

[0109] Among them, verification is performed based on the transaction-related data in the block to be verified and multiple signatures in the signature information of the transaction corresponding to the transaction-related data, and the transaction verification result of the transaction-related data can mean: if the transaction-related data in the block to be verified is valid and multiple signatures in the signature information of the transaction corresponding to the transaction-related data are successfully verified, it is determined that the transaction verification result of the transaction-related data is passed; if the transaction-related data in the block to be verified is invalid or there are multiple signatures in the signature information of the transaction corresponding to the transaction-related data that fail to be verified, it is determined that the transaction verification result of the transaction-related data is failed.

[0110] like Fig.10 As shown, the target transaction block includes a packaging result b11 and a packaging result b12. The packaging result b11 includes transaction-related data g111 corresponding to transaction 11, transaction-related data g121 corresponding to transaction 12, and a digital signature q11. The digital signature q11 is the signature information shared by transactions 11 and 12. The packaging result b12 includes transaction-related data g141 corresponding to transaction 14, a digital signature q12, and a digital signature q13. The digital signature q12 and the digital signature q13 are the signature information corresponding to transaction 14, that is, transaction 14 has multiple digital signatures.

[0111] S230. Determine the verification result of the block to be verified according to the transaction verification results of all transaction-related data in the block to be verified; and send the verification result of the block to be verified to the consensus initiating node.

[0112] After obtaining the transaction verification result of each transaction-related data in the block to be verified, the verification result of the block to be verified is determined according to the transaction verification results of all transaction-related data in the block to be verified. When the transaction verification results of all transaction-related data in the block to be verified are all passed, the verification result of the block to be verified is determined to be passed. If there is transaction-related data that has not passed the verification among all transaction-related data in the block to be verified, the verification result of the block to be verified is determined to be failed.

[0113] After obtaining the verification result of the block to be verified, the verification result of the block to be verified is sent to the consensus initiating node, and the consensus initiating node determines whether the block to be verified has passed the consensus based on the verification results returned by each node.

[0114] In this embodiment, the transaction-related data in the block to be verified is verified in two different ways to obtain verification results, thereby ensuring fast and accurate verification of the transaction-related data, thereby improving the consensus accuracy and efficiency of the block to be verified.

[0115] See also Fig.11 , Fig.11 A block diagram of a transaction processing device proposed in one embodiment of the present application is shown, and the device 1000 includes:

[0116] The acquisition module 1010 is used to acquire at least one data group to be processed from the transaction pool of the node; the transaction-related data in a data group comes from a sub-transaction pool in the transaction pool of the node;

[0117] The block generation module 1020 is used to generate a target transaction block according to the transaction-related data in at least one data group and the signature information corresponding to the sub-transaction pool from which each data group comes; wherein the target transaction block includes at least one packaging result, and one packaging result includes multiple transaction-related data from the same sub-transaction pool and the signature information corresponding to the sub-transaction pool;

[0118] The consensus module 1030 is used to reach a consensus on the target transaction block and obtain a consensus result;

[0119] The on-chain module 1040 is used to put the target transaction block on the chain if the consensus result indicates that the target transaction block has passed the consensus.

[0120] Optionally, the device also includes a storage module, which is used to receive target transaction data of the target transaction, the target transaction data including target transaction-related data corresponding to the target transaction and target signature information; temporarily storing the target transaction-related data in a target sub-transaction pool in the transaction pool of the node; the target sub-transaction pool refers to the sub-transaction pool corresponding to the target signature information.

[0121] Optionally, the block generation module 1020 is further used to perform transaction pre-execution on each transaction-related data in at least one data group, and add the transaction result obtained by the transaction pre-execution to the corresponding transaction-related data; package the transaction-related data in each data group in the at least one data group in batches with the signature information corresponding to the sub-transaction pool from which the data group comes, to obtain at least one packaging result; and obtain the target transaction block based on the at least one packaging result.

[0122] Optionally, the acquisition module 1010 is also used to acquire at least one data group to be processed from the transaction pool of the node if the block generation condition is met; the block generation condition includes at least one of the following: the number of transaction-related data in any sub-transaction pool in the node reaches a first quantity threshold, the interval between the signing times of the digital signatures of the transactions corresponding to the two latest created transaction-related data in any sub-transaction pool in the node reaches a first duration threshold, the interval between the creation time of the previous block reaches a second duration threshold, and the total number of transaction-related data in all sub-transaction pools of the node reaches a second quantity threshold.

[0123] Optionally, the acquisition module 1010 is further configured to, if there is a first sub-transaction pool in the node in which the number of transaction-related data reaches a first quantity threshold, acquire and aggregate multiple transaction-related data from the first sub-transaction pool to obtain a data group corresponding to the first sub-transaction pool; if there is a second sub-transaction pool in the node in which the interval between the signing times of the digital signatures of the transactions corresponding to the two latest created transaction-related data reaches a first duration threshold, acquire and aggregate multiple transaction-related data from the second sub-transaction pool to obtain a data group corresponding to the second sub-transaction pool; if the interval between the creation time of the previous block reaches a second duration threshold, acquire multiple first transaction-related data from at least one sub-transaction pool of the node, and aggregate the first transaction-related data from the same sub-transaction pool to obtain a data group corresponding to the sub-transaction pool; if the total number of transaction-related data in all sub-transaction pools of the node reaches a second quantity threshold, acquire multiple second transaction-related data from at least one sub-transaction pool of the node, and aggregate the second transaction-related data from the same sub-transaction pool to obtain a data group corresponding to the sub-transaction pool.

[0124] Optionally, the storage module is also used to verify the target transaction data; if the target transaction data passes the verification, the target transaction related data is temporarily stored in the cache queue of the target sub-transaction pool of the node.

[0125] Optionally, the storage module is further configured to delete transaction-related data in a corresponding data group from a sub-transaction pool corresponding to each data group in the at least one data group.

[0126] Optionally, the consensus module 1030 is also used to broadcast a consensus verification request including a target transaction block to other nodes in the blockchain system except the node; receive verification results returned by other nodes in the blockchain system except the node in response to the consensus verification request; and determine the consensus result of the target transaction block based on the verification results returned by other nodes.

[0127] Optionally, the device also includes a verification module, which is used to receive a consensus request including a block to be verified sent by a consensus initiating node in the blockchain system; the block to be verified is generated based on at least one data group to be verified obtained from a sub-transaction pool included in the transaction pool of the consensus initiating node and the signature information corresponding to the sub-transaction pool from which each data group to be verified comes from; the transaction-related data in a data group to be verified comes from a sub-transaction pool in the transaction pool of the consensus initiating node; the block to be verified includes at least one packaged result to be verified, and a packaged result to be verified includes multiple transaction-related data from the same sub-transaction pool and the signature information corresponding to the sub-transaction pool; transaction verification is performed on each transaction-related data in the block to be verified to obtain a transaction verification result of each transaction-related data in the block to be verified; the verification result of the block to be verified is determined based on the transaction verification results of all transaction-related data in the block to be verified; and the verification result of the block to be verified is sent to the consensus initiating node.

[0128] Optionally, the verification module is also used to, for each transaction-related data in the block to be verified, if the transaction-related data is included in the node's sub-transaction pool, compare the transaction hash in the transaction-related data in the block to be verified with the transaction hash in the transaction-related data in the node's sub-transaction pool to determine a transaction verification result of the transaction-related data; or, if the transaction-related data is not included in the node's sub-transaction pool, perform transaction verification based on the transaction-related data in the block to be verified and the signature information of the transaction corresponding to the transaction-related data to obtain a transaction verification result of the transaction-related data.

[0129] Optionally, the verification module is also used to perform verification based on the transaction-related data in the block to be verified and multiple signatures in the signature information of the transaction corresponding to the transaction-related data, if the transaction-related data is not included in the node's sub-transaction pool, and the number of signatures in the signature information of the transaction corresponding to the transaction-related data reaches the required number of signatures of the transaction corresponding to the transaction-related data, to obtain the transaction verification result of the transaction-related data.

[0130] It should be noted that the device embodiment in the present application corresponds to the aforementioned method embodiment. The specific principles in the device embodiment can be found in the contents of the aforementioned method embodiment and will not be repeated here.

[0131] Fig.12A structural block diagram of an electronic device for executing a transaction processing method according to an embodiment of the present application is shown. The electronic device may be Figure 1 The middle node 101, etc., needs to be explained that, Fig.12 The computer system 1200 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0132] like Fig.12 As shown, the computer system 1200 includes a central processing unit (CPU) 1201, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1202 or the program loaded from the storage part 1208 to the random access memory (RAM) 1203, such as executing the method in the above embodiment. In RAM 1203, various programs and data required for system operation are also stored. CPU 1201, ROM 1202 and RAM 1203 are connected to each other through bus 1204. Input / output (I / O) interface 1205 is also connected to bus 1204.

[0133] The following components are connected to the I / O interface 1205: an input section 1206 including a keyboard, a mouse, etc.; an output section 1207 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to the I / O interface 1205 as needed. A removable medium 1211, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1210 as needed so that a computer program read therefrom is installed into the storage section 1208 as needed.

[0134] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication section 1209, and / or installed from a removable medium 1211. When the computer program is executed by a central processing unit (CPU) 1201, various functions defined in the system of the present application are executed.

[0135] It should be noted that the computer-readable medium shown in the embodiment of the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, - but not limited to - an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by an instruction execution system, device or device or used in combination with it. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a computer-readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0136] The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present application. Wherein, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0137] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0138] As another aspect, the present application further provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiments; or may exist independently without being assembled into the electronic device. The above computer-readable storage medium carries computer-readable instructions, and when the computer-readable storage instructions are executed by a processor, the method in any of the above embodiments is implemented.

[0139] According to one aspect of the embodiments of the present application, a computer program product or a computer program is provided, the computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the electronic device executes the method in any of the above embodiments.

[0140] It should be noted that, although several modules or units of the equipment for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more modules or units described above can be embodied in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into being embodied by multiple modules or units.

[0141] Through the description of the above implementation methods, it is easy for those skilled in the art to understand that the example implementation methods described here can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the implementation method of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, including several instructions to enable an electronic device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the implementation method of the present application.

[0142] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the embodiments disclosed herein. The present application is intended to cover any variations, uses or adaptations of the present application, which follow the general principles of the present application and include common knowledge or customary techniques in the art that are not disclosed in the present application. It should be understood that the present application is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

[0143] 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 make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A transaction processing method, characterized in that: A node in a blockchain system, wherein each sub-transaction pool of the node is used to temporarily store transaction-related data of a transaction corresponding to signature information corresponding to the sub-transaction pool; one sub-transaction pool corresponds to one signature information one by one; transaction-related data of a transaction refers to other data related to the transaction in the transaction data of the transaction except the signature information; the method comprises: Acquire at least one data group to be processed from the transaction pool of the node; transaction-related data in a data group originates from a sub-transaction pool in the transaction pool of the node; Generate a target transaction block according to the transaction-related data in the at least one data group and the signature information corresponding to the sub-transaction pool from which each data group comes; wherein the target transaction block includes at least one packaging result, and one packaging result includes multiple transaction-related data from the same sub-transaction pool and the signature information corresponding to the sub-transaction pool; A consensus is reached on the target transaction block to obtain a consensus result; If the consensus result indicates that the target transaction block has passed the consensus, the target transaction block will be put on the chain.

2. The method according to claim 1, characterized in that: The method further comprises: Receiving target transaction data of a target transaction, wherein the target transaction data includes target transaction related data corresponding to the target transaction and target signature information; The target transaction related data is temporarily stored in a target sub-transaction pool in the transaction pool of the node; the target sub-transaction pool refers to a sub-transaction pool corresponding to the target signature information.

3. The method according to claim 1, characterized in that The generating a target transaction block according to the transaction-related data in the at least one data group and the signature information corresponding to the sub-transaction pool from which each data group is derived includes: Performing transaction pre-execution on each transaction-related data in the at least one data group, and adding a transaction result obtained by the transaction pre-execution to the corresponding transaction-related data; Packing the batch of transaction-related data in each data group of the at least one data group with the signature information corresponding to the sub-transaction pool from which the data group originates, to obtain at least one packaging result; The target transaction block is obtained according to the at least one packaging result.

4. The method according to claim 1, characterized in that: The acquiring at least one data group to be processed from the transaction pool of the node comprises: If the block generation condition is met, at least one data group to be processed is obtained from the transaction pool of the node; the block generation condition includes at least one of the following: the number of transaction-related data in any sub-transaction pool of the node reaches a first quantity threshold, the interval between the signing times of the digital signatures of the transactions corresponding to the two latest created transaction-related data in any sub-transaction pool of the node reaches a first duration threshold, the interval between the creation time of the previous block reaches a second duration threshold, and the total number of transaction-related data in all sub-transaction pools of the node reaches a second quantity threshold.

5. The method according to claim 4, characterized in that If the block generation condition is met, obtaining at least one data group to be processed from the transaction pool of the node includes: If a first sub-transaction pool exists in the node and the amount of transaction-related data reaches a first amount threshold, multiple transaction-related data are acquired and aggregated from the first sub-transaction pool to obtain a data group corresponding to the first sub-transaction pool; If there is a second sub-transaction pool in the node in which the interval between the signing times of the digital signatures of the transactions corresponding to the two latest created transaction-related data reaches the first time threshold, multiple transaction-related data are obtained and aggregated from the second sub-transaction pool to obtain a data group corresponding to the second sub-transaction pool; If the interval between the creation time of the previous block and the creation time of the previous block reaches a second time threshold, a plurality of first transaction related data are obtained from at least one sub-transaction pool of the node, and the first transaction related data from the same sub-transaction pool are aggregated to obtain a data group corresponding to the sub-transaction pool; If the total amount of transaction-related data in all sub-transaction pools of the node reaches a second quantity threshold, multiple second transaction-related data are obtained from at least one sub-transaction pool of the node, and the second transaction-related data from the same sub-transaction pool are aggregated to obtain a data group corresponding to the sub-transaction pool.

6. The method according to claim 2, characterized in that Each sub-transaction pool is provided with a cache queue; before temporarily storing the target transaction-related data in the target sub-transaction pool in the transaction pool of the node, the method further includes: Verifying the target transaction data; The step of temporarily storing the target transaction related data in a target sub-transaction pool in the transaction pool of the node includes: If the target transaction data passes the verification, the target transaction related data is temporarily stored in the cache queue of the target sub-transaction pool of the node.

7. The method according to any one of claims 1 to 6, characterized in that After obtaining at least one data group to be processed from the transaction pool of the node, the method further includes: The transaction-related data in the corresponding data group is deleted from the sub-transaction pool corresponding to each data group in the at least one data group.

8. The method according to claim 1, characterized in that The consensus on the target transaction block is obtained to obtain a consensus result, including: Broadcasting a consensus verification request including the target transaction block to other nodes in the blockchain system except the node; Receiving verification results returned by other nodes in the blockchain system except the node in response to the consensus verification request; The consensus result of the target transaction block is determined according to the verification results returned by the other nodes.

9. The method according to claim 1, characterized in that: The method further comprises: A consensus request including a block to be verified is received from a consensus initiating node in the blockchain system; the block to be verified is generated according to at least one data group to be verified obtained from a sub-transaction pool included in the transaction pool of the consensus initiating node and signature information corresponding to the sub-transaction pool from which each data group to be verified originates; transaction-related data in a data group to be verified originates from a sub-transaction pool in the transaction pool of the consensus initiating node; the block to be verified includes at least one packaged result to be verified, and a packaged result to be verified includes multiple transaction-related data from the same sub-transaction pool and signature information corresponding to the sub-transaction pool; Performing transaction verification on each transaction-related data in the block to be verified, and obtaining a transaction verification result of each transaction-related data in the block to be verified; Determining the verification result of the block to be verified according to the transaction verification results of all transaction-related data in the block to be verified; Send the verification result of the block to be verified to the consensus initiating node.

10. The method according to claim 9, characterized in that The performing transaction verification on each transaction-related data in the block to be verified to obtain a transaction verification result of each transaction-related data in the block to be verified includes: For each transaction-related data in the block to be verified, if the transaction-related data is included in the sub-transaction pool of the node, the transaction hash in the transaction-related data in the block to be verified and the transaction hash in the transaction-related data in the sub-transaction pool of the node are compared to determine the transaction verification result of the transaction-related data; or, if the transaction-related data is not included in the sub-transaction pool of the node, transaction verification is performed according to the transaction-related data in the block to be verified and the signature information of the transaction corresponding to the transaction-related data to obtain the transaction verification result of the transaction-related data.

11. The method according to claim 10, characterized in that If the sub-transaction pool of the node does not include the transaction-related data, transaction verification is performed according to the transaction-related data in the block to be verified and the signature information of the transaction corresponding to the transaction-related data, and a transaction verification result of the transaction-related data is obtained, including: If the transaction-related data is not included in the sub-transaction pool of the node, and the number of signatures in the signature information of the transaction corresponding to the transaction-related data reaches the required number of signatures of the transaction corresponding to the transaction-related data, verification is performed based on the transaction-related data in the block to be verified and multiple signatures in the signature information of the transaction corresponding to the transaction-related data to obtain a transaction verification result of the transaction-related data.

12. A transaction processing device, characterized in that: A node in a blockchain system, wherein each sub-transaction pool of the node is used to temporarily store transaction-related data of a transaction corresponding to signature information corresponding to the sub-transaction pool; one sub-transaction pool corresponds to one signature information one by one; transaction-related data of a transaction refers to other data related to the transaction in the transaction data of the transaction except the signature information; the device comprises: An acquisition module, used to acquire at least one data group to be processed from the transaction pool of the node; transaction-related data in a data group originates from a sub-transaction pool in the transaction pool of the node; A block generation module, configured to generate a target transaction block according to the transaction-related data in the at least one data group and the signature information corresponding to the sub-transaction pool from which each data group originates; wherein the target transaction block includes at least one packaging result, and one packaging result includes multiple transaction-related data from the same sub-transaction pool and the signature information corresponding to the sub-transaction pool; A consensus module, used to reach a consensus on the target transaction block and obtain a consensus result; The on-chain module is used to put the target transaction block on the chain if the consensus result indicates that the target transaction block has passed the consensus.

13. An electronic device, characterized in that: include: processor; A memory having computer-readable instructions stored thereon, wherein when the computer-readable instructions are executed by the processor, the method according to any one of claims 1 to 11 is implemented.

14. A computer-readable storage medium, characterized in that: Computer-readable instructions are stored thereon, and when the computer-readable instructions are executed by a processor, the method according to any one of claims 1 to 11 is implemented.

15. A computer program product or a computer program, characterized in that The method comprises computer instructions, wherein when the computer instructions are executed by a processor, the method according to any one of claims 1 to 11 is implemented.

Images