Transaction execution method and apparatus, computer device, and medium

Abstract

Embodiments of the present application are suitable for the field of blockchain technology, and provide a transaction execution method and device, computer equipment and a medium. The method comprises: dividing a plurality of transactions in a block into a plurality of transaction groups, each transaction group comprising at least one transaction; executing each transaction group in parallel by a plurality of first sub-executors to generate a read-write set corresponding to each transaction, each first sub-executor being configured to execute one transaction group; performing conflict detection on each transaction according to the read-write set; and determining that the block execution is completed when each transaction does not have an execution conflict. Through the above method, the transactions in the block can be executed in parallel, the resource utilization rate is improved, and the performance of the blockchain is improved.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, and in particular relates to a transaction execution method, apparatus, computer equipment and medium. Background Technology

[0002] As a distributed ledger, a blockchain allows one master node to select a batch of transactions from a transaction pool, package them into blocks, and then synchronize the blocks to other nodes. Each node in the blockchain executes and verifies the transactions in the block. To ensure consistency in transaction execution results across all nodes and to avoid the influence of random factors, blockchain nodes execute transactions sequentially according to the order of the transaction list when the block is packaged.

[0003] However, executing transactions sequentially cannot take advantage of the multi-core nature of the processor (Central Processing Unit / Processor, CPU), resulting in low resource utilization and poor overall performance of the blockchain. Summary of the Invention

[0004] In view of this, embodiments of this application provide a transaction execution method, apparatus, computer equipment, and medium for parallel execution of transactions, improving resource utilization and thereby enhancing blockchain performance.

[0005] A first aspect of this application provides a transaction execution method, including:

[0006] The multiple transactions in the block are divided into multiple transaction groups, and each transaction group includes at least one of the transactions;

[0007] Each transaction group is executed in parallel by multiple first sub-executors to generate a read-write set that corresponds one-to-one with each transaction. Each first sub-executor is used to execute one of the transaction groups.

[0008] Conflict detection is performed on each of the transactions based on the read / write set;

[0009] If none of the transactions have execution conflicts, then the block is determined to be completed.

[0010] A second aspect of this application provides a transaction execution apparatus, which includes a transaction static analysis module, a transaction scheduling module, and a read / write set management module, wherein:

[0011] The transaction static analysis module is used to analyze the transactions in the block and generate at least one transaction group, wherein the transaction group includes at least one of the transactions.

[0012] The transaction scheduling module is used to execute each of the transaction groups in parallel and generate read / write sets for each of the transactions;

[0013] The read-write set management module is used to perform conflict detection on each of the transactions based on the read-write set in order to determine whether the block has been completed.

[0014] A third aspect of this application provides another transaction execution apparatus, including:

[0015] A transaction grouping module is used to divide multiple transactions in a block into multiple transaction groups, and each transaction group includes at least one of the transactions;

[0016] The parallel execution module is used to execute each of the transaction groups in parallel through multiple first sub-executors, generating a read-write set that corresponds one-to-one with each of the transactions, wherein each first sub-executor is used to execute one of the transaction groups;

[0017] The conflict detection module is used to perform conflict detection on each of the transactions based on the read-write set;

[0018] The completion determination module is used to determine that the block has been completed when none of the transactions have execution conflicts.

[0019] A fourth aspect of this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect above.

[0020] A fifth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0021] A sixth aspect of this application provides a computer program product that, when run on a computer device, causes the computer device to perform the method described in the first aspect.

[0022] Compared with the prior art, the embodiments of this application have the following advantages:

[0023] In this embodiment, when a blockchain node executes a new block, it can divide the transactions in the block into multiple transaction groups, each of which may include at least one transaction. Since the states of the transaction groups are independent, multiple first sub-executors can execute each transaction group in parallel, thereby fully utilizing the multi-core capabilities of the processor. After each transaction is executed, a corresponding read-write set can be generated. Based on the read-write set, conflict detection can be performed on the transactions to determine if any execution errors occurred during the transaction execution process. When none of the transactions have execution conflicts, the block execution is considered complete. This embodiment improves the utilization of computing resources and enhances the performance of the blockchain by dividing the transactions in the block into multiple state-independent transaction groups and then executing each transaction group in parallel. By performing conflict detection on the transactions, the execution results of the transactions can be confirmed after parallel execution, thus ensuring the accuracy of the block execution results. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0025] Figure 1 This is a flowchart illustrating the steps of a transaction execution method provided in an embodiment of this application;

[0026] Figure 2 This is a schematic diagram of a sub-actuator provided in an embodiment of this application;

[0027] Figure 3 This is a flowchart illustrating the steps of another transaction execution method provided in this application embodiment;

[0028] Figure 4 This is a schematic diagram of a transaction execution apparatus provided in an embodiment of this application;

[0029] Figure 5 This is a flowchart illustrating another transaction execution method provided in an embodiment of this application;

[0030] Figure 6 This is a schematic diagram of another transaction execution apparatus provided in an embodiment of this application;

[0031] Figure 7 This is a schematic diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0032] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0033] To improve blockchain performance, transactions can be executed in parallel, thereby increasing the blockchain's throughput.

[0034] ChainMaker's implementation of parallel transactions is as follows: After the consensus master node selects a batch of transactions from the transaction pool, it first randomly executes these transactions in parallel. Then, it records and temporarily applies the read-write sets generated from the execution results of the transactions in the random execution order. If subsequent transactions conflict with previous transactions, they are re-executed based on the ledger that applied the previous transactions. Finally, the dependencies of the transactions are generated into a Directed Acyclic Graph (DAG) and packaged into the block structure. The DAG determines the concurrency and execution order of the transactions. When other nodes receive the block, they execute it in parallel according to the order in the DAG. The disadvantage of this scheme is that the order of transactions packaged in the block is determined by whether there are conflicting relationships between transactions, that is, it is not sorted according to the order in which the transactions were sent or the transaction fees, and it requires modification of the consensus logic and the packaged data.

