CN113127212B - Method and device for processing transaction in blockchain - Google Patents

Abstract

Embodiments of the present specification provide a method and apparatus for processing transactions in a blockchain, the method performed by a blockchain link point, comprising: acquiring a first transaction waiting for a speculative execution, wherein the speculative execution is pre-execution of the transaction before the transaction consensus is finished; in the event that it is determined that the second transaction being speculatively executed previously accessed the variable in the first transaction for which access was requested, speculatively executing the first transaction is performed after speculatively executing the second transaction is completed.

Description

Method and device for processing transaction in blockchain

The present application is a divisional application of patent application with application number 202011399167.1, entitled "method and apparatus for processing transactions in blockchain", filed on 12/4/2020.

Technical Field

Embodiments of the present disclosure relate to the field of blockchain technology, and more particularly, to a method and apparatus for processing transactions in a blockchain.

Background

In blockchains, transactions are typically performed after the transactions are consensus, which results in less efficient transaction processing because the transaction consensus takes more time. In order to improve transaction processing efficiency, in the prior art, transactions are speculatively executed before consensus, and execution results of the transactions are saved, and the generated execution results are not submitted immediately, but are submitted when the transactions are confirmed to be available when waiting for formal execution. When the transaction is formally executed after consensus is conducted on the transaction, if the execution result of the speculative execution is determined to be effectively available, the execution result of the speculative execution is directly used without executing the transaction again. In the implementation scheme, the speculative execution of the transaction does not consider the read-write conflict with other transactions, and when the variables accessed by different transactions are not overlapped, the implementation scheme may have better effect, but when the read-write conflict of the variables occurs to different transactions, the execution result of the speculative execution cannot be used, and the transaction processing efficiency is reduced.

Disclosure of Invention

The embodiment of the specification provides a transaction processing scheme before consensus, which can reduce the probability of failure of the execution of a gambling machine and improve the transaction processing efficiency in a blockchain.

To achieve the above object, a first aspect of the present specification provides a method of processing transactions in a blockchain, the method performed by a blockchain link point, comprising: acquiring a first transaction waiting for a speculative execution, wherein the speculative execution is pre-execution of the transaction before the transaction consensus is finished; in the event that it is determined that the second transaction being speculatively executed previously accessed the variable in the first transaction for which access was requested, speculatively executing the first transaction is performed after speculatively executing the second transaction is completed.

In one implementation of the first aspect, the method is performed by a blockchain billing node, the method further comprising: and according to the speculative execution sequence of the second transaction and the first transaction, proposing a consensus proposal for the execution sequence of the second transaction and the first transaction.

In one implementation of the first aspect, the determining that the second transaction being speculatively executed previously accessed the variable in the first transaction that requested access includes determining, based on a variable access table, that the second transaction being speculatively executed previously accessed the variable in the first transaction that requested access.

In an implementation manner of the first aspect, the determining that the second transaction being speculatively executed previously accessed the variable in the first transaction that requested access includes any one of: determining that a second transaction being speculatively executed previously read a variable requested to be written in the first transaction; determining that a second transaction being speculatively executed previously written variables in the first transaction that requested reading; determining that a second transaction being speculatively executed previously written a variable requested to be written in the first transaction.

In one implementation of the first aspect, performing speculative execution of the first transaction after completion of speculative execution of the second transaction includes obtaining a pre-recorded first time at which the second transaction began speculative execution, determining a second time at which to begin speculative execution of the first transaction based on the first time, and recording the first transaction and the second time in a blocking transaction table in chronological order of the second time to await speculative execution.

In one implementation of the first aspect, the method further includes, in case the speculative execution of the first transaction is successful, saving the speculative execution result of the first transaction in a storage space allocated for the speculative execution transaction, and recording the first transaction in a speculative execution transaction table in a time sequence in which the speculative execution is started or ended of the first transaction.

In an implementation manner of the first aspect, according to an execution order of the second transaction and the first transaction, the proposing a consensus proposal for the execution order of the second transaction and the first transaction includes obtaining a plurality of transactions arranged in sequence in a table of executed transactions that have been commissioned as a consensus proposal.

In one implementation of the first aspect, the method further includes, after obtaining the plurality of transactions in the speculative execution transaction table, as a consensus proposal, a plurality of transactions in the blocking transaction table arranged in sequence.

In one implementation of the first aspect, the acquiring the first transaction waiting for speculative execution includes acquiring the first transaction from the blocking transaction table.

In one implementation of the first aspect, the method further comprises, after acquiring the first transaction, speculatively executing the first transaction; the performing speculative execution of the first transaction after the speculative execution of the second transaction is completed in a case where it is determined that the second transaction being speculatively executed previously accessed the variable requested to be accessed in the first transaction includes ending speculative execution of the first transaction in a case where it is determined that the second transaction being speculatively executed previously accessed the variable to be accessed in the first transaction in the course of speculatively executing the first transaction, and performing speculative execution of the first transaction again after the speculative execution of the second transaction is completed.

In one implementation of the first aspect, performing speculative execution of the first transaction after completion of speculative execution of the second transaction includes storing values of variables written to the first transaction request in a storage space allocated for speculative execution of the first transaction during speculative execution of the first transaction, and reading values of variables read by the first transaction request from values of the respective variables stored in the storage space.

A second aspect of the present specification provides an apparatus for processing transactions in a blockchain, the apparatus deployed at a blockchain node, comprising: an acquisition unit configured to acquire a first transaction waiting for a speculative execution, wherein the speculative execution is a pre-execution of the transaction before a transaction consensus ends; and a speculative execution unit configured to perform speculative execution of the first transaction after the speculative execution of the second transaction is completed, in a case where it is determined that the second transaction being speculatively executed previously accessed the variable requested to be accessed in the first transaction.

In one implementation of the second aspect, the apparatus is deployed at a blockchain billing node, the apparatus further comprising: and a consensus proposal unit configured to propose a consensus proposal for the execution sequence of the second transaction and the first transaction according to the speculative execution sequence of the second transaction and the first transaction.

