CN115796874B

CN115796874B - Concurrent execution method for blockchain transaction at operation level

Info

Publication number: CN115796874B
Application number: CN202310026559.0A
Authority: CN
Inventors: 林浩然; 朱建锋
Original assignee: Hangzhou Anjie Technology Co ltd
Current assignee: Hangzhou Anjie Technology Co ltd
Priority date: 2023-01-09
Filing date: 2023-01-09
Publication date: 2023-05-09
Anticipated expiration: 2043-01-09
Also published as: CN115796874A

Abstract

The invention discloses a concurrent execution method of a blockchain transaction at an operation level, which comprises dynamically generating an operation log while concurrently executing the transaction in a block, wherein the operation log comprises a serial number, an instruction code, an operand, an operation result and a serial number of a dependent operation of each execution operation.

Description

Concurrent execution method for blockchain transaction at operation level

Technical Field

The invention relates to the field of computer parallel computing, in particular to a concurrent execution method of blockchain transactions at an operation level.

Background

Blockchain technology has attracted considerable attention and application due to its decentralised and non-tamperable nature. The introduction of smart contract technology further enables modern blockchain systems to execute user-written programs. This allows blockchain technology to be used in more areas, such as de-centralized finance, etc. However, the throughput of existing blockchain systems is still low (e.g., ethernet can only handle about 15 transactions per second), which greatly limits the scope of application of blockchain technology.

Existing blockchain systems mostly employ sequential execution to process transactions within each block. Sequential execution, while simple to implement, does not take advantage of the parallelism of modern processors and memory devices, limiting the transaction processing capabilities of the blockchain system. The conventional concurrent execution method in the database field cannot effectively improve the throughput of the blockchain system. In a high-conflict blockchain transaction environment, a traditional concurrent execution method can frequently block or suspend concurrently executed transactions, thereby causing the degradation of transaction processing performance. For example, the traditional two-phase lock method (2 PL) locks accessed data when executed concurrently, which results in contention and blocking between multiple transactions accessing the same data at the same time; the optimistic control method (OCC) can generate data collision problems due to the concurrent transactions modifying the same data at the same time, thereby frequently aborting and restarting the conflicting transactions. Therefore, there is a need for an efficient concurrent execution method for a blockchain operating environment, which utilizes parallelism of modern computer hardware on one hand, and solves the problems of transaction blocking and suspension caused by the conventional concurrent execution method on the other hand, so as to increase the speed of processing transactions by a blockchain system.

Disclosure of Invention

The invention aims to improve the defects of the prior art, and provides a concurrent execution method of a blockchain transaction at an operation level, which realizes high concurrent execution of the blockchain transaction by identifying and re-executing conflicting instructions at the operation level.

The invention discloses a concurrent execution method of blockchain transactions at an operation level, wherein the transaction execution comprises the following steps:

step one: concurrently speculating to execute all transactions in a block, recording a read set and a write set of each transaction, and generating an operation log;

step two: sequentially checking whether the read set of the transaction is matched with the global state of the current blockchain according to the sequence of the transaction in the block, if so, updating the write set of the transaction to the global state of the blockchain and submitting the write set of the transaction, otherwise, entering a step III;

step three: for transactions not submitted in step two, identifying conflicting instruction sequences within the transaction according to the operation log;

step four: checking whether the conflicting instruction sequences in the third step meet the re-execution condition, if so, entering the fifth step, otherwise, directly entering the sixth step;

step five: re-executing the conflicting instruction sequence in the third step, updating the transaction writing set to the global state of the blockchain, and submitting the transaction writing set;

step six: and (3) re-executing the whole transaction for the transaction which does not pass through the verification of the read set in the second step and the conflict instruction sequence in the fourth step, re-recording the write set of the transaction, updating the write set of the transaction to the global state of the blockchain after the execution is finished, and submitting the write set of the transaction.

As a further improvement, in the first step of the present invention, the operation log includes a sequence number of each executed operation, an instruction code, an operand, an operation result, and a sequence number of a dependent operation.

As a further improvement, the method for generating the operation log in the invention tracks the data flow in the stack, the memory and the storage, and obtains the serial number of the father operation on which each operation depends according to the instruction dependency relationship embodied in the data flow.

As a further improvement, the instruction sequence for identifying the conflict in the transaction in the third step specifically marks the instruction read to the conflict key value pair as a conflict instruction, finds all the instructions directly or indirectly depending on the conflict instructions according to the operation log, and marks the instructions as conflict instructions.

As a further improvement, in the fourth step of the present invention, the condition for re-executing the conflicting instruction sequence is specifically: the control and data streams of the transaction are not changed when the conflicting instructions are re-executed.

In the fifth step of the present invention, the conflicting instruction sequences in the third step are executed again, specifically, all conflicting instructions are executed again in sequence according to the instruction sequence number, each conflicting instruction obtains the value of the operand of the instruction again from the operation result of the dependent instruction according to the dependent instruction sequence number recorded in the operation log, then the instruction is executed again according to the instruction code of the operation log and the newly obtained operand, and the operation log of the instruction is updated according to the operation result.

The beneficial effects of the invention are as follows:

aiming at the high conflict transaction environment of the blockchain, the invention provides the blockchain transaction concurrency execution method with the operation level, which not only realizes the concurrent execution of the transaction by utilizing the parallelism of modern computer hardware, but also effectively relieves the blocking and stopping problems of the traditional concurrency execution method in the blockchain environment and accelerates the transaction processing rate of the blockchain system. In order to avoid the transaction blocking problem caused by the traditional pessimistic concurrency control method (such as 2 PL), the invention applies the optimistic concurrency control method in the database field to the blockchain field. Further, in order to improve the transaction suspension problem of the conventional optimistic concurrency control method in the blockchain working environment, the present invention proposes the concept of operation-level conflict recognition and re-execution in step three, so that only a small portion of operations will be re-executed due to data conflicts, and most of instructions unrelated to the data conflicts can still be efficiently executed concurrently.

In addition, in order to realize conflict identification and re-execution at the operation level, the invention introduces a data structure of an operation log in the step one, and realizes the execution environment and interdependent record of all operations of each transaction. Meanwhile, the invention also provides a lightweight data tracking algorithm in the first step, which can realize the generation of the operation log with lower performance loss. Through the operation log, the invention can realize quick conflict identification and re-execution of the operation level in the third step, and avoid the performance degradation caused by the need of blocking or suspending the whole transaction in the traditional concurrent execution method. Experiments show that for the Ethernet client, the performance of the block chain transaction concurrent execution method at the operation level is improved by 4.28 times compared with that of the original sequential execution method; whereas traditional concurrent execution methods, such as optimistic concurrency control algorithms (OCC), can only accelerate by a factor of 2.49. Experiments prove that the method can obviously improve the transaction processing rate of the blockchain system.

Drawings

FIG. 1 is a flow chart of a method for concurrently executing a blockchain at the operational level of the present invention.

Detailed Description

The objects and effects of the present invention will become more apparent from the following detailed description of the preferred embodiments thereof, taken in conjunction with the accompanying drawings, wherein it is to be understood that the embodiments described herein are for the purpose of illustrating the invention only and not for the purpose of limiting the same.

FIG. 1 is a flow diagram of a method of operation level blockchain concurrency execution, with a visual depiction of transaction concurrency execution.

Step one: all transactions in one block are executed concurrently, a read set and a write set of each transaction are recorded, and an operation log is generated. The operation log includes a serial number of each operation executed, an instruction code, an operand, an operation result, and a serial number of a dependent operation, as shown in the following table.

The key to operation log generation is to obtain the sequence numbers of all operations that each operation depends on. The operation log generating method is to track the data flow in the stack, the memory and the storage and obtain the serial number of the parent operation on which each operation depends according to the instruction dependency relationship embodied in the data flow. Specifically, the present invention classifies the operations within a transaction into the following categories, and log generation is performed in different ways.

1) And for the operation of modifying the account balance, generating a balance operation log, and recording the modified account address, the pre-modified balance and the modified balance.

2) For the operation of modifying account nonce, a nonce operation log is generated, and the modified account address, the pre-modification nonce and the post-modification nonce are recorded.

