Blockchain transaction processing method and apparatus, electronic device, and readable medium

Abstract

The application provides a blockchain transaction processing method and device, electronic equipment and readable medium. The method comprises: obtaining at least two to-be-processed transactions, wherein the to-be-processed transactions comprise smart contract identifiers; adding the at least two to-be-processed transactions to a directed sequence corresponding to the smart contract identifiers according to the smart contract identifiers in each to-be-processed transaction, each smart contract identifier corresponds to a directed sequence, and the directed sequence is used to indicate an execution order of the to-be-processed transactions; executing the to-be-processed transactions in the directed sequence in parallel to obtain transaction execution results; and packaging the transaction execution results to generate a transaction block. The method can reduce the time consumed in the transaction execution process, improve the execution efficiency of the blockchain transaction process, and further improve the transaction throughput of the blockchain system.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a blockchain transaction processing method, apparatus, electronic device, and readable medium. Background Technology

[0002] In a blockchain system, a transaction is a fundamental unit of business. Blockchain nodes execute smart contracts within a transaction, generating the transaction result and packaging it into a block for on-chain storage. Transaction execution is the crucial step in saving the transaction content to the blockchain. Therefore, improving the efficiency of transaction execution has become a key area of ​​focus.

[0003] In related technologies, when executing blockchain transactions, the system pre-executes the transactions that need to be packaged, determines the execution order of the transactions based on the dependencies between the transactions during pre-execution, and then formally executes the transactions and packages them onto the blockchain in that order.

[0004] However, in the aforementioned pre-execution transaction process, due to the unclear dependencies between transactions, multiple pre-execution transactions are often required to confirm the dependencies between each transaction. This results in the pre-execution transaction process consuming a lot of time, affecting the overall execution efficiency of the blockchain transaction process, and reducing the transaction throughput of the blockchain system. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a blockchain transaction processing method, apparatus, electronic device, and readable medium to reduce the time consumed in the transaction execution process, improve the execution efficiency of the blockchain transaction process, and thereby increase the transaction throughput of the blockchain system.

[0006] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0007] According to one aspect of the embodiments of this application, a blockchain transaction processing method is provided, including:

[0008] Obtain at least two pending transactions, which include smart contract identifiers;

[0009] Based on the smart contract identifiers in each pending transaction, at least two pending transactions are added to a directed sequence corresponding to the smart contract identifier. Each smart contract identifier corresponds to a directed sequence, which is used to indicate the execution order of the pending transactions.

[0010] The transactions to be processed in the directed sequence are executed in parallel to obtain the transaction execution results;

[0011] The transaction execution results are packaged to generate a transaction block.

[0012] According to one aspect of the embodiments of this application, a blockchain transaction processing apparatus is provided, comprising:

[0013] The transaction acquisition module is used to acquire at least two pending transactions, which include smart contract identifiers.

[0014] The transaction addition module is used to add at least two pending transactions to a directed sequence corresponding to the smart contract identifier, based on the smart contract identifier in each pending transaction. Each smart contract identifier corresponds to a directed sequence, and the directed sequence is used to indicate the execution order of the pending transactions.

[0015] The parallel execution module is used to execute transactions in a directed sequence in parallel to obtain transaction execution results;

[0016] The block generation module is used to package the transaction execution results into transaction blocks.

[0017] In some embodiments of this application, based on the above technical solutions, the directed sequence is a transaction queue in the transaction pool; the transaction joining module includes:

[0018] The type determination submodule is used to determine the transaction type of the transaction to be processed based on the smart contract identifier of the transaction to be processed;

[0019] The queue retrieval submodule is used to retrieve the transaction queue corresponding to the smart contract identifier if the transaction type is a smart contract execution type.

[0020] The queue addition submodule is used to add pending transactions to the transaction queue corresponding to the smart contract identifier, based on the execution order of the transactions.

[0021] In some embodiments of this application, based on the above technical solutions, the blockchain transaction processing device further includes:

[0022] The transaction execution module is used to execute pending transactions and obtain transaction results if the transaction type is a smart contract creation type or a smart contract modification type.

[0023] The queue creation module is used to create transaction queues in the transaction pool corresponding to the smart contract identifiers based on the smart contract call process in the transaction results.

[0024] In some embodiments of this application, based on the above technical solutions, the transaction joining module includes:

[0025] The set determination submodule is used to determine the set of smart contract identifiers to which each smart contract identifier contained in each pending transaction belongs. The smart contract identifier set includes smart contract identifiers with smart contract call relationships, and each smart contract identifier set corresponds to a different directed sequence.

[0026] The sequence addition submodule is used to add at least two pending transactions to the corresponding directed sequence based on the smart contract identifier set and the smart contract identifiers in each pending transaction. The pending transactions in the directed sequence are sorted according to the smart contract call relationship and the execution order of the pending transactions.

[0027] In some embodiments of this application, based on the above technical solutions, the directed sequence is a transaction queue in the transaction pool; the added sequence submodule includes:

[0028] The type determination unit is used to determine the transaction type of the transaction to be processed based on the smart contract identifier of the transaction to be processed;

[0029] The queue acquisition unit is used to acquire the transaction queue corresponding to the smart contract identifier set based on the smart contract identifier set to which the smart contract identifier belongs if the transaction type is a smart contract execution type.

[0030] The queue unit is used to add pending transactions to the transaction queue corresponding to the smart contract identifier, based on the execution order of the transactions.

[0031] In some embodiments of this application, based on the above technical solutions, the addition of the sequence submodule further includes:

[0032] The transaction execution unit is used to execute pending transactions and obtain transaction results if the transaction type is a smart contract creation type or a smart contract modification type.

[0033] The set creation unit is used to create a set of smart contract identifiers based on the smart contract call process in the transaction result, and to create a corresponding transaction queue in the transaction pool. The set of smart contract identifiers includes the smart contract identifiers of the transactions to be processed and the smart contract identifiers of the smart contracts called during the execution of the transactions to be processed.

[0034] In some embodiments of this application, based on the above technical solutions, the parallel execution module includes:

[0035] The transaction retrieval submodule is used to retrieve pending transactions from various transaction queues in the transaction pool based on the number of transactions that a block can contain, thus obtaining a transaction set.

[0036] The sequence determination submodule is used to determine the transaction execution sequence corresponding to the transaction set based on the transaction queue to which each pending transaction in the transaction set belongs. Pending transactions belonging to different transaction queues in the transaction execution sequence are executed in parallel, while pending transactions belonging to the same transaction queue are executed serially.

[0037] The first transaction execution submodule is used to execute the pending transactions contained in the transaction set according to the transaction execution sequence, and obtain the transaction execution result.

[0038] In some embodiments of this application, based on the above technical solutions, the transaction acquisition submodule includes:

[0039] The first queue acquisition unit is used to acquire a transaction queue from the transaction pool as the current transaction queue;

[0040] The transaction retrieval unit is used to retrieve a pending transaction from the current transaction queue if the current transaction queue is not empty.

[0041] The quantity comparison unit is used to compare the number of currently retrieved pending transactions with the number of transactions that can be contained in the block;

[0042] The second queue acquisition unit is used to retrieve the next transaction queue from the transaction pool and retrieve the pending transactions if the number of currently retrieved pending transactions is less than the number of transactions that the block can accommodate, until the number of currently retrieved pending transactions meets the number of transactions that the block can accommodate, thus obtaining a transaction set.

[0043] In some embodiments of this application, based on the above technical solutions, the second queue acquisition unit includes:

[0044] The quantity check subunit is used to check the remaining quantity of pending transactions in the transaction pool;

[0045] The queue retrieves sub-units, which are used to continue retrieving the next transaction queue from the transaction pool and taking out the transaction to be processed if the remaining quantity is greater than zero;

[0046] The set generates a sub-unit, which is used to generate a transaction set based on the transactions that have been taken out if the remaining quantity is equal to zero.

[0047] In some embodiments of this application, based on the above technical solutions, the directed sequence is a transaction list; the added sequence submodule includes:

[0048] The list retrieval unit is used to retrieve a list of transactions corresponding to the target smart contract identifier set, based on the target smart contract identifier set to which the smart contract identifier contained in the transaction to be processed belongs;

[0049] The list addition unit is used to add pending transactions to the transaction list corresponding to the smart contract identifier according to the execution order of the transactions;

[0050] The sequence generation unit is used to generate a directed sequence based on the transaction list when at least two transactions to be processed have been added to the corresponding transaction list.

[0051] In some embodiments of this application, based on the above technical solutions, the list acquisition unit includes:

[0052] The list check sub-unit is used to check whether a transaction list corresponding to the target smart contract identifier set exists, based on the target smart contract identifier set to which the smart contract identifier belongs;

[0053] The list creation sub-unit is used to create a transaction list corresponding to the target smart contract identifier set if the transaction list does not exist.

