CN110706101B - 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
CN110706101B
CN110706101B CN201910816544.8A CN201910816544A CN110706101B CN 110706101 B CN110706101 B CN 110706101B CN 201910816544 A CN201910816544 A CN 201910816544A CN 110706101 B CN110706101 B CN 110706101B
Authority
CN
China
Prior art keywords
transaction
variable
transactions
read
field
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
CN201910816544.8A
Other languages
Chinese (zh)
Other versions
CN110706101A (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
Advantageous 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 CN201910816544.8A priority Critical patent/CN110706101B/en
Priority to CN202110839216.7A priority patent/CN113570460A/en
Publication of CN110706101A publication Critical patent/CN110706101A/en
Priority to TW109110259A priority patent/TWI730690B/en
Priority to PCT/CN2020/082454 priority patent/WO2021036253A1/en
Application granted granted Critical
Publication of CN110706101B publication Critical patent/CN110706101B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources

Abstract

The embodiment of the present specification provides a method for executing multiple transactions concurrently in a blockchain, where the multiple transactions have a predetermined submission order and include a first transaction, and the method is executed at a first node in the blockchain, where the first node is pre-provisioned with a variable access table, and the variable access table includes a write field corresponding to a first variable, where the write field is used to record execution of a write operation on the first variable in the multiple transactions, and the method includes: for each prior transaction, determining, based on the written word segment: whether a write operation to the first variable in the prior transaction has been performed, wherein the prior transaction is a transaction in the plurality of transactions that was committed sequentially before the first transaction; and performing a read operation of the first variable in a first transaction based on the determination.

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 multiple 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 are directed to a method for performing multiple transactions concurrently in a blockchain, which is more efficient and solves the deficiencies of the prior art.
To achieve the above object, an aspect of the present specification provides a method for concurrently executing multiple transactions in a blockchain, where the multiple transactions have a predetermined submission order and include a first transaction, and the method is executed at a first node in the blockchain, where the first node is pre-configured with a variable access table, and the variable access table includes a write field corresponding to a first variable, where the write field is used to record execution of a write operation on the first variable in the multiple transactions, and the method includes:
for each prior transaction, determining, based on the written word segment: whether a write operation to the first variable in the prior transaction has been performed, wherein the prior transaction is a transaction in the plurality of transactions that was committed sequentially before the first transaction; and
based on the determination, a read operation of the first variable in a first transaction is performed.
In one embodiment, the variable access table is stored locally, wherein performing a read operation on the first variable in a first transaction based on the determination comprises performing a read operation on the first variable in a first transaction if it is determined, for each previous transaction, that a write operation on the first variable was not performed based on the write field.
In one embodiment, performing the read operation for the first variable in the first transaction based on the determination includes, for a second transaction of the plurality of transactions that precedes the first transaction in order of submission, waiting with respect to the first transaction to perform the read operation for the first variable in the first transaction after the submission of the second transaction in the event that it is determined based on the write field that the write operation for the first variable in the second transaction has been performed.
In one embodiment, the variable access table is stored locally, wherein for each prior transaction, based on the write field, it is determined: whether a write operation to the first variable in the prior transaction has been performed includes sending a report to local dedicated hardware requesting the dedicated hardware to make the determination,
performing a read operation of the first variable in a first transaction based on the determination comprises performing a read operation of the first variable in a first transaction while sending the report, and determining whether to re-perform the first transaction based on the determination received from the dedicated hardware before committing the first transaction.
In one embodiment, the variable access table is stored in a dedicated server, wherein for each prior transaction, based on the write field, it is determined: whether a write operation to the first variable in the prior transaction has been performed includes sending a report to the dedicated server requesting the dedicated server to make the determination,
performing a read operation of the first variable in the first transaction based on the determination result includes requesting the dedicated server to perform the read operation of the first variable in the first transaction while sending the report, and determining whether to re-perform the first transaction based on the determination result received from the dedicated server before submitting the first transaction.
In one embodiment, the variable access table further includes a read field corresponding to the first variable, the read field being used to record execution of a read operation on the first variable in the plurality of transactions, and the method further includes, after executing the read operation on the first variable in the first transaction, modifying the read field accordingly.
In one embodiment, the read field includes a plurality of bits corresponding to the plurality of transactions, respectively, wherein modifying the read field accordingly includes modifying bits in the read field corresponding to the first transaction accordingly.
In one embodiment, the plurality of transactions further comprises a second transaction, wherein the order of submission of the second transaction is first in the plurality of transactions, the second transaction comprising a write operation to the first variable, in which case the second transaction is submitted after the read field is modified accordingly, the method further comprising,
determining, based on the read field, whether a read operation to the first variable in a first transaction has been performed;
in an instance in which it is determined that the read of the first variable in the first transaction has been performed, notifying local re-execution of the read of the first variable in the first transaction.
In one embodiment, the plurality of transactions further includes a third transaction, wherein the order of submission of the third transaction is between the first transaction and the second transaction, the method further comprising:
after receiving locally a notification to re-execute a read operation on the first variable in a first transaction, determining whether a write operation on the first variable in a third transaction has been performed based on the write word segment;
in the case where it is determined that the write operation in the third transaction has been performed, a wait is made to re-perform the read operation on the first variable in the first transaction after the write operation on the first variable in the third transaction is committed.
In one embodiment, the predetermined number of bits included in the write field corresponds to a predetermined number of transactions, respectively, the method further comprising, after committing the second transaction, restoring a first value of the bits in the write field corresponding to the second transaction, wherein the first value is used to record: a write operation to the first variable in the second transaction has been performed.
In one embodiment, the predetermined number of bits included in the read field corresponds to a predetermined number of transactions, respectively, the second transaction further includes a read operation on the first field, and the method further includes, after the second transaction is committed, restoring a first value of the bits in the read field corresponding to the second transaction, wherein the first value is used to record: a read operation to the first variable in the second transaction has been performed.
In one embodiment, a transaction execution window is preset in the first node, and the transactions are transactions currently included in the transaction execution window, wherein the number of the transactions is less than or equal to the predetermined number, and the method further includes, after submitting the second transaction, moving the transaction execution window backward by one transaction among the transactions included in the first node and arranged in a predetermined submission order.
In one embodiment, the variable access table further includes a first global variable for indicating a location of the transaction execution window.
In one embodiment, the variable access table further includes a serial number field corresponding to the first variable for indicating the transaction batch corresponding to the first variable.
In one embodiment, the variable access table includes a key corresponding to the first variable, where the key is a hash value of the first variable.
Another aspect of the present specification provides an apparatus for concurrently executing multiple transactions in a blockchain, where the multiple transactions have a predetermined commit order and include a first transaction, the apparatus is disposed in a first node in the blockchain, the first node is pre-provisioned with a variable access table, and the variable access table includes a write field corresponding to a first variable, where the write field is used to record execution of a write operation on the first variable in the multiple transactions, and the apparatus includes:
a first determining unit configured to determine, for each preceding transaction, based on the written word segment: whether a write operation to the first variable in the prior transaction has been performed, wherein the prior transaction is a transaction in the plurality of transactions that was committed sequentially before the first transaction; and
an execution unit configured to execute a read operation of the first variable in a first transaction based on the determination result.
In one embodiment, the variable access table is stored locally, wherein the execution unit is further configured to perform a read operation on the first variable in a first transaction in the event that, for each previous transaction, it is determined based on the write field that a write operation on the first variable was not performed.
In one embodiment, the execution unit is further configured to, for a second transaction of the plurality of transactions that is submitted sequentially before the first transaction, wait with respect to the first transaction in the event that it is determined, based on the write field, that a write operation to the first variable in the second transaction has been performed to perform a read operation to the first variable in the first transaction after the second transaction is submitted.
In one embodiment, the variable access table is stored locally, wherein the first determination unit is further configured to send a report to local dedicated hardware to request the dedicated hardware to make the determination, the execution unit is further configured to execute a read operation of the first variable in a first transaction while sending the report, and determine whether to re-execute the first transaction based on a determination result received from the dedicated hardware before submitting the first transaction.
In one embodiment, the variable access table is stored in a dedicated server, wherein the first determining unit is further configured to send a report to the dedicated server requesting the dedicated server to make the determination,
the execution unit is further configured to execute a read operation of the first variable in a first transaction while sending the report, and determine whether to re-execute the first transaction based on a determination result received from the dedicated server before submitting the first transaction.
In one embodiment, the variable access table further includes a read field corresponding to the first variable, the read field is used for recording execution of a read operation on the first variable in the multiple transactions, and the apparatus further includes a modification unit configured to modify the read field accordingly after the read operation on the first variable in the first transaction is executed.
In one embodiment, the read field comprises a plurality of bits corresponding to the plurality of transactions, respectively, wherein the modification unit is further configured to modify the bits in the read field corresponding to the first transaction accordingly.
In one embodiment, the plurality of transactions further comprises a second transaction, wherein the order of submission of the second transaction is first in the plurality of transactions, the second transaction comprising a write operation to the first variable, the apparatus further comprising, in the event that the second transaction is submitted after the read field is modified accordingly,
a second determination unit configured to determine whether a read operation for the first variable in a first transaction has been performed based on the read field;
and the notification unit is configured to notify local re-execution of the read operation on the first variable in the first transaction in the case that the read operation on the first variable in the first transaction is determined to be executed.
In one embodiment, the plurality of transactions further includes a third transaction, wherein the third transaction is submitted in an order between the first transaction and the second transaction, the apparatus further comprising:
a third determination unit configured to, after receiving a notification from a local to re-execute a read operation for the first variable in the first transaction, determine whether a write operation for the first variable in a third transaction has been executed based on the write word segment;
and a waiting unit configured to wait, in a case where it is determined that the write operation in the third transaction has been performed, to re-perform the read operation for the first variable in the first transaction after the write operation for the first variable in the third transaction is committed.
In one embodiment, the predetermined number of bits included in the write field corresponds to a predetermined number of transactions, respectively, the apparatus further comprises a first restoring unit configured to restore, after committing the second transaction, a first value of a bit in the write field corresponding to the second transaction, wherein the first value is used to record: a write operation to the first variable in the second transaction has been performed.
In one embodiment, the predetermined number of bits included in the read field corresponds to a predetermined number of transactions, respectively, the second transaction further includes a read operation on the first field, and the apparatus further includes a second restoring unit configured to restore, after the second transaction is committed, a first value of the bit corresponding to the second transaction in the read field, where the first value is used for recording: a read operation to the first variable in the second transaction has been performed.
In one embodiment, a transaction execution window is preset in the first node, and the transactions are transactions currently included in the transaction execution window, wherein the number of the transactions is less than or equal to the preset number, and the apparatus further includes a window moving unit configured to, after the second transaction is submitted, move the transaction execution window backward by one transaction among the transactions included in the first node and arranged in a preset submission order.
Another aspect of the present specification provides a computer readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform any one of the above methods.
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 executing the transactions concurrently in the block chain, the variable access table is used for recording the read-write operation of the same variable executed by a plurality of transactions concurrently executed in the transaction execution window, so that the transactions can be executed concurrently for a plurality of transactions without mutual dependency, and the transactions can be executed serially for a plurality of transactions with mutual dependency, so that the processing speed is increased and the processing performance is improved while the consistency of the calculation results is ensured.
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 blockchain system in accordance with embodiments of the present description;
FIG. 2 illustrates a flow diagram of a method of concurrently executing multiple transactions in a blockchain in accordance with an embodiment of the present description;
FIG. 3 illustrates an entry in the variable access table of FIG. 1 corresponding to a first variable;
FIG. 4 shows a schematic diagram of a transaction execution window in accordance with an embodiment of the present description;
fig. 5 illustrates an apparatus 5000 for concurrently performing multiple transactions in a blockchain according to an 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.
The multiple transactions may involve the calculation of multiple variables, the order of execution of which does not affect the final calculation in the case where the same variable is not involved in both transactions, and the order of execution of which would affect the final calculation in the case where the same variable is involved in both transactions. Therefore, in the embodiment of the present specification, in order to ensure that the execution results of the plurality of transactions by each node are the same, a respective variable access table, such as the variable access table 11, the variable access table 12, and the variable access table 13 corresponding to the node 11, the node 12, and the node 13 in the figure, is preset in each node. The variable access table includes entries of variables involved in a plurality of transactions, and includes, in the entries of the variables, execution records of the variables by the respective transactions. For example, as shown enlarged in the variable access table 11 for the node 11 in the figure, the variable access table includes k1，k2,…knEtc. and k1，k2,…knRespectively corresponding write field, read field, window position (field) and sequence number (field). Wherein k is1，k2,…knRespectively keys (keys) corresponding to respective variables included in the plurality of transactions, for example hash values of the respective variables, n may take a larger value, for example 100 ten thousand. It is composed ofThe write field is used for recording write operations executed by executors corresponding to the respective transactions on the corresponding variables, and the read field is used for recording read operations executed by the executors corresponding to the respective transactions on the corresponding variables, where the executors may be any of threads, processes, and coroutines, for example. In the embodiment of the present specification, since the number of transactions is large, the transaction execution window may be set, that is, a plurality of transactions in the transaction execution window are currently executed only concurrently. In this case, as shown in the drawing, a window position in the variable access table is used to indicate a position of the current transaction execution window, and the value of the window position field may be acquired based on a global variable preset corresponding to the window position. The serial number is a transaction batch number.
Therefore, when a plurality of transactions in the block (for example, a plurality of transactions in the transaction execution window) are executed, the plurality of transactions without mutual dependency relationship can be executed concurrently by referring to the variable access table, and the plurality of transactions with mutual dependency relationship can be executed serially by re-reading, waiting and the like, so that the calculation results of all nodes are ensured to be consistent, and meanwhile, partial transactions are executed concurrently, the processing time is saved, and the calculation efficiency is improved.
It should be understood that the above description of FIG. 1 is intended to be illustrative, and not limiting, of the scope of the embodiments of the present disclosure. For example, the variable access table is not limited to the table shown in fig. 1, but may be changed as needed. For example, the variable access table does not necessarily include a window position field and a sequence number field, etc. The process of concurrently executing transactions according to an embodiment of the present specification will be described in detail below.
Fig. 2 is a flowchart illustrating a method for concurrently executing multiple transactions in a blockchain, where the multiple transactions have a predetermined submission order and include a first transaction, and the method is executed at a first node in the blockchain, where the first node is pre-configured with a variable access table, and the variable access table includes a write field corresponding to a first variable, where the write field is used to record execution of a write operation on the first variable in the multiple transactions, and the method includes:
step S202, for each prior transaction, determining, based on the written word segment: whether a write operation to the first variable in the prior transaction has been performed, wherein the prior transaction is a transaction in the plurality of transactions that was committed sequentially before the first transaction; and
step S204, based on the determination result, executing the read operation of the first variable in the first transaction.
As described above with reference to fig. 1, the method is performed at a node in the blockchain. The node performs commit on the associated transactions either while packaging the block or after receiving the newly generated block. For example, thousands of transactions may be included in a block, and the thousands may involve hundreds of variables, where multiple transactions may access different variables, or multiple transactions may access the same variable. In the prior art, in the accounting node, the respective transaction numbers of a plurality of transactions to be packed into one block have been determined according to predetermined rules, and the order of the transaction numbers indicates the execution order and the submission order of the transactions. In this specification, in order to make the final calculation result the same as the serial calculation result in the prior art, a predetermined submission order is reserved for multiple transactions in the block, that is, the number order of each transaction is used as its respective submission order, and meanwhile, based on a variable access table preset by each node, each transaction without dependency can be executed concurrently, and each transaction with dependency is executed serially according to the sequence of its number, where, for the transactions 1 and 2 numbered sequentially, if the first variable is written in the transaction 1 and read in the transaction 2, the transaction 2 depends on the result of the transaction 1.
Fig. 3 illustrates an entry in the variable access table of fig. 1 corresponding to a first variable. As shown in fig. 3, the first variable corresponds to, for example, k1 in the variable access table, and k1 is a key value of the first variable, which is, for example, a hash value of the first variable. It is to be understood that k1 is not limited to being a hash value of the first variable, but may also be any identification of the first variable. In the variable access table, the fields corresponding to k1 include the following fields corresponding to the first variable: a write field, a read field, a window position field, and a sequence number field. Wherein both the write field and the read field comprise a predetermined number of bits (only 6 bits are schematically shown in the figure), for example 64 bits, which number should be equal to or greater than the maximum number of concurrently executed transactions in the block chain, so that each transaction executed concurrently can uniquely correspond to a bit in this field. As shown in fig. 3, the initial value of each bit in the write field and the read field is 0. The write field is used for recording whether each write operation included in a plurality of concurrently executed transactions is executed or not, and the read field is used for recording whether each read operation included in the plurality of concurrently executed transactions is executed or not. For example, in a write field, for a predetermined number of concurrently executed transactions (e.g., 5 transactions), its corresponding bit in 64 bits may be determined by taking its transaction number modulo 64. That is, for memory saving, the read/write field is configured as a circular buffer, so that multiple transactions can use the read/write field, for example, access information of 64 transactions can be recorded in the read/write field at most, so that transaction 1 and transaction 65 can be recorded using the same location. In a bit in the write field corresponding to, for example, the first transaction, when the first transaction does not perform a write operation on the first variable, the value in the bit corresponding to the first transaction is 0, and after the first transaction performs a write operation on the first variable, the value in the bit may be modified to 1. In this embodiment, performing a write operation on a variable means performing the write operation in a local memory without performing an actual write operation on the variable. The values of the bits of the read field may be similarly modified, for example, the value in the bit in the read field corresponding to the first transaction may be 0 when the first transaction does not perform a read operation on the first variable, and the value in the bit may be modified to 1 after the first transaction performs a read operation on the first variable. In the embodiment of the present specification, performing a read operation on a variable means reading a stored variable to obtain a current value of the variable.
It is to be understood that the read-write field shown in fig. 3 is only one specific implementation of the read-write field according to this example, and the read-write field according to the embodiments of the present disclosure is not limited to the specific form shown in fig. 3, as long as it can record the read/write operation of the first variable by the executors of the respective transactions executed concurrently.
Generally, in the case where the number of transactions that need to be executed is large, a transaction execution window may be set when executing the transactions, and the transaction execution window may include a predetermined number of transactions. The purpose of the transaction execution window is to: the execution body can know that the input information obtained by the transaction is the newest when the execution body executes the transaction at the lower limit of the window, and can carry out final submission without waiting for other transactions, and for the transaction in the middle of the window, the execution body can not determine whether the transaction obtains the newest input or not after the execution body executes the transaction, so the transaction can not be finally submitted until the transaction is positioned at the lower limit of the window, and the transaction can find that the transaction is marked to be redone before the transaction is submitted; the window upper limit is used to limit the amount of resources used to execute the transaction, and if the upper limit is infinite, the executing entity can process the transaction until the memory resources are consumed even if no transaction is finally committed.
The transaction execution window is slid among a plurality of transactions arranged in a commit order (or transaction number) so that the plurality of transactions in the transaction execution window can be executed concurrently in the blockchain node, and it is settable to slide the transaction execution window one transaction backward every time one transaction is committed. FIG. 4 illustrates a schematic diagram of a transaction execution window according to an embodiment of the present description. As shown in fig. 4, the ten numbers 1 to 10 in the figure represent ten transactions numbered 1 to 10, respectively, and the transaction execution window may include, for example, 5 transactions. The transaction execution window may initially fall on transactions 1 through 5. After transaction 1 is submitted, the window moves one transaction back, falling on transactions 2 to 6, and likewise after transaction 2 is submitted, the window moves one more transaction back, falling on transactions 3 to 7 as shown in the figure.
Thus, the window location field in FIG. 3 is used to indicate where the transaction execution window is currently located. The window position field corresponds to, for example, a first global variable, such that the field for each variable may obtain the current window position based on the first global variable. The first global variable may be set equal to, for example, the starting transaction number, the ending transaction number, etc. of the current window. For example, in the case of window locations such as that shown in fig. 4, the window locations in fig. 3 may be filled with, for example, "3," i.e., in this case, the window locations are identified with the starting transaction in the window. The window position field may correspond to a plurality of values, for example a first value corresponding to the number of transactions that should currently be serially submitted, a second value corresponding to the maximum number of transactions for the processed state, or a second value may include the number of transactions for the window, etc.
In the case where thousands of transactions are included in one block, the transactions may be executed in batches, for example, it may be set that each batch of transactions includes 1000 transactions, and a batch number is set for each batch of transactions. Thus, the serial number field may indicate the batch number of the currently processed transaction. For example, when performing a write or read operation of a first transaction on a first variable, the current batch number of the first transaction may be compared with the batch number indicated in the serial number field of the first variable recorded in the variable access table, if the two are consistent, the operation may be continued, and if the two are inconsistent, the existing data corresponding to the first variable in the variable access table may be cleared. For example, the sequence number shown in FIG. 3 is "2," which means that the transaction being performed is a second transaction, also numbered from 1 to 1000, which is distinguished from the transaction numbered from 1 to 1000 in the first batch by the sequence number "2. By adding the sequence number field into the variable access table, the zero clearing setting of the variable access table can be avoided. In the variable access table, the access rates of the variables may be different, and some variables (for example, the variable k2) are easy to cause conflicts. For this variable k2, it needs to be marked so that the read visitor to this variable k2 does after the antecedent transaction commits. If the serial number field is passed, the variable k2 can be marked by judging whether the batch number is out of date. If the method of the sequence number is not adopted, the zero clearing can be carried out in an asynchronous mode.
It will be appreciated that the variable access table shown in FIG. 3 is merely illustrative and is not intended to limit the scope of the embodiments of the present description. For example, in the case where the number of concurrently executed transactions is small, there is no need to batch the transactions, and there is no need to control the number of transaction executions through the transaction execution window, so that only the write field and the read field may be included in the variable access table. In one embodiment, only a write field may be included in the variable access table, so that, when performing a read operation in a transaction, the read operation may be performed by determining whether a previously-numbered concurrently-executed transaction performed a write operation based on the write field, and when performing a write operation for a transaction, the subsequently-numbered transactions may be all notified so that the subsequently-numbered transactions that performed a read operation all re-perform the read operation. In one embodiment, only the read field may be included in the variable access table, so that, when performing a read operation in a transaction, it may be performed directly, and when performing a write operation of a transaction, it may be determined whether the read operation is performed by a transaction performed while being numbered later based on the read field, and the read operation may be re-performed by notifying the transaction that performed the read operation after being committed.
The steps in the method are described in detail below.
First, at step S202, for each prior transaction, based on the written word segment, it is determined: whether a write operation to the first variable in the prior transaction has been performed, wherein the prior transaction is a transaction in the plurality of transactions that was committed sequentially before the first transaction.
For example, referring to the transaction execution window in FIG. 4, for example, the window falls on transactions 3-7 as shown in the figure, i.e., transactions 3-7 are currently executed concurrently in the blockchain node, for example, transactions 3-7 can be executed concurrently by 5 executors 3-7, for example, transactions 3-7 are executed concurrently in the Etherhouse node, specifically, in the virtual machine. In this case, transaction 6 is assumed to be the first transaction, which is about to perform a read operation on the first variable. Since the transactions 3 to 7 are submitted in sequence according to the transaction number sequence, the transaction 6 needs to determine whether the transactions 3 to 5 being executed simultaneously have write operations, and if any transaction in the transactions 3 to 5 has write operations, the write operations will finally change the value of the first variable, so that the transaction 6 needs to wait until the previous transaction including the write operations is submitted before reading the value of the first variable which has passed through the write operations. For example, transaction 4 includes a write operation to a first variable, and the write operation in transaction 4 has been currently performed in the node, so that the bit corresponding to transaction 4 in the write field corresponding to the first variable in the variable access table is modified to 1, and the executor corresponding to transaction 6 in the node can know that the other executors in the node have performed the write operation to the first variable in transaction 4 based on the variable access table.
In one embodiment, the block chaining points are deployed on a server such that the variable access tables are stored locally in shared memory, in which case the executors corresponding to transaction 6 may learn the lookup results at approximately the same time that the variable access tables are looked up.
In one embodiment, the block chain node is deployed over multiple servers, such that the variable access table is stored, for example, on a dedicated server, from which other servers in the node can receive information by accessing the dedicated server.
In step S204, based on the determination result, a read operation for the first variable in the first transaction is performed.
In one embodiment, in the case where the variable access table is stored in the local shared memory, the executor corresponding to the transaction 6 may obtain the search result at approximately the same time as the variable access table is searched, and perform subsequent operations based on the result after obtaining the search result. For example, transaction 6, after the above query is made for each transaction it preceded, determines: the transactions 3-5 are currently not written to the first variable, i.e., the transactions 3-5 are currently executed without changing the value of the first variable, and thus the execution entity 6 reads the value of the first variable. For example, the implementer 6, after making the above-described query for each transaction it preceded, determines: the executor 4 has already performed a write operation to the first variable, and the transaction 6 waits until after the transaction 4 is committed, before determining whether to perform a read of the first variable. After transaction 4 is submitted, as mentioned above, the transaction execution window is moved to 5-9, and the executor 6 may perform the above query again on each transaction before it, that is, query whether the executor 5 performs the write operation on the first variable based on the variable access table, and in the case that the executor 5 also performs the write operation, the executor 6 will wait for the transaction 5 to be submitted and then read. As another example, the implementer 6, after making the above-described query for each transaction it preceded, determines: transaction 4 and execution entity 5 have both performed a write operation to the first variable, then transaction 6 waits until transaction 5 commits before performing a read of the first variable. That is, the executor 6 needs to wait until the write operation of the transaction that is before the transaction 6 and is closest to the transaction 6 among the plurality of transactions executed concurrently is committed before performing the read operation. While write operations for transactions following transaction 6 in concurrently executing transactions do not affect the execution of read operations for transaction 6.
In one embodiment, the variable access table is stored locally, and the executable corresponding to transaction 6 may send a report to local dedicated hardware requesting the dedicated hardware to determine the above steps. The special hardware is, for example, a local CPU or FPGA dedicated to access and rewrite the variable access table. The executor 6 performs a read operation of the first variable while sending the report, i.e. here the read of the first variable is done directly without waiting for the query result to be received. Before the transaction 6 commits, it is determined by the execution body 6 whether a re-read of the first variable is to be made based on information received from the dedicated hardware. For example, after the dedicated hardware receives the report and makes a query, it is determined that there is a transaction in transactions 3-5 that preceded transaction 6 that performed a write operation to the first variable, in which case the dedicated hardware notifies the execution entity 6 to resume reading the first variable.
In the case where the variable access table is stored, for example, on a dedicated server, such as transactions 3-7 are currently concurrently executed by the server 1, the execution entity in the server 1 corresponding to transaction 6 will perform a read operation on the first variable. The server 1 sends a report to the dedicated server that the first variable is to be read, to request the dedicated server to make a determination whether the executor of the concurrently executed transaction preceding transaction 6 has performed a write operation to the first variable. The server 1 requests the dedicated server to perform the reading operation of the first variable by the executing body 6 while transmitting the report, that is, since it takes a long communication time to receive the query result from the dedicated server, the reading of the first variable is directly performed without waiting for the reception of the query result. Before the transaction 6 is submitted, it is determined by the implementer 6 whether a re-read of the first variable is to be made based on information received from the dedicated server. For example, after the dedicated server receives the report and makes a query, it is determined that there is a transaction in transactions 3 to 5 before transaction 6 in which a write operation to the first variable is performed, in which case the dedicated server notifies the execution body 6 to resume reading of the first variable. Here, in order to reduce the difficulty of development, the executor 6 typically re-executes all transactions 6 after receiving the notification. For example, in the above query, it is not queried that there is a transaction in the transactions 3 to 5 in which a write operation on the first variable is performed, but the executors of the transactions 3 to 5 subsequently perform a write operation after the executors 6 perform reading, and write the write operation into the variable access table of the dedicated server after submission, so that the dedicated server notifies the executors 6 to perform re-reading of the first variable based on the write operation, and the executors 6 re-execute the transaction 6 before submission. In the query, it is not queried that there is a transaction in the transactions 3 to 5 that executes the write operation on the first variable, and the executors of the transactions 3 to 5 do not execute the write operation after the executors 6 read, that is, the dedicated server does not notify the executors 6 to re-read, so that the executors 6 can directly submit the transactions 6.
After the read operation on the first variable is performed by the execution entity 6 as described above, the bit corresponding to the transaction 6 in the read field corresponding to the first variable in the variable access table is modified to, for example, "1", which is, for example, 0 before the execution entity 6 performs the read operation.
In one embodiment, the plurality of transactions further includes a second transaction, wherein the order of submission of the second transaction is first in the plurality of transactions, the second transaction including a write operation to the first variable, and in the event that the second transaction is submitted after the read field is modified accordingly, as shown by the dashed box in fig. 2, the method further includes the steps of:
step S206, determining whether the read operation of the first variable in the first transaction is executed or not based on the read field; and
step S208, in the case that the read operation of the first variable in the first transaction is determined to be executed, notifying local re-execution of the read operation of the first variable in the first transaction.
In the above embodiment, transaction 3 shown in fig. 4, for example, is the second transaction. After the execution body 6 performs the read operation as described above, the execution body 3 performs the write operation, for example. Specifically, the executor 3 stores the value to be written to the first variable into a predetermined memory location, and then modifies the bit corresponding to the transaction 3 in the write field corresponding to the first variable in the variable access table to "1". After this modification, for example, the executor 7 will perform a read operation on the first variable after the modification, which is similar to the above, it can be known that the executor 3 has performed a write operation on the first variable by querying the variable access table, and thus, the executor 7 will wait for the transaction 3 to commit and then perform the read operation.
Since transaction 3 is located at the far left of the transaction execution window, the executing entity 3 will commit to transaction 3 after executing transaction 3. For example, process 3 may determine whether transaction 3 is currently committed based on the window location field in the table. After transaction 3 is committed, i.e. the actual writing to the first variable, the value of the first variable is modified. After transaction 3 is submitted, the following steps will be performed.
In step S206, it is determined whether a read operation to the first variable in the first transaction has been performed based on the read field.
After the transaction 3 is submitted, the executor 3 determines whether the corresponding executor has performed the read operation on the first variable for the other transactions (i.e. transactions 4-7) in the window before the submission, and if the corresponding executor has performed the read operation, notifies the corresponding executor to re-execute the read operation. For example, as described above, transaction 6 (i.e., the first transaction) is one transaction in the window after transaction 3, then executor 3 determines whether executor 6 has performed a read operation on the first variable based on the bit in the read field corresponding to transaction 6.
In step S208, in the case that it is determined that the read operation for the first variable in the first transaction has been performed, the local re-execution of the read operation for the first variable in the first transaction is notified.
After the determination by the above steps, the executor 3 notifies the executor 6 to re-execute the read operation for the first variable after determining that the executor 6 has performed the read operation based on the variable access table. Where the variable access table is stored in the local shared memory, the executor 3 may mark in the private memory space of the transaction 6 to inform the executor 6 to perform a reread operation, and the transaction 6 checks whether the reread mark exists before commit or at other times. Alternatively, the executor 3 may send an asynchronous signal to the executor 6 after marking, and the executor 6 checks whether the current transaction is set to need to be reread (because the executor may not be executing the transaction 6 when receiving the asynchronous signal) after receiving the asynchronous signal, and if so, proceeds to a reread process. In the case where the variable access table is stored in a separate dedicated server, the server marks the host on which the executor 6 is delegated via the network to notify the executor 6 to perform a reread operation.
The executor 6 may immediately re-execute the read operation, or the executor 6 may check from the variable access table whether the executors 4 and 5 subsequently performed a write operation, e.g., in case the executor 4 also performed a write operation, the executor 6 may wait until the transaction 4 is committed before re-executing the read operation.
In addition, after the transaction 3 is submitted, the transaction execution window moves backwards by one bit, namely, the transaction execution window is positioned on the transactions 4-8, in this case, the execution body 3 also clears the bit corresponding to the transaction 3 in the write field corresponding to the first variable in the variable access table, so that the use of the bit by the subsequent transaction is not influenced. Similarly, if a read operation is also included in transaction 3, the corresponding in the read field is also modified to 1 by the executor 3 after the previous read operation, and the executor 3 similarly clears this bit after the transaction 3 is committed.
Fig. 5 illustrates an apparatus 5000 for concurrently executing a plurality of transactions in a blockchain, wherein the plurality of transactions have a predetermined submission order and include a first transaction, the apparatus is disposed in a first node in the blockchain, the first node is pre-provisioned with a variable access table, the variable access table includes a write field corresponding to a first variable, and the write field is used for recording execution of a write operation on the first variable in the plurality of transactions, according to an embodiment of the present disclosure, and the apparatus includes:
a first determining unit 501 configured to, for each preceding transaction, determine, based on the written word segment: whether a write operation to the first variable in the prior transaction has been performed, wherein the prior transaction is a transaction in the plurality of transactions that was committed sequentially before the first transaction; and
an execution unit 502 configured to execute, based on the determination result, a read operation for the first variable in a first transaction.
In one embodiment, the variable access table is stored locally, wherein the execution unit 502 is further configured to perform a read operation on the first variable in a first transaction in the event that, for each previous transaction, it is determined based on the write field that a write operation on the first variable was not performed.
In one embodiment, the execution unit 502 is further configured to, for a second transaction of the plurality of transactions that is submitted sequentially before the first transaction, wait with respect to the first transaction in the case that it is determined, based on the written word segment, that a write operation to the first variable in the second transaction has been performed to perform a read operation to the first variable in the first transaction after the second transaction is submitted.
In one embodiment, the variable access table is stored locally, wherein the first determination unit 501 is further configured to send a report to local dedicated hardware to request the dedicated hardware to make the determination,
the execution unit 502 is further configured to execute a read operation of the first variable in a first transaction while sending the report, and determine whether to re-execute the first transaction based on a determination received from the dedicated hardware before submitting the first transaction.
In one embodiment, the variable access table is stored in a dedicated server, wherein the first determining unit 501 is further configured to send a report to the dedicated server to request the dedicated server to make the determination,
the execution unit 502 is further configured to request the dedicated server to perform a read operation of the first variable in the first transaction while sending the report, and to determine whether to re-perform the first transaction based on a determination result received from the dedicated server before submitting the first transaction.
In one embodiment, the variable access table further includes a read field corresponding to the first variable, where the read field is used to record execution of a read operation on the first variable in the multiple transactions, and the apparatus further includes a modification unit 503 configured to modify the read field accordingly after the read operation on the first variable in the first transaction is executed.
In one embodiment, the read field comprises a plurality of bits corresponding to the plurality of transactions, respectively, wherein the modification unit is further configured to modify the bits in the read field corresponding to the first transaction accordingly.
In one embodiment, the plurality of transactions further comprises a second transaction, wherein the order of submission of the second transaction is first in the plurality of transactions, the second transaction comprising a write operation to the first variable, the apparatus further comprising, in the event that the second transaction is submitted after the read field is modified accordingly,
a second determining unit 504 configured to determine whether a read operation for the first variable in the first transaction has been performed based on the read field; and
a notification unit 505 configured to notify that the read operation on the first variable in the first transaction is locally re-executed in a case where it is determined that the read operation on the first variable in the first transaction has been executed.
In one embodiment, the plurality of transactions further includes a third transaction, wherein the third transaction is submitted in an order between the first transaction and the second transaction, the apparatus further comprising:
a third determining unit 506 configured to, after receiving a notification from a local to re-execute the read operation on the first variable in the first transaction, determine whether a write operation on the first variable in a third transaction has been executed based on the write word segment;
a waiting unit 507 configured to wait, in a case where it is determined that the write operation in the third transaction has been performed, to re-perform the read operation on the first variable in the first transaction after the write operation on the first variable in the third transaction is committed.
In an embodiment, the predetermined number of bits included in the write field corresponds to a predetermined number of transactions, respectively, the apparatus further comprises a first restoring unit 508 configured to restore, after submitting the second transaction, a first value of the bit in the write field corresponding to the second transaction, wherein the first value is used to record: a write operation to the first variable in the second transaction has been performed.
In one embodiment, the predetermined number of bits included in the read field corresponds to a predetermined number of transactions, respectively, the second transaction further includes a read operation on the first field, and the apparatus further includes a second restoring unit 509 configured to restore a first value of the bits corresponding to the second transaction in the read field after the second transaction is submitted, wherein the first value is used for recording: a read operation to the first variable in the second transaction has been performed.
In one embodiment, a transaction execution window is preset in the first node, and the transactions are transactions currently included in the transaction execution window, wherein the number of the transactions is less than or equal to the predetermined number, and the apparatus further includes a window moving unit 510 configured to, after submitting the second transaction, move the transaction execution window backward by one transaction among the transactions included in the first node and arranged in a predetermined submission order.
Another aspect of the present specification provides a computer readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform any one of the above methods.
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 executing the transactions concurrently in the block chain, the variable access table is used for recording the read-write operation of the same variable executed by a plurality of transactions concurrently executed in the transaction execution window, so that the transactions can be executed concurrently for a plurality of transactions without mutual dependency, and the transactions can be executed serially for a plurality of transactions with mutual dependency, so that the processing speed is increased and the processing performance is improved while the consistency of the calculation results is ensured.
It is to be understood that the descriptions of "first," "second," etc. herein are merely used for simplicity of description to distinguish between similar concepts and are not intended to be limiting.
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 specification. 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 (24)

1. A method for executing a plurality of transactions concurrently in a blockchain, wherein the plurality of transactions have a predetermined submission order, including a first transaction and a second transaction, the submission order of the second transaction is located at a first position in the plurality of transactions, the second transaction includes a write operation on a first variable, the method is executed at a first node in the blockchain, the first node is pre-configured with a variable access table, the variable access table includes a write field and a read field corresponding to the first variable, wherein the write field is used for recording the execution of the write operation on the first variable in the plurality of transactions, the read field is used for recording the execution of the read operation on the first variable in the plurality of transactions, the predetermined number of bits included in the write field respectively correspond to the predetermined number of transactions, and a transaction execution window is pre-configured in the first node, the transaction execution window currently includes the plurality of transactions, wherein a number of the plurality of transactions is less than or equal to the predetermined number, the method comprising:
in the execution of the first transaction, for each prior transaction, it is determined based on the written word segment: whether a write operation to the first variable in the prior transaction has been performed, wherein the prior transaction is a transaction in the plurality of transactions that was committed sequentially before the first transaction; and
performing a read operation to the first variable in a first transaction based on the determination;
after performing a read operation on the first variable in a first transaction, modifying the read field accordingly;
in the case where the second transaction is committed after the read field is modified accordingly, determining whether a read operation to the first variable in the first transaction has been performed based on the read field; and
in the event that it is determined that the read of the first variable in the first transaction has been performed, notifying local re-execution of the read of the first variable in the first transaction;
after committing the second transaction, restoring a first value of a bit in the write field corresponding to the second transaction, wherein the first value is used to record: a write operation to the first variable in the second transaction has been performed; and
moving the transaction execution window one transaction back among the plurality of transactions.
2. The method of claim 1, wherein the variable access table is stored locally, wherein performing a read operation on the first variable in a first transaction based on the determination comprises performing a read operation on the first variable in a first transaction if, for each prior transaction, it is determined based on the write field that a write operation on the first variable is not performed.
3. The method of claim 1, wherein performing, based on the determination, the read operation for the first variable in the first transaction comprises, for a third transaction of the plurality of transactions that precedes the first transaction in order of commit, waiting with respect to the first transaction to perform the read operation for the first variable in the first transaction after committing the third transaction in the event that it is determined, based on the write field, that the write operation for the first variable in the third transaction has been performed.
4. The method of claim 1, wherein the variable access table is stored locally, wherein for each prior transaction, based on the written word segment, it is determined: whether a write operation to the first variable in the prior transaction has been performed includes sending a report to local dedicated hardware requesting the dedicated hardware to make the determination,
performing a read operation of the first variable in a first transaction based on the determination comprises performing a read operation of the first variable in a first transaction while sending the report, and determining whether to re-perform the first transaction based on the determination received from the dedicated hardware before committing the first transaction.
5. The method of claim 1, wherein the variable access table is stored in a dedicated server, wherein for each prior transaction, based on the written word, it is determined: whether a write operation to the first variable in the prior transaction has been performed includes sending a report to the dedicated server requesting the dedicated server to make the determination,
performing a read operation of the first variable in the first transaction based on the determination result includes requesting the dedicated server to perform the read operation of the first variable in the first transaction while sending the report, and determining whether to re-perform the first transaction based on the determination result received from the dedicated server before submitting the first transaction.
6. The method of claim 1, wherein the read field comprises a plurality of bits corresponding to the plurality of transactions, respectively, wherein modifying the read field accordingly comprises modifying bits in the read field corresponding to a first transaction accordingly.
7. The method of claim 1, wherein the plurality of transactions further includes a third transaction, wherein the third transaction is submitted in an order between the first transaction and the second transaction, the method further comprising:
after receiving locally a notification to re-execute a read operation on the first variable in a first transaction, determining whether a write operation on the first variable in a third transaction has been performed based on the write word segment;
in the case where it is determined that the write operation to the first variable in the third transaction has been performed, a wait is made to re-perform the read operation to the first variable in the first transaction after the write operation to the first variable in the third transaction is committed.
8. The method of claim 1, wherein the predetermined number of bits included in the read field correspond to a predetermined number of transactions, respectively, and wherein the second transaction further comprises a read operation on a first field, the method further comprising, after committing the second transaction, restoring a first value of the bit in the read field corresponding to the second transaction, wherein the first value is used to record: a read operation to the first variable in the second transaction has been performed.
9. The method of claim 1, further comprising a first global variable in the variable access table to indicate a location of the transaction execution window.
10. The method of claim 1, further comprising a serial number field corresponding to the first variable in the variable access table for indicating a transaction batch to which the first variable corresponds.
11. The method of claim 1, wherein the variable access table includes a key corresponding to the first variable, the key being a hash value of the first variable.
12. An apparatus for concurrently executing a plurality of transactions in a blockchain, wherein the plurality of transactions have a predetermined commit order, including a first transaction and a second transaction, the commit order of the second transaction is located at a first position in the plurality of transactions, the second transaction includes a write operation to a first variable, the apparatus is executed at a first node in the blockchain, the first node is pre-configured with a variable access table, the variable access table includes a write field and a read field corresponding to the first variable, wherein the write field is used for recording the execution of the write operation to the first variable in the plurality of transactions, the read field is used for recording the execution of the read operation to the first variable in the plurality of transactions, the predetermined number of bits included in the write field respectively correspond to the predetermined number of transactions, and a transaction execution window is pre-configured in the first node, the transaction execution window currently includes the plurality of transactions, wherein a number of the plurality of transactions is less than or equal to the predetermined number, the apparatus comprising:
a first determining unit configured to, in execution of a first transaction, determine, for each preceding transaction, based on the written word segment: whether a write operation to the first variable in the prior transaction has been performed, wherein the prior transaction is a transaction in the plurality of transactions that was committed sequentially before the first transaction; and
an execution unit configured to execute a read operation for the first variable in a first transaction based on the determination result;
a modification unit configured to modify the read field accordingly after performing a read operation on the first variable in a first transaction;
a second determination unit configured to, in a case where the second transaction is committed after the read field is modified accordingly, determine whether a read operation for the first variable in the first transaction has been performed based on the read field; and
a notification unit configured to notify local re-execution of the read operation on the first variable in the first transaction in a case where it is determined that the read operation on the first variable in the first transaction has been executed;
a first recovery unit configured to recover, after committing the second transaction, a first value of a bit in the write field corresponding to the second transaction, wherein the first value is used to record: a write operation to the first variable in the second transaction has been performed;
a window moving unit configured to move the transaction execution window one transaction backward in the plurality of transactions after the second transaction is submitted.
13. The apparatus of claim 12, wherein the variable access table is stored locally, wherein the execution unit is further configured to perform a read operation on the first variable in a first transaction in the event that, for each prior transaction, it is determined based on the write field that a write operation on the first variable is not performed.
14. The apparatus of claim 12, wherein the execution unit is further configured to, for a third transaction of the plurality of transactions submitted sequentially before the first transaction, wait with respect to the first transaction in the event that it is determined, based on the write field, that a write operation to the first variable in the third transaction has been performed to perform a read operation to the first variable in the first transaction after the third transaction is submitted.
15. The apparatus of claim 12, wherein the variable access table is stored locally, wherein the first determining unit is further configured to send a report to local dedicated hardware to request the dedicated hardware to make the determination,
the execution unit is further configured to execute a read operation of the first variable in a first transaction while sending the report, and determine whether to re-execute the first transaction based on a determination result received from the dedicated hardware before submitting the first transaction.
16. The apparatus of claim 12, wherein the variant access table is stored in a dedicated server, wherein the first determining unit is further configured to send a report to the dedicated server requesting the dedicated server to make the determination,
the execution unit is further configured to request the dedicated server to perform a read operation of the first variable in a first transaction while sending the report, and to determine whether to re-perform the first transaction based on a determination result received from the dedicated server before submitting the first transaction.
17. The apparatus of claim 12, wherein the read field comprises a plurality of bits corresponding to the plurality of transactions, respectively, and wherein the modification unit is further configured to modify the bits in the read field corresponding to the first transaction accordingly.
18. The apparatus of claim 12, wherein the plurality of transactions further comprises a third transaction, wherein the third transaction is submitted in an order between the first transaction and the second transaction, the apparatus further comprising:
a third determination unit configured to, after receiving a notification from a local to re-execute a read operation for the first variable in the first transaction, determine whether a write operation for the first variable in a third transaction has been executed based on the write word segment;
and a waiting unit configured to wait, in a case where it is determined that the write operation to the first variable in the third transaction has been performed, to re-perform the read operation to the first variable in the first transaction after the write operation to the first variable in the third transaction is committed.
19. The apparatus of claim 12, wherein the predetermined number of bits included in the read field correspond to a predetermined number of transactions, respectively, and the second transaction further includes a read operation on a first field, the apparatus further comprising a second restoring unit configured to restore, after the second transaction is committed, a first value of the bit corresponding to the second transaction in the read field, wherein the first value is used to record: a read operation to the first variable in the second transaction has been performed.
20. The apparatus of claim 12, further comprising a first global variable in the variable access table to indicate a location of the transaction execution window.
21. The apparatus of claim 12, further comprising a serial number field corresponding to the first variable in the variable access table for indicating a transaction batch corresponding to the first variable.
22. The apparatus of claim 12, wherein the variable access table includes a key corresponding to the first variable, the key being a hash value of the first variable.
23. 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-11.
24. 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-11.
CN201910816544.8A 2019-08-30 2019-08-30 Method and apparatus for concurrently executing transactions in a blockchain Active CN110706101B (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN201910816544.8A CN110706101B (en) 2019-08-30 2019-08-30 Method and apparatus for concurrently executing transactions in a blockchain
CN202110839216.7A CN113570460A (en) 2019-08-30 2019-08-30 Method and apparatus for concurrently executing transactions in a blockchain
TW109110259A TWI730690B (en) 2019-08-30 2020-03-26 Method and device for simultaneously executing transactions in block chain, computer readable storage medium and computing equipment
PCT/CN2020/082454 WO2021036253A1 (en) 2019-08-30 2020-03-31 Method and device for executing transactions in parallel in blockchain

Applications Claiming Priority (1)

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

Related Child Applications (1)

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

Publications (2)

Publication Number Publication Date
CN110706101A CN110706101A (en) 2020-01-17
CN110706101B true CN110706101B (en) 2021-06-29

Family

ID=69194057

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202110839216.7A Pending CN113570460A (en) 2019-08-30 2019-08-30 Method and apparatus for concurrently executing transactions in a blockchain
CN201910816544.8A Active CN110706101B (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
CN202110839216.7A Pending CN113570460A (en) 2019-08-30 2019-08-30 Method and apparatus for concurrently executing transactions in a blockchain

Country Status (3)

Country Link
CN (2) CN113570460A (en)
TW (1) TWI730690B (en)
WO (1) WO2021036253A1 (en)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113570460A (en) * 2019-08-30 2021-10-29 创新先进技术有限公司 Method and apparatus for concurrently executing transactions in a blockchain
CN111476663B (en) * 2020-04-15 2022-08-12 腾讯科技（深圳）有限公司 Data processing method and device, node equipment and storage medium
EP3977390B1 (en) * 2020-08-03 2023-12-06 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain transaction processing systems and methods
CN111754350B (en) * 2020-08-28 2020-11-24 支付宝(杭州)信息技术有限公司 Method and device for parallelly acquiring serial numbers of transaction access variables in block chain
CN111813795B (en) * 2020-08-28 2020-12-04 支付宝(杭州)信息技术有限公司 Method and apparatus for confirming transactions in a blockchain network
CN112991061B (en) * 2020-10-28 2023-06-09 支付宝(杭州)信息技术有限公司 Method and apparatus for concurrently executing transactions in blockchain

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107688999A (en) * 2017-08-11 2018-02-13 杭州秘猿科技有限公司 A kind of parallel transaction based on block chain performs method
CN108681565A (en) * 2018-04-28 2018-10-19 百度在线网络技术（北京）有限公司 block chain data parallel processing method, device, equipment and storage medium
CN109508337A (en) * 2018-11-12 2019-03-22 杭州秘猿科技有限公司 A kind of transaction is parallel to execute method, apparatus, electronic equipment and system
CN109559226A (en) * 2018-11-28 2019-04-02 杭州有盾网络科技有限公司 Block chain transaction execution method, system and electronic equipment and storage medium
CN109784930A (en) * 2019-02-18 2019-05-21 深圳市网心科技有限公司 A kind of processing method, device, electronic equipment and the medium of block chain transaction data
CN110135985A (en) * 2019-04-04 2019-08-16 杭州抖音科技有限公司 A kind of parallel execution method and system traded on block chain

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003042816A2 (en) * 2001-11-13 2003-05-22 Koninklijke Philips Electronics N.V. Entry locking for large data structures
CN104750720B (en) * 2013-12-30 2018-04-27 中国银联股份有限公司 The realization that high-performance data is handled under multi-thread concurrent access environment
US10255108B2 (en) * 2016-01-26 2019-04-09 International Business Machines Corporation Parallel execution of blockchain transactions
CN107018125B (en) * 2017-02-17 2019-08-09 阿里巴巴集团控股有限公司 A kind of block catenary system, date storage method and device
TWI646487B (en) * 2017-06-23 2019-01-01 現代財富控股有限公司 Smart contract executing system with permission rating and avoid duplication and method thereof
US11281644B2 (en) * 2017-07-28 2022-03-22 Hitachi, Ltd. Blockchain logging of data from multiple systems
CN110377570B (en) * 2017-10-12 2021-06-11 腾讯科技（深圳）有限公司 Node switching method and device, computer equipment and storage medium
CN107832154B (en) * 2017-11-14 2020-07-17 浙江亿邦通信科技有限公司 Multi-process processing method, processing device and application
US11823178B2 (en) * 2017-11-17 2023-11-21 International Business Machines Corporation Optimization of high volume transaction performance on a blockchain
CN109064171A (en) * 2018-07-26 2018-12-21 杭州秘猿科技有限公司 A kind of method, apparatus and electronic system of block chain parallel transaction
CN109300036B (en) * 2018-09-14 2020-08-14 百度在线网络技术（北京）有限公司 Bifurcation regression method and device of block chain network
US10333694B1 (en) * 2018-10-15 2019-06-25 Accelor Ltd. Systems and methods for secure smart contract execution via read-only distributed ledger
CN111782275B (en) * 2018-10-25 2024-02-06 创新先进技术有限公司 Transaction processing method and device based on blockchain and electronic equipment
CN109636384A (en) * 2018-10-26 2019-04-16 阿里巴巴集团控股有限公司 A kind of parallelization executes the method, apparatus and system of block chain transaction
KR102170346B1 (en) * 2018-11-27 2020-10-28 알리바바 그룹 홀딩 리미티드 Systems and methods for information protection
CN109547211B (en) * 2018-11-29 2020-06-30 浙江大学 Grading concurrent byzantine consensus method and system applying digital signature technology
MX2019009286A (en) * 2018-12-28 2019-10-30 Alibaba Group Holding Ltd Parallel execution of transactions in a blockchain network.
CN113570460A (en) * 2019-08-30 2021-10-29 创新先进技术有限公司 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
CN107688999A (en) * 2017-08-11 2018-02-13 杭州秘猿科技有限公司 A kind of parallel transaction based on block chain performs method
CN108681565A (en) * 2018-04-28 2018-10-19 百度在线网络技术（北京）有限公司 block chain data parallel processing method, device, equipment and storage medium
CN109508337A (en) * 2018-11-12 2019-03-22 杭州秘猿科技有限公司 A kind of transaction is parallel to execute method, apparatus, electronic equipment and system
CN109559226A (en) * 2018-11-28 2019-04-02 杭州有盾网络科技有限公司 Block chain transaction execution method, system and electronic equipment and storage medium
CN109784930A (en) * 2019-02-18 2019-05-21 深圳市网心科技有限公司 A kind of processing method, device, electronic equipment and the medium of block chain transaction data
CN110135985A (en) * 2019-04-04 2019-08-16 杭州抖音科技有限公司 A kind of parallel execution method and system traded on block chain

Also Published As

Publication number Publication date
CN113570460A (en) 2021-10-29
WO2021036253A1 (en) 2021-03-04
TW202109510A (en) 2021-03-01
CN110706101A (en) 2020-01-17
TWI730690B (en) 2021-06-11

Similar Documents

Publication Publication Date Title
CN110706101B (en) Method and apparatus for concurrently executing transactions in a blockchain
CN109359222B (en) Data storage method and system, equipment and storage medium
US9990391B1 (en) Transactional messages in journal-based storage systems
US20230161756A1 (en) Scalable, secure, efficient, and adaptable distributed digital ledger transaction network
EP3678346A1 (en) Blockchain smart contract verification method and apparatus, and storage medium
US10108658B1 (en) Deferred assignments in journal-based storage systems
CN111241061B (en) Writing method of state database, data processing device and storage medium
EP3779760B1 (en) Blockchain-based data processing method and apparatus, and electronic device
US10324905B1 (en) Proactive state change acceptability verification in journal-based storage systems
RU2585973C2 (en) Method and apparatus for controlling locking operation of database system
CN110648124B (en) Method and apparatus for concurrently executing transactions in a blockchain
EP3961461B1 (en) Method and apparatus for obtaining number for transaction-accessed variable in blockchain in parallel
CN110675255A (en) Method and apparatus for concurrently executing transactions in a blockchain
US20230275771A1 (en) Pre-execution of block chain transaction in parallel during block consensus
CN113743950A (en) Method for performing transactions in a blockchain, blockchain node and blockchain
CN113743943B (en) Method for executing transaction in block chain, main node and slave node
CN110706108B (en) Method and apparatus for concurrently executing transactions in a blockchain
CN110689344B (en) Method and apparatus for concurrently executing transactions in a blockchain
CN115237444A (en) Concurrent control method, device and equipment based on version number and storage medium
CN112561695B (en) Method and apparatus for concurrently executing transactions in a blockchain
CN109165208A (en) It is a kind of for loading data into the method and system in database
CN113076331B (en) Method, device, equipment, storage medium and program product for processing middle-stage data
CN110889040B (en) Method and device for pushing information
CN110837536B (en) Information processing method, device and storage medium
US20150019672A1 (en) Method and System for Record Access in a Distributed System

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: 20201012

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: 20201012

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: 40028852

Country of ref document: HK

GR01 Patent grant
GR01 Patent grant