CN115760405A

CN115760405A - Transaction execution method, device, computer equipment and medium

Info

Publication number: CN115760405A
Application number: CN202211465857.1A
Authority: CN
Inventors: 邱炜伟; 张珂杰; 陶烨琪; 黄方蕾; 尚璇
Original assignee: Hangzhou Qulian Technology Co Ltd
Current assignee: Hangzhou Qulian Technology Co Ltd
Priority date: 2022-11-22
Filing date: 2022-11-22
Publication date: 2023-03-07

Abstract

The embodiment of the application is applicable to the technical field of block chains, and provides a transaction execution method, a device, computer equipment and a medium, wherein the method comprises the following steps: dividing a plurality of transactions in a block into a plurality of transaction groups, wherein each transaction group comprises at least one transaction; executing each transaction group in parallel through a plurality of first sub-executors to generate a read-write set corresponding to each transaction one by one, wherein each first sub-executor is used for executing one transaction group; performing conflict detection on each transaction according to the read-write set; and when each transaction does not have an execution conflict, determining that the block execution is finished. By the method, the transaction in the block can be executed in parallel, and the resource utilization rate is improved, so that the performance of the block chain is improved.

Description

Transaction execution method, device, computer equipment and medium

Technical Field

The present application relates to a method, an apparatus, a computer device and a medium for executing a transaction, and belongs to the technical field of block chaining.

Background

The block chain is used as a distributed account book, one main node can select a batch of transactions from a transaction pool to package and generate blocks, and then the main node synchronizes the blocks to other nodes. Each node in the block chain executes the transaction in the block for verification, and because the transaction execution result of each node needs to be ensured to be consistent, and the influence of random factors on the execution result needs to be avoided, the transaction can be executed sequentially according to the sequence of the transaction list when the blocks are packed when the transaction is executed by each block link.

However, the multi-core characteristic of a Processor (CPU) cannot be utilized when transactions are executed sequentially, which results in low resource utilization and low overall performance of a block chain.

Disclosure of Invention

In view of this, embodiments of the present application provide a transaction execution method, an apparatus, a computer device, and a medium, which are used to execute transactions in parallel, and improve resource utilization, thereby improving block chain performance.

A first aspect of an embodiment of the present application provides a transaction execution method, including:

dividing a plurality of transactions in a block into a plurality of transaction groups, wherein each transaction group comprises at least one transaction;

executing each transaction group in parallel through a plurality of first sub-executors to generate a read-write set corresponding to each transaction one by one, wherein each first sub-executor is used for executing one transaction group;

performing conflict detection on each transaction according to the read-write set;

and when each transaction does not have an execution conflict, determining that the block execution is finished.

A second aspect of the embodiments of the present application provides a transaction execution apparatus, which includes a transaction static analysis module, a transaction scheduling module, and a read-write management module, wherein:

the transaction static analysis module is used for analyzing the transactions in the block and generating at least one transaction group, wherein the transaction group comprises at least one transaction;

the transaction scheduling module is used for executing all the transaction groups in parallel and generating a read-write set of all the transactions;

and the read-write set management module is used for performing conflict detection on each transaction according to the read-write set so as to determine whether the block is executed completely.

A third aspect of an embodiment of the present application provides another transaction execution apparatus, including:

the transaction grouping module is used for dividing a plurality of transactions in the block into a plurality of transaction groups, and each transaction group comprises at least one transaction;

the parallel execution module is used for executing each transaction group in parallel through a plurality of first sub-executors to generate a read-write set corresponding to each transaction one by one, and each first sub-executor is used for executing one transaction group;

the conflict detection module is used for carrying out conflict detection on each transaction according to the read-write set;

and the completion determining module is used for determining that the block is executed completely when each transaction has no execution conflict.

A fourth aspect of embodiments of the present application provides a computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the method according to the first aspect when executing the computer program.

A fifth aspect of embodiments of the present application provides a computer-readable storage medium, in which a computer program is stored, which, when executed by a processor, implements the method according to the first aspect.

A sixth aspect of embodiments of the present application provides a computer program product, which, when run on a computer device, causes the computer device to perform the method of the first aspect.

Compared with the prior art, the embodiment of the application has the following advantages:

in the embodiment of the application, when a new block is executed by a block chain node, transactions in the block can be divided into a plurality of transaction groups, and the transaction groups can include at least one transaction; because the states of the transaction groups are irrelevant, each transaction group can be executed in parallel through a plurality of first sub-executors, so that the multi-core characteristic of the processor can be fully utilized; after the execution of each transaction is finished, a corresponding read-write set can be generated, and the transaction can be subjected to conflict detection based on the read-write sets, so that whether an execution error exists in the transaction execution process is determined; block execution may be determined to be complete when none of the transactions have an execution conflict. In the embodiment, the transactions in the block are divided into a plurality of state-independent transaction groups, and then the transaction groups are executed in parallel, so that the utilization of computing resources is improved, and the performance of a block chain is improved; by performing conflict detection on the transactions, the execution result of the transactions can be confirmed after the transactions are executed in parallel, so that the accuracy of the block execution result is ensured.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings used in the embodiments or the description of the prior art will be briefly described below.

FIG. 1 is a schematic flow chart diagram illustrating steps of a transaction execution method according to an embodiment of the present application;

FIG. 2 is a schematic diagram of a sub-actuator according to an embodiment of the present disclosure;

FIG. 3 is a flow chart illustrating steps of another transaction execution method provided by embodiments of the present application;

FIG. 4 is a schematic diagram of a transaction execution device according to an embodiment of the present application;

FIG. 5 is a schematic flow chart diagram illustrating another transaction execution method provided by an embodiment of the present application;

FIG. 6 is a schematic diagram of another transaction execution device provided in an embodiment of the present application;