In one embodiment of the second aspect, the speculative execution unit is further configured to determine, based on a variable access table, that a second transaction being speculatively executed previously accessed a variable in the first transaction that requested access.

In an embodiment of the second aspect, the speculative execution unit is further configured to perform any one of: determining that a second transaction being speculatively executed previously read a variable requested to be written in the first transaction; determining that a second transaction being speculatively executed previously written variables in the first transaction that requested reading; determining that a second transaction being speculatively executed previously written a variable requested to be written in the first transaction.

In one embodiment of the second aspect, the speculative execution unit includes an acquisition subunit configured to acquire a first time at which a pre-recorded second transaction starts speculative execution, a determination subunit configured to determine a second time at which to start speculative execution of the first transaction based on the first time, and a recording subunit configured to record the first transaction and the second time in a blocking transaction table in chronological order of the second time to wait for speculative execution.

In one embodiment of the second aspect, the apparatus further includes a recording unit configured to, in a case where the speculative execution of the first transaction is successful, save, in a storage space allocated for the speculative execution exchange, a result of the speculative execution of the first transaction, and record, in a speculative execution transaction table, the first transaction in a time sequence in which the start or end of the speculative execution of the first transaction.

In one embodiment of the second aspect, the consensus proposal unit is further configured to obtain a plurality of transactions arranged in sequence in the posted execution transaction table as a consensus proposal.

In one implementation of the second aspect, the consensus proposal unit is further configured to obtain a plurality of transactions arranged in order in the blocked transaction table as a consensus proposal after the plurality of transactions in the speculative execution transaction table.

In an implementation manner of the second aspect, the obtaining unit is further configured to obtain the first transaction from the blocking transaction table.

In an implementation manner of the second aspect, the speculative execution unit is further configured to speculatively execute the first transaction after acquiring the first transaction; in the process of speculatively executing the first transaction, in the case that the second transaction in the speculative execution is determined to have previously accessed the variable to be accessed in the first transaction, the speculative execution of the first transaction is ended, and the speculative execution of the first transaction is performed again after the speculative execution of the second transaction is completed.

In one embodiment of the second aspect, the speculative execution unit is further configured to store, in a storage space allocated for speculative execution of the first transaction, values of variables written by the first transaction request, and to read values of variables read by the first transaction request from values of respective variables stored in the storage space, during speculative execution of the first transaction.

A third aspect of the present description provides a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method provided by the first aspect of the present description.

A fourth aspect of the present specification provides a computing device comprising a memory having executable code stored therein and a processor which, when executing the executable code, implements the method provided by the first aspect of the present specification.

Because all nodes in the blockchain determine the execution sequence of the transaction speculation based on the sequence of access variables when speculating to execute the transaction before consensus, the uncertainty of the execution sequence of the transaction speculation of all nodes can be avoided to a large extent, and the sequence of consensus transaction is determined according to the sequence of the speculation, so that the speculation execution results of the transactions executed speculatively can be multiplexed with high probability when the transactions are executed after consensus of all nodes, and the transaction processing efficiency in the blockchain is improved.

Drawings

The embodiments of the present specification may be further clarified by describing the embodiments of the present specification with reference to the accompanying drawings:

FIG. 1 illustrates a schematic diagram of transaction propagation, blocking, and execution according to one embodiment;

FIG. 2 illustrates a process by which a billing node processes a transaction;

FIG. 3 illustrates a method of processing transactions in a blockchain in accordance with embodiments of the present description;

FIG. 4 illustrates a flow diagram of a method of a thread speculation in a blockchain node to perform a transaction;

FIG. 5 illustrates a flow chart of a thread operating on a variable access table when writing variables in speculatively executing transactions;

FIG. 6 illustrates an apparatus for processing transactions in a blockchain in accordance with embodiments of the present description.

Detailed Description

Embodiments of the present specification will be described below with reference to the accompanying drawings.

FIG. 1 illustrates a schematic diagram of transaction propagation, blocking, and execution according to one embodiment. First, the blockchain network includes a plurality of nodes, and each node can communicate with each other. Of the nodes of the blockchain network, at least some nodes are billing-capable nodes. The accounting node may package the collected transactions into a predetermined blockform to form new blocks in the blockchain.

Suppose that some accounting node Bob in the network obtains a transaction Tx. The transaction Tx may be a transaction issued by a user terminal of a blockchain connected to the node, or the transaction Tx may be a transaction forwarded by another node Alice. And, the transaction Tx may be a general transfer transaction, a transaction to create a smart contract, or a transaction to call a smart contract.

The accounting node Bob will maintain a transaction pool locally and put the received transaction Tx into the transaction pool. When there are enough transactions in the pool, node Bob extracts a portion of the transactions from the pool and packages them into blocks. Typically, when a transaction is placed in a pool, or when a transaction is extracted from the pool for packaging, the node verifies the transaction to verify its legitimacy. After Bob packages a portion of the transaction, it broadcasts its own packaged transaction (i.e., chunk) in the blockchain network in hopes of consensus. After consensus is reached for the blocks, each node performs transactions in the agreed blocks in a consensus sequence to maintain consistency of the data content recorded at the nodes throughout the network.

Fig. 2 shows the process by which the accounting node processes the transaction. As shown in fig. 2, in brief, the accounting node firstly checks the transactions in the local transaction pool, packages the transactions into blocks in a certain order, then initiates the consensus, waits for the consensus result, and executes the transactions in the sequence arrangement in the consensus block after acquiring the consensus result. It can be seen that in this process, the steps are performed serially in sequence, and thus the processing efficiency of the transaction is low.

