Block chain transaction parallel execution method, device, system and program product

Abstract

The invention provides a block chain transaction parallel execution method, device and system and a program product. The method comprises the steps of obtaining multiple transactions from a transaction pool; controlling the Ethereum virtual machine to execute a plurality of transactions in parallel in a plurality of threads; according to a first transaction execution result that the Ethereum virtual machine executes the multiple transactions in parallel in the multiple threads, the dependency relationship among the multiple transactions is obtained, and the first transaction execution result is used for reflecting that no conflict exists among the multiple transactions; the dependency relationship is an execution sequence of different transactions; constructing a transaction dependency view according to the dependency relationship among the plurality of transactions; the transaction dependency view is used for reflecting a parallel execution sequence among a plurality of transactions passing verification; the plurality of transactions and the transaction-dependent view are packed together into a block. According to the method, all transactions can be executed in parallel, so that the transaction processing speed of the block-out node is remarkably improved, and the block-out efficiency of the block-out node is greatly improved.

Description

Technical Field

[0001] The present application belongs to the field of blockchain technology, and in particular, relates to a method, device, system and program product for parallel execution of blockchain transactions. Background Art

[0002] Blockchains built on the Ethereum virtual machine often need to execute blocks by serially executing transactions, which limits the speed of transaction execution and the frequency of block generation, making it difficult to improve the blockchain's transaction processing tps (Transactions Per Second). Summary of the invention

[0003] The embodiments of the present application provide a method, device, system and program product for parallel execution of blockchain transactions to improve the problem that a blockchain built on an Ethereum virtual machine processes transactions slowly due to serial execution of transactions.

[0004] In a first aspect, an embodiment of the present application provides a method for parallel execution of blockchain transactions, comprising:

[0005] Get multiple transactions from the transaction pool;

[0006] Controlling the Ethereum virtual machine to execute multiple transactions in parallel in multiple threads;

[0007] According to the first transaction execution result of the Ethereum virtual machine executing the multiple transactions in parallel in the multiple threads, the dependency relationship between the multiple transactions is obtained, wherein the first transaction execution result is used to reflect that there is no conflict between the multiple transactions; the dependency relationship is the execution order between the different transactions;

[0008] Constructing a transaction dependency view according to the dependency relationship between the multiple transactions; the transaction dependency view is used to reflect the parallel execution order between the multiple transactions that have been verified;

[0009] The plurality of transactions and the transaction dependencies are viewed Figure 1 Packed into blocks.

[0010] In a possible implementation of the first aspect, the dependency relationship between the multiple transactions is obtained according to the multiple transactions executed in parallel by the Ethereum virtual machine in multiple threads, including:

[0011] Obtaining a second transaction execution result of the Ethereum virtual machine executing multiple transactions in parallel in multiple threads;

[0012] When the second transaction execution result indicates that there are conflicts between two or more transactions among the multiple transactions, the two or more transactions are sequentially distributed to the threads for re-execution until there are no conflicts between the multiple transactions, thereby obtaining a first execution result;

[0013] According to the first execution result, the dependency relationship between the multiple transactions is obtained.

[0014] In a possible implementation manner of the first aspect, determining that there is a conflict between two or more transactions among the multiple transactions includes:

[0015] Each time a transaction is executed, the read-write set for executing the current transaction is written into a global key-value pair; the key of the global key-value pair is the identifier of the ledger state variable, and the value of the global key-value pair is the read-write set corresponding to the identifier of the state variable; the read-write set includes a read set and a write set;

[0016] If the state variables in the read set of the current transaction overlap with the state variables in the write set of one or more transactions executed previously, it is determined that there is a conflict between the current transaction and the one or more transactions executed previously.

[0017] In a possible implementation manner of the first aspect, the distributing the two or more transactions to the threads in sequence for re-execution until there is no conflict between the multiple transactions to obtain a first execution result includes:

[0018] Marking the write set of the current transaction as pending data, and establishing a dependency array between the current transaction and one or more transactions executed previously; when executing a subsequent transaction and reading the pending data, adding the subsequent transaction to the corresponding dependency array;

[0019] The conflicting transactions are distributed to the threads in sequence according to the dependency array, and the transactions at the back of the dependency array are distributed to the threads for execution only after the transactions at the front of the dependency array are executed and verified, until there is no conflict between the multiple transactions.

[0020] In a possible implementation of the first aspect, before controlling the Ethereum virtual machine to execute the multiple transactions in parallel in multiple threads, the method further includes:

[0021] Detecting whether at least two of the multiple transactions are sent from the same account address;

[0022] If at least two of the multiple transactions are sent from the same account address, the dependency relationship between the at least two transactions is determined according to the order of nonce values ​​corresponding to the at least two transactions;

[0023] The controlling the Ethereum virtual machine to execute multiple transactions in parallel in multiple threads includes:

[0024] According to the dependency relationship between at least two of the transactions, at least two of the transactions are executed sequentially in one or more of the threads by the Ethereum virtual machine; and transactions other than at least two of the transactions among the multiple transactions are executed in parallel in multiple threads by the Ethereum virtual machine.

[0025] In a second aspect, an embodiment of the present application provides a method for parallel execution of blockchain transactions, the method comprising:

[0026] Obtaining a block; the block includes multiple transactions and transaction dependency views of the multiple transactions, and the transaction dependency view is used to reflect the parallel execution order between the multiple transactions;