[0035] The FISCO consortium blockchain determines the parallelism of a block by partitioning it using contract ledger addresses. This means that at any given time, only one transaction can operate on a single contract address. Subsequent transactions targeting that address must wait for the current transaction to finish executing and release the lock on that contract address before they can proceed. However, when cross-contract transactions exist, deadlocks may occur. Therefore, FISCO's solution has high requirements for triggering transaction parallelism, and transaction parallelism is impossible when all transactions operate on the same contract address.

[0036] In summary, current technologies often require modifications to other modules within the blockchain, such as changing the consensus structure, when enabling parallel transactions, or the degree of transaction parallelism is not high. Therefore, this application provides a transaction parallelism method that can achieve parallel transactions and improve transaction concurrency by modifying only the transaction execution module.

[0037] The technical solution of this application will be described below through specific embodiments.

[0038] Reference Figure 1The diagram illustrates a step-by-step flowchart of a transaction execution method provided in an embodiment of this application, which may specifically include the following steps:

[0039] S101, divide the multiple transactions in the block into multiple transaction groups, each of the transaction groups including at least one of the transactions.

[0040] The execution entity in this embodiment can be a blockchain node device, which can be a computer device such as a tablet computer, wearable device, in-vehicle device, laptop computer, super mobile personal computer, or server. At least one blockchain node can be deployed on the node device.

[0041] If a blockchain node is the master node, it can retrieve multiple transactions from the transaction pool, package them into a block, and then synchronize the block to other nodes in the blockchain. If a blockchain node is not the master node, it can receive blocks from the master node.

[0042] Blockchain nodes can execute blocks sequentially. After a block is completed, the block ledger can be updated based on the block's execution result. The block's execution result includes the execution result of each transaction in the block, and the block ledger can include the state data and ledger data of the currently completed blocks in the blockchain nodes. When a new block is to be executed, it indicates that the previous block has been completed, and at this time, the block ledger can include the state data of the previous block after its completion.

[0043] After receiving a block, a blockchain node can retrieve multiple transactions from the block, analyze these transactions, and divide the blockchain into several distinct transaction groups. These transaction groups are independent of each other, allowing for parallel processing. Each transaction group can contain at least one transaction.

[0044] In one possible implementation, transactions can be grouped based on the smart contracts invoked. Transactions can complete corresponding operations by invoking smart contracts, which may include operations on fields. Static analysis can be performed on each smart contract in the blockchain node to determine the fields that each smart contract needs to operate on and the types of operations required on those fields. Based on the fields that each smart contract needs to operate on and the operations required on those fields, related smart contracts can be identified. Based on the smart contracts invoked by each transaction and the related smart contracts, transactions with dependencies can be identified. Transactions with dependencies are grouped together, thus dividing the transactions in a block into multiple transaction groups. Each transaction group may include one or more transactions. When a transaction group includes multiple transactions, the transactions within the group can have a corresponding order, arranged according to the order in which they were executed.

[0045] S102, each of the transaction groups is executed in parallel by multiple first sub-executors to generate a read-write set corresponding to each of the transactions, and each first sub-executor is used to execute one of the transaction groups.

[0046] Based on the number of processor cores in the node device, a preset number of sub-executors can be generated. Preferably, the number of sub-executors can be twice the number of processor cores in the blockchain node device, thereby ensuring that the characteristics of multi-core processors can be fully utilized during parallel transactions.

[0047] Figure 2 This is a schematic diagram of a sub-actuator provided in an embodiment of this application. For example... Figure 2 As shown, the sub-executor may include a virtual machine execution engine and a transaction ledger. The virtual machine execution engine may include the HVM virtual machine and the Ethereum Virtual Machine (EVM). The transaction ledger may include a ledger database and a state database; the initial transaction ledger may be generated based on the block ledger. The initial ledger data may be the ledger data of the previous block in the block ledger, and the initial state database may be the state data after the previous block was executed.

[0048] Multiple first sub-executors can be identified from the aforementioned multiple sub-executors. These first sub-executors can be used to execute transaction groups. When a transaction group contains multiple transactions, the first sub-executors can execute the multiple transactions in the transaction group sequentially according to the transaction execution order.

[0049] Based on the transaction ledger and virtual machine execution engine, each first sub-executor can execute one transaction group at a time. A blockchain node includes multiple first sub-executors, each capable of executing one transaction group simultaneously; that is, multiple sub-executors can execute multiple corresponding transaction groups in parallel. This parallel execution of transaction groups by multiple sub-executors improves transaction execution efficiency.

[0050] In one possible implementation, the number of transaction groups may exceed the number of first sub-executors. After determining the transaction groups, one transaction group can be allocated to each first sub-executor, and the remaining unallocated transaction groups can be temporarily stored. Once a first sub-executor has executed a transaction group, it can be re-initialized to continue executing previously unallocated transaction groups. After executing a transaction group, the first sub-executor can obtain the execution results of each transaction within the group and the operations performed on its fields. Each transaction can have a read / write set, which can include the execution results of the transaction and the operations performed on its fields.

[0051] S103, perform conflict detection on each of the transactions according to the read / write set.

[0052] In parallel transaction execution, compared to serial transaction execution, factors that can lead to incorrect transaction results may include write-read conflicts. For example, if transaction 1 performs a write operation on data A, and transaction 2 performs a read operation on data A, and transaction 2 executes after transaction 1 has finished, then when transactions 1 and 2 execute in parallel, the value of data A obtained by transaction 2 will be incorrect, resulting in an incorrect execution result for transaction 2.

