WO2024001032A1 - 在区块链系统中执行交易的方法、区块链系统和节点 - Google Patents

在区块链系统中执行交易的方法、区块链系统和节点 Download PDF

Info

Publication number
WO2024001032A1
WO2024001032A1 PCT/CN2022/135476 CN2022135476W WO2024001032A1 WO 2024001032 A1 WO2024001032 A1 WO 2024001032A1 CN 2022135476 W CN2022135476 W CN 2022135476W WO 2024001032 A1 WO2024001032 A1 WO 2024001032A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
execution
contract
consensus
preset type
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2022/135476
Other languages
English (en)
French (fr)
Inventor
王江
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ant Blockchain Technology Shanghai Co Ltd
Original Assignee
Ant Blockchain Technology Shanghai Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ant Blockchain Technology Shanghai Co Ltd filed Critical Ant Blockchain Technology Shanghai Co Ltd
Publication of WO2024001032A1 publication Critical patent/WO2024001032A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1059—Inter-group management mechanisms, e.g. splitting, merging or interconnection of groups

Definitions

  • 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.
  • Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.
  • 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.
  • the master node 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.
  • 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:
  • 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;
  • 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;
  • the first transaction 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.
  • 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.
  • 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.
  • the processor executes the executable code, it implements the first aspect or the second aspect. method.
  • Figure 1 is a block chain architecture diagram in the embodiment of this specification.
  • FIG. 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.
  • Figure 1 shows the blockchain architecture diagram in the embodiment of this specification.
  • 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.
  • P2P Peer to Peer, point-to-point
  • These nodes store the entire ledger, which stores the status of all blocks and all accounts.
  • 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 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.
  • 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.
  • 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.
  • the nodes included in the blockchain can meet Byzantine Fault Tolerance (BFT) requirements.
  • BFT Byzantine Fault Tolerance
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • PW Proof of Work
  • POS Proof of Stake
  • DPOS Delegated Proof of Stake
  • PBFT Practical Byzantine Fault Tolerance
  • 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).
  • 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.
  • the complete consensus process can be divided into four stages: Request, Pre-Prepare, Prepare and Commit.
  • 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.
  • 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.
  • 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.
  • 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.
  • each consensus node signs the consensus proposal in the submission phase and sends it to each other consensus node.
  • 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.
  • 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.
  • the blockchain node can execute transactions in parallel through multiple processes in a single machine.
  • the blockchain node can be deployed in a server cluster and execute transactions in parallel through multiple servers.
  • 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.
  • 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.
  • 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.
  • FIG 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.
  • 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.
  • the pre-execution module 11 pre-executes the transaction and obtains the pre-execution read and write set of the transaction.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • the consensus module for example, the consensus module 22
  • 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).
  • 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.
  • the contracts called by these transactions may rely on data generated through consensus during the execution process.
  • 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.
  • contracts that rely on data generated through consensus during execution are set as preset types of contracts.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the preset type of contract 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • first-type transactions transactions that include invocations of contracts of a preset type
  • second-type transactions transactions that do not include invocations of contracts of a preset type
  • 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 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 are examples of the variable status involved in the preset type of contract.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the master node 1 may serially pre-execute multiple received transactions.
  • master node 1 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.
  • master node 1 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.
  • a variable such as variable A
  • the value of variable A can be read from 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.
  • the master node 1 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.
  • 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.
  • 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.
  • 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.
  • the master node 1 can pre-execute multiple transactions received at the same time in parallel through multiple pre-execution sub-modules.
  • the master node 1 performs pre-execution conflict detection on each transaction serially after pre-executing each transaction.
  • master node 1 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.
  • variables for example, variable A
  • 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.
  • master node 1 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the pre-execution transaction set is, for example, in the form of a sequence table or a queue.
  • step S407 master node 1 generates a consensus proposal.
  • 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 may also include transaction bodies of the plurality of first type transactions and the plurality of second type transactions.
  • 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.
  • 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.
  • 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.
  • slave node 2 For this consensus process, please refer to the description of Figure 2 above, and will not be described again here.
  • step S411 the master node 1 executes the first type of transaction based on the relevant information of the first type of 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.
  • the master node 1 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.
  • the master node 1 when executing a transaction, 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.
  • master node 1 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.
  • 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.
  • the master node 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.
  • group G1 also includes 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.
  • contract Tx4 involves both a default type of contract and a non-default type of account
  • contract Tx4 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.
  • 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.
  • a non-preset type i.e. Cross-contract call
  • the master node 1 when executing a transaction, 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.
  • step S413 after the consensus is completed, slave node 2 executes multiple second type transactions in parallel.
  • the consensus proposal includes multiple pre-execution read and write sets of the second type of transactions
  • 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.
  • 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.
  • 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.
  • slave node 2 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 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.
  • the slave node 2 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.
  • 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.
  • 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.
  • step S417 determines 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.
  • step S421 determines 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.
  • 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.
  • 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.
  • slave node 2 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.
  • FIG. 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.
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • 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.
  • 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.
  • the controller 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.
  • 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.
  • the functions are divided into various modules and described separately.
  • 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.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or integrated. to another system, or some features can be ignored, or not implemented.
  • 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.
  • 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.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile 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.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • 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.
  • PRAM phase change memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • RAM random access memory
  • read-only memory read-only memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • flash memory or other memory technology
  • compact disc read-only memory CD-ROM
  • DVD digital versatile disc
  • 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.
  • computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • 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.
  • computer-usable storage media including, but not limited to, disk storage, CD-ROM, optical storage, etc.
  • program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
  • program modules may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network.
  • program modules may be located in both local and remote computer storage media including storage devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

一种在区块链中执行交易的方法、区块链系统和节点，所述区块链包括主节点和多个从节点，所述方法由所述主节点执行，包括：在开始预执行第一交易之后，在确定所述第一交易包括对预设类型的第一合约的调用时，终止对所述第一交易的预执行，记录第一信息，所述第一信息用于指示所述第一交易中包括对预设类型的合约的调用，其中，所述预设类型的合约的执行依赖于共识生成的数据；生成第一区块的共识提议，所述共识提议中包括所述第一信息；将所述共识提议发送给至少部分从节点，与所述至少部分从节点进行对所述共识提议的共识。

Description