[0027] Distributing the multiple transactions to multiple threads according to the parallel execution order of the multiple transactions indicated by the transaction dependency view;

[0028] Execute multiple transactions in parallel on multiple threads through the Ethereum virtual machine;

[0029] Submit the ledger generated after executing multiple transactions described above.

[0030] In a possible implementation manner of the second aspect, after executing the plurality of transactions in parallel on the plurality of threads by the Ethereum virtual machine, the method further includes:

[0031] Verify one by one whether there are conflicts among the multiple transactions that have been executed, and distribute the transactions with conflicts to the threads in sequence for re-execution until the multiple transactions are verified;

[0032] The ledger generated after executing multiple transactions is submitted, including:

[0033] Submit the ledgers generated after the multiple transactions are verified.

[0034] In a possible implementation manner of the second aspect, the verifying one by one whether there is a conflict between the completed transactions includes:

[0035] Each time a transaction is executed, the read-write set for executing the current transaction is written into a global key-value pair; the key of the global key-value pair is the identifier of the ledger state variable, and the value of the global key-value pair is the read-write set corresponding to the identifier of the state variable; the read-write set includes a read set and a write set;

[0036] If the state variables in the read set of the current transaction overlap with the state variables in the write set of one or more transactions executed previously, it is determined that there is a conflict between the current transaction and the one or more transactions executed previously.

[0037] In a possible implementation manner of the second aspect, distributing the conflicting transactions to the threads in sequence for re-execution until the plurality of transactions are verified, includes:

[0038] Mark the write set of the current transaction as pending data, and establish a dependency array between the current transaction and one or more transactions executed previously; when the pending data is read by executing a subsequent transaction, the subsequent transaction is added to the corresponding dependency array;

[0039] The conflicting transactions are distributed to the threads in sequence according to the dependency array, and the transactions at the back of the dependency array are distributed to the threads for execution and verification only after the transactions at the front of the dependency array are executed and verified, until multiple transactions are verified.

[0040] In a possible implementation manner of the second aspect, the method further includes:

[0041] Get the ledger submitted by the block-producing node;

[0042] The ledger submitted by the block-producing node is compared with the ledger submitted by the verification node. If they are consistent, the block is determined to be valid; if they are inconsistent, the block is determined to be invalid.

[0043] In a third aspect, an embodiment of the present application provides a blockchain transaction parallel execution device, including:

[0044] The acquisition module is used to obtain multiple transactions from the transaction pool;

[0045] A parallel execution module, used to control the Ethereum virtual machine to execute multiple transactions in parallel in multiple threads;

[0046] A determination module, configured to obtain a dependency relationship between the multiple transactions according to a first transaction execution result of the Ethereum virtual machine executing the multiple transactions in parallel in the multiple threads, wherein the first transaction execution result is used to reflect that there is no conflict between the multiple transactions; and the dependency relationship is the execution order of different transactions;

[0047] A construction module, used to construct a transaction dependency view according to the dependency relationship between the multiple transactions; the transaction dependency view is used to reflect the parallel execution order between the multiple transactions that have been verified;

[0048] The packaging module combines multiple transactions and transaction dependencies into a Figure 1 Packed into blocks.

[0049] In a fourth aspect, an embodiment of the present application provides a blockchain transaction parallel execution device, including:

[0050] An acquisition module, used for acquiring a block; the block includes a plurality of transactions and a transaction dependency view of the plurality of transactions; the transaction dependency view is used for reflecting the parallel execution order between the plurality of transactions;

[0051] A distribution module, configured to distribute the multiple transactions to multiple threads according to the parallel execution order of the multiple transactions indicated by the transaction dependency view;

[0052] A parallel execution module, used to execute multiple transactions in parallel in multiple threads through the Ethereum virtual machine;

[0053] The submission module is used to submit the ledger generated after executing multiple transactions.

[0054] In a fifth aspect, an embodiment of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the method described in any one of the first aspect or the second aspect is implemented.

[0055] In a sixth aspect, an embodiment of the present application provides a blockchain system, comprising a block producing node and a plurality of verification nodes;

[0056] The block producing node is configured to execute the method as described in any one of the first aspects;

[0057] The verification node is configured to execute the method as described in any one of the second aspects.

[0058] In a seventh aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method as described in any one of the first aspect or the second aspect is implemented.

[0059] In an eighth aspect, an embodiment of the present application provides a computer program product. When the computer program product is run on an electronic device, the electronic device executes any one of the methods in the first or second aspect above.

[0060] It can be understood that the beneficial effects of the second to eighth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here.

[0061] Compared with the prior art, the embodiments of the present application have the following beneficial effects: the embodiments of the present application execute all transactions in parallel to obtain non-conflicting dependencies between transactions, then construct a transaction dependency view based on the dependencies, and add the transaction dependency view together with all transactions to the block, so that the speed at which the block-producing node processes transactions is significantly improved, and the efficiency of the block-producing node in producing blocks is greatly improved. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0064] Figure 2 It is a flowchart of a method for parallel execution of blockchain transactions provided by an embodiment of the present application applied to a block-producing node;

[0065] Figure 3 It is a schematic diagram of the principle of a block production node provided in an embodiment of the present application;

[0066] Figure 4 It is a schematic diagram of the principle of the optimistic parallel and verification process provided by an embodiment of the present application;

[0067] Figure 5 This is a structural block diagram of a blockchain transaction parallel execution device provided by an embodiment of the present application;