3) For the virtual machine operation of the access stack, a shadow stack is additionally arranged outside the original virtual machine stack and used for recording the sequence number of the generating operation of each element in the stack, and in this way, the operation of all the access stacks can acquire the sequence number of the operation which depends on the operation from the shadow stack corresponding to the operand, and further acquire the operation which depends on the whole operation. Maintenance of the shadow stack is similar to the stack, taking the ethernet virtual machine as an example, for PUSH operation, the virtual machine pushes a constant into the stack, pushes NULL into the shadow stack (meaning that the operation does not depend on any other operation), for POP operation, the virtual machine POPs a value from the stack and also POPs a value from the shadow stack, for SWAP operation, the virtual machine exchanges elements in the stack and also exchanges elements in the corresponding shadow stack, for DUP operation, the virtual machine copies elements in the stack and also copies elements in the corresponding shadow stack, for other stack operation, the virtual machine POPs parameters from the stack and also POPs elements corresponding to the parameters from the shadow stack, if all popped shadow stack elements are NULL, then no operation log is generated, otherwise, a new operation log is generated, and its def.stack field is set as an element in the shadow stack.

4) For the operation of accessing the memory, a shadow memory is additionally arranged outside the original virtual machine memory and is used for recording the writing of each byte in the memory by which operation and the offset during writing. Taking the ethernet virtual machine as an example, for each byte of the virtual machine memory, a corresponding (LSN, offset) is stored in the shadow memory, where LSN represents the sequence number of the last operation to write to the memory location, and offset represents the offset of the last operation to write to the memory location. For an operation accessing the memory, the def.memory field of the operation log is composed of several (start, len, lsn, offset) tuples, which indicates that the memory address from start to start+len is written by the operation with sequence number lsn, and the offset is offset. For the read-in operation, the def. Memory field is obtained through the shadow memory.

5) For operations accessing the store, a mapping is additionally maintained, recording the sequence number of operations that each slot has written to the corresponding most recently, in such a way that the operations accessing the store can obtain the sequence number of operations that it depends on for the slot accessed according to this mapping.

6) For operations that may affect control and data flows (e.g., JUMP, JUMPI, MLOAD, MSTORE in ethernet, etc.), an additional conditional operation log is generated indicating that the condition must be met upon re-execution. For control flow related operations, the conditional operation log records the control flow transfer conditions and control flow transfer targets for the operation, and for data flow related operations, the conditional operation log records the address of the data written by the operation.

Step two: and sequentially checking whether the read set of the transaction is matched with the global state of the current blockchain according to the sequence of the transaction in the block, if so, updating the write set of the transaction to the global state of the blockchain and submitting the write set of the transaction, otherwise, entering the step three. Specifically, when a transaction speculation completes, the transaction enters a check queue state, and only after all transactions ordered before it (in the order within the block) are committed, the transaction formally enters a read-set check step. In the read-set verification step, the read set at the time of execution of the speculative is compared to the global store at the time of verification (i.e., after all transactions ordered prior thereto have been committed). If so, the write set obtained by the speculative execution is directly submitted to the global storage. Otherwise, recording all unmatched read sets, and entering a conflict operation identification step.

Step three: for transactions that are not committed in step two, a conflicting instruction sequence within the transaction is identified based on the oplog. Specifically, in the conflict identification step, all operations directly accessing the unmatched read set elements are first found through the oplog and marked as source conflict operations. The oplog can be considered a directed acyclic graph because it records dependencies between operations. Then, using the depth-first traversal algorithm or breadth-first traversal algorithm to traverse the graph, starting with the source conflict operation, and marking all traversed operations as conflict operations as well. After the traversal is finished, all marked operations are conflicting operations.

Step four: checking whether the conflicting instruction sequence in the third step meets the re-execution condition, if so, entering the fifth step, otherwise, directly entering the sixth step. When the operation log is generated in the first step, the control flow and the data flow to be executed are recorded, and the conditions for maintaining the control flow and the data flow are also provided. This step verifies whether the control flow and data flow match conditions are also met if the result of the conflicting operation is corrected. If not, the re-execution of the operation level cannot be performed, and only the re-execution of the transaction level can be performed.

