CN110648124A - Method and apparatus for concurrently executing transactions in a blockchain - Google Patents
Method and apparatus for concurrently executing transactions in a blockchain Download PDFInfo
- Publication number
- CN110648124A CN110648124A CN201910818227.XA CN201910818227A CN110648124A CN 110648124 A CN110648124 A CN 110648124A CN 201910818227 A CN201910818227 A CN 201910818227A CN 110648124 A CN110648124 A CN 110648124A
- Authority
- CN
- China
- Prior art keywords
- transaction
- variable
- execution
- read operation
- write
- 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.)
- Granted
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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/085—Payment architectures involving remote charge determination or related payment systems
- G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
Abstract
The embodiment of the specification provides a method and a device for executing transactions concurrently in a blockchain, the method is executed at a first node in the blockchain, the first node currently and concurrently executes a plurality of transactions including a first transaction, and the first transaction includes a reading operation on a first variable, and the method includes: after starting to execute the code of the read operation in the first transaction, inferring whether a second transaction is to write the first variable, wherein the second transaction is a transaction of the plurality of transactions having a transaction number that is less than the first transaction, wherein the transaction number corresponds to a predetermined commit order of transactions; suspending execution of the read operation in the first transaction in the event that a second transaction is inferred to be writing to the first variable.
Description
Technical Field
The embodiments of the present disclosure relate to the field of blockchain technologies, and more particularly, to a method and an apparatus for concurrently executing transactions in a blockchain.
Background
The blockchain technology is a brand-new distributed infrastructure and computing paradigm that is built on a peer-to-peer (P2P) network, utilizes a chained data structure to verify and store data, utilizes a distributed node consensus algorithm to generate and update data, utilizes cryptography to ensure the security of data transmission and access, and utilizes an intelligent contract composed of automated script codes to program and operate data. The block chain technology is also called as distributed book technology, is decentralized distributed database technology and is characterized by decentralized, transparent disclosure, no tampering and trusty. Each data of the block chain is broadcasted to the block chain nodes of the whole network, and each whole node has the full amount of consistent data. The nodes in the blockchain perform services such as transfer and data storage by sending transactions, the accounting nodes in the blockchain collect the transactions in the blockchain in the transaction pool, execute the transactions, and package the transactions into blocks and spread the transactions into the blockchain after executing the transactions. The block sent from the accounting node is verified by a verification node in the block chain, and after the verification is passed, each node executes each transaction included in the block when receiving the block. In order to ensure the data consistency of each node, when executing multiple transactions in a block, the submission order of the multiple transactions in each node needs to be consistent, so that a consistent execution result can be obtained. Therefore, in the prior art, before executing a transaction, an accounting node numbers a plurality of transactions to be executed according to a predetermined rule, and sequentially executes the plurality of transactions according to the numbering order, that is, sequentially submits the plurality of transactions, and after receiving the block, other nodes also sequentially execute and submit the plurality of transactions according to the transaction numbering order. However, the multiple transactions are not necessarily all interdependent, and in the absence of a dependency between two transactions, concurrent execution of the two transactions does not affect the final result. And if there is dependency between two transactions executed concurrently, the concurrent execution will affect the final result.
Therefore, a more efficient method for concurrently performing multiple transactions in a blockchain is needed.
Disclosure of Invention
Embodiments of the present disclosure aim to provide a more efficient method for concurrently executing multiple transactions, so as to solve the deficiencies in the prior art.
To achieve the above object, one aspect of the present specification provides a method for concurrently executing a plurality of transactions in a blockchain, the method being executed at a first node in the blockchain, the plurality of transactions including a first transaction including a read operation on a first variable, the method including:
after starting to execute the code of the read operation in the first transaction, inferring whether a second transaction is to write the first variable, wherein the second transaction is a transaction of the plurality of transactions having a transaction number that is less than the first transaction, wherein the transaction number corresponds to a predetermined commit order of transactions;
suspending execution of the read operation in the first transaction in the event that a second transaction is inferred to be writing to the first variable.
In one embodiment, a variable conflict table is preset in the first node, and the variable conflict table records that a first variable is a conflict variable, wherein the inferring whether a second transaction is to write the first variable comprises inferring that the second transaction is to write the first variable based on the variable conflict table.
In one embodiment, the method further comprises, after suspending execution of the read operation in the first transaction, determining whether the second transaction is a transaction previous to the first transaction according to a commit order, and in the event that it is determined that the second transaction is a transaction previous to the first transaction according to a commit order, resuming execution of the read operation based on execution of the second transaction.
In one embodiment, the read target of the read operation is a transaction commit result stored in the shared memory, wherein resuming execution of the read operation based on execution of the second transaction includes resuming execution of the read operation after the second transaction commits.
In one embodiment, the read target of the read operation is intermediate data written into the shared memory during processing of the second transaction, wherein resuming execution of the read operation based on execution of the second transaction includes resuming execution of the read operation based on a statement in a predetermined address of the shared memory during execution of the second transaction, the statement indicating that execution of the second transaction will no longer write to the first variable.
In an embodiment, the read target of the read operation is intermediate data written into the shared memory in the second transaction during the processing process, wherein, based on the execution of the second transaction, resuming the execution of the read operation includes, after determining that the intermediate data includes a write value to the first variable in the second transaction, resuming the execution of the read operation, and recording the execution of the read operation in the shared memory.
In one embodiment, inferring whether a second transaction is to write to the first variable comprises obtaining transaction data for the second transaction; inferring whether the second transaction is to write to the first variable based on transaction data of the second transaction.
In one embodiment, inferring whether the second transaction is to write to the first variable based on transaction data for the second transaction includes inferring whether the second transaction is to write to the first variable by inputting a name of a function called in the second transaction and the first variable into a predetermined decision model.
In one embodiment, the method further comprises, after suspending execution of the read operation in the first transaction, determining whether there is a conflicting transaction with a transaction number between the second transaction and the first transaction, wherein the conflicting transaction is a transaction that is inferred that the first variable is to be written to, and, in the absence of the conflicting transaction, resuming execution of the read operation based on execution of the second transaction.
In one embodiment, a variable collision table is pre-stored in the first node, the variable collision table having a probability of collision for a first variable recorded therein, wherein inferring whether a second transaction is to write to the first variable after the code that initiated the read operation in the first transaction comprises, after the code that initiated the read operation in the first transaction, generating a random number within a first predetermined range of values, and inferring whether a second transaction is to write to the first variable by determining whether the random number is within a second predetermined range of values, the second predetermined range of values being within the first predetermined range of values and being determined based on the probability of collision.
Another aspect of the present specification provides an apparatus for concurrently executing a plurality of transactions in a blockchain, the apparatus being disposed in a first node in the blockchain, the plurality of transactions including a first transaction including a read operation on a first variable, the apparatus comprising:
a first determining unit configured to infer whether a second transaction is to write the first variable after starting execution of the code of the read operation in the first transaction, wherein the second transaction is a transaction of the plurality of transactions having a transaction number smaller than the first transaction, wherein the transaction number corresponds to a predetermined commit order of transactions;
a suspending unit configured to suspend execution of the read operation in the first transaction in a case where it is inferred that a second transaction is to write the first variable.
In one embodiment, a variable conflict table is preset in the first node, and the variable conflict table records that the first variable is a conflict variable, wherein the first determining unit is further configured to infer that the second transaction is to write the first variable based on the variable conflict table.
In one embodiment, the apparatus further includes a second determination unit configured to determine whether the second transaction is a previous transaction of the first transaction according to a commit order after the execution of the read operation in the first transaction is suspended, and a first resumption unit configured to resume the execution of the read operation based on the execution of the second transaction in a case where it is determined that the second transaction is a previous transaction of the first transaction according to a commit order.
In an embodiment, a read object of the read operation is a transaction commit result stored in the shared memory, wherein the recovery unit is further configured to recover to execute the read operation after a second transaction is committed.
In one embodiment, the read target of the read operation is intermediate data written into the shared memory during the processing of the second transaction, wherein the recovery unit is further configured to recover the execution of the read operation based on a statement in a predetermined address of the shared memory during the execution of the second transaction, the statement indicating that the execution of the second transaction will no longer write the first variable.
In an embodiment, the read target of the read operation is intermediate data written into the shared memory during the processing of the second transaction, and the recovery unit is further configured to, after determining that the intermediate data includes a write value to the first variable in the second transaction, recover to execute the read operation, and record execution of the read operation in the shared memory.
In one embodiment, the first determining unit further comprises an acquiring subunit configured to acquire transaction data of a second transaction; and a first determining subunit configured to infer whether the second transaction is to write the first variable based on transaction data of the second transaction.
In one embodiment, the first determining subunit is further configured to infer whether the second transaction is to write the first variable by inputting the first variable and a function name called in the second transaction into a predetermined decision model.
In one embodiment, the apparatus further includes a third determination unit configured to determine whether there is a conflict transaction of a transaction number between the second transaction and the first transaction after the execution of the read operation in the first transaction is suspended, wherein the conflict transaction is a transaction that is inferred to be written to the first variable, and a second resumption unit configured to resume the execution of the read operation based on the execution of the second transaction in a case where there is no conflict transaction.
In one embodiment, a variable collision table is preset in the first node, and a collision probability of a first variable is recorded in the variable collision table, wherein the first determining unit further includes a generating subunit configured to generate a random number within a first predetermined range of values after starting execution of the code of the read operation in the first transaction, and a second determining subunit configured to infer whether a second transaction is to write the first variable by determining whether the random number is within a second predetermined range of values, which is within the first predetermined range of values and is determined based on the collision probability.
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.
By means of the scheme for executing transactions concurrently in a block chain according to the embodiment of the present specification, whether to suspend the reading operation on the variable is determined by determining the collision probability between transactions, 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, thereby avoiding collision between transactions and withdrawal of transactions with high probability, and accelerating the processing speed and improving the processing performance while ensuring the consistency of the calculation results.
Drawings
The embodiments of the present specification may be made more clear by describing the embodiments with reference to the attached drawings:
FIG. 1 illustrates a block chain system in accordance with an embodiment of the present description;
FIG. 2 illustrates a flow diagram of a method of concurrently executing transactions in a blockchain, according to one embodiment of the present description;
FIG. 3 shows a schematic form of a variable conflict table;
FIG. 4 shows a schematic form of a variable conflict table;
fig. 5 illustrates an apparatus 500 for concurrently executing transactions in a blockchain according to one embodiment of the present description.
Detailed Description
The embodiments of the present specification will be described below with reference to the accompanying drawings.
Fig. 1 shows a block chain system according to an embodiment of the present disclosure. As shown in fig. 1, the system includes a plurality of nodes (6 nodes are schematically shown in the figure) forming a block chain, and the nodes are connected in pairs, wherein the nodes include, for example, a node 11, a node 12, and a node 13. As known to those skilled in the art, in a blockchain, some nodes collect multiple transactions in the blockchain into a transaction pool and compete for billing rights. For example, node 11 in the figure becomes the accounting node by acquiring accounting rights. Node 11, after becoming an accounting node, performs multiple transactions in its transaction pool and packages the multiple transactions into blocks for transmission to other nodes, such as node 12. Node 12 will authenticate the block and similarly perform transactions in the block. After a predetermined number of nodes verify the block, i.e., the block is known to be known, other nodes in the block chain (e.g., node 13) will not need to continue verifying the block, but will perform transactions directly in the block to update the local related data.
In the case where the same variable is not involved in two transactions, the order of execution does not affect the final calculation result, whereas in the case where, for example, the first transaction includes a write to the variable k1, the second transaction includes a read to the variable k1, and the number of the first transaction precedes the second transaction, the first transaction becomes a conflicting transaction for the second transaction, that is, the second transaction must read the k1 value in the case where it is determined that the first transaction is no longer writing to its upcoming k1 value, otherwise the read k1 value is the wrong value. The number of the transaction corresponds to the submitting sequence of the transaction, and when the transaction is executed concurrently, in order to ensure that the final transaction execution result is the same, it is necessary to ensure that the submitting sequence of the transaction is the same as the submitting sequence when the transaction is executed serially. Meanwhile, in the embodiments of the present specification, in order to ensure that the execution results of the plurality of transactions by each node are the same, when the plurality of transactions are concurrently executed, the conflict of the access variables between the transactions is considered, so that the transaction is waited under the condition that the conflict probability of the concurrently executed transactions is relatively large, thereby avoiding the occurrence of the conflict. For example, as shown in fig. 1, each node may preset a variable conflict table in which variables that easily cause a transaction conflict are recorded according to the transaction execution history of the node. Thus, for example, in the node 11, after a read operation for the variable k1 is started while the second transaction is being executed, the variable conflict table in the node 11 will be referenced to determine whether k1 is a conflicting variable, and in the case where k1 is determined to be a conflicting variable, that is, there is a greater probability of a conflict between the second transaction and its previous transaction, thus suspending the read for k1 in the second transaction and waiting for the read to be performed after the submission of its previous transaction.
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, in the node, the probability of collision between transactions may also be obtained in other ways, or the second transaction may be read after other executions of its previous transaction. The process of concurrently executing transactions according to an embodiment of the present specification will be described in detail below.
Fig. 2 is a flow chart illustrating a method for concurrently executing transactions in a blockchain according to an embodiment of the present disclosure, where the method is executed at a first node in the blockchain, where a plurality of transactions including a first transaction including a read operation on a first variable are currently concurrently executed, and the method includes:
in step S202, after starting to execute the code of the read operation in the first transaction, it is inferred whether a second transaction is to write the first variable, wherein the second transaction is a transaction of the plurality of transactions having a transaction number smaller than the first transaction, wherein the transaction number corresponds to a predetermined submission order of transactions;
in step S204, in case it is inferred that a second transaction is about to write to the first variable, the read operation in the first transaction is suspended.
First, in step S202, after starting to execute the code of the read operation in the first transaction, it is inferred whether a second transaction is to write the first variable, wherein the second transaction is a transaction of the plurality of transactions having a transaction number smaller than the first transaction, wherein the transaction number corresponds to a predetermined commit order of transactions.
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 a plurality of transactions in a block, that is, the number order of each transaction is used as its respective submission order, and at the same time, by predetermining the collision probability between transactions, each transaction without dependency can be executed concurrently, and each transaction with dependency is executed serially according to the sequence of its number, thereby avoiding transaction collision, wherein, for the transactions 1 and 2 numbered sequentially, if the first variable is written in transaction 1 and read in transaction 2, transaction 2 depends on the result of transaction 1, and transaction 1 is a collision transaction of transaction 2.
In one embodiment, as described above, a variable conflict table is pre-set in each node of the blockchain, and the conflict variable records a conflict variable of the plurality of variables. FIG. 3 shows a schematic form of a variable conflict table. As shown in fig. 3, in the variable conflict table, a plurality of variables k1, k2, and … kn during execution of a plurality of transactions are listed, and a value corresponding to a conflicting variable among the plurality of variables is set to 1, and a value of a non-conflicting variable among the plurality of variables is set to 0. Thus, by querying the variable conflict table, it can be determined whether a particular variable is a conflicting variable. Such as variables that are susceptible to transaction conflicts. For example, the conflicting variables in the plurality of variables may be determined from a priori experience of a programmer to preset a variable conflict table. Alternatively, the determination may be made from historical data of existing executed transactions in the node, e.g., when a transaction in the historical data includes a read of, for example, variable k1, an average probability of a transaction prior to the transaction writing to the variable k1 is determined from the historical data. If the average probability is greater than a predetermined threshold, the variable k1 may be determined to be a conflicting variable. In one embodiment, a timestamp may be added to each variable in the table shown in FIG. 3, for example, for variable k1, each time an access conflict to variable k1 is found, the timestamp is updated, and when the table is queried, if the timestamp is found to be very far from the current time, the value of variable k1 is modified to 0. In one embodiment, the table may be updated periodically based on historical data for each predetermined period of time.
In one embodiment, after determining that k1 is a conflict variable based on a preset variable conflict table, according to a pessimistic policy, if the currently executed first transaction includes a read of the variable k1, then each transaction numbered less than the first transaction in the currently concurrently executed transactions is considered to be a conflict transaction of the first transaction, that is, each transaction is considered to be about to write to the variable k 1. Here, the transaction numbers correspond to the order of submission of the transactions, and the transaction numbers are smaller the earlier the order of submission of the transactions.
In one embodiment, a variable conflict table for each variable may be preset in the node, and the variable conflict table includes a conflict probability for each variable. FIG. 4 shows a schematic form of a variable conflict table. As shown in fig. 4, a plurality of variables k1, k2, … kn in the process of executing a plurality of transactions are listed in the variable conflict table, and the value corresponding to each variable ki in the table is the conflict probability of the variable. The probability of conflict may be determined, for example, based on historical transaction performance data. The variable conflict table shown in fig. 4 may be updated periodically. For example, in the variable collision table, the collision probability of k1 is 20%. If the currently executed first transaction includes a read of the variable k1, the collision probability of k1 indicates that the average probability that a transaction preceding the first transaction among the concurrently executed transactions writes to k1 is 20%, and thus, the collision transaction of the first transaction can be determined according to optimistic policies. Specifically, for example, a random number between 0 and 100 may be generated, and assuming that 0 to 40 are set to a predetermined range based on a probability of 20%, when the random number is in a range of 0 to 40 (including 40), it is considered that a preceding transaction of the first transaction will have a first variable written thereto, and when the random number is in a range of 40 to 100 (including 100), it is considered that a preceding transaction of the first transaction will not have the first variable written thereto, wherein the preceding transaction is a transaction executed concurrently with the first transaction and having a transaction number smaller than that of the first transaction. The predetermined range of random numbers to be used for inference may be determined based on the parameters of the loss caused by redo and wait respectively, such as: assuming that "waiting" would cause the cpu to be idle for 2ms and "redo" would cause the cpu to waste 10ms, the predetermined range may be determined to be between 0 and 20 when the collision probability is 20%, and set to be larger, e.g., 0 to 80, when the collision probability is 20%, if "waiting" would cause the cpu to be idle for 1ms and "redo" would cause the cpu to waste 10 ms.
In one embodiment, a variable collision table combining fig. 3 and fig. 4 may be preset in the node, in which when the collision probability of a variable is greater than a predetermined threshold, the collision value of the variable is set to 1, and when the collision probability of the variable is less than or equal to the predetermined threshold, the collision value of the variable is set to its actual collision probability. Therefore, when the collision probability of a variable is greater than a predetermined threshold, the variable can be directly determined as a collision variable through the variable collision table, and when the collision probability of a variable is less than or equal to the predetermined threshold, whether the variable is a collision variable can be determined through the above-mentioned manner of generating a random number. Thereby fusing pessimistic and optimistic policies.
In one embodiment, if the currently executed first transaction includes a read of variable k1, assuming the first transaction is currently executed by the first thread, the first thread may query transaction data for each prior transaction of the first transaction and determine from the transaction data a probability that the prior transaction writes to variable k1, thereby determining whether the prior transaction is a conflicting transaction for the first transaction. Specifically, where a preceding transaction, such as the first transaction, includes the second transaction, the first thread may query the name of the calling function for the second transaction and infer whether the second transaction is to write to the variable k1 by entering the function name and the variable k1 into a predetermined decision model. In one embodiment, the predetermined decision model includes, for example, a write probability table between each calling function and each variable, which determines a probability of writing each variable when calling the function, based on historical transaction execution data, or based on a specific code of the function. For example, if a write to a variable k [ n ] is included in the calling function, n is input by the transaction execution, e.g., n is 1, 2, or 3, then the probability of the write to k [1] by the function may be 1/3. Thus, by inputting the name of the calling function of the second transaction and the variable k1 into the decision model, it can be determined in the model whether the probability of writing the variable k1 by the second transaction is greater than a predetermined threshold based on the writing probability table, thereby inferring whether the second transaction will write to k 1. In one embodiment, the decision model is, for example, a decision model that performs data training through historical transactions, and after inputting the calling function name of the second transaction and the variable k1 read by the first transaction into the decision model, the decision model may infer whether the second transaction will write to the variable k 1.
In step S204, in case it is inferred that a second transaction is about to write to the first variable, the read operation in the first transaction is suspended.
In the case where it is inferred that the second transaction is about to write to the first variable as described above, that is, the second transaction is a conflicting transaction of the first transaction, the first transaction needs to suspend execution of the read operation, i.e., wait to read the value written to k1 by the second transaction, otherwise, the value k1 read by the first transaction will be an erroneous value, and after the erroneous read is performed, the read operation will be resumed subsequently and the transaction redo accordingly.
In one embodiment, after inferring that the second transaction is about to write to the variable k1 based on the variable conflict table or the variable conflict table, it is also necessary to determine whether the second transaction is a transaction previous to the first transaction, and in the case that the second transaction is a transaction previous to the first transaction, resuming execution of the read in the first transaction based on execution of the second transaction. That is, in this embodiment, after determining that the variable k1 is a conflict variable, each concurrently executed transaction prior to the first transaction is considered to be a conflict transaction of the first transaction, and therefore, it is necessary to wait until a previous transaction of the first transaction performs a corresponding operation before resuming the read operation in the first transaction.
Specifically, in an embodiment, it is assumed that the second transaction is a transaction before the first transaction, and the read object of the read operation is a submission result of the second transaction stored in the shared memory, that is, the first transaction cannot read the write value of the variable k1 in the second transaction until the second transaction is submitted. In this case, the read operation in the first transaction may resume after the second transaction commits.
In one embodiment, it is assumed that the second transaction is a transaction previous to the first transaction, and the read object of the read operation is intermediate data written into the shared memory during the processing of the second transaction. For example, when the second transaction is currently executed by the second thread, the second thread records the action of writing to k1 and the written k1 value as intermediate data in the shared memory after writing to k1 during the execution of the second transaction. After this write, the second thread, based on the preset code or compilation of code, may determine that k1 will not be subsequently written, and thus, the second thread may declare in the shared memory at a predetermined address: execution of the second transaction will no longer write the variable k1, so that after the first thread executing the first transaction reads the statement at the predetermined address, the wait described above may end, reading the value of the variable k1 written by the second thread from the intermediate data.
In one embodiment, it is assumed that the second transaction is a transaction previous to the first transaction, and the read object of the read operation is intermediate data written into the shared memory during the processing of the second transaction. For example, when the second transaction is currently executed by the second thread, the second thread records the action of writing to k1 and the written k1 value as intermediate data in the shared memory after writing to k1 during the execution of the second transaction. The first thread executing the first transaction may end the wait after determining that the second thread writes to k1 based on the intermediate data from which the value of the variable k1 written by the second thread was read. After the first thread performs the above reading, it records in the shared memory that it performed the reading of the variable k1 in the first transaction. Subsequently, for example, in the case where the second thread performs the write to the variable k1 again, the second thread will notify, for example, the transaction scheduler to re-execute the read and subsequent related operations in the first transaction, or to retire the first transaction, according to the record of the first thread in the shared memory.
In one embodiment, as described above, in the case where it is determined whether each preceding transaction is a conflict transaction of the first transaction by referring to the transaction data of the preceding transaction, in the case where it is determined that the second transaction is a conflict transaction of the first transaction, it is also necessary to determine whether there is a conflict transaction of the first transaction between the first transaction and the second transaction, that is, to determine whether the second transaction is a conflict transaction closest to the first transaction. Thus, after determining that the second transaction is the closest conflicting transaction to the first transaction, execution of the read operation in the first transaction may be resumed based on execution of the second transaction.
Fig. 5 illustrates an apparatus 500 for concurrently executing transactions in a blockchain, the apparatus being deployed in a first node in the blockchain, the first node currently concurrently executing a plurality of transactions, including a first transaction, the first transaction including a read operation on a first variable, according to one embodiment of the present specification, the apparatus including:
a first determining unit 51 configured to infer whether a second transaction is to write the first variable after starting execution of the code of the read operation in the first transaction, wherein the second transaction is a transaction of the plurality of transactions having a transaction number smaller than the first transaction, wherein the transaction number corresponds to a predetermined commit order of transactions;
a suspending unit 52 configured to suspend the read operation in the first transaction in case it is inferred that a second transaction is to write to the first variable.
In one embodiment, a variable conflict table is preset in the first node, and the variable conflict table records that the first variable is a conflict variable, wherein the first determining unit 51 is further configured to infer that the second transaction is to write the first variable based on the variable conflict table.
In one embodiment, the apparatus further comprises a second determining unit 53 configured to determine whether the second transaction is a previous transaction of the first transaction according to a commit order after suspending the execution of the read operation in the first transaction, and a first resuming unit 54 configured to resume the execution of the read operation based on the execution of the second transaction in a case where it is determined that the second transaction is a previous transaction of the first transaction according to a commit order.
In an embodiment, a read object of the read operation is a transaction commit result stored in the shared memory, wherein the first recovery unit 54 is further configured to recover to execute the read operation after the second transaction is committed.
In one embodiment, the read target of the read operation is intermediate data written into the shared memory during the processing of the second transaction, wherein the first recovery unit 54 is further configured to recover the execution of the read operation based on a statement in a predetermined address of the shared memory during the execution of the second transaction, the statement indicating that the execution of the second transaction will no longer write the first variable.
In an embodiment, the read target of the read operation is intermediate data written into the shared memory during the processing of the second transaction, and the first recovery unit 54 is further configured to, after determining that the intermediate data includes a write value to the first variable in the second transaction, recover to execute the read operation, and record the execution of the read operation in the shared memory.
In one embodiment, the first determining unit 51 further comprises an obtaining subunit 511 configured to obtain transaction data of the second transaction; and a first determining subunit 512 configured to infer whether the second transaction is to write the first variable based on transaction data of the second transaction.
In one embodiment, the first determining subunit 512 is further configured to infer whether the second transaction is to write the first variable by inputting the first variable and the name of the function called in the second transaction into a predetermined decision model.
In one embodiment, the apparatus further comprises a third determining unit 55 configured to determine whether there is a conflict transaction with a transaction number between the second transaction and the first transaction after suspending the execution of the read operation in the first transaction, wherein the conflict transaction is a transaction that is inferred to be written to the first variable, and a second resuming unit 56 configured to resume the execution of the read operation based on the execution of the second transaction in a case where there is no conflict transaction.
In one embodiment, a variable collision table is preset in the first node, and a collision probability of a first variable is recorded in the variable collision table, wherein the first determining unit 51 further includes a generating subunit 513 configured to generate a random number within a first predetermined range of values after starting execution of the code of the read operation in the first transaction, and a second determining subunit 514 configured to infer whether a second transaction is to write the first variable by determining whether the random number is within a second predetermined range of values, wherein the second predetermined range of values is within the first predetermined range of values and is determined based on the collision probability.
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.
By the scheme of executing transactions concurrently in a blockchain according to the embodiment of the present specification, whether to suspend the reading operation on the variable is determined by determining the collision probability between transactions, so that the transactions can be executed concurrently for a plurality of transactions without interdependencies; for multiple transactions with interdependencies, the transactions may be performed in series, thereby avoiding conflicts between transactions and redo of transactions with a high probability; for the situation that certain conflict probability exists between transactions, the method can carry out smooth transition between optimistic expectation and pessimistic expectation and balance between serially executing the wasted cpus and the transaction redoing wasted cpus, so that the processing speed is increased and the processing performance is improved while the consistency of the calculation result is ensured.
It is to be understood that the terms "first," "second," and the like, herein are used for descriptive purposes only and not for purposes of limitation, to distinguish between similar concepts.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
It will be further appreciated by those of ordinary skill in the art that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, computer software, or combinations of both, and that the components and steps of the examples have been described in a functional general in the foregoing description for the purpose of illustrating clearly the interchangeability of hardware and software. Whether these functions are performed in hardware or software depends on the particular application of the solution and design constraints. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied in hardware, a software module executed by a processor, or a combination of the two. A software module may reside in Random Access Memory (RAM), memory, Read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
The above-mentioned embodiments are intended to illustrate the objects, technical solutions and advantages of the present invention in further detail, and it should be understood that the above-mentioned embodiments are merely exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.
Claims (22)
1. A method of concurrently executing a plurality of transactions in a blockchain, the method being performed at a first node in the blockchain, the plurality of transactions including a first transaction including a read operation on a first variable, the method comprising:
after starting to execute the code of the read operation in the first transaction, inferring whether a second transaction is to write the first variable, wherein the second transaction is a transaction of the plurality of transactions having a transaction number that is less than the first transaction, wherein the transaction number corresponds to a predetermined commit order of transactions;
suspending execution of the read operation in the first transaction in the event that a second transaction is inferred to be writing to the first variable.
2. The method of claim 1, wherein a variable conflict table is pre-stored in the first node, the variable conflict table recording a first variable as a conflict variable, and wherein inferring whether the first variable is to be written for the second transaction comprises inferring that the first variable is to be written for the second transaction based on the variable conflict table.
3. The method of claim 2, further comprising, after suspending execution of the read operation in the first transaction, determining whether the second transaction is a transaction prior to the first transaction according to a commit order, in which case it is determined that the second transaction is a transaction prior to the first transaction according to a commit order, resuming execution of the read operation based on execution of the second transaction.
4. The method of claim 3, wherein a read target of the read operation is a transaction commit result stored in the shared memory, and wherein resuming execution of the read operation based on execution of the second transaction comprises resuming execution of the read operation after the second transaction commits.
5. The method of claim 3, wherein a read target of the read operation is intermediate data written to shared memory during processing of the second transaction, wherein resuming execution of the read operation based on execution of the second transaction comprises resuming execution of the read operation based on a statement in a predetermined address of shared memory during execution of the second transaction, the statement indicating that execution of the second transaction will no longer write to the first variable.
6. The method of claim 3, wherein the read target of the read operation is intermediate data written to the shared memory during the processing of the second transaction, and wherein resuming execution of the read operation based on the execution of the second transaction comprises resuming execution of the read operation after determining that the intermediate data includes a value written to the first variable in the second transaction, and recording the execution of the read operation in the shared memory.
7. The method of claim 1, wherein inferring whether a second transaction is to write to the first variable comprises obtaining transaction data for the second transaction; inferring whether the second transaction is to write to the first variable based on transaction data of the second transaction.
8. The method of claim 7, wherein inferring whether the second transaction is to write to the first variable based on transaction data for the second transaction comprises inferring whether the second transaction is to write to the first variable by inputting a function name called in the second transaction and the first variable into a predetermined decision model.
9. The method of claim 7, further comprising, after suspending execution of the read operation in the first transaction, determining whether there is a conflicting transaction with a transaction number between the second transaction and the first transaction, wherein the conflicting transaction is a transaction that is inferred to be written to the first variable, and, in the absence of the conflicting transaction, resuming execution of the read operation based on execution of the second transaction.
10. The method of claim 1, wherein a variable collision table is pre-stored in the first node, the variable collision table having recorded therein a collision probability of a first variable, wherein inferring whether a second transaction is to write to the first variable after initiating execution of the code for the read operation in the first transaction comprises generating a random number within a first predetermined range of values after initiating execution of the code for the read operation in the first transaction, and inferring whether a second transaction is to write to the first variable by determining whether the random number is within a second predetermined range of values, the second predetermined range of values being within the first predetermined range of values and being determined based on the collision probability.
11. An apparatus for concurrently executing a plurality of transactions in a blockchain, the apparatus being disposed in a first node in the blockchain, the plurality of transactions including a first transaction including a read operation on a first variable, the apparatus comprising:
a first determining unit configured to infer whether a second transaction is to write the first variable after starting execution of the code of the read operation in the first transaction, wherein the second transaction is a transaction of the plurality of transactions having a transaction number smaller than the first transaction, wherein the transaction number corresponds to a predetermined commit order of transactions;
a suspending unit configured to suspend execution of the read operation in the first transaction in a case where it is inferred that a second transaction is to write the first variable.
12. The apparatus according to claim 11, wherein a variable conflict table is preset in the first node, and the variable conflict table records a first variable as a conflict variable, and wherein the first determining unit is further configured to infer that a second transaction is to write the first variable based on the variable conflict table.
13. The apparatus of claim 12, further comprising a second determining unit configured to determine whether the second transaction is a previous transaction of the first transaction according to a commit order after suspending execution of the read operation in the first transaction, and a first resuming unit configured to resume execution of the read operation based on execution of the second transaction in a case where it is determined that the second transaction is a previous transaction of the first transaction according to a commit order.
14. The apparatus of claim 13, wherein a read target of the read operation is a transaction commit result stored in the shared memory, and wherein the first recovery unit is further configured to resume execution of the read operation after a second transaction commit.
15. The apparatus of claim 13, wherein a read target of the read operation is intermediate data written to shared memory during processing of the second transaction, and wherein the first recovery unit is further configured to resume execution of the read operation based on a statement in a predetermined address of shared memory during execution of the second transaction, the statement indicating that execution of the second transaction will no longer write to the first variable.
16. The apparatus according to claim 13, wherein the read target of the read operation is intermediate data written into the shared memory during the processing of the second transaction, and the first recovery unit is further configured to, after determining that the intermediate data includes a value written to the first variable in the second transaction, resume the execution of the read operation, and record the execution of the read operation in the shared memory.
17. The apparatus of claim 11, wherein the first determining unit further comprises an obtaining subunit configured to obtain transaction data for a second transaction; and a first determining subunit configured to infer whether the second transaction is to write the first variable based on transaction data of the second transaction.
18. The apparatus of claim 17, wherein the first determining subunit is further configured to infer whether the second transaction is to write the first variable by inputting a name of a function called in the second transaction and the first variable into a predetermined decision model.
19. The apparatus according to claim 17, further comprising a third determination unit configured to determine whether there is a conflict transaction of a transaction number between the second transaction and the first transaction after suspending execution of the read operation in the first transaction, wherein the conflict transaction is a transaction that is inferred to be written to the first variable, and a second resumption unit configured to resume execution of the read operation based on execution of the second transaction in a case where there is no conflict transaction.
20. The apparatus according to claim 11, wherein a variable collision table in which collision probabilities of first variables are recorded is preset in the first node, wherein the first determining unit further includes a generating subunit configured to generate a random number within a first predetermined numerical range after starting execution of the code of the read operation in the first transaction, and a second determining subunit configured to infer whether a second transaction is to write the first variable by determining whether the random number is within a second predetermined numerical range that is within the first predetermined numerical range and is determined based on the collision probabilities.
21. 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-10.
22. 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-10.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910818227.XA CN110648124B (en) | 2019-08-30 | 2019-08-30 | Method and apparatus for concurrently executing transactions in a blockchain |
| CN202110692747.8A CN113421073A (en) | 2019-08-30 | 2019-08-30 | Method and apparatus for concurrently executing transactions in a blockchain |
| TW109110268A TWI759708B (en) | 2019-08-30 | 2020-03-26 | Method and apparatus for concurrently executing transactions in a blockchain and computer-readable storage medium and computing device |
| PCT/CN2020/082698 WO2021036260A1 (en) | 2019-08-30 | 2020-04-01 | Method and apparatus for concurrently executing transactions in blockchain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910818227.XA CN110648124B (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 |
|---|---|---|---|
| CN202110692747.8A Division CN113421073A (en) | 2019-08-30 | 2019-08-30 | Method and apparatus for concurrently executing transactions in a blockchain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110648124A true CN110648124A (en) | 2020-01-03 |
| CN110648124B CN110648124B (en) | 2021-06-29 |
Family
ID=68991382
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910818227.XA Active CN110648124B (en) | 2019-08-30 | 2019-08-30 | Method and apparatus for concurrently executing transactions in a blockchain |
| CN202110692747.8A Pending CN113421073A (en) | 2019-08-30 | 2019-08-30 | Method and apparatus for concurrently executing transactions in a blockchain |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110692747.8A Pending CN113421073A (en) | 2019-08-30 | 2019-08-30 | Method and apparatus for concurrently executing transactions in a blockchain |
Country Status (3)
| Country | Link |
|---|---|
| CN (2) | CN110648124B (en) |
| TW (1) | TWI759708B (en) |
| WO (1) | WO2021036260A1 (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112001798A (en) * | 2020-10-28 | 2020-11-27 | 支付宝(杭州)信息技术有限公司 | Method and apparatus for concurrently executing transactions in a blockchain |
| CN112199204A (en) * | 2020-12-04 | 2021-01-08 | 支付宝(杭州)信息技术有限公司 | Method and device for processing transaction in block chain |
| WO2021036260A1 (en) * | 2019-08-30 | 2021-03-04 | 创新先进技术有限公司 | Method and apparatus for concurrently executing transactions in blockchain |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113656507B (en) * | 2021-08-26 | 2024-03-08 | 支付宝(杭州)信息技术有限公司 | Method and device for executing transaction in block chain system |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20160098723A1 (en) * | 2014-10-01 | 2016-04-07 | The Filing Cabinet, LLC | System and method for block-chain verification of goods |
| CN107688999A (en) * | 2017-08-11 | 2018-02-13 | 杭州秘猿科技有限公司 | A kind of parallel transaction based on block chain performs method |
| US20180158034A1 (en) * | 2016-12-07 | 2018-06-07 | International Business Machines Corporation | Dynamic reordering of blockchain transactions to optimize performance and scalability |
| US20180293556A1 (en) * | 2017-04-05 | 2018-10-11 | Samsung Sds Co., Ltd. | Method and system for processing blockchain-based real-time transaction |
| CN109636592A (en) * | 2017-10-20 | 2019-04-16 | 北京航空航天大学 | High-performance intelligence Contract Design |
| 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 |
| CN110163609A (en) * | 2019-05-28 | 2019-08-23 | 深圳前海微众银行股份有限公司 | Data processing method and device in a kind of block chain |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5701480A (en) * | 1991-10-17 | 1997-12-23 | Digital Equipment Corporation | Distributed multi-version commitment ordering protocols for guaranteeing serializability during transaction processing |
| US20090138890A1 (en) * | 2007-11-21 | 2009-05-28 | Arm Limited | Contention management for a hardware transactional memory |
| CN104572506B (en) * | 2013-10-18 | 2019-03-26 | 阿里巴巴集团控股有限公司 | A kind of method and device concurrently accessing memory |
| WO2017086983A1 (en) * | 2015-11-19 | 2017-05-26 | Hewlett Packard Enterprise Development Lp | Prediction models for concurrency control types |
| CN108874372B (en) * | 2018-06-20 | 2020-01-24 | 北京连琪科技有限公司 | Scale-based block chain contract implementation method and system |
| CN109598504B (en) * | 2018-10-25 | 2020-09-01 | 阿里巴巴集团控股有限公司 | Transaction processing method and device based on block chain and electronic equipment |
| CN109508337A (en) * | 2018-11-12 | 2019-03-22 | 杭州秘猿科技有限公司 | A kind of transaction is parallel to execute method, apparatus, electronic equipment and system |
| CN110648124B (en) * | 2019-08-30 | 2021-06-29 | 创新先进技术有限公司 | Method and apparatus for concurrently executing transactions in a blockchain |
-
2019
- 2019-08-30 CN CN201910818227.XA patent/CN110648124B/en active Active
- 2019-08-30 CN CN202110692747.8A patent/CN113421073A/en active Pending
-
2020
- 2020-03-26 TW TW109110268A patent/TWI759708B/en active
- 2020-04-01 WO PCT/CN2020/082698 patent/WO2021036260A1/en active Application Filing
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20160098723A1 (en) * | 2014-10-01 | 2016-04-07 | The Filing Cabinet, LLC | System and method for block-chain verification of goods |
| US20180158034A1 (en) * | 2016-12-07 | 2018-06-07 | International Business Machines Corporation | Dynamic reordering of blockchain transactions to optimize performance and scalability |
| US20180293556A1 (en) * | 2017-04-05 | 2018-10-11 | Samsung Sds Co., Ltd. | Method and system for processing blockchain-based real-time transaction |
| CN107688999A (en) * | 2017-08-11 | 2018-02-13 | 杭州秘猿科技有限公司 | A kind of parallel transaction based on block chain performs method |
| CN109636592A (en) * | 2017-10-20 | 2019-04-16 | 北京航空航天大学 | High-performance intelligence Contract Design |
| 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 |
| CN110163609A (en) * | 2019-05-28 | 2019-08-23 | 深圳前海微众银行股份有限公司 | Data processing method and device in a kind of block chain |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2021036260A1 (en) * | 2019-08-30 | 2021-03-04 | 创新先进技术有限公司 | Method and apparatus for concurrently executing transactions in blockchain |
| CN112001798A (en) * | 2020-10-28 | 2020-11-27 | 支付宝(杭州)信息技术有限公司 | Method and apparatus for concurrently executing transactions in a blockchain |
| CN112991061A (en) * | 2020-10-28 | 2021-06-18 | 支付宝(杭州)信息技术有限公司 | Method and apparatus for concurrently executing transactions in a blockchain |
| CN112991061B (en) * | 2020-10-28 | 2023-06-09 | 支付宝(杭州)信息技术有限公司 | Method and apparatus for concurrently executing transactions in blockchain |
| CN112199204A (en) * | 2020-12-04 | 2021-01-08 | 支付宝(杭州)信息技术有限公司 | Method and device for processing transaction in block chain |
| CN112199204B (en) * | 2020-12-04 | 2021-03-12 | 支付宝(杭州)信息技术有限公司 | Method and device for processing transaction in block chain |
Also Published As
| Publication number | Publication date |
|---|---|
| TWI759708B (en) | 2022-04-01 |
| TW202109292A (en) | 2021-03-01 |
| WO2021036260A1 (en) | 2021-03-04 |
| CN110648124B (en) | 2021-06-29 |
| CN113421073A (en) | 2021-09-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110648124B (en) | Method and apparatus for concurrently executing transactions in a blockchain | |
| CN110675255B (en) | Method and apparatus for concurrently executing transactions in a blockchain | |
| JP5379711B2 (en) | Computer-implemented method, system, and computer program for verifying correctness of execution history, including multiple operations executed in parallel on data structure | |
| US20180158034A1 (en) | Dynamic reordering of blockchain transactions to optimize performance and scalability | |
| CN108681565B (en) | Block chain data parallel processing method, device, equipment and storage medium | |
| CN110704112B (en) | Method and apparatus for concurrently executing transactions in a blockchain | |
| CN110706101B (en) | Method and apparatus for concurrently executing transactions in a blockchain | |
| Lowe | Testing for linearizability | |
| CN110689344B (en) | Method and apparatus for concurrently executing transactions in a blockchain | |
| CN110706108B (en) | Method and apparatus for concurrently executing transactions in a blockchain | |
| CN111767337B (en) | Block verification method, device and equipment | |
| CN113867903B (en) | Method and device for determining parallel conflict domain of intelligent contract in block chain | |
| Aguilera et al. | The mailbox problem | |
| Groves et al. | Trace-based derivation of a scalable lock-free stack algorithm | |
| WO2021057165A1 (en) | Method for concurrently executing transactions in blockchain, and device | |
| CN115203218A (en) | Method for solving problem of inconsistent consensus when block link points process transaction in parallel | |
| Szekeres | Designing Storage and Privacy-Preserving Systems for Large-Scale Cloud Applications | |
| Groves | Trace-based derivation of a lock-free queue algorithm | |
| Sadoghi et al. | Coordination-Avoidance Concurrency | |
| CN116450316A (en) | Method, device, electronic equipment and storage medium for parallel transaction processing | |
| Lohstroh | Theory and Application of Multithreading The Actor Model | |
| Ding et al. | Parallelization of termination checkers for algebraic software | |
| Gramoli et al. | Optimism for boosting concurrency | |
| Lamport et al. | The Mailbox Problem |
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 | ||
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40019635 Country of ref document: HK |
|
| TA01 | Transfer of patent application right |
Effective date of registration: 20200925 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Innovative advanced technology Co.,Ltd. Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant before: Advanced innovation technology Co.,Ltd. Effective date of registration: 20200925 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Advanced innovation technology Co.,Ltd. Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands Applicant before: Alibaba Group Holding Ltd. |
|
| TA01 | Transfer of patent application right | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |