CN116244373A

CN116244373A - Transaction execution method, blockchain system, master node and slave storage device

Info

Publication number: CN116244373A
Application number: CN202211734886.3A
Authority: CN
Inventors: 王毅飞
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-12-30
Filing date: 2022-12-30
Publication date: 2023-06-09

Abstract

A method of performing transactions in a blockchain, a blockchain system, a master node, and a slave storage device, the method comprising: after the computing device completes pre-execution of the first transaction, sending a pre-execution read set of the first transaction to the slave storage device, the pre-execution read set including a version of a variable read during pre-execution of the first transaction; determining from the storage device whether a conflict exists between the pre-execution read set and the first version set of the first transaction; in the event that a conflict is determined to exist, the computing device is instructed to re-pre-execute the first transaction, wherein the primary storage device stores a second set of versions including a most recent second version of the plurality of variables in the blockchain, the first set of versions being updated based on the second set of versions.

Description

Transaction execution method, blockchain system, master node and slave storage device

Technical Field

Embodiments of the present disclosure relate to the field of blockchain technology, and more particularly, to a method of executing transactions in a blockchain, a blockchain system, a master node, and a slave storage device in the master node.

Background

Blockchain (Blockchain) is a new application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. In the block chain system, the data blocks are combined into a chain data structure in a sequential connection mode according to the time sequence, and the data blocks are ensured to be non-tamperable and non-counterfeitable in a cryptographic mode. When the blockchain node executes a plurality of transactions in the block, the transaction execution speed can be increased by executing the transactions in parallel. However, transactions that invoke smart contracts are typically not executed in parallel because the variables accessed cannot be predicted before execution.

Disclosure of Invention

The invention aims to provide a method for executing transactions in a blockchain, the blockchain, a master node and a slave storage device, which improve the execution speed of the transactions in the blockchain.

A first aspect of the present specification provides a method of performing a transaction in a blockchain, the blockchain including a master node and a slave node, the master node including a slave storage device, a master storage device and a computing device, the method comprising:

the computing device, upon completion of pre-execution of a first transaction, transmitting a pre-execution read set of the first transaction to the secondary storage device, the pre-execution read set including a version of a variable read during pre-execution of the first transaction;

The slave storage device determining whether a pre-execution read set of the first transaction conflicts with a locally stored first version set, the first version set comprising a first version of a plurality of variables in a blockchain; in the event that a conflict is determined to exist, instruct the computing device to re-pre-execute the first transaction,

the main storage device stores a second version set, the second version set comprises the latest second version of a plurality of variables in a blockchain, the second version set is updated based on a pre-execution write set of a transaction after conflict detection of the pre-execution read set of the transaction by the main storage device passes, and the first version set is updated based on the second version set.

A second aspect of the present specification provides a method of executing a transaction in a blockchain, the blockchain including a master node and a slave node, the master node including a slave storage device, a master storage device and a computing device, the method being performed by the slave storage device, comprising:

receiving a pre-execution read set of a first transaction from the computing device, the pre-execution read set including a version of a variable read during pre-execution of the first transaction;

Determining whether a conflict exists between a pre-execution read set of the first transaction and a locally stored first version set, the first version set including a first version of a plurality of variables in a blockchain, and, if a conflict is determined to exist, directing the computing device to re-pre-execute the first transaction,

A third aspect of the present specification provides a blockchain system including a master node and a slave node, the master node including a slave storage device, a master storage device and a computing device,

the computing device is configured to send a pre-execution read set of a first transaction to the secondary storage device after completion of pre-execution of the first transaction, the pre-execution read set including a version of a variable read during pre-execution of the first transaction;

The slave storage device is used for determining whether a pre-execution read set of the first transaction conflicts with a locally stored first version set, and the first version set comprises a first version of a plurality of variables in a blockchain;

the computing device is configured to send a pre-execution read-write set of the first transaction to the primary storage device in the event that the secondary storage device determines that there is no conflict, the pre-execution read-write set including a pre-execution write set and the pre-execution read set, the pre-execution write set including values of variables written during pre-execution of the first transaction;

the main storage device is used for determining whether the pre-execution read set of the first transaction and the locally stored second version set have conflict, and updating the second version set based on the pre-execution write set of the first transaction in the case that no conflict exists; recording the first transaction sequence into a commit transaction queue; transmitting a plurality of transactions in the commit transaction queue that are ordered in a previously recorded order, an order in which the plurality of transactions are ordered in the commit transaction queue, and a pre-execution read-write set of the plurality of transactions to the slave node; instruct the slave storage device to update the first version set according to the second version set;

The slave node is used for executing the plurality of transactions according to the arrangement sequence of the plurality of transactions and the pre-execution read-write set of each transaction.

A fourth aspect of the present specification provides a master node in a blockchain, the master node comprising a slave storage device, a master storage device and a computing device,

the slave storage device is used for determining whether a pre-execution read set of the first transaction conflicts with a locally stored first version set, and the first version set comprises a first version of a plurality of variables in a blockchain; in the event that a conflict is determined to exist, instruct the computing device to re-pre-execute the first transaction,

A fifth aspect of the present specification provides a slave storage device in a blockchain master node, the master node further comprising a master storage device and a computing device, the slave storage device comprising:

a receiving unit for receiving a pre-execution read set of a first transaction from the computing device, the pre-execution read set comprising a version of a variable read during pre-execution of the first transaction;

a determining unit, configured to determine whether a pre-executed read set of the first transaction conflicts with a locally stored first version set, where the first version set includes a first version of a plurality of variables in a blockchain; in the event that a conflict is determined to exist, instruct the computing device to re-pre-execute the first transaction,

A sixth 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 according to the second aspect.

A seventh aspect of the present specification provides a slave storage device in a blockchain master node, comprising a memory having executable code stored therein and a processor that when executing the executable code implements the method as described in the second aspect.

According to the scheme provided by the embodiment of the specification, when the master node in the blockchain pre-executes the transaction, the conflict among the transactions is considered, and the sequence of transaction submission is determined according to the sequence of each transaction passing through the pre-execution conflict detection, so that the world state of the slave node when executing the transaction is consistent with the world state of the master node when pre-executing the transaction under the condition that the master node is not disliked. The master node periodically updates the pre-execution state set and the pre-execution version set in the slave storage device, reads the pre-execution state from the pre-execution state set in the slave storage device when the transaction is pre-executed, and firstly carries out conflict detection on the transaction through the slave storage device after the pre-execution transaction is completed, so that the burden of the master storage device is reduced, and the system performance is improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings that are needed in the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a block chain architecture diagram as applied to one embodiment of the present disclosure;

FIG. 2 is a block diagram of a master node and a slave node of a blockchain provided in an embodiment of the present disclosure;

FIG. 3 is a flow chart of a method for executing transactions between a master node and a slave node according to one embodiment of the present disclosure;

FIG. 4 is a block diagram of a slave storage device in a blockchain master node provided in an embodiment of the present disclosure.

Detailed Description

In order to make the technical solutions in the present specification better understood by those skilled in the art, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.

FIG. 1 illustrates a block chain architecture diagram as applied to embodiments of the present description. As shown in fig. 1, the blockchain includes 6 nodes, for example, a master node 1 and slave nodes 2 to 5. The connections between nodes are schematically represented as P2P (Peer to Peer) connections. The nodes all store the full amount of ledgers, i.e. the state of all blocks and all accounts. Wherein each node in the blockchain generates the same state in the blockchain by performing the same transaction, each node in the blockchain storing the same state database. Instead, the master node 1 may be responsible for receiving transactions from clients and initiating consensus offers to each slave node, including, for example, information on a plurality of transactions in a block to be blocked (e.g., block B1) and the order of submission of each transaction. After the nodes in the blockchain have successfully agreed upon the consensus proposal, each node may execute the plurality of transactions according to the commit order in the consensus proposal, thereby generating a blockb 1.

It will be appreciated that the blockchain shown in fig. 1 is merely exemplary, and that the present embodiments are not limited to application to the blockchain shown in fig. 1, but may also be applied to blockchain systems including sharding, for example.

In addition, while 6 nodes are shown in FIG. 1 as being included in a blockchain, embodiments of the present description are not limited thereto, but may include other numbers of nodes. Specifically, the nodes included in the blockchain may meet the bayer fault tolerance (Byzantine Fault Tolerance, BFT) requirements. The bayer fault tolerance requirement is understood to be that the bin node may exist inside the blockchain, and the blockchain does not show the bin behavior. In general, some bayer fault-tolerant algorithms require a node number greater than 3f+1, where f is the number of bayer nodes, e.g., the practical bayer fault-tolerant algorithm PBFT (Practical Byzantine Fault Tolerance).

In the related art, in order to increase an execution Transaction Per Second (TPS) index in a blockchain, it is required to increase the execution speed of transactions. To this end, the execution speed of transactions may be increased in the blockchain node by executing the transactions in parallel. In one embodiment, the blockchain node may execute transactions in parallel through multiple processes in a single machine, and in another embodiment, the blockchain node may be deployed in a server cluster to execute transactions in parallel through multiple servers. Generally, for transfer transactions, the block link points first divide a plurality of transactions into a plurality of transaction groups according to accounts accessed by the transactions, and the same accounts are not accessed among the transaction groups, so that each transaction group can be executed in parallel. However, when a smart contract is invoked in a transaction, the variables accessed in the transaction cannot be predicted prior to execution of the transaction, and thus multiple transactions cannot be effectively grouped, and thus transactions cannot be executed in parallel.

The embodiment of the present disclosure provides a scheme for executing transactions in parallel in a blockchain as shown in fig. 1, which can effectively improve TPS in the blockchain.

Fig. 2 shows a block diagram of a master node 1 and a slave node (e.g., slave node 2) of a blockchain provided by an embodiment of the present description. As shown in fig. 2, the master node 1 includes at least one computing device, a master storage device 12, and at least one slave storage device, and one computing device (computing device 11) and one slave storage device (slave storage device 13) are shown in fig. 2 as examples. The slave node 2 includes a consensus module 22 and a calculation module 23. The master node 1 may, for example, be connected with a client so that the computing device 11 may receive a plurality of transactions from the client. After receiving each transaction, computing device 11 pre-executes the transaction, resulting in a pre-executed read-write set of the transaction. The computing device 11 may pre-execute the received transaction in parallel by multiple threads, or multiple computing devices in the master node 1 may pre-execute multiple transactions received by the master node 1 from clients in parallel. The pre-execution read-write set comprises a pre-execution read set and a pre-execution write set, wherein the pre-execution read set can specifically comprise at least a key (key) of a read variable and a version number (version) of a variable value (value) generated in the process of pre-execution transaction, the pre-execution read set can also comprise a value (value) of the variable, and the pre-execution write set can specifically be a key value pair of the written variable generated in the process of pre-execution transaction. In one embodiment, the partial pre-execution state data in the blockchain is stored in the master storage device 12 and the plurality of slave storage devices, respectively, for example, the pre-execution version set SV12 is stored in the master storage device 12, and the pre-execution version set S13 is stored in the slave storage device 13. When the computing device 11 reads the state of the variable in a pre-execution transaction, the state value of the variable may be read from a state database, the pre-execution version set SV12 in the main storage device 12, or from the pre-execution version set S13 in the storage device 13.

The master storage device 12 includes a conflict detection module 121 and stores a pre-execution version set SV12, and the slave storage device 13 includes a conflict detection module 131 and stores a pre-execution version set SV13. After the pre-execution of the transaction, computing device 11 first sends a pre-execution read set of the transaction to slave storage device 13. The conflict detection module 131 in the slave storage device 13 may perform a first pre-execution conflict detection on a transaction based on the pre-execution version set SV13 and the pre-execution read set of the transaction. Specifically, whether the pre-execution read set and the pre-execution version set SV13 of the transaction have a conflict is detected from the storage device 13, and if the version number of a certain variable in the pre-execution read set of the transaction is different from the version number of the variable in the pre-execution version set, it may be determined that there is a conflict, so that the computing device 11 is instructed from the storage device 13 to re-pre-execute the transaction. If it is determined that there is no conflict, computing device 11 then sends the pre-execution read-write set of transactions to primary storage device 12. The conflict detection module 121 in the primary storage 12 may perform a second pre-execution conflict detection on the transaction based on the set of pre-execution versions SV12 and the pre-execution read set of the transaction. In the event that a conflict is determined to exist, the primary storage device 12 may instruct the computing device 11 to re-pre-execute the transaction. In the event that no conflict is determined to exist, the master storage device 12 submits the pre-execution results of the transaction, i.e., updates the status in the pre-execution write set of the transaction to the pre-execution status set in the master storage device and/or the slave storage device, and ranks the transaction sequentially into a submitted transaction list. At the same time, the primary storage device 12 also increments the version number of each variable in the transactional pre-execution write set by one in the pre-execution version set SV 12.

The consensus module 122 may periodically obtain a plurality of previously recorded ordered transactions from a commit transaction queue, initiate a consensus proposal to a consensus module (e.g., consensus module 22) of each slave node, the consensus proposal including the plurality of obtained transactions and an ordering of the plurality of transactions in the commit transaction queue. In addition, the consensus proposal can also comprise a pre-execution read-write set of each transaction.

The master storage device 12 may push the pre-execution write set of a batch of transactions and the pre-execution version set SV12 in the master storage device 12 to the respective slave storage devices 13 after submitting the pre-execution results of the batch of transactions, so that the slave storage devices 13 may update the pre-execution state set S13 according to the pre-execution write set of the batch of transactions and update the pre-execution version set SV13 based on the pre-execution version set SV 12. By doing so, when the execution state set needs to be read by multithreading or multi-machine execution in the master node 1, the slave storage device 13 reads the execution state set, reducing the burden on the master storage device. In addition, the computing device 11 may first perform conflict detection by the slave storage device 13, and if the conflict detection in the slave storage device is not passed, the master storage device 12 is no longer required to perform conflict detection for the transaction, thus also reducing the burden on the master storage device. In the case where the latest pre-execution version set in the master storage device 12 and the writing state of the latest batch of transactions have not been updated to the slave storage device 13, the state read from the pre-execution state set in the slave storage device 13 by the computing device 11 at the time of pre-execution of the transactions is not the latest state, which may cause the master storage device 12 to determine to re-pre-execute the transaction when pre-execution conflict detection is performed on the transaction, so that the accuracy of pre-execution is not affected.

After the consensus of the plurality of consensus nodes in the blockchain is successful, the computing modules in the respective slave nodes may begin executing the plurality of transactions. The calculation module 23 of the slave node 2 includes a grouping sub-module 231 and a plurality of execution sub-modules (an execution sub-module 232, an execution sub-module 233, and an execution sub-module 234 are schematically shown in the figure).

Specifically, in the master node 1, since collision detection is performed on each transaction in the process of pre-executing each transaction in series, and consensus is initiated according to the transaction arrangement order in the submitted transaction queue, if the master node 1 executes a plurality of transactions in common, the obtained execution result is necessarily consistent with the pre-execution result of each transaction, so that the master node 1 may not execute the plurality of transactions again, but may use the respective pre-execution result of the plurality of transactions as the execution result thereof.

In the slave node 2, the grouping sub-module 231 first divides the plurality of transactions into a plurality of transaction groups according to the respective pre-execution read-write sets of the plurality of transactions, and no conflicting transactions exist between the respective transaction groups. The case where there is a conflicting transaction between two transaction groups generally includes the following: transactions in the first transaction group read a first variable (i.e., the first transaction group reads the first variable), and the second transaction group writes the first variable; the first transaction group writes the first variable, and the second transaction group writes the first variable; the first transaction group reads the first variable and writes the first variable, and the second transaction group writes the first variable; the first transaction group reads and writes the first variable, and the second transaction group reads and writes the first variable. Wherein if two transaction groups read the same variable, it may also be considered that there is no conflicting transaction. Generally, to simplify the scheme, the grouping sub-module 231 may group multiple transactions as required by not accessing the same variables between the respective transaction groups.