[0053] While it's possible to group transactions with read / write conflicts together to avoid erroneous execution results, to further ensure correct outcomes, it's advisable to check for read / write conflicts during the parallel execution of each transaction after its completion. The read / write set can include the fields involved in the transaction and their corresponding operations. During conflict detection, the execution order of the transactions can be followed, and the read / write set of each transaction can be used to determine if any read / write conflicts exist between that transaction and other transactions preceding it.

[0054] Specifically, after the first transaction is executed, it can be determined that the first transaction does not have an execution conflict. The read / write set of the second transaction is obtained, and based on the read / write sets of the second and first transactions, it can be determined whether the second transaction has a conflict. If no conflict exists, the read / write set of the third transaction can be obtained, and based on the read / write sets of the third, second, and first transactions, it can be determined whether the third transaction has a conflict. If the second transaction has a conflict, it can be re-executed using the second sub-executor transaction. Then, based on the read / write set obtained from the re-execution, it can be determined that the second transaction does not have an execution conflict. The third transaction can then be evaluated. This process continues until all transactions have been checked. The transaction conflict detection process is executed sequentially; if the previous transaction has not been determined to be free of execution conflicts, the conflict detection for the next transaction is generally not performed.

[0055] It should be noted that this step can be executed in parallel with the previous step. That is, after obtaining the execution result of the first transaction, conflict detection can be performed on the first transaction; after the conflict detection of the first transaction is completed, if the second transaction has also been completed, conflict detection can be performed on the second transaction; and so on, performing conflict detection on transactions according to their execution order. When performing conflict detection, only the read / write set of the currently sorted transactions is needed; it is not necessary for all transactions to be completed. For example, the transactions are grouped as (transaction 1) and (transaction 2, transaction 3), with one first sub-executor executing transaction 1 and the other executing transactions 2 and 3; after transaction 1 is completed, the other first sub-executor may not have completed executing the transaction group yet, but as long as the execution result of transaction 1 is obtained, conflict detection for transaction 1 can be performed. Based on this, transaction execution and conflict detection can achieve a certain degree of parallelism, thereby improving transaction execution efficiency and shortening transaction execution time.

[0056] Since conflict detection and transaction execution can be performed in parallel, one sub-executor in the blockchain can be designated as the second sub-executor, and the others as the first sub-executors. This means a blockchain node includes one second sub-executor and multiple first sub-executors. The second sub-executor can be used only for re-executing transactions, rather than for executing them. This ensures that when re-executing a transaction, there is no need to wait for an idle sub-executor, allowing conflict detection to run concurrently with transaction execution and improving transaction concurrency.

[0057] S104, if none of the transactions have execution conflicts, then the block execution is determined to be complete.

[0058] When each transaction has no execution conflict, the block execution can be considered complete, and the execution results of each transaction can be applied to the block ledger. Then, the steps in this embodiment can be used to continue executing the next block. For example, the block ledger may include multiple fields, each with a corresponding value. The transaction read / write set also includes the field values ​​of multiple fields after transaction execution. Based on the fields and field values ​​in the read / write set, field values ​​can be updated or new fields can be created in the block ledger, which is equivalent to determining the execution results of each transaction in the block ledger.

[0059] Specifically, when a transaction is determined to have no execution conflicts, it is equivalent to confirming that the execution result of the transaction is correct. At this point, the execution result of the transaction can be temporarily saved. Then, conflict detection is performed on the next transaction until the execution result of the last transaction is determined to be correct, and the execution result of the last transaction is temporarily saved. Then, the execution results of all the temporarily saved transactions can be stored in the block ledger, updating the state of the block ledger.

[0060] This embodiment allows for the parallel execution of multiple transaction groups based on multiple first sub-executors, and it achieves a certain degree of parallelism between transaction execution and transaction conflict detection. Therefore, the method in this embodiment has high transaction parallelism, which can shorten transaction execution time, improve transaction execution efficiency, and thus enhance blockchain performance. Furthermore, after transaction execution is complete, conflict detection can be used to determine whether errors occurred during the transaction execution process, thereby ensuring the accuracy of the transaction execution results. This embodiment's method ensures the correctness of transaction execution results while executing transactions in parallel, fully utilizing the multi-core characteristics of processors and improving blockchain performance.

[0061] Reference Figure 3 This illustration shows a flowchart of another transaction execution method provided in an embodiment of this application, which may specifically include the following steps:

[0062] S301, divide the multiple transactions in the block into multiple transaction groups, each of the transaction groups including at least one of the transactions.

[0063] S302, each of the transaction groups is executed in parallel by multiple first sub-executors to generate a read-write set corresponding to each of the transactions, and each first sub-executor is used to execute one of the transaction groups.

[0064] S301-S302 in this embodiment is similar to S101-S102 in the previous embodiment and can be referred to each other. They will not be described in detail here.

[0065] S303, determine the first transaction to be detected according to the transaction execution order.

[0066] Transactions can have a corresponding transaction order based on the order in which they were packaged. When performing transaction conflict detection, transactions can be checked sequentially according to their execution order. The first transaction to be checked is the transaction with the earliest execution order among those currently not determined to be free of execution conflicts.

[0067] Once the first sub-executor has completed executing the first transaction, it can be used as the first transaction for conflict detection. Since the first transaction is the first to be executed, there are no preceding transactions in this block that would affect it. Therefore, the execution result of the current first transaction is not affected by other transactions in this block and there is no execution conflict.

[0068] After the first transaction conflict detection is completed, it can be determined whether the first transaction has an execution conflict. If the first transaction does not have an execution conflict, the next transaction of the first transaction is taken as the new first transaction. If the first transaction has an execution conflict, the first transaction can be re-executed, and the read-write set after the first transaction is re-executed can be obtained. Then, based on the read-write set, the first transaction is re-detected for conflict. Based on the read-write set after re-execution, it can be determined that the first transaction has no execution conflict. At this time, the next transaction of the first transaction can be taken as the new first transaction.

[0069] In this embodiment, the terms "first," "second," "next," and "last" are all described based on the transaction execution order.