In one related technique, the blockchain node speculatively executes transactions in the transaction pool before the consensus on the block ends (or reaches a consensus). The speculative execution of a transaction may be understood as pre-execution or prospective execution of the transaction, if it has not been determined whether the transaction should be executed or not, and the execution order of the transaction with other transactions, resulting in execution results, but rather than immediately submitting the execution results, the execution results are cached in memory for use as execution results of executing the transaction if it is determined that the execution results are valid after the transaction is executed. The speculatively executed process and the consensus process may be performed in parallel. When the consensus result is obtained so as to formally execute the transaction, judging whether the execution result of the speculative execution is effectively available, if so, directly submitting the execution result without re-executing the transaction. However, this scheme of speculative execution does not take into account read-write conflicts with other transactions at the stage of speculative execution of the transaction. In the case of read-write conflicts when parallel speculations execute different transactions because of access to the same variable, due to minor differences in the actual operating environment, the speculative execution order of the different transactions at one node may be such that the read-write order of the variable is read-before-write, and the speculative execution order of the different transactions at another node may be such that the read-write order of the variable is read-before-write. In formally executing the two transactions, the execution results of speculative execution of nodes having different transaction orders from the consensus may not be available, thereby reducing transaction processing efficiency.

In order to further improve the transaction processing efficiency in the blockchain, according to at least one embodiment of the present disclosure, during the speculative execution transaction stage, read-write collision detection is performed on the transaction, a transaction lag process with read-write collision with the executing transaction is performed, so as to prevent the read-write collision of the speculative execution transaction, and consensus proposal is performed according to the order of the speculative execution transaction, so as to further improve the probability that the execution result of the speculative execution is available, thereby improving the transaction processing efficiency.

Specific implementation steps in the transaction processing method provided in the embodiment of the present specification will be described in detail below.

Fig. 3 illustrates a method of processing transactions in a blockchain, performed by blockchain points, which may be embodied as any device, platform, or cluster of devices with computing, processing capabilities, in accordance with embodiments of the present description. The transaction processing method comprises the following steps: step S302, obtaining a transaction Tx2 waiting for speculative execution; step S304, determining whether other transactions being speculatively executed have previously accessed the variable requested to be accessed in transaction Tx2; in the case that the determination is yes, step S306 is performed, and the speculative execution transaction Tx2 is performed after the speculative execution of the determined transaction; in the case where the determination result is no, step S308 is performed, and the gambling execution transaction Tx2. The specific execution of the above steps is described below, respectively.

First, in step S302, a transaction Tx2 waiting for speculative execution is acquired.

Each time a transaction is generated or received by a node in the blockchain, the transaction is placed in the transaction pool to await consensus and execution. To speculatively execute transactions in advance of a transaction consensus, the blockchain node may obtain transactions from a pool of transactions that were not speculatively executed for speculative execution. In one embodiment, the transactions of the un-commissioned execution in the transaction pool may be recorded in the blockchain node as a pending commission execution transaction table shown in table 1, which is stored, for example, in a storage space (e.g., memory space) allocated for the commission execution transaction, along with the variable access table, the blocking transaction table, and the commissioned execution transaction table described below.

TABLE 1

Transaction information	Tx1	Tx2	Tx3	…
					Start speculative execution time	t1	t2		…

As the nodes continue to acquire transactions, information for these transactions is added sequentially (e.g., left-to-right order) in the table of transactions to be speculatively executed based on the time of acquisition. Each column of the to-be-commissioned execution transaction table corresponds to a transaction. In one embodiment, the first row of the to-be-commissioned execution transaction table is used to record transaction content of each transaction. In another embodiment, the first row of the to-be-commissioned execution transaction table is used to record a memory address of transaction content of the corresponding transaction for linking to the transaction content of the corresponding transaction. The second row of the to-be-commissioned execution transaction table is used for recording the starting commission execution time of the corresponding transaction when the corresponding transaction starts commission execution and is not executed to be completed. As shown in table 1, where transaction Tx1 is recorded as the transaction being speculatively executed, it begins speculatively executed for a time t1, such as is currently being executed by thread 1 for transaction Tx1. After the leftmost transaction (transaction Tx 2) that has not started speculative execution is acquired from table 1, the time for which the start of speculative execution of transaction Tx2 is recorded as t2 in table 1, and transaction Tx3 in table 1 is a transaction for which speculative execution has not yet started. By recording the time of starting speculative execution of transactions in a table of transactions to be speculatively executed, each thread performing speculative execution may determine whether read-write conflicts exist between transactions based on the time and set the time of late speculative execution of conflicting transactions, as will be described in detail below.

It will be appreciated that the to-be-commissioned transaction table is not limited to having the form shown in table 1, for example, the to-be-commissioned transaction table may not record the start-commission execution time of each transaction, but record the start-commission execution time of the transaction in an address of the transaction content of the stored transaction after the thread starts to commission the transaction, so that other threads may determine from the address whether the transaction starts to commission the transaction, and the start-commission execution time of the transaction.

In addition, the thread is not limited to obtaining transactions waiting for speculative execution from a table of transactions waiting for speculative execution, and in another embodiment, the thread may also obtain transactions waiting for speculative execution from a table of blocked transactions, which will be described in more detail below.

In step S304, it is determined whether there are other transactions being speculatively executed that have previously accessed the variable in transaction Tx2 for which access was requested.

To facilitate read-write collision detection, the read-write condition of each variable for transactions that have begun speculative execution may be recorded by a variable access table as shown in table 2.

TABLE 2

As shown in table 2, each column of the variable access table from column 2 corresponds to a variable, for example, column 2 corresponds to variable a and column 3 corresponds to variable b. The variable access table is, for example, a hash table, i.e., the memory address of each column of the table corresponds to the hash value of the corresponding variable, e.g., the memory address of column 2 in table 2 corresponds to the hash value of variable a, and when there is access to variable a in a transaction, the read-write record of variable a can be found by calculating the hash value of variable a. The "L" in row 1 of the variable access table is a lock identification, indicating that a thread is operating on that column. In addition, "Pos1" in the variable access table is used to record the record position of a transaction accessing the variable in a pending execution transaction table (or a blocking transaction table to be described later), and "t1" is used to record the start-speculation execution time of a transaction accessing the variable, for example, to indicate column 1 in table 1.

Thread 2 starts executing transaction Tx2 after acquiring transaction Tx2, assuming that transaction Tx2 includes (read or write) access to variable a, thread 2 first finds the read-write record entry for variable a in table 2 by calculating the hash value of variable a, and locks the read-write record entry if it is determined that the read-write record entry is not locked, i.e., marks "L" in row 1 corresponding to variable a in table 2. Then, thread 2 reads the read/write record entry of variable a.

