WO2024001032A1 - Method for executing transaction in blockchain system, and blockchain system and nodes - Google Patents

Abstract

A method for executing a transaction in a blockchain, and a blockchain system and nodes. The blockchain comprises a master node and a plurality of slave nodes. The method is executed by the master node, and comprises: after pre-execution of a first transaction is started, when it is determined that the first transaction comprises invoking a first contract of a preset type, terminating the pre-execution of the first transaction, and recording first information, wherein the first information is used for indicating that the first transaction comprises invoking a contract of the preset type, and the execution of the contract of the preset type depends on data which is generated by means of consensus; generating a consensus proposal of a first block, wherein the consensus proposal comprises the first information; and sending the consensus proposal to at least some slave nodes, so as to achieve a consensus on the consensus proposal with the at least some slave nodes.

Description

Methods, blockchain systems and nodes for executing transactions in a blockchain system

This application requires priority for the Chinese patent application submitted to the State Intellectual Property Office of China on June 29, 2022, with the application number 202210753256.4 and the application name "Method, blockchain system and node for executing transactions in a blockchain system" rights, the entire contents of which are incorporated herein by reference.

Technical field

The embodiments of this specification belong to the field of blockchain technology, and in particular relate to a method of executing transactions in a blockchain system, a blockchain system, and nodes.

Background technique

Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. In the blockchain system, data blocks are combined into a chained data structure in a chronological manner and are cryptographically guaranteed to be an untamperable and unforgeable distributed ledger. Due to the characteristics of blockchain, such as decentralization, non-tamperable information, and autonomy, blockchain has also received more and more attention and applications. In a related technology, in order to speed up the execution of transactions in the blockchain, the master node pre-executes multiple transactions and obtains the variable access information of the multiple transactions, so that the slave node can execute multiple transactions in parallel based on the variable access information. , to speed up transaction execution.

Contents of the invention

The purpose of the present invention is to provide a solution for executing transactions in a blockchain, which can improve the transaction execution speed.

A first aspect of this specification provides a method for executing transactions in a blockchain system. The blockchain system includes a master node and a plurality of slave nodes. The method is executed by the master node and includes:

After starting the pre-execution of the first transaction, when it is determined that the first transaction includes a call to the first contract of the preset type, the pre-execution of the first transaction is terminated and the first information is recorded. Used to indicate that the first transaction includes a call to a preset type of contract, where the execution of the preset type of contract relies on data generated by consensus;

Generate a consensus proposal for the first block, the consensus proposal including the first information;

The consensus proposal is sent to at least some slave nodes, and the consensus proposal is reached with the at least some slave nodes.

The second aspect of this specification provides a method for executing transactions in a blockchain system. The blockchain system includes a master node and a slave node. An account list of a preset type of contract is stored in the blockchain system. The execution of the preset type of contract relies on the data generated by consensus, and the method is executed by the slave node, including:

A consensus proposal for the first block is received from the master node. The consensus proposal includes first information of the first transaction. The first information is used to indicate that the first transaction includes the first transaction of a preset type. Contract call;

Consensus on the consensus proposal with the master node and at least some other slave nodes;

After consensus is reached, when executing the first transaction, it is determined that the first transaction includes a call to a preset type of contract, and the first transaction does not involve accounts other than accounts included in the list. When, the execution of the first transaction is completed.

Wherein, the list of accounts storing contracts of a preset type in the blockchain system includes a list of accounts storing contracts of a preset type in multiple nodes in the blockchain system.

The third aspect of this specification provides a master node in the blockchain, including:

A pre-execution unit, configured to terminate the pre-execution of the first transaction when it is determined that the first transaction includes a call to a first contract of a preset type after starting the pre-execution of the first transaction, wherein, the The execution of preset types of contracts relies on data generated by consensus;

A consensus unit, configured to generate a consensus proposal for the first block, the consensus proposal including the first information of the first transaction, the first information being used to indicate that the first transaction includes a preset type of Calling the contract; sending the consensus proposal to at least some slave nodes of the blockchain, and reaching consensus on the consensus proposal with the at least some slave nodes.

The fourth aspect of this specification provides a slave node in a blockchain. The blockchain stores an account list of a preset type of contract. The execution of the preset type of contract relies on data generated by consensus, so The slave nodes include:

A consensus unit configured to receive a consensus proposal of the first block from the master node of the blockchain, the consensus proposal including first information of the first transaction, the first information being used to indicate the first transaction including calling a first contract of a preset type; performing consensus on the consensus proposal with the master node and at least some other slave nodes;

An execution unit, configured to, after reaching consensus, when executing the first transaction, determine that the first transaction includes a call to a preset type of contract, and the first transaction does not involve other than those included in the list. When the account is outside the account, the execution of the first transaction is completed.

The fifth aspect of this specification provides a blockchain, including a master node and multiple slave nodes. The blockchain stores an account list of a preset type of contract. The execution of the preset type of contract relies on consensus. generated data,

The master node is configured to terminate the pre-execution of the first transaction when it is determined that the first transaction includes a call to the first contract of the preset type after starting the pre-execution of the first transaction; generate a third A consensus proposal for a block, the consensus proposal includes the first information of the first transaction, the first information is used to indicate that the first transaction includes a call to a preset type of contract; the The consensus proposal is sent to at least some slave nodes, and the consensus proposal is reached with the at least some slave nodes;

The slave node is used to receive the consensus proposal from the master node, and conduct consensus on the consensus proposal with the master node and at least some other slave nodes; after the consensus is reached, when executing the first transaction , when it is determined that the first transaction includes a call to a preset type of contract and the first transaction does not involve accounts other than the accounts included in the list, the execution of the first transaction is completed.

A sixth aspect of this specification provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to execute the method described in the first aspect or the second aspect.

A seventh aspect of this specification provides a computing device, including a memory and a processor. The memory stores executable code. When the processor executes the executable code, it implements the first aspect or the second aspect. method.

Through the solution provided by the embodiments of this specification, transactions involving preset types of contracts and transactions involving non-preset types of accounts are separated for pre-execution or execution, thereby avoiding the situation of inconsistency between pre-execution status and execution status, and It ensures the immediacy and randomness of transaction execution and improves transaction execution efficiency.

Description of drawings

In order to explain the technical solutions of the embodiments of this specification more clearly, the drawings needed to be used in the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some of the embodiments recorded in this specification. , for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without exerting creative labor.

Figure 1 is a block chain architecture diagram in the embodiment of this specification;

Figure 2 is a schematic diagram of the consensus process in the PBFT consensus algorithm;

Figure 3 shows the blockchain structure diagram in the embodiment of this specification;

Figure 4 is a flow chart of a method for executing transactions in the embodiment of this specification;

Figure 5 is an architectural diagram of a master node in a blockchain in an embodiment of this specification;

Figure 6 is an architectural diagram of a slave node in a blockchain in an embodiment of this specification.

Detailed ways

In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of this specification. Obviously, the described The embodiments are only some of the embodiments of this specification, but not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts should fall within the scope of protection of this specification.

Figure 1 shows the blockchain architecture diagram in the embodiment of this specification. As shown in Figure 1, the blockchain includes, for example, a total of 6 nodes including master node 1, slave node 2 to slave node 5. The connections between nodes schematically represent P2P (Peer to Peer, point-to-point) connections. These nodes store the entire ledger, which stores the status of all blocks and all accounts. Among them, each node in the blockchain generates the same state in the blockchain by executing the same transaction, and each node in the blockchain stores the same state database. The difference is that the master node 1 can be responsible for receiving transactions from the client and initiating a consensus proposal to each slave node. The consensus proposal includes, for example, multiple transactions in the block to be formed (such as block B1) and each Transaction submission order and other information. After the nodes in the blockchain successfully reach consensus on the consensus proposal, each node can execute the multiple transactions according to the submission order in the consensus proposal, thereby generating block B1.

It can be understood that the blockchain shown in FIG. 1 is only exemplary, and the embodiments of this specification are not limited to application to the blockchain shown in FIG. 1 , and may also be applied to a blockchain system including sharding, for example.

In addition, although FIG. 1 shows that the blockchain includes 6 nodes, the embodiments of this specification are not limited to this, and may include other numbers of nodes. Specifically, the nodes included in the blockchain can meet Byzantine Fault Tolerance (BFT) requirements. The mentioned Byzantine fault tolerance requirements can be understood as meaning that Byzantine nodes can exist within the blockchain, but the blockchain does not reflect Byzantine behavior externally. 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, such as the Practical Byzantine Fault Tolerance algorithm PBFT (Practical Byzantine Fault Tolerance).

Transactions in the blockchain field can refer to task units that are executed and recorded in the blockchain. Transactions usually include sending fields (From), receiving fields (To) and data fields (Data). Among them, when the transaction is a transfer transaction, the From field represents the account address that initiated the transaction (that is, initiated a transfer task to another account), the To field represents the account address that received the transaction (that is, received the transfer), and the Data field Include transfer amount. In the case of a transaction calling a smart contract in the blockchain, the From field indicates the account address that initiated the transaction, the To field indicates the account address of the contract called by the exchange, and the Data field includes the function name in the calling contract and the corresponding Data such as the incoming parameters of the function are used to obtain the code of the function from the blockchain and execute the code of the function when the transaction is executed.

The functions of smart contracts can be provided in the blockchain. Smart contracts on the blockchain are contracts that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract in the blockchain is to initiate a transaction pointing to the smart contract address, allowing each node in the blockchain to run the smart contract code in a distributed manner. It should be noted that in addition to smart contracts that can be created by users, smart contracts can also be set by the system in the genesis block. This type of contract is generally called a creation contract. Generally, some blockchain data structures, parameters, properties and methods can be set in the genesis contract. In addition, accounts with system administrator rights can create system-level contracts or modify system-level contracts (referred to as system contracts). Among them, the system contract can be used to add data structures for different business data in the blockchain.

In the scenario of deploying a contract, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying the contract) to the blockchain as shown in Figure 1. The data field of the transaction includes the code of the contract to be created ( Such as bytecode or machine code), the to field of the transaction is empty to indicate 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 the contract account corresponding to the contract address of the smart contract in the state database, allocates the state storage corresponding to the contract account, and stores The contract code is saved in the state storage of the contract, so the contract is created successfully.

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 (Bob). "0x6f8ae93..." in the to field represents the address of the smart contract being called, and the data field of the transaction includes the method and parameters for calling the smart contract. After consensus is reached on the transaction in the blockchain, each node in the blockchain can execute the transaction respectively, thereby executing the contract respectively, and update the status database based on the execution of the contract.

One of the decentralized features of blockchain technology that distinguishes it from traditional technology is that accounting is performed on each node, or distributed accounting, instead of traditional centralized accounting. In order for the blockchain system to become a decentralized, honest and trustworthy system that is hard to break, open, and cannot tamper with data records, it needs to make distributed data records secure, clear, and irreversible in the shortest possible time. In different types of blockchain networks, in order to maintain the consistency of the ledger in each node that records the ledger, a consensus algorithm is usually used to ensure it, that is, the consensus mechanism mentioned above.

For example, blockchain nodes can implement a block-granular consensus mechanism. For example, after a node (such as a unique node) generates a block, if the generated block is recognized by other nodes, the records of other nodes will be the same. block. For another example, a transaction-granularity consensus mechanism can be implemented between blockchain nodes. For example, after a node (such as a unique node) obtains a blockchain transaction, if the blockchain transaction is recognized by other nodes, Each node that recognizes the blockchain transaction can add the blockchain transaction to the latest block maintained by itself, and ultimately ensure that each node generates the same latest block. The consensus mechanism is a mechanism for blockchain nodes to reach a consensus across the entire network on block information (or block data), which can ensure that the latest blocks are accurately added to the blockchain.

The current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) ) algorithm, etc. Among various consensus algorithms, the consensus success of the consensus proposal is usually determined after a preset number of nodes reach an agreement on the consensus data (ie, consensus proposal). Specifically, in the PBFT algorithm, for N ≥ 3f + 1 consensus nodes, f malicious nodes can be tolerated. That is to say, when 2f + 1 nodes among the N consensus nodes reach an agreement, the consensus can be determined to be successful.

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

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

Specifically, in the request phase, the user of the blockchain can send a request to the node n1 through its user device, and the request is, for example, in the form of a blockchain transaction. Node n1 can receive multiple transactions from one or more user devices and store the received transactions in a transaction queue. In the preliminary stage, node n1 can take out multiple transactions belonging to a block from the transaction queue, generate a consensus proposal for the multiple transactions, and broadcast the consensus proposal and node n1's signature on the consensus proposal to other consensus nodes ( That is, node n2 - node n4), so that the consensus node continues to consensus on the block. The consensus proposal may include, for example, the transaction body of the multiple transactions and the execution order of the multiple transactions and other information.

During the preparation phase, each slave node can sign the consensus proposal and send it to each other node. Assuming that node n4 is a malicious node, node n1, node n2 and node n3 can determine that the preparation phase is completed and can enter the submission phase after receiving the signatures of 2f = 2 other consensus nodes on the consensus proposal. For example, as shown in Figure 2, after node n1 receives the signatures of node n2 and node n3, it verifies that the signatures of node n2 and node n3 are correct signatures of the consensus proposal, then it is determined that the preparation phase is completed, and node n2 is After receiving the signature of node n3 and the signature of node n1 in the preparation phase and passing the verification, it is determined that the preparation phase is completed.

In the submission phase, each consensus node signs the consensus proposal in the submission phase and sends it to each other consensus node. After receiving the signatures of 2f = 2 other consensus nodes in the submission phase, each consensus node can confirm that the submission phase is completed and the consensus success. For example, after receiving and verifying the signatures of the submission phase of node n2 and node n3, node n1 determines that the submission phase is completed. Therefore, node n1 can update the world state based on the execution results obtained by executing the multiple transactions, generate and store the Blocks of multiple transactions (such as block B1), and return the execution results of multiple transactions to the user device. Similarly, after determining that the submission phase is completed, node n2 and node n3 execute the multiple transactions, generate and store block B1, and update the world state based on the execution results of the multiple transactions.

Through the above process, the storage consistency of node n1, node n2 and node n3 is achieved. In other words, nodes n1-node n4 can still achieve successful consensus on the consensus proposal and complete the execution of the block even if there is a malicious node.

In related technologies, in order to improve the transactions per second (TPS) indicator in the blockchain, it is necessary to speed up the execution of transactions. To this end, transactions can be executed faster in blockchain nodes by executing them in parallel. In one implementation, the blockchain node can execute transactions in parallel through multiple processes in a single machine. In another implementation, the blockchain node can be deployed in a server cluster and execute transactions in parallel through multiple servers. Usually, for transfer transactions, the blockchain node first divides multiple transactions into multiple transaction groups according to the accounts accessed by the transactions. Each transaction group does not access the same account, so that each transaction group can be executed in parallel. However, when a smart contract is called in a transaction, the variables accessed in the transaction cannot be predicted before the transaction is executed, so multiple transactions cannot be effectively grouped, and transactions cannot be executed in parallel.

In a related technology, in a blockchain including a master node and multiple slave nodes, multiple transactions can be pre-executed by the master node to obtain respective pre-execution read and write sets of the multiple transactions, and based on the pre-execution read and write sets Write sets divide multiple transactions into multiple groups so that each slave node can execute multiple transactions in parallel according to multiple groups.

Figure 3 shows a structural diagram of the master node 1 and slave nodes (for example, slave node 2) of the blockchain provided by the embodiment of this specification. As shown in Figure 3, the master node 1 includes a pre-execution module 11, a conflict detection module 12 and a consensus module 13, and the slave node 2 includes a consensus module 22 and a calculation module 23. Masternode 1 can for example be connected to a client so that multiple transactions can be received from the client. After the master node 1 receives each transaction, the pre-execution module 11 pre-executes the transaction and obtains the pre-execution read and write set of the transaction. Among them, the pre-execution read and write set includes a pre-execution read set and a pre-execution write set. The pre-execution read set can specifically be the key-value pairs of read variables generated during the pre-execution transaction. The pre-execution write set can specifically be Key-value pairs of written variables generated during the pre-execution transaction. The master node 1 can maintain a pre-execution status set, and the pre-execution module 11 can read the status values of variables from the pre-execution status set or the status database when pre-executing a transaction. After pre-executing the transaction, the pre-execution module 11 can update the pre-execution status set according to the pre-execution read and write set of the transaction.

As shown in Figure 3, the pre-execution module 11 may include multiple pre-execution sub-modules, such as the pre-execution sub-module 111 and the pre-execution sub-module 112. These two pre-execution sub-modules can pre-execute transactions in parallel. The conflict detection module 12 includes a pre-execution status set and a pre-execution transaction set, wherein the master node 1 stores the pre-execution status set and the pre-execution transaction set in the memory for use by the conflict detection module 12 . The conflict detection module 12 performs pre-execution conflict detection on each transaction serially. Specifically, the conflict detection module 12 detects whether there is a conflict between the pre-execution read set of the transaction and the write set of the transaction that has been pre-executed. If the value of a certain variable in the pre-execution read set of the transaction is inconsistent with the variable in the pre-execution status set If the values are different, it can be determined that there is a conflict. If it is determined that there is no conflict, the conflict detection module 12 updates the status in the pre-execution write set of the transaction to the pre-execution status set, and arranges the transaction sequence into the pre-execution transaction set.

The consensus module 13 obtains multiple previously recorded sequential transactions from the pre-execution transaction set. The consensus module 13 can group the multiple transactions according to their respective pre-execution read and write sets to obtain multiple transaction groups. , there are no conflicting transactions between each transaction group. Among them, the situation where there are conflicting transactions between two transaction groups usually includes the following situations: the transaction in the first transaction group reads the first variable (that is, the first transaction group reads the first variable), and the second transaction group writes The first variable; the first trading group writes the first variable, the second trading group writes the first variable; the first trading group reads the first variable and writes the first variable, and the second trading group writes the first variable; The first transaction group reads the first variable and writes the first variable, and the second transaction group reads the first variable and writes the first variable. Among them, if two transaction groups read the same variables, it can be considered that there is no conflicting transaction. Generally, in order to simplify the solution, the consensus module 13 can group multiple transactions according to the requirement that the same variables are not accessed between each transaction group.

Afterwards, the master node 1 initiates a consensus proposal to the consensus module (for example, the consensus module 22) of each slave node, where the consensus proposal includes the multiple transactions and the arrangement of the multiple transactions in the pre-execution transaction set. The order, the grouped results of the multiple transactions, and the pre-execution read and write set of each transaction. It can be understood that the master node can also broadcast the multiple transactions to the slave nodes, so that the multiple transactions may not be included in the consensus proposal.

After each node in the blockchain reaches consensus on the consensus proposal, the computing module 23 in the slave node can execute the multiple transactions in parallel according to groups. The computing module 23 of the slave node 2 includes multiple execution sub-modules (the figure schematically shows the execution sub-module 232, the execution sub-module 233 and the execution sub-module 234). During the process of executing a transaction, each execution sub-module can verify the correctness of the grouping based on the obtained execution read-write set of the transaction and the pre-execution read-write set of each transaction, thereby verifying whether the master node is doing evil.

However, there are currently some transactions in the blockchain, and the contracts called by these transactions may rely on data generated through consensus during the execution process. It can be understood that the data generated through consensus may not necessarily be the first through the current execution. Consensus generation of a block, for example, the consensus may be a consensus on a block before the first block (eg, a previous block). The data generated through consensus include, for example, the execution time of the current block, the hash of the latest block, the height of the current block, random numbers generated through consensus, etc., when the time gap between pre-execution and actual execution is large. , these data are uncertain during pre-execution, that is to say, the data cannot be obtained during pre-execution, so these transactions cannot be executed correctly during pre-execution. In the following, contracts that rely on data generated through consensus during execution are set as preset types of contracts. For example, these contract accounts can be recorded into the preset type contract list in the blockchain when the contract is deployed. , to indicate that the contract is a default type of contract.

The embodiment of this specification provides a transaction execution solution. When the master node determines that the transaction calls a preset type of contract when pre-executing a transaction, it terminates the pre-execution of the transaction, that is, it will not update based on the pre-execution result of the transaction. Pre-execution status, and record relevant information indicating that the transaction includes a call to a preset type contract to be sent to the slave node. After consensus is reached on the transaction in the blockchain, the masternode can determine how to execute the transaction based on the relevant information about the transaction. Specifically, if the transaction does not involve accounts other than the preset type of contract, the transaction will be executed. If the transaction involves accounts other than the preset type of contract, the transaction will not be carried out or will not be completed. The transaction is executed to ensure the consistency of the status of the accounts in the pre-execution state set except for the preset type of contracts and the status of the accounts in the state database except for the preset type of contracts. Similarly, after receiving the relevant information of the transaction, the slave node can similarly determine how to execute the transaction after verifying the relevant information. In this way, when pre-executing and executing transactions, the preset type of contract is isolated from other accounts, so that transactions involving other accounts can still be executed in parallel, thereby improving transaction execution efficiency.

The above process will be described in detail below with reference to the flowchart of the method for executing transactions shown in FIG. 4 . In Figure 4, only the process executed by master node 1 and slave node 2 is shown. It can be understood that other slave nodes in the blockchain execute the same process as slave node 2.

Referring to Figure 4, first, in step S401, the master node 1 pre-executes a transaction and determines whether the transaction includes a call to a preset type of contract.

Master node 1 can pre-execute the transaction immediately after receiving a transaction.

In one implementation, when a contract developer deploys the above-mentioned preset type of contract to the blockchain, the preset type of contract can be deployed by calling the system contract in the transaction, and the blockchain node executes the preset type of contract. When trading, the account of the newly deployed contract can be recorded in the default type contract list in the contract status of the system contract. Therefore, when pre-executing or executing a transaction, the blockchain node can determine whether the contract called in the transaction is a preset type contract based on the default type contract list in the contract status of the system contract.

In another implementation, a preset type interface list is preset in the contract state of the system contract in the blockchain, and the execution of the preset type interface relies on data generated by consensus. Therefore, when pre-executing or executing a transaction, the blockchain node can determine whether the interface in the contract called by the transaction is a preset type interface based on the preset type interface list in the contract status of the system contract, thereby determining the transaction call Whether the contract is a default type of contract.

Specifically, when pre-executing transaction Tx1, the pre-execution sub-module 111 or 112 in master node 1 first determines whether the transaction Tx1 calls a preset type of contract, that is, determines the contract account in the To field of the transaction Tx1 Whether the corresponding contract C1 is a default type of contract. In the case where a preset type contract list is stored in the blockchain as mentioned above, the pre-execution sub-module can read the preset type contract list and determine whether the contract C1 called by the transaction Tx1 is in the preset type contract list. , in the case where it is determined that the contract C1 called by the transaction Tx1 is in the default type contract list, it is determined that the transaction Tx1 includes a call to the default type contract. Similarly, in the case where a preset type interface list is stored in the blockchain, when the pre-execution sub-module executes the interface called in the contract C1, it can determine whether the interface is pre-set based on the preset type interface list. Set the type interface to determine whether contract C1 is a default type contract.

After determining that the transaction Tx1 includes a call to a preset type of contract, the master node 1 can execute step S403, terminate the pre-execution of the transaction Tx1, and discard the generated pre-execution read-write set of the transaction Tx1, that is, not based on the transaction Tx1. The pre-execution read-write set updates the pre-execution status set in Figure 3 and generates relevant information of transaction Tx1, which is used to indicate that transaction Tx1 includes a call to a preset type of contract. In one implementation, the master node 1 can record the identification of the transaction Tx1 in a separate transaction group, such as the group G1, as the relevant information of the transaction Tx1. The group G1 is used to store the information including the preset type. Transactions involving the invocation of contracts. In the following, transactions that include invocations of contracts of a preset type are collectively referred to as first-type transactions, and transactions that do not include invocations of contracts of a preset type are collectively referred to as second-type transactions. In this way, the first type of transaction and the second type of transaction are processed separately, and the variable status involved in the preset type of contract is not maintained in the pre-execution state set, thereby eliminating the need for pre-execution of the first type of transaction. The resulting inconsistency between pre-execution status and execution status.

When the pre-execution sub-module 111 or 112 in the master node 1 pre-executes the transaction Tx2, if it is determined that the contract C2 called by the transaction Tx2 is not a preset type of contract, the pre-execution sub-module will be executed during the process of pre-executing the transaction Tx2. When contract C2 calls contract C3, master node 1 also determines whether contract C3 is a preset type contract. If it is determined that contract C3 is a preset type contract, it is determined that transaction Tx2 includes a call to the preset type contract, that is, it is determined Transaction Tx2 includes cross-contract calls to preset type contracts. Therefore, transaction Tx2 is the first type of transaction.

After determining that the transaction Tx2 includes a call to a preset type of contract, the master node 1 can execute step S403, terminate the pre-execution of the transaction Tx2, and discard the generated pre-execution read-write set of the transaction Tx2, that is, not based on the transaction Tx2. The pre-execution read-write set updates the pre-execution status set in Figure 3 and generates relevant information of transaction Tx2. This relevant information is used to indicate that transaction Tx2 includes a call to a preset type of contract. In one implementation, the master node 1 can record the identification of the above-mentioned transaction Tx1 in the group G2, which is used to record transactions that directly call a preset type of contract, and record the identification of the transaction Tx2 in the group G3. , this group G3 is used to record transactions that call preset type contracts across contracts.

When the pre-execution sub-module 111 or 112 in the master node 1 pre-executes the transaction Tx3 and determines that the transaction Tx3 does not include a call to a preset type of contract according to the above process, it can determine that the transaction Tx3 is a second type of transaction, so that it can Step S405 is executed to complete the pre-execution of transaction Tx3 and generate the pre-execution read and write set of transaction Tx3. The master node 1 can record the identification of the transaction Tx3 into the group G4, and store the pre-execution read and write set of the transaction Tx3 accordingly. The group G4 is used to record transactions that do not include calls to contracts of preset types.

In one embodiment, the master node 1 may serially pre-execute multiple received transactions. When master node 1 is pre-executing a transaction, when the value of any variable is read from the pre-execution state set or the state database in Figure 3, the key of the read variable is recorded in the read cache of the transaction set in the memory. Value pairs, when writing the value of any variable, record the key-value pair of the written variable in the write cache of the transaction, and after the pre-execution is completed, the transaction can be obtained based on the read cache and write cache of the transaction pre-execution read-write set.

Specifically, when master node 1 reads a variable (such as variable A) during the pre-execution of transaction Tx3, master node 1 first determines whether the value of variable A is stored in the write cache of transaction Tx3. If the value of variable A is stored, value, the value of variable A can be read directly from the write cache. In the case where it is determined that the value of variable A is not stored in the write cache, it is determined whether the value of variable A is stored in the read cache of the transaction. If the value of variable A is stored, the value of variable A can be read from the read cache. . When it is determined that the value of variable A is not stored in the read cache, it is determined whether the value of variable A is stored in the pre-execution state set. If the value of variable A is stored, the value of variable A can be read from the pre-execution state set. . In the event that it is determined that the value of variable A is not stored in the pre-execution state set, the value of variable A may be read from the state database. That is to say, during the process of pre-execution of the transaction, the priority of the master node 1 to read the variables is: transaction write cache > transaction read cache > pre-execution status set > status database. This can ensure that the reads during the pre-execution process are The value of the variable taken is the latest value of the variable.

After pre-executing each transaction as described above, the master node 1 obtains the pre-execution read and write set of each second type transaction and the relevant information of each first type transaction. In one implementation, the pre-execution read and write set includes a read set and a write set, wherein the read set includes key-value pairs (key-values) of variables read when pre-executing the transaction, and the pre-execution write set includes a pre-execution write set. A key-value pair for the variable written when this transaction is executed. In another implementation manner, the read set of the pre-execution read and write set may include the version number of the variable read when the transaction is pre-executed, and the write set may include the version number of the variable written.

In the case of calling a contract in a transaction, the blockchain node may write to different variables based on the values of the variables read during the execution of the contract called by the transaction. For example, when the value of the read variable is 1, write 10 to variable a, when the value of the read variable is 2, write 20 to variable b, and so on. Therefore, for a transaction that calls a contract, the blockchain node must execute the transaction to determine the variables read and written by the transaction, thereby obtaining the read and write set of the transaction. To this end, the master node 1 obtains the pre-execution read and write set of each transaction by pre-executing each of the multiple transactions. The pre-execution process is basically the same as the process of executing the transaction. The difference is that the pre-execution of the pair of transactions is Execution is the execution process that takes place before consensus, and the execution of transactions is the execution process that takes place after consensus. And the pre-execution result of the pre-execution transaction is only used to update the pre-execution state set, not to update the world state, while the execution result of the execution transaction is used to update the world state.

In one implementation, referring to Figure 3, the master node 1 can pre-execute multiple transactions received at the same time in parallel through multiple pre-execution sub-modules. In order to prevent conflicts caused by multiple pre-execution sub-modules updating the pre-execution status set in parallel, the master node 1 performs pre-execution conflict detection on each transaction serially after pre-executing each transaction.

Specifically, when master node 1 performs pre-execution conflict detection on transaction Tx3, it first determines whether the pre-execution status set includes variables (for example, variable A) in the pre-execution read set of transaction Tx3. If not, it is similarly determined whether other variables in the pre-execution read set of transaction Tx3 are included in the pre-execution state set. If the pre-execution status set does not include all variables in the pre-execution read set of transaction Tx3, that is, the previous transaction that has been pre-execution conflict detected has not read or written the variables accessed by this transaction, then the pre-execution of transaction Tx3 can be determined There is no conflict between the read set and the pre-execution status set, that is, it is determined that the pre-execution of the transaction Tx3 does not conflict with the previous transactions that have undergone pre-execution conflict detection.

If master node 1 determines that the pre-execution status set includes the value of variable A, it determines whether the value of variable A in the pre-execution read set is consistent with the value of variable A in the pre-execution status set. If they are consistent, it means that the variable read by transaction Tx3 The value of A is the latest status of variable A during pre-execution. When master node 1 determines that the value read for each variable in the pre-execution read set of transaction Tx3 is the latest state in the pre-execution process, it can be determined that there is no conflict between the pre-execution read set and the pre-execution status set of transaction Tx3.

If master node 1 determines that the value of variable A in the pre-execution read set of transaction Tx3 is inconsistent with the value of variable A in the pre-execution state set, it means that the value of variable A read by transaction Tx3 is not the latest state in the pre-execution process, so , it can be determined that there is a conflict between the pre-execution read set and the pre-execution status set of transaction Tx3. In the case where it is determined that a conflict exists, the master node 1 can re-pre-execute the transaction Tx3.

When the master node 1 determines that there is no conflict between the pre-execution read set and the pre-execution status set of transaction Tx3, it updates the pre-execution status set and the pre-execution transaction set based on the pre-execution read and write set of transaction Tx3.

Specifically, for example, master node 1 updates the values of variables read or written in the pre-execution read-write set of transaction Tx3 to the pre-execution state set, so that the pre-execution state set records the latest values of each variable during the pre-execution process. state. At the same time, the master node 1 sequentially records the transaction Tx3 into the pre-execution transaction set, for example, records the transaction at the end position (ie, the last position) of the pre-execution transaction set. That is to say, the order of the transactions recorded in the pre-execution transaction set reflects the order of conflict detection of each transaction, and there is no conflict between each recorded transaction and the previously recorded transaction. Wherein, the pre-execution transaction set is, for example, in the form of a sequence table or a queue.

In step S407, master node 1 generates a consensus proposal.

In one implementation, the consensus proposal may include information related to multiple first-type transactions, the arrangement order of the multiple first-type transactions, pre-execution read-write sets of multiple second-type transactions, the Pre-execution sequence for multiple Type 2 transactions. The relevant information of the plurality of first type transactions is, for example, group G1, or may be group G2 and group G3. The arrangement order of the plurality of first-type transactions may, for example, be determined based on the reception order of each first-type transaction, for subsequent serial execution of at least part of the plurality of first-type transactions in accordance with the arrangement order. .

The consensus proposal may also include transaction bodies of the plurality of first type transactions and the plurality of second type transactions. It can be understood that the master node 1 can also broadcast the transaction bodies of the plurality of first type transactions and the plurality of second type transactions to each slave node in the form of broadcast, so that these may not be included in the consensus proposal. The transaction body of the transaction.

In another implementation manner, the master node 1 can use the consensus module 13 to perform multiple transactions based on the read variable key (key) and the written variable key included in the pre-execution read and write set of each second type transaction. The second type of transactions is grouped. As mentioned above, this grouping can prevent transactions in different transaction groups from accessing the same variables. This access includes read operations and write operations. When the grouping conditions are met, there will be no conflicting transactions between various transaction groups. Therefore, individual trading groups can be executed in parallel.

In this implementation, the consensus proposal may include relevant information of multiple first-type transactions, the arrangement order of the multiple first-type transactions, pre-execution read-write sets of multiple second-type transactions, the multiple The pre-execution sequence of the second type transactions, and the grouping results of multiple second type transactions.

In step S409, master node 1 sends the consensus proposal to at least some slave nodes (including slave node 2) to achieve consensus on the consensus proposal in the blockchain. For this consensus process, please refer to the description of Figure 2 above, and will not be described again here.

In step S411, the master node 1 executes the first type of transaction based on the relevant information of the first type of transaction.

As mentioned above, in the process of pre-executing the second type transaction, the master node 1 pre-executes the second type transaction based on the pre-execution state set, so that the state read by the second type transaction is the correct world state. The master node 1. Trust its own pre-execution results. Therefore, the pre-execution read-write set of the second type of transaction can be directly used as the execution read-write set of the second type of transaction. That is, there is no need to execute the second type of transaction and can be directly based on the second type of transaction. The transaction's pre-execution read-write set updates the state in the state database.

For the first type of transaction, since the master node 1 has not completed the pre-execution of the first type of transaction, it needs to execute the first type of transaction based on the relevant information of the first type of transaction.

In one implementation, when executing a transaction, the master node 1 obtains the identification of each first type transaction recorded in the group G1. The master node 1 can serially execute multiple first-type transactions in the group G1 in accordance with the order in the consensus proposal. A type of transaction, the group G1 includes, for example, the above-mentioned transaction Tx1 and transaction Tx2.

Specifically, when executing transaction Tx1, master node 1 first determines whether transaction Tx1 calls a preset type contract. After determining that transaction Tx1 calls a preset type contract, it determines whether transaction Tx1 also involves non-default type accounts. The preset type of accounts may include external accounts and contract accounts in addition to the preset type of contract list. In the case where it is determined that the transaction Tx1 does not involve an account of a non-default type, the master node 1 can continue to execute the transaction Tx1. Specifically, during the execution of contract C1 called by transaction Tx1, master node 1 obtains the data generated through consensus and executes contract C1 based on the data. The consensus can be on the first block that is currently unexecuted. consensus, or it can be a consensus on the blocks before the first block. After completing the execution of transaction Tx1, the master node obtains the execution read-write set of transaction Tx1, and can update the world state in the state database based on the execution read-write set of transaction Tx1. In this case, since transaction Tx1 only involves preset type contracts and not non-default type contracts, the execution of transaction Tx1 will not affect the world state of the variables in the pre-execution state set, and will not cause pre- The execution status is inconsistent with the execution status.

Assume that group G1 also includes transaction Tx4. When executing transaction Tx4, master node 1 determines that transaction Tx4 calls the default type of contract C4, and when executing contract C4, determines that contract C4 involves a non-default type of account, such as a contract C4 includes updates to the status of external accounts, or contract C4 calls a non-default type of contract, then master node 1 terminates the execution of transaction Tx4. In this case, since contract Tx4 involves both a default type of contract and a non-default type of account, if contract Tx4 is executed, it will affect the world state of the variables in the pre-execution state set (i.e., non-default type of account) , will cause inconsistency between the pre-execution state and the execution state. Therefore, the execution of transaction Tx4 is terminated to avoid such a situation.

For transaction Tx2 in group G1, when master node 1 executes transaction Tx2 and determines that transaction Tx2 does not call a contract of the preset type, it can directly determine that the contract called by transaction Tx2 must have called a contract of a non-preset type (i.e. Cross-contract call), that is, the transaction Tx2 involves both a preset type of contract and a non-default type of account. Refer to the statement above for the transaction Tx4, so the execution of the transaction Tx2 can be terminated.

In another implementation manner, when executing a transaction, the master node 1 obtains the identification of each first-type transaction recorded in the group G2 and the group G3. For each transaction in group G2, master node 1 can refer to the execution of the above-mentioned transaction Tx1 and transaction Tx4. For each transaction in group G3, since each transaction in group G3 involves a preset type of contract , also involves non-default type contracts, so master node 1 may not execute all transactions in group G3.

In step S413, after the consensus is completed, slave node 2 executes multiple second type transactions in parallel.

After the consensus is completed, in one implementation, the consensus proposal includes multiple pre-execution read and write sets of the second type of transactions, and the slave node 2 can perform multiple pre-execution read and write sets of the second type of transactions based on the multiple pre-execution read and write sets of the second type of transactions. The second type transactions are grouped so that the plurality of second type transactions can be executed in parallel based on the grouping results. Wherein, for each transaction group, slave node 2 serially executes multiple transactions in the transaction group in accordance with the pre-execution order of the multiple transactions in the transaction group.

In another implementation, the consensus proposal also includes grouping results of multiple second-type transactions, so that slave node 2 can directly execute multiple second-type transactions in parallel based on the grouping results.

After executing each second type transaction, slave node 2 obtains the execution read-write set of the transaction. The execution read-write set includes the execution read set and the execution write set, where the execution read set is read during the execution of the transaction. The status value of the variable. The execution write set is the status value of the variable written during the execution of the transaction. Slave node 2 can also compare whether the pre-execution read-write set and the execution read-write set of the transaction are consistent. If they are inconsistent, it can be determined that the master node is evil.

Alternatively, after the slave node 2 completes the execution of a group of transactions, it generates the group's execution read-write set based on the execution read-write set of each transaction in the group. The consensus proposal may also include the group's pre-execution read-write set. , thus, the slave node 2 can determine whether the master node is evil by comparing the pre-execution read-write set and the execution read-write set of the group.

In step S415, slave node 2 executes the first type of transaction and determines whether the first type of transaction calls a preset type contract.

Slave node 2 can execute the first type of transaction in parallel while executing the second type of transaction. The slave node 2 may serially execute multiple first-type transactions according to the order in which the multiple first-type transactions are arranged in the consensus proposal.

Specifically, in one implementation, the consensus proposal includes group G1, and group G1 includes transaction Tx1, transaction Tx2, and transaction Tx4. Similar to the master node executing the first type of transaction above, when the slave node 2 executes the transaction Tx1, it determines that the transaction Tx1 calls the default type of contract C1. Therefore, the slave node 2 executes step S421 to determine whether the transaction Tx1 involves non-preset type of account. After determining that the transaction Tx1 does not involve an account of a non-default type, the slave node 2 executes step S425 to complete the execution of the transaction Tx1.

When the slave node 2 executes the transaction Tx2, it is determined that the transaction Tx2 does not call the default type contract, but calls the non-default type contract C2. Therefore, the slave node 2 executes step S417 to determine whether the transaction Tx2 calls the default type across contracts. contract. Slave node 2 calls contract C3 during the execution of contract C2 and determines that contract C3 is a preset type of contract, so slave node 2 executes step S419 to terminate the execution of transaction Tx2. If slave node 2 determines in step S417 that transaction Tx2 does not call a preset type of contract across contracts, it means that transaction Tx2 does not include a call to a preset type of contract. Therefore, contract Tx2 should be a second type of transaction, not the first. Type transaction, master node 1 provides wrong transaction type information, therefore, slave node 2 can determine that the master node is evil.

When the slave node 2 executes the transaction Tx4, it is determined that the transaction Tx4 calls the default type of contract C4. Therefore, the slave node 2 executes step S421 to determine whether the transaction Tx4 involves an account other than the default type. After determining that the transaction Tx4 involves a non-preset type of account, the slave node 2 executes step S423 to terminate the execution of the transaction Tx4.

In another implementation, the consensus proposal includes group G2 and group G3. Group G2 includes, for example, transactions Tx1 and transaction Tx4, and group G3 includes, for example, transaction Tx2. Slave node 2 can execute transactions in group G2 and group G3 in parallel. When slave node 2 executes each transaction in group G2, it first executes step S415, then executes step S421, and then executes step S423 or step S425 to verify whether group G2 in the consensus proposal is correct. When executing each transaction in group G3, slave node 2 first performs step S415 and then performs step S417 to verify whether group G3 in the consensus proposal is correct.

Figure 5 is an architectural diagram of a master node in a blockchain in an embodiment of this specification, including:

The pre-execution unit 51 is configured to terminate the pre-execution of the first transaction when it is determined that the first transaction includes a call to a first contract of a preset type after starting the pre-execution of the first transaction, wherein, The execution of the above-mentioned preset types of contracts relies on the data generated by consensus;

Consensus unit 52, configured to generate a consensus proposal for the first block, the consensus proposal including the first information of the first transaction, the first information being used to indicate that the first transaction includes a pair of preset types. Invoke the contract; send the consensus proposal to at least some slave nodes of the blockchain, and conduct consensus on the consensus proposal with the at least some slave nodes.

Figure 6 is an architectural diagram of a slave node in a blockchain in an embodiment of this specification. The blockchain stores an account list of a preset type of contract. The execution of the preset type of contract depends on Data generated by consensus, the slave nodes include:

Consensus unit 61, configured to receive a consensus proposal of the first block from the master node of the blockchain, where the consensus proposal includes first information of the first transaction, where the first information is used to indicate the first The transaction includes a call to a first contract of a preset type; consensus on the consensus proposal with the master node and at least some other slave nodes;

Execution unit 62 is configured to, after consensus is reached, when executing the first transaction, determine that the first transaction includes a call to a preset type of contract, and the first transaction does not involve anything other than the list including The execution of the first transaction is completed when the account is outside the account.

In the 1990s, improvements in a technology could be clearly distinguished as hardware improvements (for example, improvements in circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements in method processes). However, with the development of technology, many improvements in today's method processes can be regarded as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement of a method flow cannot be implemented using hardware entity modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic functions are determined by the user programming the device. Designers can program themselves to "integrate" a digital system on a PLD, instead of asking chip manufacturers to design and produce dedicated integrated circuit chips. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing, and before compilation The original code must also be written in a specific programming language, which is called Hardware Description Language (HDL), and HDL is not just one kind, but there are many, 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., are currently the most commonly used The two are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that by simply logically programming the method flow using the above-mentioned hardware description languages and programming it into the integrated circuit, the hardware circuit that implements the logical method flow can be easily obtained.

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 (eg, software or firmware) executable by the (micro)processor. , logic gates, switches, Application Specific Integrated Circuit (ASIC), programmable logic controllers and embedded microcontrollers. Examples of controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, For Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic. Those skilled in the art also know that in addition to implementing the controller in the form of pure computer-readable program code, the controller can be completely programmed with logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded logic by logically programming the method steps. Microcontroller, etc. to achieve the same function. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the means for implementing various functions can be considered as structures within hardware components as well as software modules implementing the methods.

The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not rule out that with the development of computer technology in the future, the computer that implements the functions of the above 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, or a personal digital assistant. , media player, navigation device, email device, game console, tablet, wearable device, or a combination of any of these devices.

Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-inventive means. The sequence of steps listed in the embodiment is only one way of executing the sequence of many steps, and does not represent the only execution sequence. When the actual device or terminal product is executed, it can be executed sequentially or in parallel according to the methods shown in the embodiments or figures (such as a parallel processor or multi-thread processing environment, or even a distributed data processing environment). The terms "comprises," "comprises" or any other variation thereof are intended to cover a non-exclusive inclusion such that a process, method, product or apparatus including a list of elements includes not only those elements but also others not expressly listed elements, or also elements inherent to the process, method, product or equipment. Without further limitation, it does not exclude the presence of additional identical or equivalent elements in a process, method, product or apparatus including the stated elements. For example, if the words "first" and "second" are used to express names, they do not indicate any specific order.

For the convenience of description, when describing the above device, the functions are divided into various modules and described separately. Of course, when implementing one or more of this specification, the functions of each module can be implemented in the same or multiple software and/or hardware, or the modules that implement the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. . The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated. to another system, or some features can be ignored, or not implemented. On the other hand, the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.

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 process and/or block in the flowchart illustrations and/or block diagrams, and combinations of processes and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device produce a use A device for realizing the functions specified in one process or multiple processes of the flowchart and/or one block or multiple blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction means, the instructions The device implements the functions specified in a process or processes of the flowchart and/or a block or blocks of the block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device. Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.

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

Memory may include non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information. Information may be computer-readable instructions, data structures, modules of programs, 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), and 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 tape, magnetic tape storage, graphene storage or other magnetic storage devices or any other non-transmission medium can be used to store information that can be accessed by a computing device. As defined in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should be understood by those skilled in the art that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. Product form.

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

Each embodiment in this specification is described in a progressive manner. The same and similar parts between the various embodiments can be referred to each other. Each embodiment focuses on its differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple. For relevant details, please refer to the partial description of the method embodiment. In the description of this specification, reference to the terms "one embodiment," "some embodiments," "an example," "specific examples," or "some examples" or the like means that specific features are described in connection with the embodiment or example. , structures, materials or features are included in at least one embodiment or example of this specification. In this specification, the schematic expressions of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the specific features, structures, materials or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and combine different embodiments or examples and features of different embodiments or examples described in this specification unless they are inconsistent with each other.

The above descriptions are only examples of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. To those skilled in the art, various modifications and changes may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this specification shall be included in the scope of the claims.

Claims (17)

1. A method of executing transactions in a blockchain system. The blockchain system includes a master node and a plurality of slave nodes. The method is executed by the master node and includes:

   After starting the pre-execution of the first transaction, when it is determined that the first transaction includes a call to the first contract of the preset type, the pre-execution of the first transaction is terminated and the first information is recorded. Used to indicate that the first transaction includes a call to a preset type of contract, where the execution of the preset type of contract relies on data generated by consensus;

   Generate a consensus proposal for the first block, the consensus proposal including the first information;

   The consensus proposal is sent to at least some slave nodes, and the consensus proposal is reached with the at least some slave nodes.
2. The method of claim 1, wherein determining that the first transaction includes calling a contract of a preset type includes: determining that the first transaction calls a first contract of the preset type, and the first information Used to instruct the first transaction to call the contract of the preset type.
3. The method according to claim 2, wherein an account list of preset types of contracts is stored in the blockchain system, and the method further includes: after reaching a consensus, when executing the first transaction, after determining that the When the first transaction does not involve accounts other than the accounts included in the list, the execution of the first transaction is completed.
4. The method of claim 3, further comprising: when performing the first transaction, when it is determined that the first transaction involves an account other than the account included in the list, terminating the transaction of the first transaction. Execution of a transaction.
5. The method of claim 1, wherein determining that the first transaction includes a call to a first contract of a preset type includes: pre-executing the first transaction after determining that the first transaction calls a second contract, In the process of pre-executing the second contract, it is determined that the second contract calls the first contract, and the first information is used to indicate that the first transaction involves a non-default type of contract and the default type. A contract, wherein the first contract is a non-default type contract, and the method further includes: when executing the first block, not executing the first transaction according to the first information.
6. The method of claim 1, further comprising, after starting the pre-execution of the second transaction, completing the pre-execution of the second transaction when it is determined that the second transaction does not include a call to a preset type of contract. , obtain the pre-execution read-write set of the second transaction, record the pre-execution sequence of the second transaction, and the consensus proposal also includes multiple pre-execution read-write sets and pre-execution sequences of the second transaction.
7. The method according to claim 6, completing the pre-execution of the second transaction includes: pre-executing the second transaction based on the pre-execution status set, the method further includes: after pre-executing the second transaction, The second transaction performs the following processing: determine whether the pre-execution read set of the second transaction conflicts with the pre-execution status set, wherein, in the case where it is determined that there is no conflict, the pre-execution read set based on the second transaction The execution read-write set updates the pre-execution status set, and records the second transaction sequence into the pre-execution transaction set as the pre-execution sequence of the second transaction.
8. The method of claim 7, wherein determining whether a pre-execution read set of the second transaction conflicts with the pre-execution status set includes determining whether the pre-execution status set includes the second transaction variables in the pre-execution read set, in the case where it is determined that the pre-execution state set includes the variable, determine the value of the variable in the pre-execution state set and the value of the variable in the pre-execution read set Whether they are consistent, and if they are inconsistent, it is determined that there is a conflict between the pre-execution read set of the second transaction and the pre-execution status set.
9. The method of claim 1, wherein determining that the first transaction includes calling a first contract of a preset type includes determining in the first contract during pre-execution of the first transaction Call the preset interface, the execution of which depends on the data generated by consensus.
10. A method of executing transactions in a blockchain system. The blockchain system includes a master node and a slave node. An account list of a preset type of contract is stored in the blockchain system. The preset type of The execution of the contract relies on the data generated by consensus, and the method is executed by the slave node, including:

    A consensus proposal for the first block is received from the master node. The consensus proposal includes first information of the first transaction. The first information is used to indicate that the first transaction includes the first transaction of a preset type. Contract call;

    Consensus on the consensus proposal with the master node and at least some other slave nodes;

    After consensus is reached, when executing the first transaction, it is determined that the first transaction includes a call to a preset type of contract, and the first transaction does not involve accounts other than accounts included in the list. When, the execution of the first transaction is completed.
11. The method of claim 10 , further comprising: upon executing the first transaction, upon determining that the first transaction involves an account other than an account included in the list, terminating access to the first transaction. implement.
12. The method according to claim 11, the first information is used to indicate that: the first transaction includes a call to a first contract of a preset type, and the first transaction involves accounts other than those included in the list. For other accounts, the method further includes: when it is determined that the first information is correct, terminating the execution of the first transaction.
13. The method according to claim 10 or 11, the consensus proposal further includes a plurality of pre-execution read and write sets of second transactions, the method further includes: according to the pre-execution read and write sets of the plurality of second transactions The plurality of second transactions are grouped, and the plurality of second transactions are executed in parallel according to the grouping results.
14. A master node in a blockchain system, including:

    A pre-execution unit, configured to terminate the pre-execution of the first transaction when it is determined that the first transaction includes a call to a first contract of a preset type after starting the pre-execution of the first transaction, wherein, the The execution of preset types of contracts relies on data generated by consensus;

    A consensus unit, configured to generate a consensus proposal for the first block, the consensus proposal including the first information of the first transaction, the first information being used to indicate that the first transaction includes a preset type of Calling the contract; sending the consensus proposal to at least some slave nodes of the blockchain system, and reaching consensus on the consensus proposal with the at least some slave nodes.
15. A slave node in a blockchain system. The blockchain system stores an account list of a preset type of contract. The execution of the preset type of contract relies on data generated by consensus. The slave node includes :

    A consensus unit configured to receive a consensus proposal of the first block from the master node of the blockchain system, the consensus proposal including first information of the first transaction, and the first information is used to indicate the first The transaction includes a call to a first contract of a preset type; consensus on the consensus proposal with the master node and at least some other slave nodes;

    An execution unit, configured to, after reaching consensus, when executing the first transaction, determine that the first transaction includes a call to a preset type of contract, and the first transaction does not involve other than those included in the list. account other than the account, the execution of the first transaction is completed.
16. A blockchain system includes a master node and multiple slave nodes. An account list of a preset type of contract is stored in the blockchain system. The execution of the preset type of contract relies on data generated by consensus,

    The master node is configured to terminate the pre-execution of the first transaction when it is determined according to the list that the first transaction includes a call to the first contract of the preset type after starting to pre-execute the first transaction. Execute; generate a consensus proposal for the first block, the consensus proposal includes the first information of the first transaction, the first information is used to indicate that the first transaction includes a call to a preset type of contract ;Send the consensus proposal to at least some slave nodes, and conduct consensus on the consensus proposal with the at least some slave nodes;

    The slave node is used to receive the consensus proposal from the master node, and conduct consensus on the consensus proposal with the master node and at least some other slave nodes; after the consensus is reached, when executing the first transaction , when it is determined according to the list that the first transaction includes a call to a preset type of contract, and the first transaction does not involve accounts other than the accounts included in the list, complete the first transaction execution.
17. A computer-readable storage medium on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to perform the method described in any one of claims 1-13.

Images