在区块链系统中执行交易的方法、区块链系统和节点
本申请要求于2022年6月29日提交中国国家知识产权局、申请号为202210753256.4、申请名称为“在区块链系统中执行交易的方法、区块链系统和节点”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本说明书实施例属于区块链技术领域，尤其涉及一种在区块链系统中执行交易的方法、区块链系统和节点。
背景技术
区块链(Blockchain)是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链系统中按照时间顺序将数据区块以顺序相连的方式组合成链式数据结构，并以密码学方式保证的不可篡改和不可伪造的分布式账本。由于区块链具有去中心化、信息不可篡改、自治性等特性，区块链也受到人们越来越多的重视和应用。在一种相关技术中，为了加快区块链中的交易执行速度，由主节点预执行多个交易，得到多个交易的变量访问信息，从而从节点可基于该变量访问信息并行执行多个交易，以加快交易执行速度。
发明内容
本发明的目的在于提供一种在区块链中执行交易的方案，可以提高交易执行速度。
本说明书第一方面提供一种在区块链系统中执行交易的方法，所述区块链系统包括主节点和多个从节点，所述方法由所述主节点执行，包括：
在开始预执行第一交易之后，在确定所述第一交易包括对预设类型的第一合约的调用时，终止对所述第一交易的预执行，记录第一信息，所述第一信息用于指示所述第一交易中包括对预设类型的合约的调用，其中，所述预设类型的合约的执行依赖于共识生成的数据；
生成第一区块的共识提议，所述共识提议中包括所述第一信息；
将所述共识提议发送给至少部分从节点，与所述至少部分从节点进行对所述共识提议的共识。
本说明书第二方面提供一种在区块链系统中执行交易的方法，所述区块链系统包括主节点和从节点，所述区块链系统中存储有预设类型的合约的账户列表，所述预设类型的合约的执行依赖于共识生成的数据，所述方法由所述从节点执行，包括：
从所述主节点接收第一区块的共识提议，所述共识提议中包括第一交易的第一信 息，所述第一信息用于指示所述第一交易中包括对预设类型的第一合约的调用；
与所述主节点和其他至少部分从节点进行对所述共识提议的共识；
在共识达成之后，在执行所述第一交易时，在确定所述第一交易包括对预设类型的合约的调用、且所述第一交易不涉及除所述列表包括的账户之外的账户时，完成对所述第一交易的执行。
其中，所述区块链系统中存储有预设类型的合约的账户列表包括，所述区块链系统中的多个节点中分别存储有预设类型的合约的账户列表。
本说明书第三方面提供一种区块链中的主节点，包括：
预执行单元，用于在开始预执行第一交易之后，在确定所述第一交易包括对预设类型的第一合约的调用时，终止对所述第一交易的预执行，其中，所述预设类型的合约的执行依赖于共识生成的数据；
共识单元，用于生成第一区块的共识提议，所述共识提议中包括所述第一交易的第一信息，所述第一信息用于指示所述第一交易中包括对预设类型的合约的调用；将所述共识提议发送给所述区块链的至少部分从节点，与所述至少部分从节点进行对所述共识提议的共识。
本说明书第四方面提供一种区块链中的从节点，所述区块链中存储有预设类型的合约的账户列表，所述预设类型的合约的执行依赖于共识生成的数据，所述从节点包括：
共识单元，用于从所述区块链的主节点接收第一区块的共识提议，所述共识提议中包括第一交易的第一信息，所述第一信息用于指示所述第一交易中包括对预设类型的第一合约的调用；与所述主节点和其他至少部分从节点进行对所述共识提议的共识；
执行单元，用于在共识达成之后，在执行所述第一交易时，在确定所述第一交易包括对预设类型的合约的调用、且所述第一交易不涉及除所述列表包括的账户之外的账户时，完成对所述第一交易的执行。
本说明书第五方面提供一种区块链，包括主节点和多个从节点，所述区块链中存储有预设类型的合约的账户列表，所述预设类型的合约的执行依赖于共识生成的数据，
所述主节点用于在开始预执行第一交易之后，在确定所述第一交易包括对所述预设类型的第一合约的调用时，终止对所述第一交易的预执行；生成第一区块的共识提议，所述共识提议中包括所述第一交易的第一信息，所述第一信息用于指示所述第一交易中包括对预设类型的合约的调用；将所述共识提议发送给至少部分从节点，与所述至少部分从节点进行对所述共识提议的共识；
所述从节点用于从所述主节点接收所述共识提议，与所述主节点和其他至少部分从节点进行对所述共识提议的共识；在共识达成之后，在执行所述第一交易时，在确定所述第一交易包括对预设类型的合约的调用、且所述第一交易不涉及除所述列表包括的账户之外的账户时，完成对所述第一交易的执行。
本说明书第六方面提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行第一方面或第二方面所述的方法。
本说明书第七方面提供一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现第一方面或第二方面所述的方法。
通过本说明书实施例提供的方案，将涉及预设类型的合约的交易与涉及非预设类型的账户的交易分隔开进行预执行或执行，避免了预执行状态与执行状态不一致的情况，又保证了交易执行的即时性和随机性，提高了交易执行效率。
附图说明
为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本说明书实施例中的区块链架构图；
图2为PBFT共识算法中的共识过程示意图；
图3示出了本说明书实施例中的区块链结构图；
图4为本说明书实施例中的执行交易的方法流程图；
图5为本说明书实施例中的一种区块链中的主节点的架构图；
图6为本说明书实施例中的一种区块链中的从节点的架构图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。
图1示出本说明书实施例中的区块链架构图。如图1中，区块链中例如包含主节点1、从节点2～从节点5共6个节点。节点之间的连线示意性的表示P2P(Peer to Peer，点对点)连接。这些节点上都存储全量的账本，即存储全部区块和全部账户的状态。其中，区块链中的每个节点通过执行相同的交易而产生区块链中的相同的状态，区块链中的每个节点存储相同的状态数据库。所不同的是，主节点1可负责从客户端接收交易，并向各个从节点发起共识提议，该共识提议中例如包括将要成块的区块(例如区块B1)中的多个交易及各个交易的提交顺序等信息。在区块链中的节点对共识提议共识成功之后，各个节点可根据共识提议中的提交顺序执行该多个交易，从而生成区 块B1。
可以理解，图1所示的区块链仅仅是示例性的，本说明书实施例不限于应用于图1所示的区块链，例如还可以应用于包括分片的区块链系统中。
另外，图1中虽然示出了区块链中包括6个节点，本说明书实施例不限于此，而是可以包括其他数目的节点。具体是，区块链中包含的节点可以满足拜占庭容错(Byzantine Fault Tolerance，BFT)要求。所述的拜占庭容错要求可以理解为在区块链内部可以存在拜占庭节点，而区块链对外不体现拜占庭行为。一般的，一些拜占庭容错算法中要求节点个数大于3f+1，f为拜占庭节点个数，例如实用拜占庭容错算法PBFT(Practical Byzantine Fault Tolerance)。
区块链领域中的交易可以指在区块链中执行并记录在区块链中的任务单元。交易中通常包括发送字段(From)、接收字段(To)和数据字段(Data)。其中，在交易为转账交易的情况中，From字段表示发起该交易(即发起对另一个账户的转账任务)的账户地址，To字段表示接收该交易(即接收转账)的账户地址，Data字段中包括转账金额。在交易调用区块链中的智能合约的情况中，From字段表示发起该交易的账户地址，To字段表示交易所调用的合约的账户地址，Data字段中包括调用合约中的函数名、及对该函数的传入参数等数据，以用于在交易执行时从区块链中获取该函数的代码并执行该函数的代码。
区块链中可提供智能合约的功能。区块链上的智能合约是在区块链系统上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。在区块链中调用智能合约，是发起一笔指向智能合约地址的交易，使得区块链中每个节点分布式地运行智能合约代码。需要说明的是，除了可以由用户创建智能合约，也可以在创世块中由系统设置智能合约。这类合约一般称为创世合约。一般的，创世合约中可以设置一些区块链的数据结构、参数、属性和方法。此外，具有系统管理员权限的账户可以创建系统级的合约，或者修改系统级的合约(简称为系统合约)。其中，所述系统合约可用于在区块链中增加不同业务的数据的数据结构。
在部署合约的场景中，例如，Bob将一个包含创建智能合约信息(即部署合约)的交易发送到如图1所示的区块链中，该交易的data字段包括待创建的合约的代码(如字节码或者机器码)，交易的to字段为空，以表示该交易用于部署合约。节点间通过共识机制达成一致后，确定合约的合约地址“0x6f8ae93…”，各个节点在状态数据库中添加与该智能合约的合约地址对应的合约账户，分配与该合约账户对应的状态存储，并将合约代码保存在该合约的状态存储中，从而合约创建成功。
在调用合约的场景中，例如，Bob将一个用于调用智能合约的交易发送到如图1所示的区块链中，该交易的from字段是交易发起方(即Bob)的账户的地址，to字段中的“0x6f8ae93…”代表了被调用的智能合约的地址，交易的data字段包括调用智能合约的方法和参数。在区块链中对该交易进行共识之后，区块链中的各个节点可分别 执行该交易，从而分别执行该合约，基于该合约的执行更新状态数据库。
区块链技术区别于传统技术的去中心化特点之一，就是在各个节点上进行记账，或者称为分布式记账，而不是传统的集中式记账。区块链系统要成为一个难以攻破的、公开的、不可篡改数据记录的去中心化诚实可信系统，需要在尽可能短的时间内做到分布式数据记录的安全、明确及不可逆。不同类型的区块链网络中，为了在各个记录账本的节点中保持账本的一致，通常采用共识算法来保证，即前述提到的共识机制。
例如，区块链节点之间可以实现区块粒度的共识机制，比如在节点(例如某个独特的节点)产生一个区块后，如果产生的这个区块得到其它节点的认可，其它节点记录相同的区块。再例如，区块链节点之间可以实现交易粒度的共识机制，比如在节点(例如某个独特的节点)获取一笔区块链交易后，如果这笔区块链交易得到其他节点的认可，认可该区块链交易的各个节点可以分别将该区块链交易添加至自身维护的最新区块中，并且最终能够确保各个节点产生相同的最新区块。共识机制是区块链节点就区块信息(或称区块数据)达成全网一致共识的机制，可以保证最新区块被准确添加至区块链。
当前主流的共识机制包括：工作量证明(Proof of Work，POW)、股权证明(Proof of Stake，POS)、委任权益证明(Delegated Proof of Stake，DPOS)、实用拜占庭容错(Practical Byzantine Fault Tolerance，PBFT)算法等。其中，在各种共识算法中，通常在预设数目的节点对待共识的数据(即共识提议)达成一致之后，从而确定对该共识提议的共识成功。具体是，在PBFT算法中，对于N≥3f+1个共识节点，可容忍f个恶意节点，也就是说，当N个共识节点中2f+1个节点达成一致时，可确定共识成功。
图2为PBFT共识算法中的共识过程示意图。
如图2所示，根据PBFT共识算法，可将完整的共识过程划分为请求(Request)、预备(Pre-Prepare)、准备(Prepare)和提交(Commit)四个阶段。假设一区块链中包括节点n1-节点n4四个共识节点，其中，节点n1例如为主节点，节点n2-节点n4例如为从节点，根据PBFT算法，在节点n1-节点n4中可容忍f＝1个恶意节点。
具体是，在请求阶段，区块链的用户可通过其用户设备向节点n1发送请求，该请求例如为区块链交易的形式。节点n1可以从一个或多个用户设备接收到多个交易，并将接收到的交易存储在交易队列中。在预备阶段，节点n1可以从交易队列中取出属于一个区块的多个交易，并针对该多个交易生成共识提议，将该共识提议及节点n1对该共识提议的签名广播给其他共识节点(即节点n2-节点n4)，以使共识节点继续对该区块进行共识，该共识提议中例如可包括该多个交易的交易体和该多个交易的执行顺序等信息。
在准备阶段，各个从节点可对共识提议进行签名并发送给其他各个节点。假设节点n4为恶意节点，节点n1、节点n2和节点n3在分别接收到2f＝2个其他共识节点的对共识提议的签名之后，可确定准备阶段完成，可进入提交阶段。例如，如图2中所 示，节点n1在接收到节点n2和节点n3的签名之后，验证节点n2和节点n3的签名都是正确的对共识提议的签名，则确定准备阶段完成，节点n2在接收到节点n3的签名和预备阶段节点n1的签名并验证通过之后，确定准备阶段完成。
在提交阶段，各个共识节点对共识提议进行提交阶段的签名并发送给其他各个共识节点，各个共识节点在接收到2f＝2个其他共识节点的提交阶段的签名之后，可确定提交阶段完成，共识成功。例如，节点n1在接收到节点n2和节点n3的提交阶段的签名并验证之后，确定提交阶段完成，从而，节点n1可根据执行该多个交易得到的执行结果更新世界状态，生成并存储包括该多个交易的区块(例如区块B1)，并将多个交易的执行结果返回给用户设备。类似地，节点n2和节点n3在确定提交阶段完成之后，执行该多个交易，生成并存储区块B1，并根据多个交易的执行结果更新世界状态。
通过上述过程，实现了节点n1、节点n2和节点n3的存储一致性。也就是说，节点n1-节点n4在存在一个恶意节点的情况下仍可以实现对共识提议的共识成功，完成对区块的执行。
在相关技术中，为了提高区块链中的每秒执行交易(TPS)指标，需要加快交易的执行速度。为此，区块链节点中可通过并行执行交易来加快交易的执行速度。在一种实施方式中，区块链节点可通过单机中的多个进程并行执行交易，在另一种实施方式中，区块链节点可部署在服务器集群中，通过多台服务器并行执行交易。通常，对于转账交易，区块链节点首先根据交易访问的账户将多个交易划分为多个交易组，各个交易组之间不访问相同的账户，从而可并行执行各个交易组。然而，当交易中调用智能合约时，在执行该交易之前不能预知该交易中访问的变量，从而无法对多个交易进行有效的分组，也就无法对并行执行交易。
在一种相关技术中，在包括主节点和多个从节点的区块链中，可以由主节点预执行多个交易，得到多个交易各自的预执行读写集，并根据该预执行读写集将多个交易分为多个组，从而各个从节点可按照多个组并行执行多个交易。
图3示出了本说明书实施例提供的区块链的主节点1和从节点(例如从节点2)的结构图。如图3所示，主节点1中包括预执行模块11、冲突检测模块12和共识模块13，从节点2中包括共识模块22和计算模块23。主节点1例如可以与客户端连接，从而可以从客户端接收到多个交易。主节点1在接收到每个交易之后，预执行模块11预执行该交易，得到该交易的预执行读写集。其中，预执行读写集包括预执行读集和预执行写集，预执行读集具体可以为在预执行交易的过程中生成的读取的变量的键值对，预执行写集具体可以为在预执行交易的过程中生成的写入的变量的键值对。主节点1中可维护预执行状态集，预执行模块11在预执行交易时，可从预执行状态集或者状态数据库中读取变量的状态值。预执行模块11在预执行交易之后，可根据交易的预执行读写集更新预执行状态集。
如图3中所示，预执行模块11中可包括多个预执行子模块，例如预执行子模块 111和预执行子模块112，这两个预执行子模块可并行预执行交易。冲突检测模块12中包括预执行状态集和预执行交易集合，其中，主节点1例如在内存中存储所述预执行状态集和预执行交易集合，以供冲突检测模块12使用。冲突检测模块12串行地对各个交易进行预执行冲突检测。具体是，冲突检测模块12检测该交易的预执行读集与已经预执行的交易的写集是否存在冲突，如果该交易的预执行读集中的某个变量的值与预执行状态集中的该变量的值不同，则可确定存在冲突。如果确定不存在冲突，冲突检测模块12将该交易的预执行写集中的状态更新到预执行状态集中，并将该交易顺序排列到预执行交易集合中。
共识模块13从预执行交易集合中获取在先记录的顺序排列的多个交易，共识模块13可根据该多个交易各自的预执行读写集对该多个交易进行分组，得到多个交易组，各个交易组之间不存在冲突交易。其中，两个交易组之间存在冲突交易的情况通常包括如下种情况：第一交易组中的交易读取第一变量(即第一交易组读取第一变量)，第二交易组写入第一变量；第一交易组写入第一变量，第二交易组写入第一变量；第一交易组读取第一变量且写入第一变量，第二交易组写入第一变量；第一交易组读取第一变量且写入第一变量，第二交易组读取第一变量且写入第一变量。其中，如果两个交易组读取相同的变量也可以认为是不存在冲突交易。通常，为了简化方案，共识模块13可按照各个交易组之间不访问相同的变量的要求来对多个交易进行分组。
之后，主节点1向各个从节点的共识模块(例如共识模块22)发起共识提议，其中，该共识提议中包括所述多个交易、所述多个交易在所述预执行交易集合中的排列顺序、所述多个交易的分组结果、以及各个交易的预执行读写集。可以理解，主节点也可以向从节点广播所述多个交易，从而在共识提议中可以不包括所述多个交易。
在区块链中各个节点对共识提议达成共识之后，从节点中的计算模块23可以按照分组并行执行所述多个交易。其中，从节点2的计算模块23中包括多个执行子模块(图中示意示出执行子模块232、执行子模块233和执行子模块234)。每个执行子模块在执行交易的过程中可以根据得到的交易的执行读写集和各个交易的预执行读写集来验证分组的正确性，从而验证主节点是否作恶。
然而，目前在区块链中存在部分交易，该部分交易调用的合约可能在执行过程中依赖通过共识生成的数据，可以理解，所述通过共识生成的数据不一定是通过对当前执行的第一区块的共识生成，例如，该共识可以为例如对第一区块的之前的区块(例如前一个区块)的共识。所述通过共识生成的数据例如包括当前区块的执行时间、当前最新区块的哈希、当前区块高度、通过共识生成的随机数等情况，当预执行和真实执行的时间差距较大时，这些数据在预执行时均为不确定的，也就是说，在预执行时不能获取到该数据，从而在预执行时不能正确地执行这些交易。下文中，将在执行过程中依赖通过共识生成的数据的合约设置为预设类型的合约，例如，可在合约部署时，就将这些合约账户记录到区块链中的预设类型合约列表中，以指示该合约为预设类型 的合约。
本说明书实施例提供一种交易执行方案，主节点在预执行交易时在确定该交易调用预设类型的合约时，终止对该交易的预执行，也即不会基于该交易的预执行结果更新预执行状态，并记录用于指示该交易中包括对预设类型合约的调用的相关信息，以发送给从节点。在区块链中对该交易共识之后，主节点可根据该交易的相关信息确定如何执行该交易。具体是，如果该交易中不涉及对除预设类型的合约之外的账户，则执行该交易，如果该交易中涉及对除预设类型的合约之外的账户，则不进行或者不完成对该交易的执行，以保证预执行状态集中的除预设类型的合约之外的账户的状态与状态数据库中的除预设类型的合约之外的账户的状态的一致性。类似地，从节点在接收到该交易的相关信息之后，可以在验证该相关信息之后，类似地确定如何执行该交易。通过这样，在预执行和执行交易时，将预设类型的合约与其他账户隔离开，使得仍然可以并行执行涉及其他账户的交易，从而提高了交易执行效率。
下文将参考图4所示的执行交易的方法流程图详细描述上述过程。在图4中仅示出了主节点1和从节点2执行的流程，可以理解，区块链中的其他从节点与从节点2执行相同的流程。
参考图4，首先，在步骤S401，主节点1预执行交易，确定交易是否包括对预设类型的合约的调用。
主节点1可以在每接收到一个交易之后，就立即对该交易进行预执行。
在一种实施方式中，当合约开发者向区块链中部署上述预设类型的合约时，可通过在交易中调用系统合约进行对该预设类型合约的部署，区块链节点在执行该交易时，可在系统合约的合约状态中的预设类型合约列表中记录该新部署的合约的账户。从而，区块链节点在预执行或执行交易时，可基于系统合约的合约状态中的预设类型合约列表，来确定该交易中调用的合约是否为预设类型合约。
在另一种实施方式中，区块链中的系统合约的合约状态中预设了预设类型接口列表，所述预设类型接口的执行依赖于共识生成的数据。从而，区块链节点在预执行或执行交易时，可基于系统合约的合约状态中的预设类型接口列表，来确定该交易调用的合约中的接口是否为预设类型接口，从而确定交易调用的合约是否为预设类型的合约。
具体是，主节点1中的预执行子模块111或112在预执行交易Tx1时，首先确定该交易Tx1是否调用了预设类型的合约，也即，确定该交易Tx1的To字段中的合约账户对应的合约C1是否为预设类型的合约。在区块链中如上文所述存储有预设类型合约列表的情况中，预执行子模块可读取该预设类型合约列表，确定该交易Tx1调用的合约C1是否在该预设类型合约列表中，在确定交易Tx1调用的合约C1在预设类型合约列表中的情况中，则确定该交易Tx1包括对预设类型合约的调用。类似地，在区块链中存储有预设类型接口列表的情况中，预执行子模块在执行到所述合约C1中调用的接 口时，可根据该预设类型接口列表确定该接口是否为预设类型接口，从而确定合约C1是否为预设类型合约。
在确定交易Tx1包括对预设类型的合约的调用之后，主节点1可执行步骤S403，终止对交易Tx1的预执行，丢弃已经生成的交易Tx1的预执行读写集，即不基于交易Tx1的预执行读写集更新图3中的预执行状态集，生成交易Tx1的相关信息，该相关信息用于指示交易Tx1包括对预设类型的合约的调用。在一种实施方式中，主节点1可以将交易Tx1的标识记录到一个单独的交易组中，例如组G1中，作为交易Tx1的相关信息，该组G1中用于存放包括对预设类型的合约的调用的交易，下文中将包括对预设类型的合约的调用的交易统称为第一类型交易，将不包括对预设类型的合约的调用的交易统称为第二类型交易。通过这样，将第一类型交易与第二类型交易分隔开进行处理，并且在预执行状态集中不维护预设类型的合约涉及的变量状态，从而免去了由于对第一类型交易的预执行导致的预执行状态与执行状态的不一致。
主节点1中的预执行子模块111或112在预执行交易Tx2时，如果确定该交易Tx2调用的合约C2不是预设类型的合约，预执行子模块在预执行该交易Tx2的过程中当执行合约C2调用的合约C3时，主节点1还确定合约C3是否为预设类型的合约，如果确定合约C3为预设类型合约，则确定交易Tx2中包括对预设类型的合约的调用，即确定交易Tx2中包括对预设类型合约的跨合约调用，因此，交易Tx2为第一类型的交易。
在确定交易Tx2包括对预设类型的合约的调用之后，主节点1可执行步骤S403，终止对交易Tx2的预执行，丢弃已经生成的交易Tx2的预执行读写集，即不基于交易Tx2的预执行读写集更新图3中的预执行状态集，生成交易Tx2的相关信息，该相关信息用于指示交易Tx2包括对预设类型的合约的调用。在一种实施方式中，主节点1可以将上述交易Tx1的标识记录在组G2中，该组G2中用于记录直接调用预设类型的合约的交易，将交易Tx2的标识记录到组G3中，该组G3用于记录跨合约调用预设类型合约的交易。
主节点1中的预执行子模块111或112在预执行交易Tx3时，在按照上述过程确定交易Tx3不包括对预设类型的合约的调用时，可确定交易Tx3为第二类型交易，从而可执行步骤S405，完成对交易Tx3的预执行，生成交易Tx3的预执行读写集。主节点1可将交易Tx3的标识记录到组G4中，并相应地存储交易Tx3的预执行读写集，该组G4用于记录不包括对预设类型的合约的调用的交易。
在一种实施方式中，主节点1可串行预执行接收的多个交易。主节点1在预执行交易时，当从图3中的预执行状态集或者状态数据库中读取任意变量的值时，在内存中设置的该交易的读缓存中记录该读取的变量的键值对，在写入任意变量的值时，在该交易的写缓存中记录该写入的变量的键值对，并在预执行结束之后，可基于该交易的读缓存和写缓存获取该交易的预执行读写集。
具体是，主节点1在预执行交易Tx3的过程中读取变量(例如变量A)时，主节 点1首先确定该交易Tx3的写缓存中是否存储有变量A的值，如果存储了变量A的值，可直接从写缓存中读取变量A的值。在确定所述写缓存中未存储变量A的值情况中，确定该交易的读缓存中是否存储有变量A的值，如果存储了变量A的值，可从读缓存中读取变量A的值。在确定所述读缓存中未存储变量A的值情况中，确定所述预执行状态集中是否存储变量A的值，如果存储了变量A的值，可从预执行状态集中读取变量A的值。在确定预执行状态集中未存储变量A的值的情况中，可从状态数据库读取变量A的值。也就是说，主节点1在预执行交易的过程中，读取变量的优先度为：交易的写缓存>交易的读缓存>预执行状态集>状态数据库，通过如此可保证预执行过程中读取的变量的值为该变量最新的值。
主节点1在如上所述预执行每个交易之后，得到各个第二类型交易的预执行读写集，各个第一类型交易的相关信息。在一种实施方式中，该预执行读写集中包括读集和写集，其中，读集包括预执行该交易时读取的变量的键值对(key-value)，预执行写集包括预执行该交易时写入的变量的键值对。在另一种实施方式中，该预执行读写集的读集中可包括预执行该交易时读取的变量的版本号，写集中可包括写入的变量的版本号。
在交易中调用合约的情况中，区块链节点在执行该交易调用的合约的过程中，有可能根据读取的变量的值来对不同的变量进行写入。例如，当读取的变量的值为1时，对变量a写入10，当读取的变量的值为2时，对变量b写入20等等。因此，对于调用合约的交易，区块链节点必须通过执行该交易，才能确定该交易读取的变量和写入的变量，从而得到该交易的读写集。为此，主节点1通过预执行多个交易中的每个交易，得到每个交易的预执行读写集，该预执行的过程与执行交易的过程基本相同，不同在于，该对交易的预执行是在共识之前进行的执行过程，而对交易的执行是在共识之后进行的执行过程。并且预执行交易的预执行结果仅用于更新预执行状态集，而不用于更新世界状态，而执行交易的执行结果用于更新世界状态。
在一种实施方式中，参考图3，主节点1可通过多个预执行子模块对同时接收的多个交易并行进行预执行。为了防止多个预执行子模块并行更新预执行状态集导致冲突，主节点1在预执行各个交易之后，串行地对各个交易进行预执行冲突检测。
具体是，主节点1在对交易Tx3进行预执行冲突检测时，首先确定预执行状态集中是否包括交易Tx3的预执行读集中的变量(例如变量A)。如果没有，再类似地确定预执行状态集中是否包括交易Tx3的预执行读集中的其他变量。如果预执行状态集中不包括交易Tx3的预执行读集中的全部变量，也就是说，之前经过预执行冲突检测的交易还未对该交易访问的变量进行读写，则可确定交易Tx3的预执行读集与预执行状态集没有冲突，也即确定该交易Tx3的预执行与之前经过预执行冲突检测的交易不存在冲突。
如果主节点1确定预执行状态集中包括变量A的值，则确定预执行读集中的变量 A的值与预执行状态集中的变量A的值是否一致，如果一致，说明该交易Tx3读取的变量A的值为预执行过程中变量A的最新状态。当主节点1对于交易Tx3预执行读集中的每个变量都确定所读取的值为预执行过程中的最新状态之后，可确定该交易Tx3的预执行读集与预执行状态集不存在冲突。
如果主节点1确定交易Tx3的预执行读集中的变量A的值与预执行状态集中的变量A的值不一致，说明该交易Tx3读取的变量A的值不是预执行过程中的最新状态，因此，可确定交易Tx3的预执行读集与预执行状态集存在冲突。在确定存在冲突的情况中，主节点1可对该交易Tx3重新进行预执行。
主节点1在确定交易Tx3的预执行读集与预执行状态集不存在冲突的情况中，基于该交易Tx3的预执行读写集更新预执行状态集和预执行交易集合。
具体是，例如，主节点1将交易Tx3的预执行读写集中读取或者写入的变量的值更新到预执行状态集中，从而使得该预执行状态集中记录各个变量在预执行过程中的最新状态。同时，主节点1将该交易Tx3顺序记录到预执行交易集合中，例如将该交易记录到预执行交易集合的末尾位置(即最后一个位置)。也就是说，预执行交易集合中记录的交易的顺序体现了各个交易的冲突检测的顺序，并且所记录的各个交易与之前记录的交易不存在冲突。其中，所述预执行交易集合例如为顺序表的形式，或者为队列的形式。
在步骤S407，主节点1生成共识提议。
在一种实施方式中，该共识提议中可包括多个第一类型交易的相关信息、所述多个第一类型交易的排列顺序、多个第二类型交易的预执行读写集、所述多个第二类型交易的预执行顺序。所述多个第一类型交易的相关信息例如为组G1，或者可以为组G2和组G3。所述多个第一类型交易的排列顺序例如可基于各个第一类型交易的接收顺序确定，以用于后续按照该排列顺序进行对该多个第一类型交易中的至少部分交易的串行执行。
所述共识提议中还可以包括所述多个第一类型交易和所述多个第二类型交易的交易体。可以理解，所述主节点1也可以通过广播的形式将所述多个第一类型交易和所述多个第二类型交易的交易体广播给各个从节点，从而在共识提议中可以不包括这些交易的交易体。
在另一种实施方式中，主节点1中可通过共识模块13基于各个第二类型交易的预执行读写集中包括的读取的变量的键(key)和写入的变量key，对多个第二类型交易进行分组。如上文所述，该分组可使得不同交易组中的交易不访问相同的变量，该访问包括读操作和写操作，在达到该分组条件的情况下，各个交易组之间不会存在冲突交易，因此，各个交易组可以并行执行。
在该实施方式下，共识提议中可包括多个第一类型交易的相关信息、所述多个第一类型交易的排列顺序、多个第二类型交易的预执行读写集、所述多个第二类型交易 的预执行顺序、以及多个第二类型交易的分组结果。
在步骤S409，主节点1将共识提议发送给至少部分从节点(包括从节点2)，以在区块链中进行对该共识提议的共识。该共识过程可参考上文对图2的描述，在此不再赘述。
在步骤S411，主节点1根据第一类型交易的相关信息，进行对第一类型交易的执行。
如上文所述，主节点1在预执行第二类型交易的过程中，通过基于预执行状态集预执行第二类型交易，使得第二类型交易读取的状态即为正确的世界状态，主节点1信任自身的预执行结果，因此，可以直接将第二类型交易的预执行读写集用作为第二类型交易的执行读写集，即不需要执行第二类型交易，可直接基于第二类型交易的预执行读写集更新状态数据库中的状态。
对于第一类型的交易，由于主节点1未完成对第一类型交易的预执行，因此需要根据第一类型交易的相关信息进行对第一类型交易的执行。
在一种实施方式中，主节点1在执行交易时，获取在组G1中记录各个第一类型交易的标识，主节点1可按照共识提议中的排列顺序串行执行组G1中的多个第一类型交易，组G1中例如包括上述交易Tx1和交易Tx2。
具体是，主节点1在执行交易Tx1时，首先确定交易Tx1是否调用预设类型合约，在确定交易Tx1调用预设类型合约之后，确定交易Tx1是否还涉及非预设类型的账户，所述非预设类型账户可以包括除所述预设类型合约列表之外的外部账户和合约账户。在确定交易Tx1不涉及非预设类型的账户的情况中，主节点1可继续进行对交易Tx1的执行。具体是，在执行交易Tx1调用的合约C1的过程中，主节点1获取通过共识生成的数据，并基于该数据执行合约C1，其中，该共识可以是对当前未执行完成的第一区块进行的共识，或者可以为对第一区块之前的区块进行的共识。主节点在完成对交易Tx1的执行之后，得到交易Tx1的执行读写集，并可基于交易Tx1的执行读写集更新状态数据库中的世界状态。在该情况中，由于交易Tx1中仅涉及预设类型合约，而不涉及非预设类型的合约，交易Tx1的执行不会影响到预执行状态集中的变量的世界状态，也就不会造成预执行状态与执行状态的不一致。
假设组G1中还包括交易Tx4，主节点1在执行交易Tx4时，确定交易Tx4调用预设类型的合约C4,并且在执行合约C4时，确定合约C4中涉及非预设类型的账户，例如合约C4中包括对外部账户的状态的更新，或者合约C4中调用非预设类型的合约，则主节点1终止对交易Tx4的执行。在该情况中，由于合约Tx4既涉及预设类型的合约，又涉及非预设类型的账户，如果执行合约Tx4将影响到预执行状态集中的变量(即非预设类型的账户)的世界状态，会造成预执行状态与执行状态的不一致，因此，终止对交易Tx4的执行，以避免这样的情况出现。
对于组G1中的交易Tx2，主节点1在执行交易Tx2时，在确定交易Tx2未调用预设类型的合约时，可直接确定交易Tx2调用的合约中必然调用了非预设类型的合约(即跨合 约调用)，即，交易Tx2中既涉及预设类型的合约，又涉及非预设类型的账户，参考上文对交易Tx4的陈述，因此可终止对该交易Tx2的执行。
在另一种实施方式中，主节点1在执行交易时，获取在组G2和组G3中记录的各个第一类型交易的标识。对于组G2中的各个交易，主节点1可参考上文对上述交易Tx1和交易Tx4的执行而执行，对于组G3中的各个交易，由于组G3中的每个交易即涉及预设类型的合约，也涉及非预设类型的合约，因此主节点1可不执行组G3中的全部交易。
在步骤S413，从节点2在共识完成之后，并行执行多个第二类型交易。
在共识完成之后，在一种实施方式中，共识提议中包括多个第二类型交易的预执行读写集，从节点2可基于多个第二类型交易的预执行读写集对多个第二类型交易分组，从而可基于该分组结果并行执行该多个第二类型交易。其中，对于每个交易组，从节点2按照该交易组中的多个交易的预执行顺序串行执行该交易组中的多个交易。
在另一种实施方式中，共识提议中还包括对多个第二类型交易的分组结果，从而从节点2可直接基于该分组结果并行执行多个第二类型交易。
从节点2在执行每个第二类型交易之后，得到该交易的执行读写集，该执行读写集包括执行读集和执行写集，其中，执行读集为在执行交易过程中读取的变量的状态值，执行写集为执行交易的过程中写入的变量的状态值。从节点2还可以比较该交易的预执行读写集与执行读写集是否一致，如果不一致，则可以确定主节点作恶。
或者，从节点2在执行完成一个组的交易之后，基于该组中各个交易的执行读写集生成该组的执行读写集，所述共识提议中还可以包括该组的预执行读写集，从而，从节点2可通过比较该组的预执行读写集和执行读写集来确定主节点是否作恶。
在步骤S415，从节点2执行第一类型的交易，确定第一类型交易是否调用预设类型合约。
从节点2可以在执行第二类型交易的同时，并行地执行第一类型交易。从节点2可根据共识提议中的多个第一类型交易的排列顺序串行执行多个第一类型交易。
具体是，在一种实施方式中，共识提议中包括组G1，组G1中包括交易Tx1、交易Tx2和交易Tx4。与上文主节点执行第一类型交易类似地，从节点2在执行交易Tx1时，确定交易Tx1调用预设类型的合约C1，因此，从节点2执行步骤S421，确定交易Tx1是否涉及非预设类型的账户。在确定交易Tx1未涉及非预设类型的账户之后，从节点2执行步骤S425，完成对交易Tx1的执行。
从节点2在执行交易Tx2时，确定交易Tx2未调用预设类型的合约，而是调用非预设类型的合约C2，因此，从节点2执行步骤S417，确定交易Tx2是否跨合约调用预设类型合约。从节点2在执行合约C2的过程中调用合约C3，并确定合约C3为预设类型的合约，从而从节点2执行步骤S419,终止对交易Tx2的执行。如果从节点2在步骤S417确定交易Tx2未跨合约调用预设类型的合约，则说明交易Tx2中不包括对预设类型合约的调用，因此，合约Tx2应为第二类型交易，而不是第一类型交易，主节点1提供了错误的交易 类型信息，因此，从节点2可确定主节点作恶。
从节点2在执行交易Tx4时，确定交易Tx4调用预设类型的合约C4，因此，从节点2执行步骤S421，确定交易Tx4是否涉及非预设类型的账户。在确定交易Tx4涉及非预设类型的账户之后，从节点2执行步骤S423，终止对交易Tx4的执行。
在另一种实施方式中，共识提议中包括组G2和组G3，组G2中例如包括交易Tx1和交易Tx4，组G3中例如包括交易Tx2。从节点2可并行地执行组G2和组G3中的交易。其中，从节点2在执行组G2中的每个交易时，首先执行步骤S415，然后执行步骤S421，然后执行步骤S423或者步骤S425，以验证共识提议中的组G2是否正确。从节点2在执行组G3中的每个交易时，首先执行步骤S415，然后执行步骤S417，以验证共识提议中的组G3是否正确。
图5为本说明书实施例中的一种区块链中的主节点的架构图，包括：
预执行单元51，用于在开始预执行第一交易之后，在确定所述第一交易包括对预设类型的第一合约的调用时，终止对所述第一交易的预执行，其中，所述预设类型的合约的执行依赖于共识生成的数据；
共识单元52，用于生成第一区块的共识提议，所述共识提议中包括所述第一交易的第一信息，所述第一信息用于指示所述第一交易中包括对预设类型的合约的调用；将所述共识提议发送给所述区块链的至少部分从节点，与所述至少部分从节点进行对所述共识提议的共识。
图6为本说明书实施例中的一种区块链中的从节点的架构图，所述区块链中存储有预设类型的合约的账户列表，所述预设类型的合约的执行依赖于共识生成的数据，所述从节点包括：
共识单元61，用于从所述区块链的主节点接收第一区块的共识提议，所述共识提议中包括第一交易的第一信息，所述第一信息用于指示所述第一交易中包括对预设类型的第一合约的调用；与所述主节点和其他至少部分从节点进行对所述共识提议的共识；
执行单元62，用于在共识达成之后，在执行所述第一交易时，在确定所述第一交易包括对预设类型的合约的调用、且所述第一交易不涉及除所述列表包括的账户之外的账户时，完成对所述第一交易的执行。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑 功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如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)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为服务器系统。当然，本申请不排除随着未来计算机技术的发展，实现上述实施例功能的计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
虽然本说明书一个或多个实施例提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执 行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。例如若使用到第一，第二等词语用来表示名称，而并不表示任何特定的顺序。
为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
本发明是参照根据本发明实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储、石墨烯存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
本领域技术人员应明白，本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本本说明书一个或多个实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
以上所述仅为本说明书一个或多个实施例的实施例而已，并不用于限制本本说明书一个或多个实施例。对于本领域技术人员来说，本说明书一个或多个实施例可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在权利要求范围之内。