In one case, a write request for variable a is included in transaction Tx2, and the read-write record of variable a recorded in the variable access table is as shown in table 2. Thread 2 reads column 1 of table 1 based on Pos1 in the read record entry of variable a in table 2, compares column 1 with column 2 of table 2 to record t1, and can determine that (Pos 1, t 1) in table 2 corresponds to Tx1, i.e., current Tx1 is speculatively executing, thereby determining that transaction Tx1 being speculatively executing previously read variable a, and that transaction Tx2 has a read-write collision with Tx1 currently being speculatively executing.

In another case, a write request for variable a is included in transaction Tx2, and a write to variable a is recorded in the variable access table, for example, transaction Tx 1. In the case where it is determined that the transaction Tx1 is currently being speculatively executed based on the write record by a similar procedure as above, it may also be determined that the transaction Tx1 being speculatively executed has previously written the variable a, and that the transaction Tx2 has a write-write conflict with the transaction Tx1 being speculatively executed.

In another case, a read request for variable a is included in transaction Tx2, and a write to variable a is recorded in the variable access table, for example, transaction Tx 1. In determining that transaction Tx1 is currently being speculatively executed based on the write record by a process similar to that described above, it may also be determined that transaction Tx1 being speculatively executed has previously written variable a and that transaction Tx2 has a read-write collision with transaction Tx1 being speculatively executed.

In another case, if the read record entry in column 2 of table 2 is (Pos 1, t 0), thread 2 compares t0 to be inconsistent with t1 in column 1 of table 1, indicating that the corresponding transaction of (Pos 1, t 0) has been completed or executed by a late speculation (described below), and thus thread 2 may delete (Pos 1, t 0) recorded in table 2. Thereafter, if transaction Tx2 does not request access to other variables, thread 2 may determine that there is an access conflict with Tx2 for a transaction that is not currently being speculatively executed.

In another case, the transaction Tx2 includes a read request for the variable a, and the variable access table records the read of the variable a by the transaction Tx1, the thread 2 may determine that there is an access conflict with Tx2 for the transaction that is not currently being speculatively executed, the thread 2 may execute step S308, record the read information of the variable a by the transaction Tx2 in the variable access table, and continue the speculatively executed transaction Tx2.

It will be appreciated that the read/write collision table shown in table 2 is merely illustrative and is not intended to limit the form of the read/write collision table in the embodiments of the present specification. For example, the variables in the read-write conflict table may not necessarily be operated on mutually exclusive by way of locking, such as by operating on an atomic operation. In addition, the position in table 1 is not necessarily recorded in the read-write conflict table, but the transaction number may be directly recorded to indicate the current transaction accessing the variable, and the record of the transaction in the read-write conflict table may be deleted after the transaction speculative execution is completed.

In addition, the variable access table is not limited to include a read record table entry and a write record table entry, for example, the variable access table includes only a variable access record, and a thread records a previous access to the variable a in the variable access table as long as, for example, the variable a is read or written in the process of speculatively executing the transaction, and in this embodiment, compared with the above embodiment, the variable a is read in advance for the transaction Tx1 being speculatively executed, and the blocking speculatively executed for the transaction Tx2 is also performed in the case of requesting the variable a to be read in the transaction Tx2, but since the blocking speculatively executed for the transaction Tx2 can be performed for both the foregoing read-write conflict and the write-write conflict, the transaction processing efficiency of the node can still be improved as a whole.

In addition, although it is described in the above description that step S304 is performed after starting the speculative execution of the transaction Tx2, the embodiment of the present specification is not limited thereto, and for example, the thread may read in advance a variable requesting reading and writing in the transaction Tx2 after acquiring the transaction Tx2, and perform step S304.

In the case that the determination result in step S304 is no, the thread 2 determines that the transaction Tx2 has no access conflict with the transaction currently being speculatively executed, and the thread 2 may execute step S308 to speculatively execute the transaction Tx2. Specifically, thread 2 records (Pos 2, t 2) in the access record of variable a in the variable access table, releases the lock on variable a in table 2, and continues to speculatively execute transaction Tx2, where Pos2 is the position of record transaction Tx2 in the to-be-speculatively executed transaction table or the blocking transaction table, and t2 is the time of starting speculatively execute transaction Tx2. If access to other variables is not included in the transaction Tx2, thread 2 may complete the speculative execution of transaction Tx2, store the execution results of the speculative execution of transaction Tx2 in memory, record transaction Tx2 in the speculative execution transaction table set in the blockchain node in the order in which the transactional speculative execution was completed, and delete the column of transaction Tx2 in the transaction table to be speculatively executed (or the blocked transaction table), e.g., move the relevant contents of Tx3 in table 1 into column 2. If transaction Tx2 includes access to variable b in addition to variable a, then it is determined, based on the read-write record of variable b, similar to above, whether transaction Tx2 has an access conflict with other transactions being speculatively executed.

In the case that the determination of the step S304 is yes, the thread 2 executes a step S306 to speculatively execute the transaction Tx2 after speculatively executing the determined transaction (e.g., the transaction Tx 1).

In the event that thread 2 determines that transaction Tx2 has an access conflict with transaction Tx1 currently being speculatively executed, it may release the lock on variable a in the read-write conflict table and cause transaction Tx2 to lag speculative execution to ensure that transaction Tx2 is speculatively executed after transaction Tx1 speculative execution is completed. By ensuring that the speculative execution transaction Tx2 follows the speculative execution transaction Tx1, the order in which the respective nodes speculatively execute transactions Tx1 and Tx2 is consistent, thereby preventing some nodes from losing their speculative execution results when executing the transaction formally following consensus.

The speculative execution of transaction Tx2 after transaction Tx1 may be ensured in a number of ways. In one embodiment, a blocking transaction table as shown in Table 3 may be provided in the blockchain node.

TABLE 3 Table 3

Blocking transaction information	Tx2
				Time to unblock	t3
Start speculative execution time