Thereafter, the plurality of execution sub-modules may execute the transactions in the plurality of transaction groups in parallel.

Through the process described above, the master node in the blockchain considers conflicts between transactions when pre-executing the transactions, and determines the order in which the transactions are submitted according to the order in which the respective transactions were detected by pre-executing the conflicts, such that the world state of the slave node when executing the transactions is consistent with the world state of the master node when pre-executing the transactions without the master node being disliked. The master node periodically updates the pre-execution state set and the pre-execution version set in the slave storage device 13, reads the pre-execution state from the pre-execution state set in the slave storage device 13 when the pre-execution transaction is completed, and firstly performs conflict detection on the transaction through the slave storage device 13 after the pre-execution transaction is completed, so that the burden of the master storage device 12 is reduced, and the system performance is improved.

Meanwhile, the slave node can group the transactions based on the pre-execution read-write set of the master node without pre-executing the transactions, so that the transactions are executed in parallel, and the transaction execution efficiency is improved.

The above process will be described in detail below with reference to a flow chart of a method of executing a transaction as shown in fig. 3. Only the flows performed by master node 1 and slave node 2 are shown in fig. 3, it being understood that other slave nodes in the blockchain perform the same flows as slave node 2.

As shown in fig. 3, first, in step S301, the computing device 11 in the master node 1 pre-executes a transaction, resulting in a pre-executed read-write set of transactions.

Computing device 11 may pre-execute a transaction immediately after each transaction is received. Computing device 11 may pre-execute multiple transactions received simultaneously in parallel.

Where the computing device 11 reads a variable (e.g., variable a) during pre-execution of, for example, transaction Tx1, the computing device 11 first determines whether the value of variable a is stored in the write cache of the transaction, and if the value of variable a is stored, may read the value of variable a directly from the write cache. In the case of determining that the value of the variable A is not stored in the write cache, determining whether the value of the variable A is stored in the read cache of the transaction, and if the value of the variable A is stored, reading the value of the variable A from the read cache. Wherein, the key value pair of the variable which has been written in the process of executing the transaction is stored in the write cache, and the key value and version of the variable which has been read in the process of executing the transaction is stored in the read cache. In the case of determining that the value of the variable a is not stored in the read cache, the computing device determines the storage device to be read according to the correspondence between the variable a to be read and one of the master storage device and each of the slave storage devices, for example, determines that the variable a corresponds to the slave storage device 13. Thereafter, the computing device 11 may request the value of the variable a from the storage device 13, and if the value of the variable a is included in the pre-execution state set of the storage device 13, the value of the variable a read from the pre-execution version set S13 and the latest version number of the variable a read from the pre-execution version set SV13 are returned from the storage device 13 to the computing device 11, so that the computing device 11 records the value and version number of the variable a in the read cache of the transaction. In the case where the value of the variable a is not included from the pre-execution state set of the storage device 13, information of the read failure may be returned to the computing device 11, so that the computing device 11 may read the value of the variable a from the state database. That is, the priority of reading the variable in the process of pre-executing the transaction by the master node 1 is: write cache of transaction > read cache of transaction > state database from pre-execution state set in storage device.

After pre-executing transaction Tx1 as described above, computing device 11 obtains the pre-executed read-write set of transaction Tx 1. In one embodiment, the pre-execution read-write set includes a read set and a write set, wherein the read set includes a key of a variable and a version number of the variable read when the transaction is pre-executed, and the write set includes a key pair of the variable written when the transaction is pre-executed.

In the case of a call to a contract in a transaction, the blockchain node may write to a different variable depending on the value of the variable read during execution of the contract for the transaction call. For example, when the value of the read variable is 1, 10 is written to the variable a, when the value of the read variable is 2, 20 is written to the variable b, and so on. Thus, for a transaction to invoke a contract, the blockchain node must determine the variables read and written by the transaction by executing the transaction, thereby obtaining a read-write set for the transaction. To this end, the computing device 11 obtains a pre-execution read-write set of each transaction by pre-executing each transaction of the plurality of transactions, the pre-execution process being substantially the same as the process of executing the transaction, except that the pre-execution of the transaction is an execution process performed before the consensus, and the execution of the transaction is an execution process performed after the consensus, and the pre-execution result of the pre-execution transaction is used only to update the pre-execution state set, not to update the world state, and the execution result of the execution transaction is used to update the world state.

In step S303, the computing device sends the pre-execution read set of the transaction to the slave storage device.

In one embodiment, computing device 11 may also send to slave storage device 12 a pre-execution read set of transaction Tx1 along with a pre-execution write set that may be used to subsequently update the pre-execution version set SV12 in the slave storage device if conflict detection for transaction Tx1 passes.

In step S305, after receiving the pre-execution read set of the transaction from the storage device 13, it is determined whether the pre-execution read set of the transaction conflicts with the pre-execution version set SV 13.

