Method for executing transaction in blockchain and principal node of blockchain

Abstract

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

Description

TECHNICAL FIELD

[0001] One or more embodiments of the present specification relate to the technical field of blockchain, in particular to a method for executing transactions in a blockchain and a master node of the blockchain. BACKGROUND

[0002] Blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. In a blockchain, data blocks are combined into a chain-like data structure in a time sequence, and the data blocks are guaranteed to be unalterable and unforgeable by means of cryptography. Due to the characteristics of decentralization, information unalterability, and autonomy, blockchain has attracted more and more attention and application.

[0003] At present, the execution efficiency of transactions is difficult to improve, and a scheme for efficiently executing transactions is needed. SUMMARY

[0004] One or more embodiments of the present specification provide a method for executing transactions in a blockchain and a master node of the blockchain.

[0005] According to a first aspect, a method for executing transactions in a blockchain is provided, the blockchain comprising a master node and a slave node, the method being executed by the master node, and the method comprising:

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

[0007] determining that a first transaction in the plurality of transactions is a transaction of a preset type;

[0008] after pre-executing the plurality of transactions, performing consensus on the first block with the slave node;

[0009] after completing the consensus on the first block, re-executing the first transaction.

[0010] According to a second aspect, a master node in a blockchain is provided, the blockchain further comprising a slave node, and the master node comprising:

[0011] a pre-execution process configured to pre-execute a plurality of transactions belonging to a first block and determine that a first transaction in the plurality of transactions is a transaction of a preset type;

[0012] a consensus process configured to perform consensus on the first block with the slave node after pre-executing the plurality of transactions;

[0013] a calculation process configured to re-execute the first transaction after completing the consensus on the first block.

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

[0015] According to a fourth aspect, a computing device is provided, 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 one of the above first aspect when executing the program.

[0016] The technical solutions provided by the embodiments of the present specification can include the following beneficial effects:

[0017] The method for executing transactions in a blockchain and the master node of the blockchain provided by the 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 the multiple transactions of the current block, the transaction of the preset type is re-executed after the consensus of the current block is completed. Thus, the execution speed of the block in the blockchain is effectively improved, and the performance of the blockchain system is improved.

[0018] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the drawings required in the embodiment description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments described in the present specification, and other drawings can also be obtained according to these drawings without creative labor for those skilled in the art.

[0020] Figure 1 is a blockchain architecture diagram to which the embodiments of the present specification are applied;

[0021] Figure 2 is a consensus process diagram in a PBFT consensus algorithm according to an exemplary embodiment of the present specification;

[0022] Figure 3 is a process diagram for executing transactions in a blockchain according to an exemplary embodiment of the present specification;

[0023] Figure 4 is a structure diagram of a master node and a slave node of a blockchain according to an exemplary embodiment of the present specification;

[0024] Figure 5 is a flowchart of a method for executing transactions in a blockchain according to an exemplary embodiment of the present specification;

[0025] Figure 6 is a block diagram of a master node in a blockchain according to an exemplary embodiment of the present specification. DETAILED DESCRIPTION

[0026] In order to enable those skilled in the art to better understand the technical solutions in the specification, the technical solutions in the specification will be clearly and completely described below in conjunction with the drawings in the embodiments of the specification. Obviously, the described embodiments are only part of the embodiments of the specification, not all the embodiments. Based on the embodiments in the specification, all other embodiments obtained by those skilled in the art without creative labor should belong to the scope of protection of the specification.

[0027] Blockchain is generally divided into three types: public chain (Public Blockchain), private chain (Private Blockchain) and consortium chain (Consortium Blockchain). In addition, there are various combinations, such as private chain + consortium chain, consortium chain + public chain and different combination forms. Among them, the highest degree of decentralization is the public chain. Participants who join the public chain can read data records on the chain, participate in transactions, and compete for the right to account for new blocks through consensus. In the private chain, the write permission of the network is controlled by an organization or an institution, and the data reading permission is subject to the organization's regulations. Consortium chain is a blockchain between public chain and private chain, which can realize "partial decentralization". Each node in the consortium chain usually has a corresponding entity organization or organization; participants join the network through authorization and form an interest-related consortium to jointly maintain the operation of the blockchain.

[0028] As shown in Figure 1 , it is a blockchain architecture diagram to which the embodiments of the present specification are applied.

[0029] In Figure 1In the illustrated blockchain architecture diagram, the blockchain includes, for example, 6 nodes, including a master node 1 and 5 slave nodes 2-6. The connection between the nodes schematically represents a P2P (Peer to Peer) connection. The nodes can store the full amount of the ledger, i.e., store all blocks and the state of all accounts. Each node in the blockchain can generate the same state in the blockchain by executing the same transactions, and each node in the blockchain can store the same state database. The difference is that the master node 1 can be responsible for pre-executing the received transactions and initiating a consensus proposal to each slave node, which includes, for example, a plurality of transactions in a block to be chunked (e.g., block B1) and pre-execution read-write sets and pre-execution order of each transaction in the consensus proposal. After each node in the blockchain successfully reaches consensus on the consensus proposal, each slave node can execute the plurality of transactions according to the pre-execution order in the consensus proposal, thereby generating the block B1.

[0030] It can be understood that Figure 1 Although the blockchain includes 6 nodes in the above description, the embodiments of the present disclosure are not limited thereto, but can include other numbers of nodes. Specifically, the nodes included in the blockchain can satisfy the Byzantine Fault Tolerance (BFT) requirement. The Byzantine Fault Tolerance requirement can be understood as that there can be Byzantine nodes inside the blockchain, but the blockchain does not exhibit Byzantine behavior externally. Generally, some Byzantine Fault Tolerance algorithms require the number of nodes to be greater than 3f+1, where f is the number of Byzantine nodes (i.e., malicious nodes), for example, PBFT (Practical Byzantine Fault Tolerance).

