CN114936092A

CN114936092A - Method for executing transaction in block chain and main node of block chain

Info

Publication number: CN114936092A
Application number: CN202210600442.4A
Authority: CN
Inventors: 林鹏; 徐文博
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-05-30
Filing date: 2022-05-30
Publication date: 2022-08-23
Also published as: WO2023231335A1

Abstract

The present specification provides a method of performing a transaction in a blockchain comprising a master node and slave nodes, and a master node of the blockchain, wherein the method of performing a transaction in a blockchain is performed by the master node, the method comprising: pre-executing a plurality of transactions belonging to a first block; determining that a first transaction of the plurality of transactions is a preset type of transaction; after pre-executing the plurality of transactions, agreeing with the slave node on the first tile; re-executing the first transaction after completing the consensus on the first block.

Description

Method for executing transaction in block chain and main node of block chain

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technology, and more particularly, to a method for performing transactions in a blockchain and a master node of the blockchain.

Background

A block chain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. The data blocks are combined into a chain data structure in a block chain in a time sequence in a sequential connection mode, and the data blocks are guaranteed to be not falsifiable and not forged in a cryptographic mode. Because the blockchain has the characteristics of decentralization, information non-tampering, autonomy and the like, the blockchain is also paid more and more attention and is applied by people.

At present, the execution efficiency of the transaction is difficult to be improved, and a scheme for executing the transaction efficiently is needed.

Disclosure of Invention

One or more embodiments of the present specification provide a method of performing a transaction in a blockchain and a master node of the blockchain.

According to a first aspect, there is provided a method of performing a transaction in a blockchain, the blockchain comprising a master node and slave nodes, the method being performed by the master node, the method comprising:

pre-executing a plurality of transactions belonging to a first block;

determining that a first transaction of the plurality of transactions is a preset type of transaction;

after pre-executing the plurality of transactions, agreeing with the slave node on the first tile;

re-executing the first transaction after completing the consensus on the first block.

According to a second aspect, there is provided a master node in a blockchain, the blockchain further comprising a slave node, the master node comprising:

the system comprises a pre-execution process, a first processing unit and a second processing unit, wherein the pre-execution process is used for pre-executing a plurality of transactions belonging to a first block and determining that a first transaction in the plurality of transactions is a preset type of transaction;

a consensus process for agreeing with the slave node on the first block after pre-executing the plurality of transactions;

a computing process to re-execute the first transaction after the consensus on the first block is completed.

According to a third aspect, there is provided a computer readable storage medium, storing a computer program which, when executed by a processor, implements the method of any of the first aspects above.

According to a fourth aspect, there is provided a computing device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the method of any of the first aspects when executing the program.

The technical scheme provided by the embodiment of the specification can have the following beneficial effects:

in the method for executing transactions in a blockchain and the master node of the blockchain provided in the embodiments of the present specification, after the master node completes pre-execution of a current block, if it is determined that a preset type of transaction exists in multiple transactions of the current block, the preset type of transaction is re-executed after the consensus on the current block is completed. Therefore, the execution speed of the blocks in the block chain is effectively improved, and the performance of the block chain system is improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

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

FIG. 1 is a block chain architecture diagram applied in an embodiment of the present disclosure;

FIG. 2 is a diagram illustrating a consensus process in a PBFT consensus algorithm, according to an exemplary embodiment, shown herein;

FIG. 3 is a diagram illustrating a process for performing transactions in a blockchain according to an exemplary embodiment of the present disclosure;

FIG. 4 is a block diagram illustrating master and slave nodes of a blockchain in accordance with an exemplary embodiment of the present description;

FIG. 5 is a flow diagram illustrating a method for performing transactions in a blockchain in accordance with an exemplary embodiment of the present description;

fig. 6 is a block diagram illustrating a master node in a blockchain in accordance with an example embodiment of the present specification.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, 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 a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

Blockchains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain) and alliance chain (Consortium Blockchain). In addition, there are various types of combinations, such as private chain + federation chain, federation chain + public chain, and other different combinations. The most decentralized of these is the public chain. The public chain is represented by bitcoin and ether house, and the participators joining the public chain can read the data record on the chain, participate in transaction, compete for accounting right of new blocks through consensus, and the like. In the private chain, the write rights of the network are controlled by an organization or organization, and the data read rights are specified by the organization. A federation chain is a block chain between public and private chains, and may implement "partial decentralization. Each node in a federation chain typically has a physical organization or organization corresponding to it; participants jointly maintain blockchain operation by authorizing to join the network and forming a benefit-related alliance.

Fig. 1 is a block chain architecture diagram applied in the embodiment of the present disclosure.

In the block chain architecture diagram shown in fig. 1, the block chain includes, for example, 6 nodes including a master node 1, a slave node 2, and a slave node 6. The lines between the nodes schematically represent P2P (Peer-to-Peer) connections. The nodes may have a full ledger stored on them, i.e. the status of all blocks and all accounts. Wherein each node in the blockchain can generate the same state in the blockchain by performing the same transaction, and each node in the blockchain can store the same state database. In contrast, the master node 1 may be responsible for pre-executing the received transactions and initiating consensus proposals to the respective slave nodes, including information such as a number of transactions in the tile to be blocked (e.g., tile B1) and the pre-execution read-write set and pre-execution order of the respective transactions. After each node in the blockchain successfully agrees on the consensus proposal, each slave node may execute the multiple transactions according to the pre-execution order in the consensus proposal, thereby generating block B1.