[0070] S304, determine the target field based on the read / write set of the first transaction, wherein the target field is the field in which a read operation is performed in the first transaction.

[0071] Field operations can include read and write operations. A read operation requires retrieving the field's value, while a write operation modifies that value. During transaction execution, the values ​​retrieved by read operations are typically used for subsequent operations. Therefore, if the value retrieved by a read operation is incorrect, the subsequent transaction execution result will also be incorrect. Conversely, a write operation to change a field's value does not require the field's value to be correct; the transaction will proceed based on the field value corresponding to the write operation because a write operation does not cause subsequent execution results to be incorrect. For example, to increment the value of field A, a read operation on field A is required first, followed by a write operation. If the retrieved value is incorrect, the increment of field A will also be incorrect, meaning the value of field A corresponding to the subsequent write operation will be incorrect. However, to assign a value to field A, setting A to 1, a write operation on field A is required. After the write operation, A equals 1, which is correct. Therefore, subsequent operations based on this field will not result in errors. Thus, when determining if there is an execution conflict, it is necessary to determine whether the field value retrieved by the read operation is correct. In this case, the field read in the first transaction can be identified first.

[0072] From the read / write set of the first transaction, the target field for which a read operation was performed in the first transaction can be identified. If the target field for which a read operation was performed does not exist in the first transaction, then it can be determined that there is no execution conflict in the first transaction.

[0073] S305, based on the read / write set, detect whether there is a second transaction that performs a write operation on the target field, wherein the second transaction is a transaction whose execution order precedes the first transaction.

[0074] Write-read conflicts can lead to errors in parallel execution. Specifically, if a transaction preceding the first transaction performs a write operation on a field, and the first transaction then performs a read operation on that same field, the first transaction's execution result will be incorrect during parallel execution. In this case, we can determine the first read-write set of the first transaction and the second read-write sets of all transactions preceding it in the execution order. Then, we can determine whether each field in the first transaction's read-write set that underwent a read operation was also written to in any of the second read-write sets. If a second read-write set performed a write operation on a field, and the first read-write set performed a read operation on that field, then the transaction corresponding to that second read-write set can be identified as the second transaction.

[0075] If no transaction performed a write operation on the target field before the first transaction, then there is no second transaction that conflicts with the first transaction. If there is no second transaction that conflicts with the first transaction in parallel, then it is determined that the first transaction does not have an execution conflict. It can then be confirmed that the execution result of the first transaction in the read / write set is correct. Then, a new first transaction is determined, and conflict detection continues based on the new first transaction until conflict detection of all transactions is completed.

[0076] S306, if the second transaction exists, determine the transaction group of the second transaction.

[0077] S307, perform conflict detection on the first transaction based on the transaction grouping of the second transaction.

[0078] If the second transaction is not in the same transaction group as the first transaction, it means that the two transactions must be executed in parallel, and therefore the first transaction is determined to have an execution conflict.

[0079] If the second transaction and the first transaction are in the same transaction group, it means that these two transactions were executed sequentially according to the transaction execution order. The two transactions executed sequentially will not conflict with each other. However, if the second transaction has been re-executed before, then the subsequent transactions in the sequence also need to be re-executed. Therefore, it can be determined whether the second transaction is the target transaction that the second sub-executor has re-executed; if the second transaction is not the target transaction, it is determined that the first transaction does not have an execution conflict; if the second transaction is the target transaction, it is determined that the first transaction has an execution conflict.

[0080] S308, if there is a target transaction with execution conflict, the target transaction is re-executed through the second sub-executor.

[0081] If there are target transactions with execution conflicts, the execution results of all transactions whose execution order precedes the target transaction can be sent to the second sub-executor along with the target transaction's identification information. The second sub-executor can then determine the target transaction that needs to be re-executed based on the identification information, and then re-execute the target transaction based on the execution results of the transactions preceding it, resulting in a new read / write set.

[0082] Specifically, the transaction read / write set includes the transaction execution result. Therefore, the read / write sets of all transactions whose execution order precedes the target transaction can be sent to the second sub-executor. The second sub-executor can apply these read / write sets to the transaction ledger and re-execute the target transaction based on this ledger. Since the transaction ledger initialized by the second sub-executor is generated based on the previous block ledger, and the previous block ledger is already correct, and all transactions before the target transaction have undergone conflict detection, it is equivalent to confirming that the execution result is correct. Therefore, when executing the target transaction, the data in the transaction ledger is correct, thus ensuring that the correct execution result can be obtained after executing the target transaction, that is, the new read / write set obtained after executing the target transaction is correct.

[0083] Based on this new read-write set, conflict detection can be resumed. A re-execution flag can be added to the new read-write set; when performing conflict detection based on the read-write set, if the read-write set contains a re-execution flag, it can be directly determined that the corresponding transaction does not have an execution conflict.

[0084] It should be noted that when performing conflict detection on the first transaction based on the read-write sets of all transactions prior to the first transaction and the read-write set of the first transaction, if there is a re-executed transaction prior to the first transaction, the read-write set corresponding to the re-executed transaction should be the read-write set of the second sub-executor that executed the transaction.

[0085] S309, if none of the transactions have execution conflicts, then the block execution is determined to be complete.

[0086] Once it is determined that the last transaction does not have any execution conflicts, it can be confirmed that the execution results of all transactions are correct. At this point, the block execution is complete, and the execution results of all transactions can be stored in the block ledger.

[0087] Specifically, if a transaction does not have an execution conflict, the execution result can be stored in the temporary block ledger. Then, the system continues to check whether the next transaction has an execution conflict. When the execution result of the last transaction in the execution order is applied to the temporary block ledger, it can be shown that the execution result of each transaction is correct and that the execution result of each transaction has been stored in the temporary block ledger, thus confirming that the block execution is complete. At this point, the execution results of all transactions in the temporary ledger can be stored in the block ledger.