[0031] In the field of blockchain, a transaction can refer to a task unit executed in the blockchain and recorded in the blockchain. A transaction generally includes a sending field (From), a receiving field (To), and a data field (Data). In the case of a transfer transaction, the From field indicates the account address that initiates the transaction (i.e., initiates the transfer task to another account), the To field indicates the account address that receives the transaction (i.e., receives the transfer), and the Data field includes the transfer amount. In the case of a transaction calling a smart contract in the blockchain, the From field indicates the account address that initiates the transaction, the To field indicates the account address of the contract called by the transaction, and the Data field includes the function name in the called contract and the input parameters of the function, etc., for obtaining the code of the function from the blockchain and executing the code of the function when the transaction is executed.

[0032] The blockchain can provide the function of a smart contract. The smart contract on the blockchain is a contract that can be triggered by a transaction to execute on the blockchain system. The smart contract can be defined in the form of code. Calling the smart contract in the blockchain is to initiate a transaction pointing to the address of the smart contract, so that each node in the blockchain runs the smart contract code in a distributed manner. It should be noted that in addition to creating a smart contract by a user, a system can also set a smart contract in the genesis block. Such a contract is generally referred to as a genesis contract. Generally, the genesis contract can set some data structures, parameters, attributes and methods of the blockchain. In addition, an account with system administrator permission can create a system-level contract or modify a system-level contract (referred to as a system contract). The system contract can be used to add data structures of different businesses in the blockchain.

[0033] In the scenario of deploying a contract, for example, Bob sends a transaction containing information for creating a smart contract (i.e., deploying a contract) to the blockchain as shown in Figure 1 The data field of the transaction includes the code (such as bytecode or machine code) of the contract to be created, and the to field of the transaction is empty, indicating that the transaction is used to deploy the contract. After the nodes reach an agreement through the consensus mechanism, the contract address "0x6f8ae93…" of the contract is determined, each node adds a contract account corresponding to the contract address of the smart contract in the state database, allocates a state storage corresponding to the contract account, and saves the contract code in the state storage of the contract, so that the contract is successfully created.

[0034] In the scenario of calling a contract, for example, Bob sends a transaction for calling a smart contract to the blockchain as shown in Figure 1 The from field of the transaction is the address of the account of the transaction initiator (i.e., Bob), the "0x6f8ae93…" in the to field represents the address of the called smart contract, and the data field of the transaction includes the method and parameters for calling the smart contract. After the transaction is consensus in the blockchain, each node in the blockchain can execute the transaction respectively, thereby executing the contract respectively, and updating the state database based on the execution of the contract.

[0035] One of the decentralized features that distinguishes blockchain technology from traditional technology is that accounting is performed on each node, or distributed accounting, rather than traditional centralized accounting. In order for the blockchain system to become a decentralized honest and trustworthy system that is difficult to attack, public and tamper-proof data record, it needs to achieve secure, clear and irreversible distributed data record in the shortest possible time. In different types of blockchain networks, in order to maintain consistency of the account book in each recording node, a consensus algorithm is usually used to ensure it, i.e., the aforementioned consensus mechanism.

[0036] For example, blockchain nodes can implement a block-level consensus mechanism. For example, after a node (e.g., a unique node) generates a block, if the generated block is recognized by other nodes, the other nodes will record the same block. Another example is a transaction-level consensus mechanism. For example, after a node (e.g., a unique node) obtains a blockchain transaction, if the blockchain transaction is recognized by other nodes, each node that recognized the blockchain transaction can add the blockchain transaction to the latest block it maintains, ultimately ensuring that each node generates the same latest block. The consensus mechanism is a mechanism by which blockchain nodes reach a network-wide consensus on block information (or block data), which can ensure that the latest block is accurately added to the blockchain.

[0037] Current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), and Practical Byzantine Fault Tolerance (PBFT) algorithms. Among these various consensus algorithms, consensus on a consensus proposal is typically determined to be successful only after a predetermined number of nodes reach agreement on the consensus data (i.e., the consensus proposal). Specifically, in the PBFT algorithm, for N ≥ 3f + 1 consensus nodes, f malicious nodes can be tolerated. In other words, consensus is considered successful when 2f + 1 of the N consensus nodes reach agreement.

[0038] Figure 2 Schematic diagram of the consensus process in the PBFT consensus algorithm.

[0039] like Figure 2 As shown in Figure 1, according to the PBFT consensus algorithm, the complete consensus process can be divided into four phases: Request, Pre-Prepare, Prepare, and Commit. Assume that a blockchain includes four consensus nodes, n1 through n4, where n1 is the master node and n2 through n4 are slave nodes. According to the PBFT algorithm, n1 through n4 can tolerate f = 1 malicious node.

[0040] Specifically, in the request phase, a user of the blockchain can send a request, e.g., in the form of a blockchain transaction, to the node n1 through his / her user device. The node n1 can receive multiple transactions from one or more user devices and store the received transactions in a transaction queue. In the preparation phase, the node n1 can take multiple transactions belonging to one block from the transaction queue and generate a consensus proposal for the multiple transactions, broadcast the consensus proposal and the signature of the node n1 on the consensus proposal to other consensus nodes (i.e., nodes n2-n4) so that the consensus nodes continue to reach consensus on the block, which can include, e.g., the transaction body of the multiple transactions and the execution order of the multiple transactions.

[0041] In the preparation phase, each slave node can sign and send the consensus proposal to other nodes. Assuming that the node n4 is a malicious node, the nodes n1, n2 and n3 can determine that the preparation phase is complete after receiving the signatures of 2f=2 other consensus nodes on the consensus proposal, and can enter the commit phase. For example, as shown in FIG. 1B, after receiving the signatures of the nodes n2 and n3, the node n1 verifies that the signatures of the nodes n2 and n3 are both correct signatures on the consensus proposal, and determines that the preparation phase is complete. After receiving the signature of the node n3 and the signature of the node n1 in the preparation phase and verifying that they are correct, the node n2 determines that the preparation phase is complete. Figure 2