Specifically, when performing pre-execution conflict detection on the transaction Tx1, the storage device 13 first determines whether the local pre-execution version set S13 includes a variable (for example, a variable a) in the pre-execution read set of the transaction Tx 1. If not, it is again similarly determined whether other variables in the pre-execution read set for transaction Tx1 are included in the pre-execution version set S13. If all variables in the pre-execution read set of transaction Tx1 are not included in the pre-execution version set S13, that is, the transaction that has been previously subject to pre-execution conflict detection has not yet written to the variables accessed by the transaction, it may be determined that the pre-execution read set of transaction Tx1 does not conflict with the pre-execution version set S13.

If the value of the variable a is included in the pre-execution version set S13 from the storage device 13, it is determined whether the version number of the variable a in the pre-execution read set is identical to the version number of the variable a in the pre-execution version set S13, and if so, it is indicated that there is no conflict between the value of the variable a read by the transaction and the pre-execution version set S13. After determining from the storage device 13 that there is no conflict for each variable in the pre-execution read set of transaction Tx1, it may be determined that there is no conflict between the pre-execution read set of transaction Tx1 and the pre-execution version set S13.

If it is determined from the storage device 13 that the version number of variable A in the pre-execution read set of transaction Tx1 does not match the version number of variable A in the pre-execution version set S13, it is stated that the value of variable A read by the transaction Tx1 conflicts with the pre-execution version set S13.

In step S307, in the case where it is determined that there is a conflict, the determination result for indicating that there is a conflict is transmitted from the storage device 13 to the computing device 11, so that the computing device 11 may be instructed to re-pre-execute the transaction Tx1, and the computing device 11 re-pre-executes the transaction Tx1 by executing step S301 after receiving the instruction.

Specifically, since the computing device 11 pre-executes a plurality of transactions in parallel, the computing device 11 may submit a transaction Tx2, for example, writing the variable a, at the master storage device 12 after reading the variable a and before the pre-execution completes the transaction Tx1, thereby updating the version number of the variable a in the pre-execution version set SV12, i.e., adding 1 to the existing version number, and pushing the updated pre-execution version set SV12 to the slave storage device 13, thereby updating the version number of the variable a in the pre-execution version set SV13 from the storage device 13. When the slave computing device 11 compares the pre-execution read set of the transaction Tx1 with the pre-execution version set SV13 after the pre-execution of the transaction Tx1 is completed, it may be determined that the version number of the variable a in the pre-execution read set of the transaction Tx1 is inconsistent with the version number of the variable a in the pre-execution version set SV13, that is, even if the master storage device 12 performs collision detection on the pre-execution result of the transaction Tx1, the detection result will not pass. Thus, the slave storage device 13 may directly instruct the computing device 11 to re-execute the transaction Tx1 upon determining that the collision detection is not passed, without the master storage device having to perform collision detection on the pre-execution result of the transaction Tx 1. Thus, the calculation load of the main storage device 12 is reduced, and the processing efficiency of the main node is improved.

In another case, in the case of the pre-execution state set S12, where part of the variables are also stored in the primary storage device 12, the computing device 11 may read the newer version of the variable in the primary storage device 12, but not in agreement with the older version number of the variable in the secondary storage device 13, in which case the secondary storage device 13 still instructs the computing device 11 to re-pre-execute the transaction and does not affect the correctness of the execution of the transaction, and the embodiments of the present description increase the overall processing efficiency of the primary node even if this second case exists due to the greater proportion of the former case.

In step S309, in the case where it is determined that there is no conflict, the determination result for indicating that there is no conflict is returned from the storage device 13 to the computing device 11.

In step S311, the computing device 11 transmits the pre-execution read-write set of the transaction Tx1 to the main storage device 12.

In step S313, the primary storage device 12 determines whether there is a conflict between the pre-execution read set of transaction Tx1 and the pre-execution version set SV 12.

The primary storage device 12, upon receiving the pre-execution read-write sets for each transaction, determines whether the pre-execution read sets for the transaction conflict with the pre-execution version set SV 12.

The computing device 11 sends the pre-execution read-write set of each transaction to the main storage device 12 after pre-executing each transaction in parallel, the main storage device 12 may store the received pre-execution read-write set of each transaction in a message queue, and the main storage device 12 may take out the pre-execution read-write set of transactions one by one from the message queue, so as to perform pre-execution conflict detection on each transaction in series. By doing so, the pre-execution version set SV12 does not need to be locked in the main storage device 12, and the collision detection efficiency is improved.

Specifically, when performing pre-execution conflict detection on transaction Tx1, the primary storage device 12 first determines whether the local pre-execution version set SV12 includes a variable (e.g., variable a) in the pre-execution read set of transaction Tx 1. If not, it is again similarly determined whether the pre-execution version set SV12 includes other variables in the pre-execution read set for transaction Tx 1. If the set of pre-execution states does not include all of the variables in the pre-execution read set for transaction Tx1, that is, the transaction previously subject to pre-execution conflict detection has not yet written to the variable accessed by the transaction, then it may be determined that the pre-execution read set for transaction Tx1 does not conflict with the pre-execution version set SV12, that is, that pre-execution of the transaction Tx1 does not conflict with the transaction previously subject to pre-execution conflict detection.