[0068] Figure 6 It is a flowchart of a method for parallel execution of blockchain transactions provided by an embodiment of the present application applied to a verification node;

[0069] Figure 7 It is a schematic diagram of the principle of a verification node provided by an embodiment of the present application;

[0070] Figure 8 It is a structural block diagram of a blockchain transaction parallel execution device provided by another embodiment of the present application. DETAILED DESCRIPTION

[0071] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0072] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, wholes, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or combinations thereof.

[0073] It should also be understood that the term “and / or” used in the specification and appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0074] As used in the specification and appended claims of this application, the term "if" can be interpreted as "when" or "uponce" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "uponce it is determined" or "in response to determining" or "uponce [described condition or event] is detected" or "in response to detecting [described condition or event]", depending on the context.

[0075] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0076] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0077] Glossary:

[0078] Ethereum: Ethereum is an open source blockchain platform that not only provides a cryptocurrency, Ether (ETH), but also allows developers to create and deploy smart contracts. Ethereum uses the execution environment of the "Ethereum Virtual Machine" (EVM) to run smart contracts. Each node participating in the Ethereum network has an EVM instance to ensure that all nodes reach a consensus on the execution results of the smart contract.

[0079] Transaction: A transaction is a state-changing operation performed on the Ethereum network. These transactions can involve transferring Ether (ETH), calling smart contracts, or other operations related to the blockchain state. Each transaction is recorded on the blockchain, forming an immutable and permanent record. These transaction records together constitute the Ethereum distributed ledger. The execution of a transaction may cause changes in state variables, thereby updating the state of the ledger.

[0080] Smart Contract: A smart contract is a self-executing code on the Ethereum blockchain that contains specific logic and state variables. Example: A simple token contract can define how to transfer tokens, check balances, and other functions. Users can call this smart contract through transactions.

[0081] Ledger: Ethereum's ledger is a decentralized database that records all transactions and status changes. It is a distributed, immutable record, and all nodes maintain the same copy of the ledger. Ethereum's ledger includes not only account balances, but also the code and status of smart contracts. Whenever a new transaction occurs, the ledger is updated to reflect the latest status.

[0082] State variables: State variables are a set of data stored on the Ethereum blockchain that represent the status of smart contracts and accounts. Each account (including ordinary accounts and contract accounts) has its own state variables, which can store information such as balances, contract codes, and stored data. The update of state variables is achieved through transactions. When a transaction is executed, it changes the state variables of the relevant accounts. Ethereum's virtual machine (EVM) is responsible for executing transactions and updating state variables based on the transaction content.

[0083] Key-Value Pair: A key-value pair is a data representation method that consists of two parts: a key and a corresponding value. A key is a unique identifier, and a value is the data associated with the key. Key-value pairs can be used to store and manage large amounts of data. By organizing data into key-value pairs, data can be easily stored, retrieved, and updated. The key can be used to quickly locate the corresponding value, and the search efficiency is higher than that of linear search.

[0084] like Figure 1 As shown, Figure 1 A schematic diagram of the structure of a blockchain system is provided for the embodiment of the present application. The system includes multiple nodes, and multiple nodes compete for the packaging right. Whenever a new block is packaged and uploaded to the chain by a node, this node is called a block-producing node, and the remaining nodes are called verification nodes. The same copy of the ledger is maintained in each node.

[0085] Block producing nodes are mainly responsible for packaging new blocks and adding them to the blockchain. These nodes compete for the right to create new blocks by solving complex mathematical problems, a process called mining. The node that successfully solves the problem will receive a certain reward, and the new block it packages will be verified and confirmed by other verification nodes in the network. Block producing nodes can be electronic devices such as computers, servers, and mining machines.

[0086] Verification nodes are responsible for verifying the legitimacy of new blocks and confirming the validity of transactions. They verify new blocks to ensure that the transactions in the blocks comply with Ethereum's rules and consensus mechanism. Verification nodes can be electronic devices such as computers, servers, and mining machines.

[0087] In traditional blockchain systems, both block-producing nodes and verification nodes process transactions serially, that is, one after another. Although this method does not cause conflicts between transactions, it will limit processing speed and efficiency.

[0088] The block producing nodes and verification nodes in the embodiment of the present application process transactions in parallel, and re-execute conflicting transactions that exist during the parallel execution process to improve processing speed and efficiency.

[0089] For details, see Figure 2-Figure 4 , Figure 2 A schematic flow chart of a method for parallel execution of blockchain transactions by a block-producing node provided in an embodiment of the present application is shown. Figure 3 A schematic diagram showing the principle of a block generation node provided in an embodiment of the present application is shown; Figure 4 The schematic diagram of the principle of the optimistic parallel execution and verification process provided by the embodiment of the present application is shown. The method includes S110-S150.

[0090] S110: Obtain multiple transactions from the transaction pool.

[0091] When a user initiates a transaction, the transaction is broadcast to all nodes in the network. Each node will add the valid transactions it receives to its own transaction pool. The transaction pool is a temporary storage area where transactions wait to be processed. Block-producing nodes (miners) usually select transactions from the transaction pool based on the transaction fee, and transactions with higher fees are more likely to be obtained first.

[0092] Among multiple transactions, there may be ordinary transfer transactions that do not require the invocation of smart contracts, and there may also be transactions that require the invocation of smart contracts (such as token transfers, decentralized finance, cross-chain transactions, insurance contracts, participation in decentralized autonomous organizations, participation in decentralized financial applications, identity verification, etc.).