[0042] In the commit phase, each consensus node signs and sends the consensus proposal in the commit phase to other consensus nodes, and each consensus node can determine that the commit phase is complete and the consensus is successful after receiving the signatures of 2f=2 other consensus nodes in the commit phase. For example, after receiving the signatures of the nodes n2 and n3 in the commit phase and verifying them, the node n1 determines that the commit phase is complete, so that the node n1 can update the world state according to the execution result of the multiple transactions, generate and store a block (e.g., block B1) including the multiple transactions, and return the execution result of the multiple transactions to the user device. Similarly, after determining that the commit phase is complete, the nodes n2 and n3 execute the multiple transactions, generate and store the block B1, and update the world state according to the execution result of the multiple transactions.

[0043] Through the above process, the storage consistency of the nodes n1, n2 and n3 is achieved. That is, the nodes n1-n4 can still achieve successful consensus on the consensus proposal and complete the execution of the block even if there is one malicious node.

[0044] ​Currently, there is an uncertain transaction that depends on uncertain data, which can be distributed random numbers for example. Therefore, the pre-execution write set obtained by pre-executing the uncertain transaction before consensus cannot be used to update the state database. In the related art, consensus needs to be performed on the uncertain data to obtain consistent data among nodes. After consensus, each node of the blockchain uses the consistent data to formally execute the uncertain transaction to obtain a write set for updating the state database. However, due to the small number of uncertain transactions, the way of re-executing all transactions for uncertain transactions makes it difficult to improve the execution efficiency of the block, and also affects the performance of the blockchain system. The embodiments of the present specification provide a scheme for executing transactions in the blockchain shown in Figure 1 , which can effectively improve the execution speed of the block in the blockchain, thereby improving the performance of the blockchain system.

[0045] Figure 3 is a process diagram for executing transactions in a blockchain according to an exemplary embodiment.

[0046] As shown in Figure 3 , the execution process of the block can be divided into five processes: pre-execution, consensus, transaction execution, state update, and block writing. For each process, the transactions of each block can be processed in turn according to the order of the blocks. Alternatively, the processes of different processes can be completed by different processes.

[0047] Specifically, after the master node of the blockchain obtains the multiple transactions of block N, the master node first pre-executes the transactions of block N to obtain the pre-execution read-write set corresponding to each transaction, which can be used to group the multiple transactions of block N. During the pre-execution of any transaction, it can be determined whether the transaction is a preset type of transaction (i.e., the above-mentioned uncertain transaction). If the transaction is a preset type of transaction, the transaction can be marked or the identification of the transaction can be recorded.

[0048] After completing the pre-execution of the transactions of block N, on the one hand, the master node can perform the preparation stage (hereinafter referred to as the PP stage) of the consensus of block N, that is, generate a consensus proposal for block N and broadcast the consensus proposal to each slave node. The consensus proposal can include, for example, the hash values of the transactions of block N, the pre-execution read-write set of each transaction, and the pre-execution order of the transactions of block N. On the other hand, the master node can also continue to obtain the multiple transactions of block N+1 in parallel, pre-execute the multiple transactions of block N+1, and perform the PP stage of the consensus of block N+1.

