Block chain transaction processing method and device, equipment, medium and product

Abstract

The invention provides a block chain transaction processing method and device, equipment, a medium and a product. The method comprises the steps of obtaining N pre-verification transactions and a pre-execution result of each pre-verification transaction; n is a positive integer; analyzing the N pre-execution results, and determining a data dependency relationship among the N pre-verification transactions; dividing the N pre-verified transactions into M transaction subsets based on the data dependency relationship; each transaction subset comprises one or more pre-verification transactions, the pre-verification transactions in the same transaction subset have a data dependency relationship, and M is a positive integer and is less than or equal to N; respectively creating transaction tasks for the M transaction subsets, wherein one transaction task corresponds to one transaction subset; and packaging the target block based on the M transaction tasks, and performing parallel processing on the M transaction tasks in the target block on the block chain. According to the method and the device, parallel processing can be performed on each transaction in the block on the block chain, so that the transaction processing efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a blockchain transaction processing method, a blockchain transaction processing apparatus, a computer device, a computer-readable storage medium, and a computer program product. Background Art

[0002] In the blockchain, currently packaging nodes usually select a sufficient group of transactions from the transaction pool for verification, execution and assembly of new blocks only after collecting enough transactions (for example, 100 transactions), which will cause a lag in transaction execution; and the verification and execution of each transaction in the blockchain are executed serially, which will reduce the speed of packaging new blocks and reduce the efficiency of transaction execution. Summary of the invention

[0003] The embodiments of the present application propose a blockchain transaction processing method, device, equipment, medium and product, which can process each transaction in a block on the blockchain in parallel, thereby improving the efficiency of transaction processing.

[0004] On the one hand, an embodiment of the present application provides a blockchain transaction processing method, the method comprising:

[0005] Get N pre-verification transactions and the pre-execution results of each pre-verification transaction; N is a positive integer;

[0006] Analyze N pre-execution results and determine the data dependencies between N pre-verification transactions;

[0007] Based on data dependency, N pre-verified transactions are divided into M transaction subsets; each transaction subset contains one or more pre-verified transactions, and each pre-verified transaction in the same transaction subset has a data dependency relationship, M is a positive integer and M≤N;

[0008] Create transaction tasks for each of the M transaction subsets, with one transaction task corresponding to one transaction subset;

[0009] The target block is packaged based on M transaction tasks, and the M transaction tasks in the target block are processed in parallel on the blockchain.

[0010] On the one hand, an embodiment of the present application provides a blockchain transaction processing device, the device comprising:

[0011] An acquisition unit, used to acquire N pre-verification transactions and a pre-execution result of each pre-verification transaction; N is a positive integer;

[0012] A processing unit, configured to analyze the N pre-execution results and determine data dependencies between the N pre-verification transactions;

[0013] The processing unit is further used to divide the N pre-verified transactions into M transaction subsets based on data dependency; each transaction subset contains one or more pre-verified transactions, and each pre-verified transaction in the same transaction subset has a data dependency relationship, and M is a positive integer and M≤N;

[0014] The processing unit is further used to create transaction tasks for the M transaction subsets respectively, where one transaction task corresponds to one transaction subset;

[0015] The processing unit is also used to package the target block based on the M transaction tasks, and to process the M transaction tasks in the target block in parallel on the blockchain.

[0016] In a possible implementation, the pre-execution result includes a read data set and a write data set of the pre-verification transaction, and any two pre-verification transactions among the N pre-verification transactions are represented as pre-verification transaction i and pre-verification transaction j; the processing unit analyzes the N pre-execution results, determines the data dependency relationship between the N pre-verification transactions, and performs the following operations:

[0017] Performing data analysis on the pre-execution result of pre-verification transaction i and the pre-execution result of pre-verification transaction j to obtain a data analysis result;

[0018] Based on the data analysis results, determine the data dependency relationship between pre-verified transaction i and pre-verified transaction j;

[0019] Among them, the data dependency relationship between pre-verification transaction i and pre-verification transaction j includes any one or more of the following: a data dependency relationship between the read data set of pre-verification transaction i and the read data set of pre-verification transaction j, a data dependency relationship between the write data set of pre-verification transaction i and the write data set of pre-verification transaction j, a data dependency relationship between the read data set of pre-verification transaction i and the write data set of pre-verification transaction j, and a data dependency relationship between the write data set of pre-verification transaction i and the read data set of pre-verification transaction j.

[0020] In a possible implementation, both pre-verification transaction i and pre-verification transaction j belong to transactions in an asset transaction scenario; both the read data set and the write data set store data in a key-value pair format, where the key in the key-value pair refers to the account address; and the processing unit is further configured to perform the following operations:

[0021] If the account address of pre-verified transaction i is the same as the account address of pre-verified transaction j, it is determined that there is a data dependency relationship between pre-verified transaction i and pre-verified transaction j;

[0022] If the account address of pre-verification transaction i is different from the account address of pre-verification transaction j, it is determined that there is no data dependency relationship between pre-verification transaction i and pre-verification transaction j.

[0023] In a possible implementation, the read data set includes: a smart contract to be called to execute a pre-verified transaction; and the processing unit is further configured to perform the following operations:

[0024] If the smart contract that needs to be called by pre-verification transaction i is the same as the smart contract that needs to be called by pre-verification transaction j, it is determined that there is a data dependency relationship between pre-verification transaction i and pre-verification transaction j;

[0025] If the smart contract that needs to be called by pre-verification transaction i is different from the smart contract that needs to be called by pre-verification transaction j, it is determined that there is no data dependency relationship between pre-verification transaction i and pre-verification transaction j.

[0026] In a possible implementation, the processing unit divides N pre-verified transactions into M transaction subsets based on data dependencies, and performs the following operations:

[0027] If there is a data dependency relationship between pre-verified transaction i and pre-verified transaction j, pre-verified transaction i and pre-verified transaction j are classified into the same transaction subset;

[0028] If there is no data dependency relationship between pre-verification transaction i and pre-verification transaction j, pre-verification transaction i and pre-verification transaction j are respectively divided into different transaction subsets.

[0029] In a possible implementation, before obtaining N pre-verification transactions and the pre-execution result of each pre-verification transaction, the processing unit is further configured to perform the following operations:

[0030] Receive pending transactions and perform pre-verification on the transactions, including: verifying the validity of the smart contract to be called by the transaction, verifying the security of the transaction, and verifying the legitimacy of the transaction;

[0031] If it is determined that the transaction has passed the pre-verification process, the transaction will be treated as a pre-verified transaction;

[0032] Execute the pre-verification transaction and obtain the pre-execution result of the pre-verification transaction.

[0033] In a possible implementation, the processing unit executes the pre-verification transaction and obtains a pre-execution result of the pre-verification transaction, which is used to perform the following operations:

[0034] Create a transaction read cache and a transaction write cache for pre-verified transactions;

[0035] In the process of executing the pre-verification transaction, obtaining a read data set of the pre-verification transaction and storing the read data set of the pre-verification transaction in the transaction read cache; and,

[0036] Obtain a write data set for a pre-verified transaction and store the write data set for the pre-verified transaction in a transaction write cache.

[0037] In a possible implementation, the processing unit is further configured to perform the following operations:

[0038] Parse the transaction data of the target pre-verification transaction to obtain a read data set of the target pre-verification transaction, where the target pre-verification transaction is any pre-verification transaction among the N pre-verification transactions;

[0039] Determine the target smart contract to be called by the target pre-verification transaction from the read data set of the target pre-verification transaction;

[0040] Call the target smart contract to execute the target pre-verified transaction and obtain the transaction execution data of the target pre-verified transaction;

[0041] Add the transaction execution data to the write data set of the target pre-verification transaction.

[0042] In a possible implementation, the processing unit is further configured to perform the following operations:

[0043] Determine a serial transaction task from the M transaction tasks, where the serial transaction task includes a plurality of pre-verified transactions having data dependency relationships;

[0044] Add task tags to serial transaction tasks. Task tags are used to indicate the sequential execution of pre-verified transactions in the serial transaction tasks.

[0045] The target block with the task tag added is sent to at least one consensus node in the blockchain, so that after receiving the target block, the consensus node executes each pre-verification transaction in the serial transaction task in the order of the task tag, and executes the M transaction tasks in the target block in parallel.

[0046] In a possible implementation, the processing unit adds a task tag to the serial transaction task to perform the following operations:

[0047] Obtaining the pre-execution results of each pre-verification transaction included in the serial transaction task in the target block, the pre-execution results including the read data set and the write data set of the pre-verification transaction;

[0048] Analyze the read data set and write data set of each pre-verification transaction to determine the transaction execution order between each pre-verification transaction;

[0049] An execution order array for the serial transaction task is generated based on the determined transaction execution order, and a task tag for the serial transaction task is generated based on the execution order array.

[0050] In a possible implementation, the processing unit processes M transaction tasks in the target block in parallel on the blockchain to perform the following operations:

[0051] Determine the number K of serial transaction tasks among the M transaction tasks, where K is a positive integer;

[0052] Start K contract coroutines and start MK contract processes;

[0053] Execute M transaction tasks in the target block in parallel in K contract coroutines and MK contract processes;

[0054] Among them, a transaction task is executed by a contract coroutine or a contract process.

[0055] In a possible implementation, the processing unit is further configured to perform the following operations:

[0056] Determine the transaction execution order between each pre-verification transaction included in the serial transaction task;

[0057] According to the transaction execution order between each pre-verified transaction, each pre-verified transaction is executed sequentially in each contract coroutine.

[0058] On the one hand, an embodiment of the present application provides a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the above-mentioned blockchain transaction processing method.

[0059] On the one hand, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is read and executed by a processor of a computer device, the computer device executes the above-mentioned blockchain transaction processing method.

[0060] On the one hand, the embodiment of the present application provides a computer program product or a computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the above-mentioned blockchain transaction processing method.

[0061] In the embodiment of the present application, N pre-verification transactions and the pre-execution results of each pre-verification transaction can be obtained, N is a positive integer; the N pre-execution results are analyzed to determine the data dependency between the N pre-verification transactions; based on the data dependency, the N pre-verification transactions are divided into M transaction subsets; each transaction subset contains one or more pre-verification transactions, and each pre-verification transaction in the same transaction subset has a data dependency, M is a positive integer and M≤N; transaction tasks are created for each M transaction subset, one transaction task corresponds to one transaction subset; the target block is packaged based on the M transaction tasks, and the M transaction tasks in the target block are processed in parallel on the blockchain. It can be seen that the present application can perform pre-verification on each on-chain transaction and then pre-execute it, so as to obtain the pre-execution results of the pre-verification transaction, and the data dependency between each pre-verification transaction can be determined based on each pre-execution result, so that the pre-verification transaction can be divided into different transaction tasks according to the data dependency, and each transaction task can be executed in parallel in the blockchain, thereby realizing the parallel processing of blockchain transactions, which can improve the efficiency of transaction processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present application. For ordinary technical objects in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0063] Figure 1 It is a structural diagram of a blockchain system provided by an embodiment of the present application;

[0064] Figure 2 It is a schematic diagram of a transaction process of different types of nodes provided in an embodiment of the present application;

[0065] Figure 3a This is a schematic diagram of the structure of a blockchain provided by an embodiment of the present application;

[0066] Figure 3b It is a schematic diagram of a flow chart of generating a block provided in an embodiment of the present application;

[0067] Figure 4 It is a structural diagram of a blockchain transaction processing system provided by an embodiment of the present application;

[0068] Figure 5 It is a flowchart of a blockchain transaction processing method provided by an embodiment of the present application;

[0069] Figure 6 This is an interactive flow chart of blockchain transaction processing provided by an embodiment of the present application;

[0070] Figure 7 It is a flowchart of a transaction execution provided by an embodiment of the present application;

[0071] Figure 8 It is a structural schematic diagram of a blockchain transaction processing device provided in an embodiment of the present application;

[0072] Fig. 9 It is a structural diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0073] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0074] This application provides a blockchain transaction processing solution. First, it can pre-verify and pre-execute received transactions; second, it can split each pre-transaction contained in the block into several transaction tasks according to the data dependency relationship reflected by the pre-execution results of each pre-verified transaction, and then realize the parallel execution of multiple transaction tasks, thereby improving the efficiency of on-chain transaction processing. Specifically, the principle of the blockchain transaction processing solution provided by this application is as follows:

[0075] 1) When a blockchain node receives a new transaction, it can immediately perform pre-verification and pre-execution processing on the transaction to obtain the pre-execution result of the pre-verified transaction. Optionally, the pre-execution result of the pre-verified transaction can be stored in a pre-verification transaction pool.

[0076] 2) When a blockchain node needs to package a new block, it can obtain N pre-verified transactions and the pre-execution results of each pre-verified transaction from the pre-verified transaction pool; N is a positive integer.

[0077] 3) Next, the blockchain node can analyze the N pre-execution results and determine the data dependency between the N pre-verified transactions; and based on the data dependency, divide the N pre-verified transactions into M transaction subsets; each transaction subset contains one or more pre-verified transactions, and each pre-verified transaction in the same transaction subset has a data dependency relationship, M is a positive integer and M≤N. Then, create transaction tasks for each of the M transaction subsets, one transaction task corresponds to one transaction subset; finally, the target block can be packaged based on the M transaction tasks, and the M transaction tasks in the target block can be processed in parallel on the blockchain.

[0078] 4) Optionally, the blockchain node can also broadcast the packaged target block to other consensus nodes in the blockchain for block consensus. When the block consensus is passed, the target block can be added to the blockchain.

[0079] It can be seen from this that the present application can pre-verify and pre-execute each on-chain transaction, thereby obtaining the pre-execution result of the pre-verified transaction. Subsequently, the data dependency relationship between each pre-verified transaction can be determined based on each pre-execution result, so that the pre-verified transaction can be divided into different transaction tasks according to the data dependency relationship. Subsequently, each transaction task can be executed in parallel in the blockchain, thereby realizing parallel processing of blockchain transactions and improving the efficiency of transaction processing.

[0080] The following is a detailed introduction to the relevant technical terms involved in the blockchain transaction processing solution provided by this application.

[0081] 1. Pre-verification of transactions and pre-execution results

[0082] Pre-verification transactions, as the name implies, refer to transactions that have been pre-verified in the blockchain. Specifically, when a blockchain node receives a new transaction, it can immediately pre-verify the new transaction. The pre-verification process may include: verifying the legitimacy of the transaction, verifying the security of the transaction, verifying the validity of the smart contract requested by the transaction, etc. The result of the pre-verification process performed on the new transaction may include pre-verification passed or pre-verification failed.

[0083] The pre-execution result refers to the result obtained after the pre-execution processing of the pre-verified transaction is passed after the transaction pre-verification. Specifically, the pre-execution result may include: during the execution of the pre-verified transaction, the read data set of the pre-verified transaction, and the write data set of the pre-verified transaction. Among them, the read data set may include the call information of the smart contract required to be called in the process of executing the current transaction, and the call information may include but is not limited to: the call address, contract identifier, contract name, and contract version of the smart contract; the write data set may include the transaction execution result obtained after calling the smart contract to execute the current transaction. Among them, one transaction can correspond to one read data set and one write data set, and one transaction can also correspond to multiple read data sets and multiple write data sets.

[0084] 2. Data Dependencies

[0085] Data dependency is used to reflect the correlation between each pre-transaction transaction. The so-called correlation is a relationship used to measure whether any two pre-verification transactions are associated. For example, if there is a data dependency between pre-verification transaction 1 and pre-verification transaction 2, then it can be considered that pre-verification transaction 1 and pre-verification transaction 2 are mutually associated; if there is no data dependency between pre-verification transaction 2 and pre-verification transaction 3, then it can be considered that pre-verification transaction 1 and pre-verification transaction 2 are not mutually associated. In this application, the data dependency between pre-verification transactions can be analyzed based on the pre-execution results of the pre-verification transactions.

[0086] 3. Trading tasks

[0087] A trading task refers to a task created based on each pre-verified transaction. A trading task may include one or more pre-verified transactions. There is a data dependency between the pre-verified transactions in the same trading task. Therefore, the pre-verified transactions in the same trading task need to be executed serially. There is no data dependency between the pre-verified transactions in different trading tasks. Therefore, different trading tasks can be processed in parallel.

[0088] 4. Blockchain Technology

[0089] Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains relevant information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Specifically, this application will introduce the blockchain system and related terms such as blocks in detail.

[0090] (1) Blockchain system:

[0091] See also Figure 1 , Figure 1 This is a schematic diagram of the structure of a blockchain system provided by an embodiment of the present application. Figure 1 As shown, the blockchain system can be a data sharing system. The so-called data sharing system refers to a system for sharing data between node devices. The data sharing system 100 may include multiple node devices 101. The multiple node devices 101 may refer to various computer devices in the data sharing system. The computer device may be, for example, a terminal device or a server. Among them, the device types of different node devices 101 may be the same or different. For example, a certain node device 101 may be a terminal device, and another node device 101 may be a server.

[0092] exist Figure 1In the blockchain system shown, each node device 101 can receive input information when performing normal work, and maintain the shared data in the data sharing system based on the received input information. For example, when any node device 101 in the blockchain system receives a transaction on-chain request, the node device 101 can parse the transaction on-chain request to obtain the transaction to be on-chain, and then send the transaction to be on-chain to other blockchain nodes in the blockchain, so that each blockchain node can conduct a blockchain consensus on the current transaction. If the consensus is passed, the transaction can be written into the blockchain, thereby completing the on-chain processing of the transaction, so that each blockchain node on the blockchain can jointly maintain the transaction data (i.e., shared data) of the transaction in the blockchain.

[0093] (2) Blockchain Node:

[0094] ①Node type:

[0095] In the blockchain system, blockchain nodes can be divided into different types of nodes, such as packaging nodes and consensus nodes. Different types of nodes can have different node functions. For example, packaging nodes are mainly responsible for receiving new transactions and pre-verifying and pre-executing new transactions, and then packaging each pre-verified transaction to generate a consensus block (such as a target block); for example, consensus nodes are mainly responsible for receiving the target block and executing each pre-verified transaction in the target block. See Figure 2 , Figure 2 Schematic diagram of a transaction process of different types of nodes provided in the embodiment of the present application. Figure 2 As shown, after receiving a new transaction, the packaging node can immediately pre-verify and pre-execute the transaction to obtain the pre-execution result of the pre-verified transaction, and then the packaging node can package N pre-verified transactions according to the pre-execution results of the N pre-verified transactions to generate a target block. Subsequently, the packaging node can send the packaged target block to multiple consensus nodes, so that each consensus node can divide the N pre-verified transactions into M transaction tasks based on the pre-execution results of the N pre-verified transactions in the target block, and then execute the M transaction tasks in parallel in the blockchain.

[0096] ②Node function:

[0097] a. Application functions are used to be deployed in the blockchain to implement specific businesses according to actual business needs, and record data related to the implementation of business functions to form record data (such as transaction data). The business functions implemented by the transaction data on the blockchain may include, for example, resource transfer functions, game business functions, etc. In one implementation, a digital signature (such as a digital signature generated by signing the transaction data using the private key of the on-chain object) may be carried in the on-chain request for transaction data to indicate the source of the transaction data, and the transaction data may be sent to other nodes in the blockchain system, so that other nodes can add the transaction data to a temporary block when they successfully verify the source and integrity of the transaction data, thereby completing the on-chain processing of the transaction data.

[0098] b. Contract function. Any blockchain node in the blockchain system has the function of calling and executing the corresponding smart contract. The so-called smart contract (referred to as contract): smart contract has three major elements: commitment, agreement, and digital form. Therefore, it can expand the application scope of blockchain to all aspects of financial industry transactions, payments, settlements and liquidations. Smart contract means that when a pre-compiled condition is triggered, the smart contract will immediately execute the corresponding contract terms. Its working principle is similar to the if-then statement of a computer program. Among them, a smart contract virtual machine (a virtual machine that can execute smart contracts) runs in the blockchain node. The smart contract virtual machine can understand and execute these codes to realize the function of the smart contract. In this application, various types of smart contracts can be deployed in the blockchain node based on the contract function, so that the corresponding smart contract can be called in the blockchain to execute the corresponding contract transaction.

[0099] ③Node identification:

[0100] Each node in the blockchain system has a corresponding node identifier, and each node in the blockchain system can store the node identifiers of other nodes in the blockchain system, so that the generated blocks can be broadcast to other nodes in the blockchain system based on the node identifiers of other nodes. Each node can maintain a node identifier list as shown in the following table, and store the node name and node identifier in the node identifier list.

[0101] The node identifier may be an IP (Internet Protocol, a protocol for interconnecting networks) address or any other information that can be used to identify the node. Table 1 only uses the IP address as an example for description.

[0102] Table 1. Node ID list

[0103] Node Name Node ID Node 1 000.000.000.000 Node 2 111.111.111.111 … … Node N xxx.xxx.xxx.xxx

[0104] In an embodiment of the present application, in the data interaction process between the packaging node and the consensus node mentioned above, the packaging node can carry its own node identification, so that other consensus nodes can perform node identity authentication processing based on the corresponding node identification before performing consensus processing, thereby improving the security of the blockchain consensus process.

[0105] (3) Block structure:

[0106] See also Figure 3a , Figure 3a This is a schematic diagram of the structure of a blockchain provided by an embodiment of the present application. Figure 3a As shown in the figure, the blockchain consists of multiple blocks, and each blockchain contains a genesis block. As the name implies, the so-called genesis block is the first block, the initial block. The genesis block includes a block header and a block body. The block header stores the input information feature value, version number, timestamp and difficulty value, and the block body stores the input information; the next block of the genesis block uses the genesis block as the parent block, and the next block also includes a block header and a block body. The block header stores the input information feature value of the current block, the block header feature value, version number, timestamp and difficulty value of the parent block, and so on, so that the transaction data stored in each block in the blockchain is associated with the transaction data stored in the parent block, ensuring the security of the transaction data in the block.

[0107] In an embodiment of the present application, after the transaction data is processed on the chain, the transaction data can be added to the block body of the current block in the blockchain. According to the structure of the block, the security and reliability of the transaction data stored on the chain can be guaranteed, and the risk of transaction data being tampered with can be avoided.

[0108] (4) Block generation process:

[0109] See also Figure 3b , Figure 3b is a schematic diagram of a flow chart of generating a block provided in an embodiment of the present application. Figure 3b As shown, in the generated Figure 3a When each block in the blockchain shown in the figure is received, the blockchain node verifies the input information when receiving it. After the verification is completed, the input information is stored in the memory pool and the hash tree used to record the input information is updated. After that, the update timestamp is updated to the time when the input information is received, and different random numbers are tried to calculate the eigenvalues ​​multiple times so that the calculated eigenvalues ​​can satisfy the following formula:

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

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

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