[0054] The list retrieval sub-unit is used to retrieve the transaction list corresponding to the target smart contract identifier set, based on the target smart contract identifier set to which the smart contract identifier belongs, if the transaction list exists.

[0055] In some embodiments of this application, based on the above technical solutions, the parallel execution module includes:

[0056] The execution sequence generation submodule is used to generate a transaction execution sequence corresponding to a transaction set based on the transaction lists to which at least two pending transactions belong. Pending transactions belonging to the same transaction list are executed serially, while pending transactions belonging to different transaction lists are executed in parallel.

[0057] The second transaction execution submodule is used to execute at least two pending transactions according to the transaction execution sequence to obtain the transaction execution result.

[0058] According to one aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the blockchain transaction processing method as described above by executing the executable instructions.

[0059] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the blockchain transaction processing method as described above.

[0060] According to one aspect of the embodiments of this application, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain transaction processing method provided in the various optional implementations described above.

[0061] In the embodiments of this application, after a blockchain node obtains at least two pending transactions to be processed, it adds the at least two pending transactions to a directed sequence corresponding to the smart contract identifiers in each pending transaction. Then, it executes the pending transactions in the directed sequence in parallel to obtain the transaction execution results. Finally, it packages the transaction execution results to generate a transaction block. Through this method, during transaction execution, transactions are divided into different execution sequences based on different smart contracts, allowing blockchain transactions based on different smart contracts to be executed in parallel. The dependencies between transactions can be determined without pre-executing transactions, eliminating the need for pre-executing transactions during the transaction execution process. This reduces the time consumed in the transaction execution process, improves the execution efficiency of the blockchain transaction process, and ultimately increases the transaction throughput of the blockchain system.

[0062] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0063] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0064] In the attached diagram:

[0065] Figure 1 This is an optional structural diagram of the distributed system 100 provided in this embodiment of the invention applied to a blockchain system;

[0066] Figure 2 This is a schematic flowchart of a blockchain transaction processing method according to an embodiment of this application;

[0067] Figure 3 This is a schematic flowchart of a blockchain transaction processing method according to an embodiment of this application;

[0068] Figure 4 This is a schematic flowchart of a blockchain transaction processing method according to an embodiment of this application;

[0069] Figure 5 This is a schematic flowchart of a blockchain transaction processing method according to an embodiment of this application;

[0070] Figure 6 This is a schematic flowchart of a blockchain transaction processing method according to an embodiment of this application;

[0071] Figure 7This is a schematic diagram of the transaction pool structure in an embodiment of this application;

[0072] Figure 8 This is a schematic flowchart of a blockchain transaction processing method according to an embodiment of this application;

[0073] Figure 9 This is a flowchart illustrating the process of adding a transaction to the transaction pool in an embodiment of this application.

[0074] Figure 10 This is a schematic flowchart of a blockchain transaction processing method according to an embodiment of this application;

[0075] Figure 11 This is a schematic diagram illustrating the process of retrieving transactions to be processed from the transaction queue in an embodiment of this application;

[0076] Figure 12 This is an example diagram illustrating the determination of the transaction execution sequence in an embodiment of this application;

[0077] Figure 13 This is a schematic flowchart of a blockchain transaction processing method according to an embodiment of this application;

[0078] Figure 14 This is a schematic flowchart of a blockchain transaction processing method according to an embodiment of this application;

[0079] Figure 15 This is a flowchart illustrating the overall process of obtaining transactions to be processed from the transaction pool in an embodiment of this application.

[0080] Figure 16 This is a schematic flowchart of a blockchain transaction processing method according to an embodiment of this application;

[0081] Figure 17 This is a schematic flowchart of a blockchain transaction processing method according to an embodiment of this application;

[0082] Figure 18 This is a schematic flowchart illustrating the construction of a directed sequence of transactions to be processed in an embodiment of this application;

[0083] Figure 19 This is a schematic flowchart of a blockchain transaction processing method according to an embodiment of this application;

[0084] Figure 20 This is a schematic diagram of the transaction list in the embodiments of this application;

[0085] Figure 21 A schematic block diagram illustrating the composition of a blockchain transaction processing apparatus in an embodiment of this application is shown.

[0086] Figure 22A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0087] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0088] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0089] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0090] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0091] It should be understood that the blockchain transaction processing method in this application can be applied to blockchain transaction scenarios, specifically to scenarios where blockchain transactions are executed and uploaded to the blockchain. In a blockchain system, a block typically includes multiple blockchain transactions. When generating a new block, these transactions need to be executed before the transaction results are packaged and uploaded to the blockchain. The process of executing transactions involves a large number of computational operations. Using the solution in this application, blockchain nodes can separate transactions with no dependencies in their execution processes and execute them in parallel, thereby improving the efficiency of the transaction execution process. Specifically, in the solution of this application, when a new smart contract is uploaded to the blockchain or when an existing smart contract is modified, the blockchain stores the set of smart contracts involved in that smart contract. During the execution of a transaction, the blockchain nodes first divide the transaction according to the smart contracts to be executed. Transactions belonging to the same smart contract set are grouped together and executed serially, while transactions belonging to different smart contract sets are divided and executed in parallel. The maximum number of transactions included in a block is fixed. Therefore, parallelizing multiple transactions can improve the overall execution efficiency of all transactions in a block, and it does not require pre-execution of the transaction process of each block, thus avoiding the consumption of additional time and computing resources in the pre-execution process.

[0092] The system involved in the embodiments of the present invention can be a distributed system formed by connecting a client and multiple nodes (any form of computing device in the network, such as a server or a user terminal) through network communication.

[0093] Taking a distributed system as an example, see blockchain system. Figure 1 , Figure 1 This is an optional structural diagram of the distributed system 100 provided in this embodiment of the invention applied to a blockchain system. It consists of multiple nodes (any form of computing device in the network, such as servers or user terminals) and clients, forming a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In the distributed system, any machine, such as a server or terminal, can join and become a node. A node includes a hardware layer, a middleware layer, an operating system layer, and an application layer.

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

[0095] 1) Routing: A basic function of nodes used to support communication between nodes.

[0096] In addition to routing capabilities, nodes can also have the following functions:

[0097] 2) Applications are deployed in the blockchain to implement specific business needs. They record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system. When other nodes successfully verify the source and integrity of the record data, they add the record data to a temporary block.

[0098] For example, the business logic implemented by the application includes:

[0099] 2.1) A wallet is used to provide the function of trading virtual resources, including initiating transactions (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system. After the other nodes successfully verify the transaction, they store the transaction record data in the temporary block of the blockchain as a response to acknowledge the validity of the transaction; of course, the wallet also supports querying the remaining virtual resources in the virtual resource address.

[0100] 2.2) Shared ledger, used to provide functions such as storage, query and modification of ledger data. It sends the record data of the operation on the ledger data to other nodes in the blockchain system. After the other nodes verify the validity, as a response to acknowledge the validity of the ledger data, they store the record data in a temporary block. They can also send confirmation to the node that initiated the operation.

[0101] 2.3) Smart contracts are computerized protocols that can execute the terms of a contract. They are implemented through code deployed on a shared ledger that executes when certain conditions are met. Based on actual business needs, the code is used to complete automated transactions, such as querying the logistics status of goods purchased by a buyer and transferring the buyer's virtual resources to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions; they can also execute contracts for processing received information.

[0102] 3) A blockchain consists of a series of blocks that are sequentially generated. Once a new block is added to the blockchain, it will not be removed. The blocks contain the data submitted by the nodes in the blockchain system.

[0103] Each node in a blockchain system can be a terminal device or a server. A server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. This application does not impose any restrictions on these. Terminal devices can be mobile phones, computers, smart voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc., but are not limited to these. Terminal devices and servers can be connected directly or indirectly through wired or wireless communication methods, which is not limited in this application. The number of terminal devices and servers is also not limited.

[0104] The following provides a further description of the blockchain transaction processing in the embodiments of this application. Please refer to [link / reference]. Figure 2 , Figure 2 This is a schematic flowchart illustrating a blockchain transaction processing method according to an embodiment of this application. This method can be executed by a server located where the nodes used to execute transactions reside in the blockchain system, such as the blockchain nodes described above. Figure 2 As shown, this blockchain transaction processing method includes at least steps S210 to S240, which are detailed below:

[0105] Step S210: Obtain at least two pending transactions, which include smart contract identifiers.

[0106] Pending transactions are those received by blockchain nodes that need to be executed before being added to the blockchain. In a blockchain, each block typically includes multiple transactions; therefore, when generating a new block, a blockchain node obtains at least two pending transactions, executes them, and adds them to a block for on-chain processing. Each pending transaction includes a smart contract identifier. A smart contract is the transaction rule that the pending transaction must follow during execution. Different smart contracts have different smart contract identifiers, and each pending transaction needs to use this identifier to execute the smart contract it must adhere to. The smart contract identifier can specifically be the smart contract name, smart contract number, smart contract source code, or binary representation, etc.