Step five: and re-executing the conflicting instruction sequence in the third step, updating the transaction writing set, and then updating the transaction writing set to the global state of the blockchain and submitting the transaction writing set. The re-execution of the conflict instruction sequence is specifically as follows: first, all operations that directly access the unmatched read set elements are found and the results of these operations are updated to the correct values in the current global store. For other conflict operations, according to the dependent operation serial number recorded in the operation log, the value of the operand of the operation is obtained again from the operation result of the dependent operation, then the instruction is executed again according to the instruction code of the operation log and the newly obtained operand, and the result is stored in the operation result column of the operation log of the operation. Wherein, for a conflict operation (such as SSTORE instruction in Ethernet), the result of the operation is updated to the write set of the transaction. After all conflict operations are re-executed, the write set is written into global storage and the transaction is committed.

Step six: and (3) discarding the write set of the transaction which fails to pass through the verification of the read set of the step (II) and the conflict instruction sequence of the step (IV) in the speculative execution stage, re-executing all operations of the transaction in a brand-new virtual machine environment, recording the write set of the transaction in the process of executing the transaction, writing the write set into a global storage after the transaction is executed, and submitting the transaction.

It will be appreciated by persons skilled in the art that the foregoing description is only a single example of the invention and is not intended to limit the invention, and that although the invention has been described in detail with reference to the foregoing examples, it will be apparent to those skilled in the art that modifications may be made to the technical solutions described in the foregoing examples, or that equivalents may be substituted for part of the technical features thereof. Modifications, equivalents, and alternatives falling within the spirit and principles of the invention are intended to be included within the scope of the invention.

Claims

1. A method of concurrent execution of blockchain transactions at an operational level, wherein the transaction execution comprises the steps of:

step three: for transactions not submitted in step two, identifying conflicting instruction sequences within the transaction according to the operation log; in the conflict identification step, firstly, operations of directly accessing unmatched read set elements are found through an operation log, the operations are marked as source conflict operations, the operation log is regarded as a directed acyclic graph because the dependency relationship among the operations is recorded by the operation log, then the graph is traversed by using a depth-first traversal algorithm or a breadth-first traversal algorithm with the source conflict operations as a starting point, all the traversed operations are marked as conflict operations, and after the traversal is finished, all the marked operations are the conflict operations;

step five: re-executing the conflicting instruction sequence in the third step, updating the transaction writing set to the global state of the blockchain, and submitting the transaction writing set; the re-execution of the conflicting instruction sequence is specifically: firstly, finding all operations directly accessing unmatched read set elements, updating the results of the operations into correct values in the current global storage, for other conflict operations, re-acquiring the values of operands of the operations from operation results of the dependent operations according to the dependent operation serial numbers recorded in operation logs, re-executing the instructions according to instruction codes of the operation logs and newly acquired operands, and storing the results into operation result columns of the operation logs of the operations, wherein for conflict operations of writing storage, updating the results of the operations into write sets of the transaction together, writing the write sets into the global storage after all conflict operations are re-executed, and submitting the transaction;

2. The method of claim 1, wherein in the first step, the operation log includes a sequence number of each operation, an instruction code, an operand, an operation result, and a sequence number of a dependent operation.

3. The method for concurrently executing blockchain transactions at an operation level according to claim 1, wherein the method for generating the operation log is to track data flows in a stack, a memory and a storage, and obtain a serial number of a parent operation on which each operation depends according to an instruction dependency relationship embodied in the data flows.

4. A method for concurrently executing blockchain transactions at the operation level according to claim 1, 2 or 3, wherein the instruction sequence for identifying the conflicts in the transactions in the third step is specifically that the instruction read to the conflict key value pair is marked as a conflict instruction, all the instructions directly or indirectly depending on the conflict instructions are found according to the operation log, and the instructions are also marked as conflict instructions.

5. The method according to claim 4, wherein in the fourth step, the re-execution condition of the conflicting instruction sequence is specifically: the control and data streams of the transaction are not changed when the conflicting instructions are re-executed.

6. The method according to claim 1, 2, 3 or 5, wherein in the fifth step, the conflicting instruction sequences in the third step are re-executed in sequence, and each conflicting instruction re-acquires the value of the operand of the instruction from the operation result of the dependent instruction according to the dependent instruction serial number recorded in the operation log, and then re-executes the instruction according to the instruction code of the operation log and the newly acquired operand, and updates the operation log of the instruction according to the operation result.