To delay execution of transaction Tx2, thread 2 deletes the record for transaction Tx2 from table 1, moves the relevant contents of Tx3 in table 1 into column 3, and records the information for transaction Tx2 in the blocking transaction table as shown in table 3. As shown in table 3, assuming that the blocking transaction table is not currently recording a blocking transaction, thread 2 may record a memory address storing the transaction contents of transaction Tx2 in the blocking transaction information of column 2 from the left to link to transaction Tx2, and record time t3 of the unblocking of transaction Tx2 in the unblocking time of column 2, line 2, i.e., the earliest time that transaction Tx2 may be speculatively executed again. Time t3 is determined by adding a predetermined length of time (e.g., 200 microseconds) to the start speculative execution time t1 of transaction Tx1, which is used to ensure that transaction Tx1 has been speculatively executed after time t3 (including time t 3). The predetermined length of time is determined based on the projected transaction execution time and the process scheduling perturbation. For example, for a system that is less time consuming to execute a transaction, substantially undisturbed in the execution phase, has little fluctuation in performance such as memory access, the predetermined length of time may be set to be shorter, otherwise the predetermined length of time may be set to be longer.

As shown in Table 3, the blocking transaction table further comprises starting speculative execution time of the blocking transaction, the thread can acquire the transaction waiting for speculative execution from the table for speculative execution, and after the thread acquires the transaction from the blocking transaction table and starts speculative execution, the thread can record the starting speculative execution time of the corresponding transaction in the blocking transaction table so as to calculate the unblocking time of other transactions when read-write conflict exists between the thread and the other transactions. Similarly to the above-described transaction table to be speculative, the start speculative execution time may be recorded not in the blocking transaction table but in the recording address of the transaction contents of the corresponding transaction.

When speculative execution of further transactions is blocked, subsequent blocked transactions may be recorded in a left to right order in table 3. In this case, when a thread acquires a transaction waiting for speculative execution in executing the above-described step S302, the thread may first acquire the leftmost blocked transaction in the blocked transaction table for speculative execution, and the other threads may acquire each blocked transaction in the blocked transaction table in the order from left to right. In the case where a transaction in the blocking transaction table is emptied or the unblocking time of the acquired blocking transaction is later than the current time, the thread may acquire a transaction from the pending execution transaction table for speculative execution that does not begin speculative execution. By thus acquiring transactions for speculative execution, the blocking transaction table may be implemented as a first-in-first-out queue (First Input First Output, FIFO). It will be appreciated that the order of acquiring transactions described above is not necessary, as long as it is ensured that transactions in the blocking transaction table are performed after the unblocking time recorded in the table. After thread 2 records transaction Tx2 in the blocking transaction table, where since transaction Tx2 is the transaction with the earliest unblocking time in the blocking transaction table, thread 2 may acquire other transactions in the pending execution transaction table for speculative execution.

For example, after completing transaction Tx1 by thread 1, transaction Tx2 may be obtained from the blocking transaction table as described above, thread 1 first determines whether current time t4 is equal to or greater than blocking time t3 corresponding to transaction Tx2 recorded in the blocking transaction table, in case t4 is equal to or greater than t3, thread 1 may start speculatively executing transaction Tx2 and execute step S304 described above again on transaction Tx2, in case it is determined that no other transaction being speculatively executed has access conflict with transaction Tx2, thread 1 may execute step S308 to complete speculative execution on transaction Tx2, store the execution result of speculative execution on transaction Tx2, delete the column of transaction Tx2 in table 3, and record transaction Tx2 in the speculative execution transaction table in order of complete speculative execution of transaction Tx2. In another embodiment, the thread may record in the posted execution transaction table based on the chronological order of the beginning of the posted execution of transaction Tx2 after the posted execution completes transaction Tx2. Table 4 shows the contents recorded in the speculative execution transaction table.

TABLE 4 Table 4

Tx1

Tx2

As shown in table 4, since in this case the transaction Tx2 was speculatively executed after the transaction Tx1 was speculatively executed, the transaction Tx1 was speculatively executed after the completion of the speculative execution of the transaction Tx2, and thus the transaction Tx1 was already recorded in the speculatively executed transaction table, and thus the identification of the transaction Tx2 was recorded in the speculatively executed transaction table on the right side of the location where the identification of the transaction Tx1 was recorded, in the order of the transactional speculatively executed transaction table.

The foregoing generally describes a method process for a blockchain node to speculatively execute transactions. The execution of the transaction processing method in the blockchain provided in the embodiments of the present specification is described below in terms of threads.

FIG. 4 illustrates a flow diagram of a method of a thread speculation in a blockchain node to perform a transaction. Assume that a blockchain node includes a plurality of threads for speculatively executing transactions in parallel, each thread executing the flow shown in fig. 4. First, in step S401, the thread acquires the earliest unblocking time etime in the blocking transaction table at which the speculative execution of the transaction is not started. As described above, when a thread obtains transaction speculation execution, it is first determined whether there is a transaction in the blocked transaction table for which unblock time has elapsed, to speculatively execute the blocked transaction first. For example, referring to Table 3, assuming that columns 3 and 4 from the left in Table 3 record blocked transactions, since the blocked transaction table records transactions with unblocking times from first to last in left to right order, if Tx2 is indicated in Table 3 as not having been speculatively executed, then t3 is the earliest unblocking time etime.

In step S402, the current time ctime is acquired. In step S403, it is determined whether ctime is equal to or greater than etime, i.e. it is determined whether the unblocking time etime has currently elapsed, and if ctime is equal to or greater than unblocking time etime (e.g. t3 in table 3), it is indicated that transaction Tx2 can be currently speculatively executed again, and therefore the thread executes step S404 to obtain the transaction corresponding to etime in the blocked transaction table (i.e. transaction Tx 2).

If ctime is less than the unblocking time etime, it indicates that all transactions in the blocked transaction table are not unblocked, and thus, the thread executes step S405 to acquire a transaction in the transaction table to be speculatively executed that is not started to be speculatively executed. Referring to table 1, after transaction Tx2 is deleted from the to-be-speculative execution transaction table as described above, the earliest received transaction in table 1 for which speculative execution is not started is Tx3, and thus, the thread may acquire transaction Tx3 for speculative execution.