It is to be understood that although fig. 1 illustrates 6 nodes included in the blockchain, embodiments of the present specification are not limited thereto and may include other numbers of nodes. Specifically, the nodes included in the block chain may satisfy the Byzantine Fault Tolerance (BFT) requirement. The byzantine fault tolerance requirement can be understood as that byzantine nodes can exist in a block chain, and the block chain does not show the byzantine behavior to the outside. Generally, some Byzantine Fault-tolerant algorithms require the number of nodes to be greater than 3f +1, where f is the number of Byzantine nodes (i.e., malicious nodes), such as the practical Byzantine Fault-tolerant algorithm pbft (practical Byzantine Fault-tolerant algorithm).

A transaction in the blockchain domain may refer to a unit of a task that is performed in the blockchain and recorded in the blockchain. The transaction typically includes a send field (From), a receive field (To), and a Data field (Data). Where the transaction is a transfer transaction, the From field indicates the address of the account From which the transaction was initiated (i.e., From which a transfer task To another account was initiated), the To field indicates the address of the account From which the transaction was received (i.e., From which a transfer was received), and the Data field includes the transfer amount. In the case of a transaction calling an intelligent contract in a blockchain, a From field represents an account address for initiating the transaction, a To field represents an account address of the contract called by the transaction, and a Data field includes Data such as a function name in the calling contract and incoming parameters To the function, so as To obtain code of the function From the blockchain and execute the code of the function when the transaction is executed.

The block chain may provide the functionality of an intelligent contract. An intelligent contract on a blockchain is a contract that can be executed on a blockchain system triggered by a transaction. An intelligent contract may be defined in the form of code. Calling the intelligent contract in the block chain is to initiate a transaction pointing to the intelligent contract address, so that each node in the block chain runs the intelligent contract code in a distributed mode. It should be noted that, in addition to the creation of the smart contracts by the users, the smart contracts may also be set by the system in the creation block. This type of contract is generally referred to as a startup contract. In general, the data structure, parameters, attributes and methods of some blockchains may be set in the startup contract. Further, an account with system administrator privileges may create a contract at the system level, or modify a contract at the system level (simply referred to as a system contract). Wherein the system contract is usable to add data structures for different services in a blockchain.

In the scenario of contract deployment, for example, Bob sends a transaction containing information to create an intelligent contract (i.e., a deployment contract) into the blockchain as shown in fig. 1, the data field of the transaction includes the code (e.g., bytecode or machine code) of the contract to be created, and the to field of the transaction is null to indicate that the transaction is for contract deployment. After agreement is achieved among the nodes through a consensus mechanism, a contract address '0 x6f8ae93 …' of the contract is determined, each node adds a contract account corresponding to the contract address of the intelligent contract into a state database, a state storage corresponding to the contract account is allocated, and a contract code is stored in the state storage of the contract, so that the contract creation is successful.

In the scenario of invoking a contract, for example, Bob sends a transaction for invoking a smart contract into the blockchain as shown in fig. 1, where the from field of the transaction is the address of the account of the transaction initiator (i.e., Bob), and "0 x6f8ae93 …" in the to field represents the address of the invoked smart contract, and the data field of the transaction includes the method and parameters for invoking the smart contract. After the transaction is identified in the blockchain, each node in the blockchain can execute the transaction respectively, so that the contract is executed respectively, and the state database is updated based on the execution of the contract.

The blockchain technology is different from the traditional technology in one of decentralization characteristics, namely accounting is performed on each node, or distributed accounting is performed, and the traditional centralized accounting is not performed. To be a difficult-to-defeat, open, non-falsifiable data record decentralized honest and trusted system, the blockchain system needs to be secure, unambiguous, and irreversible in the shortest possible time for distributed data records. In different types of blockchain networks, in order to keep the ledger consistent among the nodes recording the ledger, a consensus algorithm is generally adopted to guarantee, that is, the aforementioned consensus mechanism.

For example, a common mechanism of block granularity can be implemented between block nodes, such as after a node (e.g., a unique node) generates a block, if the generated block is recognized by other nodes, other nodes record the same block. For another example, a common mechanism of transaction granularity may be implemented between the blockchain nodes, such as after a node (e.g., a unique node) acquires a blockchain transaction, if the blockchain transaction is approved by other nodes, each node that approves the blockchain transaction may add the blockchain transaction to the latest block maintained by itself, and finally, each node may be ensured to generate the same latest block. The consensus mechanism is a mechanism for the blockchain node to achieve a network-wide consensus on the blockchain information (or called blockdata), which can ensure that the latest block is accurately added to the blockchain.