[0113] 5. Cloud Technology:

[0114] In the blockchain transaction processing scheme proposed in this application, the blockchain involves a large number of data computing services and data storage services, so a large amount of computer operating costs are required. Then, the file editing scheme provided in this application involves cloud technology, and cloud technology can be used to provide data computing services and data storage services. Specifically, the pre-verification transaction can be pre-executed on the blockchain based on the data computing service to obtain the pre-execution result; and the pre-execution result of the pre-verification transaction can be stored in data based on the data storage service. Among them, the so-called cloud technology (Cloudtechnology) is a general term for network technology, information technology, integration technology, management platform technology, application technology, etc. based on the cloud computing business model application, which can form a resource pool, which is used on demand and is flexible and convenient. Among them, cloud technology can include cloud storage technology. The so-called cloud storage (cloud storage) is a new concept extended and developed from the concept of cloud computing. The distributed cloud storage system (hereinafter referred to as the storage system) refers to a storage system that uses cluster applications, grid technology, and distributed storage file systems to bring together a large number of storage devices of various types in the network (storage devices are also called storage nodes) through application software or application interfaces to work together and provide data storage and business access functions to the outside world.

[0115] It should be noted that the relevant data involved in the blockchain transaction processing process in this application, for example: transaction data, pre-execution results, transaction subsets, etc. When the above embodiments of this application are applied to specific products or technologies, user permission or consent must be obtained, and the relevant data collection, use and processing processes must comply with relevant national and regional laws and standards, comply with the principles of legality, legitimacy and necessity, and do not involve obtaining data types prohibited or restricted by regulations. In some optional embodiments, the relevant data involved in the embodiments of this application are obtained after the object has been authorized separately. In addition, when obtaining the separate authorization of the object, the purpose of the relevant data involved must be indicated to the object.

[0116] The following is a detailed introduction to the architecture diagram of the blockchain transaction processing system provided by this application.

[0117] See also Figure 4 , Figure 4 This is a schematic diagram of the architecture of a blockchain transaction processing system provided by an embodiment of the present application. Figure 4 As shown, the architecture diagram of the blockchain transaction processing system may include at least: a blockchain node and at least one client (e.g., client 1, client 2, client 3). The blockchain node may be directly or indirectly connected to any client via wired or wireless communication.

[0118] In a feasible embodiment, any computer device (blockchain node or any client) in the blockchain transaction processing system can be a mobile phone, tablet computer, laptop computer, PDA, mobile Internet device (MID), vehicle, vehicle-mounted equipment, roadside equipment, aircraft, wearable device, smart devices such as smart watches, smart bracelets, pedometers, etc., virtual reality devices... and so on.

[0119] In another feasible embodiment, any computer device (blockchain node or any client) in the blockchain transaction processing system can also be a server. Specifically, the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0120] It is understandable that the types of various computer devices in the blockchain transaction processing system can be the same or different. For example, the blockchain node can be a server, and each client can be a mobile phone; for another example, client 1 can be a server, client 2 can be a mobile phone, client 3 can be a car device, etc. This application does not limit the number and type of various computer devices in the blockchain transaction processing system.

[0121] (1) First, the main functions of each computer device in the blockchain transaction processing system: blockchain node and client are briefly described.

[0122] ① Client: Responsible for sending transactions to blockchain nodes. During the transaction sending process, the client can send each transaction in sequence, or it can send multiple transactions in batches at one time. For example, client 1 can send transaction 1 to the blockchain node, client 2 can send transaction 2 to the blockchain node, and client 3 can send transaction 3 to the blockchain node.

[0123] ② Blockchain nodes: mainly include packaging nodes and consensus nodes. Among them, packaging nodes are mainly responsible for pre-verification, pre-execution, and block packaging of received transactions. It should be understood that only after the pre-verification of the transaction is passed, the current transaction can be pre-executed to obtain the pre-execution result. If the pre-verification of the transaction fails, the current transaction will not be pre-executed; the consensus node is mainly responsible for synchronizing and storing the new blocks (such as the target block) packaged by the packaging node, and then consensus processing of each pre-verified transaction in the target block.

[0124] In the embodiment of the present application, the packaging node is responsible for receiving transactions uploaded by each client, and performing pre-verification and pre-execution processing on the received transactions (wherein, pre-verified and pre-executed transactions can also be referred to as pre-verified transactions) to obtain the pre-execution results of each pre-verified transaction (e.g., read-write sets: read data sets and write data sets), and store the read data sets and write data sets of each pre-verified transaction in the pre-verified transaction pool. Subsequently, the packaging node can broadcast the packaged new block to each consensus node, and any consensus node can realize the parallel execution of each pre-verified transaction in the blockchain according to the read data sets and write data sets of each pre-verified transaction in the new block when receiving the new block.

[0125] (2) Then, the data interaction process between blockchain nodes and clients in the blockchain transaction processing system is introduced in detail:

[0126] ① Any client can initiate a new on-chain transaction to the blockchain node, for example, client 1 can initiate transaction 1, client 2 can initiate transaction 2, and client 3 can initiate transaction 3. Optionally, the transaction rights of the client that sends transactions to the blockchain node can be set. The transaction rights here can include, for example: the maximum number of transactions initiated (for example, 100), the transaction type of the transaction initiated (for example, the transaction types allowed to be initiated by client 1 include: type 1, type 2; for example, the transaction types allowed to be initiated by client 2 include: type 2, type 3), and whether the transaction can be sent to the blockchain (for example, client 1 can send transactions to the blockchain, and client 2 cannot send transactions to the blockchain), etc.

[0127] ② When a new block needs to be packaged, the blockchain node can obtain N pre-verified transactions and the pre-execution results of each pre-verified transaction from the pre-verified transaction pool in the blockchain, where N is a positive integer.

[0128] ③ The blockchain node analyzes N pre-execution results and determines the data dependency relationship between the N pre-verification transactions; and based on the data dependency relationship, divides the N pre-verification transactions into M transaction subsets; each transaction subset contains one or more pre-verification transactions, and each pre-verification transaction in the same transaction subset has a data dependency relationship, M is a positive integer and M≤N.

[0129] ④ The blockchain node can create transaction tasks for each of the M transaction subsets obtained by division. One transaction task corresponds to one transaction subset, that is, a transaction task is created based on one transaction subset.

[0130] ⑤ The blockchain node can package the target block based on M transaction tasks, and process the M transaction tasks in the target block in parallel on the blockchain. Specifically, the blockchain node can assemble N pre-verified transactions into a target block in the form of M transaction tasks, and can execute the M transaction tasks in the target block in parallel.

[0131] ⑥Optionally, if the blockchain node is a bookkeeping node, then after the bookkeeping node packages the target block, it can also broadcast the target block to the consensus node in the blockchain network, so that the consensus node can process the N pre-verified transactions in the target block in parallel as M transaction tasks.

[0132] The blockchain transaction processing system provided by the present application can obtain N pre-verification transactions and the pre-execution results of each pre-verification transaction, where N is a positive integer; analyze the N pre-execution results to determine the data dependency between the N pre-verification transactions; divide the N pre-verification transactions into M transaction subsets based on the data dependency; each transaction subset contains one or more pre-verification transactions, and each pre-verification transaction in the same transaction subset has a data dependency, where M is a positive integer and M≤N; create transaction tasks for each M transaction subset, one transaction task corresponds to one transaction subset; package the target block based on the M transaction tasks, and perform parallel processing on the blockchain for the M transaction tasks in the target block. It can be seen that the present application can perform pre-verification on each on-chain transaction and then perform pre-execution, so as to obtain the pre-execution results of the pre-verification transaction, and subsequently determine the data dependency between each pre-verification transaction based on each pre-execution result, so as to be able to divide the pre-verification transaction into different transaction tasks according to the data dependency, and subsequently execute each transaction task in parallel in the blockchain, thereby realizing the parallel processing of blockchain transactions and improving the efficiency of transaction processing.

[0133] It can be understood that the blockchain transaction processing system described in the embodiment of the present application is to more clearly illustrate the technical solution of the embodiment of the present application, and does not constitute a limitation on the technical solution provided in the embodiment of the present application. It is known to those skilled in the art that with the evolution of the system architecture and the emergence of new business scenarios, the technical solution provided in the embodiment of the present application is also applicable to similar technical problems.

[0134] The specific embodiments involved in the blockchain transaction processing solution are described below with reference to the accompanying drawings.

[0135] See also Figure 5 , Figure 5 is a flowchart of a blockchain transaction processing method provided by an embodiment of the present application. The blockchain transaction processing method can be Figure 4 The blockchain node in the blockchain transaction processing system shown in the figure is executed, and the blockchain node can be a terminal device or a server. Figure 5 As shown, the blockchain transaction processing method mainly includes but is not limited to the following steps S501 to S505:

[0136] S501: Obtain N pre-verification transactions and a pre-execution result of each pre-verification transaction.

[0137] In a possible implementation, before obtaining N pre-verification transactions and the pre-execution results of each pre-verification transaction, the blockchain node is also used to perform the following operations: receiving the transaction to be processed and pre-verifying the transaction; if it is determined that the pre-verification process of the transaction is passed, the transaction is used as a pre-verification transaction; and the pre-verification transaction is executed to obtain the pre-execution result of the pre-verification transaction. Among them, the pre-verification process includes: verifying the validity of the smart contract that needs to be called by the transaction, verifying the security of the transaction, and verifying the legality of the transaction. ① For example, the transaction data of the pre-verification transaction carries the call information of the smart contract (such as the contract identifier of the smart contract to be called). Based on the contract identifier, it can be found whether there is a matching smart contract in the blockchain. If it exists, it can be determined that the validity verification of the smart contract of the current pre-verification transaction has passed. If it does not exist, it can be determined that the validity verification of the smart contract of the current pre-verification transaction has failed. ② For another example, detect whether the pre-verification transaction is an abnormal transaction (wherein, if the pre-verification transaction is an asset transfer transaction, the so-called abnormal transaction can be, for example, a transaction in which the account address for receiving the asset and the account address for transferring the asset are the same account address). If not, it can be determined that the security verification of the pre-verification transaction has passed; if so, it can be determined that the security verification of the pre-verification transaction has failed. ③ For another example, analyze whether the transaction data of the pre-verification transaction contains sensitive data. If not, it can be determined that the legitimacy verification of the pre-verification transaction has passed; if included, it can be determined that the legitimacy verification of the pre-verification transaction has failed.

[0138] Further, after determining that the pre-verification of the transaction has passed, the pre-verification transaction can be executed to obtain the pre-execution result of the pre-verification transaction. Among them, the specific process of executing the pre-verification transaction may include: creating a transaction read cache and a transaction write cache for the pre-verification transaction; in the process of executing the pre-verification transaction, obtaining a read data set of the pre-verification transaction, and storing the read data set of the pre-verification transaction in the transaction read cache; and obtaining a write data set of the pre-verification transaction, and storing the write data set of the pre-verification transaction in the transaction write cache. In other words, the pre-execution result includes a read data set and a write data set. The transaction read cache is used to store the read data set of any pre-verification transaction. The so-called read data set includes the call information of the smart contract corresponding to the execution of the pre-verification transaction. For example, the call information may include but is not limited to: the call address of the smart contract, the contract identifier (such as the contract name), etc.; the transaction write cache is used to store the write data set of any pre-verification transaction. The so-called write data set includes the transaction execution result obtained after calling the smart contract to execute the pre-verification transaction.