[0107] Step S220: Based on the smart contract identifiers in each pending transaction, add at least two pending transactions to a directed sequence corresponding to the smart contract identifier. Each smart contract identifier corresponds to a directed sequence, and the directed sequence is used to indicate the execution order of the pending transactions.

[0108] Blockchain nodes parse the content of transactions to be processed, thereby reading the stored smart contract identifiers and then finding the directed sequence corresponding to each smart contract identifier. The correspondence between smart contract identifiers and directed sequences can be stored in the blockchain or in the terminal device of the blockchain node. This correspondence can be pre-configured based on the specific execution relationship of the smart contracts, or it can be established by the blockchain node during blockchain execution based on the smart contracts to be added to the blockchain. The directed sequence is established corresponding to the smart contract identifier, and the corresponding directed sequence can be found based on the smart contract identifier. Specifically, in one embodiment, when it is determined that the directed sequence corresponding to a smart contract identifier does not exist, the blockchain node can create a directed sequence corresponding to the smart contract identifier. Each smart contract identifier corresponds to one directed sequence, and each transaction to be processed typically executes only one smart contract; that is, based on the smart contract identifier, each transaction to be processed is only added to one directed sequence. Different smart contract identifiers can correspond to the same directed sequence; therefore, transactions to be processed executing different smart contracts can also be added to the same directed sequence. In the directed sequence, transactions to be processed are arranged according to the order in which they are executed. The order of arrangement is usually determined by the blockchain nodes, for example, by sorting the transactions according to their reception time or creation time.

[0109] Step S230: Execute the transactions to be processed in the directed sequence in parallel to obtain the transaction execution results.

[0110] Blockchain nodes execute pending transactions in directed sequences in parallel, resulting in transaction execution outcomes. Specifically, each blockchain node retrieves one pending transaction from each directed sequence containing such transactions and executes it, allowing for concurrent execution between directed sequences—that is, pending transactions from different smart contracts are executed concurrently. At the start of parallel execution, the number of pending transactions is the same as the number of directed sequences containing such transactions. Since the number of pending transactions within a directed sequence varies and concurrent execution only occurs between directed sequences, pending transactions belonging to the same directed sequence are not executed concurrently. As transactions are executed, the number of concurrently executed pending transactions may decrease. Once all pending transactions in a directed sequence have been executed, the blockchain node retrieves another pending transaction from that sequence for execution, continuing until all pending transactions in that directed sequence have been executed. It is understandable that the number of transactions included in a block is finite; therefore, pending transactions in a directed sequence can be executed in batches, generating multiple blocks. All pending transactions to be added to a block are executed and merged to obtain the transaction execution result. For example, if a block can contain a maximum of 10 transactions, the transaction execution result will contain a maximum of 10 execution results corresponding to the 10 pending transactions.

[0111] Step S240: Package the transaction execution results to generate a transaction block.

[0112] Blockchain nodes package the transaction execution results into transaction blocks and upload them to the blockchain, thus completing the transaction processing. Transaction blocks typically also include information about the transaction to be processed, information about the transacting parties, the transaction time, and consensus information.

[0113] In the embodiments of this application, after a blockchain node obtains at least two pending transactions to be processed, it adds the at least two pending transactions to a directed sequence corresponding to the smart contract identifiers in each pending transaction. Then, it executes the pending transactions in the directed sequence in parallel to obtain the transaction execution results. Finally, it packages the transaction execution results to generate a transaction block. Through this method, during transaction execution, transactions are divided into different execution sequences based on different smart contracts, allowing blockchain transactions based on different smart contracts to be executed in parallel. The dependencies between transactions can be determined without pre-executing transactions, eliminating the need for pre-executing transactions during the transaction execution process. This reduces the time consumed in the transaction execution process, improves the execution efficiency of the blockchain transaction process, and ultimately increases the transaction throughput of the blockchain system.

[0114] In one embodiment of this application, based on the above technical solution, please refer to... Figure 3 , Figure 3 This is a schematic flowchart illustrating a blockchain transaction processing method according to an embodiment of this application. In this embodiment, the directed sequence is the transaction queue in the transaction pool, such as... Figure 3 As shown, step S220 above, which adds at least two pending transactions to the directed sequence corresponding to the smart contract identifiers, specifically includes the following steps:

[0115] Step S310: Determine the transaction type of the pending transaction based on the smart contract identifier of the pending transaction;

[0116] Step S320: If the transaction type is a smart contract execution type, then obtain the transaction queue corresponding to the smart contract identifier;

[0117] Step S330: Add the pending transactions to the transaction queue corresponding to the smart contract identifier according to the execution order of the transactions.

[0118] In this embodiment, the solution of this application is applied to optimize the transaction pool of a blockchain node. Typically, blockchain nodes centrally execute and upload transactions after receiving a certain number of pending transactions. Therefore, upon receiving pending transactions, a blockchain node temporarily stores them in a transaction pool, and retrieves a certain number of pending transactions from the pool to generate transaction blocks when needed. In this embodiment, this is specifically achieved through multiple transaction queues. The blockchain node creates a corresponding transaction queue in the transaction pool for each smart contract identifier based on the transaction. The blockchain node distinguishes the transaction type of the pending transactions based on the smart contract identifier. The transaction types of pending transactions include smart contract execution type, smart contract creation type, and smart contract modification type. Specifically, the smart contract execution type indicates that the smart contract to be executed by the pending transaction is already uploaded to the blockchain; the smart contract creation type and smart contract modification type indicate that the smart contract in the transaction has not yet been uploaded to the blockchain. Therefore, the smart contract to be executed can be determined based on the smart contract identifier of the pending transaction, and the transaction type of the pending transaction can be determined based on whether the smart contract has been uploaded to the blockchain. For smart contracts already on the blockchain, a corresponding transaction queue is created in the transaction pool during the smart contract onboarding process. Therefore, if the transaction type to be processed is a smart contract execution type, the transaction queue corresponding to the smart contract identifier can be directly obtained. Subsequently, blockchain nodes add the transactions to be processed to the transaction queue corresponding to the smart contract identifier according to the execution order of the transactions. Specifically, transactions to be processed can be added to the transaction queue according to the time order in which they were received, or they can be added to the transaction queue according to the pre-configured logical relationship between smart contracts.

[0119] In the embodiments of this application, the pending transaction is added to the transaction queue corresponding to the smart contract identifier in the transaction pool according to the smart contract identifier of the pending transaction. This allows pending transactions executing different smart contracts to be separated in the transaction pool, which is beneficial for more pending transactions that can be executed in parallel from the transaction pool, thereby improving the efficiency of parallel execution of pending transactions.

[0120] In one embodiment of this application, based on the above technical solution, please refer to... Figure 4 , Figure 4 This is a schematic flowchart illustrating a blockchain transaction processing method according to an embodiment of this application. In this embodiment, as... Figure 4 As shown, after determining the transaction type of the transaction to be processed based on the smart contract identifier of the transaction to be processed in step S310 above, the blockchain transaction processing method of this application further includes the following steps:

[0121] Step S410: If the transaction type is a smart contract creation type or a smart contract modification type, then execute the pending transaction and obtain the transaction result;

[0122] Step S420: Based on the smart contract call process in the transaction result, create a transaction queue in the transaction pool corresponding to the smart contract identifier.

[0123] Specifically, if the transaction type of the pending transaction is a smart contract creation type or a smart contract modification type, it means that the smart contract to be executed in the pending transaction is a new smart contract that has not yet been recorded on the blockchain. Therefore, it is necessary to record the smart contract on the blockchain first, and create a transaction queue corresponding to the new smart contract in the transaction pool so that the pending transactions of the new smart contract can be distinguished and stored from the pending transactions of other smart contracts during subsequent transaction execution. Specifically, for pending transactions of the smart contract creation type or smart contract modification type, the calculation process of the pending transaction is first executed, and the calculation result is waited for to be packaged and recorded on the blockchain. The transaction block after being recorded on the blockchain can be used as the transaction result, or the transaction-related information can be obtained from the transaction block after being recorded on the blockchain as the transaction result. The transaction result will include the smart contract call process information of the new smart contract. Subsequently, based on the smart contract call process in the transaction result, the blockchain node can create a transaction queue corresponding to the smart contract identifier in the transaction pool. The correspondence between the smart contract identifier and the transaction queue can be stored in the blockchain or stored in the node device.

[0124] In the embodiments of this application, when a new smart contract is carried in a transaction to be processed, a corresponding transaction queue is created in the transaction pool after the new smart contract is added to the chain. This enables the automatic creation of a corresponding transaction queue when a new smart contract is added to the blockchain, which helps to simplify the management of transaction queues in the transaction pool and improve the overall management efficiency of the blockchain system.