In the case of acquiring transaction Tx2 from the blocking transaction table, the thread performs step S406, recording ctime as the start-speculative execution time of transaction Tx2 in row 3 in column 2 in table 3. In the case where the transaction Tx3 is acquired from the to-be-commissioned execution transaction table, the thread performs step S406, and the start-commissioned execution time of the transaction Tx3 is recorded in table 1.

Then, the thread executes step S407, and the speculative execution transaction operates on the variable access table.

For example, after the thread begins speculative execution of transaction Tx2 again, the thread determines whether to continue speculative execution of transaction Tx2 by operating on the variable access table since read and/or write requests for variables are included in transaction Tx2, a flowchart of the thread's operation on the variable access table will be described in detail below with respect to fig. 5.

Based on the operation on the variable access table, if it is confirmed that the transaction Tx2 has no access conflict with other transactions currently being speculatively executed, the transaction Tx2 may be continuously executed such that the speculative execution of the transaction Tx2 is successful, so that the thread may perform step S409 to record the transaction Tx2 into the speculative execution transaction table, i.e., delete the transaction Tx2 from the blocking transaction table, and record the transaction Tx2 into the speculative execution transaction table in the time sequence in which the speculative execution is successful, as shown in table 4. Meanwhile, the thread saves in memory the result of speculative execution of transaction Tx2, including the value of the variable to which the value of the read variable is writable. In the process of executing the speculative execution, when reading the value of the variable a, it is first determined whether the value of the variable a is maintained in a memory space (or other storage space) allocated for executing the transaction by the speculative execution, if the value of the variable a is maintained in the memory, the value of the variable a is read from the memory, if the value of the variable a is not found in the memory, the value of the variable a can be read from the world state database, and the value of the variable a is stored in the memory. When a variable a is written during speculative execution, the value of the variable a maintained in memory is modified without updating the value into the world state database.

Based on the operation on the variable access table, if the thread confirms that transaction Tx2 has an access conflict with other transactions currently being speculatively executed, step S410 may be performed to record transaction Tx2 into the blocking transaction table. Specifically, the transaction Tx2 currently recorded in the blocking transaction table is deleted first, and the information of the transaction Tx2 is recorded again in the blocking transaction table in the order of the re-determined unblocking time of the transaction Tx2, so that the transaction Tx2 lags behind the speculative execution again.

After executing step S410 or step S409, the thread may return to step S401 to start a new loop.

FIG. 5 illustrates a flow chart of a thread operating on a variable access table when writing variables in speculatively executing transactions.

Having described various access conflicts between different transactions that may occur during speculative execution, one type of read-write conflict between transactions is schematically illustrated in FIG. 5, i.e., a transaction currently speculatively executed by a thread (e.g., transaction Tx 2) includes a write request to a variable (e.g., variable a), the thread determining whether there is any other transaction being speculatively executed that previously performed a read operation on variable a based on a variable access table, thereby determining whether there is a read-write conflict. It will be appreciated that for other types of access conflicts between different transactions, a process similar to that shown in FIG. 5 may be used to operate, for example, the thread may also determine whether there is a write conflict by previously writing to variable a based on a variable access table to determine whether there are other transactions being speculatively executed.

Referring to fig. 5, after the thread executes an instruction (or request) to read variable a in transaction Tx2, the thread executes step S501, obtaining a variable lock for variable a in the variable access table. Referring to Table 2 above, a thread may obtain a variable lock, for example, by performing a mutex operation on row 1 of column 2 corresponding to variable a, thereby recording an "L" at that location if it is determined that the location is empty, for indicating that the information for variable a in the variable access table has been locked. The mutual exclusivity operation is, for example, an atomic operation, and the like, and is not limited herein.

In step S502, the thread determines whether the read record entry for variable a is empty, i.e., whether a read of variable a was made during speculative execution of a transaction. If the read record entry is empty, indicating that there has been no speculative execution of the transaction reading variable a, the thread may execute step S507 to record the information of the current transaction in the write record entry, i.e., the record location of the record transaction Tx2 (i.e., the location in the to-be-speculative execution transaction table or the blocked transaction table of record transaction Tx 2) and the start speculative execution time. The record may be a plug-in record or an overlay record. The inserted record is that the current transaction information is recorded after the transaction information recorded before, but the information of the previous transaction is not covered, and each transaction information in the inserted record can be in a form of a linked list. The overwrite type record is to overwrite the transaction information recorded before with the current transaction information, namely, only the latest transaction information is recorded in the write record table. Step S508 may then be performed to return the variable lock for variable a, and step S509 may be performed to return the identification to continue speculative execution. So that the thread can write to variable a and continue speculatively executing transaction Tx2.

When the thread determines in step S502 that the read record entry of the variable a is not empty, the thread executes step S503 to obtain Pos and corresponding time bt in the read record entry of the variable a. Referring to the above-described method of recording transaction information in the write record entry, transaction information of a plurality of transactions in which the variable was read in the past may be recorded in the read record entry in an inserted manner, or only transaction information of the latest transaction in which the variable was read in the past may be recorded in an overlaid manner. In the case where only the latest transaction information is recorded in the read record entry of the variable a, refer to table 2, i.e., read (Pos 1, t 1), where bt=t1, pos1 is the position where the latest transaction is recorded, and depending on whether the transaction is obtained from the to-be-commissioned execution transaction table or the blocking transaction table, the Pos may be the position in the to-be-commissioned execution transaction table or the position in the blocking transaction table, for example, where Pos1 is the 1 st column in the to-be-commissioned execution transaction table as shown in table 1. After that, the thread executes step S504 to obtain the start-speculative execution time ct of the transaction corresponding to Pos. Specifically, the thread may read the start speculative execution time ct (whose value is t 1) recorded in column 1 of the transaction table to be speculative. Then, the thread performs step S505 to compare whether bt is equal to ct. In the case where transaction information of a plurality of transactions having accessed the variable a in the past is recorded in the read record entry of the variable a, the thread may perform steps S503 to S505 with respect to the transaction information of each transaction, which will not be described in detail herein.