[0049] After each of the follower nodes receives the consensus proposal, the main node and the follower nodes perform a preparation phase (hereinafter referred to as a P phase) and a commit phase (hereinafter referred to as a C phase) for consensus on the block N (for details, refer to the process of Figure 2 If the plurality of transactions of the block N include a transaction of a preset type, the uniform data relied on by the transaction of the preset type can be obtained through consensus. After the consensus is completed, the main node obtains the consensus result and re-executes at least the transaction of the preset type. It can be understood that if the plurality of transactions of the block N do not include the transaction of the preset type, the transactions in the block N do not need to be re-executed.

[0050] In the process of consensus on the block N, the main node can also update the world state in the state database in parallel based on the pre-execution write set of each transaction of the block N, and perform the write block on the block N in parallel. If the plurality of transactions of the block N include the transaction of the preset type, the world state in the state database can be updated using the pre-execution write set of the transaction before the transaction of the preset type. After the consensus is completed and the transaction of the preset type is re-executed, the world state in the state database is continuously updated using the execution write set obtained by re-executing the transaction of the preset type.

[0051] It should be noted that after the main node completes the pre-execution of the block N+1, the main node needs to wait until the write block on the block N is completed, and then continue to update the world state in the state database based on the pre-execution write set of each transaction of the block N+1.

[0052] After each of the follower nodes receives the consensus proposal sent by the main node, in the process of consensus on the block N, each of the follower nodes can group the transactions of the block N based on the pre-execution read-write set and the pre-execution order sent by the main node, and execute each of the transactions of the block N in parallel according to the grouping. Alternatively, each of the follower nodes can also update the state database based on the execution write set in parallel in the process of executing the transactions. For example, after each of the follower nodes executes a group of transactions of the block N, the follower nodes can update the state database based on the execution write set of the group of transactions in parallel in the process of executing the next group of transactions. Each of the follower nodes can perform the write block on the block N in parallel in the process of updating the state database based on the execution write set of each of the transactions of the block N.

[0053] It should be noted that if the plurality of transactions of the block N include the transaction of the preset type, the uniform data relied on by the transaction of the preset type can be obtained through consensus. After the consensus is completed, each of the follower nodes can obtain the consensus result and execute the transaction of the preset type in parallel based on the consensus result. In addition, each of the follower nodes needs to wait until the write block on the block N is completed, and then continue to update the state database according to the execution write set of each of the transactions of the block N+1.

[0054] In the embodiment, after the master node pre-executes the current block, if it is determined that there is a transaction of a preset type in the plurality of transactions of the current block, the transaction of the preset type is re-executed after the consensus of the current block is completed. Thus, the execution speed of the block in the blockchain is effectively improved, and the performance of the blockchain system is improved.

[0055] Figure 4 A structure diagram of a master node and a slave node of a blockchain provided by an embodiment of the present specification is shown.

[0056] As shown in Figure 4 , the master node can 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 calculation process 18. The slave node can 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 calculation process 28.

[0057] The master node can interact with the client through the access process 11, for example. The access process 11 can receive a plurality of transactions from the client and transmit the plurality of transactions to the cache process 13, which puts the received transactions into a transaction queue. In addition, the cache process 13 also stores state data of the current latest 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 a preset time interval and pre-executes the obtained transactions to obtain a pre-execution read-write set of each transaction. The pre-execution read-write set of any transaction can include a pre-execution read set and a pre-execution write set. The pre-execution read set can be a key-value pair of a variable read in the process of pre-executing the transaction, and the pre-execution write set can be a key-value pair of a variable written in the process of pre-executing the transaction. In the process of pre-executing the transaction, the state values of the variables in the read set of the transaction can be obtained from the latest state data stored in the cache process 13. After pre-executing each transaction, the pre-execution read-write set of the transaction can be submitted to the cache process 13 for storage, and the state values of the variables in the write set obtained by pre-executing the transaction can be used to update the state data stored in the cache process 13.

[0058] It should be noted that the master node can set multiple pre-execution processes, and the multiple pre-execution processes can pre-execute transactions in parallel. If the transactions are pre-executed in parallel by multiple pre-execution processes, after each transaction is executed, the read set of the pre-executed transaction needs to be verified before the state data stored in the cache process 13 is updated. For example, after the pre-execution of the transaction Tx1 is completed, it can be verified whether the state values of the variables in the read set of the transaction Tx1 stored in the cache process 13 have changed compared with the state values before the pre-execution. If no change occurs, the state values of the variables in the write set obtained by pre-executing the transaction can be directly used to update the state data stored in the cache process 13. If a change occurs, the transaction Tx1 needs to be re-pre-executed by using the new state values of the variables in the read set of the transaction Tx1 stored in the cache process 13.

[0059] In addition, during the pre-execution of any transaction, if it is determined that the transaction is a preset type of transaction, the pre-execution process 12 can notify the cache process 13 that the transaction is a preset type of transaction when submitting the pre-execution read-write set of the transaction to the cache process 13, and the cache process 13 can mark the transaction.

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

[0061] The consensus process 14 can generate a consensus proposal carrying the to-be-consensus data, and broadcast the consensus proposal to other slave nodes in the block chain through the communication process 17. During the consensus process of other slave nodes, the consensus process 14 can return the consensus information to the consensus process 14 through the communication process 17. In addition, the consensus process 14 can also send the transaction body, the pre-execution read-write set, and the pre-execution order of multiple transactions in the block to the management process 16. If the block includes a preset type of transaction, the consensus process 14 can also send the information of the preset type of transaction to the management process 16. After the consensus is completed, the consensus process 14 can also send the consensus result to the management process 16.

[0062] In an implementation, the management process 16 can group the transactions based on the pre-executed read-write sets of the transactions of the block, to obtain grouping information. In another implementation, the management process 16 can also obtain the grouping information of the transactions from other follower nodes. It can be understood that the present embodiment is not limited to the specific manner of obtaining the grouping information by the management process. Then, the management process 16 can 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 generate the block data of the block based on the transaction bodies of the transactions of the block, the pre-executed read-write sets, the grouping information, and the like, and store the block data into the block database in the storage process 15.

[0063] If the block includes a transaction of a preset type, after completing the consensus, the management process 16 can send the transaction of the preset type to the computing process 18, and send the uniform value of the uncertain variable involved in the transaction of the preset type to the computing process 18 based on the consensus result. The computing process 18 can re-execute the transaction of the preset type based on the uniform value of the uncertain variable involved in the transaction of the preset type, and optionally, the computing process 18 can also re-execute each transaction after the transaction of the preset type in the block. On one hand, the computing process 18 can update the state database in the storage process 15 with the write set obtained by re-executing the transaction. On the other hand, the computing process 18 can also send a re-execution event notification to the cache process 13, the re-execution event notification including the execution write set obtained by re-executing each transaction. The cache process 13 can re-update the state data of the stored world state with the execution write set.

[0064] The follower node can interact with the client through the access process 21, for example. The access process 21 can receive a plurality of transactions from the client, and transmit the plurality of transactions to the cache process 23, which can put the received transactions into a transaction queue. The pre-execution process 22 can obtain a batch of transactions from the transaction queue of the cache process 23 at a preset time interval, and verify the obtained transactions, and return the verified transactions to the cache process 23. The cache process 23 can broadcast the verified transactions to the master node and other follower nodes through the communication process 27, and the cache process 23 can also receive transactions from other nodes through the communication process 27.

[0065] On the one hand, consensus process 24 can receive consensus proposals initiated by the master node through communication process 27 and reach consensus on blocks based on the consensus proposals. At the same time, consensus process 24 can send information such as the pre-execution read / write sets and pre-execution order of the multiple transactions in the block included in the consensus proposal to management process 26. During the consensus process, consensus process 24 can return consensus messages to the master node through communication process 27 and receive consensus results from the master node through communication process 27. After consensus is successful, consensus process 24 can send the consensus results to management process 26.

[0066] On the other hand, management process 26 can concurrently group multiple transactions in a block based on their respective pre-execution read-write sets and pre-execution order, resulting in multiple transaction groups. These transaction groups are then assigned to computation processes 28, which can be multiple and can execute the transaction groups in parallel after consensus is reached. When executing transactions, computation processes 28 can retrieve the state values ​​of each variable in the transaction's read set from storage process 25. After each transaction group is executed, computation process 28 verifies the pre-execution write set based on the execution results of the transaction group. If the verification passes, the blockchain status database in storage process 25 is updated based on the execution results of the transaction group. If the verification fails, indicating malicious behavior by the master node, computation process 28 can notify management process 26, which then initiates a master change request to other slave nodes through consensus process 24 to replace the master node.

[0067] Finally, the management process 26 generates the block data of the block based on the transaction bodies of multiple transactions of the block, pre-execution read-write sets, execution read-write sets, grouping information and other information, and stores the block data in the block database in the storage process 25.

[0068] The following will refer to Figure 5 The flowchart of the method for executing a transaction shown in the figure describes the above process in detail. Figure 5 The figure shows the process of executing a block by a master node and any slave node. The master node includes at least a pre-execution process e11, a cache process e12, a consensus process e13, a management process e14, a storage process e15, and a computation process e16. The slave node includes at least a consensus process e21, a management process e22, a computation process e23, and a storage process e24.

[0069] like Figure 5As shown, first, in step 501, the pre-execution process e11 pre-executes a plurality of transactions belonging to block N, which for example include transactions Tx1-Tx6, to obtain a pre-execution read-write set corresponding to each of the transactions Tx1-Tx6. In an embodiment, the pre-execution read-write set of a transaction includes a read set and a write set, where the read set includes key-values of variables read when pre-executing the transaction, and the write set includes key-values of variables written when pre-executing the transaction. In another embodiment, the read set of the pre-execution read-write set can include version numbers of variables read when pre-executing the transaction, and the write set can include version numbers of variables written, where each written value of a variable and a version number corresponding to the written value are stored in the state data of the world state of the blockchain, so that the values read and written by a transaction can be determined by including the version numbers of the variables in the read-write set.

[0070] 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 preset type of transaction, which for example is a transaction including a preset variable in the read set, the preset variable being an uncertain variable using a random number as a state value. Specifically, whether the pre-executed transaction is a preset type of transaction can be determined by the following manner: in the process of pre-executing the transaction, it is determined that the transaction calls a smart contract, and when calling the smart contract, it is determined whether the smart contract calls a preset interface. If the preset interface is called, it is determined that the transaction is a preset type of transaction. The preset interface can be an interface for obtaining a random number, for example. If block N includes a preset type of transaction, the pre-execution process e11 can randomly obtain a random number as a state value of a preset variable involved in 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.

[0071] If transactions Tx1-Tx6 are pre-executed serially by one pre-execution process e11, after pre-executing each transaction, if the transaction is not a preset type of transaction, the pre-execution process e11 can directly transmit the pre-execution read-write set of the transaction to the caching process e12, and the caching process e12 updates the world state stored thereby using the pre-execution write set of the transaction. If the transaction is a preset type of transaction, the pre-execution process e11 can transmit the pre-execution read-write set of the transaction to the caching process e12, and instruct the caching process e12 to mark the transaction.

[0072] If the transactions Tx1-Tx6 are pre-executed in parallel by multiple pre-execution processes e11, after each pre-execution of a transaction, it is necessary to verify whether the read set of the transaction has read-write conflict with other parallel pre-executed transactions. For example, the pre-execution read set of the transaction Tx2 includes variable A, and the pre-execution write set includes variable B. When pre-executing the transaction Tx2, the value of the variable A read is Va, and the transaction Tx2 is pre-executed based on Va. After completing the pre-execution of the transaction Tx2, the value of the variable A in the cache process e12 is checked. If the value of the variable A is still Va, it is determined that there is no read-write conflict. If the value of the variable A is no longer Va, but becomes Vb, the transaction Tx2 can be re-pre-executed based on Vb. It should be noted that, in addition to verifying the read-write conflict through the value of the variable, the read-write conflict can also be verified through the version number of the variable. In the case where there is no read-write conflict, if the transaction is not a preset type of transaction, the pre-execution process e11 can directly transmit the pre-execution read-write set of the transaction to the cache process e12, and the cache process e12 updates the stored world state using the pre-execution write set of the transaction. If the transaction is a preset type of transaction, the pre-execution process e11 can 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.

[0073] Then, in step 503, the consensus process e13 obtains the pre-execution read-write set corresponding to each of the transactions Tx1-Tx6 from the cache process e12, generates a consensus proposal for the block N, and broadcasts the consensus proposal to the follower nodes. The consensus proposal includes the pre-execution read-write set corresponding to each of the transactions Tx1-Tx6. Optionally, the consensus proposal can also include the order in which the pre-execution process e11 pre-executes the transactions Tx1-Tx6, and the hash value of the transactions Tx1-Tx6, and the like. If there is a preset type of transaction in the transactions Tx1-Tx6, the consensus proposal can also include information of the preset variable involved in the preset type of transaction. After the follower nodes receive the consensus proposal, the consensus of the block N is completed together with the leader node. The consensus process e13 of the leader node and the consensus process e21 of the follower node obtain the consensus result. Specifically, the follower nodes can return the consensus message to the leader node, and receive the consensus result sent by the leader node (after the consensus is successful, the consensus process e21 of the follower node can send the consensus result to the management process e22). If there is a preset type of transaction in the transactions Tx1-Tx6, the consensus result can include the unified value of the preset variable involved in the preset type of transaction.

[0074] For example, the transaction Tx3 is a preset type of transaction, the transaction Tx3 includes a variable C, the variable C takes a random number, after consensus, it is determined that the uniform value of the variable C is k, and the consensus result can include the uniform value k of the variable C. The following from node uniformly uses k as the state value of the variable C when executing the transaction Tx3.

[0075] Then, in step 505, the management process e14 obtains the pre-execution write set in the pre-execution read-write set obtained by pre-executing the transactions Tx1-Tx6 from the consensus process e13, and in the process of consensus on the block N, the management process e14 can update the state database stored in the storage process e15 based on the pre-execution write set of the non-preset type of transaction in parallel. Specifically, the management process e14 updates the state database by using the latest state value of the variable in the pre-execution write set of the transactions Tx1-Tx2. For example, the pre-execution write set of the transaction Tx1 includes the variable C, and the pre-execution write set of the transactions Tx2-Tx6 does not involve the variable C, so the state value of the variable C in the pre-execution write set of the transaction Tx1 can be directly used to update the state database. For another example, the pre-execution write set of the transactions Tx1 and Tx2 both include the variable D, and the pre-execution order of the transaction Tx2 is after the transaction Tx1, so the state value of the variable D in the pre-execution write set of the transaction Tx2 is the latest state value of the variable D, and the state database can be updated by using the state value of the variable D in the pre-execution write set of the transaction Tx2. Since the transaction Tx3 is a preset type of transaction, the state database does not need to be updated by using the pre-execution write set of the transactions Tx3-Tx6.

[0076] In step 507, after completing the consensus on the block N, the management process e14 sends the transactions Tx3-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 e16. The computing process e16 re-executes the transactions Tx3-Tx6 based on the value k of the variable C, and updates the state database in the storage process e15 based on the re-execution result. In addition, the computing process e16 can also send a re-execution event notification to the cache process e12, and the re-execution event notification can include the execution write set obtained by re-executing the transactions Tx3-Tx6. The cache process e12 can update the state data stored therein by using the execution write set of the transactions Tx3-Tx6.

[0077] In step 509, after completing the update of the state database in storage process e15, management process e14 performs the write block operation on block N. Specifically, management process e14 generates the block header and the block body of block N, and stores the block header and the block body of block N into the block database in storage process e15. The block body includes, for example, the transaction body of each of transactions Tx1-Tx6, the receipt, and the like. The block header can include the state root, the receipt root, the transaction root, and the like.

[0078] In step 511, consensus process e21 of the follower node can send the pre-execution read-write set, the pre-execution order, and the uniform value k of variable C included in transaction Tx3 of transactions Tx1-Tx6 included in the received consensus proposal to management process e22. In the process of consensus, management process e22 groups transactions Tx1-Tx6 of the block based on the pre-execution read-write set and the pre-execution order in parallel, to obtain a plurality of transaction groups. The transactions in different transaction groups do not have conflicting variables, and the order of the transactions in the same transaction group is consistent with the pre-execution order. Then, each transaction group is executed in parallel. For example, transactions Tx1, Tx2, and Tx4 are transaction group a, and transactions Tx3, Tx5, and Tx6 are transaction group b.

[0079] Then, management process e22 can assign the plurality of transaction groups, for example, transaction group a and transaction group b, to a plurality of computing processes e23, and the plurality of computing processes e23 execute transaction group a and transaction group b in parallel at the same time, execute the transactions in transaction group a in series in the pre-execution order, and execute the transactions in transaction group b in series in the pre-execution order.

[0080] In step 513, computing process e23 updates the state database stored in storage process e24 using the write set of each transaction group after the execution of the transaction group is completed, and sends the execution result of the transaction group to management process e22. For example, after the execution of transaction group a is completed, computing process e23 can obtain the latest state values of all variables involved in the execution write set of transactions Tx1, Tx2, and Tx4, and update the state database using the obtained latest state values of the variables. Finally, in step 513, after computing process e23 of the follower node completes the update of the state database in storage process e24, management process e22 performs the write block operation on block N. The specific process of the write block operation is similar to that of the master node, and is not described herein.

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

[0082] It should be noted that although the operations of the method of the embodiments of the present specification are described in a specific order in the above embodiments, this does not require or imply that the operations must be performed in this specific order, or that all of the illustrated operations must be performed to achieve desirable results. Instead, the order of the steps depicted in the flowcharts can be changed. Additionally or alternatively, certain steps can be omitted, multiple steps can be combined into one step, and / or one step can be split into multiple steps.

[0083] Corresponding to the above method embodiments for executing transactions in a blockchain, the present specification also provides embodiments of an apparatus for executing transactions in a blockchain.

[0084] As Figure 6 indicated, Figure 6 is a block diagram of a master node in a blockchain according to an exemplary embodiment of the present specification, the blockchain further comprising a slave node, the master node can comprise a pre-execution process 601, a consensus process 602 and a calculation process 603.

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

[0086] The consensus process 602 is configured to perform consensus on the first block with the slave node after pre-executing the multiple transactions.

[0087] The calculation process 603 is configured to re-execute the first transaction after completing the consensus on the first block.

[0088] In some embodiments, the above-mentioned transaction of a preset type is a transaction including a preset variable in a read set, and the preset variable uses a random number as a state value.

[0089] In other embodiments, the pre-execution process 601 can determine that the first transaction in the multiple transactions is a transaction of a preset type by determining that the first transaction calls a smart contract during pre-execution of the first transaction, and determining whether a preset interface is called when the smart contract is called, and if the preset interface is called, determining that the first transaction is a transaction of a preset type.

[0090] In some embodiments, the consensus process 602 can re-execute the first transaction by obtaining a consensus result including a consensused target state value of the preset variable in the read set of the first transaction, and re-executing the first transaction based on the target state value.

[0091] In some embodiments, the first transaction is a preset type of transaction that is first pre-executed among the plurality of transactions of the first block. After re-executing the first transaction, the computing process 603 re-executes the transactions that are pre-executed after the first transaction among the plurality of transactions.

[0092] In some embodiments, the master node further comprises a cache process (not shown in the figure) that stores state data of the latest world state of the blockchain. After the pre-execution process 601 pre-executes the plurality of transactions, the pre-execution process 601 submits the 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 write set in the pre-execution read-write set of each transaction.

[0093] In some embodiments, after the computing process 603 re-executes the first transaction, the computing process 603 sends a re-execution event notification to the cache process, the re-execution event notification including the execution write set obtained by re-executing the first transaction, and the cache process re-updates the stored state data of the world state using the execution write set.

[0094] In some embodiments, the pre-execution process 601 is configured to read the pre-execution read set of the plurality of transactions from the cache process, and pre-execute the plurality of transactions using the read pre-execution read set.

[0095] For the device embodiment, since it basically corresponds to the method embodiment, the relevant part is described in the part of the method embodiment. The device embodiment described above is only illustrative, wherein the units described as separate components can or can not be physically separated, and the components displayed as units can or can not be physical units, i.e., they can be located in one place or distributed on multiple network units. Some or all of the modules can be selected to achieve the purpose of one or more embodiments of the present specification according to actual needs. Those skilled in the art can understand and implement it without creative labor.

[0096] The one or more embodiments of the present specification also provide a computer readable storage medium storing a computer program, the computer program being used to execute the above Figures 2 to 5 Any embodiment provides a method for executing transactions in a blockchain.

[0097] One or more embodiments of the present specification also provide a computing device comprising a memory and a processor, the memory having stored therein executable code, the processor implementing the above-mentioned Figures 2 to 5 Any embodiment provides a method of executing a transaction in a blockchain.

[0098] In the 1990s, it was quite obvious to distinguish whether an improvement in a technology was in hardware (e.g., improvement in circuit structures of diodes, transistors, switches, etc.) or in software (improvement in method flow). However, as technology has evolved, many improvements in method flow today can be considered as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structures by programming the improved method flow into hardware circuits. Therefore, it cannot be said that an improvement in a method flow cannot be implemented by hardware entity modules. For example, a programmable logic device (PLD) (e.g., a field programmable gate array (FPGA)) is an integrated circuit whose logic function is determined by user programming of the device. A digital system is "integrated" on a PLD by the designer programming it, rather than by asking a chip manufacturer to design and fabricate a custom integrated circuit chip. Moreover, instead of manually fabricating integrated circuit chips, this programming is now mostly implemented by "logic compiler" software, which is similar to software compilers used in program development, and the original code to be compiled is written in a specific programming language, which is called a hardware description language (HDL), and there are many such languages, 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., and the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should be aware that, as long as the method flow is logically programmed in the above-mentioned hardware description languages and programmed into an integrated circuit, a hardware circuit implementing the logical method flow can be easily obtained.

[0099] The controller can be implemented in any suitable way, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code, such as 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 can also be implemented as part of the control logic of the memory. The skilled person will also appreciate that, in addition to implementing the controller in pure computer readable program code, it is possible to implement the controller in the form of logic gates, switches, an application specific integrated circuit, a programmable logic controller and an embedded microcontroller, etc. to perform the same functions by logically programming the method steps. Such a controller can therefore be considered to be a hardware component, and the means included therein to perform the various functions can also be considered to be structures within the hardware component. Alternatively, or even additionally, the means to perform the various functions can be considered to be both a software module implementing the method and a structure within a hardware component.

[0100] The systems, apparatuses, modules or units illustrated by the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present application does not rule out that with the development of future computer technologies, computers implementing the functions of the above embodiments can be personal computers, laptop computers, vehicle human-computer interaction devices, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, electronic mail devices, game consoles, tablet computers, wearable devices, or combinations of any of these devices.

[0101] Although the method operations of the embodiments of the present specification are described in sequential order, some of the operations can in practical implementations be performed concurrently, in parallel, or in a different order. The above description of the embodiments of the present specification is provided as an example only and is not intended to be limiting. For example, the steps recited in the examples or flow charts can include more, fewer, or different steps than those described. The order in which the steps are presented is merely one example and is not intended to be limiting. The steps can be performed in an order different than presented, or performed in parallel, or in a different order, for example in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment. The terms "comprise", "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 can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Exclusion of such elements is only present if it is expressly stated that these elements are excluded. For example, use of the terms "first", "second", or the like does not denote any order or importance, but rather the terms are used to distinguish one element from another.

[0102] For ease of description, the above apparatuses are described in various modules with different functions. Of course, when implementing one or more of the present specification, the functions of the modules can be implemented in one or more software and / or hardware, or the modules implementing the same function can be implemented by a combination of sub-modules or sub-units. The above-described apparatus embodiments are only illustrative, for example, the division of the units is only a logical function division, and in actual implementation, another division mode can be used, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed each other can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0103] The present application is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, as well as combinations of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus produce a means for implementing the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions of a flow or multiple flows and / or blocks Figure 1 The functions of a flow or multiple flows and / or blocks

[0104] These computer program instructions can 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 instructions which implement the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0105] These computer program instructions can 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 Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

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

[0107] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, non-volatile memory, such as read-only memory (ROM), EPROM, and / or flash memory. The memory is an example of computer-readable media.

[0108] Computer-readable media includes permanent and non-permanent, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules 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 disc (DVD), or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage, graphene storage, or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to computing devices. According to the definition herein, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

[0109] Those skilled in the art will appreciate that the one or more embodiments described herein can be provided as a method, a system or a computer program product. Accordingly, the one or more embodiments described herein can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the one or more embodiments described herein 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-ROMs, optical storage devices, etc.) embodying computer readable code.

[0110] The one or more embodiments described herein can 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. The one or more embodiments described herein 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 can be located in both local and remote computer storage media including memory storage devices.

[0111] The various embodiments described in this specification can 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. The various embodiments described in this 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 can be located in both local and remote computer storage media including memory storage devices.

[0112] The above description is only some embodiments of the one or more embodiments described in this specification and is not intended to limit the one or more embodiments described in this specification. Those skilled in the art can make various modifications and changes to the one or more embodiments described in this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the one or more embodiments described in this specification shall be included in the scope of the claims.

Claims

1. A method for executing a transaction in a blockchain, the blockchain comprising a master node and a slave node, the method being executed by the master node, the method comprising: Pre-execute multiple transactions belonging to the first block; Determining that a first transaction among the multiple transactions is a transaction of a preset type; wherein the transaction of the preset type is a transaction that includes a preset variable in a read set, and the preset variable uses a random number as a state value; After pre-executing the plurality of transactions, reaching a consensus on the first block with the slave node; After reaching a consensus on the first block, the first transaction is re-executed.

2. The method according to claim 1, wherein Determining that the first transaction among the multiple transactions is a transaction of a preset type includes: During pre-execution of the first transaction, determining that the first transaction invokes a smart contract; When calling the smart contract, determine whether to call the preset interface; If the preset interface is called, it is determined that the first transaction is a transaction of a preset type.

3. The method according to claim 1, wherein The re-executing the first transaction includes: Obtain a consensus result; the consensus result includes a target state value after consensus; the target state value is the state value of the preset variable in the read set of the first transaction; The first transaction is re-executed based on the target state value.

4. The method according to claim 1, wherein After determining that a first transaction among the multiple transactions is a transaction of a preset type, the method further includes: marking the first transaction.

5. The method according to claim 1, wherein The first transaction is the first pre-executed transaction of a preset type among multiple transactions in the first block; wherein, after re-executing the first transaction, the method further includes: A transaction among the plurality of transactions that was pre-executed after the first transaction is re-executed.

6. The method according to claim 1, wherein The master node includes a pre-execution process, a consensus process, and a computation process; the master node pre-executes the multiple transactions through the pre-execution process and determines that a first transaction among the multiple transactions is a transaction of a preset type; the master node reaches a consensus on the first block through the consensus process; The master node re-executes the first transaction through the computing process.

7. The method according to claim 6, wherein: The master node also includes a cache process, which stores state data of the latest world state of the blockchain; After the pre-execution process pre-executes the plurality of transactions, the method further includes: The pre-execution process submits the pre-execution read-write sets of each transaction obtained by pre-executing the multiple transactions to the cache process, and the cache process updates the state data of the stored world state according to the pre-execution write sets in the pre-execution read-write sets of each transaction.