fig. 7 is a schematic diagram of a computer device according to an embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular system structures, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. However, it will be apparent to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

To improve the performance of the blockchain, transactions may be performed in a parallel manner to improve the throughput of the blockchain.

The method for realizing the parallelism of the Changan chain (chainmaker) to the transaction comprises the following steps: after a batch of transactions are selected from a transaction pool by a common recognition master node, the batch of transactions are executed randomly, then a read-write set generated by the execution result of the transactions is recorded and temporarily applied in the order of random execution, if the subsequent transactions conflict with the preceding transactions, the subsequent transactions are re-executed based on an account book applied with the preceding transactions, finally a Direct Acyclic Graph (DAG) generated by the dependence relationship of the transactions is packed into a block structure, and the DAG determines the concurrency and the execution order of the transactions. When other nodes receive the blocks, the blocks are executed in parallel according to the sequence in the DAG. The disadvantage of this solution is that the sequence of block packed transactions is determined according to whether the transactions have a conflict relationship, that is, the transactions are not sorted according to the sending sequence of the transactions or the transaction commission fees, and the consensus logic and the packed data need to be modified.

The fisco alliance chain determines the parallelism of a block in a manner of splitting a contract account book address, namely, one contract address has only one transaction to operate the contract address at the same time, the subsequent transaction of the contract address needs to wait for the completion of the execution of the current transaction, the execution can be performed after the lock of the contract address is released, and when a contract crossing condition exists, a deadlock condition may occur. Therefore, the requirement of the scheme of the fisco on the condition of triggering transaction parallel is high, and when the transaction operations are all the same contract address, the transaction parallel cannot be carried out.

In summary, in the prior art, when the block chain performs transactions concurrently, or other modules in the block chain need to be modified at the same time, for example, a consensus structure needs to be changed; or the transaction parallelism is not high. Based on this, the embodiment of the application provides a transaction parallel method, which can realize the parallel of transactions and improve the concurrency of transactions under the condition that only a transaction execution module is changed.

The technical solution of the present application is explained below by specific examples.

Referring to fig. 1, a schematic flow chart illustrating steps of a transaction execution method provided in an embodiment of the present application is shown, which may specifically include the following steps:

s101, dividing a plurality of transactions in a block into a plurality of transaction groups, wherein each transaction group comprises at least one transaction.

The execution subject of this embodiment may be a node device of a block chain of the block chain, and the node device may be a computer device such as a tablet computer, a wearable device, an in-vehicle device, a notebook computer, a super mobile personal computer, and a server. At least one blockchain node may be deployed on the node device.

If the blockchain node is the master node of the blockchain, the blockchain node can acquire a plurality of transactions from the transaction pool, then pack the transactions into blocks, and then synchronize the blocks to other nodes in the blockchain. If the blockchain node is not the master node, the blockchain node may receive the block from the master node.

The blockchain node may perform the blocks in order. After a block is executed, the block book may be updated based on the execution result of the block. The execution result of the block includes the execution result of each transaction in the block, and the block ledger may include status data and ledger data of a block in the block chain node for which execution is currently completed. When a new block is to be executed, it indicates that the previous block has been executed, and the block ledger may include status data after the previous block is executed.

After the block link node receives the block, it can acquire multiple transactions in the block, then analyze the multiple transactions, and divide the block chain into multiple different transaction groups. The transaction groups are independent of each other, so that the transaction groups can be in parallel. At least one transaction may be included in each transaction group.

In one possible implementation, transactions may be grouped based on smart contracts invoked by the transactions. The transaction can complete corresponding operations by calling the intelligent contracts, the intelligent contracts can include operations on fields, and each intelligent contract in the blockchain nodes can be statically analyzed, so that the fields required to be operated by each intelligent contract and the type of the operations required to be performed on the fields can be determined. The intelligent contracts with the association relationship can be determined based on the fields that each intelligent contract needs to operate on and the operations that each intelligent contract needs to perform on the fields. Based on the intelligent contracts called by the various transaction exchanges and the intelligent contracts with the association relations, the transactions with the dependency relations can be determined, and the transactions with the dependency relations are regarded as one transaction group, so that the transactions in the block are divided into a plurality of transaction groups. Each transaction group may include one or more transactions, and when a plurality of transactions are included in the transaction group, the transactions in the transaction group may have a corresponding arrangement order, and the transactions in the transaction group are arranged in a transaction execution order.

And S102, executing each transaction group in parallel through a plurality of first sub-executors to generate a read-write set corresponding to each transaction one by one, wherein each first sub-executor is used for executing one transaction group.

Based on the core number of the processor of the node device, a preset number of sub-executors may be generated. Preferably, the number of the sub-executors may be 2 times of the number of the processor cores of the node devices of the block chain, so as to ensure that the characteristics of the multi-core processor can be fully utilized in the transaction parallel process.

Fig. 2 is a schematic diagram of a sub-actuator according to an embodiment of the present disclosure. As shown in fig. 2, the sub-executors may include a virtual machine execution engine and a transaction ledger. Wherein the Virtual Machine execution engine may include an HVM Virtual Machine and an etherhouse Virtual Machine EVM (EVM). The transaction ledger may include a ledger database and a status database, and the initial transaction ledger may be generated based on a block ledger. The initial account book data may be account book data of a previous block in the block account book, and the initial state database may be state data after execution of the previous block is completed.

From the plurality of sub-executors, a plurality of first sub-executors may be determined, which may be used to execute the transaction packet. When a plurality of transactions are included in the transaction packet, the first sub-executor may serially execute the plurality of transactions in the transaction packet in a transaction execution order.

Each first sub-executor may be used to execute one of the transaction groups at the same time based on the transaction ledger and the virtual machine execution engine. The block link point comprises a plurality of first sub-actuators, and each first sub-actuator can execute one transaction group at the same time; that is, multiple sub-executors may execute corresponding multiple transaction packets in parallel. The transaction grouping is executed by the plurality of sub-executors in parallel, thereby improving the transaction execution efficiency.

In a possible implementation manner, the number of transaction packets may be greater than the number of the first sub-executors, and after determining the transaction packets, one transaction packet may be allocated to each first sub-executor, and the remaining unallocated transaction packets may be temporarily stored. After a first sub-executor completes executing a transaction packet, the first sub-executor may be re-initialized, so as to continue to use the first sub-executor to execute transaction packets that have not been allocated before. After the first sub-executor executes the transaction grouping, the execution result of each transaction in the transaction grouping and the operation performed on the field can be obtained. Each transaction may have a read-write set that may include the results of the execution of the transaction and the operations performed on the fields.

S103, performing conflict detection on each transaction according to the read-write set.

The transaction parallel execution process, compared to the transaction serial execution process, may include the following factors that cause the transaction execution result to be incorrect: a write-read conflict. For example, transaction 1 writes to data A, transaction 2 reads from data A, and transaction 2 is executed after transaction 1 is completed. Then transaction 1 and transaction 2 are executed in parallel, the value of the a data obtained for transaction 2 is incorrect and the result of the execution of transaction 2 is incorrect.

Although the transaction with the write-read conflict can be divided into one transaction group as much as possible to avoid the error of the transaction execution result, in order to further ensure the correct transaction result, whether the write-read conflict exists in the transaction parallel execution process can be detected after the transaction execution is completed. The read-write set may include fields involved in the transaction and operations corresponding to the fields. When conflict detection is performed, whether a write-read conflict exists between a transaction and other transactions before the transaction can be determined according to the execution sequence of the transaction and the read-write set of the transaction.

Specifically, after the execution of the first transaction is completed, it may be determined that the first transaction does not have an execution conflict; acquiring a read-write set of the second transaction, and determining whether a conflict exists in the second transaction according to the read-write set of the second transaction and the read-write set of the first transaction; if no conflict exists, the read-write set of the third transaction can be continuously acquired, and whether the conflict exists in the third transaction can be determined based on the read-write set of the third transaction, the second transaction and the first transaction. When the second transaction has conflict, the second sub-executor transaction can be used for re-executing the second transaction, and then the second transaction can be determined to have no execution conflict based on the read-write set obtained by re-executing; the determination may then continue for a third transaction. And so on until all transactions are detected completely. The conflict detection process for transactions is performed sequentially, and in the event that a previous transaction does not determine that there is no execution conflict, conflict detection for the next transaction is generally not performed.

It should be noted that this step may be executed in parallel with the previous step. Namely, after the execution result of the first transaction is obtained, the conflict detection can be carried out on the first transaction; after the first transaction conflict detection is completed, if the second transaction is also completed, the second transaction can be subjected to conflict detection; and by analogy, performing conflict detection on the transactions according to the execution sequence of the transactions. When performing conflict detection, only the read-write set of the currently ordered transactions is needed, and all transactions are not necessarily required to be completely executed. For example, the transaction group is: (transaction 1) and (transaction 2, transaction 3), wherein one of the first sub-executors executes transaction 1 and the other first sub-executor executes transaction 2, transaction 3; after transaction 1 execution is complete, another first sub-executor may not have executed the complete transaction packet yet, but as long as the execution result of transaction 1 is obtained, conflict detection for transaction 1 may be performed. Based on the method, the execution of the transaction and the conflict detection can realize a certain degree of parallelism, so that the execution efficiency of the transaction can be improved, and the execution time of the transaction can be shortened.

Since the collision detection and the transaction execution can be executed in parallel, one sub-executor in the block chain may be used as the second sub-executor, and the other sub-executors may be used as the first sub-executor, that is, the block chain node includes one second sub-executor and a plurality of first sub-executors. The second sub-executor may not be used for executing the transaction, but only for re-executing the transaction, thereby ensuring that no idle sub-executor needs to be waited for when the transaction is re-executed, so that the conflict detection of the transaction can be parallel to the execution of the transaction, and the concurrency of the transaction is improved.

And S104, if the transactions do not have execution conflict, determining that the block execution is finished.

When each transaction does not have an execution conflict, it may be determined that the block execution is complete, and the execution result of each transaction is applied in the block ledger, and then the next block may be executed continuously using the steps in this embodiment. For example, the block ledger may include a plurality of fields, each field may have a corresponding field value, and the read-write set of the transaction also includes field values of the plurality of fields after the transaction is executed, and according to the fields and the field values in the read-write set, the field values may be updated or new fields may be created in the block ledger, which is equivalent to determining the execution result of each transaction in the block ledger.

Specifically, when it is determined that a transaction does not have an execution conflict, it is equivalent to determining that the execution result of the transaction is correct, and at this time, the execution result of the transaction may be temporarily saved; and then continuing to perform conflict detection on the next transaction until the execution result of the last transaction is determined to be correct and temporarily storing the execution result of the last transaction. Then, the execution results of the respective transactions temporarily stored may be all stored in the block book, and the state of the block book may be updated.

In this embodiment, a plurality of transaction groups can be executed in parallel based on a plurality of first sub-executors, and transaction execution and transaction conflict detection can be implemented in parallel to a certain extent. In addition, after the transaction execution is completed, whether an error occurs in the transaction execution process can be determined through conflict detection, so that the transaction execution result is ensured to be accurate. The method of the embodiment ensures the correct transaction execution result while executing the transaction in parallel, fully utilizes the characteristic of multiple cores of the processor, and improves the performance of the block chain.

Referring to fig. 3, a schematic flow chart illustrating steps of another transaction execution method provided in the embodiment of the present application is shown, which may specifically include the following steps:

s301, dividing a plurality of transactions in the block into a plurality of transaction groups, wherein each transaction group comprises at least one transaction.

S302, executing each transaction group in parallel through a plurality of first sub-executors to generate a read-write set corresponding to each transaction one by one, wherein each first sub-executor is used for executing one transaction group.

S301 to S302 in this embodiment are similar to S101 to S102 in the previous embodiment, and they may be referred to each other, which is not described herein again.

S303, determining the first transaction to be detected according to the transaction execution sequence.

The transactions may have a corresponding transaction order in the order in which they were packaged. When the transaction conflict detection is performed, the detection can be performed sequentially according to the execution sequence of the transactions. The first transaction to be detected is a transaction with the highest execution sequence in the current transactions which are not determined to have no execution conflict.

After the first sub-executor executes the first transaction, the first transaction can be used as the first transaction for conflict detection. Because the first transaction is executed first, there is no preceding transaction in this block that affects the transaction, so the current execution result of the first transaction is not affected by other transactions in this block, and there is no execution conflict.

After the first transaction conflict is detected, it may be determined whether the first transaction has an execution conflict; if the first transaction does not have an execution conflict, taking the next transaction of the first transaction as a new first transaction; if the first transaction has an execution conflict, the first transaction can be re-executed, a read-write set after the first transaction is re-executed is obtained, then conflict detection is continuously performed on the first transaction based on the read-write set, no execution conflict exists in the first transaction based on the read-write set after re-execution, and at this time, the next transaction of the first transaction can be used as a new first transaction.

In this embodiment, the first, second, next, and last are described based on the transaction execution order.

S304, determining a target field according to the read-write set of the first transaction, wherein the target field is a field for executing read operation in the first transaction.

Operations on fields may include read operations that require the retrieval of a value for a field and write operations that change the value of a field. In the transaction execution process, the value of the field obtained by the read operation is generally used for subsequent operations, so that if the value of the field obtained by the read operation is incorrect, the subsequent transaction execution result is also wrong; changing the value of a field using a write operation does not require that the value of the field be correct, and the transaction proceeds back to a subsequent operation based on the field value corresponding to the write operation, because the write operation does not cause a subsequent execution result error. For example, to add one to a value of a field a, a read operation needs to be performed on the field a first, and then a write operation needs to be performed, and if the read value of the field is incorrect, the addition of one to the value of the field a will inevitably result in an error, that is, the value of the field a corresponding to the subsequent write operation is incorrect. If a field a is assigned a value, and a is equal to 1, then a write operation needs to be performed on the field a, and after the write operation, if a is equal to 1, then subsequent operations are performed based on the field a without errors. Therefore, in determining whether there is an execution conflict, it is necessary to determine whether the field value read by the read operation is correct. At this point, the field in the first transaction in which the read operation is to occur may be determined first.

From the read-write set of the first transaction, a target field for which a read operation was performed in the first transaction may be determined. If the target field for performing the read operation does not exist in the first transaction, it may be determined that there is no execution conflict for the first transaction.

S305, detecting whether a second transaction for executing the write operation on the target field exists according to the read-write set, wherein the second transaction is a transaction of which the transaction execution sequence is before the first transaction.

A write-read conflict may cause a parallel result error, that is, if a transaction before the first transaction performs a write operation on a field and the first transaction performs a read operation on the field, the result of executing the first transaction in the parallel process of the first transaction and the transaction may be an error. In this case, a first read-write set for the first transaction and a second read-write set for each transaction whose execution order of the transactions precedes the first transaction may be determined; then, whether each field of the first transaction executing the read operation in the read-write set of the first transaction executes the write operation in each second read-write set is determined. If a field is written by a certain second read-write set and read by the first read-write set, the transaction corresponding to the second read-write set can be determined to be the second transaction.

If there is no transaction prior to the first transaction that performed a write operation to the target field, there is no second transaction that has an execution conflict with the first transaction. If the second transaction which has parallel conflict with the first transaction does not exist, the first transaction is determined not to have execution conflict, the execution result of the first transaction in the read-write set can be confirmed to be correct, then a new first transaction is determined, and conflict detection is continued based on the new first transaction until conflict detection of all transactions is completed.

S306, if the second transaction exists, determining the transaction group of the second transaction.

S307, according to the transaction group of the second transaction, performing conflict detection on the first transaction.

And if the second transaction and the first transaction are not in the same transaction group, which indicates that the two transactions are executed in parallel, determining that the first transaction has an execution conflict.

If the second transaction and the first transaction are in the same transaction group, which indicates that the two transactions are executed serially according to the transaction execution sequence, the two transactions executed serially do not conflict with each other, but if the second transaction is executed again before, the subsequent transactions in the series also need to be executed again. Thus, it may be determined whether the second transaction is a target transaction that has been re-executed by the second sub-executor; if the second transaction is not the target transaction, determining that the first transaction does not have an execution conflict; if the second transaction is a target transaction, it is determined that the first transaction has an execution conflict.

And S308, if the target transaction with the execution conflict exists, re-executing the target transaction through the second sub-executor.

If there is a target transaction with execution conflict, the execution results of the transactions whose execution order is determined to be before the target transaction may be sent to the second sub-executor, and then the execution results and the identification information of the target transaction may be sent to the second sub-executor. The second sub-executor may determine a target transaction that needs to be re-executed according to the identification information, and then re-execute the target transaction according to an execution result of each transaction before the target transaction, to obtain a new read-write set.

Specifically, the read-write sets of the transactions include the execution results of the transactions, and therefore, the read-write sets of all transactions whose transaction execution sequence is before the target transaction may be sent to the second sub-executor, and the second sub-executor may apply the read-write sets to the transaction ledger and re-execute the target transaction based on the transaction ledger. Because the transaction ledger after the initialization of the second sub-executor is generated based on the previous block ledger, the previous block ledger is already correct, and all transactions before the target transaction have completed the conflict detection, which is equivalent to that the execution result is confirmed to be correct, when the target transaction is executed, the data in the transaction ledger is correct, so that it can be ensured that the correct execution result can be obtained after the target transaction is executed, that is, the new read-write set obtained by executing the target transaction is correct.

Based on the new read-write set, collision detection may resume. For a new read-write set, a re-execution identifier can be added; when the conflict detection is carried out based on the read-write set, if the read-write set has the re-execution identifier, the corresponding transaction can be directly determined not to have the execution conflict.

It should be noted that, when performing conflict detection on the first transaction based on the read-write sets of each transaction before the first transaction and the read-write set of the first transaction, if there is a transaction that has been re-executed before the first transaction, the read-write set corresponding to the re-executed transaction should be the read-write set for the second sub-executor to execute the transaction.

S309, if there is no execution conflict in each transaction, determining that the block is executed completely.

When it is determined that the last transaction does not have an execution conflict, it may be determined that the execution results of the transactions are all correct, and at this time, the block execution is completed, and the execution results of the transactions may all be stored in the block ledger.

Specifically, if the transaction does not have an execution conflict, the execution result may be stored in the temporary block book; then continuing to detect whether the next transaction of the transaction has an execution conflict; when the execution result of the transaction with the last execution sequence is applied to the temporary block ledger, it can be shown that the execution result of each transaction is correct, the execution result of each transaction is already stored in the temporary block ledger, and it can be determined that the block execution is completed; at this time, the execution results of all transactions in the temporary ledger can be stored into the block ledger.

After that, the data in the temporary block account book may be cleared, and the execution of the next block may be continued.

In this embodiment, each transaction may be executed in parallel by the first sub-executor, and conflict detection may be performed on the transactions in sequence; when a transaction conflict is determined to exist based on conflict detection, the read-write sets before the transaction are merged and applied to the second sub-actuator, the transaction is re-executed in the second sub-actuator, and then the conflict is solved, so that the transaction result is guaranteed to be correct, the confirmation of the transaction execution result is completed, the accuracy of the block execution result is guaranteed, and the transaction can be performed in parallel in the block execution process, so that the same block can be executed by all block chain link points to obtain the same execution result. It should be noted that, the sequence numbers of the steps in the foregoing embodiments do not mean the execution sequence, and the execution sequence of each process should be determined by the function and the inherent logic of the process, and should not constitute any limitation to the implementation process of the embodiments of the present application.

The embodiment of the present application further provides a transaction executing apparatus, which may include a transaction static analysis module, a transaction scheduling module, and a read-write management module, wherein:

the transaction static analysis module is configured to analyze transactions in a block to generate at least one transaction packet, where the transaction packet includes at least one transaction;

the transaction scheduling module is used for executing each transaction group in parallel and generating a read-write set of each transaction;

the read-write set management module is configured to perform conflict detection on each transaction according to the read-write set to determine whether the block is executed completely.

The transaction scheduling module includes a sub-executor list, where the sub-executor list includes at least one first sub-executor, and the first sub-executor includes a transaction ledger, where:

the sub-executor list is used for executing the transaction groups in parallel through the first sub-executors;

the first sub-executor is configured to execute the transaction group based on the transaction ledger.

The read-write set management module is further configured to determine a target transaction with an execution conflict according to the read-write set, and send the target transaction to the transaction scheduling module;

the transaction scheduling module is further configured to re-execute the target transaction having the execution conflict.

The device further comprises a temporary block account book, and the read-write management module is further used for:

if the transaction is confirmed not to have the execution conflict, applying the execution result of the transaction to the temporary block account book;

and if the execution result of each transaction is applied to the temporary block book, storing the data in the temporary block book to a block book of a block chain node.

The transaction scheduling module further includes a second sub-executor configured to execute the target transaction having the execution conflict.

The transaction grouping module is used for dividing a plurality of transactions in a block into a plurality of transaction groups, and each transaction group comprises at least one transaction;

a parallel execution module, configured to execute each transaction group in parallel through a plurality of first sub-executors, and generate a read-write set corresponding to each transaction one to one, where each first sub-executor is configured to execute one transaction group;

a conflict detection module for performing conflict detection on each transaction according to the read-write set;

and the completion determining module is used for determining that the block is completed when each transaction does not have execution conflict.

For the specific implementation process of each module of the transaction apparatus in this embodiment, reference may be made to other method embodiments, which are not described herein again.

Fig. 4 is a schematic diagram of a transaction execution apparatus according to an embodiment of the present application, and as shown in fig. 4, the execution apparatus may include a sub-executor No. 0, a sub-executor list, a block ledger, a read-write set management module, and a static transaction analysis module, where the transaction execution apparatus shown in fig. 4 may be an example of the transaction execution apparatus provided in the previous embodiment, the sub-executor No. 0, the sub-executor list, and the block ledger may constitute the transaction scheduling module, the sub-executor No. 0 may be the second sub-executor, the sub-executor list may include a plurality of the first sub-executors, and the block ledger may be the temporary block ledger.

FIG. 5 is a flowchart illustrating the execution apparatus in FIG. 4 executing blocks. As shown in fig. 5, the transaction static analysis module, the transaction scheduling module, and the read-write header management module are executed in parallel, and operate in a pipeline manner. Firstly, the block transaction is analyzed by the transaction static analysis module to generate a plurality of transaction lists which are irrelevant to the state, and the transaction list in fig. 5 is the transaction group. The transaction list may be placed in a transaction queue and subsequently concurrently retrieved from the transaction queue for incorporation into the transaction scheduling module.