Claims (17)

  1. 一种在区块链系统中执行交易的方法，所述区块链系统包括主节点和多个从节点，所述方法由所述主节点执行，包括：
    在开始预执行第一交易之后，在确定所述第一交易包括对预设类型的第一合约的调用时，终止对所述第一交易的预执行，记录第一信息，所述第一信息用于指示所述第一交易中包括对预设类型的合约的调用，其中，所述预设类型的合约的执行依赖于共识生成的数据；
    生成第一区块的共识提议，所述共识提议中包括所述第一信息；
    将所述共识提议发送给至少部分从节点，与所述至少部分从节点进行对所述共识提议的共识。
  2. 根据权利要求1所述的方法，所述确定所述第一交易包括对预设类型的合约的调用包括：确定所述第一交易调用所述预设类型的第一合约，所述第一信息用于指示所述第一交易调用所述预设类型的合约。
  3. 根据权利要求2所述的方法，所述区块链系统中存储有预设类型的合约的账户列表，所述方法还包括：在共识达成之后，在执行所述第一交易时，在确定所述第一交易不涉及除所述列表包括的账户之外的账户时，完成对所述第一交易的执行。
  4. 根据权利要求3所述的方法，所述方法还包括：在执行所述第一交易时，在确定所述第一交易涉及除所述列表包括的账户之外的账户时，终止对所述第一交易的执行。
  5. 根据权利要求1所述的方法，所述确定所述第一交易包括对预设类型的第一合约的调用包括：在确定所述第一交易调用第二合约之后预执行所述第一交易，在预执行所述第二合约的过程中确定所述第二合约调用所述第一合约，所述第一信息用于指示所述第一交易涉及非预设类型的合约和所述预设类型的合约，其中所述第一合约为非预设类型的合约，所述方法还包括：在执行所述第一区块时，根据所述第一信息不进行对所述第一交易的执行。
  6. 根据权利要求1所述的方法，还包括，在开始预执行第二交易之后，在确定所述第二交易不包括对预设类型的合约的调用时，完成对所述第二交易的预执行，得到所述第二交易的预执行读写集，记录所述第二交易的预执行顺序，所述共识提议中还包括多个所述第二交易的预执行读写集和预执行顺序。
  7. 根据权利要求6所述的方法，完成对所述第二交易的预执行包括：基于预执行状态集预执行所述第二交易，所述方法还包括：在预执行完第二交易之后，对所述第二交易进行如下处理：确定所述第二交易的预执行读集是否与所述预执行状态集存在冲突，其中，在确定不存在冲突的情况中，基于所述第二交易的预执行读写集更新所述预执行状态集，将所述第二交易顺序记录到预执行交易集合中，作为所述第二交易的预执行顺序。
  8. 根据权利要求7所述的方法，其中，所述确定所述第二交易的预执行读集是否与所述预执行状态集存在冲突包括，确定所述预执行状态集中是否包括所述第二交易的预执行读集中的变量，在确定所述预执行状态集中包括所述变量的情况中，确定所述预执行状态集中的所述变量的值与所述预执行读集中的所述变量的值是否一致，如果不一致，则确定所述第二交易的预执行读集与所述预执行状态集存在冲突。
  9. 根据权利要求1所述的方法，其中，所述确定所述第一交易包括对预设类型的第一合约的调用包括，在预执行所述第一交易的过程中确定所述第一合约中调用预设接口，所述预设接口的执行依赖于共识生成的数据。
  10. 一种在区块链系统中执行交易的方法，所述区块链系统包括主节点和从节点，所述区块链系统中存储有预设类型的合约的账户列表，所述预设类型的合约的执行依赖于共识生成的数据，所述方法由所述从节点执行，包括：
    从所述主节点接收第一区块的共识提议，所述共识提议中包括第一交易的第一信息，所述第一信息用于指示所述第一交易中包括对预设类型的第一合约的调用；
    与所述主节点和其他至少部分从节点进行对所述共识提议的共识；
    在共识达成之后，在执行所述第一交易时，在确定所述第一交易包括对预设类型的合约的调用、且所述第一交易不涉及除所述列表包括的账户之外的账户时，完成对所述第一交易的执行。
  11. 根据权利要求10所述的方法，还包括：在执行所述第一交易时，在确定所述第一交易涉及除所述列表包括的账户之外的账户时，终止对所述第一交易的执行。
  12. 根据权利要求11所述的方法，所述第一信息用于指示：所述第一交易中包括对预设类型的第一合约的调用，且所述第一交易涉及除所述列表包括的账户之外的账户，所述方法还包括：在确定所述第一信息正确时，终止对所述第一交易的执行。
  13. 根据权利要求10或11所述的方法，所述共识提议中还包括多个第二交易的预执行读写集，所述方法还包括：根据所述多个第二交易的预执行读写集对所述多个第二交易分组，根据所述分组结果并行执行所述多个第二交易。
  14. 一种区块链系统中的主节点，包括：
    预执行单元，用于在开始预执行第一交易之后，在确定所述第一交易包括对预设类型的第一合约的调用时，终止对所述第一交易的预执行，其中，所述预设类型的合约的执行依赖于共识生成的数据；
    共识单元，用于生成第一区块的共识提议，所述共识提议中包括所述第一交易的第一信息，所述第一信息用于指示所述第一交易中包括对预设类型的合约的调用；将所述共识提议发送给所述区块链系统的至少部分从节点，与所述至少部分从节点进行对所述共识提议的共识。
  15. 一种区块链系统中的从节点，所述区块链系统中存储有预设类型的合约的账户列表，所述预设类型的合约的执行依赖于共识生成的数据，所述从节点包括：
    共识单元，用于从所述区块链系统的主节点接收第一区块的共识提议，所述共识提议中包括第一交易的第一信息，所述第一信息用于指示所述第一交易中包括对预设类型的第一合约的调用；与所述主节点和其他至少部分从节点进行对所述共识提议的共识；
    执行单元，用于在共识达成之后，在执行所述第一交易时，在确定所述第一交易包括对预设类型的合约的调用、且所述第一交易不涉及除所述列表包括的账户之外的账户时，完成对所述第一交易的执行。
  16. 一种区块链系统，包括主节点和多个从节点，所述区块链系统中存储有预设类型的合约的账户列表，所述预设类型的合约的执行依赖于共识生成的数据，
    所述主节点用于在开始预执行第一交易之后，在根据所述列表确定所述第一交易包括对所述预设类型的第一合约的调用时，终止对所述第一交易的预执行；生成第一区块的共识提议，所述共识提议中包括所述第一交易的第一信息，所述第一信息用于指示所述第一交易中包括对预设类型的合约的调用；将所述共识提议发送给至少部分从节点，与所述至少部分从节点进行对所述共识提议的共识；
    所述从节点用于从所述主节点接收所述共识提议，与所述主节点和其他至少部分从节点进行对所述共识提议的共识；在共识达成之后，在执行所述第一交易时，在根据所述列表确定所述第一交易包括对预设类型的合约的调用、且所述第一交易不涉及除所述列表包括的账户之外的账户时，完成对所述第一交易的执行。
  17. 一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行权利要求1-13中任一项的所述的方法。
