CN110689344B - Method and apparatus for concurrently executing transactions in a blockchain - Google Patents

Method and apparatus for concurrently executing transactions in a blockchain Download PDF

Info

Publication number
CN110689344B
CN110689344B CN201910816530.6A CN201910816530A CN110689344B CN 110689344 B CN110689344 B CN 110689344B CN 201910816530 A CN201910816530 A CN 201910816530A CN 110689344 B CN110689344 B CN 110689344B
Authority
CN
China
Prior art keywords
transaction
processed
task
buffer
waiting
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910816530.6A
Other languages
Chinese (zh)
Other versions
CN110689344A (en
Inventor
刘晓建
张兆勇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advanced New Technologies Co Ltd
Original Assignee
Advanced New Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Advanced New Technologies Co Ltd filed Critical Advanced New Technologies Co Ltd
Priority to CN201910816530.6A priority Critical patent/CN110689344B/en
Publication of CN110689344A publication Critical patent/CN110689344A/en
Application granted granted Critical
Publication of CN110689344B publication Critical patent/CN110689344B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/389Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/544Buffers; Shared memory; Pipes
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Exchange, e.g. stocks, commodities, derivatives or currency exchange

Abstract

The embodiment of the specification provides a method and a device for executing transactions in a blockchain concurrently, wherein the method is executed by a first executive in a first node in the blockchain and comprises the following steps: after predetermined operation is carried out in the process of processing the first transaction, a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed are recorded in the shared memory so as to enter a waiting process relative to the first transaction; determining whether a plurality of to-be-processed tasks which are recorded in the shared memory exist or not, wherein the plurality of to-be-processed tasks are recorded by the predetermined number of executors; and in the case that the waiting process corresponding to a second task to be processed is determined to be finished, continuing to execute the second task to be processed based on the execution information corresponding to the second task to be processed, wherein the plurality of tasks to be processed comprise the second task to be processed.

Description

Method and apparatus for concurrently executing transactions in a blockchain
Technical Field
The embodiments of the present disclosure relate to the field of blockchain technologies, and more particularly, to a method and an apparatus for concurrently executing transactions in a blockchain.
Background
The blockchain technology is a brand-new distributed infrastructure and computing paradigm that is built on a peer-to-peer (P2P) network, utilizes a chained data structure to verify and store data, utilizes a distributed node consensus algorithm to generate and update data, utilizes cryptography to ensure the security of data transmission and access, and utilizes an intelligent contract composed of automated script codes to program and operate data. The block chain technology is also called as distributed book technology, is decentralized distributed database technology and is characterized by decentralized, transparent disclosure, no tampering and trusty. Each data of the block chain is broadcasted to the block chain nodes of the whole network, and each whole node has the full amount of consistent data. The nodes in the blockchain perform services such as transfer and data storage by sending transactions, the accounting nodes in the blockchain collect the transactions in the blockchain in the transaction pool, execute the transactions, and package the transactions into blocks and spread the transactions into the blockchain after executing the transactions. The block sent from the accounting node is verified by a verification node in the block chain, and after the verification is passed, each node executes each transaction included in the block when receiving the block. In order to ensure the data consistency of each node, when executing multiple transactions in a block, the submission order of the multiple transactions in each node needs to be consistent, so that a consistent execution result can be obtained. Therefore, in the prior art, before executing a transaction, an accounting node numbers a plurality of transactions to be executed according to a predetermined rule, and sequentially executes the plurality of transactions according to the numbering order, that is, sequentially submits the plurality of transactions, and after receiving the block, other nodes also sequentially execute and submit the plurality of transactions according to the transaction numbering order. However, the multiple transactions are not necessarily all interdependent, and in the absence of a dependency between two transactions, concurrent execution of the two transactions does not affect the final result. And if there is dependency between two transactions executed concurrently, the concurrent execution will affect the final result.
Therefore, a more efficient method for concurrently performing multiple transactions in a blockchain is needed.
Disclosure of Invention
Embodiments of the present disclosure aim to provide a more efficient scheme for concurrently executing transactions, so as to solve the deficiencies in the prior art.
To achieve the above object, one aspect of the present specification provides a method for executing transactions concurrently in a blockchain, the method being executed at a first node in the blockchain, where the first node currently executes transactions concurrently through a preset predetermined number of executors, and the first node includes a first executor, and the method is executed by the first executor and includes:
after predetermined operation is carried out in the process of processing the first transaction, a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed are recorded in the shared memory so as to enter a waiting process relative to the first transaction;
determining whether a plurality of to-be-processed tasks which are recorded in the shared memory exist or not, wherein the plurality of to-be-processed tasks are recorded by the predetermined number of executors; and
and in the case that the waiting process corresponding to a second task to be processed is determined to be finished, continuing to execute the second task to be processed based on the execution information corresponding to the second task to be processed, wherein the plurality of tasks to be processed comprise the second task to be processed.
In one embodiment, the method further includes, in a case where it is determined that the waiting process of each of the plurality of pending tasks has not ended, obtaining a second transaction to be processed from a first buffer in the shared memory, and starting to execute the second transaction.
In an embodiment, the shared memory includes a second buffer, where, after a predetermined operation is performed in a process of processing the first transaction, recording a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed in the shared memory includes, after the first transaction is processed, in a case that it is determined that the second transaction is not submitted, recording the first task to be processed corresponding to the first transaction in the second buffer, where the second transaction is a transaction previous to the first transaction according to a predetermined submission order.
In one embodiment, for a plurality of pending tasks already recorded in the shared memory, determining whether there is a pending task in which the waiting process ends includes determining whether the waiting process of the pending task corresponding to the smallest transaction number in the second buffer ends based on the currently committed transaction recorded in the shared memory to determine whether there is a pending task in the second buffer waiting for the ending of the waiting process, where the transaction numbers correspond to the order of the commit of the transactions.
In one embodiment, in a case where it is determined that the waiting process corresponding to the second to-be-processed task is ended, continuing to execute the second to-be-processed task based on the execution information corresponding to the second to-be-processed task includes, in a case where it is determined that the waiting process of the second to-be-processed task in the second buffer is ended, continuing to execute the submission of the third transaction based on the execution information corresponding to the second to-be-processed task, where the second to-be-processed task corresponds to the third transaction.
In an embodiment, the shared memory includes a third buffer, and the first transaction includes a read operation on a first variable, where recording, in the shared memory, a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed after a predetermined operation is performed in a process of processing the first transaction includes recording, in the third buffer, the first task to be processed corresponding to the first transaction after a request for reading the first variable is made, where the first task to be processed includes recording the first variable.
In one embodiment, the third buffer includes the second to-be-processed task, the second to-be-processed task corresponds to a read operation of a second variable in a second transaction, and for a plurality of to-be-processed tasks already recorded in the shared memory, determining whether there is any to-be-processed task in which a waiting process ends includes determining whether a variable value of the second variable is returned, and in a case where it is determined that the variable value of the second variable is returned, determining that the waiting process of the second to-be-processed task ends.
In an embodiment, for a plurality of to-be-processed tasks already recorded in the shared memory, determining whether there is a to-be-processed task waiting for the completion of the process includes, for the plurality of to-be-processed tasks already recorded in the third buffer, sequentially determining whether the waiting process of each to-be-processed task is completed based on a sequence of transaction numbers corresponding to the to-be-processed tasks from small to large, where the second to-be-processed task is a first-determined to-be-processed task waiting for the completion of the process, where the transaction numbers correspond to a predetermined submission sequence of transactions.
In one embodiment, determining whether the variable value of the second variable is returned includes determining whether the variable value of the second variable is returned based on whether a predetermined address in a shared memory stores the variable value of the second variable, wherein the predetermined address corresponds to the second transaction.
In one embodiment, in a case where it is determined that the waiting process corresponding to the second to-be-processed task ends, continuing to execute the second to-be-processed task based on the execution information corresponding to the second to-be-processed task includes, in a case where it is determined that there is a second to-be-processed task waiting for the process to end in the third buffer, continuing to execute the second transaction based on the execution information corresponding to the second to-be-processed task and a variable value of the second variable.
In one embodiment, the shared memory includes a fourth buffer, the first transaction includes a read operation on a first variable, wherein, after the predetermined operation is carried out in the process of processing the first transaction, the first task to be processed corresponding to the first transaction and the execution information corresponding to the first task to be processed are recorded in the shared memory, after executing the code to the read operation, determining whether each transaction that is in a commit order prior to the first transaction and that is not committed is a conflicting transaction in which a write operation to the first variable has been performed, the respective transactions including a second transaction, in the case that the second transaction is determined to be a conflict transaction closest to the first transaction, recording a first to-be-processed task corresponding to the first transaction in a fourth buffer area, wherein the first to-be-processed task comprises recording of the second transaction.
In one embodiment, for the plurality of pending tasks already recorded in the shared memory, determining whether there is a pending task waiting for the end of the process includes determining whether there is a pending task waiting for the end of the process among the plurality of pending tasks recorded in the fourth buffer area based on a transaction recorded in the shared memory that should be currently submitted.
In one embodiment, the shared memory includes a fifth buffer, the first transaction includes a read operation on a first variable, wherein, after the predetermined operation is carried out in the process of processing the first transaction, the first task to be processed corresponding to the first transaction and the execution information corresponding to the first task to be processed are recorded in the shared memory, after executing the code to the read operation, inferring whether each transaction that precedes the first transaction in commit order and is uncommitted is a conflicting transaction to write the first variable, the transactions including a second transaction, in the case that the second transaction is inferred to be a conflict transaction closest to the first transaction, recording a first to-be-processed task corresponding to the first transaction in the fifth buffer area, wherein the first to-be-processed task comprises recording of the second transaction.
In an embodiment, the shared memory includes at least one buffer area, and the at least one buffer area corresponds to at least one type of task to be processed, respectively, where determining whether there is a task to be processed in which a waiting process ends includes determining whether there is a task to be processed in each buffer area in which a waiting process ends based on a predetermined sequence of the at least one buffer area.
Another aspect of the present specification provides an apparatus for concurrently executing transactions in a blockchain, the apparatus being deployed in a first executable in a first node in the blockchain, where the first node currently concurrently executes transactions through a preset predetermined number of executors, and including the first executable, and the first executable is currently processing the first transaction, the apparatus including:
the recording unit is configured to record a first to-be-processed task corresponding to a first transaction and execution information corresponding to the first to-be-processed task in a shared memory after a predetermined operation is performed in the process of processing the first transaction so as to enter a waiting process relative to the first transaction;
a determining unit configured to determine, for a plurality of to-be-processed tasks already recorded in the shared memory, whether there is a to-be-processed task in which a waiting process ends, the plurality of to-be-processed tasks being recorded by the predetermined number of executors; and
and a continuous execution unit configured to, in a case where it is determined that the waiting process corresponding to a second to-be-processed task is ended, continue to execute the second to-be-processed task based on execution information corresponding to the second to-be-processed task, where the plurality of to-be-processed tasks include the second to-be-processed task.
In one embodiment, the apparatus further includes a transaction execution unit configured to, in a case where it is determined that the waiting process of each of the plurality of tasks to be processed has not ended, obtain a second transaction to be processed from a first buffer in the shared memory, and start executing the second transaction.
In an embodiment, the shared memory includes a second buffer, and the recording unit is further configured to, after the first transaction is completed, in a case that it is determined that the second transaction is not submitted, record a first task to be processed corresponding to the first transaction in the second buffer, where the second transaction is a previous transaction of the first transaction according to a predetermined submission order.
In one embodiment, the determining unit is further configured to determine whether a waiting process of the to-be-processed task corresponding to the minimum transaction number in the second buffer area is finished based on the currently to-be-submitted transaction recorded in the shared memory, so as to determine whether the to-be-processed task waiting for the end of the process exists in the second buffer area, where the transaction numbers correspond to a submission order of the transactions.
In one embodiment, the execution continuation unit is further configured to, in a case where it is determined that the waiting process of the second to-be-processed task in the second buffer is ended, continue to perform the submission of the third transaction based on the execution information corresponding to the second to-be-processed task, where the second to-be-processed task corresponds to the third transaction.
In an embodiment, the shared memory includes a third buffer, and the first transaction includes a read operation on a first variable, where the recording unit is further configured to record a first to-be-processed task corresponding to the first transaction in the third buffer after requesting the read operation on the first variable, where the first to-be-processed task includes a record of the first variable.
In an embodiment, the second to-be-processed task is included in the third buffer, the second to-be-processed task corresponds to a read operation on a second variable in a second transaction, and the determining unit is further configured to determine whether a variable value of the second variable is returned, and in a case where it is determined that the variable value of the second variable is returned, determine that the waiting process of the second to-be-processed task is ended.
In an embodiment, the determining unit is further configured to, for a plurality of to-be-processed tasks already recorded in the third buffer, sequentially determine whether the waiting process of each to-be-processed task is finished based on a sequence of transaction numbers corresponding to the to-be-processed tasks from small to large, where the second to-be-processed task is a to-be-processed task in which the waiting process determined for the first time is finished, and the transaction numbers correspond to a predetermined submission sequence of transactions.
In one embodiment, the determination unit is further configured to determine whether a variable value of a second variable is returned based on whether a predetermined address in the shared memory stores the variable value of the second variable, wherein the predetermined address corresponds to the second transaction.
In one embodiment, the execution continuation unit is further configured to, in a case where it is determined that there is a second to-be-processed task waiting for the end of the process in the third buffer, continue to execute the second transaction based on execution information corresponding to the second to-be-processed task and a variable value of the second variable.
In an embodiment, a fourth buffer is included in the shared memory, wherein the recording unit is further configured to, after executing the code of the read operation, determine whether each transaction that is not submitted and whose submission order is prior to the first transaction is a conflict transaction in which a write operation on the first variable has been performed, the transactions including the second transaction, and in a case where it is determined that the second transaction is a conflict transaction closest to the first transaction, record a first to-be-processed task corresponding to the first transaction in the fourth buffer, where the first to-be-processed task includes a record of the second transaction.
In an embodiment, the determining unit is further configured to determine whether there is a pending task waiting for the end of the process among the plurality of pending tasks recorded in the fourth buffer area, based on the transaction recorded in the shared memory that should be currently submitted.
In an embodiment, the shared memory includes a fifth buffer area, the first transaction includes a read operation on the first variable, wherein the recording unit is further configured to, after executing the code to the read operation, infer whether each transaction that is not submitted and is in a sequence before the first transaction is a conflict transaction to be performed with a write operation on the first variable, the transactions include a second transaction, and in a case that the second transaction is inferred to be a conflict transaction closest to the first transaction, record a first to-be-processed task corresponding to the first transaction in the fifth buffer area, where the first to-be-processed task includes a record of the second transaction.
In an embodiment, the shared memory includes at least one buffer area, and the at least one buffer area corresponds to at least one task to be processed, respectively, where the determining unit is further configured to determine whether there is a task to be processed in each buffer area waiting for the end of the process based on a predetermined sequence of the at least one buffer area.
Another aspect of the present specification provides a computer-readable storage medium having stored thereon a computer program which, when executed on a computer, causes the computer to perform any of the methods described above.
Another aspect of the present specification provides a computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor implements any one of the above methods when executing the executable code.
According to the scheme for concurrently executing the transaction, when the executing body needs to wait in the transaction executing process, the processing information of the transaction is recorded, and other tasks to be processed or other transactions to be processed are obtained from the shared memory for processing, so that the waiting time of the executing body is reduced, and the overall speed of concurrent execution of the transaction is increased.
Drawings
The embodiments of the present specification may be made more clear by describing the embodiments with reference to the attached drawings:
FIG. 1 illustrates a block chain system in accordance with an embodiment of the present description;
FIG. 2 is a schematic diagram illustrating concurrent execution of transactions by multiple threads at various nodes in a blockchain;
FIG. 3 illustrates a flow diagram of a method of concurrently executing transactions in a blockchain, according to one embodiment of the present description;
fig. 4 illustrates an apparatus 400 for concurrently executing transactions in a blockchain according to one embodiment of the present description.
Detailed Description
The embodiments of the present specification will be described below with reference to the accompanying drawings.
Fig. 1 shows a block chain system according to an embodiment of the present disclosure. As shown in fig. 1, the system includes a plurality of nodes (6 nodes are schematically shown in the figure) forming a block chain, and the nodes are connected in pairs, wherein the nodes include, for example, a node 11, a node 12, and a node 13. As known to those skilled in the art, in a blockchain, some nodes collect multiple transactions in the blockchain into a transaction pool and compete for billing rights. For example, node 11 in the figure becomes the accounting node by acquiring accounting rights. Node 11, after becoming an accounting node, performs multiple transactions in its transaction pool and packages the multiple transactions into blocks for transmission to other nodes, such as node 12. Node 12 will authenticate the block and similarly perform transactions in the block. After a predetermined number of nodes verify the block, i.e., the block is known to be known, other nodes in the block chain (e.g., node 13) will not need to continue verifying the block, but will perform transactions directly in the block to update the local related data.
Fig. 2 shows a schematic diagram of transactions executed concurrently by multiple threads at various nodes in a blockchain. It is understood that the threads may be replaced by executables such as processes, coroutines, etc. As shown in fig. 2, in each node, generally, the number of CPUs is limited, and the number of preset threads is also fixed, for example, assuming that the number of CPUs of the node is 4, the number of threads preset in the thread pool is 6, so that 6 threads compete for preemption of the CPUs, and only after preemption of the CPUs, execution of the tasks in the task pool can be started.
In the process of executing multiple transactions concurrently by multiple threads, the multiple transactions may involve the calculation of multiple variables, in the case that two transactions do not involve the same variable, the execution order does not affect the final calculation result, and in the case that two transactions involve the same variable, the execution order affects the final calculation result. In the embodiment of the present specification, in order to ensure that the execution results of the plurality of transactions by the respective nodes are the same, conflicts of access variables between the transactions are considered while the plurality of transactions are concurrently executed, so that some of the threads executed in parallel need to go through a waiting process. Or may need to wait while waiting to return to access the store.
As shown in fig. 2, the shared memory of the first node is included, for example, a buffer 1 for indicating pending transactions is included, and the shared memory is readable and writable with respect to all threads. For example, 10 pending transactions 1, 2, … 10 are currently recorded in the first buffer, wherein the initial number of the bit boxes corresponding to the numbers 1, 2, …, 10 in the figure should be 1, which indicates that all transactions are pending, and the numbers of the transactions 1-10 correspond to the submission order of the respective transactions. After the transactions are executed concurrently, for example, the threads 1 to 4 seize the CPUs 1 to 4, respectively, so that the threads 1 to 4 can obtain one task from the first buffer respectively for processing, for example, the threads 1 to 4 start processing the transactions 1 to 4, respectively, and after the threads 1 to 4 start processing the transactions 1 to 4, the bits corresponding to the transactions 1 to 4 in the first buffer are modified to 0 respectively to indicate that the transactions have started to be executed. It will be appreciated that while the figure schematically illustrates thread 1 preempting CPU1 and executing transaction 1, thread 2 preempting CPU2 and executing transaction 2, etc., it will be understood that the illustration is for illustrative purposes only and that the thread number, CPU number, and transaction number do not correspond to one another, e.g., thread 1 may preempt CPU2, execute transaction 3, etc.
Also shown in fig. 2 are a plurality of buffers for recording tasks to be processed, buffers 2-5, wherein each buffer corresponds to a kind of waiting procedure. For example, buffer 2 corresponds to a waiting procedure for a transaction to commit after execution, buffer 3 corresponds to a waiting procedure for a request to read to wait for a return of a variable value, buffer 4 corresponds to a waiting procedure for a prior transaction to commit based on a variable write record before reading, and buffer 5 corresponds to a waiting procedure for a prior transaction to commit or write based on a transaction collision probability before reading. In this embodiment of the present specification, in order to concurrently execute a transaction, the process of executing the transaction includes a process of processing the transaction and a process of submitting the transaction, where the process of processing the transaction is to store a result of processing the transaction in a buffer corresponding to the transaction, and the process of submitting the transaction is to store a final result of processing in a shared memory shared by the transactions. For example, after the thread 3 processes the transaction 3, in order to ensure that the final results of executing each transaction are consistent, it is necessary to ensure that each transaction is submitted in sequence according to the numbering sequence, and therefore, the transaction 3 needs to wait for the submission of the previous transaction 2 before submitting the transaction. In this case, thread 3 records in buffer 2 at a location corresponding to transaction 3, e.g., changing the initial 0 to 1, and then thread 3 goes into the buffer to fetch the new task. For example, thread 3 may first check buffer 2 for tasks waiting for the process to end. The shared memory in fig. 2 also records a current transaction window, which may be maintained, for example, by a thread that has committed a transaction. For example, thread 1 may modify the first transaction in the transaction window to 2 after submitting transaction 1. Thus, the transaction window is shifted one bit back among the transactions to be submitted, and when the thread starts executing a new transaction (e.g., transaction 7) based on the window first, the last transaction in the transaction window may be updated from 6 to 7. At this point, for example, thread 3, after checking buffer 2, may first determine whether transaction 2 is the transaction that should currently be committed based on the window. In case there is no task waiting for the end of the process in the buffer 2, it can be checked whether there is a task waiting for the end of the process in the buffer 3, and so on. In the case where there is no task waiting for the process to end in any of the buffers 2-5, then a pending transaction, such as transaction 6, may be retrieved from buffer 1. When the thread 3 also encounters a waiting process in the process of executing the transaction 6, the corresponding to-be-processed task is recorded in a corresponding one of the buffers 2-5, for example, as shown by a dashed arrow on the right side in the figure, the thread 3 records the to-be-processed task corresponding to the transaction 6 in the buffer 4. Then, similarly, thread 3 first determines in buffers 2-5 whether there is a pending task waiting for the process to end.
It will be appreciated that the above description of FIG. 2 is intended to be illustrative, and not to limit the scope of the embodiments of the present description. For example, the specific form of the buffers 1 to 5 is not necessarily the form shown in the figure, as long as the corresponding information can be recorded. The process of concurrently executing transactions according to an embodiment of the present specification will be described in detail below.
Fig. 3 is a flowchart illustrating a method for concurrently executing transactions in a blockchain according to an embodiment of the present disclosure, where the method is executed at a first node in the blockchain, where a first executable is preset in the first node, and the first executable is currently processing a first transaction, and the method is executed by the first executable, and includes:
step S302, after performing a predetermined operation in a process of processing a first transaction, recording a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed in a shared memory, so as to enter a waiting process with respect to the first transaction;
step S304, determining whether a plurality of tasks to be processed which are recorded in the shared memory exist in the shared memory or not, wherein the tasks to be processed wait for the completion of the process exist; and
step S306, in a case that it is determined that the waiting process corresponding to the second task to be processed is ended, continuing to execute the second task to be processed based on the execution information corresponding to the second task to be processed, where the plurality of tasks to be processed includes the second task to be processed.
First, in step S302, after a predetermined operation is performed during processing of a first transaction, a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed are recorded in a shared memory, so as to enter a waiting process with respect to the first transaction.
As described above with reference to fig. 2, the first executable may be, for example, a thread, a process, a coroutine, etc. execution entity, and the shared memory is shared with respect to multiple executors for concurrently executing transactions. The following description will be given by taking a thread as an example.
In the process of concurrently executing transactions in a node, for one of the transactions being executed, a plurality of waiting processes may be included, which may be due to different reasons.
In one embodiment, as described above with reference to fig. 2, the plurality of concurrently executed transactions have a preset submission order, for example, the transactions 1 to 10 in fig. 2 must be submitted sequentially according to the descending order of their numbers, so as to ensure that the execution results of the plurality of transactions by each node are the same. Here, in the node, when a thread executes a transaction, the processing result is first stored in a buffer corresponding to only the transaction, and after the transaction is committed, the execution result is stored in a shared memory shared by the transactions. For example, in the process of processing a first transaction, a write operation needs to be performed on a first variable, and a value of the first variable after the write operation is first saved in a buffer corresponding to the first transaction, and the value can be used only when the first transaction is processed, and the value is not read or written when other transactions are processed. After the first transaction is submitted, the value of the first transaction is stored in the shared memory, and other transactions may read the value or modify the value by submitting it.
Since the transactions have a predetermined commit order, as shown in FIG. 2, for example, the first transaction is transaction 6 in FIG. 2, then the first executable is thread 3 in the figure. If the transaction prior to transaction 6 has not been committed after thread 3 has processed transaction 6, then thread 3 needs to wait for transaction 5 to commit to transaction 6 before it can proceed. Here, thread 3 may determine whether transaction 5 commits based on transaction window parameters preset in shared memory. The transaction window controls the maximum total number of the transactions which can be executed concurrently, and the two sides of the transaction window are respectively the transaction with the minimum number and the transaction with the maximum number which are executed concurrently currently, for example, 1 and 6 in fig. 2 indicate that the transactions which are executed concurrently currently are transactions 1 to 6. Thus, by determining whether transaction 5 is the smallest transaction in the transaction window, it is determined whether transaction 5 should currently be committed. In this case, the thread 3 may modify the bit corresponding to the transaction 6 in the buffer 2 to 1 as shown in fig. 2, so as to add a to-be-processed task corresponding to the transaction 6, which can continue to be executed only after the transaction 5 is submitted, and at the same time, may store the execution information corresponding to the to-be-processed task, that is, the current processing information of the transaction 6, into the execution information buffer corresponding to each transaction in the shared memory, for example.
In one embodiment, transaction 6 includes a read operation for variable k1, thread 3, after starting execution of the code of the read operation, issues a read request for variable k1 to the hardware or thread used to read the variable, and then records "k 1" in the byte corresponding to transaction 6 in buffer 3 shown in fig. 2 to add a pending task corresponding to transaction 6 that continues execution until the value of variable k1 returns.
In one embodiment, transaction 6 includes a read operation to variable k1, and thread 3, after starting execution of the code for the read operation, queries a write buffer in the shared memory that records the writes to the variables (including variable k1) during the current processing of the transactions. For example, the write buffer only records the writes of transaction 4 to variable k1, and does not record the writes of transaction 5 to variable k 1. Since, based on this record, transaction 4 will change the value of k1 in the variable table in shared memory after committing, transaction 6 needs to read the value of the variable k1 after waiting for transaction 4 to commit, otherwise the wrong value of k1 will be read. After the check of the write buffer is performed, thread 3 records "4" in the byte corresponding to transaction 6 in buffer 3 in fig. 2 to add a pending task corresponding to transaction 6, where "4" corresponds to transaction 4, indicating that the pending task may not continue to be executed until transaction 4 is committed.
In one embodiment, transaction 6 includes a read operation to variable k 1. Thread 3, after starting execution of the code for the read operation, infers whether each transaction (e.g., transactions 1-5 in FIG. 2) that was committed sequentially before transaction 6, of the plurality of transactions being executed concurrently, is to write to variable k 1. In one method, transaction conflict probabilities of the variables may be determined in advance based on transaction execution histories in the node, when the transaction conflict probability of the variable k1 is greater than a predetermined threshold, it may be inferred that all transactions 1-5 will write to the variable k1, and thus, it is necessary to wait for transaction 5 to commit before performing a read operation in transaction 6, and if transaction 5 writes the write value to k1 in the process into a buffer corresponding to transaction 5 in the shared memory (the buffer is not a variable table corresponding to each transaction), it may wait for transaction 5 to complete the write to k1 before performing a read operation to k 1. In one approach, thread 3 may determine a probability of conflict for transaction 6 with each preceding transaction based on transaction data for each preceding transaction 6, and infer whether each transaction is to write to k1 based on the probability of conflict, thereby determining whether to wait for the transaction to commit or write. For example, in the case where it is determined that the probability of writing transaction 4 to k1 is greater than or equal to the predetermined threshold and the probability of writing transaction 5 to k1 is less than the predetermined threshold, thread 3 records "4" in the byte corresponding to transaction 6 in buffer 5 in FIG. 2 to record a pending task corresponding to transaction 6 that may continue to execute only after transaction 4 is committed or written.
Although four waiting cases have been enumerated above, the waiting cases in the embodiment of the present specification are not limited to the above-described four cases, but may be any waiting case triggered by a predetermined operation.
In step S304, it is determined whether there is a pending task in which the waiting process ends, for the multiple pending tasks already recorded in the shared memory.
As mentioned above, the shared memory includes the buffers 2-5, in which different types of tasks to be processed are recorded. For example, after the thread 3 stores the first task to be processed corresponding to the transaction 6 in the shared memory through the step S302, the thread 3 checks the buffers 2-5 in the shared memory in a predetermined order for acquiring the task to be processed in which the waiting process is finished. It is understood that, in fig. 2, the pending tasks in the buffers 2-5 may be the pending tasks recorded by any one of the threads 1-4.
For example, thread 3 may first check buffer 2. As described above, each of the pending tasks recorded in the buffer 2 corresponds to processing a transaction that is completed waiting for submission. For example, as shown in fig. 2, in the buffer 2, it may be determined that the minimum transaction with the corresponding bit of 1 is transaction 2, the thread 3 may determine whether the transaction that should be currently submitted is transaction 2 based on the transaction window in the shared memory, if the transaction that should be currently submitted is transaction 2, it indicates that the waiting process of the task to be processed corresponding to transaction 2 is ended, and the thread 3 may obtain the execution information corresponding to transaction 2 from the buffer in the shared memory for storing the transaction execution information, and continue to execute transaction 2 based on the execution information, i.e., perform submission of transaction 2.
In case thread 3 finds no pending task in buffer 2 waiting for the end of the process, thread 3 may check buffer 3, for example. As described above, each of the tasks to be processed recorded in the buffer 3 is waiting for the return of the corresponding variable value. For example, "k 2" is recorded in the byte in buffer 3 corresponding to transaction 2, indicating that transaction 2 is waiting for the return of the value of variable k 2. Thread 3 may determine whether the value of k2 has been written from a predetermined address in the shared memory corresponding to transaction 2, which corresponds to transaction 2, in which case the value of k2 is written, indicating the end of the waiting process for the pending task corresponding to transaction 2. Wherein the value of k2 may be written to at this address by other threads performing read operations. In the event that it is determined that the value of k2 has not been written, it may be determined whether the waiting process has ended for the pending task following transaction 2. For example, "k 1" is recorded in the byte corresponding to transaction 3, it may be determined whether the value of k1 has been written at a predetermined address corresponding to transaction 3.
In case thread 3 finds no pending task waiting for the end of the process in both buffers 2 and 3, thread 3 may check buffer 4, for example. As described above, the pending tasks recorded in the buffer 4 correspond to transactions that wait for other transactions to commit for a read operation based on a write situation. Similarly to checking the buffer 2, the thread 3 may determine, for example, whether transaction 1, which transaction 2 waits, is committed based on the transaction window in the shared memory, in which case the waiting process for the pending task corresponding to transaction 2 ends, in case it is determined that transaction 1 is committed. In the event that it is determined that transaction 1 is not committed, thread 3 may determine whether the waiting process for the pending task corresponding to the transaction following transaction 2 is complete, e.g., may determine whether the waiting process corresponding to transaction 3 is complete.
In case thread 3 finds no pending task waiting for the end of the process in buffers 2-4, thread 3 may check buffer 5, for example. As described above, the pending tasks recorded in the buffer 5 correspond to transactions waiting for other transactions to commit or write for a read operation based on the probability of collision. Thread 3 may similarly determine whether transaction 1, on which transaction 2 is waiting, is committed, or may determine whether the waiting process for the pending task corresponding to transaction 2 is finished based on the variable value that transaction 1 writes in shared memory during processing.
It is understood that the buffers 2-5 included in the shared memory are only illustrative and not restrictive, the sequence of checking the buffers is only illustrative and not restrictive, and in a specific implementation, the buffers and the sequence of checking the buffers may be set according to the needs of a scene.
In one embodiment, in the case that no pending task waiting for the end of the process is detected in any of the buffers 2-5, the thread 3 may detect the buffer 1 in the shared memory shown in fig. 2, and the pending transaction is recorded in the buffer 1, so that the thread 3 may obtain the pending transaction (e.g., transaction 6) with the smallest number from the buffer 1 and start executing the transaction.
In step S306, in a case that it is determined that there is a second to-be-processed task waiting for the completion of the process in the shared memory, the second to-be-processed task is continuously executed based on the execution information corresponding to the second to-be-processed task.
In one embodiment, the thread 3 acquires the second to-be-processed task waiting for the end of the process in the buffer 2, and the thread 3 continues to perform the submission of the transaction corresponding to the second to-be-processed task based on the corresponding execution information. After determining that the waiting process of the second to-be-processed task is finished, the thread 3 removes the corresponding second to-be-processed task in the buffer, for example, modifies "1" corresponding to the second to-be-processed task in the buffer 2 to 0.
In one embodiment, the thread 3 acquires the second to-be-processed task in the buffer 3, and the thread 3 continues to execute the operation subsequent to the read operation in the corresponding transaction based on the corresponding execution information and the value of the corresponding variable.
In one embodiment, the thread 3 acquires the second pending task in the buffer 4, and the thread 3 continues to perform the corresponding read operation in the corresponding transaction based on the corresponding execution information.
In one embodiment, the thread 3 acquires the second pending task in the buffer 5, and the thread 3 continues to perform the corresponding read operation in the corresponding transaction based on the corresponding execution information.
Fig. 4 shows another aspect of the present specification, which provides an apparatus 400 for concurrently executing transactions in a blockchain, the apparatus being deployed in a first executable in a first node in the blockchain, where the first node currently concurrently executes transactions through a preset predetermined number of executors, and the first executable includes a first executable, and the first executable is currently processing a first transaction, and the apparatus includes:
a recording unit 41, configured to, after a predetermined operation is performed in a process of processing a first transaction, record a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed in a shared memory, so as to enter a waiting process with respect to the first transaction;
a determining unit 42 configured to determine, for a plurality of to-be-processed tasks already recorded in the shared memory, whether there is a to-be-processed task in which a waiting process ends, the plurality of to-be-processed tasks being recorded by the predetermined number of executors; and
and a continuing execution unit 43, configured to, in a case that it is determined that the waiting process corresponding to a second task to be processed is ended, continue to execute the second task to be processed based on the execution information corresponding to the second task to be processed, where the plurality of tasks to be processed includes the second task to be processed.
In one embodiment, the apparatus further includes a transaction executing unit 44 configured to, in a case where it is determined that the waiting process of each of the plurality of tasks to be processed has not ended, obtain a second transaction to be processed from a first buffer in the shared memory, and start executing the second transaction.
In an embodiment, the shared memory includes a second buffer, where the recording unit 41 is further configured to, after the first transaction is completed, in a case that it is determined that the second transaction is not submitted, record a first task to be processed corresponding to the first transaction in the second buffer, where the second transaction is a previous transaction of the first transaction according to a predetermined submission order.
In one embodiment, the determining unit 42 is further configured to determine whether the waiting process of the to-be-processed task corresponding to the minimum transaction number in the second buffer is finished based on the currently to-be-submitted transaction recorded in the shared memory, so as to determine whether there is a to-be-processed task waiting for the end of the process in the second buffer, where the transaction numbers correspond to the submission order of the transactions.
In one embodiment, the execution continuation unit 43 is further configured to, in a case where it is determined that the waiting process of the second to-be-processed task in the second buffer is ended, continue to perform the submission of the third transaction based on the execution information corresponding to the second to-be-processed task, where the second to-be-processed task corresponds to the third transaction.
In an embodiment, the shared memory includes a third buffer, and the first transaction includes a read operation on a first variable, where the recording unit 41 is further configured to record a first task to be processed corresponding to the first transaction in the third buffer after the read operation on the first variable is requested, where the first task to be processed includes recording of the first variable.
In an embodiment, the second to-be-processed task is included in the third buffer, the second to-be-processed task corresponds to a read operation on a second variable in a second transaction, and the determining unit 42 is further configured to determine whether a variable value of the second variable is returned, and in a case where it is determined that the variable value of the second variable is returned, determine that the waiting process of the second to-be-processed task is ended.
In one embodiment, the determining unit 42 is further configured to, for a plurality of to-be-processed tasks already recorded in the third buffer, sequentially determine whether the waiting process of each to-be-processed task is finished based on the order of transaction numbers corresponding to the to-be-processed tasks from small to large, where the second to-be-processed task is a to-be-processed task at which the waiting process that is determined for the first time is finished, and the transaction numbers correspond to a predetermined submission order of transactions.
In one embodiment, the determining unit 42 is further configured to determine whether a variable value of a second variable is returned based on whether a predetermined address in the shared memory stores the variable value of the second variable, wherein the predetermined address corresponds to the second transaction.
In one embodiment, the execution continuation unit 43 is further configured to, in a case where it is determined that there is a second to-be-processed task waiting for the end of the process in the third buffer, continue to execute the second transaction based on the execution information corresponding to the second to-be-processed task and the variable value of the second variable.
In an embodiment, the shared memory includes a fourth buffer area, the first transaction includes a read operation on the first variable, wherein the recording unit 41 is further configured to, after executing the code of the read operation, determine whether each transaction that is not submitted and whose submission order is prior to the first transaction is a conflict transaction in which a write operation on the first variable has been performed, the transactions include a second transaction, and in a case that it is determined that the second transaction is a conflict transaction closest to the first transaction, record a first task to be processed corresponding to the first transaction in the fourth buffer area, where the first task to be processed includes a record of the second transaction.
In one embodiment, the determining unit 42 is further configured to determine whether there is a pending task waiting for the end of the process in the plurality of pending tasks recorded in the fourth buffer area based on the transaction recorded in the shared memory that should be currently submitted.
In an embodiment, the shared memory includes a fifth buffer area, the first transaction includes a read operation on the first variable, wherein the recording unit 41 is further configured to, after executing the code of the read operation, infer whether each transaction that is not submitted and whose submission order is prior to the first transaction is a conflict transaction to be performed with a write operation on the first variable, the transactions include a second transaction, and in a case that the second transaction is inferred to be a conflict transaction closest to the first transaction, record a first task to be processed corresponding to the first transaction in the fifth buffer area, where the first task to be processed includes a record of the second transaction.
In an embodiment, the shared memory includes at least one buffer area, and the at least one buffer area corresponds to at least one type of task to be processed, respectively, where the determining unit 42 is further configured to determine whether there is a task to be processed in each buffer area that waits for the completion of the process based on a predetermined sequence of the at least one buffer area.
Another aspect of the present specification provides a computer-readable storage medium having stored thereon a computer program which, when executed on a computer, causes the computer to perform any of the methods described above.
Another aspect of the present specification provides a computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor implements any one of the above methods when executing the executable code.
According to the scheme for concurrently executing the transaction, when the executing body needs to wait in the transaction executing process, the processing information of the transaction is recorded, and other tasks to be processed or other transactions to be processed are obtained from the shared memory for processing, so that the waiting time of the executing body is reduced, and the overall speed of concurrent execution of the transaction is increased.
It is to be understood that the terms "first," "second," and the like, herein are used for descriptive purposes only and not for purposes of limitation, to distinguish between similar concepts.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
It will be further appreciated by those of ordinary skill in the art that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, computer software, or combinations of both, and that the components and steps of the examples have been described in a functional general in the foregoing description for the purpose of illustrating clearly the interchangeability of hardware and software. Whether these functions are performed in hardware or software depends on the particular application of the solution and design constraints. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied in hardware, a software module executed by a processor, or a combination of the two. A software module may reside in Random Access Memory (RAM), memory, Read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
The above-mentioned embodiments are intended to illustrate the objects, technical solutions and advantages of the present invention in further detail, and it should be understood that the above-mentioned embodiments are merely exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims (28)

1. A method for concurrently executing transactions in a blockchain, the method being executed at a first node in the blockchain, the first node currently concurrently executing transactions through a preset predetermined number of executors, the predetermined number of executors including a first executor, the first executor currently processing a first transaction, the method being executed by the first executor, comprising:
after predetermined operation is carried out in the process of processing the first transaction, a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed are recorded in the shared memory so as to enter a waiting process relative to the first transaction; the shared memory comprises a second buffer area, wherein after a preset operation is carried out in the process of processing the first transaction, recording a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed in the shared memory comprises recording the first task to be processed corresponding to the first transaction in the second buffer area in the case of determining that the second transaction is not submitted after the first transaction is processed, wherein the second transaction is the previous transaction of the first transaction according to a preset submission sequence;
determining whether a plurality of to-be-processed tasks which are recorded in the shared memory exist or not, wherein the plurality of to-be-processed tasks are recorded by the predetermined number of executors; and
and in the case that the waiting process corresponding to a second task to be processed is determined to be finished, continuing to execute the second task to be processed based on the execution information corresponding to the second task to be processed, wherein the plurality of tasks to be processed comprise the second task to be processed.
2. The method of claim 1, further comprising, in the event that it is determined that the waiting process for each of the plurality of pending tasks has not ended, retrieving a second transaction to be processed from a first buffer in shared memory and beginning execution of the second transaction.
3. The method of claim 1, wherein determining whether there are pending tasks in which a waiting process ends for a plurality of pending tasks already recorded in the shared memory comprises determining whether the waiting process for the pending task in the second buffer corresponding to a minimum transaction number corresponding to a commit order of transactions ends to determine whether there are pending tasks in the second buffer waiting for a process end based on transactions recorded in the shared memory that should currently be committed.
4. The method of claim 3, wherein in an instance in which it is determined that the waiting process corresponding to a second pending task is ended, continuing to execute the second pending task based on the execution information corresponding to the second pending task comprises, in an instance in which it is determined that the waiting process for the second pending task in the second buffer is ended, continuing to execute the submission of a third transaction based on the execution information corresponding to the second pending task, wherein the second pending task corresponds to the third transaction.
5. The method of claim 1, wherein the shared memory includes a third buffer, and the first transaction includes a read operation of the first variable, and wherein recording a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed in the shared memory after performing a predetermined operation during processing of the first transaction includes recording a first task to be processed corresponding to the first transaction in the third buffer after requesting the read operation of the first variable, and wherein the first task to be processed includes recording the first variable.
6. The method according to claim 5, wherein the second to-be-processed task is included in the third buffer, the second to-be-processed task corresponding to a read operation for a second variable in a second transaction, and for the plurality of to-be-processed tasks that have been recorded in the shared memory, determining whether there is any to-be-processed task in which a waiting process ends includes determining whether a variable value of the second variable is returned, and in a case where it is determined that the variable value of the second variable is returned, determining that the waiting process of the second to-be-processed task ends.
7. The method according to claim 6, wherein determining whether there are pending tasks in which a waiting process ends for the pending tasks already recorded in the shared memory comprises, for the pending tasks already recorded in the third buffer, sequentially determining whether the waiting process of each pending task ends based on an order of transaction numbers corresponding to each pending task from small to large, wherein the second pending task is the pending task for which the waiting process is first determined to end, and wherein the transaction numbers correspond to a predetermined submission order of transactions.
8. The method of claim 6, wherein determining whether a variable value of the second variable is returned comprises determining whether a variable value of the second variable is returned based on whether a predetermined address in a shared memory stores the variable value of the second variable, wherein the predetermined address corresponds to the second transaction.
9. The method of claim 6, wherein in the event that it is determined that the waiting process corresponding to a second pending task is finished, continuing to execute the second pending task based on the execution information corresponding to the second pending task comprises, in the event that it is determined that there is a second pending task in the third buffer that is waiting for the process to be finished, continuing to execute the second transaction based on the execution information corresponding to the second pending task and a variable value of the second variable.
10. The method of claim 1, wherein a fourth buffer is included in the shared memory, wherein the first transaction includes a read operation on a first variable, wherein, after the predetermined operation is carried out in the process of processing the first transaction, the first task to be processed corresponding to the first transaction and the execution information corresponding to the first task to be processed are recorded in the shared memory, after executing the code to the read operation, determining whether each transaction that is in a commit order prior to the first transaction and that is not committed is a conflicting transaction in which a write operation to the first variable has been performed, the respective transactions including a second transaction, in the case that the second transaction is determined to be a conflict transaction closest to the first transaction, recording a first to-be-processed task corresponding to the first transaction in a fourth buffer area, wherein the first to-be-processed task comprises recording of the second transaction.
11. The method of claim 10, wherein determining whether there are pending tasks in which to wait for the process to end for the plurality of pending tasks already recorded in the shared memory comprises determining whether there are pending tasks in the plurality of pending tasks recorded in the fourth buffer that are to wait for the process to end based on transactions recorded in the shared memory that are currently due to commit.
12. The method of claim 1, wherein a fifth buffer is included in the shared memory, wherein the first transaction includes a read operation on a first variable, wherein, after the predetermined operation is carried out in the process of processing the first transaction, the first task to be processed corresponding to the first transaction and the execution information corresponding to the first task to be processed are recorded in the shared memory, after executing the code to the read operation, inferring whether each transaction that precedes the first transaction in commit order and is uncommitted is a conflicting transaction to write the first variable, the transactions including a second transaction, in the case that the second transaction is inferred to be a conflict transaction closest to the first transaction, recording a first to-be-processed task corresponding to the first transaction in the fifth buffer area, wherein the first to-be-processed task comprises recording of the second transaction.
13. The method according to claim 1, wherein the shared memory includes at least one buffer area, and the at least one buffer area corresponds to at least one type of to-be-processed task, respectively, and wherein, for the plurality of to-be-processed tasks already recorded in the shared memory, determining whether there is a to-be-processed task waiting for the end of the process includes determining whether there is a to-be-processed task waiting for the end of the process in each buffer area based on a predetermined order of the at least one buffer area.
14. An apparatus for concurrently executing transactions in a blockchain, the apparatus being deployed in a first executable in a first node in the blockchain, the first node currently concurrently executing transactions through a preset predetermined number of executors, wherein the apparatus comprises the first executable, and the first executable is currently processing a first transaction, the apparatus comprising:
the recording unit is configured to record a first to-be-processed task corresponding to a first transaction and execution information corresponding to the first to-be-processed task in a shared memory after a predetermined operation is performed in the process of processing the first transaction so as to enter a waiting process relative to the first transaction; the shared memory comprises a second buffer area, wherein after a preset operation is carried out in the process of processing the first transaction, recording a first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed in the shared memory comprises recording the first task to be processed corresponding to the first transaction in the second buffer area in the case of determining that the second transaction is not submitted after the first transaction is processed, wherein the second transaction is the previous transaction of the first transaction according to a preset submission sequence;
a determining unit configured to determine, for a plurality of to-be-processed tasks already recorded in the shared memory, whether there is a to-be-processed task in which a waiting process ends, the plurality of to-be-processed tasks being recorded by the predetermined number of executors; and
and a continuous execution unit configured to, in a case where it is determined that the waiting process corresponding to a second to-be-processed task is ended, continue to execute the second to-be-processed task based on execution information corresponding to the second to-be-processed task, where the plurality of to-be-processed tasks include the second to-be-processed task.
15. The apparatus according to claim 14, further comprising a transaction execution unit configured to, in a case where it is determined that the waiting process of each of the plurality of pending tasks has not ended, retrieve a second transaction to be processed from a first buffer in the shared memory and start executing the second transaction.
16. The apparatus according to claim 14, wherein the determining unit is further configured to determine whether a waiting process of the to-be-processed task in the second buffer corresponding to the minimum transaction number is finished based on the currently to-be-submitted transaction recorded in the shared memory to determine whether there is a to-be-processed task in the second buffer waiting for the completion of the process, wherein the transaction numbers correspond to a submission order of the transactions.
17. The apparatus according to claim 16, wherein the execution continuation unit is further configured to, in a case where it is determined that the waiting process of the second to-be-processed task in the second buffer is ended, continue to perform the submission of the third transaction based on the execution information corresponding to the second to-be-processed task, wherein the second to-be-processed task corresponds to the third transaction.
18. The apparatus according to claim 14, wherein a third buffer is included in the shared memory, and the first transaction includes a read operation of a first variable, wherein the recording unit is further configured to record a first to-be-processed task corresponding to the first transaction in the third buffer after the read operation of the first variable is requested, and wherein the first to-be-processed task includes a record of the first variable.
19. The apparatus according to claim 18, wherein the second to-be-processed task is included in the third buffer, the second to-be-processed task corresponding to a read operation of a second variable in a second transaction, and the determination unit is further configured to determine whether a variable value of the second variable is returned, and in a case where it is determined that the variable value of the second variable is returned, determine that the waiting process of the second to-be-processed task is ended.
20. The apparatus according to claim 19, wherein the determining unit is further configured to sequentially determine, for a plurality of to-be-processed tasks already recorded in the third buffer, whether the waiting process of each to-be-processed task is ended based on an order of transaction numbers corresponding to the to-be-processed tasks from small to large, wherein the second to-be-processed task is a to-be-processed task at which the waiting process determined for the first time is ended, and wherein the transaction numbers correspond to a predetermined submission order of transactions.
21. The apparatus of claim 19, wherein the determination unit is further configured to determine whether a variable value of a second variable is returned based on whether a predetermined address in a shared memory stores the variable value of the second variable, wherein the predetermined address corresponds to the second transaction.
22. The apparatus of claim 19, wherein the execution continuation unit is further configured to, in a case where it is determined that there is a second to-be-processed task waiting for a process to end in the third buffer, continue execution of the second transaction based on execution information corresponding to the second to-be-processed task and a variable value of the second variable.
23. The apparatus according to claim 14, wherein a fourth buffer is included in the shared memory, the first transaction includes a read operation on the first variable, wherein the recording unit is further configured to determine, after executing the code to the read operation, whether each transaction that is not submitted and whose submission order is prior to the first transaction is a conflict transaction in which a write operation on the first variable has been performed, the transactions include a second transaction, and in a case where it is determined that the second transaction is a conflict transaction closest to the first transaction, record a first to-be-processed task corresponding to the first transaction in the fourth buffer, wherein the first to-be-processed task includes a record of the second transaction.
24. The apparatus according to claim 23, wherein the determining unit is further configured to determine whether there is a pending task waiting for the end of the process among the plurality of pending tasks recorded in the fourth buffer based on a transaction recorded in the shared memory that should be currently submitted.
25. The apparatus according to claim 14, wherein a fifth buffer is included in the shared memory, the first transaction includes a read operation on the first variable, wherein the recording unit is further configured to infer, after executing the code to the read operation, whether each transaction that is not submitted and whose submission order is prior to the first transaction is a conflicting transaction to be written on the first variable, the transactions include a second transaction, and in a case where the second transaction is inferred to be a closest conflicting transaction to the first transaction, record a first to-be-processed task corresponding to the first transaction in the fifth buffer, wherein the first to-be-processed task includes a record of the second transaction.
26. The apparatus according to claim 14, wherein the shared memory includes at least one buffer area, and the at least one buffer area corresponds to at least one type of to-be-processed task, respectively, and wherein the determining unit is further configured to determine whether there is to-be-processed task waiting for the end of the process in each buffer area based on a predetermined order of the at least one buffer area.
27. A computer-readable storage medium, on which a computer program is stored which, when executed in a computer, causes the computer to carry out the method of any one of claims 1-14.
28. A computing device comprising a memory and a processor, wherein the memory has stored therein executable code that, when executed by the processor, performs the method of any of claims 1-14.
CN201910816530.6A 2019-08-30 2019-08-30 Method and apparatus for concurrently executing transactions in a blockchain Active CN110689344B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910816530.6A CN110689344B (en) 2019-08-30 2019-08-30 Method and apparatus for concurrently executing transactions in a blockchain

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN202110621493.0A CN113435885A (en) 2019-08-30 2019-08-30 Method and apparatus for concurrently executing transactions in a blockchain
CN201910816530.6A CN110689344B (en) 2019-08-30 2019-08-30 Method and apparatus for concurrently executing transactions in a blockchain
TW109110266A TWI732501B (en) 2019-08-30 2020-03-26 Method and device for parallel execution of transactions in block chain, computer readable storage medium and computing equipment
PCT/CN2020/082696 WO2021036259A1 (en) 2019-08-30 2020-04-01 Method and device for executing transactions in parallel in blockchain

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN202110621493.0A Division CN113435885A (en) 2019-08-30 2019-08-30 Method and apparatus for concurrently executing transactions in a blockchain

Publications (2)

Publication Number Publication Date
CN110689344A CN110689344A (en) 2020-01-14
CN110689344B true CN110689344B (en) 2021-04-09

Family

ID=69107726

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202110621493.0A Pending CN113435885A (en) 2019-08-30 2019-08-30 Method and apparatus for concurrently executing transactions in a blockchain
CN201910816530.6A Active CN110689344B (en) 2019-08-30 2019-08-30 Method and apparatus for concurrently executing transactions in a blockchain

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN202110621493.0A Pending CN113435885A (en) 2019-08-30 2019-08-30 Method and apparatus for concurrently executing transactions in a blockchain

Country Status (3)

Country Link
CN (2) CN113435885A (en)
TW (1) TWI732501B (en)
WO (1) WO2021036259A1 (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113435885A (en) * 2019-08-30 2021-09-24 创新先进技术有限公司 Method and apparatus for concurrently executing transactions in a blockchain
CN112991061A (en) * 2020-10-28 2021-06-18 支付宝(杭州)信息技术有限公司 Method and apparatus for concurrently executing transactions in a blockchain

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106406896A (en) * 2016-09-27 2017-02-15 北京天德科技有限公司 Block chain block-building method based on parallel PipeLine technology
CN107688999A (en) * 2017-08-11 2018-02-13 杭州秘猿科技有限公司 A kind of parallel transaction based on block chain performs method
US20180158034A1 (en) * 2016-12-07 2018-06-07 International Business Machines Corporation Dynamic reordering of blockchain transactions to optimize performance and scalability
CN108804112A (en) * 2018-05-22 2018-11-13 上海分布信息科技有限公司 A kind of block chain falls account processing method and system
CN109636384A (en) * 2018-10-26 2019-04-16 阿里巴巴集团控股有限公司 A kind of parallelization executes the method, apparatus and system of block chain transaction
CN109784930A (en) * 2019-02-18 2019-05-21 深圳市网心科技有限公司 A kind of processing method, device, electronic equipment and the medium of block chain transaction data

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180218343A1 (en) * 2017-01-30 2018-08-02 Dais Technology, Inc. Smart contract execution on a blockchain
CN107453896B (en) * 2017-06-27 2020-08-04 创新先进技术有限公司 Method and device for processing multiple block chain network data and server
US10984134B2 (en) * 2017-07-14 2021-04-20 Microsoft Technology Licensing, Llc Blockchain system for leveraging member nodes to achieve consensus
CN107562775B (en) * 2017-07-14 2020-04-24 创新先进技术有限公司 Data processing method and device based on block chain
US10761877B2 (en) * 2017-07-21 2020-09-01 Intel Corporation Apparatuses, methods, and systems for blockchain transaction acceleration
CN107592292B (en) * 2017-07-26 2019-08-09 阿里巴巴集团控股有限公司 A kind of block chain communication method between nodes and device
CN107590738A (en) * 2017-08-24 2018-01-16 阿里巴巴集团控股有限公司 Processing method, device and the server of selection common recognition node
CN107704269A (en) * 2017-10-16 2018-02-16 中国银行股份有限公司 A kind of method and system based on block chain generation block
CN108537543A (en) * 2018-03-30 2018-09-14 百度在线网络技术(北京)有限公司 Method for parallel processing, device, equipment and the storage medium of block chain data
CN108681565B (en) * 2018-04-28 2020-11-10 百度在线网络技术(北京)有限公司 Block chain data parallel processing method, device, equipment and storage medium
CN110009316A (en) * 2018-12-14 2019-07-12 阿里巴巴集团控股有限公司 Event-handling method and device, electronic equipment based on block chain
CN110020856B (en) * 2019-01-31 2020-06-05 阿里巴巴集团控股有限公司 Method, node and storage medium for realizing mixed transaction in block chain
CN110011981B (en) * 2019-03-15 2021-06-29 湖北工程学院 Trusted cloud storage method and system based on block chain
CN110135985B (en) * 2019-04-04 2021-07-27 杭州抖音科技有限公司 Parallel execution method and system for transactions on block chain
CN113222752A (en) * 2019-04-12 2021-08-06 创新先进技术有限公司 Data processing system, method, computing device and storage medium based on block chain
CN110147273A (en) * 2019-05-17 2019-08-20 深圳前海微众银行股份有限公司 A kind of task executing method and device
CN110163609A (en) * 2019-05-28 2019-08-23 深圳前海微众银行股份有限公司 Data processing method and device in a kind of block chain
CN113435885A (en) * 2019-08-30 2021-09-24 创新先进技术有限公司 Method and apparatus for concurrently executing transactions in a blockchain

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106406896A (en) * 2016-09-27 2017-02-15 北京天德科技有限公司 Block chain block-building method based on parallel PipeLine technology
US20180158034A1 (en) * 2016-12-07 2018-06-07 International Business Machines Corporation Dynamic reordering of blockchain transactions to optimize performance and scalability
CN107688999A (en) * 2017-08-11 2018-02-13 杭州秘猿科技有限公司 A kind of parallel transaction based on block chain performs method
CN108804112A (en) * 2018-05-22 2018-11-13 上海分布信息科技有限公司 A kind of block chain falls account processing method and system
CN109636384A (en) * 2018-10-26 2019-04-16 阿里巴巴集团控股有限公司 A kind of parallelization executes the method, apparatus and system of block chain transaction
CN109784930A (en) * 2019-02-18 2019-05-21 深圳市网心科技有限公司 A kind of processing method, device, electronic equipment and the medium of block chain transaction data

Also Published As

Publication number Publication date
CN113435885A (en) 2021-09-24
TW202109512A (en) 2021-03-01
CN110689344A (en) 2020-01-14
WO2021036259A1 (en) 2021-03-04
TWI732501B (en) 2021-07-01

Similar Documents

Publication Publication Date Title
CN110675255B (en) Method and apparatus for concurrently executing transactions in a blockchain
CN110689344B (en) Method and apparatus for concurrently executing transactions in a blockchain
US8473950B2 (en) Parallel nested transactions
Timnat et al. Wait-free linked-lists
CN110648124B (en) Method and apparatus for concurrently executing transactions in a blockchain
US10416925B2 (en) Distributing computing system implementing a non-speculative hardware transactional memory and a method for using same for distributed computing
Feldman et al. A wait-free multi-word compare-and-swap operation
TWI730690B (en) Method and device for simultaneously executing transactions in block chain, computer readable storage medium and computing equipment
JPH0773087A (en) Method for recovery of file state in data processing system
JPH06222936A (en) Method for update of value of shared variable
CN110704112B (en) Method and apparatus for concurrently executing transactions in a blockchain
CN111047449A (en) Method and device for executing transaction in block chain
KR20170132873A (en) Method for processing database transactions in a distributed computing system
US20120059997A1 (en) Apparatus and method for detecting data race
CN110706108B (en) Method and apparatus for concurrently executing transactions in a blockchain
Peng et al. Fa-stack: A fast array-based stack with wait-free progress guarantee
CN112561695B (en) Method and apparatus for concurrently executing transactions in a blockchain
US20090064141A1 (en) Efficient utilization of transactions in computing tasks
TWI743719B (en) Method and device for simultaneously executing transactions in block chain, computer readable storage medium and computing equipment
CN112001798B (en) Method and apparatus for concurrently executing transactions in a blockchain
CN112487096A (en) Block transaction execution method and device
CN110515707A (en) Certainty concurrency control method and system based on preparatory issued transaction

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right

Effective date of registration: 20200925

Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Applicant after: Innovative advanced technology Co.,Ltd.

Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Applicant before: Advanced innovation technology Co., Ltd

Effective date of registration: 20200925

Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Applicant after: Advanced innovation technology Co., Ltd

Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands

Applicant before: Alibaba Group Holding Ltd.

TA01 Transfer of patent application right
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40028291

Country of ref document: HK

GR01 Patent grant
GR01 Patent grant