The transaction scheduling module pre-creates a thread pool and sub-executors, which may be in a sub-executor queue. When a transaction list comes in, the thread pool can take out one sub-executor from the idle sub-executor queue for transaction execution. Before the sub-executor starts to execute the transaction in the transaction list, the initialization of a transaction book is carried out: a transaction ledger is created based on the block ledger. The execution of the transaction in the sub-actuators is based on the transaction ledger, the transaction ledger can generate a corresponding read-write set for each transaction, the transaction scheduling module can send the read-write set to the read-write set management module after the read-write set is generated, and meanwhile, the sub-actuators can be returned to the idle sub-actuator list after the execution of each transaction in the transaction list.

After the read-write set is generated, the read-write set management module can also concurrently and sequentially perform conflict judgment and application of the read-write set according to the transaction packing sequence. And the read-write set management module sequentially judges the conflict of each transaction according to the read-write sets of the transactions according to the sequence. If the read-write set management module judges that the current transaction is conflict-free according to the read-write set, the execution result of the current transaction is sent to the transaction scheduling module to confirm that the transaction is executed; if the read-write set judges that the current transaction has conflict, the read-write set of all transactions before the current transaction is applied to a transaction account book in the number 0 sub-actuator, and conflict information of the transaction is sent to the number 0 sub-actuator; the number 0 sub-executor can acquire the transaction needing to be executed again from the transaction scheduling module according to the conflict information of the read-write set management module, and then execute the transaction again based on the updated transaction book. Since the execution result of each transaction before the current transaction is confirmed to be correct, the read-write set of all transactions before the current transaction is applied to the transaction ledger in the number 0 sub-executor, the obtained new ledger is correct, and the execution result of the current transaction is correct after the current transaction is re-executed based on the ledger. The re-executed transaction is re-executed based on the results of all the previous transactions, so that no conflict is generated, a new read-write set is obtained after the re-execution of the transaction is finished, 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 continuously and sequentially judge whether the transaction conflicts exist according to the read-write sets of the subsequent transactions.

The read-write header management module in fig. 5 includes a block ledger, which may be a temporary block ledger. After each transaction is confirmed to be conflict-free, the execution result of the transaction in the corresponding read-write set can be applied to the temporary block ledger. When all the transactions are executed, the transaction scheduling module sends an end signal to inform the modules that the execution of the blocks is finished, so that the transaction parallelism in one block is finished.

To better illustrate the present application, specific examples are set forth below.

First, a scenario in which no transaction conflict exists after the transactions are executed in parallel is described as follows:

assume that there are 6 transactions tx1, tx2, tx3, tx4, tx5, tx6 in the current tile, and the grouping is as follows:

Group1：tx1，tx3，tx4

Group2：tx2，tx5

Group3：tx6

the transaction groups are taken out in parallel, and a sub-executor is allocated to each transaction group, and the read-write set generated after each transaction group is executed can be as shown in table 1:

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

TABLE 1

It should be noted that, this embodiment represents the read-write set as follows: r < k, g > represents a read set, k represents a read key value, and g represents a packet number where the key is read; w < k, v, g > represents the write set, k represents the modified key value, v represents the value corresponding to the key, and g represents the packet number where the modified key is located.

After the transaction read-write set is generated, the read-write set management module sequentially judges according to the transaction sequence, firstly Tx1 is the first transaction without conflict, and the execution result of Tx1 can be applied to the temporary block ledger; then Tx2 includes a key2 that is conflict-free from the previous and therefore conflict-free, the Tx2 execution result may be applied to the temporary block ledger; tx3 reads one key1 and key1 is written in Tx1, and a write-read conflict should be generated, but Tx1 and Tx3 are the same transaction group, so the execution is performed based on the same transaction book, and therefore the conflict does not exist, and the execution result of Tx3 can be applied to the temporary block book; tx4 also writes a key4 which does not exist before, there is no conflict, writes a key2 consistent with Tx2, although not belonging to the same group, the write operation also does not belong to a conflict, therefore, tx4 also has no conflict, and the execution result of Tx4 can be applied to the temporary block book; tx5 read key a and write key5 do not conflict with the previous, and the execution result of Tx5 may be applied to the temporary block ledger; tx6 write key6 does not conflict and read keyA coincides with the read set of Tx5, but read operation does not conflict, so Tx6 also does not conflict and the result of Tx6 execution can be applied to the temporary block ledger. Therefore, each transaction has no conflict and the transaction result is correct.

After the read-write set management module judges that all read-write sets are finished, the read-write set management module informs the transaction scheduling module of successful transactions, and after the transaction scheduling module receives the execution result of each transaction, the execution result of each transaction can be applied to the block ledger of the current node of the block chain, so that the execution of each transaction is finished in the block ledger, and then the read-write set management module informs each module of quitting, and the execution of the current block is finished.

In the following, a scenario in which a transaction conflict exists after the transactions are executed in parallel is described as follows:

assume that there are 6 transactions tx1, tx2, tx3, tx4, tx5, tx6 in the current tile, which are grouped as follows:

Group1：tx1，tx3，tx4

Group2：tx2，tx5

Group3：tx6

the transaction groups are taken out in parallel and distributed to the sub-executors, and the read-write sets generated after each transaction group is executed are shown in table 2:

TABLE 2