[0088] After that, the data in the temporary block ledger can be cleared, and the execution of the next block can continue.

[0089] In this embodiment, each transaction can be executed in parallel by a first sub-executor, and conflict detection can be performed on each transaction sequentially. When a conflict is determined based on the conflict detection, the read-write set before the transaction is merged and applied to a second sub-executor. The transaction is then re-executed in the second sub-executor to resolve the conflict, thereby ensuring the correctness of the transaction result and completing the confirmation of the transaction execution result. This ensures the accuracy of the block execution result, and even with parallel transactions during block execution, it can be ensured that each blockchain node obtains the same execution result when executing the same block. It should be noted that the sequence number of each step in the above embodiment does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of this application embodiment.

[0090] This application also provides a transaction execution apparatus, which may include a transaction static analysis module, a transaction scheduling module, and a read / write set management module, wherein:

[0091] The aforementioned static transaction analysis module is used to analyze transactions in a block and generate at least one transaction group, wherein the transaction group includes at least one of the aforementioned transactions.

[0092] The aforementioned transaction scheduling module is used to execute each of the aforementioned transaction groups in parallel and generate read / write sets for each of the aforementioned transactions;

[0093] The aforementioned read-write set management module is used to perform conflict detection on each of the aforementioned transactions based on the aforementioned read-write set, in order to determine whether the aforementioned block has been completed.

[0094] The aforementioned transaction scheduling module includes a list of sub-executors, which includes at least one first sub-executor. The first sub-executor includes a transaction ledger, wherein:

[0095] The above list of sub-executors is used to execute each of the above-mentioned transaction groups in parallel through each of the above-mentioned first sub-executors;

[0096] The first sub-executor is used to execute one of the aforementioned transaction groups based on the aforementioned transaction ledger.

[0097] The aforementioned read-write set management module is also used to determine the target transaction with execution conflict based on the aforementioned read-write set, and send the target transaction to the aforementioned transaction scheduling module;

[0098] The aforementioned transaction scheduling module is also used to re-execute the aforementioned target transactions that have execution conflicts.

[0099] The aforementioned device also includes a temporary block ledger, and the aforementioned read / write set management module is further used for:

[0100] If it is confirmed that the above transactions do not have execution conflicts, the execution results of the above transactions will be applied to the above temporary block ledger;

[0101] If the execution results of each of the above transactions are applied to the above temporary block ledger, then the data in the above temporary block ledger will be stored in the block ledger of the blockchain node.

[0102] The aforementioned transaction scheduling module also includes a second sub-executor, which is used to execute the aforementioned target transactions that have execution conflicts.

[0103] The transaction grouping module is used to divide multiple transactions in a block into multiple transaction groups, and each of the above transaction groups includes at least one of the above transactions.

[0104] The parallel execution module is used to execute each of the above-mentioned transaction groups in parallel through multiple first sub-executors, generating a read-write set that corresponds one-to-one with each of the above-mentioned transactions. Each of the above-mentioned first sub-executors is used to execute one of the above-mentioned transaction groups.

[0105] The conflict detection module is used to perform conflict detection on each of the above transactions based on the above read-write set;

[0106] The completion determination module is used to determine that the above block has been completed if none of the above transactions have execution conflicts.

[0107] The specific execution process of each module of the trading device in this embodiment can be referred to other method embodiments, and will not be repeated here.

[0108] Figure 4 This is a schematic diagram of a transaction execution device provided in an embodiment of this application, such as... Figure 4 As shown, the execution device may include a sub-executor No. 0, a list of sub-executors, a block ledger, a read / write set management module, and a transaction static analysis module. Figure 4The transaction execution device shown can be an example of the transaction execution device provided in the previous embodiment, wherein the No. 0 sub-executor, the sub-executor list and the block ledger can constitute the transaction scheduling module described above. The No. 0 sub-executor can be the second sub-executor described above. The sub-executor list can include multiple first sub-executors described above. The block ledger can be the temporary block ledger described above.

[0109] Figure 5 yes Figure 4 A flowchart illustrating the execution process of the actuators within a block. (For example...) Figure 5 As shown, the transaction static analysis module, transaction scheduling module, and read / write set management module execute in parallel, working in a pipeline manner. First, the transaction static analysis module analyzes the block transactions, generating several state-independent transaction lists. Figure 5 The transaction list in the table refers to the aforementioned transaction groups. The transaction list can be placed into the transaction queue, and then the transaction list can be retrieved from the transaction queue in parallel and added to the transaction scheduling module.

[0110] The transaction scheduling module pre-creates a thread pool and several sub-executors, which can reside in a sub-executor queue. When a transaction list arrives, the thread pool can retrieve a sub-executor from the idle sub-executor queue to execute the transaction. Before executing a transaction in the transaction list, the sub-executor initializes the transaction ledger: a transaction ledger is created based on the block ledger. The execution of transactions within the sub-executor is based on this transaction ledger, which generates a corresponding read-write set for each transaction. After the read-write set is generated, the transaction scheduling module can send the read-write set to the read-write set management module. Simultaneously, after executing all transactions in the transaction list, the sub-executor can be returned to the idle sub-executor list.