8. The method according to claim 7, further comprising, after the computing process re-executes the first transaction: The computing process sends a re-execution event notification to the cache process, where the re-execution event notification includes an execution write-set obtained by re-executing the first transaction; The cache process re-updates the state data of the stored world state using the execution write set.

9. The method according to claim 7, wherein: The pre-execution process pre-executes the plurality of transactions, including: The pre-execution process reads the pre-execution read sets of the multiple transactions from the cache process, and pre-executes the multiple transactions using the read pre-execution read sets.

10. The method according to claim 9, wherein: The master node also includes a management process and a storage process; The storage process stores a state database of the blockchain; the method further includes: The consensus process obtains the pre-execution read-write set of each transaction from the cache process; The management process obtains the pre-execution write set in the pre-execution read-write set of each transaction from the consensus process; During consensus on the first block, the management process concurrently updates a state database of the blockchain stored by the storage process based on the pre-execution write set.

11. A master node in a blockchain, the blockchain further comprising slave nodes, the master node comprising: a pre-execution process, configured to pre-execute multiple transactions belonging to the first block and determine that a first transaction among the multiple transactions is a transaction of a preset type; wherein the transaction of the preset type is a transaction in a read set that includes a preset variable, and the preset variable uses a random number as a state value; a consensus process, configured to reach a consensus on the first block with the slave node after pre-executing the plurality of transactions; A computing process is used to re-execute the first transaction after reaching a consensus on the first block.