[0139] Among them, taking the target pre-verification transaction as any one of the N pre-verification transactions as an example, how the blockchain node determines the read data set and write data set of the target pre-verification transaction is explained. Specifically, the blockchain node parses the transaction data of the target pre-verification transaction to obtain the read data set of the target pre-verification transaction; from the read data set of the target pre-verification transaction, the target smart contract to be called by the target pre-verification transaction is determined; the target smart contract is called to execute the target pre-verification transaction to obtain the transaction execution data of the target pre-verification transaction; and the transaction execution data is added to the write data set of the target pre-verification transaction.

[0140] From the above, it can be seen that when a blockchain node receives a transaction to be processed, it can immediately pre-verify and pre-execute the transaction, thereby obtaining the pre-execution result of the pre-verified transaction. There is no need to wait until enough transactions are collected before verifying and executing the transaction, thus improving the efficiency of transaction execution.

[0141] In a possible implementation, the pre-execution result of each pre-verification transaction can be stored in a pre-verification transaction pool, and the blockchain node can obtain N pre-verification transactions and the pre-execution result of each pre-verification transaction from the pre-verification transaction pool, where N is a positive integer. The N pre-verification transactions can be all or part of the transactions in the pre-verification transaction pool. If the N pre-verification transactions are part of the transactions in the pre-verification transaction pool, the N pre-verification transactions can be part of the transactions randomly selected from the pre-verification transaction pool, or the N pre-verification transactions can be transactions selected from the pre-verification transaction pool according to a specified selection method. For example, the specified selection method can include: transactions of a specified type (e.g., transactions of an asset transfer type), a specified number of transactions (e.g., 100), transactions within a specified time period (e.g., transactions within the time period from October 1 to October 7), and so on.

[0142] S502: Analyze N pre-execution results to determine data dependencies between the N pre-verification transactions.

[0143] In a possible implementation, the pre-execution result includes a read data set and a write data set of the pre-verification transaction, and any two pre-verification transactions among the N pre-verification transactions are represented as pre-verification transaction i and pre-verification transaction j. The blockchain node analyzes the N pre-execution results and determines the data dependency relationship between the N pre-verification transactions, which specifically includes the following process: performing data analysis on the pre-execution result of pre-verification transaction i and the pre-execution result of pre-verification transaction j to obtain a data analysis result; based on the data analysis result, determining the data dependency relationship between pre-verification transaction i and pre-verification transaction j; wherein the data dependency relationship between pre-verification transaction i and pre-verification transaction j includes any one or more of the following: the read data set of pre-verification transaction i has a data dependency relationship with the read data set of pre-verification transaction j, the write data set of pre-verification transaction i has a data dependency relationship with the write data set of pre-verification transaction j, the read data set of pre-verification transaction i has a data dependency relationship with the write data set of pre-verification transaction j, and the write data set of pre-verification transaction i has a data dependency relationship with the read data set of pre-verification transaction j.

[0144] Several methods for determining whether there is a data dependency relationship between pre-verification transaction i and pre-verification transaction j are described below.

[0145] Method 1: Assume that both pre-verification transaction i and pre-verification transaction j belong to transactions in the asset transaction scenario, and both the read data set and the write data set are stored in the format of key-value pairs (K(Key, key)-V(Value, value)), and the key (Key) in the key-value pair refers to the account address. Then, if the account address of pre-verification transaction i is the same as the account address of pre-verification transaction j, it is determined that there is a data dependency relationship between pre-verification transaction i and pre-verification transaction j; if the account address of pre-verification transaction i is different from the account address of pre-verification transaction j, it is determined that there is no data dependency relationship between pre-verification transaction i and pre-verification transaction j.

[0146] Method 2: Assume that the read data set includes: the smart contract that needs to be called to execute the pre-verification transaction. Then, if the smart contract that needs to be called by pre-verification transaction i is the same as the smart contract that needs to be called by pre-verification transaction j, it is determined that there is a data dependency relationship between pre-verification transaction i and pre-verification transaction j; if the smart contract that needs to be called by pre-verification transaction i is different from the smart contract that needs to be called by pre-verification transaction j, it is determined that there is no data dependency relationship between pre-verification transaction i and pre-verification transaction j.

[0147] Method 3: If the pre-execution result (read data set and / or write data set) of pre-verification transaction i is directly associated with the pre-execution result (read data set and / or write data set) of pre-verification transaction j, for example, the Value of pre-verification transaction i includes the account address of pre-verification transaction j, then there is a data dependency relationship between pre-verification transaction i and pre-verification transaction j; if there is no correlation between the pre-execution result of pre-verification transaction i and the pre-execution result of pre-verification transaction j, then there is a data dependency relationship between pre-verification transaction i and pre-verification transaction j.

[0148] Further, according to the above method, the data dependency between N pre-verification transactions can be determined respectively. Optionally, the data dependency between any two pre-verification transactions can be identified by an indication tag. For example, if there is a data dependency between pre-verification transaction i and pre-verification transaction j, the indication tag can be set to 1. If there is no data dependency between pre-verification transaction i and pre-verification transaction j, the indication tag can be set to 0. Of course, the indication tag can also be set to other data formats, such as strings or text, etc., and this application does not make specific limitations on this; specifically, if there is a data dependency between pre-verification transaction i and pre-verification transaction j, the indication tag can be set to "yes", and if there is no data dependency between pre-verification transaction i and pre-verification transaction j, the indication tag can be set to "no".

[0149] By adopting the above method, the data dependency of N pre-verification transactions can be analyzed based on the pre-execution results of the N pre-verification transactions, and the data dependency between the N pre-verification transactions can be reflected in the form of indicator tags, so that the data dependency between each pre-verification transaction can be reflected based on the indicator tags, and the relationship between the pre-verification transactions can be reflected more conveniently and flexibly.

[0150] S503: Based on the data dependency, divide the N pre-verified transactions into M transaction subsets; each transaction subset contains one or more pre-verified transactions, and there is a data dependency relationship between the pre-verified transactions in the same transaction subset, M is a positive integer and M≤N.

[0151] In a possible implementation, the blockchain node divides N pre-verification transactions into M transaction subsets based on data dependency, which specifically includes the following process: if there is a data dependency between pre-verification transaction i and pre-verification transaction j, pre-verification transaction i and pre-verification transaction can be divided into the same transaction subset; if there is no data dependency between pre-verification transaction i and pre-verification transaction j, pre-verification transaction i and pre-verification transaction can be divided into different transaction subsets respectively. According to the above method, N pre-verification transactions can be divided into M transaction subsets based on the data dependency between N pre-verification transactions.

[0152] S504: Create transaction tasks for each of the M transaction subsets, with one transaction task corresponding to one transaction subset.

[0153] In specific implementation, the blockchain node can create M transaction tasks based on M transaction subsets, that is, one transaction subset corresponds to one transaction task. Since one transaction subset contains one or more pre-verified transactions, the created transaction task also includes one or more pre-verified transactions. For example, the created M transaction tasks can be expressed in the data format shown in Table 2 below:

[0154] Table 2. Data format of transaction tasks

[0155] Trading tasks Pre-verified transactions Task 1 tx1, tx2, tx3 Task 2 tx4, tx5 Task 3 tx6 ... ...

[0156] As shown in Table 2 above, assuming that there are 6 pre-verification transactions: tx1, tx2, tx3, tx4, tx5, and tx6, according to the above method of the present application, these 6 pre-verification transactions can be created into three transaction tasks respectively according to the data dependency relationship between each pre-verification transaction: task 1, task 2, and task 3, among which task 1 includes the three pre-verification transactions tx1, tx2, and tx3, task 2 includes the two pre-verification transactions tx4 and tx5, and task 3 includes the one pre-verification transaction tx6.

[0157] In a possible implementation, after creating M transaction tasks, the blockchain node can also determine a serial transaction task from the M transaction tasks, wherein the serial transaction task includes multiple pre-verification transactions with data dependencies; add a task tag to the serial transaction task, wherein the task tag is used to indicate the sequential execution of each pre-verification transaction in the serial transaction task; send the target block with the task tag added to at least one consensus node in the blockchain, so that the consensus node executes each pre-verification transaction in the serial transaction task in the order of the task tag after receiving the target block, and executes the M transaction tasks in the target block in parallel. For example, as shown in Table 2 above, Task 1 and Task 2 can be considered as serial transaction tasks, then task tags can be added to Task 1 and Task 2 respectively. Subsequently, when the consensus node receives the target block, it can parse the target block and execute each pre-verification transaction in the serial transaction task in the order of the task tags.

[0158] Specifically, a blockchain node adds a task label to a serial transaction task, which may include the following process: first, obtaining the pre-execution results of each pre-verification transaction included in the serial transaction task in the target block, the pre-execution results including the read data set and the write data set of the pre-verification transaction; then, analyzing the read data set and the write data set of each pre-verification transaction to determine the transaction execution order between each pre-verification transaction; finally, generating an execution order array for the serial transaction task based on the determined transaction execution order, and generating a task label for the serial transaction task based on the execution order array. For example, if task 1 is a serial transaction task, and the serial transaction task includes three pre-verification transactions: tx1, tx2, and tx3, then the transaction execution order between the pre-verification transactions can be determined according to the data reading relationship reflected by the read data sets and write data sets of the three pre-verification transactions tx1, tx2, and tx3. For example, if the read data set of tx1 includes the write data set of tx2, tx1 can only be executed after tx2 is executed, that is, the transaction execution order of tx2 takes precedence over the transaction execution order of tx1; if the read data set of tx3 includes the write data sets of tx1 and tx2, tx3 can only be executed after tx1 and tx2 are both executed, that is, the transaction execution order of tx1 and tx2 takes precedence over the transaction execution order of tx3. Therefore, the transaction execution order of the three pre-verification transactions tx1, tx2, and tx3 is: tx2->tx1->tx3. Then, based on the determined transaction execution order, an execution order array [2, 1, 3] for the serial transaction task can be generated, and the array [2, 1, 3] can be determined as the task label added to the current serial transaction task.

[0159] S505: Packing the target block based on the M transaction tasks, and processing the M transaction tasks in the target block in parallel on the blockchain.

[0160] Specifically, the blockchain node can package the M created transaction tasks into a target block. Since there is no data dependency between the pre-verified transactions between different transaction tasks, the M transaction tasks in the target block can be executed in parallel.

[0161] In a possible implementation, the blockchain node processes M transaction tasks in the target block in parallel on the blockchain, which mainly includes the following process: first, determine the number K of serial transaction tasks in the M transaction tasks, where K is a positive integer; then, start K contract coroutines and start MK contract processes; execute the M transaction tasks in the target block in parallel in the K contract coroutines and MK contract processes; wherein one transaction task is executed by one contract coroutine or one contract process. For example, assuming that the transaction tasks include: Task 1, Task 2, and Task 3, where Task 1 and Task 2 are both serial transaction tasks, one contract process and two and contract coroutines can be started, and then the above three transaction tasks can be executed in parallel in the one contract process and the two and contract coroutines.