[0111] After generating the read / write set, the read / write set management module can concurrently perform conflict checks and applications on the read / write sets according to the order in which transactions are packaged. The read / write set management module sequentially checks the conflict of each transaction based on its read / write set. If the read / write set management module determines that the current transaction has no conflict, it sends the execution result of the current transaction to the transaction scheduling module to confirm the completion of the transaction. If the read / write set determines that the current transaction has a conflict, it applies the read / write sets of all transactions preceding the current transaction to the transaction ledger in sub-executor 0, and sends the conflict information of this transaction to sub-executor 0. Sub-executor 0 can then obtain the transaction that needs to be re-executed from the transaction scheduling module based on the conflict information from the read / write set management module, and then re-execute the transaction based on the updated transaction ledger. Since the execution results of all transactions preceding the current transaction have been confirmed as correct, the new ledger obtained by applying the read / write sets of all transactions preceding the current transaction to the transaction ledger in sub-executor 0 is correct. After re-executing the current transaction based on this ledger, the execution result of the current transaction is correct. A re-executed transaction is based on the results of all previous transactions, so there will be no conflict. After the re-execution of the transaction is completed, a new read-write set will be obtained. The read-write set management module can continue to correct the execution result of the current transaction based on the new read-write set, and then continue to determine whether there is a conflict in the transaction based on the read-write set of the subsequent transactions.

[0112] Figure 5 The read / write set management module includes a block ledger, which can be a temporary block ledger. After each transaction is confirmed to be conflict-free, the execution result of that transaction in the corresponding read / write set can be applied to this temporary block ledger. When all transactions have been executed, the transaction scheduling module sends an end signal to inform each module that block execution has ended, thus completing the parallel execution of transactions within a block.

[0113] To better illustrate this application, specific examples are provided below.

[0114] First, let's illustrate this scenario with no transaction conflicts after all transactions are executed in parallel:

[0115] Suppose that there are 6 transactions in the current block: tx1, tx2, tx3, tx4, tx5, and tx6. Their grouping is as follows:

[0116] Group 1: tx1, tx3, tx4

[0117] Group 2: tx2, tx5

[0118] Group3: tx6

[0119] Transaction packets are retrieved in parallel, and a sub-executor is assigned to each transaction packet. The read and write sets generated after each transaction packet is executed are shown in Table 1.

[0120] Tx1 IN<key1,value1,g1> Tx2 IN<key2,value2,g2> Tx3 R<key1,g1>,W<key3,value3,g1> Tx4 IN<key2,value2’,g1> ,IN<key4,value4,g1> Tx5 R<keyA,g2>,W<key5,value5,g2> Tx6 R<keyA,g3>,W<key6,value6,g3>

[0121] Table 1

[0122] It should be noted that in this embodiment, the read / write set is represented as follows: R<k,g> This indicates the read set, where k represents the key value to be read, and g represents the group number containing that key; W<k,v,g> This indicates a write set, where k represents the modified key value, v represents the value corresponding to that key, and g represents the group number of the modified key.

[0123] After the transaction read / write set is generated, the read / write set management module will judge the transactions sequentially. First, Tx1 is the first conflict-free transaction, so its execution result can be applied to the temporary block ledger. Next, Tx2 includes a key2 that has no conflict with the previous transaction, so it also has no conflict, and its execution result can be applied to the temporary block ledger. Tx3 reads a key1, which was written to in Tx1, and should theoretically cause a read / write conflict. However, since Tx1 and Tx3 belong to the same transaction group, they are executed based on the same transaction ledger, so there is no conflict, and the execution result of Tx3 can be applied to the temporary block ledger. Tx4 also writes a previously non-existent key4, without conflict. Writing a key2 is identical to Tx2, although they don't belong to the same group. However, write-write operations are also not conflicting, so Tx4 is also conflict-free, and its result can be applied to the temporary block ledger. Tx5 reads keyA and writes key5 without conflict, and its result can be applied to the temporary block ledger. Tx6 writes key6 without conflict, and reads keyA, which is identical to the read set of Tx5, but read-read operations are not conflicting, so Tx6 is also conflict-free, and its result can be applied to the temporary block ledger. Therefore, all transactions are conflict-free, and the transaction results are correct.

[0124] After the read-write set management module has judged all read-write sets, it informs the transaction scheduling module of successful transactions. After receiving the execution result of each transaction, the transaction scheduling module can apply the execution result of each transaction to the block ledger of the current node of the blockchain, thereby completing the execution of each transaction in the block ledger. After that, it informs each module to exit, and the current block execution is complete.

[0125] The following scenario illustrates a situation where transaction conflicts arise after transactions have been executed in parallel:

[0126] Suppose that there are 6 transactions in the current block: tx1, tx2, tx3, tx4, tx5, and tx6. Their grouping is as follows:

[0127] Group 1: tx1, tx3, tx4

[0128] Group 2: tx2, tx5

[0129] Group3: tx6

[0130] Transaction groups are retrieved in parallel and assigned to sub-executors. The read / write sets generated after each transaction group is executed are shown in Table 2.

[0131]

[0132]

[0133] Table 2

[0134] After generating the transaction read / write set, the read / write set management module will judge the transactions sequentially. First, Tx1 is the first conflict-free transaction, and its execution result can be applied to the temporary block ledger. Then, Tx2 writes a key2 that has no conflict with the previous one, so it also has no conflict. Tx3 reads a key2, but key2 was written into Tx2, and Tx3 and Tx2 do not belong to the same group, thus a conflict occurs. After the conflict, sub-executor 0 will apply the read / write sets of Tx1 and Tx2 to its own transaction ledger. Simultaneously, the read / write set management module informs the transaction scheduling module that Tx3 needs to be re-executed. Therefore, Tx3 will be executed based on the read / write sets of Tx1 and Tx2. After re-execution, sub-executor 0 finishes, resulting in a new read / write set for Tx3. This set will be changed to group 0, and the read / write set management module will re-evaluate its conflict. If the read / write set is found to be generated by group 0, it will be considered conflict-free. In this case, Tx3 is deemed conflict-free, and the execution result of the new read / write set can be applied to the temporary block ledger. The read / write set evaluation for the next transaction then continues. Tx4 writes a previously non-existent key4, which is conflict-free, but reads key3. Although there is a write-read conflict, they should not conflict since they belong to the same group. However, because Tx3 was re-executed, this conflict persists. Therefore, the read / write set result generated by Tx3 may also change. Since Tx4 reads key3 written in Tx3, Tx4 also needs to be re-executed, which can be considered a Tx4 conflict. The read / write set management module sends the read / write sets of Tx1, Tx2, and Tx3 to sub-executor 0. Sub-executor 0 can apply the execution results corresponding to the read / write sets of Tx1, Tx2, and Tx3 to the transaction ledger, and then re-execute Tx4 based on the transaction ledger to obtain a new read / write set of Tx4. The read / write set of Tx4 will be changed to group 0, and the read / write set management module will re-perform conflict judgment on the new read / write set of Tx4. Since the new read / write set of Tx4 is group 0, the read / write set management module will re-perform conflict judgment on the new read / write set of Tx4. The module determines that Tx4 is conflict-free at this point, and can apply the execution result of the new read-write set of Tx4 to the temporary block ledger, and then continue to perform conflict detection for the next transaction; Tx5 reads keyA and writes key5 without conflict, and the execution result of Tx5 can be applied to the temporary block ledger; Tx6 writes key6 without conflict, and reads keyA and the read set is consistent with Tx5. Although the reads are not conflicting, Tx6 reads key5, which is not in the same group as Tx5, so Tx6 is determined to be conflicted and needs to be re-executed according to the above re-execution process, and then the execution result of the read-write set of TX6 obtained from the re-execution is applied to the temporary block ledger.