[0125] In one embodiment of this application, based on the above technical solution, please refer to... Figure 5 , Figure 5 This is a schematic flowchart illustrating a blockchain transaction processing method according to an embodiment of this application. In this embodiment, as... Figure 5 As shown, step S220 above, which adds at least two pending transactions to the directed sequence corresponding to the smart contract identifiers, specifically includes the following steps:

[0126] Step S510: Determine the set of smart contract identifiers to which each smart contract identifier contained in the transaction to be processed belongs. The set of smart contract identifiers includes smart contract identifiers with smart contract call relationships. Each set of smart contract identifiers corresponds to a different directed sequence.

[0127] Step S520: Based on the smart contract identifier set and the smart contract identifiers in each pending transaction, add at least two pending transactions to the corresponding directed sequence, wherein the pending transactions in the directed sequence are sorted according to the smart contract call relationship and the execution order of the pending transactions.

[0128] In the embodiments of this application, smart contracts have mutual calling relationships, meaning that during the execution of one smart contract, another smart contract may be called. Therefore, the execution of one smart contract requires the execution of two smart contracts, which are not executed in parallel but sequentially. Thus, smart contracts with calling relationships need to be added to the same directed sequence for sequential execution. Specifically, the blockchain node first determines the set of smart contract identifiers to which the smart contract identifiers contained in each pending transaction belong. This set includes smart contract identifiers with calling relationships, and each set corresponds to a different directed sequence. The smart contract identifier set is created during the smart contract's on-chain process and includes the smart contract identifiers of other smart contracts called by the smart contract. For example, the specific form of the smart contract identifier set could be <the smart contract identifiers of this contract, and all smart contract identifiers called by this contract>. After determining the set of smart contract identifiers to which the smart contract identifiers belong, the blockchain node adds at least two pending transactions to the corresponding directed sequence based on the smart contract identifier set and the smart contract identifiers in each pending transaction. Specifically, based on the set of smart contract identifiers to which the smart contract identifier in the pending transaction belongs, the pending transaction is added to the directed sequence corresponding to the set of smart contract identifiers. In the directed sequence, pending transactions are sorted according to the smart contract call relationship and the execution order of the pending transactions.

[0129] In the embodiments of this application, the directed sequence corresponds to the set of smart contract identifiers. Through the set of smart contract identifiers, pending transactions under smart contracts with smart contract call relationships are added to the same directed sequence, thereby ensuring that pending transactions executed in parallel will not cause errors due to smart contract execution conflicts, and improving the stability of the blockchain system.

[0130] In one embodiment of this application, based on the above technical solution, please refer to... Figure 6 , Figure 6 This is a schematic flowchart illustrating a blockchain transaction processing method according to an embodiment of this application. In this embodiment, the directed sequence is the transaction queue in the transaction pool, such as... Figure 6 As shown, step S520 above, which adds at least two pending transactions to the corresponding directed sequence based on the smart contract identifier set and the smart contract identifiers in each pending transaction, specifically includes the following steps:

[0131] Step S610: Determine the transaction type of the pending transaction based on the smart contract identifier of the pending transaction;

[0132] Step S620: If the transaction type is a smart contract execution type, then obtain the transaction queue corresponding to the smart contract identifier set according to the smart contract identifier set to which the smart contract identifier belongs;

[0133] Step S630: Add the pending transactions to the transaction queue corresponding to the smart contract identifier according to the execution order of the transactions.

[0134] Specifically, in the embodiments of this application, the directed sequence is a transaction queue in the transaction pool. Depending on whether other smart contracts are called during the execution of the smart contract, the transaction queue in the transaction pool can correspond to a smart contract identifier or a set of smart contract identifiers. It is understood that even if no other smart contracts are called, a set of smart contract identifiers can be established based on the smart contract identifier itself. For clarity, please refer to [link to relevant documentation]. Figure 7 , Figure 7 This is a schematic diagram of the transaction pool structure in an embodiment of this application. Figure 7 As shown, the transaction pool contains multiple transaction queues, namely transaction queues 1 to 4, each corresponding to a different smart contract. Transaction queues 1 and 3 correspond to sets of smart contract identifiers containing two smart contract identifiers, while transaction queues 2 and 4 directly correspond to smart contract identifiers, or can be understood as corresponding to sets of smart contract identifiers containing one smart contract identifier. Based on this transaction pool, when adding a transaction to be processed, the transaction type is first determined according to the smart contract identifier of the transaction. The transaction types include smart contract execution type, smart contract creation type, and smart contract modification type. Among them, smart contract execution type indicates that the smart contract to be executed by the transaction is a smart contract that has already been uploaded to the blockchain, while smart contract creation type and smart contract modification type indicate that the smart contract in the transaction has not yet been uploaded to the blockchain. If the transaction type is smart contract execution type, it means that there is a corresponding transaction queue in the transaction pool. Therefore, the transaction queue corresponding to the smart contract identifier set can be obtained from the transaction pool according to the smart contract identifier set to which the smart contract identifier belongs. Subsequently, based on the execution order of the transactions, the pending transactions are added to the transaction queue corresponding to the smart contract identifier. For example, if pending transaction X executes smart contract A and pending transaction Y executes smart contract C, they will both be added to transaction queue 1 when placed in the transaction pool, and sorted in the order of pending transaction X -> pending transaction Y. In one embodiment, the pending transactions in the transaction queue can also be sorted according to the receipt time of the pending transactions.

[0135] In the embodiments of this application, for pending transactions under smart contracts with smart contract call relationships, the pending transactions are added to the transaction queue corresponding to the smart contract identifier set according to the smart contract identifier. Under the premise of ensuring that the execution of smart contracts does not conflict, pending transactions executing different smart contracts are separated, which is conducive to more pending transactions that can be executed in parallel from the transaction pool, thereby improving the throughput of the transaction pool.

[0136] In one embodiment of this application, based on the above technical solution, please refer to... Figure 8 , Figure 8 This is a schematic flowchart illustrating a blockchain transaction processing method according to an embodiment of this application. In this embodiment, as... Figure 8 As shown, after determining the transaction type of the transaction to be processed based on the smart contract identifier of the transaction to be processed in step S610 above, the blockchain transaction processing method of this application further includes the following steps:

[0137] Step S810: If the transaction type is a smart contract creation type or a smart contract modification type, then execute the pending transaction and obtain the transaction result;

[0138] Step S820: Based on the smart contract call process in the transaction result, create a smart contract identifier set and create a corresponding transaction queue in the transaction pool. The smart contract identifier set includes the smart contract identifier of the transaction to be processed and the smart contract identifier of the smart contract called during the execution of the transaction to be processed.

[0139] Specifically, if the transaction type of the pending transaction is a smart contract creation type or a smart contract modification type, it means that the smart contract to be executed in the pending transaction is a new smart contract that has not yet been recorded on the blockchain. Therefore, it is necessary to record the smart contract on the blockchain first, and create a transaction queue corresponding to the new smart contract in the transaction pool so that the pending transactions of the new smart contract can be distinguished and stored differently from the pending transactions of other smart contracts during subsequent transaction execution. After the smart contract is recorded on the blockchain, the blockchain node will obtain the smart contract identifiers called during the transaction execution process and the transaction results, create a smart contract identifier set, and create a transaction queue corresponding to the newly created smart contract identifier set in the transaction pool for the recorded smart contract and the smart contracts it calls. It can be understood that the solution in this embodiment is the process of adding the pending transaction to the transaction pool. Please refer to [link to relevant documentation]. Figure 9 , Figure 9 This is a flowchart illustrating the process of adding a transaction to the transaction pool in an embodiment of this application. Figure 9As shown, in step 901, the received transactions to be processed are usually transmitted in serialized form. Therefore, the blockchain node deserializes the transactions to obtain the transactions to be processed, which can also be considered transaction objects. Then, in step 902, the smart contract identifier, such as the smart contract name, is obtained from the transactions to be processed. Next, in step 903, the transaction processing type of the transactions to be processed is determined based on the obtained contract name. For example, if the obtained contract name exists in the blockchain, the transaction processing type is a contract execution transaction; otherwise, it is a contract creation or contract modification transaction. For contract execution transactions, in step 904, the blockchain node queries the transaction queue corresponding to the smart contract from the transaction pool, and in step 905, adds the transactions to be processed to the corresponding transaction queue. Finally, in step 906, the transaction is waited to be retrieved from the transaction queue for further packaging and on-chain processing. Returning to step 903, if there is no corresponding transaction queue in the transaction pool for a contract creation or modification transaction type, then in step 907, the process of triggering the packaging and execution of the transaction is waited for. For example, the pending transaction is directly added to the transaction pool without being placed in any queue, or it is placed in a dedicated queue and executed serially with all other pending transactions. After the transaction for creating or modifying a contract reaches consensus in the blockchain, in step 908, the blockchain node obtains the smart contract executed in the transaction and the smart contracts it calls during execution, thereby constructing a smart contract identifier set. Subsequently, in step 909, a transaction queue corresponding to the smart contract identifier set is created in the transaction pool. The created transaction queue supports the creation or modification of smart contracts and other smart contracts called by them.