[0162] Furthermore, since a serial transaction task includes multiple pre-verification transactions, in the process of executing each transaction task in parallel, for any serial transaction task, each pre-verification transaction needs to be executed serially within the serial transaction task. Specifically, the transaction execution order between each pre-verification transaction included in the serial transaction task can be determined; according to the transaction execution order between each pre-verification transaction, each pre-verification transaction is sequentially executed in each contract coroutine. For example, for the serial transaction task (task 1), since the transaction execution order of the three pre-verification transactions tx1, tx2, and tx3 included in task 1 is: tx2->tx1->tx3, then each pre-verification transaction can be executed sequentially in the contract coroutine according to the transaction execution order, thereby realizing the parallel execution of each transaction task and the serial execution of each pre-verification transaction in some transaction tasks. Compared with the requirement that all pre-verification transactions must be executed serially, this application can improve the transaction execution efficiency.

[0163] The following uses an asset transfer transaction scenario as an example to illustrate the detailed process of how this application implements parallel processing of transactions.

[0164] For example, both the read data set and the write data set can be stored in the format of key-value pairs: K (Key)-nonce-V (Value). Among them, Key represents the account address, Value represents the account balance, and the middle number nonce represents the number of transactions initiated by the current account. Nonce can usually be set to a positive integer that increases from 0. Of course, the nonce number can also be understood as the version number of the data. Based on the read data set and write data set of each pre-verified transaction in the asset transfer transaction scenario, this application executes each pre-transaction in parallel, mainly including the following processes:

[0165] For example, the account state of the current blockchain node is: (k1, 0, v1), (k2, 0, v2), (k3, 0, v3), (k4, 20, v4), (k5, 100, v5). At present, assume that a new block contains the following 6 pre-verified transactions that have been pre-verified and pre-executed, and these pre-verified transactions are executed in the order of: T1->T2->T3>T4->T5->T6. The current blockchain node (such as a packaging node) receives the following 6 pre-verified transactions. According to the above logic, after pre-verification and pre-execution of each pre-verified transaction, the pre-execution results (read data set and write data set) of each pre-verified transaction are respectively expressed as:

[0166] T1->Write(k1,1,v1'),Write(k2,1,v2');

[0167] T2->Read(k1),Write(k3,1,v3');

[0168] T3->Write(k2,2,v2');

[0169] T4->Write(k4,21,v4');

[0170] T5->Write(k5,101,v5'),Read(k4);

[0171] T6->Read(k4),Write(k4,22,v4”).

[0172] According to the read and write data sets of the above pre-verified transactions, the blockchain node that synchronizes the current block can be divided into two transaction tasks for parallel execution when verifying and executing block transactions:

[0173] 1) Since T1 will update the status of k1 and k2, and T2 reads k1, that is, there is a dependency relationship between T1 and T2, so T2 will be put into the same task as T1 and executed in sequence; in addition, since T3 will update k2, there is a dependency relationship between T3 and T1, so T3 will also be added to the task where T1 is located. For example, transactions T1, T2, and T3 can all be added to transaction task 1.

[0174] 2) Since T4, T5, T6 have no dependencies with the previous three transactions (i.e., T1, T2, and T3); and T4, T5, and T6 have dependencies with each other (for example, T5 will read k4, which is updated in T4, i.e., T5 will read the transaction execution result of T4; and T6 will also read the transaction execution result of T4 and update k4), transactions T4, T5, and T6 can all be added to transaction task 2.

[0175] In summary, there is a data dependency between each pre-verification transaction in the same transaction task; there is no data dependency between each pre-verification transaction between different transaction tasks. Subsequently, each transaction task (such as the above transaction task 1 and transaction task 2) can be executed in parallel to achieve the parallel execution of multiple pre-verification transactions in the target block, thereby improving the execution efficiency of block transactions.

[0176] In the embodiment of the present application, N pre-verification transactions and the pre-execution results of each pre-verification transaction can be obtained, N is a positive integer; the N pre-execution results are analyzed to determine the data dependency between the N pre-verification transactions; based on the data dependency, the N pre-verification transactions are divided into M transaction subsets; each transaction subset contains one or more pre-verification transactions, and each pre-verification transaction in the same transaction subset has a data dependency, M is a positive integer and M≤N; transaction tasks are created for each M transaction subset, one transaction task corresponds to one transaction subset; the target block is packaged based on the M transaction tasks, and the M transaction tasks in the target block are processed in parallel on the blockchain. It can be seen that the present application can perform pre-verification on each on-chain transaction and then pre-execute it, so as to obtain the pre-execution results of the pre-verification transaction, and the data dependency between each pre-verification transaction can be determined based on each pre-execution result, so that the pre-verification transaction can be divided into different transaction tasks according to the data dependency, and each transaction task can be executed in parallel in the blockchain, thereby realizing the parallel processing of blockchain transactions, which can improve the efficiency of transaction processing.

[0177] See also Figure 6 , Figure 6 This is an interactive flow chart of a blockchain transaction processing provided by an embodiment of the present application. Figure 6 As shown, the interactive process is mainly performed by: the client, the packaging node, and the consensus node. Among them, the packaging node and the consensus node refer to different types of blockchain nodes. Specifically, the interactive process of blockchain transaction processing provided by this application mainly includes the following steps S601-S610:

[0178] S601: The target object initiates a transaction and generates a transaction on-chain request.

[0179] In specific implementation, the transaction initiated by the target object can be any type of transaction. For example, the transaction here can include: game-type transactions, asset-type transactions, and so on. In addition, the number of transactions initiated by the target object can be one or more, that is, the target object is allowed to send transactions in batches, and the target object is also allowed to send individual transactions. Next, the client can assemble the transaction and generate a transaction chain request, in which the transaction chain request can include the transaction data corresponding to the transaction itself. For example, if the current transaction is an asset transaction, the transaction data may include: the account address of the asset transfer, the account address of the asset receiving, the contract address of the target smart contract to be called, the amount of digital assets to be transferred, and so on. Optionally, the transaction chain request can also include the identity information of the target object.

[0180] S602: The client sends a transaction on-chain request to the packaging node.

[0181] In specific implementation, after generating a transaction on-chain request, the client can use the private key of the target object to sign the transaction on-chain request to indicate the source of the transaction on-chain request. Optionally, the client can also determine the type of transaction to be on-chain. If it is a preset type (such as asset type), the transaction data of the transaction to be on-chain can be encrypted to obtain encrypted transaction data, and then a transaction on-chain request is generated based on the encrypted transaction data. In this way, the data security of certain special types of transactions can be guaranteed, thereby improving the reliability of the data interaction process.

[0182] S603: The packaging node responds to the transaction on-chain request and pre-verifies the transaction.

[0183] In a possible implementation, after receiving the transaction chain request initiated by the client, the packaging node can also obtain the client's identification, and then verify the client based on the client's identification. The verification here includes: any one or more of authority verification, signature verification, validity verification, security verification, and legality verification. Specifically, for example, the packaging node can obtain a blacklist list, which stores the identification of at least one client that does not have transaction authority. If the current client's identification exists in the blacklist list, it can be determined that the client's authority verification has failed; if the current client's identification does not exist in the blacklist list, it can be determined that the client's authority verification has passed. For another example, the client's public key can be obtained, and then the client's public key is used to verify the transaction chain request. If the verification passes, the signature verification passes; if the verification fails, the signature verification fails. For another example, the packaging node can parse the transaction chain request and determine the number of transactions contained in the transaction chain request. If the number of transactions is greater than or equal to the number threshold, it can be determined that the validity verification of the client has failed; if the number of transactions is less than the number threshold, it can be determined that the validity verification of the client has passed. In this way, the client that initiates the transaction on-chain request can be verified, thereby improving the effectiveness of the on-chain transaction.

[0184] In a possible implementation, after receiving the transaction on-chain request uploaded by the target object, the packaging node can also perform authentication processing on the target object. Among them, during the authentication process of the target object, the packaging node can also request to obtain the identity information of the target object, and perform identity authentication processing on the target object based on the identity information of the target object. Among them, when obtaining the identity information of the target object, the authorization of the target object needs to be requested. Specifically, before obtaining the identity information of the target object, the packaging node needs to send an authorization request to the target object, and the authorization request is used to request the authorization of the target object. When the target object agrees to the authorization, the identity information of the target object can be obtained. For example, after the client used by the target object obtains the authorization request sent by the blockchain node, the interface can be displayed in the client, and the prompt information is displayed in the interface, and the prompt information is used to prompt the target object whether to authorize the identity information, and a confirmation control and a rejection control are provided. If the target object clicks the confirmation control, it means that the target object agrees to the authorization, and if the target object clicks the rejection control, it means that the target object refuses the authorization. In this way, when obtaining the identity information of the target object, the authorization of the target object can be requested, thereby improving the security of the identity information of the target object and avoiding data leakage.

[0185] Furthermore, after the packaging node performs the above verification and passes, the transaction can be pre-verified. The pre-verification process includes: verifying the validity of the smart contract that needs to be called by the transaction, verifying the security of the transaction, and verifying the legality of the transaction. ① For example, the transaction data of the pre-verification transaction carries the call information of the smart contract (for example, the contract identifier of the smart contract to be called). Based on the contract identifier, it can be found whether there is a matching smart contract in the blockchain. If it exists, it can be determined that the validity verification of the smart contract of the current pre-verification transaction has passed. If it does not exist, it can be determined that the validity verification of the smart contract of the current pre-verification transaction has failed. ② For another example, it is detected whether the pre-verification transaction is an abnormal transaction (wherein, if the pre-verification transaction is an asset transfer transaction, the so-called abnormal transaction can be, for example, a transaction in which the account address of the asset receiving and the account address of the asset transfer are the same account address). If not, it can be determined that the security verification of the pre-verification transaction has passed; if so, it can be determined that the security verification of the pre-verification transaction has failed. ③ For example, analyze whether the transaction data of the pre-verification transaction contains sensitive data. If not, it can be determined that the legitimacy verification of the pre-verification transaction has passed; if included, it can be determined that the legitimacy verification of the pre-verification transaction has failed.

[0186] S604: The packaging node pre-verifies the transaction, pre-executes the transaction, and obtains the pre-execution result.

[0187] In specific implementation, the specific process of executing a pre-verified transaction may include: creating a transaction read cache and a transaction write cache for the pre-verified transaction; in the process of executing the pre-verified transaction, obtaining a read data set of the pre-verified transaction, and storing the read data set of the pre-verified transaction in the transaction read cache; and obtaining a write data set of the pre-verified transaction, and storing the write data set of the pre-verified transaction in the transaction write cache. In other words, the pre-execution result includes a read data set and a write data set. The transaction read cache is used to store the read data set of any pre-verified transaction. The so-called read data set includes the call information of the smart contract corresponding to the execution of the pre-verified transaction. For example, the call information may include but is not limited to: the call address of the smart contract, the contract identifier (such as the contract name), etc.; the transaction write cache is used to store the write data set of any pre-verified transaction. The so-called write data set includes the transaction execution result obtained after calling the smart contract to execute the pre-verified transaction.

[0188] Among them, taking the target pre-verification transaction as any one of the N pre-verification transactions as an example, how the blockchain node determines the read data set and write data set of the target pre-verification transaction is explained. Specifically, the blockchain node parses the transaction data of the target pre-verification transaction to obtain the read data set of the target pre-verification transaction; from the read data set of the target pre-verification transaction, the target smart contract to be called by the target pre-verification transaction is determined; the target smart contract is called to execute the target pre-verification transaction to obtain the transaction execution data of the target pre-verification transaction; and the transaction execution data is added to the write data set of the target pre-verification transaction.

[0189] It should be noted that for any transaction initiated by the client, the packaging node can perform pre-verification and pre-execution processing on the transaction according to the steps shown in S601-S604 above (wherein, the transaction pre-verified by the packaging node can be called a pre-verified transaction) to obtain the pre-execution result of the pre-verified transaction. Subsequently, the packaging node can store the pre-execution results of each pre-verified transaction in the pre-verified transaction pool.

[0190] S605: The packaging node obtains N pre-verification transactions and the pre-execution result of each pre-verification transaction.

[0191] Specifically, the packaging node can obtain N pre-verified transactions and the pre-execution results of each pre-verified transaction from the pre-verified transaction pool. Among them, the N pre-verified transactions can be all transactions or part of transactions in the pre-verified transaction pool. If the N pre-verified transactions are part of transactions in the pre-verified transaction pool, then the N pre-verified transactions can be part of transactions randomly selected from the pre-verified transaction pool, or the N pre-verified transactions can be transactions selected from the pre-verified transaction pool according to a specified selection method.

[0192] S606: The packaging node assembles the N pre-verified transactions into a target block based on the N pre-execution results, and the target block includes M transaction tasks.

[0193] Specifically, the specific process of the packaging node assembling the target block may include the following steps:

[0194] 1) Analyze N pre-execution results and determine the data dependencies between N pre-verification transactions.

[0195] 2) Based on data dependency, N pre-verified transactions are divided into M transaction subsets; each transaction subset contains one or more pre-verified transactions, and there is a data dependency relationship between the pre-verified transactions in the same transaction subset, M is a positive integer and M≤N.

