Parallel execution method and device for transactions in block
By executing transactions within blocks in parallel and recording operation logs, and by monitoring and rolling back conflicting operations in real time, the problem of limited transaction throughput and long confirmation time in traditional blockchain systems is solved, achieving more efficient transaction processing.
Patent Information
- Application Number
- CN202511696827.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-19
- Publication Date
- 2026-02-17
AI Technical Summary
In traditional blockchain systems, the serial execution of transactions within a block results in the underutilization of multi-core CPU resources, limited transaction throughput, and excessively long transaction confirmation times. Existing parallel execution methods perform worse than serial execution in high-conflict scenarios.
The method of parallel execution of transactions within a block is adopted. By executing multiple transactions in a block in parallel and recording the operation record of each transaction, operation conflicts are monitored in real time, conflicting operations are rolled back and re-executed, and the granularity of conflicts is reduced from the entire transaction to the opcode level.
It improves the accuracy and efficiency of parallel execution of transactions within a block, reduces invalid redundant calculations, and enhances the resource utilization and transaction throughput of multi-core CPUs.
Smart Images
Figure CN121542353A_ABST
Abstract
Description
Technical Field
[0001] This application relates to blockchain technology, and more particularly to a method and apparatus for parallel execution of transactions within a block. Background Technology
[0002] With the maturity of distributed ledger technology, blockchain, with its decentralized, tamper-proof, and traceable characteristics, has been widely used in finance, supply chain, and the Internet of Things. Traditional blockchain systems use a serial execution method, that is, transactions within a block are executed one by one in sequence. This serial execution method leads to the underutilization of multi-core central processing unit (CPU) resources, severely limited transaction throughput, and excessively long transaction confirmation times.
[0003] To address the aforementioned issues, a parallel execution approach has been proposed, in which all transactions within a block are executed in parallel, and a complete read-write set is recorded. Once all transactions within a block have been executed, a global comparison is performed based on the read-write set to detect conflicts. If a conflict is found, the transactions are re-executed sequentially, starting from the first conflicting transaction.
[0004] However, this parallel execution method can only detect conflicts after all transactions have been completed, and once a conflict occurs, the calculations of all transactions after the conflict are invalidated. Therefore, in high-conflict scenarios, the performance of this parallel execution method is even worse than that of serial execution. Summary of the Invention
[0005] This application provides a method and apparatus for parallel execution of transactions within a block, which improves the accuracy and efficiency of parallel execution of transactions within a block.
[0006] In a first aspect, embodiments of this application provide a method for parallel execution of transactions within a block. This method can be executed by a parallel execution device for transactions within a block. The method includes: parallel execution of M transactions in a block; M is an integer greater than 1; when executing the first state variable of the i-th transaction, if there is an operation conflict with the (i+n)-th transaction on the first state variable, then roll back the operation of the (i+n)-th transaction on the first state variable; the i-th transaction and the (i+n)-th transaction are both transactions in the M transactions and the (i+n)-th transaction is any subsequent transaction of the i-th transaction; i and n are integers greater than 1; after the i-th transaction has completed its operation on the first state variable, the operation of the (i+n)-th transaction on the first state variable is re-executed.
[0007] Using the above method, conflicting operations can be detected in a timely manner during the execution of transactions within a block, and the conflicting operations can be re-executed after they are detected. This reduces the granularity of re-execution of conflicts from the "entire transaction" to the "opcode level", thereby reducing invalid duplicate calculations.
[0008] In one possible implementation, a conflict is determined between the execution of the first state variable of the i-th transaction and the i+n-th transaction regarding the first state variable, in the following manner: if the i-th transaction performs a write operation on the first state variable, and the i+n-th transaction has already performed a read operation on the first state variable, then it is determined that there is a conflict between the i-th transaction and the i+n-th transaction regarding the first state variable.
[0009] In one possible implementation, the method further includes: after the M transactions are completed, obtaining the parallel execution results of the M transactions based on the operation records of the M transactions and recording them in a shared record, wherein if the same state variable exists in the operation records of at least two transactions, the operation record of the subsequent transaction in the at least two transactions is used as the basis for recording in the shared record.
[0010] Using the above method, the shared record corresponding to the block can be accurately obtained based on the operation records and transaction sequence numbers of multiple transactions within the block.
[0011] In one possible implementation, parallel execution of M transactions in a block includes: executing any one of the M transactions in the block in parallel, and recording the operations of each transaction on each state variable during execution to obtain an operation record for each transaction; wherein, the operation record of any transaction includes the update source for any state variable in the transaction; if there is a write operation on a state variable in the transaction, the update source is itself; if there is a read operation on a state variable in the transaction, the update source is the latest read operation trigger; determining whether there is an operation conflict on the first state variable of the i-th transaction with the (i+n)-th transaction when executing the first state variable is as follows: when executing the first state variable of the i-th transaction, reading the operation record of the i-th transaction, and if the update source for the first state variable in the operation record of the i-th transaction is the (i+n)-th transaction, then determining that there is an operation conflict on the first state variable with the (i+n)-th transaction.
[0012] By using the above method, based on the first state variable recorded in the operation log and the source of the update of the first state variable, the read and write operations of each opcode can be monitored in real time, realizing timely detection of conflicts and improving the accuracy and efficiency of parallel execution of transactions within the block.
[0013] In one possible implementation, the operation of each transaction on each state variable during execution is recorded to obtain the operation record of each transaction, including: if the h-th transaction does not read the second state variable from the operation record of the h-th transaction when performing a read operation on the second state variable, then the operation record of the previous transaction is read sequentially until the shared record is reached; if the second state variable is read from the operation record information of the hk-th transaction, then the second state variable is updated in the operation records from the hk-th transaction to the h-th transaction, and the corresponding update source is the h-th transaction.
[0014] In one possible implementation, before recording the operations of each transaction on each state variable during execution, the method further includes: creating a local cache space for each transaction; the initial state of the local cache space of any transaction is empty, which is used to store the operation records of the transaction during execution; the local cache space of any i-th transaction and the local cache space of the (i+1)-th transaction form a cache linked list.
[0015] Using the above method, this application constructs a local cache space in the form of a doubly linked list, creating a traceable and ordered read / write history view.
[0016] Secondly, embodiments of this application provide a parallel execution apparatus for transactions within a block. The apparatus includes an execution module for parallel execution of M transactions in a block; M is an integer greater than 1; and a rollback module for rolling back the operation of the (i+n)th transaction on the first state variable when executing the first state variable of the i-th transaction, if there is an operation conflict with the (i+n)-th transaction on the first state variable; the i-th transaction and the (i+n)-th transaction are both transactions in the M transactions and the (i+n)-th transaction is any subsequent transaction of the i-th transaction; i and n are integers greater than 1; the execution module is further configured to re-execute the operation of the (i+n)-th transaction on the first state variable after the i-th transaction has completed its operation on the first state variable.
[0017] In one possible implementation, the parallel execution device for transactions within the block further includes a determining module, which is configured to: when the i-th transaction performs a write operation on the first state variable, if the (i+n)-th transaction has already performed a read operation on the first state variable, determine that there is an operational conflict between the i-th transaction and the (i+n)-th transaction on the first state variable.
[0018] In one possible implementation, the execution module is further configured to, after the M transactions are completed, obtain the parallel execution results of the M transactions based on the operation records of the M transactions and record them in a shared record, wherein if the same state variable exists in the operation records of at least two transactions, the operation record of the subsequent transaction in the at least two transactions is used as the basis for recording in the shared record.
[0019] In one possible implementation, the execution module is specifically used to execute any one of the M transactions in the block in parallel, and record the operation of each transaction on each state variable during the execution process to obtain the operation record of each transaction; wherein, the operation record of any transaction includes the update source for any state variable in the transaction; if there is a write operation on the state variable in the transaction, the update source is itself; if there is a read operation on the state variable in the transaction, the update source is the latest read operation triggerer; The determining module is further configured to, when executing the first state variable of the i-th transaction, read the operation record of the i-th transaction, and if the update source for the first state variable in the operation record of the i-th transaction is the (i+n)-th transaction, then determine that there is an operation conflict with the (i+n)-th transaction on the first state variable.
[0020] In one possible implementation, the execution module is specifically configured to: if the second state variable is not read from the operation record of the h-th transaction when the h-th transaction performs a read operation on it, then read the operation record of the previous transaction in sequence until the shared record is reached; if the second state variable is read from the operation record information of the hk-th transaction, then update the second state variable and the corresponding update source as the h-th transaction in the operation records from the hk-th transaction to the h-th transaction.
[0021] In one possible implementation, the parallel execution device for transactions within a block further includes a creation module, which is used to create a local cache space for each transaction; the initial state of the local cache space of any transaction is empty, and it is used to store the operation record of the transaction during the transaction execution process; the local cache space of any i-th transaction and the local cache space of the (i+1)-th transaction constitute a cache linked list.
[0022] Thirdly, embodiments of this application also provide a parallel execution device for intra-block transactions, the device including a memory and a processor, the memory being used to store computer programs or instructions; the processor being used to invoke the computer programs or instructions stored in the memory to execute the method as in any possible implementation of the first aspect.
[0023] Fourthly, embodiments of this application also provide a computer-readable storage medium storing instructions that, when read and executed by a computer, cause the computer to perform a method as described in any possible implementation of the first aspect.
[0024] Fifthly, embodiments of this application also provide a computer program that stores instructions that, when read and executed by a computer, cause the computer to perform a method as described in any possible implementation of the first aspect. Attached Figure Description
[0025] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0026] Figure 1 A flowchart illustrating a method for parallel execution of intra-block transactions provided in an embodiment of this application; Figure 2 This application provides a schematic diagram of parallel execution as an embodiment of the present application; Figure 3 This application provides a schematic diagram of a parallel execution process as an embodiment of the present application. Figure 4 A schematic diagram illustrating the process details of re-executing a third transaction, provided for an embodiment of this application; Figure 5 This is a schematic diagram of the internal modules of a parallel execution device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a parallel execution device provided in an embodiment of this application. Detailed Implementation
[0027] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0028] In blockchain applications, a smart contract is considered embedded in the blockchain system when its transactions reach consensus among a majority of nodes. Users can manage state data through the smart contract's interface methods, and changes to this state data are recorded on the blockchain, thus enabling users to modify on-chain data through the smart contract.
[0029] In traditional blockchain systems, multiple transactions within a block are executed sequentially. This execution method leads to underutilization of multi-core CPU resources, excessively long user transaction confirmation times, and severely limited transaction throughput. To improve block execution performance, existing technologies propose a parallel execution scheme that executes all transactions within a block in parallel and records read / write sets. After all transactions within a block have been executed in parallel, a global comparison is performed based on the read / write sets to detect conflicts. If a conflict exists, the transactions that first encountered the conflict are re-executed sequentially to ensure consistency. However, once a conflict occurs, the computation of all transactions after the conflict is invalidated. In high-concurrency scenarios, the performance of this parallel execution remains low.
[0030] Based on this, while ensuring complete consistency with the strictly serial execution results within the block, this application proposes a parallel execution method for transactions within a block, which aims to improve the accuracy and efficiency of parallel execution of transactions within a block.
[0031] Figure 1 This is a flowchart illustrating a parallel execution method for intra-block transactions provided in an embodiment of this application. This process can be executed by a parallel execution device for intra-block transactions, such as... Figure 1 As shown, the process includes the following steps: Step 101: The parallel execution device executes M transactions in the block in parallel.
[0032] Specifically, a parallel execution device refers to the device that executes transactions within the aforementioned block in parallel. For ease of description, it will be referred to as a parallel execution device below. A parallel execution device can be a computer, a physical server, or other intelligent device. A block contains at least one transaction, where M is an integer greater than 1.
[0033] In one possible implementation, the parallel execution of M transactions within a block includes: the M transactions begin execution simultaneously according to their own execution logic; during transaction execution, the parallel execution device performs read, write, and computation operations on the smart contract's state variables based on the opcodes of the code segment and the parameters at the time of invocation. It should be noted that the M transactions can be executed by M threads within the parallel execution device, with each thread executing one transaction from the block.
[0034] In one possible implementation, the parallel execution of M transactions within a block includes: for any one of the M transactions, while executing in parallel, recording the operations performed by each transaction on each state variable during execution, resulting in an operation record for each transaction. The operation record for any transaction includes the source of updates for any state variable within the transaction. If a transaction contains a write operation on a state variable, the update source is itself; if a transaction contains a read operation on a state variable, the update source is the trigger of the latest read operation.
[0035] For example, one of the M transactions is the second transaction TX2. During the execution of the second transaction, a write operation is performed on the state variable 'a'. Therefore, the operation record of the second transaction includes the value of the state variable 'a' and the source of the update of the state variable 'a', which is the second transaction. The other of the M transactions is the third transaction TX3. During the execution of the third transaction, a read operation is performed on the state variable 'b'. Therefore, the operation record of the third transaction includes the value of the state variable 'b' and the source of the update of the state variable 'b', which is the third transaction.
[0036] Specifically, the operation of each transaction on each state variable during execution is recorded to obtain the operation record of each transaction, including: if the h-th transaction does not read the second state variable from the operation record of the h-th transaction when performing a read operation on the second state variable, then the operation record of the previous transaction is read sequentially until the shared record is reached; if the second state variable is read from the operation record information of the hk-th transaction, then the second state variable is updated in the operation records of the hk-th to h-th transactions and the corresponding update source is the h-th transaction.
[0037] In this context, transaction h is one of the M transactions mentioned above. When performing a read operation on the second state variable, the value of the second state variable is first read from the operation record of transaction h. The second state variable can be any state variable. The operation record for each transaction is the record of operations performed from the start of each transaction's execution. Therefore, if transaction h performs a write operation on the second state variable before performing a read operation on it, the operation record of transaction h will include the value of the second state variable. Thus, when transaction h performs a read operation on the second state variable, it can read the value of the second state variable from the operation record of transaction h.
[0038] If transaction h did not perform a write operation on the second state variable before performing a read operation on it, then the operation record of transaction h will not include the value of the second state variable, and therefore transaction h will not be able to read the value of the second state variable from the operation record of transaction h. In this case, transaction h will read the operation record of the previous transaction. If the value of the second state variable is not read from the operation record of the previous transaction, it will continue to read the value of the second state variable from the operation record of the transaction before the previous transaction, until the value of the second state variable is read from the shared record. It should be noted that if the value of the second state variable is not read from the shared record, the value of the second state variable in persistent storage can be read from block 99. After reading the value of the second state variable, for example, if transaction h reads the value of the second state variable from transaction hk, then it updates the operation records of transaction hk up to the operation record of transaction h based on the value of the second state variable. That is, the operation records of transaction hk up to the operation record of transaction h all record the value of the second state variable and the source of the update of the second state variable is transaction h.
[0039] Before recording the operations on each state variable during the execution of each transaction, the process also includes: creating a local cache space for each transaction. The initial state of the local cache space for any transaction is empty. This local cache space is used to store the transaction's operation records during execution. The local cache space of any i-th transaction and the local cache space of the (i+1)-th transaction form a cache linked list. That is, the local cache spaces of M transactions can be doubly linked cache lists, recording the operation records of each transaction in the local cache space.
[0040] Step 102: When the parallel execution device executes the first state variable of the i-th transaction, if there is an operation conflict with the first state variable of the (i+n)-th transaction, the operation of the (i+n)-th transaction on the first state variable is rolled back.
[0041] Specifically, both the i-th transaction and the (i+n)-th transaction are transactions within the M transactions, and the (i+n)-th transaction is any subsequent transaction of the i-th transaction. The first state variable is any state variable among the M transactions. A conflict between the execution of the first state variable of the i-th transaction and the (i+n)-th transaction is determined as follows: when executing the first state variable of the i-th transaction, the operation record of the i-th transaction is read. If the update source for the first state variable in the operation record of the i-th transaction is the (i+n)-th transaction, then a conflict between the i+n-th transaction and the first state variable is determined. The reason for the conflict is that, under normal serial execution, the (i+n)-th transaction should be executed after the i-th transaction. That is, if the M transactions are TX1, TX2, and TX3, then TX1 should be executed first, followed by TX2 and TX3 in sequence. Therefore, the (i+n)th transaction should be executed after the (i)th transaction has been completed. If the (i+n)th transaction performs an operation on the first state variable first, the operation of the first state variable by the (i)th transaction will actually change the first state variable, which will cause the operation of the first state variable by the (i+n)th transaction to be incorrect. In this case, when the first state variable of the (i)th transaction is executed, there will be an operation conflict between the first state variable of the (i+n)th transaction and the first state variable of the (i)th transaction.
[0042] For example, a conflict is determined between the execution of the first state variable of transaction i and transaction i+n in the following manner: if transaction i+n has already performed a read operation on the first state variable while transaction i is performing a write operation on it, then a conflict is determined between transaction i and transaction i+n regarding the first state variable. For example, Figure 2 A schematic diagram of parallel execution provided for an embodiment of this application, such as... Figure 2 As shown, block 99 is a completed block, and its corresponding cache is persistent storage. Block 100 includes three transactions: TX1, TX2, and TX3. Each transaction has its own local cache space. Since the first transaction has already been completed, its local cache space is also called a shared cache. The second transaction needs to write to state variable 'a', then read from state variable 'a', and then write to state variable 'b'. The third transaction needs to read from state variable 'b'. The third transaction reads from state variable 'b' after the second transaction reads from state variable 'a' and before writing from state variable 'b'. Figure 3 This is a schematic diagram of a parallel execution process provided in an embodiment of this application. Figure 3 To and Figure 2The corresponding parallel execution process is shown in the diagram. S1 to S7 are seven steps executed sequentially in chronological order. Specifically, the second transaction executes step S1, performing a write operation on state variable 'a'. For a write operation, the state variable and update source are directly written to the second transaction's local cache space; for example, a=1, update by TX2. Next, the third transaction executes step S2, reading state variable 'b'. First, the third transaction reads state variable 'b' from its local cache space, finding no value there. Then, the third transaction executes step S3, reading the value of state variable 'b' from the next higher-level cache. Finding no value, it continues with step S4, reading the value of state variable 'b' from the next higher-level cache space. The third transaction executes step S5, reading the value of state variable 'b' as 2 from the shared cache, then updating the second transaction's local cache space; for example, b=2, update by TX3. Further, the third transaction continues with step S6, updating its local cache space based on the read value of state variable 'b'; for example, b=2, update by TX3. TX3; Next, the second transaction writes the value of state variable b, for example, b=4, update by TX2. When the second transaction writes the value of state variable b to the local cache space, it is found that the value of state variable b has been recently updated, and the updated transaction is the third transaction. The transaction sequence of the third transaction is greater than the transaction sequence of the second transaction. Therefore, it is determined that there is a conflict with the operation of the third transaction on state variable b. Here, state variable b is the first state variable mentioned above.
[0043] If it is determined that there is an operation conflict on the first state variable in the (i+n)th transaction, then the operation on the first state variable in the (i+n)th transaction is rolled back. Continuing with the above example, the read operation on state variable b in the third transaction is rolled back, that is, steps S2 to S6 are rolled back. Thus, after the rollback, the local cache space of the third transaction and the local cache space of the second transaction will not have the value of state variable b read from the shared cache.
[0044] Step 103: After the i-th transaction completes its operation on the first state variable, the parallel execution device re-executes the operation on the first state variable of the i+n-th transaction.
[0045] Specifically, after the i-th transaction completes its operation on the first state variable, the (i+n)-th transaction re-executes its operation on the first state variable. Continuing with the example above, assuming no further write operations are performed on state variable b after the second transaction's write operation, a third transaction can be executed to read state variable b after the second transaction's write operation. The value read by the third transaction from state variable b is the updated value from the second transaction, i.e., b=4.
[0046] It should be noted that if there are subsequent write operations on state variable b after the write operation on state variable b in the second transaction, the read operation on state variable b in the third transaction needs to be executed again after the second transaction is completed, or after the second transaction has completed its operation on state variable b. After the second transaction is completed, the write operations on all state variables in the second transaction are merged into the shared cache.
[0047] Figure 4 This is a schematic diagram illustrating the process details of re-executing a third transaction, as provided in an embodiment of this application. Figure 4 As shown, after the second transaction is completed, the third transaction reads the value of the state variable b. If it doesn't find the value in its local cache, it reads it from the next higher level cache. Since the second transaction has already written to the state variable, its local cache contains the value of state variable b. Therefore, the third transaction can read the value of state variable b from the previous transaction. After the third transaction rereads the value of state variable b, it updates its local cache.
[0048] After M transactions are completed, the parallel execution results of the M transactions are obtained based on the operation records of the M transactions and recorded in the shared record. If the same state variable exists in the operation records of at least two transactions, the operation record of the subsequent transaction in the at least two transactions is used as the basis for recording in the shared record.
[0049] Specifically, shared records can be stored in a shared cache. After all M transactions in a block have been executed, the write operations on the state variable from the M transactions are merged into the shared cache. It's understood that multiple transactions may have performed write operations on the same state variable. In this case, the write operation on that state variable by the last transaction among the multiple transactions is included in the shared cache. For example, if the second transaction performs a write operation on state variable b, updating it to 4, and the third transaction also performs a write operation on state variable b, updating it to 5, then the updated value of state variable b by the third transaction is included in the shared cache.
[0050] Figure 5This is a schematic diagram of the internal modules of a parallel execution device provided in an embodiment of this application, such as... Figure 5 As shown, the device may include: an execution module 501 and a rollback module 502. Optionally, it may also include a storage module for storing computer instructions or programs. The execution module 501 may call the computer instructions or programs stored in the storage module.
[0051] The execution module 501 is used to execute M transactions in the block in parallel; M is an integer greater than 1. The rollback module 502 is used to roll back the operation of the (i+n)th transaction on the first state variable when executing the first state variable of the i-th transaction; the i-th transaction and the (i+n)th transaction are both transactions in the M transactions and the (i+n)th transaction is any subsequent transaction of the i-th transaction; i and n are integers greater than 1. The execution module is also used to re-execute the operation of the (i+n)th transaction on the first state variable after the i-th transaction has completed its operation on the first state variable.
[0052] In one possible implementation, the parallel execution device for transactions within the block further includes a determining module 503, which is configured to: when the i-th transaction performs a write operation on the first state variable, if the (i+n)-th transaction has already performed a read operation on the first state variable, determine that there is an operation conflict between the i-th transaction and the (i+n)-th transaction on the first state variable.
[0053] In one possible implementation, the execution module 501 is further configured to, after the M transactions are completed, obtain the parallel execution results of the M transactions based on the operation records of the M transactions and record them in a shared record, wherein if the same state variable exists in the operation records of at least two transactions, the operation record of the subsequent transaction in the at least two transactions is used as the basis for recording in the shared record.
[0054] In one possible implementation, the execution module 501 is specifically used to execute any one of the M transactions in the block in parallel, and record the operation of each transaction on each state variable during the execution process to obtain the operation record of each transaction; wherein, the operation record of any transaction includes the update source for any state variable in the transaction; if there is a write operation on the state variable in the transaction, the update source is itself; if there is a read operation on the state variable in the transaction, the update source is the latest read operation triggerer; The determining module 503 is further configured to, when executing the first state variable of the i-th transaction, read the operation record of the i-th transaction, and if the update source for the first state variable in the operation record of the i-th transaction is the (i+n)-th transaction, then determine that there is an operation conflict with the (i+n)-th transaction on the first state variable.
[0055] In one possible implementation, the execution module 501 is specifically configured to: if the second state variable is not read from the operation record of the h-th transaction when the h-th transaction performs a read operation on it, then read the operation record of the previous transaction in sequence until the shared record; if the second state variable is read from the operation record information of the hk-th transaction, then update the second state variable and the corresponding update source as the h-th transaction in the operation records from the hk-th transaction to the h-th transaction.
[0056] In one possible implementation, the parallel execution device for transactions within a block further includes a creation module 504, which is used to create a local cache space for each transaction; the initial state of the local cache space of any transaction is empty, and it is used to store the operation record of the transaction during the transaction execution process; the local cache space of any i-th transaction and the local cache space of the (i+1)-th transaction constitute a cache linked list.
[0057] Figure 6 This is a schematic diagram of the structure of a parallel execution device provided in an embodiment of this application. Figure 6 As shown, it includes at least one processor 601 and a memory 602 connected to at least one processor 601. In this embodiment, the specific connection medium between the processor 601 and the memory 602 is not limited. Figure 6 Taking the connection between the processor 601 and the memory 602 via a bus as an example, the bus can be divided into address bus, data bus, control bus, etc.
[0058] In this embodiment of the application, the memory 602 stores instructions that can be executed by at least one processor 601. By executing the instructions stored in the memory 602, the at least one processor 601 can implement the steps of the above-described parallel execution method for transactions within a block.
[0059] The processor 601 is the control center of the computer device, capable of connecting various parts of the computer device via various interfaces and lines. It performs resource configuration by running or executing instructions stored in the memory 602 and accessing data stored in the memory 602. Optionally, the processor 601 may include one or more processing units. The processor 601 may integrate an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the modem processor may not be integrated into the processor 601. In some embodiments, the processor 601 and the memory 602 may be implemented on the same chip; in other embodiments, they may be implemented on separate chips.
[0060] Processor 601 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.
[0061] Memory 602, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 602 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Memory 602 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. In the embodiments of this application, memory 602 can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.
[0062] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0063] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0064] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0065] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0066] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.
Claims
1. A method for parallel execution of transactions within a block, characterized in that, The method includes: Execute M transactions in a block in parallel; M is an integer greater than 1; When executing the first state variable of the i-th transaction, if there is an operation conflict with the (i+n)-th transaction on the first state variable, then the operation of the (i+n)-th transaction on the first state variable is rolled back; the i-th transaction and the (i+n)-th transaction are both transactions in the M transactions and the (i+n)-th transaction is any subsequent transaction of the i-th transaction; i and n are integers greater than 1; After the i-th transaction completes its operation on the first state variable, the (i+n)-th transaction's operation on the first state variable is re-executed.
2. The method according to claim 1, characterized in that, The following methods are used to determine if there is an operation conflict between the first state variable of transaction i and transaction i+n when executing the first state variable: When the i-th transaction performs a write operation on the first state variable, if the (i+n)-th transaction has already performed a read operation on the first state variable, then it is determined that there is an operational conflict between the i-th transaction and the (i+n)-th transaction on the first state variable.
3. The method according to claim 1, characterized in that, Also includes: After the M transactions are completed, the M transactions are obtained based on their operation records. The parallel execution results of each transaction are recorded in a shared record. If the same state variable exists in the operation records of at least two transactions, the operation record of the subsequent transaction in the at least two transactions is used as the basis for recording in the shared record.
4. The method according to any one of claims 1 to 3, characterized in that, Execute M transactions in a block in parallel, including: Execute any one of the M transactions in the block in parallel, and record the operation of each transaction on each state variable during the execution process to obtain the operation record of each transaction; wherein, the operation record of any transaction includes the update source for any state variable in the transaction; if there is a write operation on the state variable in the transaction, the update source is itself; if there is a read operation on the state variable in the transaction, the update source is the latest read operation triggerer. The following methods are used to determine if there is an operation conflict between the first state variable of transaction i and transaction i+n when executing the first state variable: When executing the first state variable of the i-th transaction, read the operation record of the i-th transaction. If the update source for the first state variable in the operation record of the i-th transaction is the (i+n)-th transaction, then it is determined that there is an operation conflict with the (i+n)-th transaction on the first state variable.
5. The method according to claim 4, characterized in that, Record the operations performed on each state variable during the execution of each transaction, resulting in an operation record for each transaction, including: If the h-th transaction fails to read the second state variable from its operation record when performing a read operation, the operation record of the previous transaction is read sequentially until the shared record is reached. If the second state variable is read from the operation record information of transaction hk, then the second state variable is updated in the operation record from transaction hk to transaction h, and the corresponding update source is transaction h.
6. The method according to claim 4, characterized in that, Before recording the operations on each state variable during the execution of each transaction, it also includes: Create a local cache space for each transaction; the initial state of the local cache space of any transaction is empty, and it is used to store the operation record of the transaction during the execution of the transaction; the local cache space of any i-th transaction and the local cache space of the (i+1)-th transaction form a cache linked list.
7. A parallel execution apparatus for intra-block transactions, characterized in that, include: The execution module is used to execute M transactions in a block in parallel. M is an integer greater than 1; The rollback module is used to roll back the operation of the first state variable of the (i+n)th transaction on the first state variable when the first state variable of the i-th transaction is executed. The i-th transaction and the (i+n)-th transaction are both transactions in the M transactions, and the (i+n)-th transaction is any subsequent transaction of the i-th transaction; i and n are integers greater than 1; The execution module is further configured to, after the i-th transaction has completed its operation on the first state variable, re-execute the operation on the first state variable of the i+n-th transaction.
8. A device for parallel execution of intra-block transactions, characterized in that, include: Memory is used to store computer programs or instructions; A processor is configured to invoke a computer program or instructions stored in the memory to perform the method as described in any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when read and executed by a computer, cause the computer to perform the method as described in any one of claims 1 to 6.
10. A computer program product, characterized in that, The computer program product stores instructions that, when read and executed by a computer, cause the computer to perform the method as described in any one of claims 1 to 6.