[0140] In the embodiments of this application, when a new smart contract is carried in a transaction to be processed, a set of smart contract identifiers is created according to the calling relationship of the smart contracts after the new smart contract is added to the blockchain, and a corresponding transaction queue is created in the transaction pool for the set of smart contract identifiers. This allows the calling relationship between smart contracts and the establishment of a corresponding transaction queue to be automatically recorded when a new smart contract is added to the blockchain, which is beneficial for the automatic management and updating of the structure of the transaction pool and reduces the management cost of the transaction pool.

[0141] In one embodiment of this application, based on the above technical solution, please refer to... Figure 10 , Figure 10 This is a schematic flowchart illustrating a blockchain transaction processing method according to an embodiment of this application. In this embodiment, as... Figure 10 As shown, step S230 above, which executes the transactions to be processed in the directed sequence in parallel to obtain the transaction execution result, includes the following steps:

[0142] Step S1010: Based on the number of transactions contained in the block, retrieve the transactions to be processed from each transaction queue in the transaction pool to obtain a transaction set;

[0143] Step S1020: Determine the transaction execution sequence corresponding to the transaction set based on the transaction queue to which each pending transaction in the transaction set belongs. Among them, pending transactions belonging to different transaction queues in the transaction execution sequence are executed in parallel, and pending transactions belonging to the same transaction queue are executed serially.

[0144] Step S1030: Execute the pending transactions contained in the transaction set according to the transaction execution sequence to obtain the transaction execution result.

[0145] When a blockchain node packages and uploads pending transactions, it retrieves these transactions from the transaction pool. Based on the number of transactions a block can hold, the blockchain node obtains a transaction set from each transaction queue within the pool. The number of pending transactions in the transaction set is typically equal to the number of transactions a block can hold, unless the total number of pending transactions in the pool is less than the number of transactions a block can hold. It's understood that transaction queues can execute in parallel. Therefore, the blockchain node can determine the transaction execution sequence corresponding to the transaction set based on the transaction queue to which each pending transaction belongs. Specifically, the transaction execution sequence can be represented using a directed acyclic graph (DAG), where the pending transactions in each queue form a path within the DAG. Thus, pending transactions belonging to different queues in the execution sequence are executed in parallel (i.e., pending transactions on different paths in the DAG are executed in parallel), while pending transactions belonging to the same queue are executed sequentially (i.e., pending transactions on the same path in the DAG are executed sequentially). By executing pending transactions within a transaction set according to the transaction execution sequence, the various transaction queues can be executed in parallel, and the transaction results of all pending transactions constitute the transaction execution result. The following example illustrates this process; please refer to [link / reference]. Figure 11 , Figure 11 This is a schematic diagram illustrating the process of retrieving transactions to be processed from the transaction queue in an embodiment of this application. Figure 11 As shown, the transaction pool contains four transaction queues. When retrieving transactions to be processed, transactions are retrieved from each queue in turn. Figure 11In this block, the transaction queue is managed according to a first-in, first-out (FIFO) rule, and each block contains 6 transactions. Therefore, during the first retrieval of pending transactions, transactions Tx0, Tx4, Tx7, Tx9, Tx1, and Tx5 are retrieved in sequence according to the transaction queue. During the second retrieval, transactions Tx2, Tx6, Tx8, Tx10, and Tx3 are retrieved in sequence. It can be seen that during the second retrieval, because the number of transactions in the transaction pool is less than the maximum number of transactions a block can hold, the second block only contains 5 transactions, which is less than the maximum of 6 transactions. Figure 12 This is an example diagram illustrating the determination of the transaction execution sequence in an embodiment of this application. For example... Figure 12 As shown, the transaction sets obtained from the four transaction queues in the transaction pool include Tx0, Tx4, Tx7, Tx9, Tx1, and Tx5. Based on the transaction queue in the transaction pool where each pending transaction is located, the execution order of the pending transactions can be directly determined, thus directly determining the transaction execution sequence corresponding to the transaction set. Figure 12 In this process, transactions Tx0 and Tx1, as well as Tx4 and Tx5, have contract call relationships. Therefore, the determined transaction execution sequence includes four parallel execution groups: Tx0 and Tx1, Tx4 and Tx5, Tx6, and Tx8. Transactions within a group are executed serially, while transactions within a component can be executed in parallel. For example, at the start of execution, Tx0, Tx4, Tx6, and Tx8 can be executed in parallel, while Tx1 and Tx5 must wait for Tx0 and Tx4 to finish executing before they can be executed.

[0146] In the embodiments of this application, a transaction execution sequence is constructed based on the transaction queue in the transaction pool. The transaction execution sequence includes the parallel and serial execution relationship of the transactions to be processed. Then, the transactions to be processed are executed according to the transaction execution sequence, so that the transactions to be processed can be executed in parallel when executing the blocks to be processed, thereby improving the overall efficiency of executing multiple transactions to be processed.

[0147] In one embodiment of this application, based on the above technical solution, please refer to... Figure 13 , Figure 13 This is a schematic flowchart illustrating a blockchain transaction processing method according to an embodiment of this application. In this embodiment, as... Figure 13 As shown, step S1010 above, which involves retrieving pending transactions from various transaction queues in the transaction pool based on the number of transactions accommodated in the block, to obtain a transaction set, includes the following steps:

[0148] Step S1310: Obtain a transaction queue from the transaction pool as the current transaction queue;

[0149] Step S1320: If the current transaction queue is not empty, then take a transaction to be processed from the current transaction queue;

[0150] Step S1330: Compare the number of currently retrieved pending transactions with the number of transactions contained in the block;

[0151] Step S1340: If the number of pending transactions that have been retrieved is less than the number of transactions that can be accommodated in the block, then the next transaction queue is obtained from the transaction pool and pending transactions are retrieved until the number of pending transactions that have been retrieved meets the number of transactions that can be accommodated in the block, and a transaction set is obtained.

[0152] In this embodiment, when retrieving transactions to be processed, the blockchain node traverses all transaction queues in the transaction pool and takes out transactions to be processed from each queue in turn. Specifically, the blockchain node first retrieves a transaction queue from the transaction pool as the current transaction queue. The retrieved queue can be any transaction queue, and then checks whether the current transaction queue is empty. If it is empty, the next transaction queue is retrieved. If the current transaction queue is not empty, a transaction to be processed is taken from the current transaction queue. Subsequently, the number of transactions to be processed that have been retrieved is counted and compared with the number of transactions that can be contained in a block. If the number of transactions to be processed that have been retrieved is less than the number of transactions that can be contained in a block, it is necessary to continue retrieving transactions to be processed. The blockchain node retrieves the next transaction queue from the transaction pool and takes out transactions to be processed, repeating the process of retrieving queues and transactions to be processed until the number of transactions to be processed that have been retrieved meets the number of transactions that can be contained in a block, thus obtaining a transaction set. It is immediately apparent that the process of retrieving transaction queues is cyclical, that is, after reading all transaction queues once, the next round of reading of all queues is restarted.

[0153] In the embodiments of this application, transactions to be processed are obtained from each transaction queue in the transaction pool in a cyclical manner to form a transaction set, thereby maximizing the number of transactions that can be executed in parallel in each block, thus ensuring the parallel efficiency of transaction execution and improving the response speed of the transaction process in the blockchain system.

[0154] In one embodiment of this application, based on the above technical solution, please refer to... Figure 14 , Figure 14 This is a schematic flowchart illustrating a blockchain transaction processing method according to an embodiment of this application. In this embodiment, as... Figure 14 As shown, step S1340 above, which involves obtaining the next transaction queue from the transaction pool and retrieving the transactions to be processed, includes the following steps:

[0155] Step S1410: Check the remaining number of pending transactions in the transaction pool;

[0156] Step S1420: If the remaining quantity is greater than zero, continue to obtain the next transaction queue from the transaction pool and retrieve the transaction to be processed;

[0157] Step S1430: If the remaining quantity is zero, generate a transaction set based on the transactions that have been taken out and are yet to be processed.

[0158] During the process of retrieving pending transactions from the transaction queue, blockchain nodes determine whether to stop reading based on the number of pending transactions in the transaction pool. Specifically, when retrieving the next transaction queue from the transaction pool, the remaining number of pending transactions in the pool is checked first, i.e., the number of pending transactions in each transaction queue of the pool. If the remaining number of pending transactions is greater than zero, the next transaction queue will be retrieved, and attempts will be made to retrieve pending transactions from it. If the remaining number is zero, even if the number of pending transactions retrieved is less than the maximum number of transactions a block can hold, the blockchain node will still generate a transaction set based on the retrieved pending transactions. That is, the number of transactions included in the block generated this time will be less than the maximum number of transactions a block can hold. The overall process of retrieving pending transactions from the transaction queue of the transaction pool is described below; please refer to [link to documentation]. Figure 15 , Figure 15 This is a flowchart illustrating the overall process of obtaining transactions to be processed from the transaction pool in an embodiment of this application. Figure 15As shown, the blockchain node determines whether the conditions for obtaining a transaction are met based on factors such as elapsed time or the number of transactions received. If the conditions are met, in box 1501, it starts obtaining the next transaction queue from the transaction queue that was stopped when it last obtained a transaction from the transaction pool. If no stopped transaction queue is recorded, it starts from the first transaction queue or from any random transaction queue. Subsequently, in box 1502, the blockchain node records the total number N of all pending transactions in the current transaction pool, and in box 1503, it begins traversing all transaction queues in the transaction pool to obtain pending transactions. For the currently obtained transaction queue, in box 1504, it obtains the first transaction from the current transaction queue, and then in box 1505, it checks whether the obtained transaction is empty. If the transaction is empty, in box 1506, it can be confirmed that there are no pending transactions in the current transaction queue, so it traverses the next transaction queue and returns to box 1504 to continue execution. If the transaction obtained in box 1505 is not empty, then in box 1507, the transaction to be processed is retrieved from the current transaction queue, added to the transaction set, and the total number of transactions N is decremented by one. Subsequently, in box 1508, it is determined whether the number of transactions in the transaction set meets the number of transactions required to package a block. If it does, the process proceeds to box 1510, exiting the transaction pool traversal process, and the obtained transaction set is used as the result of obtaining the transaction to be processed, i.e., the transaction level of the block to be generated. If the number of transactions in the transaction set does not meet the number of transactions required to package a block, then in box 1509, it is determined whether the total number of transactions N is zero. If the total number of transactions N is zero, there are no other transactions to be processed in the transaction pool, and the process can proceed to box 1510 to complete the process of obtaining the transaction to be processed. Otherwise, if the total number of transactions N is not zero, the process iterates through the next transaction queue and returns to box 1504 to continue execution.

[0159] In the embodiments of this application, the process of obtaining transactions to be processed is determined by the total number of remaining transactions in the transaction pool. This avoids repeatedly obtaining transactions and wasting time when the number of transactions to be processed is less than the number of transactions in a block, thereby reducing the time loss in the block packaging process.

[0160] In one embodiment of this application, based on the above technical solution, please refer to... Figure 16 , Figure 16 This is a schematic flowchart illustrating a blockchain transaction processing method according to an embodiment of this application. In this embodiment, the directed sequence is a transaction list, such as... Figure 16 As shown, step S520 above, which adds at least two pending transactions to the corresponding directed sequence based on the smart contract identifier set and the smart contract identifiers in each pending transaction, includes the following steps:

[0161] Step S1610: Obtain a list of transactions corresponding to the target smart contract identifier set, based on the target smart contract identifier set to which the smart contract identifier contained in the transaction to be processed belongs;

[0162] Step S1620: Add the pending transactions to the transaction list corresponding to the smart contract identifier according to the execution order of the transactions;

[0163] Step S1630: When at least two pending transactions are added to the corresponding transaction list, a directed sequence is generated based on the transaction list.

[0164] Specifically, in this embodiment, the blockchain transaction processing method described in this application is applied to the process of executing transactions to be processed after obtaining them from the transaction pool. In this embodiment, the transaction pool can be an optimized transaction pool according to the above embodiments, i.e., the transaction pool includes a transaction queue, or it can be an unoptimized transaction pool. Specifically, for the obtained transactions to be processed, the blockchain node will obtain a transaction list corresponding to the target smart contract identifier set based on the target smart contract identifier set to which the smart contract identifier contained in the transaction to be processed belongs. The transaction list is a storage structure established locally by the blockchain node for grouping transactions to be processed. The blockchain node will establish a corresponding transaction list for each smart contract identifier set. After obtaining the transaction list, the blockchain node will add the transactions to be processed to the transaction list corresponding to the smart contract identifier according to the execution order of the transactions, thereby enabling the grouping of transactions to be processed based on the smart contract identifier. It can be understood that since smart contracts can call other smart contracts during execution, different smart contract identifiers can correspond to the same transaction list if they belong to the same smart contract identifier set. For each pending transaction, the process of obtaining and adding transactions to the transaction list is repeated. When all pending transactions have been added to their respective transaction lists, a directed sequence can be generated based on the transaction lists involved. That is, the pending transactions in each transaction list constitute a directed sequence.

[0165] In the embodiments of this application, when processing pending transactions obtained from the transaction pool, the pending transactions are added to the corresponding transaction list according to the smart contract identifier, thereby generating a directed sequence that conforms to the execution relationship of the pending transactions without the need to pre-execute the pending transactions, thus improving the efficiency of constructing the directed sequence.

[0166] In one embodiment of this application, based on the above technical solution, please refer to... Figure 17 , Figure 17 This is a schematic flowchart illustrating a blockchain transaction processing method according to an embodiment of this application. In this embodiment, as... Figure 16As shown, step S1610 above, which obtains a transaction list corresponding to the target smart contract identifier set based on the target smart contract identifier set to which the smart contract identifier contained in the transaction to be processed belongs, includes the following steps:

[0167] Step S1710: Based on the target smart contract identifier set to which the smart contract identifier belongs, check whether the transaction list corresponding to the target smart contract identifier set exists;

[0168] Step S1720: If the transaction list does not exist, create a transaction list corresponding to the target smart contract identifier set;

[0169] Step S1730: If the transaction list exists, obtain the transaction list corresponding to the target smart contract identifier set based on the target smart contract identifier set to which the smart contract identifier belongs.

[0170] In this embodiment, when a blockchain node retrieves a transaction list, it will create a corresponding transaction list if the list does not exist. Specifically, the blockchain node first checks whether a transaction list corresponding to the target smart contract identifier set exists, based on the target smart contract identifier set to which the smart contract identifier belongs. If the corresponding transaction list does not exist, it means that in the pending transactions being processed, the smart contracts of already processed pending transactions and the smart contract of the pending transaction can be executed in parallel. Therefore, the blockchain node will create a transaction list corresponding to the target smart contract identifier set to facilitate grouping and storing pending transactions. If the transaction list exists, it means that in the pending transactions being processed, transactions executing the same smart contract or executing smart contracts with a calling relationship have already been processed, and the corresponding transaction list was already established during previous processing. Therefore, the transaction list corresponding to the target smart contract identifier set can be retrieved based on the target smart contract identifier set to which the smart contract identifier belongs. Please refer to [link to relevant documentation]. Figure 18 , Figure 18 This is a schematic flowchart illustrating the construction of a directed sequence of transactions to be processed in an embodiment of this application. For example... Figure 18As shown, after obtaining the pending transactions to be added to the block, the blockchain node traverses the transaction set in the block in box 1801, and obtains the smart contract name in the pending transaction in box 1802 as the smart contract identifier. Then, in box 1803, it checks whether the transaction list corresponding to the smart contract has been created. If not, it creates the transaction list corresponding to the target smart contract identifier set in box 1804. If the transaction list has been created, it proceeds to box 1805 to add the pending transaction to the corresponding transaction list. Then, in box 1806, it checks whether the pending transactions have been traversed completely. If the traversal is not complete, it returns to box 1802 to continue processing the next transaction; if the traversal is complete, it proceeds to box 1807 to output all transaction lists as a directed sequence. The pending transactions in each transaction list form a directed sequence according to their execution order.

[0171] In the embodiments of this application, when obtaining the transaction list, if the transaction list does not exist, a corresponding transaction list will be created. This eliminates the need to continuously maintain the storage structure corresponding to each smart contract identifier set, reducing the computing and storage resources occupied by the blockchain node and helping to reduce the operating cost of the blockchain node.

[0172] In one embodiment of this application, based on the above technical solution, please refer to... Figure 19 , Figure 19 This is a schematic flowchart illustrating a blockchain transaction processing method according to an embodiment of this application. In this embodiment, as... Figure 19 As shown, step S230 above, which executes the transactions to be processed in the directed sequence in parallel to obtain the transaction execution result, includes the following steps:

[0173] Step S1910: Based on the transaction lists to which at least two pending transactions belong, generate a transaction execution sequence corresponding to the transaction set, wherein pending transactions belonging to the same transaction list are executed serially, and pending transactions belonging to different transaction lists are executed in parallel.

[0174] Step S1920: Execute at least two pending transactions according to the transaction execution sequence to obtain the transaction execution result.