[0196] 3) Create transaction tasks for each of the M transaction subsets, with one transaction task corresponding to one transaction subset.

[0197] 4) Pack the target block based on M transaction tasks.

[0198] It should be noted that the specific process of how to assemble the target block described in the above steps 1)-4) can refer to the specific process described in steps S502-S505 in the above embodiment, and will not be repeated in this embodiment of the present application.

[0199] S607: The packaging node broadcasts the target block to the consensus node.

[0200] In one possible implementation, the packaging node can directly broadcast the assembled target block to each consensus node in the blockchain, so that any consensus node can execute the M transaction tasks in the target block in parallel after receiving the target block.

[0201] In another possible implementation, after the packaging node has created M transaction tasks, the packaging node can also determine a serial transaction task from the M transaction tasks, where the serial transaction task includes multiple pre-verification transactions with data dependencies; add a task tag to the serial transaction task, where the task tag is used to indicate the sequential execution of each pre-verification transaction in the serial transaction task; send the target block with the task tag added to at least one consensus node in the blockchain, so that the consensus node executes each pre-verification transaction in the serial transaction task in the order of the task tag after receiving the target block, and executes the M transaction tasks in the target block in parallel. For example, as shown in Table 2 above, Task 1 and Task 2 can be considered as serial transaction tasks, so task tags can be added to Task 1 and Task 2 respectively.

[0202] S608: The consensus node parses the target block and executes M transaction tasks in parallel.

[0203] In a possible implementation, after receiving the target block, the consensus node can obtain the node information (such as node identification) of the packaging node, and authenticate the packaging node according to the node information to ensure that the target block is sent by the packaging node itself, thereby ensuring the security of the target block. Then, after the consensus node passes the identity authentication of the packaging node, the consensus node can parse the target block, obtain M transaction tasks, and then execute the M transaction tasks in parallel to obtain the transaction execution results of each pre-verified transaction in the transaction task.

[0204] For example, see Figure 7 , Figure 7 This is a flow chart of a transaction execution process provided by an embodiment of the present application. Figure 7 As shown, the process of a blockchain node (such as a consensus node or a packaging node) calling a smart contract to execute any pre-verified transaction may include the following steps S1-S6:

[0205] S1. Trigger the contract.

[0206] In specific implementation, the blockchain node can receive the transaction request sent by the client, and then call the smart contract that matches the target transaction to be executed by the transaction request. For example, if the target transaction is an asset transaction, the smart contract can be an asset processing contract.

[0207] S2. Analyze transactions.

[0208] In specific implementation, the blockchain node can parse the transaction data of the target transaction, obtain the contract call address and contract name, and obtain the smart contract used to execute the target transaction (for example, including contract name, contract method, and contract input information).

[0209] S3. Load the contract’s storage information and the contract’s bytecode.

[0210] In specific implementation, the blockchain node obtains the corresponding contract bytecode and contract input from the target transaction and status database.

[0211] S4. Execute the contract.

[0212] In specific implementation, the contract file of the smart contract is executed in the blockchain node to complete the business logic of the target transaction. For example, if the target transaction is an asset transaction, the called asset processing contract can complete the corresponding asset processing logic and obtain the transaction execution result.

[0213] S5. Return the result and update the status database.

[0214] In specific implementation, the blockchain node can write the transaction execution results back to the status database to complete the update of the business status.

[0215] S6. Create a Merkle tree root and store it in the block.

[0216] In specific implementation, when all pre-verified transactions in the target block have been executed, the system will store the hash summary of the current state of the state database as a certification record in the blockchain.

[0217] S609: The consensus node returns the transaction execution result to the packaging node.

[0218] In one possible implementation, the consensus node can return the transaction execution result of a pre-verification transaction to the consensus node immediately after executing the pre-verification transaction. In another possible implementation, the consensus node can return the transaction execution results of all pre-verification transactions to the packaging node in batches only after all pre-verification transactions in the target block have been executed. In the process of returning the transaction execution results in batches, the consensus node can merge the transaction execution results according to the execution order of each pre-verification transaction, and then return the merged transaction execution results to the packaging node.

[0219] S610: The packaging node merges the transaction execution results and adds the target block to the blockchain.

[0220] Specifically, after executing M transaction tasks, the packaging node can obtain the transaction execution results of each pre-verified transaction, then merge the transaction execution results of each pre-verified transaction, and finally add the target block to the blockchain. Subsequently, the blockchain ledger data can be updated and the next round of block packaging can be started.

[0221] In the embodiment of the present application, the idea of ​​transaction pre-verification and pre-execution is adopted to obtain the pre-execution result (i.e., the read data set and the write data set); then, according to the transaction read-write set obtained by the pre-execution, the data dependency relationship between each pre-verified transaction in the blockchain can be analyzed to realize the splitting of transaction tasks, thereby realizing the parallel execution of multiple transaction tasks and improving the efficiency of transaction execution. Among them, this solution has the following beneficial effects:

[0222] (1) When a packaging node receives a new on-chain transaction, it can immediately pre-verify and pre-execute the transaction. There is no need to wait until enough transactions are collected before verifying and executing the transaction, thus achieving timely processing of transactions.

[0223] (2) When a blockchain node receives a new block, the pre-verification transactions contained in the new block are all pre-verified and pre-executed transactions. The pre-execution result of each transaction can be obtained, and the read-write set of each pre-verification transaction can be analyzed to determine the data dependency relationship between each pre-verification transaction. According to the data dependency relationship, each pre-verification transaction in the block is split into multiple transaction tasks. Each transaction task is allowed to be executed in parallel, thereby improving the efficiency of transaction execution in the block.

[0224] The following provides an apparatus of an embodiment of the present application. Next, in combination with the blockchain-based blockchain transaction processing solution provided in the above-mentioned embodiment of the present application, the relevant apparatus of the embodiment of the present application is introduced accordingly.

[0225] See also Figure 8 , Figure 8 Schematic diagram of a blockchain transaction processing device provided in an embodiment of the present application. Figure 8 As shown, the blockchain transaction processing device 800 can be applied to the blockchain node mentioned in the above embodiments. Specifically, the blockchain transaction processing device 800 can be a computer program (including program code) running in a computer device, for example, the blockchain transaction processing device 800 is an application software; the blockchain transaction processing device 800 can be used to execute the corresponding steps in the blockchain-based blockchain transaction processing method provided in the embodiment of the present application. In specific implementation, the blockchain transaction processing device 800 can specifically include:

[0226] The acquisition unit 801 is used to acquire N pre-verification transactions and the pre-execution result of each pre-verification transaction; N is a positive integer;

[0227] The processing unit 802 is used to analyze the N pre-execution results and determine the data dependency relationship between the N pre-verification transactions;

[0228] The processing unit 802 is further configured to divide the N pre-verified transactions into M transaction subsets based on the data dependency relationship; each transaction subset includes one or more pre-verified transactions, and each pre-verified transaction in the same transaction subset has a data dependency relationship, where M is a positive integer and M≤N;

[0229] The processing unit 802 is further configured to create transaction tasks for each of the M transaction subsets, where one transaction task corresponds to one transaction subset;

[0230] The processing unit 802 is further used to package the target block based on the M transaction tasks, and to process the M transaction tasks in the target block in parallel on the blockchain.

[0231] In a possible implementation, the pre-execution result includes a read data set and a write data set of the pre-verification transaction, and any two pre-verification transactions among the N pre-verification transactions are represented as pre-verification transaction i and pre-verification transaction j; the processing unit 802 analyzes the N pre-execution results, determines the data dependency relationship between the N pre-verification transactions, and performs the following operations:

[0232] Performing data analysis on the pre-execution result of pre-verification transaction i and the pre-execution result of pre-verification transaction j to obtain a data analysis result;

[0233] Based on the data analysis results, determine the data dependency relationship between pre-verified transaction i and pre-verified transaction j;

[0234] Among them, the data dependency relationship between pre-verification transaction i and pre-verification transaction j includes any one or more of the following: a data dependency relationship between the read data set of pre-verification transaction i and the read data set of pre-verification transaction j, a data dependency relationship between the write data set of pre-verification transaction i and the write data set of pre-verification transaction j, a data dependency relationship between the read data set of pre-verification transaction i and the write data set of pre-verification transaction j, and a data dependency relationship between the write data set of pre-verification transaction i and the read data set of pre-verification transaction j.

[0235] In a possible implementation, both pre-verification transaction i and pre-verification transaction j belong to transactions in an asset transaction scenario; both the read data set and the write data set store data in a key-value pair format, where the key in the key-value pair refers to the account address; and the processing unit 802 is further configured to perform the following operations:

[0236] If the account address of pre-verified transaction i is the same as the account address of pre-verified transaction j, it is determined that there is a data dependency relationship between pre-verified transaction i and pre-verified transaction j;

[0237] If the account address of pre-verification transaction i is different from the account address of pre-verification transaction j, it is determined that there is no data dependency relationship between pre-verification transaction i and pre-verification transaction j.

[0238] In a possible implementation, the read data set includes: a smart contract to be called to execute a pre-verified transaction; the processing unit 802 is further configured to perform the following operations:

[0239] If the smart contract that needs to be called by pre-verification transaction i is the same as the smart contract that needs to be called by pre-verification transaction j, it is determined that there is a data dependency relationship between pre-verification transaction i and pre-verification transaction j;

[0240] If the smart contract that needs to be called by pre-verification transaction i is different from the smart contract that needs to be called by pre-verification transaction j, it is determined that there is no data dependency relationship between pre-verification transaction i and pre-verification transaction j.

[0241] In a possible implementation, the processing unit 802 divides the N pre-verified transactions into M transaction subsets based on the data dependency, and performs the following operations:

[0242] If there is a data dependency relationship between pre-verified transaction i and pre-verified transaction j, pre-verified transaction i and pre-verified transaction j are classified into the same transaction subset;

[0243] If there is no data dependency relationship between pre-verification transaction i and pre-verification transaction j, pre-verification transaction i and pre-verification transaction j are respectively divided into different transaction subsets.