PCT/CN2022/135476 2022-06-29 2022-11-30 在区块链系统中执行交易的方法、区块链系统和节点 Ceased WO2024001032A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210753256.4 2022-06-29
CN202210753256.4A CN115150409B (zh) 2022-06-29 2022-06-29 在区块链系统中执行交易的方法、区块链系统、节点及计算机可读存储介质

Publications (1)

Publication Number Publication Date
WO2024001032A1 true WO2024001032A1 (zh) 2024-01-04

Family

ID=83410900

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135476 Ceased WO2024001032A1 (zh) 2022-06-29 2022-11-30 在区块链系统中执行交易的方法、区块链系统和节点

Country Status (2)

Country Link
CN (1) CN115150409B (zh)
WO (1) WO2024001032A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114022275A (zh) * 2021-10-18 2022-02-08 润联软件系统(深圳)有限公司 基于区块链的区块链转账交易方法及相关设备

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115150409B (zh) * 2022-06-29 2024-07-12 蚂蚁区块链科技(上海)有限公司 在区块链系统中执行交易的方法、区块链系统、节点及计算机可读存储介质
CN115766038A (zh) * 2022-11-30 2023-03-07 蚂蚁区块链科技(上海)有限公司 区块链中的交易发送方法和区块链节点
CN116668001B (zh) * 2023-05-31 2026-04-17 蚂蚁区块链科技(上海)有限公司 区块链中的交易处理方法和区块链节点

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190334726A1 (en) * 2018-04-30 2019-10-31 Dell Products L.P. Blockchain-based method and system for immutable resource allocation in a cloud computing environment
CN112734586A (zh) * 2021-01-27 2021-04-30 国网信息通信产业集团有限公司 基于区块链的数据处理方法及系统
CN113743941A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 一种在区块链中执行交易的方法、区块链和主节点
CN114547203A (zh) * 2022-02-25 2022-05-27 蚂蚁区块链科技(上海)有限公司 执行交易的方法、区块链、主节点和从节点
CN115150409A (zh) * 2022-06-29 2022-10-04 蚂蚁区块链科技(上海)有限公司 在区块链系统中执行交易的方法、区块链系统和节点

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11070360B2 (en) * 2018-08-13 2021-07-20 International Business Machines Corporation Parallel transaction validation and block generation in a blockchain
JP7394211B2 (ja) * 2019-08-19 2023-12-07 杭州趣鏈科技有限公司 スマートコントラクトの並行実行の方法、装置、機器、及び媒体
CN110659907B (zh) * 2019-09-24 2021-11-12 北京海益同展信息科技有限公司 用于执行智能合约的方法和装置
CN111240831A (zh) * 2019-12-31 2020-06-05 陕西医链区块链集团有限公司 区块链中交易并行执行方法、装置、电子设备、存储介质
CN112527800B (zh) * 2020-12-18 2022-07-22 山大地纬软件股份有限公司 树形链式账本结构、高性能并行共识方法及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190334726A1 (en) * 2018-04-30 2019-10-31 Dell Products L.P. Blockchain-based method and system for immutable resource allocation in a cloud computing environment
CN112734586A (zh) * 2021-01-27 2021-04-30 国网信息通信产业集团有限公司 基于区块链的数据处理方法及系统
CN113743941A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 一种在区块链中执行交易的方法、区块链和主节点
CN114547203A (zh) * 2022-02-25 2022-05-27 蚂蚁区块链科技(上海)有限公司 执行交易的方法、区块链、主节点和从节点
CN115150409A (zh) * 2022-06-29 2022-10-04 蚂蚁区块链科技(上海)有限公司 在区块链系统中执行交易的方法、区块链系统和节点

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114022275A (zh) * 2021-10-18 2022-02-08 润联软件系统(深圳)有限公司 基于区块链的区块链转账交易方法及相关设备
CN114022275B (zh) * 2021-10-18 2025-10-21 润联软件系统(深圳)有限公司 基于区块链的区块链转账交易方法及相关设备