If it is determined in step S505 that bt is not equal to ct, it is indicated that the transaction recorded in the read record entry, which is already the outdated information, has been executed or blocked from being executed, and the read operation of the transaction on the variable a has now been terminated, so that there is no read-write conflict with the currently executed transaction, so that the thread executes step S506, deletes the current information from the read record entry, and thereafter executes steps S507 to S509, and the execution of steps S507 to S509 will be described in detail herein. If it is determined at step S505 that bt=ct, it is explained that the transaction recorded in the read record entry is currently being speculative in execution, and that the transaction has a read-write conflict with the transaction currently being executed by the thread. Thus, in order to ensure the read-write consistency of each node, the thread will end the speculative execution of the current transaction and cause the current transaction to be executed with a delay, specifically, the thread executes step S508 to release the lock, namely, delete the variable lock of the variable in the variable access table, then execute step S509 to return an end speculative execution identifier, the thread will continue to execute step S410 in fig. 4 after executing the step, record the transaction into the blocking transaction table, and in executing the step, the thread determines the unblocking time of the current transaction based on the start speculative execution time (i.e., ct) of the transaction having read-write conflict with the current transaction.

The above describes the process of speculatively executing transactions in the blockchain node prior to transaction consensus, and the accounting node in the blockchain also speculatively executes transactions in the transaction pool by the method described above, and at the same time, the accounting node initiates a consensus proposal to block the consensus transaction according to the transactions in the transaction pool at a predetermined time. To ensure that the results of execution of the speculative execution are largely available, the accounting node may initiate a consensus proposal according to the order of transactions that have been speculatively executed.

In one embodiment, as described above, each of the transactions that have been speculatively executed is recorded in the node in the order of the speculative execution by means of the speculative execution transaction table as shown in table 4, so that the accounting node may first obtain the plurality of transactions in the order from the speculative execution transaction table as the plurality of transactions in the same order in the consensus proposal.

After acquiring the plurality of transactions as a consensus proposal, the accounting node may also acquire a plurality of transaction arrangements arranged in sequence from the blocking transaction table as shown in table 3 as a consensus proposal together after the plurality of transactions having already agreed to proposal if the number of the plurality of transactions having already agreed to proposal is insufficient to constitute a block. If the number of transactions for which the consensus proposal is still insufficient, the accounting node may also obtain from the table of transactions to be speculatively executed as shown in table 1 a plurality of transactions arranged in sequence together as a consensus proposal after the plurality of transactions for which the proposal has been consensus.

By thus setting the transactions in the consensus proposal and the arrangement order thereof, the following accounting node can directly use the results of the speculative execution of the transactions as the results of the formal execution, since the preceding transactions in the consensus proposal coincide with the ordered transactions that have been speculatively executed, in executing the plurality of transactions of the consensus. Since the plurality of transactions arranged in the middle in the consensus proposal are sequentially acquired from the blocking transaction table, a part of the plurality of transactions arranged in the front may have been executed, and the partial execution result is stored, the execution of the transaction may be completed using the partial execution result. Other non-accounting nodes may directly use the execution results of the speculative execution of the transaction locally for transactions in the consensus proposal that have been speculatively executed and in which the order of the speculative execution in the consensus proposal is consistent with the order of the speculative execution in executing the consensus, and may re-execute the transaction in the event that the world state of the transaction to be executed after the consensus is consistent with the world state of the transaction when the speculative execution of the transaction is executed after the consensus, or else discard the execution results of the speculative execution for transactions in the consensus proposal.

Because all nodes in the blockchain determine the execution sequence of the transaction speculation based on the sequence of the access variables when speculating to execute the transaction before consensus, the uncertainty of the execution sequence of the transaction speculation of all nodes can be avoided to a large extent, and the sequence of the consensus transaction is determined according to the sequence of the speculation, so that the speculation execution results of the transaction executed by speculation can be multiplexed with high probability when the transaction is executed after consensus of all nodes, and the transaction processing efficiency is improved.

Fig. 6 illustrates an apparatus 600 for processing transactions in a blockchain, the apparatus 600 deployed at a blockchain node for performing the methods of fig. 3-5 of the present description, the apparatus 600 comprising:

an acquisition unit 61 configured to acquire a first transaction waiting for a speculative execution, wherein the speculative execution is a pre-execution of a transaction before a transaction consensus ends;

the speculative execution unit 62 is configured to perform speculative execution of the first transaction after the speculative execution of the second transaction is completed, in a case where it is determined that the second transaction being speculatively executed previously accessed a variable in the first transaction that is requested to be accessed.

In one implementation of the second aspect, the apparatus 600 is deployed at a blockchain billing node, the apparatus 600 further comprising: a consensus proposal unit 63 configured to propose a consensus proposal for the execution order of the second transaction and the first transaction according to the speculative execution order of the second transaction and the first transaction.

In one embodiment, the speculative execution unit 62 is further configured to determine, based on the variable access table, that a second transaction being speculatively executed previously accessed a variable in the first transaction that requested access.

In one embodiment, the speculative execution unit 62 is further configured to perform any one of: determining that a second transaction being speculatively executed previously read a variable requested to be written in the first transaction; determining that a second transaction being speculatively executed previously written variables in the first transaction that requested reading; determining that a second transaction being speculatively executed previously written a variable requested to be written in the first transaction.

In one embodiment, the speculative execution unit 62 includes:

an acquisition subunit 621 configured to acquire a pre-recorded first time at which the second transaction began speculative execution,

A determination subunit 622 configured to determine a second time to start gambling the first transaction based on the first time,

a recording subunit 623 configured to record the first transaction and the second time in the blocking transaction table in chronological order of the second time to await speculative execution.

In an embodiment, the apparatus 600 further comprises a recording unit 64 configured to, in case of successful speculative execution of the first transaction, save the speculative execution result of the first transaction in a storage space allocated for the speculative execution transaction, record the first transaction in a speculative execution transaction table in a time sequence in which the speculative execution starts or ends of the first transaction.