[0175] Specifically, after obtaining the transaction list, the blockchain nodes generate a transaction execution sequence corresponding to the transaction set based on the transaction list to which the transactions to be processed belong. The transaction execution sequence can take the form of a directed acyclic graph. For a clearer explanation, please refer to [link to relevant documentation]. Figure 20 , Figure 20 This is a schematic diagram of the transaction list in an embodiment of this application. For example... Figure 20As shown, the pending transactions in the transaction pool are sorted by reception time, and the pending transactions retrieved from the transaction pool also follow a first-in, first-out (FIFO) rule. Therefore, the pending transactions retrieved for a block are Tx0 to Tx5. Subsequently, during processing, the pending transactions are divided into different transaction queues according to their contract call relationships. Figure 20 Transactions Tx0 and Tx3, and Tx1 and Tx4, have a calling relationship. Therefore, Tx0 and Tx3 are added to the same transaction queue, Tx1 and Tx4 are added to another transaction list, and Tx2 and Tx5 are added to separate transaction lists. Based on these lists, a transaction execution sequence can be formed. Transactions belonging to the same transaction list are executed serially, while transactions belonging to different transaction lists are executed in parallel. For example... Figure 20 Transactions Tx0, Tx1, Tx2, and Tx5 can be executed in parallel, while Tx0 and Tx3 must be executed sequentially. At least two transactions must be executed according to the transaction execution sequence to obtain the transaction execution result.

[0176] In the embodiments of this application, during the transaction execution process, the parallel and serial states of transactions to be processed are managed according to the relationship of the transaction list. This allows the transaction execution sequence to be constructed at the time of block generation without having to determine the transaction relationship between individual transactions through execution, thereby improving the processing efficiency of constructing the transaction execution sequence.

[0177] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0178] The following describes the implementation of the apparatus of this application, which can be used to execute the blockchain transaction processing method in the above embodiments of this application. Figure 21 A schematic block diagram illustrating the composition of a blockchain transaction processing apparatus in an embodiment of this application is shown. Figure 21 As shown, the blockchain transaction processing device 2100 mainly includes:

[0179] The transaction acquisition module 2110 is used to acquire at least two pending transactions, which include smart contract identifiers.

[0180] The transaction addition module 2120 is used to add at least two pending transactions to a directed sequence corresponding to the smart contract identifier based on the smart contract identifier in each pending transaction. Each smart contract identifier corresponds to a directed sequence, and the directed sequence is used to indicate the execution order of the pending transactions.

[0181] The parallel execution module 2130 is used to execute transactions to be processed in a directed sequence in parallel to obtain transaction execution results;

[0182] The block generation module 2140 is used to package the transaction execution results into transaction blocks.

[0183] In some embodiments of this application, based on the above technical solutions, the directed sequence is a transaction queue in the transaction pool; the transaction joining module 2120 includes:

[0184] The type determination submodule is used to determine the transaction type of the transaction to be processed based on the smart contract identifier of the transaction to be processed;

[0185] The queue retrieval submodule is used to retrieve the transaction queue corresponding to the smart contract identifier if the transaction type is a smart contract execution type.

[0186] The queue addition submodule is used to add pending transactions to the transaction queue corresponding to the smart contract identifier, based on the execution order of the transactions.

[0187] In some embodiments of this application, based on the above technical solutions, the blockchain transaction processing device further includes:

[0188] The transaction execution module is used to execute pending transactions and obtain transaction results if the transaction type is a smart contract creation type or a smart contract modification type.

[0189] The queue creation module is used to create transaction queues in the transaction pool corresponding to the smart contract identifiers based on the smart contract call process in the transaction results.

[0190] In some embodiments of this application, based on the above technical solutions, the transaction joining module 2120 includes:

[0191] The set determination submodule is used to determine the set of smart contract identifiers to which each smart contract identifier contained in each pending transaction belongs. The smart contract identifier set includes smart contract identifiers with smart contract call relationships, and each smart contract identifier set corresponds to a different directed sequence.

[0192] The sequence addition submodule is used to add at least two pending transactions to the corresponding directed sequence based on the smart contract identifier set and the smart contract identifiers in each pending transaction. The pending transactions in the directed sequence are sorted according to the smart contract call relationship and the execution order of the pending transactions.

[0193] In some embodiments of this application, based on the above technical solutions, the directed sequence is a transaction queue in the transaction pool; the added sequence submodule includes:

[0194] The type determination unit is used to determine the transaction type of the transaction to be processed based on the smart contract identifier of the transaction to be processed;

[0195] The queue acquisition unit is used to acquire the transaction queue corresponding to the smart contract identifier set based on the smart contract identifier set to which the smart contract identifier belongs if the transaction type is a smart contract execution type.

[0196] The queue unit is used to add pending transactions to the transaction queue corresponding to the smart contract identifier, based on the execution order of the transactions.

[0197] In some embodiments of this application, based on the above technical solutions, the addition of the sequence submodule further includes:

[0198] The transaction execution unit is used to execute pending transactions and obtain transaction results if the transaction type is a smart contract creation type or a smart contract modification type.

[0199] The set creation unit is used to create a set of smart contract identifiers based on the smart contract call process in the transaction result, and to create a corresponding transaction queue in the transaction pool. The set of smart contract identifiers includes the smart contract identifiers of the transactions to be processed and the smart contract identifiers of the smart contracts called during the execution of the transactions to be processed.

[0200] In some embodiments of this application, based on the above technical solutions, the parallel execution module 2130 includes:

[0201] The transaction retrieval submodule is used to retrieve pending transactions from various transaction queues in the transaction pool based on the number of transactions that a block can contain, thus obtaining a transaction set.

[0202] The sequence determination submodule is used to determine the transaction execution sequence corresponding to the transaction set based on the transaction queue to which each pending transaction in the transaction set belongs. Pending transactions belonging to different transaction queues in the transaction execution sequence are executed in parallel, while pending transactions belonging to the same transaction queue are executed serially.

[0203] The first transaction execution submodule is used to execute the pending transactions contained in the transaction set according to the transaction execution sequence, and obtain the transaction execution result.

[0204] In some embodiments of this application, based on the above technical solutions, the transaction acquisition submodule includes:

[0205] The first queue acquisition unit is used to acquire a transaction queue from the transaction pool as the current transaction queue;

[0206] The transaction retrieval unit is used to retrieve a pending transaction from the current transaction queue if the current transaction queue is not empty.

[0207] The quantity comparison unit is used to compare the number of currently retrieved pending transactions with the number of transactions that can be contained in the block;

[0208] The second queue acquisition unit is used to retrieve the next transaction queue from the transaction pool and retrieve the pending transactions if the number of currently retrieved pending transactions is less than the number of transactions that the block can accommodate, until the number of currently retrieved pending transactions meets the number of transactions that the block can accommodate, thus obtaining a transaction set.

[0209] In some embodiments of this application, based on the above technical solutions, the second queue acquisition unit includes:

[0210] The quantity check subunit is used to check the remaining quantity of pending transactions in the transaction pool;

[0211] The queue retrieves sub-units, which are used to continue retrieving the next transaction queue from the transaction pool and taking out the transaction to be processed if the remaining quantity is greater than zero;

[0212] The set generates a sub-unit, which is used to generate a transaction set based on the transactions that have been taken out if the remaining quantity is equal to zero.

[0213] In some embodiments of this application, based on the above technical solutions, the directed sequence is a transaction list; the added sequence submodule includes:

[0214] The list retrieval unit is used to retrieve a list of transactions corresponding to the target smart contract identifier set, based on the target smart contract identifier set to which the smart contract identifier contained in the transaction to be processed belongs;

[0215] The list addition unit is used to add pending transactions to the transaction list corresponding to the smart contract identifier according to the execution order of the transactions;

[0216] The sequence generation unit is used to generate a directed sequence based on the transaction list when at least two transactions to be processed have been added to the corresponding transaction list.

[0217] In some embodiments of this application, based on the above technical solutions, the list acquisition unit includes:

[0218] The list check sub-unit is used to check whether a transaction list corresponding to the target smart contract identifier set exists, based on the target smart contract identifier set to which the smart contract identifier belongs;

[0219] The list creation sub-unit is used to create a transaction list corresponding to the target smart contract identifier set if the transaction list does not exist.

[0220] The list retrieval sub-unit is used to retrieve the transaction list corresponding to the target smart contract identifier set, based on the target smart contract identifier set to which the smart contract identifier belongs, if the transaction list exists.

[0221] In some embodiments of this application, based on the above technical solutions, the parallel execution module 2130 includes:

[0222] The execution sequence generation submodule is used to generate a transaction execution sequence corresponding to a transaction set based on the transaction lists to which at least two pending transactions belong. Pending transactions belonging to the same transaction list are executed serially, while pending transactions belonging to different transaction lists are executed in parallel.

[0223] The second transaction execution submodule is used to execute at least two pending transactions according to the transaction execution sequence to obtain the transaction execution result.