After the transaction read-write set is generated, the read-write set management module sequentially judges according to the transaction sequence, firstly Tx1 is the first transaction without conflict, and the execution result of Tx1 can be applied to the temporary block book; tx2 then writes a key2 that is not in conflict with the previous, and therefore also not in conflict; tx3 reads a key2, the key2 is written in Tx2, and Tx3 and Tx2 do not belong to the same group, so a conflict occurs, after the conflict occurs, the sub-executor No. 0 will apply the read-write sets of Tx1 and Tx2 to its own transaction book, and at the same time, the read-write set management module informs the transaction scheduling module that Tx3 needs to be re-executed, so Tx3 will re-executed on the basis of the read-write sets of Tx1 and Tx2, after the re-execution of the sub-executor No. 0 is finished, a new read-write set of Tx3 is obtained, the read-write set of Tx3 will be changed to group 0, and the read-write set management module performs conflict determination on the new read-write set of Tx3 again, when the read-write set generated by group 0 is found, the read-write set management module will consider that there is no conflict, at this time, tx3 determines that there is no conflict, and can apply the execution result corresponding to the new read-write set of Tx3 to the temporary block book, and then continue to the read-write set of the next transaction; the Tx4 writes a key4 which does not exist before, so that no conflict exists, but reads the key3, and although there is a write-read conflict, the key belongs to the same group and should not conflict, but because the Tx3 is re-executed, the read-write set result generated by the Tx3 may also be changed, and the Tx4 reads the key3 written in the Tx3, so that the Tx4 also needs to be re-executed, so that the Tx4 conflict can be calculated, the read-write set management module sends the read-write sets of Tx1, tx2 and Tx3 to the sub-actuator No. 0, the sub-actuator No. 0 can apply the execution results corresponding to the read-write sets of Tx1, tx2 and Tx3 to the transaction ledger, and then re-executes Tx4 based on the transaction ledger to obtain a new read-write set of Tx4, the read-write set of Tx4 is changed to a group 0, and the read-write set management module performs conflict judgment on the new read-write set of Tx4 again; since the new read/write set group of Tx4 is 0, the read/write set management module determines that Tx4 is conflict-free at this time, and may apply the execution result corresponding to the new read/write set of Tx4 to the temporary block book, and then continue to perform conflict detection for the next transaction; tx5 read key a and write key5 do not conflict with the previous, and the execution result of Tx5 may be applied to the temporary block ledger; the Tx6 write key6 does not conflict, the read key a is consistent with the read set of Tx5, although the read and read are not conflicting, the Tx6 read key5 and Tx5 are not in the same group, so the Tx6 judges that there is a conflict and needs to re-execute the transaction once according to the re-execution flow, and then applies the execution result of the read and write set of Tx6 obtained by re-execution to the temporary block account book.

After the read-write set management module judges that all read-write sets are finished, the transaction scheduling module is informed of successful transactions, and after the transaction scheduling module receives the execution result of each transaction, the execution result of each transaction can be applied to the block ledger of the current node of the block chain, so that the execution of each transaction is finished in the block ledger, and then the module is informed of quitting, and the current block execution is finished.

In the execution process, the read-write header management module can work in parallel in the transaction execution process of the transaction scheduling module. The read-write set management module can perform conflict detection only by waiting for the read-write set of the next transaction in sequence, and does not need to wait for the transaction scheduling module to finish all transactions, so that the concurrency of the transactions is improved.

In this embodiment, it is equivalent to complete parallel execution of the transaction only by adapting the transaction execution module in the block chain and without modifying other modules.

In addition, the method in the application has the advantages that the overhead caused by conflict generated in parallel in the transaction is constant and is at most 2 times of the original overhead, namely when all transactions generate conflict and are re-executed, the overhead is 2 times of the original overhead, and the execution time of the transaction can be estimated based on a fixed expectable overhead.

Referring to fig. 6, a schematic diagram of a transaction execution apparatus provided in the embodiment of the present application is shown, and specifically may include a transaction grouping module 61, a parallel execution module 62, a collision detection module 63, and a completion determination module 64, where:

a transaction grouping module 61, configured to divide a plurality of transactions in a block into a plurality of transaction groups, where each transaction group includes at least one transaction;

a parallel execution module 62, configured to execute each transaction group in parallel through a plurality of first sub-executors, and generate a read-write set corresponding to each transaction one to one, where each first sub-executor is configured to execute one transaction group;

a conflict detection module 63, configured to perform conflict detection on each transaction according to the read-write set;

a completion determining module 64, configured to determine that the block execution is completed when none of the transactions has an execution conflict.

In one possible implementation, the apparatus further includes:

and the re-execution module is used for re-executing the target transaction through the second sub-executor if the target transaction with the execution conflict exists.

In a possible implementation manner, the read-write set includes an execution result of the transaction, and the parallel execution module 62 includes:

an execution result determination submodule for determining an execution result of a transaction prior to the target transaction;

and the sending submodule is used for sending the execution result and the identification information of the target transaction to the second sub-actuator, and the second sub-actuator is used for executing the target transaction according to the execution result.

In a possible implementation manner, the collision detection module 63 includes:

the first transaction determining submodule is used for determining a first transaction to be detected according to the transaction execution sequence;

the second transaction detection submodule is used for detecting whether a second transaction which performs target operation on the same field as the first transaction exists or not according to the read-write set;

the transaction grouping determination submodule is used for determining the transaction grouping of the second transaction if the second transaction exists;

and the judgment sub-module is used for carrying out conflict detection on the first transaction according to the transaction group of the second transaction.

In a possible implementation manner, the determining submodule includes:

a first determining unit, configured 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;

a second determining unit, configured to determine whether the second transaction is the target transaction that has been executed again by the second sub-executor if the second transaction and the first transaction are in the same transaction group; determining that the first transaction does not have an execution conflict if the second transaction is not the target transaction; determining that the first transaction has an execution conflict if the second transaction is the target transaction.

In one possible implementation, the completion determining module 64 includes:

the temporary storage submodule is used for storing the execution result in a temporary block book if the transaction does not have the execution conflict;

a confirmation completion sub-module, configured to, if it is determined that each transaction does not have an execution conflict according to an execution order, and an execution result of each transaction is stored in the temporary block ledger, store the execution result of each transaction in the temporary block ledger into the block ledger.

In a possible implementation manner, the apparatus further includes:

and the sub-executor generating module is used for generating a plurality of sub-executors according to the processor cores of the node equipment in the block chain, wherein the sub-executors comprise a plurality of first sub-executors and at least one second sub-executor.

For the apparatus embodiment, since it is substantially similar to the method embodiment, it is described relatively simply, and reference may be made to the description of the method embodiment section for relevant points.

Fig. 7 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 7, the computer device 7 of this embodiment includes: at least one processor 70 (only one shown in fig. 7), a memory 71, and a computer program 72 stored in the memory 71 and executable on the at least one processor 70, the processor 70 implementing the steps in any of the various method embodiments described above when executing the computer program 72.

The computer device 7 may be a desktop computer, a notebook, a palm computer, a cloud server, or other computing devices. The computer device may include, but is not limited to, a processor 70, a memory 71. Those skilled in the art will appreciate that fig. 7 is merely an example of the computer device 7, and does not constitute a limitation of the computer device 7, and may include more or less components than those shown, or combine some of the components, or different components, such as input output devices, network access devices, etc.

The Processor 70 may be a Central Processing Unit (CPU), and the Processor 70 may be other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory 71 may in some embodiments be an internal storage unit of the computer device 7, such as a hard disk or a memory of the computer device 7. The memory 71 may also be an external storage device of the computer device 7 in other embodiments, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like, which are provided on the computer device 7. Further, the memory 71 may also include both an internal storage unit and an external storage device of the computer device 7. The memory 71 is used for storing an operating system, an application program, a BootLoader (BootLoader), data, and other programs, such as program codes of the computer programs. The memory 71 may also be used to temporarily store data that has been output or is to be output.

An embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored, and when the computer program is executed by a processor, the computer program implements the steps in the foregoing method embodiments.

The embodiments of the present application provide a computer program product, which when executed on a computer device, enables the computer device to implement the steps in the above method embodiments.

The above-mentioned embodiments are only used to illustrate the technical solutions of the present application, and not to limit the same. Although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not depart from the spirit and scope of the embodiments of the present application, and they should be construed as being included in the present application.

Claims

1. A transaction execution method, comprising:

and if the transaction does not have execution conflict, determining that the block is executed completely.

2. The method of claim 1, wherein after performing collision detection for each of the transactions according to the read-write set, the method further comprises:

and if the target transaction with the execution conflict exists, re-executing the target transaction through the second sub-executor.

3. The method of claim 2, wherein the read-write set includes results of execution of the transaction, and the re-executing of the target transaction by the second sub-executor comprises:

determining an execution result of a transaction prior to the target transaction;

and sending the execution result and the identification information of the target transaction to the second sub-executor, wherein the second sub-executor is used for executing the target transaction according to the execution result.

4. The method of claim 2 or 3, wherein the transactions have an order of execution of the transactions, and wherein the performing collision detection for each of the transactions based on the read-write sets comprises:

determining a first transaction to be detected according to the transaction execution sequence;

determining a target field according to the read-write set of the first transaction, wherein the target field is a field for executing read operation in the first transaction;

detecting whether a second transaction for executing write operation on the target field exists according to the read-write set, wherein the second transaction is a transaction of which the transaction execution sequence is before the first transaction;

if the second transaction exists, determining a transaction group of the second transaction;

and performing conflict detection on the first transaction according to the transaction group of the second transaction.

5. The method of claim 4, wherein said performing collision detection for said first transaction based on a transaction grouping for said second transaction comprises:

determining that the first transaction has an execution conflict if the second transaction is not in the same transaction group as the first transaction;

if the second transaction is in the same transaction group as the first transaction, determining whether the second transaction is the target transaction that has been re-executed by the second sub-executor; determining that the first transaction does not have an execution conflict if the second transaction is not the target transaction; determining that the first transaction has an execution conflict if the second transaction is the target transaction.

6. The method of any of claims 1-3 or 5, wherein determining that the block execution is complete if there is no execution conflict for each of the transactions comprises:

if the transaction does not have an execution conflict, storing an execution result of the transaction in a temporary block book;

if it is determined that there is no execution conflict for each transaction according to the execution sequence and the execution result of each transaction is stored in the temporary block book, storing the execution result of each transaction in the temporary block book in the block book.

7. The method of claim 6, wherein prior to dividing the plurality of transactions in the block into a plurality of transaction groups, the method further comprises:

and generating a plurality of sub executors according to the processor cores of the node equipment in the block chain, wherein the sub executors comprise a plurality of first sub executors and at least one second sub executor.

8. The transaction execution device is characterized by comprising a transaction static analysis module, a transaction scheduling module and a read-write management module, wherein:

the transaction static analysis module is used for analyzing the transactions in the block to generate at least one transaction group, wherein the transaction group comprises at least one transaction;

9. The apparatus of claim 8, wherein the transaction scheduling module comprises a list of sub-executors, the list of sub-executors including at least one first sub-executor, the first sub-executor including a transaction ledger, wherein:

the sub-executor list is used for executing all the transaction groups in parallel through all the first sub-executors;

the first sub-executor is configured to execute one of the transaction groups based on the transaction ledger.

10. The apparatus of claim 8 or 9,

the read-write set management module is also used for determining target transactions with execution conflicts according to the read-write set and sending the target transactions to the transaction scheduling module;

11. The apparatus of claim 10, wherein the apparatus further comprises a temporary block ledger, the read-write set management module further to:

if the transaction is confirmed to have no execution conflict, applying an execution result of the transaction to the temporary block book;

and if the execution result of each transaction is applied to the temporary block ledger, storing the data in the temporary block ledger to a block ledger of a block chain node.

12. The apparatus of claim 11, wherein the transaction scheduling module further comprises a second sub-executor to execute the target transaction with an execution conflict.

13. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that the processor implements the method according to any of claims 1-7 when executing the computer program.

14. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1-7.