[0244] In a possible implementation, before obtaining N pre-verification transactions and the pre-execution result of each pre-verification transaction, the processing unit 802 is further configured to perform the following operations:

[0245] Receive pending transactions and perform pre-verification on the transactions, including: verifying the validity of the smart contract to be called by the transaction, verifying the security of the transaction, and verifying the legitimacy of the transaction;

[0246] If it is determined that the transaction has passed the pre-verification process, the transaction will be treated as a pre-verified transaction;

[0247] Execute the pre-verification transaction and obtain the pre-execution result of the pre-verification transaction.

[0248] In a possible implementation, the processing unit 802 executes the pre-verification transaction and obtains a pre-execution result of the pre-verification transaction, which is used to perform the following operations:

[0249] Create a transaction read cache and a transaction write cache for pre-verified transactions;

[0250] In the process of executing the pre-verification transaction, obtaining a read data set of the pre-verification transaction and storing the read data set of the pre-verification transaction in the transaction read cache; and,

[0251] Obtain a write data set for a pre-verified transaction and store the write data set for the pre-verified transaction in a transaction write cache.

[0252] In a possible implementation, the processing unit 802 is further configured to perform the following operations:

[0253] Parse the transaction data of the target pre-verification transaction to obtain a read data set of the target pre-verification transaction, where the target pre-verification transaction is any pre-verification transaction among the N pre-verification transactions;

[0254] Determine the target smart contract to be called by the target pre-verification transaction from the read data set of the target pre-verification transaction;

[0255] Call the target smart contract to execute the target pre-verified transaction and obtain the transaction execution data of the target pre-verified transaction;

[0256] Add the transaction execution data to the write data set of the target pre-verification transaction.

[0257] In a possible implementation, the processing unit 802 is further configured to perform the following operations:

[0258] Determine a serial transaction task from the M transaction tasks, where the serial transaction task includes a plurality of pre-verified transactions having data dependency relationships;

[0259] Add task tags to serial transaction tasks. Task tags are used to indicate the sequential execution of pre-verified transactions in the serial transaction tasks.

[0260] The target block with the task tag added is sent to at least one consensus node in the blockchain, so that after receiving the target block, the consensus node executes each pre-verification transaction in the serial transaction task in the order of the task tag, and executes the M transaction tasks in the target block in parallel.

[0261] In a possible implementation, the processing unit 802 adds a task tag to the serial transaction task to perform the following operations:

[0262] Obtaining the pre-execution results of each pre-verification transaction included in the serial transaction task in the target block, the pre-execution results including the read data set and the write data set of the pre-verification transaction;

[0263] Analyze the read data set and write data set of each pre-verification transaction to determine the transaction execution order between each pre-verification transaction;

[0264] An execution order array for the serial transaction task is generated based on the determined transaction execution order, and a task tag for the serial transaction task is generated based on the execution order array.

[0265] In a possible implementation, the processing unit 802 processes the M transaction tasks in the target block in parallel on the blockchain to perform the following operations:

[0266] Determine the number K of serial transaction tasks among the M transaction tasks, where K is a positive integer;

[0267] Start K contract coroutines and start MK contract processes;

[0268] Execute M transaction tasks in the target block in parallel in K contract coroutines and MK contract processes;

[0269] Among them, a transaction task is executed by a contract coroutine or a contract process.

[0270] In a possible implementation, the processing unit 802 is further configured to perform the following operations:

[0271] Determine the transaction execution order between each pre-verification transaction included in the serial transaction task;

[0272] According to the transaction execution order between each pre-verified transaction, each pre-verified transaction is executed sequentially in each contract coroutine.

[0273] In the embodiment of the present application, N pre-verification transactions and the pre-execution results of each pre-verification transaction can be obtained, N is a positive integer; the N pre-execution results are analyzed to determine the data dependency between the N pre-verification transactions; based on the data dependency, the N pre-verification transactions are divided into M transaction subsets; each transaction subset contains one or more pre-verification transactions, and each pre-verification transaction in the same transaction subset has a data dependency, M is a positive integer and M≤N; transaction tasks are created for each M transaction subset, one transaction task corresponds to one transaction subset; the target block is packaged based on the M transaction tasks, and the M transaction tasks in the target block are processed in parallel on the blockchain. It can be seen that the present application can perform pre-verification on each on-chain transaction and then pre-execute it, so as to obtain the pre-execution results of the pre-verification transaction, and the data dependency between each pre-verification transaction can be determined based on each pre-execution result, so that the pre-verification transaction can be divided into different transaction tasks according to the data dependency, and each transaction task can be executed in parallel in the blockchain, thereby realizing the parallel processing of blockchain transactions, which can improve the efficiency of transaction processing.

[0274] See also Fig. 9 , Fig. 9 It is a structural diagram of a computer device provided in an embodiment of the present application. The computer device 900 is used to execute the steps performed by the blockchain node (packaging node or consensus node) in the aforementioned method embodiment, and the computer device 900 includes: one or more processors 901; one or more input devices 902, one or more output devices 903 and a memory 904. The above-mentioned processor 901, input device 902, output device 903 and memory 904 are connected via a bus 905. Among them, the processor 901 (or CPU (Central Processing Unit)) is the processing core of the computer device, and the processor 901 is suitable for implementing one or more program instructions, and is specifically suitable for loading and executing one or more program instructions to implement the above-mentioned blockchain transaction processing method. In addition, the memory 904 can be a high-speed RAM memory, or it can be a non-volatile memory (non-volatile memory), such as at least one disk memory; optionally, the memory 904 can also be at least one memory located away from the aforementioned processor. The memory 904 provides a storage space for storing the operating system of the computer device, and the storage space is also used to store a computer program, which includes program instructions, and the program instructions are suitable for being called and executed by the processor 901 to perform each step of the blockchain transaction processing method in this application. In specific implementation, the processor 901 is used to call the program instructions stored in the memory 904 to perform the following operations:

[0275] Get N pre-verification transactions and the pre-execution results of each pre-verification transaction; N is a positive integer;

[0276] Analyze N pre-execution results and determine the data dependencies between N pre-verification transactions;

[0277] Based on data dependency, N pre-verified transactions are divided into M transaction subsets; each transaction subset contains one or more pre-verified transactions, and each pre-verified transaction in the same transaction subset has a data dependency relationship, M is a positive integer and M≤N;

[0278] Create transaction tasks for each of the M transaction subsets, with one transaction task corresponding to one transaction subset;

[0279] The target block is packaged based on M transaction tasks, and the M transaction tasks in the target block are processed in parallel on the blockchain.

[0280] In a possible implementation, the pre-execution result includes a read data set and a write data set of the pre-verification transaction, and any two pre-verification transactions among the N pre-verification transactions are represented as pre-verification transaction i and pre-verification transaction j; the processor 901 analyzes the N pre-execution results, determines the data dependency relationship between the N pre-verification transactions, and performs the following operations:

[0281] Performing data analysis on the pre-execution result of pre-verification transaction i and the pre-execution result of pre-verification transaction j to obtain a data analysis result;

[0282] Based on the data analysis results, determine the data dependency relationship between pre-verified transaction i and pre-verified transaction j;

[0283] Among them, the data dependency relationship between pre-verification transaction i and pre-verification transaction j includes any one or more of the following: a data dependency relationship between the read data set of pre-verification transaction i and the read data set of pre-verification transaction j, a data dependency relationship between the write data set of pre-verification transaction i and the write data set of pre-verification transaction j, a data dependency relationship between the read data set of pre-verification transaction i and the write data set of pre-verification transaction j, and a data dependency relationship between the write data set of pre-verification transaction i and the read data set of pre-verification transaction j.

[0284] In a possible implementation, both pre-verification transaction i and pre-verification transaction j belong to transactions in an asset transaction scenario; both the read data set and the write data set store data in a key-value pair format, where the key in the key-value pair refers to the account address; the processor 901 is further configured to perform the following operations:

[0285] If the account address of pre-verified transaction i is the same as the account address of pre-verified transaction j, it is determined that there is a data dependency relationship between pre-verified transaction i and pre-verified transaction j;

[0286] If the account address of pre-verification transaction i is different from the account address of pre-verification transaction j, it is determined that there is no data dependency relationship between pre-verification transaction i and pre-verification transaction j.

[0287] In a possible implementation, the read data set includes: executing a smart contract that needs to be called for a pre-verified transaction; the processor 901 is further configured to perform the following operations:

[0288] If the smart contract that needs to be called by pre-verification transaction i is the same as the smart contract that needs to be called by pre-verification transaction j, it is determined that there is a data dependency relationship between pre-verification transaction i and pre-verification transaction j;

[0289] If the smart contract that needs to be called by pre-verification transaction i is different from the smart contract that needs to be called by pre-verification transaction j, it is determined that there is no data dependency relationship between pre-verification transaction i and pre-verification transaction j.

[0290] In a possible implementation, the processor 901 divides N pre-verified transactions into M transaction subsets based on data dependencies, and performs the following operations:

[0291] If there is a data dependency relationship between pre-verified transaction i and pre-verified transaction j, pre-verified transaction i and pre-verified transaction j are classified into the same transaction subset;

[0292] If there is no data dependency relationship between pre-verification transaction i and pre-verification transaction j, pre-verification transaction i and pre-verification transaction j are respectively divided into different transaction subsets.

[0293] In a possible implementation, before obtaining N pre-verification transactions and the pre-execution result of each pre-verification transaction, the processor 901 is further configured to perform the following operations:

[0294] Receive pending transactions and perform pre-verification on the transactions, including: verifying the validity of the smart contract to be called by the transaction, verifying the security of the transaction, and verifying the legitimacy of the transaction;

[0295] If it is determined that the transaction has passed the pre-verification process, the transaction will be treated as a pre-verified transaction;

[0296] Execute the pre-verification transaction and obtain the pre-execution result of the pre-verification transaction.

[0297] In a possible implementation, the processor 901 executes the pre-verification transaction and obtains a pre-execution result of the pre-verification transaction, which is used to perform the following operations:

[0298] Create a transaction read cache and a transaction write cache for pre-verified transactions;

[0299] In the process of executing the pre-verification transaction, obtaining a read data set of the pre-verification transaction and storing the read data set of the pre-verification transaction in the transaction read cache; and,

[0300] Obtain a write data set for a pre-verified transaction and store the write data set for the pre-verified transaction in a transaction write cache.

[0301] In a possible implementation manner, the processor 901 is further configured to perform the following operations:

[0302] Parse the transaction data of the target pre-verification transaction to obtain a read data set of the target pre-verification transaction, where the target pre-verification transaction is any pre-verification transaction among the N pre-verification transactions;

[0303] Determine the target smart contract to be called by the target pre-verification transaction from the read data set of the target pre-verification transaction;

[0304] Call the target smart contract to execute the target pre-verified transaction and obtain the transaction execution data of the target pre-verified transaction;

[0305] Add the transaction execution data to the write data set of the target pre-verification transaction.

[0306] In a possible implementation manner, the processor 901 is further configured to perform the following operations:

[0307] Determine a serial transaction task from the M transaction tasks, where the serial transaction task includes a plurality of pre-verified transactions having data dependency relationships;

[0308] Add task tags to serial transaction tasks. Task tags are used to indicate the sequential execution of pre-verified transactions in the serial transaction tasks.