[0224] It should be noted that the apparatus provided in the above embodiments and the method provided in the above embodiments belong to the same concept, and the specific way in which each module performs the operation has been described in detail in the method embodiments, and will not be repeated here.

[0225] Figure 22 A schematic diagram of a computer system suitable for implementing the embodiments of this application is shown. It should be noted that... Figure 22 The computer system 2200 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0226] like Figure 22As shown, the computer system 2200 includes a Central Processing Unit (CPU) 2201, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 2202 or programs loaded from Storage Unit 2208 into Random Access Memory (RAM) 2203. The RAM 2203 also stores various programs and data required for system operation. The CPU 2201, ROM 2202, and RAM 2203 are interconnected via a bus 2204. An Input / Output (I / O) interface 2205 is also connected to the bus 2204.

[0227] The following components are connected to I / O interface 2205: an input section 2206 including a keyboard, mouse, etc.; an output section 2207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 2208 including a hard disk, etc.; and a communication section 2209 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 2209 performs communication processing via a network such as the Internet. A drive 2210 is also connected to I / O interface 2205 as needed. Removable media 2211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 2210 as needed so that computer programs read from them can be installed into storage section 2208 as needed.

[0228] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 2209, and / or installed from removable medium 2211. When the computer program is executed by central processing unit (CPU) 2201, it performs various functions defined in the system of this application.

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

[0230] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0231] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0232] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0233] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0234] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A blockchain transaction processing method, characterized in that, include: Obtain at least two pending transactions, wherein the pending transactions include smart contract identifiers; Determine the set of smart contract identifiers to which each smart contract identifier contained in a pending transaction belongs. The set of smart contract identifiers includes smart contract identifiers with smart contract call relationships. Each set of smart contract identifiers corresponds to a different directed sequence. The directed sequence is a transaction queue in the transaction pool, and the transaction pool contains multiple directed sequences. Based on the set of smart contract identifiers and the smart contract identifiers in each pending transaction, the at least two pending transactions are added to the corresponding directed sequence, wherein the pending transactions in the directed sequence are sorted according to the smart contract call relationship and the execution order of the pending transactions; Based on the number of transactions contained in the block, transactions to be processed are obtained from each transaction queue of the transaction pool to obtain a transaction set; Based on the transaction queue to which each pending transaction in the transaction set belongs, the transaction execution sequence corresponding to the transaction set is determined, wherein pending transactions belonging to different transaction queues in the transaction execution sequence are executed in parallel, and pending transactions belonging to the same transaction queue are executed serially. The pending transactions contained in the transaction set are executed according to the transaction execution sequence to obtain the transaction execution result; The transaction execution results are packaged to generate a transaction block.

2. The method according to claim 1, characterized in that, The method further includes: The transaction type of the pending transaction is determined based on the smart contract identifier of the pending transaction; If the transaction type is a smart contract execution type, then obtain the transaction queue corresponding to the smart contract identifier; According to the execution order of the transactions, the pending transactions are added to the transaction queue corresponding to the smart contract identifier.

3. The method according to claim 2, characterized in that, After determining the transaction type of the pending transaction based on its smart contract identifier, the method further includes: If the transaction type is a smart contract creation type or a smart contract modification type, then the pending transaction is executed to obtain the transaction result; Based on the smart contract call process in the transaction result, a transaction queue corresponding to the smart contract identifier is created in the transaction pool.

4. The method according to claim 1, characterized in that, The step of adding the at least two pending transactions to the corresponding directed sequence based on the smart contract identifier set and the smart contract identifiers in each pending transaction includes: The transaction type of the pending transaction is determined based on the smart contract identifier of the pending transaction; If the transaction type is a smart contract execution type, then obtain the transaction queue corresponding to the smart contract identifier set according to the smart contract identifier set to which the smart contract identifier belongs; According to the execution order of the transactions, the pending transactions are added to the transaction queue corresponding to the smart contract identifier.

5. The method according to claim 4, characterized in that, After determining the transaction type of the pending transaction based on its smart contract identifier, the method further includes: If the transaction type is a smart contract creation type or a smart contract modification type, then the pending transaction is executed to obtain the transaction result; Based on the smart contract call process in the transaction result, a smart contract identifier set is created, and a corresponding transaction queue is created in the transaction pool. The smart contract identifier set includes the smart contract identifier of the pending transaction and the smart contract identifier of the smart contract called during the execution of the pending transaction.

6. The method according to claim 1, characterized in that, The step of obtaining a transaction set by retrieving pending transactions from each transaction queue of the transaction pool based on the number of transactions contained in the block includes: Obtain a transaction queue from the transaction pool as the current transaction queue; If the current transaction queue is not empty, then a transaction to be processed is taken from the current transaction queue; Compare the number of currently retrieved pending transactions with the number of transactions contained in the block; If the number of pending transactions retrieved is less than the number of transactions that the block can accommodate, then the next transaction queue is obtained from the transaction pool and pending transactions are retrieved until the number of pending transactions retrieved meets the number of transactions that the block can accommodate, thus obtaining a transaction set.

7. The method according to claim 6, characterized in that, The step of obtaining the next transaction queue from the transaction pool and retrieving the transactions to be processed includes: Check the remaining number of pending transactions in the transaction pool; If the remaining quantity is greater than zero, then continue to obtain the next transaction queue from the transaction pool and retrieve the transactions to be processed; If the remaining quantity is zero, then a transaction set is generated based on the transactions that have been taken out and are yet to be processed.

8. The method according to claim 1, characterized in that, The directed sequence is a transaction list; the step of adding at least two pending transactions to the corresponding directed sequence based on the smart contract identifier set and the smart contract identifiers in each pending transaction includes: Based on the target smart contract identifier set to which the smart contract identifier contained in the pending transaction belongs, obtain a transaction list corresponding to the target smart contract identifier set; According to the execution order of the transactions, the pending transactions are added to the transaction list corresponding to the smart contract identifier; When at least two pending transactions are added to their respective transaction lists, the directed sequence is generated based on the transaction lists.

9. The method according to claim 8, characterized in that, The step of obtaining a transaction list corresponding to the target smart contract identifier set based on the target smart contract identifier set to which the smart contract identifier contained in the transaction to be processed belongs includes: Based on the target smart contract identifier set to which the smart contract identifier belongs, check whether a transaction list corresponding to the target smart contract identifier set exists; If the transaction list does not exist, a transaction list corresponding to the target smart contract identifier set is created; If the transaction list exists, then based on the target smart contract identifier set to which the smart contract identifier belongs, obtain the transaction list corresponding to the target smart contract identifier set.

10. The method according to claim 8, characterized in that, The parallel execution of the transactions to be processed in the directed sequence to obtain the transaction execution results includes: Based on the transaction lists to which the at least two pending transactions belong, a transaction execution sequence corresponding to the transaction set is generated, wherein pending transactions belonging to the same transaction list are executed serially, and pending transactions belonging to different transaction lists are executed in parallel. The at least two pending transactions are executed according to the transaction execution sequence to obtain the transaction execution result.

11. A blockchain transaction processing device, characterized in that, include: The transaction acquisition module is used to acquire at least two pending transactions, wherein the pending transactions include smart contract identifiers; The set determination submodule is used to determine the set of smart contract identifiers to which each smart contract identifier contained in the transaction to be processed belongs. The set of smart contract identifiers includes smart contract identifiers with smart contract call relationships. Each set of smart contract identifiers corresponds to a different directed sequence. The directed sequence is a transaction queue in the transaction pool. The transaction pool contains multiple directed sequences. The sequence addition submodule is used to add at least two pending transactions to the corresponding directed sequence according to the smart contract identifier set and the smart contract identifiers in each pending transaction. The pending transactions in the directed sequence are sorted according to the smart contract call relationship and the execution order of the pending transactions. The transaction acquisition submodule is used to obtain pending transactions from each transaction queue of the transaction pool according to the number of transactions that the block can accommodate, and obtain a transaction set. The sequence determination submodule is used to determine the transaction execution sequence corresponding to the transaction set based on the transaction queue to which each pending transaction in the transaction set belongs. In the transaction execution sequence, pending transactions belonging to different transaction queues are executed in parallel, and pending transactions belonging to the same transaction queue are executed serially. The first transaction execution submodule is used to execute the pending transactions contained in the transaction set according to the transaction execution sequence, and obtain the transaction execution result; The block generation module is used to package the transaction execution results into transaction blocks.

12. An electronic device, characterized in that, include: processor; Memory for storing the executable instructions of the processor; The processor is configured to execute the blockchain transaction processing method according to any one of claims 1 to 10 by executing the executable instructions.

13. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the blockchain transaction processing method as described in any one of claims 1 to 10.

14. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium, and a processor of a computer device reads and executes the computer instructions from the computer-readable storage medium, causing the computer device to perform the blockchain transaction processing method as described in any one of claims 1 to 10.

Images