Also Published As

Publication number Publication date
CN115150409A (zh) 2022-10-04
CN115150409B (zh) 2024-07-12

Similar Documents

Publication Publication Date Title
WO2023231336A1 (zh) 执行交易的方法和区块链节点
WO2023231337A1 (zh) 在区块链中执行交易的方法、区块链的主节点和从节点
CN114827165B (zh) 对多个交易进行分组的方法和区块链节点
CN114936256B (zh) 在区块链中执行交易的方法和区块链节点
CN115150409B (zh) 在区块链系统中执行交易的方法、区块链系统、节点及计算机可读存储介质
WO2024001024A1 (zh) 在区块链系统中执行交易的方法、区块链系统和节点
CN114547203B (zh) 执行交易的方法、区块链、主节点和从节点
WO2023185059A1 (zh) 一种共识方法和区块链节点
WO2024092932A1 (zh) 交易执行方法和区块链节点
WO2024001025A1 (zh) 一种预执行缓存数据清理方法和区块链节点
WO2023160083A1 (zh) 执行交易的方法、区块链、主节点和从节点
TW201918878A (zh) 任務執行的方法及裝置
US20250342469A1 (en) Transaction execution methods, nodes, and blockchain systems
CN116032756A (zh) 基于区块链更新应用程序的配置信息的方法和区块链节点
WO2023231335A1 (zh) 在区块链中执行交易的方法及区块链的主节点
WO2026092570A1 (zh) 跨链系统中的跨链转移资源的方法、系统及装置
CN115098595A (zh) 区块链系统中的节点分组方法和区块链节点
WO2025025436A1 (zh) 基于区块链系统的数据管理方法和区块链节点
WO2024244342A1 (zh) 区块链中的交易处理方法和区块链节点
WO2023240933A1 (zh) 一种基于区块链的分布式应用部署方法及装置
CN117273924A (zh) 交易执行方法及装置和电子设备
CN116366666A (zh) 区块链系统中的链状态更新方法和区块链节点
CN116166342A (zh) 业务处理方法、装置、设备及存储介质
CN115865365B (zh) 基于区块链的分账处理方法、装置及系统
CN116305311A (zh) 区块链系统中验证读写集的方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22949112

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22949112

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 22949112

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 23/06/2025)

122 Ep: pct application non-entry in european phase

Ref document number: 22949112

Country of ref document: EP

Kind code of ref document: A1