[0135] After the read-write set management module has judged all read-write sets, it informs the transaction scheduling module of successful transactions. After receiving the execution result of each transaction, the transaction scheduling module can apply the execution result of each transaction to the block ledger of the current node of the blockchain, thereby completing the execution of each transaction in the block ledger. After that, it informs each module to exit, and the current block execution is complete.

[0136] During the above execution process, the read / write set management module can work in parallel with the transaction scheduling module while the transaction is being executed. The read / write set management module only needs to wait for the read / write set of the next transaction in the sequence to perform conflict detection, without waiting for the transaction scheduling module to finish executing all transactions, which improves transaction concurrency.

[0137] In this embodiment, it is equivalent to only needing to adapt the transaction execution module in the blockchain, without modifying other modules, to complete the parallel execution of transactions.

[0138] Furthermore, the method in this application has a constant additional overhead caused by conflicts arising from parallel transactions, which is at most twice the original overhead. That is, when all transactions conflict and are re-executed, the overhead is twice the original overhead. Based on a fixed and predictable additional overhead, the execution time of transactions can be estimated.

[0139] Reference Figure 6 The diagram illustrates a transaction execution apparatus according to an embodiment of this application, which may specifically include a transaction grouping module 61, a parallel execution module 62, a conflict detection module 63, and a completion determination module 64, wherein:

[0140] The transaction grouping module 61 is used to divide multiple transactions in a block into multiple transaction groups, and each transaction group includes at least one of the transactions.

[0141] Parallel execution module 62 is used to execute each of the transaction groups in parallel through multiple first sub-executors, generating a read-write set corresponding to each of the transactions, wherein each first sub-executor is used to execute one of the transaction groups;

[0142] Conflict detection module 63 is used to perform conflict detection on each of the transactions based on the read-write set;

[0143] The completion determination module 64 is used to determine that the block execution is complete when none of the transactions have execution conflicts.

[0144] In one possible implementation, the device further includes:

[0145] The re-execution module is used to re-execute the target transaction via a second sub-executor if there is a target transaction with execution conflict.

[0146] In one possible implementation, the read-write set includes the execution result of the transaction, and the parallel execution module 62 includes:

[0147] The execution result determination submodule is used to determine the execution results of transactions prior to the target transaction;

[0148] The sending submodule is used to send the execution result and the identification information of the target transaction to the second sub-executor, and the second sub-executor is used to execute the target transaction according to the execution result.

[0149] In one possible implementation, the conflict detection module 63 includes:

[0150] The first transaction determination submodule is used to determine the first transaction to be detected according to the transaction execution order;

[0151] The second transaction detection submodule is used to detect, based on the read / write set, whether there is a second transaction that performs the same target operation on the same field as the first transaction pair;

[0152] The transaction grouping determination submodule is used to determine the transaction group of the second transaction if the second transaction exists.

[0153] The judgment submodule is used to perform conflict detection on the first transaction based on the transaction grouping of the second transaction.

[0154] In one possible implementation, the above-mentioned judgment submodule includes:

[0155] The first determination unit is used to determine that the first transaction has an execution conflict if the second transaction and the first transaction are not in the same transaction group.

[0156] The second determination unit is configured to determine whether the second transaction is the target transaction that the second sub-executor has re-executed if the second transaction and the first transaction are in the same transaction group; if the second transaction is not the target transaction, determine that the first transaction does not have an execution conflict; and if the second transaction is the target transaction, determine that the first transaction has an execution conflict.

[0157] In one possible implementation, the completion determination module 64 includes:

[0158] A temporary storage submodule is used to store the execution result in a temporary block ledger if the transaction does not have an execution conflict;

[0159] The confirmation completion submodule is used to store the execution results of each transaction in the temporary block ledger into the block ledger if it is determined that each transaction has no execution conflict according to the execution order and the execution results of each transaction are stored in the temporary block ledger.

[0160] In one possible implementation, the above-mentioned device further includes:

[0161] The sub-executor generation module is used to generate multiple sub-executors based on the number of processor cores of the node devices in the blockchain. The sub-executors include multiple first sub-executors and at least one second sub-executor.

[0162] As the apparatus embodiments are basically similar to the method embodiments, they are described in a relatively simple manner. For relevant details, please refer to the description in the method embodiment section.