[0309] The target block with the task tag added is sent to at least one consensus node in the blockchain, so that after receiving the target block, the consensus node executes each pre-verification transaction in the serial transaction task in the order of the task tag, and executes the M transaction tasks in the target block in parallel.

[0310] In a possible implementation, the processor 901 adds a task tag to the serial transaction task to perform the following operations:

[0311] Obtaining the pre-execution results of each pre-verification transaction included in the serial transaction task in the target block, the pre-execution results including the read data set and the write data set of the pre-verification transaction;

[0312] Analyze the read data set and write data set of each pre-verification transaction to determine the transaction execution order between each pre-verification transaction;

[0313] An execution order array for the serial transaction task is generated based on the determined transaction execution order, and a task tag for the serial transaction task is generated based on the execution order array.

[0314] In a possible implementation, the processor 901 processes the M transaction tasks in the target block in parallel on the blockchain to perform the following operations:

[0315] Determine the number K of serial transaction tasks among the M transaction tasks, where K is a positive integer;

[0316] Start K contract coroutines and start MK contract processes;

[0317] Execute M transaction tasks in the target block in parallel in K contract coroutines and MK contract processes;

[0318] Among them, a transaction task is executed by a contract coroutine or a contract process.

[0319] In a possible implementation manner, the processor 901 is further configured to perform the following operations:

[0320] Determine the transaction execution order between each pre-verification transaction included in the serial transaction task;

[0321] According to the transaction execution order between each pre-verified transaction, each pre-verified transaction is executed sequentially in each contract coroutine.

[0322] In the embodiment of the present application, N pre-verification transactions and the pre-execution results of each pre-verification transaction can be obtained, N is a positive integer; the N pre-execution results are analyzed to determine the data dependency between the N pre-verification transactions; based on the data dependency, the N pre-verification transactions are divided into M transaction subsets; each transaction subset contains one or more pre-verification transactions, and each pre-verification transaction in the same transaction subset has a data dependency, M is a positive integer and M≤N; transaction tasks are created for each M transaction subset, one transaction task corresponds to one transaction subset; the target block is packaged based on the M transaction tasks, and the M transaction tasks in the target block are processed in parallel on the blockchain. It can be seen that the present application can perform pre-verification on each on-chain transaction and then pre-execute it, so as to obtain the pre-execution results of the pre-verification transaction, and the data dependency between each pre-verification transaction can be determined based on each pre-execution result, so that the pre-verification transaction can be divided into different transaction tasks according to the data dependency, and each transaction task can be executed in parallel in the blockchain, thereby realizing the parallel processing of blockchain transactions, which can improve the efficiency of transaction processing.

[0323] In addition, it should be pointed out here that: the embodiment of the present application also provides a computer storage medium, and a computer program is stored in the computer storage medium, and the computer program includes program instructions. When the processor executes the above program instructions, the method in the corresponding embodiment of the foregoing text can be executed, so it will not be repeated here. For technical details not disclosed in the computer storage medium embodiment involved in this application, please refer to the description of the method embodiment of this application. As an example, the program instructions can be deployed on a computer device, or executed on multiple computer devices located in one place, or, executed on multiple computer devices distributed in multiple locations and interconnected by a communication network.

[0324] According to one aspect of the present application, an embodiment of the present application further provides a computer program product or a computer program, the computer program product or the computer program including computer instructions, the computer instructions being stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device can execute the method in the above corresponding embodiment, and therefore, it will not be described in detail here.

[0325] A person skilled in the art can appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. A person skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0326] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present invention is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from a website site, a computer, a server or a data center to another website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access or a data processing device such as a server, a data center, etc. that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)), etc.

[0327] The above disclosure is only the preferred embodiment of the present application, which certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A blockchain transaction processing method, characterized in that: include: Obtaining N pre-verification transactions and a pre-execution result of each of the pre-verification transactions; N is a positive integer; Analyze N pre-execution results to determine data dependencies between the N pre-verification transactions; Based on the data dependency, the N pre-verified transactions are divided into M transaction subsets; each of the transaction subsets contains one or more pre-verified transactions, and each pre-verified transaction in the same transaction subset has a data dependency relationship, M is a positive integer and M≤N; Creating transaction tasks for the M transaction subsets respectively, one transaction task corresponding to one transaction subset; A target block is packaged based on the M transaction tasks, and the M transaction tasks in the target block are processed in parallel on the blockchain.

2. The method according to claim 1, characterized in that The pre-execution result includes a read data set and a write data set of the pre-verification transaction, and any two pre-verification transactions among the N pre-verification transactions are represented as pre-verification transaction i and pre-verification transaction j; and analyzing the N pre-execution results to determine the data dependency relationship between the N pre-verification transactions includes: Performing data analysis on the pre-execution result of the pre-verification transaction i and the pre-execution result of the pre-verification transaction j to obtain a data analysis result; Based on the data analysis result, determining a data dependency relationship between the pre-verification transaction i and the pre-verification transaction j; Among them, the data dependency relationship between the pre-verification transaction i and the pre-verification transaction j includes any one or more of the following: a data dependency relationship between the read data set of the pre-verification transaction i and the read data set of the pre-verification transaction j, a data dependency relationship between the write data set of the pre-verification transaction i and the write data set of the pre-verification transaction j, a data dependency relationship between the read data set of the pre-verification transaction i and the write data set of the pre-verification transaction j, and a data dependency relationship between the write data set of the pre-verification transaction i and the read data set of the pre-verification transaction j.

3. The method according to claim 2, characterized in that The pre-verification transaction i and the pre-verification transaction j both belong to transactions in the asset transaction scenario; the read data set and the write data set both store data in the format of key-value pairs, where the key in the key-value pair refers to the account address; the method further includes: If the account address of the pre-verification transaction i is the same as the account address of the pre-verification transaction j, it is determined that there is a data dependency relationship between the pre-verification transaction i and the pre-verification transaction j; If the account address of the pre-verification transaction i is different from the account address of the pre-verification transaction j, it is determined that there is no data dependency relationship between the pre-verification transaction i and the pre-verification transaction j.

4. The method according to claim 3, characterized in that The data read includes: executing the smart contract to be called for the pre-verification transaction; the method also includes: If the smart contract that needs to be called by the pre-verification transaction i is the same as the smart contract that needs to be called by the pre-verification transaction j, it is determined that there is a data dependency relationship between the pre-verification transaction i and the pre-verification transaction j; If the smart contract that needs to be called by the pre-verification transaction i is different from the smart contract that needs to be called by the pre-verification transaction j, it is determined that there is no data dependency relationship between the pre-verification transaction i and the pre-verification transaction j.

5. The method according to any one of claims 1 to 4, characterized in that: The dividing the N pre-verified transactions into M transaction subsets based on the data dependency relationship includes: If there is a data dependency relationship between the pre-verification transaction i and the pre-verification transaction j, the pre-verification transaction i and the pre-verification transaction j are classified into the same transaction subset; If there is no data dependency relationship between the pre-verification transaction i and the pre-verification transaction j, the pre-verification transaction i and the pre-verification transaction j are respectively divided into different transaction subsets.

6. The method according to claim 1, characterized in that Before obtaining N pre-verification transactions and the pre-execution result of each of the pre-verification transactions, the method further includes: Receive a transaction to be processed and perform a pre-verification process on the transaction, wherein the pre-verification process includes: verifying the validity of a smart contract to be invoked by the transaction, verifying the security of the transaction, and verifying the legitimacy of the transaction; If it is determined that the pre-verification process for the transaction is passed, the transaction is treated as a pre-verification transaction; The pre-verification transaction is executed to obtain a pre-execution result of the pre-verification transaction.

7. The method according to claim 6, characterized in that The executing the pre-verification transaction to obtain a pre-execution result of the pre-verification transaction includes: Creating a transaction read cache and a transaction write cache for the pre-verified transaction; In the process of executing the pre-verification transaction, obtaining a read data set of the pre-verification transaction, and storing the read data set of the pre-verification transaction in a transaction read cache; and, A write data set of the pre-verification transaction is obtained, and the write data set of the pre-verification transaction is stored in a transaction write cache.

8. The method according to claim 7, characterized in that The method further comprises: Parsing transaction data of a target pre-verification transaction to obtain a read data set of the target pre-verification transaction, wherein the target pre-verification transaction is any one of the N pre-verification transactions; Determine, from the read data set of the target pre-verification transaction, a target smart contract to be called by the target pre-verification transaction; Calling the target smart contract to execute the target pre-verification transaction, and obtaining transaction execution data of the target pre-verification transaction; The transaction execution data is added to a write data set of the target pre-verification transaction.

9. The method according to claim 1, characterized in that The method further comprises: Determine a serial transaction task from the M transaction tasks, wherein the serial transaction task includes a plurality of pre-verified transactions having a data dependency relationship; Adding a task tag to the serial transaction task, wherein the task tag is used to indicate the sequential execution of each pre-verification transaction in the serial transaction task; The target block with the task tag added is sent to at least one consensus node in the blockchain, so that after receiving the target block, the consensus node executes each pre-verification transaction in the serial transaction task in the order of the task tag, and executes the M transaction tasks in the target block in parallel.

10. The method according to claim 9, characterized in that The step of adding a task label to the serial transaction task includes: Obtaining pre-execution results of each pre-verification transaction included in the serial transaction task in the target block, wherein the pre-execution results include a read data set and a write data set of the pre-verification transaction; Analyze the read data set and write data set of each pre-verification transaction to determine the transaction execution order between each pre-verification transaction; An execution order array for the serial transaction task is generated based on the determined transaction execution order, and a task tag for the serial transaction task is generated based on the execution order array.

11. The method according to claim 9, characterized in that The parallel processing of the M transaction tasks in the target block on the blockchain includes: Determine the number K of serial transaction tasks among the M transaction tasks, where K is a positive integer; Start K contract coroutines and start MK contract processes; Execute the M transaction tasks in the target block in parallel in the K contract coroutines and the MK contract processes; Among them, a transaction task is executed by a contract coroutine or a contract process.

12. The method according to claim 11, characterized in that The method further comprises: Determine the transaction execution order between each pre-verification transaction included in the serial transaction task; According to the transaction execution order between the pre-verification transactions, the pre-verification transactions are executed sequentially in each contract process.

13. A blockchain transaction processing device, characterized in that: include: An acquisition unit, used to acquire N pre-verification transactions and a pre-execution result of each of the pre-verification transactions; N is a positive integer; A processing unit, configured to analyze the N pre-execution results and determine data dependencies between the N pre-verification transactions; The processing unit is further used to divide the N pre-verified transactions into M transaction subsets based on the data dependency relationship; each of the transaction subsets contains one or more pre-verified transactions, and each pre-verified transaction in the same transaction subset has a data dependency relationship, and M is a positive integer and M≤N; The processing unit is further used to create transaction tasks for the M transaction subsets respectively, where one transaction task corresponds to one transaction subset; The processing unit is further used to package the target block based on the M transaction tasks, and to process the M transaction tasks in the target block in parallel on the blockchain.

14. A computer device, characterized in that: include: storage devices and processors; a memory storing one or more computer programs; A processor, configured to load the one or more computer programs to implement the blockchain transaction processing method as described in any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and the computer program is suitable for being loaded by a processor and executing the blockchain transaction processing method as claimed in claims 1-12.

16. A computer program product, characterized in that The computer program product includes a computer program, which is suitable for being loaded by a processor and executing the blockchain transaction processing method as claimed in claims 1-12.

Images