[0093] For example, 500 transactions are obtained from the transaction pool.

[0094] S120: Control the Ethereum virtual machine to execute multiple transactions in parallel in multiple threads.

[0095] like Figure 3 As shown, a distributor can be set in the block node to distribute transactions, and the distributor can be a functional module. A thread pool is also set in the block node, and there are multiple threads in the thread pool.

[0096] See also Figure 4 ,This embodiment distributes transactions to multiple threads and executes all transactions in parallel through optimistic parallel execution, thereby improving the transaction processing speed. Optimistic parallelism means that all transactions are processed in parallel assuming that there are no conflicts, so as to improve the throughput and response speed of the blockchain network.

[0097] For example, the distributor distributes 500 transactions to 10 threads in the thread pool for execution. Each thread can execute one transaction at a time. After the current transaction is executed, the distributor will distribute another transaction to the thread. Once a transaction is distributed to a specific thread, the thread starts executing the transaction. Each thread executes these transactions independently in its own virtual environment.

[0098] S130: According to the first transaction execution result of the Ethereum virtual machine executing multiple transactions in parallel in multiple threads, the dependency relationship between the multiple transactions is obtained; wherein the first transaction execution result is used to reflect that there is no conflict between the multiple transactions; the dependency relationship is the execution order of different transactions.

[0099] If transaction B needs to use the execution result of transaction A, then there is a dependency relationship between transaction A and transaction B. This dependency relationship means that transaction B must be executed only after transaction A is completed.

[0100] S140: Construct a transaction dependency view according to the dependency relationship between the multiple transactions; the transaction dependency view is used to reflect the parallel execution order between the multiple transactions that have been verified.

[0101] The transaction dependency view is a directed acyclic graph that records the parallel execution order between all transactions in a block.

[0102] S150: Treat multiple transactions and transaction dependencies as Figure 1 Packed into blocks.

[0103] By packaging the transaction dependency view and all transactions into a block, the verification node can analyze the parallel execution order of all transactions through the transaction dependency view, so that the verification node can execute transactions in parallel deterministically.

[0104] This embodiment executes all transactions in parallel to obtain non-conflicting dependencies between transactions, then constructs a transaction dependency view based on the dependencies, and adds the transaction dependency view together with all transactions to the block, so that the speed at which block-producing nodes process transactions is significantly improved, and the efficiency of block-producing nodes is greatly improved.

[0105] As an optional implementation, in S130, the dependency relationship between the multiple transactions is derived based on the multiple transactions executed in parallel by the Ethereum virtual machine in multiple threads, including S131-S133.

[0106] S131: Obtain the second transaction execution result of the Ethereum virtual machine executing multiple transactions in parallel in multiple threads.

[0107] S132: When the second transaction execution result indicates that there is a conflict between two or more transactions among the multiple transactions, the two or more transactions are distributed to threads in sequence for re-execution until there is no conflict between the multiple transactions, thereby obtaining a first execution result.

[0108] It is easy to understand that when the second transaction execution result indicates that there is no conflict between transactions in the multiple transactions, the second transaction execution result is equivalent to the first transaction execution result.

[0109] That is to say, there may be no conflict between the multiple transactions obtained. In this case, the execution order of multiple transactions in multiple threads is the dependency relationship between the multiple transactions. When there is a conflict between multiple transactions, the conflicting transactions are distributed to the thread pool in turn for re-execution, thereby adjusting the order in which the transactions enter the thread for execution.

[0110] Traditional serial execution of transactions means that each transaction is executed after the previous transaction is completed, and there will be no conflicts between transactions because the execution result of each transaction is based on the state of the previous transaction. However, if Ethereum adopts the method of parallel execution of transactions, it means that multiple transactions can be executed at the same time, and these transactions may read and write operations on the same state variable, resulting in inconsistent state or wrong results. In addition, when executing in parallel, different threads may process transactions in different orders. If the execution of transactions depends on a specific order, but the distributor distributes the transactions in the later order to the thread pool for execution first, or distributes multiple transactions to the thread for execution at the same time, it will cause conflicts in transactions.

[0111] For example, suppose the initial state is that the balance of account 1 is 20 ether. There are two transactions: Transaction A: Increase the balance of account 1 by 10 ether. Transaction B: Decrease the balance of account 1 by 5 ether. If it is executed sequentially: Transaction A is executed first, and the balance of account 1 becomes 30 ether. Then Transaction B is executed, and the balance of account 1 becomes 25 ether. The final state is that the balance of account 1 is 25 ether. If it is executed in parallel: Transaction A and Transaction B are distributed to two different threads for simultaneous execution. Thread 1 executes Transaction A, reads the balance of account 1 as 20 ether, then increases it by 10 ether, and prepares to write 30 ether. At the same time, Thread 2 executes Transaction B, reads the balance of account 1 as 20 ether, then decreases it by 5 ether, and prepares to write 15 ether. If these two threads try to write the state at the same time, the final result may be that the balance of account 1 is 15 or 30 ether, instead of 25 ether. This situation will cause conflicts between transactions. In this case, transaction B needs to be distributed to the thread for re-execution, so that transaction B can be executed after transaction A is completed.

[0112] S133: Obtain dependency relationships among multiple transactions according to the first execution result.

[0113] As an optional implementation, the method for determining whether conflicts exist between two or more transactions among the multiple transactions in S132 includes S134-S135.