The current mainstream consensus mechanisms include: proof of Work (POW), Proof of stock (POS), Proof of commission rights (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, etc. In various consensus algorithms, after a predetermined number of nodes agree on data to be agreed (i.e., a consensus proposal), it is determined that the consensus proposal is successful. Specifically, in the PBFT algorithm, f malicious nodes can be tolerated for N ≧ 3f +1 consensus nodes, that is, when 2f +1 nodes among the N consensus nodes agree, it can be determined that consensus is successful.

FIG. 2 is a schematic diagram of the consensus process in the PBFT consensus algorithm.

As shown in fig. 2, according to the PBFT consensus algorithm, the complete consensus process can be divided into four phases of Request (Request), Prepare (Pre-Prepare), Prepare (Prepare), and Commit (Commit). Assuming that a blockchain includes four consensus nodes, i.e., node n 1-node n4, where node n1 is, for example, a master node, and node n 2-node n4 is, for example, a slave node, according to the PBFT algorithm, 1 malicious node, i.e., f, can be tolerated among nodes n 1-node n 4.

In particular, during the request phase, the user of the blockchain may send a request, for example in the form of a blockchain transaction, to node n1 via his user device. Node n1 may receive multiple transactions from one or more user devices and store the received transactions in a transaction queue. In the preparation stage, the node n1 may take multiple transactions belonging to a block from the transaction queue, generate consensus proposals for the multiple transactions, and broadcast the consensus proposals and the signatures of the consensus proposals from the node n1 to other consensus nodes (i.e., the node n2 to the node n4) so that the consensus nodes continue to agree on the block, where the consensus proposals may include information such as transaction bodies of the multiple transactions and execution sequence of the multiple transactions.

In the preparation phase, each slave node may sign the consensus proposal and send it to other respective nodes. Assuming node n4 is a malicious node, node n1, node n2, and node n3 may determine that the preparation phase is complete and may enter the commit phase after receiving signatures for consensus proposals for 2f ═ 2 other consensus nodes, respectively. For example, as shown in fig. 2, node n1, after receiving the signatures of node n2 and node n3, verifies that the signatures of node n2 and node n3 are both correct signatures for consensus proposals, then determines that the preparation phase is complete, and node n2, after receiving the signature of node n3 and the signature of node n1 and verifying that pass, determines that the preparation phase is complete.

In the submission stage, each consensus node signs the consensus offer in the submission stage and sends the consensus offer to other consensus nodes, and after receiving the signatures of the submission stages of 2 f-2 other consensus nodes, each consensus node can determine that the submission stage is completed and the consensus is successful. For example, node n1, after receiving the signature of the commit phase of node n2 and node n3 and verifying, determines that the commit phase is complete, so node n1 may update the world state based on the execution results from executing the plurality of transactions, generate and store a block (e.g., block B1) including the plurality of transactions, and return the execution results of the plurality of transactions to the user device. Similarly, node n2 and node n3 execute the multiple transactions after determining that the commit phase is complete, generate and store block B1, and update the world state according to the execution results of the multiple transactions.

Through the above process, the storage consistency of the node n1, the node n2 and the node n3 is achieved. That is, the node n 1-the node n4 can still achieve successful consensus on the consensus proposal in the presence of a malicious node, and complete the execution of the block.

Currently, there is an uncertain transaction that is performed in dependence on uncertain data, which may be, for example, distributed random numbers. Thus, pre-execution of the indeterminate transaction prior to consensus results in a pre-execution write set that cannot be used to update the state database. In the related art, it is necessary to identify the uncertain data to obtain data consistent with each node. And formally executing the uncertainty transaction by each node of the blockchain using the consistent data after consensus to obtain a write set for updating the state database. However, since the number of the uncertain transactions is small, the execution efficiency of the block is difficult to be improved by a method of re-executing all transactions for the uncertain transactions, and the performance of the blockchain system is also affected. Embodiments of the present disclosure provide a scheme for performing transactions in a blockchain shown in fig. 1, which can effectively increase the execution speed of blocks in the blockchain, thereby improving the performance of the blockchain system.

Fig. 3 is a diagram illustrating a process for performing transactions in a blockchain, according to an example embodiment.

As shown in FIG. 3, the block execution flow can be divided into 5 processes, namely pre-execution, consensus, transaction execution, status update and write. For each process, the transactions for each tile may be processed in sequence in the order of the tiles. Alternatively, the flow of different processes may be completed by different processes.

Specifically, after acquiring multiple transactions of the block N, the master node of the block chain performs pre-execution on each transaction of the block N, so as to obtain a pre-execution read-write set corresponding to each transaction, where the pre-execution read-write set may be used to group the multiple transactions of the block N. In the process of pre-executing any transaction, it may be determined whether the transaction is a predetermined type of transaction (i.e., the contingency transaction described above), and if the transaction is a predetermined type of transaction, the transaction may be flagged or an identification of the transaction may be recorded.

After completing the pre-execution of each transaction for block N, on the one hand, the master node may perform a consensus preparation phase (hereinafter referred to as PP phase) for block N, i.e. generating a consensus proposal for block N, which may include, for example, a hash value of each transaction for block N, a set of pre-executed reads and writes for each transaction, and a pre-execution order of each transaction for block N, and broadcasting the consensus proposal to each slave node. On the other hand, the master node may further continue to acquire multiple transactions of block N +1 in parallel, pre-execute the multiple transactions of block N +1, and perform a consensus PP phase for block N + 1.

After each slave node receives the consensus proposal, the master node performs a preparation phase (hereinafter referred to as P phase) and a commit phase (hereinafter referred to as C phase) of consensus on the block N (refer to the process of fig. 2). Meanwhile, if the plurality of transactions of the block N includes a predetermined type of transaction, unified data on which the predetermined type of transaction is performed may be commonly obtained. After the consensus is completed, the master node obtains the consensus result and re-executes at least the preset type of transaction. It is to be understood that if the predetermined type of transaction is not included in the plurality of transactions of block N, the transactions of block N do not need to be re-executed.

In the process of consensus on block N, the master node may also update the world states in the state database based on the pre-executed write sets of the respective transactions of block N in parallel, and write blocks to block N in parallel. If the plurality of transactions of the block N include a preset type of transaction, the world state in the state database may be updated by using a pre-execution write set of transactions before the preset type of transaction. And after the consensus is completed and the preset type of transaction is re-executed, continuously updating the world state in the state database by using the execution write set obtained by re-executing the preset type of transaction.

It should be noted that after the host node completes the pre-execution of the block N +1, it is required to wait for the host node to complete the block writing of the block N, and then the host node may continue to update the world state in the state database based on the pre-execution write sets of the transactions of the block N + 1.

After receiving the consensus proposal sent by the master node, each slave node can group the transactions of the block N in parallel based on the pre-execution read-write set and the pre-execution sequence sent by the master node in the process of consensus on the block N, and execute the transactions of the block N in parallel according to the group. Optionally, the slave nodes may also update the status database based on the executing write set in parallel during the execution of the transaction. For example, each time a slave node completes execution of a set of transactions for block N, the state database may be updated in parallel based on the execution write set of the set of transactions that completed execution during execution of the next set of transactions. The slave nodes may write blocks to block N in parallel during the update of the status database based on the execution of the write set of each transaction of block N.

It should be noted that, if the plurality of transactions of the block N include a predetermined type of transaction, the unified data on which the predetermined type of transaction is executed may be commonly obtained. After the consensus on the block N is completed, each slave node may obtain the consensus result and perform the predetermined type of transaction in parallel based on the consensus result. In addition, the slave node may continue to update the status database according to the execution write set of each transaction of block N +1 until it waits for the completion of the write to block N.

In this embodiment, after the host node completes the pre-execution of the current block, if it is determined that the preset type of transaction exists in the multiple transactions of the current block, the preset type of transaction is re-executed after the consensus on the current block is completed. Therefore, the execution speed of the blocks in the block chain is effectively improved, and the performance of the block chain system is improved.

Fig. 4 is a structural diagram illustrating a master node and a slave node of a block chain provided in an embodiment of the present specification.

As shown in fig. 4, the master node may include an access process 11, a pre-execution process 12, a cache process 13, a consensus process 14, a storage process 15, a management process 16, a communication process 17, and a computation process 18, and the slave node may include an access process 21, a pre-execution process 22, a cache process 23, a consensus process 24, a storage process 25, a management process 26, a communication process 27, and a computation process 28.

The master node may interact with the client through the access process 11, for example, the access process 11 may receive a plurality of transactions from the client, transmit the plurality of transactions to the cache process 13, and the cache process 13 places the received transactions in a transaction queue. In addition, the cache process 13 also stores the current latest state data of the world state of the blockchain. The pre-execution process 12 obtains a batch of transactions from the transaction queue of the cache process 13 at preset time intervals, and pre-executes the obtained transactions to obtain a pre-executed read-write set of each transaction. The pre-execution read-write set of any transaction may include a pre-execution read set and a pre-execution write set, where the pre-execution read set may specifically be key-value pairs of read variables generated during the pre-execution transaction, and the pre-execution write set may specifically be key-value pairs of written variables generated during the pre-execution transaction. During the pre-execution of the transaction, the state values of the variables in the read set of the transaction may be obtained from the latest state data stored by the caching process 13. After each transaction is executed in advance, the pre-execution read-write set of the transaction may be submitted to the cache process 13 for storage, and the state values of the variables in the write set obtained by executing the transaction in advance are used to update the state data stored in the cache process 13.

It should be noted that the master node may set up a plurality of pre-execution processes, and the plurality of pre-execution processes may pre-execute the transaction in parallel. If transactions are pre-executed in parallel by a plurality of pre-execution processes, the read set of the pre-executed transactions needs to be validated each time a transaction is executed before the state data stored in the cache process 13 is updated. For example, after the pre-execution completes the transaction Tx1, it can be verified whether the state value stored in the cache process 13 by each variable in the read set of the transaction Tx1 is changed compared to the state value before the pre-execution. If no change occurs, the state data stored in the cache process 13 can be directly updated by using the state values of the variables in the write set obtained by pre-executing the transaction. If a change occurs, transaction Tx1 needs to be re-pre-executed with the new state values of the variables in the read set of transaction Tx1 in the caching process 13.

In addition, in the process of pre-executing any transaction, if it is determined that the transaction is a transaction of a preset type, the pre-execution process 12 may notify the cache process 13 that the transaction is a transaction of a preset type when the pre-execution read-write set of the transaction is submitted to the cache process 13, and the cache process 13 may mark the transaction.

The cache process 13 stores not only each transaction, but also a pre-execution read-write set obtained by pre-executing each transaction and a pre-execution sequence of each transaction. At intervals, the consensus process 14 may obtain data to be consensus corresponding to a block from the cache process 13, where the data to be consensus may include a hash value/transaction identifier/transaction body of each transaction of the block, a pre-execution read-write set of each transaction, and a pre-execution sequence of each transaction. The data to be consensus-confirmed may further include information of uncertain variables involved in a preset type of transaction if the block includes a preset type of transaction.

The consensus process 14 can generate a consensus proposal carrying the data to be consensus and broadcast the consensus proposal to other slave nodes in the block chain through the communication process 17, and the other slave nodes can return information generated by consensus to the consensus process 14 through the communication process 17 during the process of consensus on the block. In addition, the consensus process 14 may send transaction bodies, pre-execution read-write sets, and pre-execution sequences of multiple transactions for the block to the management process 16. The consensus process 14 may also send information about the predetermined type of transaction to the management process 16 if the predetermined type of transaction is included in the block. After the consensus is completed, the consensus process 14 may send the consensus result to the management process 16 as well.

In one implementation, the management process 16 may group transactions based on a set of pre-executed reads and writes for multiple transactions for the block, resulting in grouping information. In another implementation, the management process 16 may also obtain grouping information for transactions from other slave nodes. It is to be understood that the present embodiment is not limited to the specific manner in which the management process acquires the grouping information. The management process 16 may then update the state database in the storage process 15 with the state values of the variables in the write set obtained by pre-executing the block. And pre-executes information such as read-write sets and grouping information based on transaction entities of multiple transactions of the block, generates block data of the block, and stores the block data in a block database in the storage process 15.

If the block includes the predetermined type of transaction, after the consensus is completed, the management process 16 may send the predetermined type of transaction to the calculation process 18, and send the unified value of the uncertain variable related to the predetermined type of transaction to the calculation process 18 based on the result of the consensus. The predetermined type of transaction is re-executed by the computing process 18 based on the unified value of the uncertain variable involved in the predetermined type of transaction, optionally, the computing process 18 may also re-execute each transaction following the predetermined type of transaction in the block. In one aspect, the computing process 18 may update the state database in the storage process 15 with the write set resulting from the re-execution of the transaction. On the other hand, the computing process 18 may also send a re-execution event notification to the caching process 13, the re-execution event notification including the set of execution writes resulting from re-executing the respective transaction. The caching process 13 may re-update the state data of the stored world state with the execution write set.

Wherein the slave node may interact with the client, for example, through the access process 21, the access process 21 may receive a plurality of transactions from the client and transmit the plurality of transactions to the cache process 23, and the cache process 23 places the received transactions in a transaction queue. The pre-execution process 22 acquires a batch of transactions from the transaction queue of the cache process 23 at preset intervals, verifies the acquired transactions, and returns the verified transactions to the cache process 23. The caching process 23 may broadcast the validated transactions to the master node and other slave nodes via the communication process 27, and the caching process 23 may also receive transactions from other nodes via the communication process 27.

In one aspect, the consensus process 24 may receive a consensus proposal initiated by the master node through the communication process 27 and consensus the block based on the consensus proposal. Meanwhile, the consensus process 24 may send information such as the pre-execution read-write set and the pre-execution sequence of each of the multiple transactions of the block included in the consensus offer to the management process 26. In the process of consensus, the consensus process 24 may return a consensus message to the master node through the communication process 27, and receive a consensus result sent by the master node through the communication process 27. After the consensus is successful, the consensus process 24 may send the consensus result to the management process 26.

On the other hand, the management process 26 may group the transactions of the block into a plurality of transaction groups based on the pre-execution read-write sets and the pre-execution sequence of the transactions of the block in parallel. Multiple transaction groups are then assigned to the computing process 28, there may be multiple computing processes 28, and multiple computing processes 28 may execute the transaction groups in parallel after consensus is complete. The computing process 28 may obtain the state values of the variables in the read set of the transaction from the storage process 25 when executing the transaction. After each execution of a transaction group, the computing process 28 may verify the pre-executed write set based on the execution results of the transaction group, and if the verification is passed, update the state database of the block chain in the storage process 25 based on the execution results of the transaction group. If the authentication fails, indicating that the master node is rogue, the computing process 28 may notify the management process 26 that a rehosting request is initiated by the management process 26 to another slave node via the consensus process 24 to replace the master node.

Finally, the management process 26 pre-executes the read/write set, performs the read/write set and grouping information based on the transaction entities of the multiple transactions of the block, generates the block data of the block, and stores the block data in the block database in the storage process 25.

The above-described process will be described in detail below with reference to a flowchart of a method of performing a transaction as shown in fig. 5. In fig. 5, the process performed by the master node and any slave node on a block is shown. The master node at least comprises a pre-execution process e11, a cache process e12, a consensus process e13, a management process e14, a storage process e15 and a calculation process e 16. The slave node at least comprises a consensus process e21, a management process e22, a calculation process e23 and a storage process e 24.

As shown in fig. 5, first, in step 501, the pre-execution process e11 pre-executes a plurality of transactions belonging to block N, the transactions including, for example, transaction Tx 1-transaction Tx6, and obtains pre-execution read-write sets corresponding to transactions Tx 1-Tx 6, respectively. In one embodiment, a pre-executed read-write set for a transaction includes a read set including key-value pairs (key-values) of variables read when the transaction is pre-executed and a write set including key-value pairs of variables written when the transaction is pre-executed. In another embodiment, the read set of the pre-executed read/write set may include version numbers of variables read when the transaction is pre-executed, and the write set may include version numbers of variables written therein, where, for example, each written value of a variable and a version number corresponding to each written value are stored in the state data of the world state of the block chain, so that the values read and written in the transaction may be determined by including the version numbers of the variables in the read/write set.

In the process of pre-executing each transaction by the pre-execution process e11, it can be determined whether the pre-executed transaction is a transaction of a preset type, for example, a transaction including a preset variable in the reading set, where the preset variable is an uncertain variable using a random number as a state value. Specifically, it may be determined whether the pre-executed transaction is a preset type of transaction by: and in the process of pre-executing the transaction, determining that the transaction calls an intelligent contract, and judging whether the intelligent contract calls a preset interface or not when the intelligent contract is called. And if the preset interface is called, determining that the transaction is a preset type of transaction. The preset interface may be, for example, an interface for acquiring a random number. If the block N includes the preset type of transaction, the pre-execution process e11 may randomly obtain a random number as a state value of a preset variable related to the preset type of transaction, and pre-execute the preset type of transaction to obtain a pre-execution read-write set of the preset type of transaction.

If the transaction Tx 1-transaction Tx6 is pre-executed serially by a pre-executing process e11, each time a transaction is pre-executed, if the transaction is not a pre-set type of transaction, the pre-executing process e11 may directly transmit the pre-executed read-write set of the transaction to the caching process e12, and the caching process e12 updates its stored world state with the pre-executed read-write set of the transaction. If the transaction is a predetermined type of transaction, the pre-execution process e11 may transmit the pre-execution read-write set of the transaction to the cache process e12 and instruct the cache process e12 to mark the transaction.

If the transaction Tx 1-transaction Tx6 is pre-executed by multiple pre-executing processes e11 in parallel, it needs to be verified whether the read set of the transaction has read-write conflict with other parallel pre-executed transactions every time one transaction is pre-executed. For example, transaction Tx2 includes variable A in the pre-execution read set and variable B in the pre-execution write set. When transaction Tx2 is pre-executed, the value of variable A is read as Va, and transaction Tx2 is pre-executed based on Va. After completing the pre-execution of transaction Tx2, the value of variable A in caching process e12 is checked, and if the value of variable A is also Va, it is determined that there is no read-write conflict. If the value of variable A is no longer Va but becomes Vb, the transaction Tx2 may be re-executed based on Vb. It should be noted that, in addition to verifying the read-write collision through the value of the variable, the read-write collision may also be verified through the version number of the variable. In the case that there is no read-write conflict, if the transaction is not a preset type of transaction, the pre-execution process e11 may directly transmit the pre-execution read-write set of the transaction to the caching process e12, and the caching process e12 updates the stored world state with the pre-execution read-write set of the transaction. If the transaction is a predetermined type of transaction, the pre-execution process e11 may transmit the pre-execution read-write set of the transaction to the cache process e12 and instruct the cache process e12 to mark the transaction.

Next, in step 503, the consensus process e13 obtains the pre-execution read-write sets corresponding to the transactions Tx 1-Tx 6 from the buffer process e12, generates a consensus proposal for the block N, and broadcasts the consensus proposal to the slave nodes. The consensus proposal includes pre-execution sets of reads corresponding to transactions Tx 1-Tx 6, respectively. Optionally, the consensus proposal may also include information such as the order of pre-execution process e11 pre-execution transaction Tx 1-transaction Tx6 and the hash value of transaction Tx 1-transaction Tx 6. The consensus proposal may also include information on preset variables involved in a preset type of transaction if there is a preset type of transaction in the transactions Tx 1-Tx 6. After receiving the consensus proposal, the slave node completes the consensus on the block N together with the master node. The consensus process e13 of the master node and the consensus process e21 of the slave node obtain consensus results. Specifically, the slave node may return the consensus message to the master node and receive the consensus result sent by the master node (after the consensus is successful, the consensus process e21 of the slave node may send the consensus result to the management process e 22). If there is a preset type of transaction in the transactions Tx 1-Tx 6, the consensus result may include a uniform value of a preset variable involved in the preset type of transaction.

For example, the transaction Tx3 is a preset type of transaction, the transaction Tx3 includes a variable C, the value of the variable C is a random number, after consensus, it is determined that the uniform value of the variable C is k, and then the consensus result may include the uniform value k of the variable C. The following slave nodes uniformly adopt k as the state value of the variable C when executing the transaction Tx 3.

Then, in step 505, the management process e14 obtains the pre-executed write sets in the pre-executed read and write sets obtained from the pre-executed transactions Tx1 to Tx6 from the consensus process e13, and in the process of consensus on block N, the management process e14 may update the state database stored in the storage process e15 in parallel based on the pre-executed write sets of the non-preset type transactions. Specifically, the management process e14 updates the state database with the latest state values of the variables in the pre-executed write set of transactions Tx 1-Tx 2. For example, the pre-execution write set of transaction Tx1 includes variable C, whereas none of the pre-execution write sets of transaction Tx 2-transaction Tx6 involves variable C, so the state database can be updated directly with the state value of variable C in the pre-execution write set of transaction Tx 1. As another example, the pre-execution write sets of transactions Tx1 and Tx2 each include variable D, and the pre-execution order of transaction Tx2 follows transaction Tx1, so the state value of variable D in the pre-execution write set of transactions Tx2 is the latest state value of variable D, and the state database may be updated with the state value of variable D in the pre-execution write set of transactions Tx 2. Since the transaction Tx3 is a pre-set type of transaction, the state database is not updated with the pre-execution write set of transaction Tx 3-transaction Tx 6.

In step 507, after completing the consensus on block N, the management process e14 sends the transaction Tx 3-transaction Tx6 to the computing process e16, and sends the uniform value k of the variable C included in the transaction Tx3 to the computing process e 16. The calculation process e16 re-executes the transaction Tx 3-transaction Tx6 based on the value k of the variable C, and updates the state database in the storage process e15 based on the re-executed result. Additionally, the compute process e16 may also send a re-execution event notification to the cache process e12, which may include the execution write set resulting from re-executing the transaction Tx 3-transaction Tx 6. The caching process e12 may update its stored state data with the executing write set of transaction Tx 3-transaction Tx 6.

In step 509, after completing the update of the status database in the storage process e15, the management process e14 performs a write block operation for block N. Specifically, the management process e14 generates a block header and a block body of the block N, and stores the block header and the block body of the block N in the block database in the storage process e 15. The block includes, for example, transaction data such as transaction data, receipt data, and the like of the transactions Tx 1-Tx 6. The block header may include data such as a status root, a receipt root, a transaction root, etc.

In step 511, the consensus process e21 of the slave node may send information such as the pre-execution read-write set of the transactions Tx 1-Tx 6 included in the received consensus proposal, the pre-execution order, and the uniform value k of the variable C included in the transaction Tx3 to the management process e 22. In the process of consensus, the management process e22 groups the transactions Tx 1-Tx 6 of the block into multiple transaction groups based on the pre-execution read-write set and the pre-execution sequence in parallel. So that there are no conflicting variables for transactions of different transaction groups, and the transaction order of the same transaction group is consistent with the order of pre-execution. The various transaction groups are then executed in parallel. For example, transaction Tx1, transaction Tx2, transaction Tx4 are transaction group a, and transaction Tx3, transaction Tx5, transaction Tx6 are transaction group b.

Then, the management process e22 may assign multiple transaction groups, such as transaction group a and transaction group b, to multiple compute processes e23, execute transaction group a and transaction group b simultaneously in parallel by multiple compute processes e23, execute transactions in transaction group a serially in a pre-execution order, and execute transactions in transaction group b serially in a pre-execution order.

In step 513, each time the computing process e23 executes to complete a transaction group, the state database stored in the storage process e24 is updated with the write set for that transaction group, and the results of the execution of that transaction group are sent to the management process e 22. For example, after the execution of the transaction group a is completed, the computing process e23 may obtain the latest status values of all variables involved in the execution write set of the transaction Tx1, the transaction Tx2, and the transaction Tx4, and update the status database with the obtained latest status values of these variables. Finally, in step 513, after the slave node's computing process e23 completes the update of the state database in the storage process e24, the management process e22 performs a write block operation on block N. The specific process of the block writing operation is similar to that of the master node, and is not described herein again.

In the method for executing transactions in a blockchain provided in the above embodiments of the present specification, after the master node completes the pre-execution of the current block, if it is determined that there is a transaction of a preset type in multiple transactions of the current block, after the consensus on the current block is completed, the transaction of the preset type is re-executed. Therefore, the execution speed of the blocks in the block chain is effectively improved, and the performance of the block chain system is improved.

It should be noted that although in the above embodiments, the operations of the methods of the embodiments of the present specification have been described in a particular order, this does not require or imply that these operations must be performed in this particular order, or that all of the illustrated operations must be performed, to achieve desirable results. Rather, the steps depicted in the flowcharts may change the order of execution. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions.

In correspondence with the aforementioned method embodiments for performing transactions in a blockchain, embodiments of an apparatus for performing transactions in a blockchain are also provided.

As shown in fig. 6, fig. 6 is a block diagram of a master node in a blockchain shown in the present specification according to an exemplary embodiment, where the blockchain further includes a slave node, and the master node may include: pre-execution process 601, consensus process 602, and computation process 603.

The pre-execution process 601 is configured to pre-execute a plurality of transactions belonging to the first block, and determine that a first transaction in the plurality of transactions is a preset type of transaction.

A consensus process 602 for agreeing with the slave node on the first tile after pre-executing the plurality of transactions.

A calculation process 603 for re-executing the first transaction after completing the consensus on the first block.

In some embodiments, the predetermined type of transaction is a transaction in which the reading set includes a predetermined variable, and the predetermined variable uses a random number as a state value.

In other embodiments, the pre-execution process 601 may determine that the first transaction in the plurality of transactions is a predetermined type of transaction by: in the process of pre-executing the first transaction, determining that the first transaction calls an intelligent contract, judging whether to call a preset interface or not when calling the intelligent contract, and if the preset interface is called, determining that the first transaction is a preset type of transaction.

In other embodiments, the consensus process 602 may re-execute the first transaction by: and acquiring a consensus result, wherein the consensus result comprises a target state value after consensus, the target state value is the state value of the preset variable in the reading set of the first transaction, and the first transaction is executed again based on the target state value.

In other embodiments, the first transaction is a predetermined type of transaction that is pre-executed first among a plurality of transactions of the first block. Wherein after re-executing the first transaction, computing process 602 also re-executes a transaction of the plurality of transactions that was pre-executed after the first transaction.

In other embodiments, the home node further includes a cache process (not shown) that stores state data of the latest world state of the block chain. After the pre-execution process 601 pre-executes a plurality of transactions, the pre-execution process 601 submits pre-execution read-write sets of each transaction obtained by pre-executing the plurality of transactions to the cache process, and the cache process updates the stored state data of the world state according to the pre-execution read-write sets in the pre-execution read-write sets of each transaction.

In other embodiments, after the computing process 603 re-executes the first transaction, the computing process 603 sends a re-execution event notification to the caching process, the re-execution event notification including an execution write set resulting from re-executing the first transaction, the caching process re-updating the stored state data of the world state with the execution write set.

In other embodiments, pre-execution process 601 is configured to: pre-execution readsets of the plurality of transactions are read from the cache process and the plurality of transactions are pre-executed using the read pre-execution readsets.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of one or more embodiments of the present specification. One of ordinary skill in the art can understand and implement it without inventive effort.

One or more embodiments of the present specification further provide a computer-readable storage medium storing a computer program, where the computer program can be used to execute the method for executing a transaction in a blockchain provided in any one of the embodiments of fig. 2 to 5.

One or more embodiments of the present specification also provide a computing device including a memory and a processor, where the memory stores executable code, and the processor executes the executable code to implement the method for performing transactions in a blockchain as provided in any of the embodiments of fig. 2 to 5 above.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry for implementing the logical method flows can be readily obtained by a mere need to program the method flows with some of the hardware description languages described above and into an integrated circuit.

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, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, 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 for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a server system. Of course, this application does not exclude that with future developments in computer technology, the computer implementing the functionality of the above described embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, 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 operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an actual apparatus or end product executes, it may execute sequentially or in parallel (e.g., parallel processors or multi-threaded environments, or even distributed data processing environments) according to the method shown in the embodiment or 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, the presence of additional identical or equivalent elements in a process, method, article, or apparatus that comprises the recited elements is not excluded. For example, if the terms first, second, etc. are used to denote names, they do not denote any particular order.

For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, when implementing one or more of the present description, the functions of each module may be implemented in one or more software and/or hardware, or a module implementing the same function may be implemented by a combination of multiple sub-modules or sub-units, etc. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one type of logical functional division, and other divisions may be realized in practice, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an 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 flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams 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 a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

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

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 computer storage media 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, compact disc read only memory (CD-ROM), Digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic tape 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. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

As will be appreciated by one skilled in the art, 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. Furthermore, one or more embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

One or more embodiments of the present description 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 can 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.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment. In the description of the specification, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," 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 specification. In this specification, the schematic representations of the terms used above are not necessarily intended to refer 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, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

The above description is merely exemplary of one or more embodiments of the present disclosure and is not intended to limit the scope of one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments described herein will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement or the like made within the spirit and principle 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 slave nodes, the method performed by the master node, the method comprising:

pre-executing a plurality of transactions belonging to a first block;

2. The method of claim 1, wherein the predetermined type of transaction is a transaction in the reading set that includes a predetermined variable, the predetermined variable having a random number as a status value.

3. The method of claim 2, wherein the determining that a first transaction of the plurality of transactions is a preset type of transaction comprises:

determining that the first transaction invokes a smart contract during pre-execution of the first transaction;

when the intelligent contract is called, judging whether a preset interface is called or not;

and if the preset interface is called, determining that the first transaction is a preset type of transaction.

4. The method of claim 2, wherein said re-executing said first transaction comprises:

acquiring a consensus result; the consensus result comprises a target state value after consensus; the target state value is a state value of the preset variable in the reading set of the first transaction;

re-executing the first transaction based on the target state value.

5. The method of claim 1, wherein after determining that a first transaction of the plurality of transactions is a preset type of transaction, the method further comprises: the first transaction is marked.

6. The method of claim 1, wherein the first transaction is a preset type of transaction in which a first transaction of the plurality of transactions of the first block is pre-executed; wherein after re-executing the first transaction, the method further comprises:

re-executing a transaction of the plurality of transactions that was pre-executed after the first transaction.

7. The method of claim 1, wherein the master node comprises a pre-execution process, a consensus process, and a computation process; the main node pre-executes the multiple transactions through the pre-execution process and determines that a first transaction in the multiple transactions is a preset type of transaction; the main node performs consensus on the first block through the consensus process; the master node re-executes the first transaction through the computing process.

8. The method of claim 7, wherein the master node further comprises a caching process that stores state data of a latest world state of the blockchain;

wherein after the pre-execution process pre-executes the plurality of transactions, further comprising:

and the pre-execution process submits a pre-execution read-write set of each transaction obtained by pre-executing the plurality of transactions to the cache process, and the cache process updates the stored state data of the world state according to the pre-execution read-write set in the pre-execution read-write set of each transaction.

9. The method of claim 8, further comprising, after the computing process re-executes the first transaction:

the computing process sending a re-execution event notification to the caching process, the re-execution event notification including an execution write set resulting from re-executing the first transaction;

the caching process re-updates the stored state data of the world state with the execution write set.

10. The method of claim 8, wherein the pre-execution process pre-executes the plurality of transactions, comprising:

the pre-execution process reads a pre-execution read set of the plurality of transactions from the cache process and pre-executes the plurality of transactions using the read pre-execution read set.

11. The method of claim 10, wherein the master node further comprises a management process and a storage process; the storage process stores a state database of the block chain; the method further comprises the following steps:

the common identification process acquires the pre-execution read-write set of each transaction from the cache process;

the management process acquires a pre-execution write set in the pre-execution read-write set of each transaction from the consensus process;

in the process of consensus on the first block, the management process updates the state database of the block chain stored by the storage process in parallel based on the pre-execution write set.

12. A master node in a blockchain, the blockchain further comprising a slave node, the master node comprising:

the system comprises a pre-execution process, a first processing unit and a second processing unit, wherein the pre-execution process is used for pre-executing a plurality of transactions belonging to a first block and determining a first transaction in the plurality of transactions as a preset type of transaction;

a consensus process for agreeing with the slave node on the first tile after pre-executing the plurality of transactions;

13. The master node of claim 12, wherein the predetermined type of transaction is a transaction in the read set that includes a predetermined variable, the predetermined variable having a random number as a state value.

14. The master node of claim 13, wherein the pre-execution process determines that a first transaction of the plurality of transactions is a preset type of transaction by:

15. The master node of claim 13, the computing process to re-execute the first transaction by:

re-executing the first transaction based on the target state value.

16. The master node of claim 12, wherein the first transaction is a preset type of transaction for which a first transaction of the plurality of transactions of the first block is pre-executed; wherein, after re-executing the first transaction, the computing process further re-executes a transaction of the plurality of transactions that was pre-executed after the first transaction.

17. The home node of claim 12, wherein the home node further comprises a caching process that stores state data of a latest world state of the blockchain;

after the pre-execution process pre-executes the multiple transactions, the pre-execution process submits pre-execution read-write sets of the multiple transactions obtained by pre-executing the multiple transactions to the cache process, and the cache process updates the stored state data of the world state according to the pre-execution read-write sets in the pre-execution read-write sets of the multiple transactions.

18. The master node of claim 17, wherein, after the computing process re-executes the first transaction, the computing process sends a re-execution event notification to the cache process, the re-execution event notification including an execution write set resulting from re-executing the first transaction; the caching process re-updates the stored state data of the world state with the execution write set.

19. The master node of claim 17, wherein the pre-execution process is configured to: reading pre-execution readsets of the transactions from the caching process and pre-executing the transactions using the read pre-execution readsets.

20. The master node of claim 10, wherein the master node further comprises a management process and a storage process; the storage process stores a state database of the block chain;

the consensus process is further used for acquiring the pre-execution read-write set of each transaction from the cache process;

the management process is used for acquiring the pre-execution writing set in the pre-execution reading set of each transaction from the consensus process; and in the process of consensus on the first block, updating a state database of the block chain stored by the storage process based on the pre-execution write set in parallel.

21. A computer-readable storage medium, on which a computer program is stored which, when executed in a computer, causes the computer to carry out the method of any one of claims 1-11.

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