If the primary storage device 12 determines that the pre-execution version set SV12 includes the value of the variable a, it determines whether the version number of the variable a in the pre-execution read set is consistent with the version number of the variable a in the pre-execution version set SV12, and if so, it indicates that the value of the variable a read by the transaction is the latest state of the variable a in the pre-execution process. After the primary storage device 12 determines that the read value is the most recent state in the pre-execution process for each variable in the pre-execution read set of transaction Tx1, it may be determined that there is no conflict between the pre-execution read set of transaction Tx1 and the pre-execution version set SV12, so that the pre-execution result of transaction Tx1 may be submitted.

If the primary storage device 12 determines that the version number of variable A in the pre-execution read set of transaction Tx1 does not match the version number of variable A in the pre-execution version set SV12, it may determine that the pre-execution read set of transaction Tx1 has a conflict with the pre-execution version set SV12, thus indicating that the value of variable A read by this transaction Tx1 is not the most current state in the pre-execution process. In the event that a conflict is determined to exist, the primary storage device 12 may instruct the computing device 11 to re-pre-execute the transaction Tx1, the computing device 11 re-pre-executing the transaction Tx1 by executing step S301 after receiving the instruction (not shown in fig. 3).

In step S315, the primary storage device 12 updates the pre-execution version set SV12 based on the pre-execution write set of the transaction Tx1 and updates the commit transaction queue in the event that it is determined that there is no conflict between the pre-execution read set and the pre-execution version set SV12 of the transaction Tx 1.

Specifically, in the case where it is determined that there is no conflict, the main storage device 12 adds 1 to the version number of each variable in the pre-execution write set of the transaction Tx1 in the pre-execution version set SV12, and simultaneously sequentially records the identification of the transaction Tx1 in the commit transaction queue, for example, records the identification of the transaction Tx1 in the end position (i.e., the last position) of the commit transaction queue. That is, the order in which the transactions recorded in the transaction queue are submitted represents the order in which the respective transactions pass conflict detection, and the recorded respective transactions do not conflict with previously recorded transactions. The information of the submitted transaction in the embodiment of the present specification is not limited to the form of the submitted transaction queue, and may be, for example, a form of a sequence table.

In the case where a partial pre-execution state is also stored in the main storage device 12, the main storage device 12 also updates the pre-execution state set based on the pre-execution write set for the transaction Tx 1. Specifically, the main storage device 12 updates the variable value corresponding to the main storage device 12 among the values of the variables written in the pre-execution write set of the transaction Tx1 to the pre-execution state set, so that the pre-execution state set records the latest state of each variable in the pre-execution process.

In step S317, the master storage device 12 transmits the pre-execution version set SV12 and the transactional pre-execution write set to the slave storage device 13.

Specifically, the master storage device 12 may transmit the latest pre-execution version set SV12 and the latest pre-execution write set of a batch of transactions through conflict detection to the slave storage device 13 every predetermined period of time or at a preset time. It will be appreciated that the master storage device 12 may also send the latest pre-execution version set SV12 and the pre-execution write set for a committed transaction to the slave storage device 13 after each commit of the pre-execution results of that transaction.

In step S319, the local pre-execution version set SV13 is updated from the storage device 13 to the latest pre-execution version set SV12. At the same time, the slave storage device 13 may update the state of the variable corresponding to the slave storage device 13 in the pre-execution state set S13 in the latest batch of transactions through conflict detection.

In step S321, the master storage device transmits the plurality of transactions, the arrangement order thereof, and the pre-execution read-write set thereof, which are sequentially arranged in the commit transaction queue, to the slave node 2.

Specifically, the master storage device 12 may send a plurality of transactions that are arranged in the order of the heads of the commit transaction queue, the arrangement order of the plurality of transactions in the commit transaction queue, and the pre-execution read-write sets of the plurality of transactions as consensus proposals to each slave node so as to agree with each slave node that the plurality of transactions are the plurality of transactions in the block to be generated, and the arrangement order of the plurality of transactions is the arrangement order thereof in the commit transaction queue.

By doing so, the master node 1 eliminates conflicts between transactions when performing pre-execution, and each node performs each transaction in the order of arrangement in the commit transaction queue when performing the transaction, so that the read-write set obtained by performing the transaction without disliked master node is consistent with the pre-execution read-write set of the transaction.

After the master node 1 completes the pre-execution of the plurality of transactions, since the above-described consensus process makes the pre-execution read-write set of transactions coincide with the execution read-write set as described above, the master node 1 can directly use the pre-execution result of the plurality of transactions in the consensus proposal as the execution result of the plurality of transactions, update the status database according to the pre-execution read-write set of the plurality of transactions, and generate the block. Wherein a block may be generated in the master node 1 by the computing device 11 or the master storage device 12. The block includes a block header and a block body. The block includes, for example, data such as transaction bodies and receipts of the transactions. The block header may include status root, receipt root, transaction root, etc. data.

In step S323, the slave node 2 groups a plurality of transactions based on the pre-execution read-write set.

The slave node 2 may group a plurality of transactions based on keys (keys) of read variables and written variable keys included in the pre-execution read-write set of the respective transactions. As described above, the grouping may be such that transactions in different transaction groups do not access the same variables, including read and write operations, and where the grouping condition is reached, there is no conflicting transaction between the transaction groups, and therefore, the transaction groups may be executed in parallel.

In step S325, the slave node 2 performs the plurality of transactions in parallel according to the grouping result and the arrangement order of the plurality of transactions.

Referring to fig. 2, the slave node 2 may execute transactions in a plurality of transaction groups in parallel through a plurality of execution sub-modules. Assuming that the grouping sub-module 231 divides the plurality of transactions into 6 groups g 1-g 6, the grouping sub-module 231 may send groups g1 and g2 to the execution sub-module 232, groups g3 and g4 to the execution sub-module 233, and groups g5 and g6 to the execution sub-module 234, so that each of the execution sub-modules may execute transactions in the group to which it is divided in parallel.

Taking the execution submodule 232 as an example, the execution submodule 232 may process the group g1 and the group g2 to which it is divided in series or in parallel. Because there may be conflicts between transactions in one group, the execution submodule 232 serially executes transactions in a single group according to the order in which the multiple transactions in the single group are arranged. The execution sub-module 232 obtains the execution read-write set of the transaction Tx1 after executing a certain transaction (e.g., the transaction Tx 1) of the group g 1. The execution submodule 232 may compare whether the execution read-write set of the transaction Tx1 is consistent with the pre-execution read-write set. If the executing read-write set of transaction Tx1 is consistent with the pre-executing read-write set, the execution sub-module 232 may update the state (i.e., world state) of the various variables in the cache based on the executing write set of transaction Tx 1.

If not, it is stated that the master node 1 provides the slave node 2 with the wrong pre-execution read-write set. I.e. master node 1 is bad. In this case, in order that the execution sub-module 232, the execution sub-module 233 and the execution sub-module 234 may still continue to execute each transaction group in parallel according to the existing grouping result, the execution sub-module 232 rolls back execution of the transaction Tx1, specifically may delete the read-write set obtained by executing the transaction Tx1, and remove the transaction Tx1 from the group g1 into the group g7, where the group g7 is used for aggregating transactions with a read set different from the pre-execution read set. That is, by rolling back execution of transaction Tx1 so that transaction Tx1 does not affect the current world state, causing rolling back of other transactions, by moving transaction Tx1 out of group g1 so that variables accessed by transaction Tx1 do not affect grouping of other transactions, each execution sub-module may continue to execute each transaction group in parallel.

After completing execution of the plurality of transactions, the slave node 2 may generate a block according to execution results of the plurality of transactions. Alternatively, the slave node 2 may include a pre-execution read-write set of multiple transactions in a block. By including the pre-execution read-write set of the plurality of transactions in the block, when other slave nodes lose data due to a failure or the like, the plurality of transactions in the block can be re-executed based on the pre-execution read-write set of the block in the slave node 2, thereby obtaining the world state consistent with the slave node 2.

FIG. 4 is an architecture diagram of a slave storage device in a blockchain master node, the master node further including a master storage device and a computing device, the slave storage device including:

a receiving unit 41 for receiving a pre-execution read set of a first transaction from the computing device, the pre-execution read set comprising a version of a variable read during pre-execution of the first transaction;

a determining unit 42, configured to determine whether a pre-executed read set of the first transaction conflicts with a locally stored first version set, where the first version set includes a first version of a plurality of variables in a blockchain; in the event that a conflict is determined to exist, instruct the computing device to re-pre-execute the first transaction,

The present description also 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 as shown in fig. 3.

A seventh aspect of the present specification provides a slave storage device in a blockchain master node, comprising a memory having executable code stored therein and a processor that when executing the executable code implements the method as shown in fig. 3.

According to the scheme provided by the embodiment of the specification, when the master node in the blockchain pre-executes the transaction, the conflict among the transactions is considered, and the sequence of transaction submission is determined according to the sequence of each transaction passing through the pre-execution conflict detection, so that the world state of the slave node when executing the transaction is consistent with the world state of the master node when pre-executing the transaction under the condition that the master node is not disliked. The master node periodically updates the pre-execution state set and the pre-execution version set in the slave storage device 13, reads the pre-execution state from the pre-execution state set in the slave storage device 13 when the pre-execution transaction is completed, and firstly performs conflict detection on the transaction through the slave storage device 13 after the pre-execution transaction is completed, so that the burden of the master storage device 12 is reduced, and the system performance is improved.

In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation device is a server system. Of course, the present application does not exclude that as future computer technology evolves, the computer implementing the functions of the above-described embodiments may be, for example, a personal computer, a laptop computer, a car-mounted human-computer interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When implemented in an actual device or end product, the instructions may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment) as illustrated by the embodiments or by the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, it is not excluded that additional identical or equivalent elements may be present in a process, method, article, or apparatus that comprises a described element. For example, if first, second, etc. words are used to indicate a name, but not any particular order.

For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, when one or more of the present description is implemented, the functions of each module may be implemented in the same piece or pieces of software and/or hardware, or a module that implements the same function may be implemented by a plurality of sub-modules or a combination of sub-units, or the like. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

One skilled in the relevant art will recognize that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

One or more embodiments of the present specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

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. In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present specification. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.

The foregoing is merely an example of one or more embodiments of the present specification and is not intended to limit the one or more embodiments of the present specification. Various modifications and alterations to one or more embodiments of this description will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, or the like, which is within the spirit and principles of the present specification, should be included in the scope of the claims.

Claims