[0114] S134: Each time a transaction is completed, the read-write set of the current transaction is written into a global key-value pair; the key of the global key-value pair is the identifier of the ledger state variable, and the value of the global key-value pair is the read-write set corresponding to the identifier of the state variable; the read-write set includes a read set and a write set.

[0115] In the process of executing transactions through the Ethereum virtual machine in a thread, changes to state variables in the ledger will be triggered. These state variable changes include changes to account balances, storage variables, or smart contract states. The changed state variables will be reflected in the ledger. By performing read and write operations on state variables, a read and write set about the variable can be formed. This read and write operation includes the following steps: Read state: Before the transaction is executed, the relevant state variables will first be read in the ledger to obtain the current state information. Execute logic: According to the read state, the logic in the contract is executed, which will modify some state variables. Write state: After execution is completed, the state variables in the ledger are updated and the new values ​​are written to the state tree.

[0116] During the parallel execution process, there will be a global key-value pair, where the key represents the identifier of the ledger state variable. In order to distinguish the state variables in a fine-grained manner, the identifier can be subdivided into a combination of account address + read-write type. The read-write type can be account balance, nonce value or account status. The subdivided read-write type can improve the accuracy of transaction read-write sets and avoid misidentification of transaction conflicts. The effect is more obvious in smart contract call transactions. The value of the key-value pair is a treemap (tree data structure), which stores the read-write results of the key in different executions of the same transaction and the read-write results of the key in different transactions.

[0117] For example, assume there are two smart contract transactions, transaction C and transaction D, both of which involve the balance of account 3.

[0118] Transaction C: Withdraw 100 ether from account 3.

[0119] Transaction D: Deposit 50 ETH into account 3.

[0120] During parallel execution, Ethereum will create two key-value pairs for these two transactions:

[0121] Key-value pair C: {Account 3 address + Account balance} -> {Result of extracting 100 units of currency};

[0122] Key-value pair D: {Account 3 address + Account balance} -> {Result of depositing 50 units of currency}.

[0123] S135: If the state variables in the read set of the current transaction overlap with the state variables in the write set of one or more transactions executed previously, it is determined that there is a conflict between the current transaction and the one or more transactions executed previously.

[0124] About overlap: For each state variable in the read set of the current transaction, check whether it exists in the write set of the previously executed transaction. If it does, it means that the current transaction depends on the result of the previously executed transaction and may cause a conflict.

[0125] Specifically, if a state variable is read in the current transaction and modified in the previous transaction, the state variables in the read set of the current transaction and the state variables in the write set of the previous transaction will overlap, and there will be a dependency relationship between the two transactions. Based on this dependency relationship, the correct execution order of the transactions can be determined, avoiding possible erroneous results caused by concurrent execution.

[0126] As an optional implementation, in S132, two or more transactions are distributed to the threads in sequence for re-execution until there is no conflict between the multiple transactions, and a first execution result is obtained, including S136 and S137.

[0127] S136: Mark the write set of the current transaction as pending data, and establish a dependency array between the current transaction and one or more transactions executed previously; when the subsequent transaction reads the pending data, the subsequent transaction is added to the corresponding dependency array.

[0128] S137: Distribute the conflicting transactions to the threads in sequence according to the dependency array, and distribute the latter transactions in the dependency array to the threads for execution only after the former transactions in the dependency array are executed and verified, until there is no conflict between the multiple transactions.

[0129] The dependency array is equivalent to the serial number that marks the execution order of transactions with dependencies.

[0130] There will be many temporary execution results of parallel execution of transactions. Those execution results are temporarily recorded in the key-value memory structure mentioned above. When all transaction execution verifications are completed, it means that the current execution results and dependencies of all transactions have been fixed and will not change. It is necessary to update these determined execution results (write operations to the ledger) to the final ledger and submit them. It can be considered that after submission, the changes of the block to the ledger are determined.

[0131] For example, suppose there is an Ethereum smart contract with a state variable called balance, which is used to record the account balance of a user. Now there are two transactions, transaction E and transaction F.

[0132] When transaction E is executed, the current value of balance is read and some operations (such as transfer) are prepared based on this value. At this time, assume that the value of balance is 100.

[0133] At the same time or after transaction E is executed, transaction F also attempts to execute. Transaction F also reads the value of balance and prepares to modify it based on this value (such as increase or decrease). Assume that the balance value read by transaction F is still 100 (before transaction E is executed).

[0134] Now, if transaction E completes first and updates the value of balance (for example, to 90 after the transfer), and transaction F continues to execute without knowing about this change, and operates based on the original value it reads (which is still 100), then the final result may produce a conflicting or inconsistent state. For example, if transaction F expects the account balance to be 100 and tries to deduct 10 units, the deduction operation is actually incorrect because the actual balance is no longer 100.

[0135] In this case, there is a dependency or conflict between the execution of transaction E and transaction F. The state read by transaction F is based on an outdated value (i.e. the value before transaction E was executed), which leads to incorrect results.

[0136] At this time, the write set of transaction F is marked as pending data and added to the dependency array of transaction E. For example, the dependency array of transaction F is [E], which means that transaction F will not be executed until transaction E is completed.

[0137] If transaction G and transaction F enter the thread at the same time when they are re-executed, the read result of transaction G is the write set when transaction F was first executed. The write set is marked as pending data, so transaction G needs to add the corresponding dependency array, that is, [E, F]. This means that transaction G will not be executed until transactions E and F are executed in sequence.