12. The master node according to claim 11, wherein: The pre-execution process determines that the first transaction among the multiple transactions is a transaction of a preset type by: During pre-execution of the first transaction, determining that the first transaction invokes a smart contract; When calling the smart contract, determine whether to call the preset interface; If the preset interface is called, it is determined that the first transaction is a transaction of a preset type.

13. The master node according to claim 11, wherein the computing process re-executes the first transaction in the following manner: Obtain a consensus result; the consensus result includes a target state value after consensus; the target state value is the state value of the preset variable in the read set of the first transaction; The first transaction is re-executed based on the target state value.

14. The master node according to claim 11, wherein: The first transaction is the first pre-executed transaction of a preset type among multiple transactions in the first block; wherein, after re-executing the first transaction, the computing process further re-executes transactions among the multiple transactions that were pre-executed after the first transaction.

15. The master node according to claim 11, wherein: The master node also includes a cache process, which stores state data of the latest world state of the blockchain; After the pre-execution process pre-executes the multiple transactions, the pre-execution process submits the pre-execution read-write sets of each transaction obtained by pre-execution of the multiple transactions to the cache process, and the cache process updates the state data of the stored world state according to the pre-execution write sets in the pre-execution read-write sets of each transaction.

16. The master node according to claim 15, wherein: After the computing process re-executes the first transaction, the computing process sends a re-execution event notification to the cache process, where the re-execution event notification includes an execution write set obtained by re-executing the first transaction; the cache process re-updates state data of the stored world state using the execution write set.

17. The master node according to claim 15, wherein: The pre-execution process is configured to: read the pre-execution read sets of the multiple transactions from the cache process, and pre-execute the multiple transactions using the read pre-execution read sets.

18. The master node according to claim 17, wherein: The master node also includes a management process and a storage process; the storage process stores the state database of the blockchain; The consensus process is further configured to obtain the pre-execution read-write set of each transaction from the cache process; The management process is configured to obtain a pre-execution write set in the pre-execution read-write set of each transaction from the consensus process; and in parallel, during the consensus process on the first block, update the state database of the blockchain stored by the storage process based on the pre-execution write set.

19. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to any one of claims 1 to 10.

20. A computing device comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 10 is implemented.

Images