In one embodiment, the consensus proposal unit 63 is further configured to obtain a plurality of transactions arranged in sequence in the speculative execution transaction table as a consensus proposal.

In one embodiment, the consensus proposal unit 63 is further configured to obtain a plurality of transactions arranged in order in the blocked transaction table as a consensus proposal after the plurality of transactions in the speculative execution transaction table.

In an embodiment, the obtaining unit 61 is further configured to obtain the first transaction from the blocking transaction table.

In one embodiment, the speculative execution unit 62 is further configured to speculatively execute the first transaction after the first transaction is acquired; in the process of speculatively executing the first transaction, in the case that the second transaction in the speculative execution is determined to have previously accessed the variable to be accessed in the first transaction, the speculative execution of the first transaction is ended, and the speculative execution of the first transaction is performed again after the speculative execution of the second transaction is completed.

In one embodiment, the speculative execution unit is further configured to store, during speculative execution of the first transaction, values of variables written by the first transaction request in a storage space allocated for speculative execution of the transaction, and to read values of variables read by the first transaction request from values of respective variables stored in the storage space.

The present embodiments also provide a computer-readable storage medium having a computer program stored thereon, which when executed in a computer, causes the computer to perform the method as shown in fig. 3 to 5 of the present specification.

Embodiments of the present disclosure also provide a computing device including a memory and a processor, where the memory stores executable code, and the processor implements the methods shown in fig. 3 to 5 of the present disclosure when executing the executable code.

It should be understood that the description of "first," "second," etc. herein is merely for simplicity of description and does not have other limiting effect on the similar concepts.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments.

The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can 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 are also possible or may be advantageous.

Those of ordinary skill would further appreciate that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, in computer software, or in a combination of the two, and that the elements and steps of the examples have been generally described in terms of function in the foregoing description to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Those of ordinary skill in the art may implement the described functionality using different approaches for each particular application, but such implementation is not to be considered as beyond the scope of the present application. The software modules may be disposed 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 foregoing description of the embodiments has been provided for the purpose of illustrating the general principles of the invention, and is not meant to limit the scope of the invention, but to limit the invention to the particular embodiments, and any modifications, equivalents, improvements, etc. that fall within the spirit and principles of the invention are intended to be included within the scope of the invention.

Claims (11)

1. A method of processing transactions in a blockchain, the method performed by blockchain links points, comprising:

acquiring a first transaction waiting for a speculative execution, wherein the speculative execution is pre-execution of the transaction before the transaction consensus is finished;

performing speculative execution of the first transaction after the speculative execution of the second transaction is completed in the event that it is determined that the second transaction being speculatively executed previously accessed a variable in the first transaction that was requested to be accessed;

and recording the sequence of the speculative execution and the execution result of the speculative execution of the first transaction and the second transaction, wherein the sequence of the speculative execution is used for judging whether the execution result of the speculative execution is correct or not in the execution process of the first transaction and the second transaction.

2. The method of claim 1, wherein determining that the second transaction being speculatively executed previously accessed the variable in the first transaction that requested access comprises determining, based on a variable access table, that the second transaction being speculatively executed previously accessed the variable in the first transaction that requested access.

3. The method of claim 2, wherein the determining that the second transaction being speculatively executed previously accessed the variable in the first transaction requesting access comprises any one of: determining that a second transaction being speculatively executed previously read a variable requested to be written in the first transaction; determining that a second transaction being speculatively executed previously written variables in the first transaction that requested reading; determining that a second transaction being speculatively executed previously written a variable requested to be written in the first transaction.

4. The method of claim 2, wherein performing speculative execution of the first transaction after completion of speculative execution of a second transaction comprises obtaining a first time at which a second transaction begins speculative execution, determining a second time at which to begin speculative execution of the first transaction based on the first time.

5. The method of claim 4, further comprising, in the event that speculative execution of the first transaction is successful, saving the speculative execution results of the first transaction in a memory space allocated for speculative execution transactions, recording the first transaction in a speculative execution transaction table in a chronological order of a start or end of speculative execution of the first transaction.

6. The method of claim 5, further comprising, after determining a second time, recording the first transaction and the second time in a blocking transaction table in a chronological order of the second time to await speculative execution.

7. The method of claim 6, the obtaining a first transaction awaiting speculative execution comprising obtaining the first transaction from the blocking transaction table.

8. The method of claim 1, further comprising, after acquiring the first transaction, speculatively executing the first transaction;

the performing speculative execution of the first transaction after the speculative execution of the second transaction is completed in a case where it is determined that the second transaction being speculatively executed previously accessed the variable requested to be accessed in the first transaction includes ending speculative execution of the first transaction in a case where it is determined that the second transaction being speculatively executed previously accessed the variable to be accessed in the first transaction in the course of speculatively executing the first transaction, and performing speculative execution of the first transaction again after the speculative execution of the second transaction is completed.

9. The method of claim 1, wherein performing speculative execution of the first transaction after completion of speculative execution of a second transaction comprises storing values of variables written to by the first transaction request in a memory space allocated for speculative execution of the first transaction during speculative execution of the first transaction, and reading values of variables read by the first transaction request from values of the respective variables stored in the memory space.

10. An apparatus for processing transactions in a blockchain, the apparatus deployed at a blockchain node, comprising:

an acquisition unit configured to acquire a first transaction waiting for a speculative execution, wherein the speculative execution is a pre-execution of the transaction before a transaction consensus ends;

a speculative execution unit configured to perform speculative execution of the first transaction after completion of speculative execution of a second transaction in a case where it is determined that the second transaction being speculatively executed previously accessed a variable in the first transaction that is requested to be accessed;

and the recording unit is configured to record the sequence of the speculative execution of the first transaction and the second transaction and the execution result of the speculative execution, wherein the sequence of the speculative execution is used for judging whether the execution result of the speculative execution is correct in the execution process of the first transaction and the second transaction.

11. A computing device comprising a memory having executable code stored therein and a processor, which when executing the executable code, implements the method of any of claims 1-9.