[0138] This embodiment verifies whether there are conflicts between completed transactions one by one, and distributes the conflicting transactions to threads for re-execution in sequence until multiple transactions (i.e., all transactions obtained in S110) are verified. Verification one by one means that after each transaction is executed, the current transaction is verified with all completed transactions. Figure 3 As shown, a validator can be designed in the block-producing node to implement the above verification process of S134-S137, and the validator can be a logic module.

[0139] As an optional implementation, before S120: controlling the Ethereum virtual machine to execute the multiple transactions in parallel in multiple threads, it also includes S111.

[0140] S111: Detect whether there are at least two transactions among the multiple transactions that are sent from the same account address; if there are at least two transactions among the multiple transactions that are sent from the same account address, the dependency relationship between the at least two transactions is determined according to the sequence of nonce values ​​corresponding to the at least two transactions.

[0141] Correspondingly, S120: controlling the Ethereum virtual machine to execute the multiple transactions in parallel in multiple threads, including: executing at least two transactions in sequence in one or more threads through the Ethereum virtual machine according to the dependency relationship between the at least two transactions; and executing transactions other than at least two transactions in the multiple transactions in parallel in multiple threads through the Ethereum virtual machine.

[0142] There is a natural dependency between at least two transactions sent from the same account address, and they cannot be executed in parallel. That is, one transaction must be completed before the next transaction can be executed. If multiple transactions sent from the same account address are executed in parallel, there will be conflicts between them. Figure 2 As shown, a conflict detector can be designed in the block producing node. The conflict detector can be a logic module, which is used to filter out at least two transactions sent from the same account address before the transaction is distributed to the thread, and inform the distributor of the nonce values ​​of at least two transactions.

[0143] The blockchain has a nonce value to mark the order of transactions sent by the same account address. An account address that has never sent a transaction must send transactions in the order of nonce 0, 1, 2, etc., otherwise it will be rejected. Therefore, the dependency between multiple transactions sent by the same account address can be determined based on the nonce value. The distributor will distribute multiple transactions to threads one by one for execution according to the order of nonce values.

[0144] In the embodiment of the present application, a conflict detector can be used to analyze the dependencies between some transactions, such as at least two transactions sent to the same account address, and the transaction dependencies of the remaining parts can be obtained after executing the transactions.

[0145] The block producing node of the embodiment of the present application executes all transactions in parallel, verifies and performs dependency analysis on the completed transactions, re-executes the conflicting transactions, and builds a transaction dependency view after the transaction verification is passed and adds it to the block together with all transactions, so that the speed of processing transactions by the block producing node is significantly improved, and the block producing efficiency of the block producing node is greatly improved.

[0146] As an optional implementation, after S150, S160 is also included.

[0147] S160: Add the block to the blockchain and submit the ledger generated after all transactions are verified.

[0148] After packaging the block, the block-producing nodes need to solve a Proof of Work (PoW) or Proof of Stake (PoS) problem to prove the computational work they have done to create a new block.

[0149] Each time a thread executes a transaction, the ledger will be updated once. For re-executed transactions, the ledger will be updated with the one that passed the verification. After the block-producing node submits its updated ledger, the verification node executes and verifies the transactions in the block, forming the verification node's ledger. By comparing the block-producing node's ledger with the verification node's ledger to see if they are consistent, it can be determined whether the block packaged by the block-producing node is valid.

[0150] It should be noted that the ledger obtained by the block-producing node in the embodiment of the present application is consistent with the ledger obtained by serial execution, that is, the ledger will not be inconsistent with the ledger of serial execution transactions due to parallel execution of transactions.

[0151] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0152] Corresponding to the blockchain transaction parallel execution method described in the above embodiment, Figure 5 A structural block diagram of a blockchain transaction parallel execution device provided in an embodiment of the present application is shown. For ease of explanation, only the parts related to the embodiment of the present application are shown.

[0153] Reference Figure 5 , the device comprises:

[0154] The acquisition module 210 is used to acquire multiple transactions from the transaction pool.

[0155] The parallel execution module 220 is used to control the Ethereum virtual machine to execute multiple transactions in parallel in multiple threads.

[0156] The determination module 230 is used to obtain the dependency relationship between the multiple transactions according to the first transaction execution result of the Ethereum virtual machine executing the multiple transactions in parallel in multiple threads, wherein the first transaction execution result is used to reflect that there is no conflict between the multiple transactions; the dependency relationship is the execution order between different transactions.

[0157] The construction module 240 is used to construct a transaction dependency view according to the dependency relationship between multiple verified transactions; the transaction dependency view is used to reflect the parallel execution order between the multiple verified transactions.

[0158] The packaging module 250 combines multiple transactions and transaction dependencies into Figure 1 Packed into blocks.

[0159] It should be noted that the information interaction, execution process, etc. between the above-mentioned devices / units are based on the same concept as the method embodiment of the present application. Their specific functions and technical effects can be found in the method embodiment part and will not be repeated here.

[0160] See also Figure 6-Figure 7 , Figure 6 A schematic flow chart of a method for parallel execution of blockchain transactions applied to a verification node provided in an embodiment of the present application is shown. Figure 7 The schematic diagram of the principle of the verification node provided by the embodiment of the present application is shown. The method includes S310-S340.