1. A method of performing a transaction in a blockchain, the blockchain including a master node and a slave node, the master node including a slave storage device, a master storage device, and a computing device, the method comprising:

2. The method of claim 1, further comprising:

in the event that the slave storage device determines that there is no conflict, the computing device sends a pre-execution read-write set of the first transaction to the master storage device, the pre-execution read-write set including a pre-execution write set and the pre-execution read set, the pre-execution write set including values of variables written during pre-execution of the first transaction;

the primary storage device determining whether there is a conflict between a pre-execution read set of the first transaction and the locally stored second version set, and in the event that it is determined that there is no conflict, updating the second version set based on a pre-execution write set of the first transaction; the secondary storage device is instructed to update the first set of versions according to the second set of versions.

3. The method of claim 2, further comprising:

the main storage device records the identification sequence of the first transaction into a submitted transaction queue under the condition that no conflict exists; transmitting a plurality of transactions in the commit transaction queue that are ordered in a previously recorded order, an order in which the plurality of transactions are ordered in the commit transaction queue, and a pre-execution read-write set of the plurality of transactions to the slave node;

the slave node executes the plurality of transactions according to the arrangement sequence of the plurality of transactions and the pre-execution read-write set of each transaction.

4. A method according to claim 2 or 3, further comprising: and the master storage device instructs the slave storage device to update the variable state set stored in the slave storage device according to the pre-execution write set in the case that no conflict exists.

5. The method of claim 4, the slave storage device variable state set comprising states of a portion of variables in a blockchain, the method further comprising:

the storage device, in response to an indication of the master storage device, in the event that it is determined that a first variable in the pre-execution write set corresponds to the slave storage device, updates the set of variable states according to a value of the first variable in the pre-execution write set.

6. The method of claim 5, further comprising: the computing device, when reading a second variable in pre-executing the first transaction, requests a value of the second variable from the secondary storage device in the event that it is determined that the second variable corresponds to the secondary storage device.

7. The method of claim 6, wherein the determining from a storage device whether a pre-execution read set of the transaction conflicts with a locally stored first version set comprises, in the event that a version of the second variable is included in the first version set, determining whether a version of the second variable in the first version set is consistent with a version of the second variable in the pre-execution read set, and if not, determining that the pre-execution read set conflicts with the first version set.

8. The method of claim 7, wherein the primary storage device determining whether a pre-execution read set of the transaction conflicts with a locally stored second version set comprises, in the event that a version of the second variable is included in the second version set, determining whether a version of the second variable in the second version set is consistent with a version of the second variable in the pre-execution read set, and if not, determining that the pre-execution read set conflicts with the second version set.

9. The method of claim 2, further comprising, the primary storage device notifying the computing device that the first transaction is re-pre-executed if it is determined that there is a conflict between a pre-executed read set and a second version set of the first transaction.

10. The method of claim 3, wherein the slave node executing the plurality of transactions according to the rank order and the pre-execution read-write set of the plurality of transactions comprises the slave node grouping the plurality of transactions according to the pre-execution read-write set of the plurality of transactions, the plurality of transactions being executed in parallel according to the rank order and the grouping result of the plurality of transactions.

11. A method of performing a transaction in a blockchain, the blockchain including a master node and a slave node, the master node including a slave storage device, a master storage device, and a computing device, the method performed by the slave storage device, comprising:

12. A blockchain system includes a master node and a slave node, the master node including a slave storage device, a master storage device, and a computing device,

the computing device is configured to send a pre-execution read-write set of the first transaction to the primary storage device in the event that the secondary storage device determines that there is no conflict, the pre-execution read-write set including a pre-execution write set and the pre-execution read set, 5 the pre-execution write set including values of variables written during pre-execution of the first transaction;

The main storage device is used for determining whether the pre-execution read set of the first transaction and the locally stored second version set have conflict, and updating the second version set based on the pre-execution write set of the first transaction in the case that no conflict exists; recording the first transaction sequence into a commit transaction queue; transmitting a plurality of transactions in the commit transaction queue that are ordered in a previously recorded order, an order in which the plurality of transactions are ordered in the commit transaction queue, and a 0 pre-execution read-write set of the plurality of transactions to the slave node; instruct the slave storage device to update the first version set according to the second version set;

13. A master node in a blockchain, the master node comprising a slave storage device, a master storage device, and a computing device, 5 the computing device being configured to send a pre-execution read set of a first transaction to the slave storage device after pre-execution of the first transaction is completed, the pre-execution read set comprising a version of a variable read during pre-execution of the first transaction;

0, wherein the primary storage device stores a second version set, the second version set including a most up-to-date second version of the plurality of variables in the blockchain, the second version set updated based on a pre-execution write set of the transaction after a conflict detection by the primary storage device for the pre-execution read set of the transaction passes, the first version set updated based on the second version set.

14. A slave storage device in a blockchain master node, the master node further comprising a master storage device and a computing device, the 5-slave storage device comprising:

a determining unit, configured to determine whether a pre-executed read set of the first transaction conflicts with a locally stored first version set, where the first version set includes a first version of a plurality of variables in a blockchain; in the event that a conflict is determined to exist, reference 0 indicates that the computing device re-pre-executes the first transaction,

15. A computer readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of claim 11.

16. A slave storage device in a blockchain master node, comprising a memory having executable code stored therein and a processor that when executing the executable code implements the method of claim 11.