[0163] Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 7 As shown, the computer device 7 of this embodiment includes: at least one processor 70 ( Figure 7 (Only one is shown) a processor, a memory 71, and a computer program 72 stored in the memory 71 and executable on the at least one processor 70, which, when executing the computer program 72, implements the steps in any of the above method embodiments.

[0164] The computer device 7 can be a desktop computer, laptop, handheld computer, or cloud server, etc. This computer device may include, but is not limited to, a processor 70 and a memory 71. Those skilled in the art will understand that... Figure 7 The computer device 7 is merely an example and does not constitute a limitation on the computer device 7. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0165] The processor 70 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0166] In some embodiments, the memory 71 may be an internal storage unit of the computer device 7, such as a hard disk or memory of the computer device 7. In other embodiments, the memory 71 may be an external storage device of the computer device 7, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 7. Furthermore, the memory 71 may include both internal and external storage units of the computer device 7. The memory 71 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 71 can also be used to temporarily store data that has been output or will be output.

[0167] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.

[0168] This application provides a computer program product that, when run on a computer device, enables the computer device to perform the steps described in the above-described method embodiments.

[0169] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A transaction execution method, characterized in that, include: Based on the number of processor cores of the node devices in the blockchain, multiple sub-executors are generated, each sub-executor including multiple first sub-executors and at least one second sub-executor; The multiple transactions in the block are divided into multiple transaction groups, and each transaction group includes at least one of the transactions; Each transaction group is executed in parallel by multiple first sub-executors to generate a read-write set that corresponds one-to-one with each transaction, and each first sub-executor is used to execute one transaction group. Conflict detection is performed on each of the transactions based on the read / write set; If there is a target transaction with execution conflict, the target transaction is re-executed through the second sub-executor; If none of the transactions have execution conflicts, then the block is determined to have been executed successfully. The transactions have an execution order, and the conflict detection of each transaction based on the read / write set includes: According to the transaction execution order, determine the first transaction to be detected; Based on the read / write set of the first transaction, a target field is determined, wherein the target field is the field in the first transaction in which a read operation is performed; Based on the read / write set, detect whether there is a second transaction that performs a write operation on the target field, wherein the second transaction is a transaction whose execution order precedes the first transaction; If the second transaction exists, then determine the transaction grouping of the second transaction; Based on the transaction grouping of the second transaction, conflict detection is performed on the first transaction.

2. The method as described in claim 1, characterized in that, The read / write set includes the execution result of the transaction, and the re-execution of the target transaction through the second sub-executor includes: Determine the execution results of transactions preceding the target transaction; The execution result and the identification information of the target transaction are sent to the second sub-executor, which is used to execute the target transaction according to the execution result.

3. The method as described in claim 1, characterized in that, The step of performing conflict detection on the first transaction based on the transaction grouping of the second transaction includes: If the second transaction and the first transaction are not in the same transaction group, then the first transaction is determined to have an execution conflict. If the second transaction and the first transaction are in the same transaction group, then it is determined whether the second transaction is the target transaction that the second sub-executor has re-executed; if the second transaction is not the target transaction, then it is determined that the first transaction does not have an execution conflict; if the second transaction is the target transaction, then it is determined that the first transaction has an execution conflict.

4. The method according to any one of claims 1-3, characterized in that, If none of the transactions have execution conflicts, then determining that the block execution is complete includes: If the transaction does not have an execution conflict, the execution result of the transaction is stored in a temporary block ledger; If all the transactions are determined to have no execution conflict according to the execution order, and the execution results of all the transactions are stored in the temporary block ledger, then the execution results of all the transactions in the temporary block ledger are stored in the block ledger.

5. A transaction execution apparatus, characterized in that, The transaction execution device includes a transaction static analysis module, a transaction scheduling module, and a read / write set management module, wherein: The transaction static analysis module is used to analyze the transactions in the block and generate at least one transaction group, wherein the transaction group includes at least one of the transactions. The transaction scheduling module is used to execute each of the transaction groups in parallel and generate read / write sets for each of the transactions; The read-write set management module is used to perform conflict detection on each of the transactions according to the read-write set in order to determine whether the block has been executed. The device is also used to perform: Based on the number of processor cores of the node devices in the blockchain, multiple sub-executors are generated, each sub-executor including multiple first sub-executors and at least one second sub-executor; If there is a target transaction with execution conflict, the target transaction is re-executed through the second sub-executor; The transactions have an execution order, and the conflict detection of each transaction based on the read / write set includes: According to the transaction execution order, determine the first transaction to be detected; Based on the read / write set of the first transaction, a target field is determined, wherein the target field is the field in the first transaction in which a read operation is performed; Based on the read / write set, detect whether there is a second transaction that performs a write operation on the target field, wherein the second transaction is a transaction whose execution order precedes the first transaction; If the second transaction exists, then determine the transaction grouping of the second transaction; Based on the transaction grouping of the second transaction, conflict detection is performed on the first transaction.

6. The apparatus as claimed in claim 5, characterized in that, The transaction scheduling module includes a list of sub-executors, which includes at least one first sub-executor. The first sub-executor includes a transaction ledger, wherein: The sub-executor list is used to execute each of the transaction groups in parallel through each of the first sub-executors; The first sub-executor is configured to execute one of the transaction groups based on the transaction ledger.

7. The apparatus as described in claim 5 or 6, characterized in that, The read-write set management module is further configured to determine the target transaction with execution conflict based on the read-write set, and send the target transaction to the transaction scheduling module; The transaction scheduling module is also used to re-execute the target transaction that has an execution conflict.

8. The apparatus as claimed in claim 7, characterized in that, The device also includes a temporary block ledger, and the read / write set management module is further used for: If it is confirmed that the transaction does not have an execution conflict, the execution result of the transaction will be applied to the temporary block ledger. If the execution result of each transaction is applied to the temporary block ledger, then the data in the temporary block ledger is stored in the blockchain node's block ledger.

9. The apparatus as claimed in claim 8, characterized in that, The transaction scheduling module further includes a second sub-executor, which is used to execute the target transaction that has execution conflicts.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1-4.

11. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-4.

Images