[0161] S310: Obtain the block packaged by the block-producing node; the block includes multiple transactions and transaction dependency views of the multiple transactions, and the transaction dependency view is used to reflect the parallel execution order between the multiple transactions.

[0162] Specifically, the block can be obtained through the above S110 - S150 .

[0163] The transaction dependency view is a directed acyclic graph that records the parallel execution order of all transactions in a block. The parallel execution order of all transactions can be analyzed in the conflict detector in the verification node based on the transaction dependency view.

[0164] S320: Distribute the multiple transactions to multiple threads according to the parallel execution order of the multiple transactions indicated by the transaction dependency view.

[0165] A distributor can be designed in the verification node to distribute transactions to multiple threads in the order of parallel execution of transactions. The number of threads in the verification node is the same as the number of threads in the block node.

[0166] For the distributor, the dependencies of all current transactions have been determined, and transactions can be directly distributed to threads in the thread pool for execution based on the dependencies of current transactions. It can be considered that there will be no conflicts in the execution of transactions between threads at this time, and the highest degree of parallelism can be achieved (the conflicting dependencies have been generated when the block-producing node is executed).

[0167] S330: Execute the multiple transactions in parallel in multiple threads through the Ethereum virtual machine.

[0168] S340: Submit the ledger generated after executing multiple transactions.

[0169] The verification node of the embodiment of the present application can achieve deterministic transaction parallelism by obtaining the transaction dependency view in the block, thereby greatly improving the transaction parallelism.

[0170] As an optional implementation manner, after S330, the method further includes:

[0171] S331: Verify one by one whether there are conflicts between the executed transactions, and distribute the conflicting transactions to threads in sequence for re-execution until multiple transactions are verified.

[0172] Generally, there will be no conflicts when the verification node is verifying. If there are conflicts between transactions, the conflicting transactions can be verified and re-executed according to the methods of S134-S137.

[0173] As an optional implementation, the method also includes S350-S360.

[0174] S350: Obtain the ledger submitted by the block-producing node.

[0175] S360: Compare the ledger submitted by the block-producing node with the ledger submitted by the verification node. If they are consistent, the block is determined to be valid; if they are inconsistent, the block is determined to be invalid.

[0176] Corresponding to the blockchain transaction parallel execution method described in the above embodiment, Figure 6 A structural block diagram of a blockchain transaction parallel execution device provided in an embodiment of the present application is shown. For ease of explanation, only the parts related to the embodiment of the present application are shown.

[0177] Reference Figure 8 , the device comprises:

[0178] The acquisition module 410 is used to obtain the block packaged by the block-producing node; the block includes multiple transactions and transaction dependency views of the multiple transactions, and the transaction dependency view is used to reflect the parallel execution order between the multiple transactions.

[0179] The distribution module 420 is used to distribute the multiple transactions to multiple threads according to the parallel execution order of the multiple transactions indicated by the transaction dependency view.

[0180] A parallel execution module 430, for executing multiple transactions in parallel in multiple threads through the Ethereum virtual machine;

[0181] The submission module 440 is used to submit the ledger generated after executing multiple transactions.

[0182] It should be noted that the information interaction, execution process, etc. between the above-mentioned devices / units are based on the same concept as the method embodiment of the present application. Their specific functions and technical effects can be found in the method embodiment part and will not be repeated here.

[0183] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0184] An embodiment of the present application also provides an electronic device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor implements the steps of any of the above-mentioned method embodiments when executing the computer program.

[0185] An embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0186] An embodiment of the present application provides a computer program product. When the computer program product runs on a mobile terminal, the mobile terminal can implement the steps in the above-mentioned method embodiments when executing the computer program product.

[0187] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, which can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may at least include: any entity or device capable of carrying the computer program code to an electronic device, a recording medium, a computer memory, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), an electric carrier signal, a telecommunication signal, and a software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk or an optical disk. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electric carrier signals and telecommunication signals.

[0188] The program code embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0189] The computer program code for performing the operation of the embodiment of the application can be written with one or more programming languages ​​or their combination, and the programming language includes object-oriented programming languages, such as python, Java, Smalltalk, C++, and also includes conventional procedural programming languages, such as "C" language or similar programming languages. The program code can be executed completely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on the remote computer, or executed completely on the remote computer or server. In the case of a remote computer, the remote computer can include a local area network (LAN) or a wide area network (WAN)--connected to the user's computer through any type of network, or, can be connected to an external computer (for example, utilizing an Internet service provider to connect through the Internet).

[0190] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

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

[0192] In the embodiments provided in the present application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0193] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0194] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A method for parallel execution of blockchain transactions, characterized in that: The method comprises: Get multiple transactions from the transaction pool; Controlling the Ethereum virtual machine to execute multiple transactions in parallel in multiple threads; According to the first transaction execution result of the Ethereum virtual machine executing the multiple transactions in parallel in the multiple threads, the dependency relationship between the multiple transactions is obtained, wherein the first transaction execution result is used to reflect that there is no conflict between the multiple transactions; the dependency relationship is the execution order between the different transactions; Constructing a transaction dependency view according to the dependency relationship between the multiple transactions; the transaction dependency view is used to reflect the parallel execution order between the multiple transactions that have been verified; The multiple transactions and the transaction dependency views are packaged together into a block.

2. The method for parallel execution of blockchain transactions according to claim 1, characterized in that: The dependency relationship between the multiple transactions is obtained based on the multiple transactions executed in parallel by the Ethereum virtual machine in multiple threads, including: Obtaining a second transaction execution result of the Ethereum virtual machine executing multiple transactions in parallel in multiple threads; When the second transaction execution result indicates that there are conflicts between two or more transactions among the multiple transactions, the two or more transactions are sequentially distributed to the threads for re-execution until there are no conflicts between the multiple transactions, thereby obtaining a first execution result; According to the first execution result, the dependency relationship between the multiple transactions is obtained.

3. The method for parallel execution of blockchain transactions according to claim 2, characterized in that: Determining that there is a conflict between two or more of the multiple transactions, including: Each time a transaction is executed, the read-write set for executing the current transaction is written into a global key-value pair; the key of the global key-value pair is the identifier of the ledger state variable, and the value of the global key-value pair is the read-write set corresponding to the identifier of the state variable; the read-write set includes a read set and a write set; If the state variables in the read set of the current transaction overlap with the state variables in the write set of one or more transactions executed previously, it is determined that there is a conflict between the current transaction and the one or more transactions executed previously.

4. The method for parallel execution of blockchain transactions according to claim 3, characterized in that: The step of distributing the two or more transactions to the threads in sequence for re-execution until there is no conflict between the transactions, and obtaining a first execution result, includes: Marking the write set of the current transaction as pending data, and establishing a dependency array between the current transaction and one or more transactions executed previously; when executing a subsequent transaction and reading the pending data, adding the subsequent transaction to the corresponding dependency array; The conflicting transactions are distributed to the threads in sequence according to the dependency array, and the transactions at the back of the dependency array are distributed to the threads for execution only after the transactions at the front of the dependency array are executed and verified, until there is no conflict between the multiple transactions.

5. The method for parallel execution of blockchain transactions according to any one of claims 1 to 4, characterized in that: Before controlling the Ethereum virtual machine to execute the multiple transactions in parallel in multiple threads, the method further includes: Detecting whether at least two of the multiple transactions are sent from the same account address; If at least two of the multiple transactions are sent from the same account address, the dependency relationship between the at least two transactions is determined according to the order of nonce values ​​corresponding to the at least two transactions; The controlling the Ethereum virtual machine to execute multiple transactions in parallel in multiple threads includes: According to the dependency relationship between at least two of the transactions, at least two of the transactions are executed sequentially in one or more of the threads by the Ethereum virtual machine; and transactions other than at least two of the transactions among the multiple transactions are executed in parallel in multiple threads by the Ethereum virtual machine.

6. A method for parallel execution of blockchain transactions, characterized in that: The method comprises: Obtaining a block; the block includes multiple transactions and transaction dependency views of the multiple transactions, and the transaction dependency view is used to reflect the parallel execution order between the multiple transactions; Distributing the multiple transactions to multiple threads according to the parallel execution order of the multiple transactions indicated by the transaction dependency view; Execute multiple transactions in parallel on multiple threads through the Ethereum virtual machine; Submit the ledger generated after executing multiple transactions described above.

7. The method for parallel execution of blockchain transactions according to claim 6, characterized in that: After executing the plurality of transactions in parallel on the plurality of threads through the Ethereum virtual machine, the method further includes: Verify one by one whether there are conflicts among the multiple transactions that have been executed, and distribute the transactions with conflicts to the threads in sequence for re-execution until the multiple transactions are verified; The ledger generated after executing multiple transactions is submitted, including: Submit the ledgers generated after the multiple transactions are verified.

8. The method for parallel execution of blockchain transactions according to claim 7, characterized in that: The step of verifying one by one whether there are conflicts between the completed transactions includes: Each time a transaction is executed, the read-write set for executing the current transaction is written into a global key-value pair; the key of the global key-value pair is the identifier of the ledger state variable, and the value of the global key-value pair is the read-write set corresponding to the identifier of the state variable; the read-write set includes a read set and a write set; If the state variables in the read set of the current transaction overlap with the state variables in the write set of one or more transactions executed previously, it is determined that there is a conflict between the current transaction and the one or more transactions executed previously.

9. The method for parallel execution of blockchain transactions according to claim 8, characterized in that: The step of distributing the conflicting transactions to the threads in sequence for re-execution until the plurality of transactions are verified, includes: Mark the write set of the current transaction as pending data, and establish a dependency array between the current transaction and one or more transactions executed previously; when the pending data is read by executing a subsequent transaction, the subsequent transaction is added to the corresponding dependency array; The conflicting transactions are distributed to the threads in sequence according to the dependency array, and the transactions at the back of the dependency array are distributed to the threads for execution and verification only after the transactions at the front of the dependency array are executed and verified, until multiple transactions are verified.

10. The method for parallel execution of blockchain transactions according to any one of claims 6 to 9, characterized in that: The method further comprises: Get the ledger submitted by the block-producing node; The ledger submitted by the block-producing node is compared with the ledger submitted by the verification node. If they are consistent, the block is determined to be valid; if they are inconsistent, the block is determined to be invalid.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 5 or 6 to 10 is implemented.

12. A blockchain system, comprising a block-producing node and multiple verification nodes, characterized in that: The block producing node is configured to execute the method according to any one of claims 1 to 5; The verification node is configured to execute the method according to any one of claims 6 to 10.

13. A computer program product, characterized in that When the computer program product runs on an electronic device, the electronic device is enabled to execute the method according to any one of claims 1 to 5 or 6 to 10.

Images