WO2023231335A1 - 在区块链中执行交易的方法及区块链的主节点 - Google Patents

在区块链中执行交易的方法及区块链的主节点 Download PDF

Info

Publication number
WO2023231335A1
WO2023231335A1 PCT/CN2022/135259 CN2022135259W WO2023231335A1 WO 2023231335 A1 WO2023231335 A1 WO 2023231335A1 CN 2022135259 W CN2022135259 W CN 2022135259W WO 2023231335 A1 WO2023231335 A1 WO 2023231335A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
execution
consensus
transactions
blockchain
Prior art date
Application number
PCT/CN2022/135259
Other languages
English (en)
French (fr)
Inventor
林鹏
徐文博
Original Assignee
蚂蚁区块链科技(上海)有限公司
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 蚂蚁区块链科技(上海)有限公司 filed Critical 蚂蚁区块链科技(上海)有限公司
Publication of WO2023231335A1 publication Critical patent/WO2023231335A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification

Definitions

  • One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a method of executing transactions in a blockchain and a master node of the blockchain.
  • 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 sequential manner in chronological order, and cryptography is used to ensure that the data blocks cannot be tampered with or forged. Due to the characteristics of blockchain, such as decentralization, non-tamperable information, and autonomy, blockchain has also received more and more attention and applications.
  • One or more embodiments of this specification provide a method for executing transactions in a blockchain and a master node of the blockchain.
  • a method of executing transactions in a blockchain includes a master node and a slave node, the method is executed by the master node, the method includes:
  • the first transaction After completing the consensus on the first block, the first transaction is re-executed.
  • a master node in a blockchain is provided, the blockchain further includes slave nodes, and the master node includes:
  • the pre-execution process is used to pre-execute multiple transactions belonging to the first block and determine that the first transaction among the multiple transactions is a preset type of transaction;
  • a consensus process used to reach consensus on the first block with the slave node after pre-executing the multiple transactions
  • the calculation process is used to re-execute the first transaction after completing the consensus on the first block.
  • a computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method described in any one of the above-mentioned first aspects is implemented.
  • a computing device including a memory, a processor, and a computer program stored on the memory and executable on the processor.
  • the processor executes the program, any one of the above first aspects is implemented. the method described.
  • the embodiments of this specification provide a method for executing transactions in a blockchain and a master node of the blockchain. After the master node completes pre-execution of the current block, if it is determined that there are presets in multiple transactions of the current block. type of transaction, the preset type of transaction will be re-executed after completing the consensus on the current block. This effectively improves the execution speed of blocks in the blockchain and improves the performance of the blockchain system.
  • Figure 1 is a diagram of the blockchain architecture applied in the embodiment of this specification.
  • FIG. 2 is a schematic diagram of the consensus process in the PBFT consensus algorithm shown in this specification according to an exemplary embodiment
  • Figure 3 is a schematic diagram of the process of executing transactions in a blockchain according to an exemplary embodiment of this specification
  • Figure 4 is a structural diagram of a master node and a slave node of a blockchain illustrated in this specification according to an exemplary embodiment
  • Figure 5 is a flow chart of a method for executing transactions in a blockchain illustrated in this specification according to an exemplary embodiment
  • Figure 6 is a block diagram of a master node in a blockchain illustrated in this specification according to an exemplary embodiment.
  • Blockchains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain.
  • public chains are represented by Bitcoin and Ethereum. Participants who join the public chain can read data records on the chain, participate in transactions, and compete for the accounting rights of new blocks through consensus.
  • the alliance chain is a blockchain between the public chain and the private chain, which can achieve "partial decentralization". Each node in the alliance chain usually has a corresponding entity or organization; participants join the network through authorization and form a stakeholder alliance to jointly maintain the operation of the blockchain.
  • the blockchain includes, for example, a total of six nodes: master node 1, slave node 2 to slave node 6.
  • the connections between nodes schematically represent P2P (Peer to Peer, point-to-point) connections.
  • P2P Peer to Peer, point-to-point
  • These nodes can store the entire ledger, that is, store the status of all blocks and all accounts.
  • each node in the blockchain can generate the same state in the blockchain by executing the same transaction, and each node in the blockchain can store the same state database.
  • the difference is that the master node 1 can be responsible for pre-executing the received transactions and initiating a consensus proposal to each slave node.
  • the consensus proposal includes, for example, multiple transactions in the block to be formed (for example, block B1).
  • each slave node can execute the multiple transactions according to the pre-execution order in the consensus proposal, thereby generating block B1.
  • FIG. 1 shows that the blockchain includes 6 nodes
  • the embodiments of this description 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 (i.e. malicious nodes), such as the Practical Byzantine Fault Tolerance algorithm PBFT (Practical Byzantine Fault Tolerance).
  • PBFT Practical Byzantine Fault Tolerance algorithm
  • 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 uncertain data can be, for example, distributed random numbers. Therefore, the pre-execution write set obtained by pre-executing non-deterministic transactions before consensus cannot be used to update the state database.
  • the method of re-executing all transactions for uncertain transactions makes it difficult to improve the execution efficiency of the block and also affects the performance of the blockchain system.
  • the embodiment of this specification provides a solution for executing transactions in the blockchain shown in Figure 1, which can effectively increase the execution speed of blocks in the blockchain, thereby improving the performance of the blockchain system.
  • Figure 3 is a schematic diagram of a process of executing transactions in a blockchain according to an exemplary embodiment.
  • the block execution process can be divided into five processes: pre-execution, consensus, transaction execution, status update and block writing.
  • the transactions of each block can be processed in sequence according to the order of the blocks.
  • the flow of different processes can be accomplished through different processes.
  • the master node of the blockchain After the master node of the blockchain obtains multiple transactions of block N, it first pre-executes each transaction of block N, thereby obtaining the pre-execution read and write set corresponding to each transaction.
  • the pre-execution read and write set Sets can be used to group multiple transactions of block N.
  • it can be determined whether the transaction is a preset type of transaction (ie, the above-mentioned uncertain transaction). If the transaction is a preset type of transaction, the transaction can be marked, or the transaction can be marked. The transaction ID is recorded.
  • the master node can perform the preparatory stage of consensus on block N (hereinafter referred to as the PP stage), that is, generate a consensus proposal for block N and submit it to each
  • the consensus proposal is broadcast from the node, and the consensus proposal may include, for example, the hash value of each transaction of block N, the pre-execution read and write set of each transaction, and the pre-execution sequence of each transaction of block N.
  • the master node can also continue to obtain multiple transactions of block N+1 in parallel, pre-execute multiple transactions of block N+1, and perform the PP phase of consensus on block N+1.
  • each slave node After each slave node receives the consensus proposal, it and the master node carry out the preparation phase (hereinafter referred to as P phase) and submission phase (hereinafter referred to as C phase) of consensus on block N (for details, please refer to the process in Figure 2).
  • P phase preparation phase
  • C phase submission phase
  • the master node After the consensus is completed, the master node obtains the consensus results and re-executes at least the preset type of transaction. It can be understood that if the multiple transactions in block N do not include transactions of the preset type, there is no need to re-execute the transactions in block N.
  • the master node can also update the world state in the state database based on the pre-execution write set of each transaction of block N in parallel, and write blocks to block N in parallel.
  • the pre-execution write set of transactions before the transactions of the preset type can be first used to update the world state in the state database.
  • the execution write set obtained by re-executing the transaction of the preset type is used to continue to update the world state in the state database.
  • each slave node After each slave node receives the consensus proposal sent by the master node, in the process of consensus on block N, the transactions of block N can be grouped in parallel based on the pre-execution read-write set and pre-execution sequence sent by the master node. And execute each transaction of block N in parallel according to the group.
  • each slave node can also update the state database based on the execution write set in parallel during the transaction execution process. For example, every time the slave node completes executing a set of transactions in block N, it can update the state database based on the execution write set of the completed set of transactions in parallel during the execution of the next set of transactions.
  • Each slave node can write blocks to block N in parallel during the process of updating the state database based on the execution write set of each transaction of block N.
  • each slave node can obtain the consensus result and execute preset types of transactions in parallel based on the consensus result.
  • the slave node needs to wait for the completion of writing to block N before it can continue to update the state database based on the execution write set of each transaction in block N+1.
  • Figure 4 shows the structure diagram of the master node and slave node of the blockchain provided by the embodiment of this specification.
  • the master node may include access process 11, pre-execution process 12, cache process 13, consensus process 14, storage process 15, management process 16, communication process 17 and calculation process 18, and the slave node may include Access process 21, pre-execution process 22, cache process 23, consensus process 24, storage process 25, management process 26, communication process 27 and calculation process 28.
  • the master node can interact with the client through the access process 11, for example.
  • the access process 11 can receive multiple transactions from the client and transmit the multiple transactions to the cache process 13, and the cache process 13 will place the received transactions. into the transaction queue.
  • the cache process 13 also stores status data of the latest world status of the blockchain.
  • the pre-execution process 12 obtains a batch of transactions from the transaction queue of the cache process 13 every preset period, and pre-executes the obtained transactions to obtain a pre-execution read and write set of each transaction.
  • the pre-execution read and write set of any transaction can include a pre-execution read set and a pre-execution write set.
  • the pre-execution read set can specifically be the key-value pair of the read variable generated during the pre-execution transaction.
  • the pre-execution write set Specifically, it can be a key-value pair of a written variable generated during the process of pre-execution of the transaction.
  • the status value of each variable in the read set of the transaction can be obtained from the latest status data stored by the cache process 13 .
  • the pre-execution read-write set of the transaction can be submitted to the cache process 13 for storage, and the status data stored in the cache process 13 can be updated using the status values of each variable in the write set obtained by pre-executing the transaction.
  • the master node can set up multiple pre-execution processes, and multiple pre-execution processes can pre-execute transactions in parallel. If transactions are pre-executed by multiple pre-execution processes in parallel, each time a transaction is executed, the read set of the pre-executed transactions needs to be verified before updating the state data stored in the cache process 13 . For example, after the pre-execution of transaction Tx1 is completed, it can be verified whether the state value of each variable in the read set of transaction Tx1 stored in the cache process 13 has changed compared with the state value before pre-execution. If no change occurs, the state data stored in the cache process 13 can be directly updated using the state values of each variable in the write set obtained by pre-executing the transaction. If a change occurs, the transaction Tx1 needs to be pre-executed again using the new status values of each variable in the read set of the transaction Tx1 in the cache process 13 .
  • the pre-execution process 12 determines that the transaction is a preset type of transaction, it can notify the cache process 13 when submitting the pre-execution read-write set of the transaction to the cache process 13 13 This transaction is a preset type of transaction, and the cache process 13 can mark the transaction.
  • the cache process 13 not only stores each transaction, but also stores the pre-execution read-write set obtained by pre-executing each transaction and the pre-execution sequence of each transaction. Every once in a while, the consensus process 14 can obtain the consensus data corresponding to a block from the cache process 13.
  • the consensus data can include the hash value/transaction identification/transaction body and each transaction of each transaction in the block. Respective pre-execution read and write sets and the pre-execution order of individual transactions. If the block includes a preset type of transaction, the to-be-consensus data may also include information on uncertain variables involved in the preset type of transaction.
  • the consensus process 14 can generate a consensus proposal carrying the data to be agreed upon, and broadcast the consensus proposal to other slave nodes in the blockchain through the communication process 17. During the process of other slave nodes consensus on the block, they can use the communication process 17 to 17 returns the information generated by the consensus to the consensus process 14. In addition, the consensus process 14 can also send the transaction bodies, pre-execution read and write sets and pre-execution sequences of multiple transactions of the block to the management process 16 . If the block includes a preset type of transaction, the consensus process 14 can also send the information of the preset type of transaction to the management process 16. After completing the consensus, the consensus process 14 may also send the consensus result to the management process 16 .
  • the management process 16 can group transactions based on the pre-execution read and write sets of multiple transactions in the block to obtain grouping information. In another implementation, the management process 16 may also obtain grouping information for transactions from other slave nodes. It can be understood that this embodiment does not limit the specific manner in which the management process obtains group information. Then, the management process 16 can update the state database in the storage process 15 using the state values of each variable in the write set obtained by pre-executing the block. Based on the transaction bodies of multiple transactions of the block, pre-execution read-write sets, grouping information and other information, the block data of the block is generated, and the block data is stored in the block database in the storage process 15 .
  • the management process 16 can send the preset type of transaction to the calculation process 18, and based on the consensus result, the uncertain variables involved in the preset type of transaction
  • the unified value is sent to the calculation process 18.
  • the calculation process 18 re-executes the preset type of transaction based on the unified values of the uncertain variables involved in the preset type of transaction.
  • the calculation process 18 can also re-execute the preset type of transaction in the block. subsequent transactions.
  • the calculation process 18 can update the state database in the storage process 15 using the write set obtained by re-executing the transaction.
  • the computing process 18 may also send a re-execution event notification to the cache process 13, where the re-execution event notification includes the execution write set obtained by re-executing each transaction.
  • the cache process 13 can utilize the execution write set to re-update the stored state data of the world state.
  • the slave node can interact with the client through the access process 21, for example.
  • the access process 21 can receive multiple transactions from the client and transmit the multiple transactions to the cache process 23, and the cache process 23 will place the received transactions. into the transaction queue.
  • the pre-execution process 22 obtains a batch of transactions from the transaction queue of the cache process 23 every preset period, verifies the obtained transactions, and returns the verified transactions to the cache process 23 .
  • the cache process 23 can broadcast the verified transactions to the master node and other slave nodes through the communication process 27. At the same time, the cache process 23 can also receive transactions from other nodes through the communication process 27.
  • the consensus process 24 can receive the consensus proposal initiated by the master node through the communication process 27 and consensus on the block based on the consensus proposal. At the same time, the consensus process 24 may send information such as pre-execution read and write sets and pre-execution sequences of multiple transactions of the blocks included in the consensus proposal to the management process 26 . During the consensus process, the consensus process 24 can return a consensus message to the master node through the communication process 27 and receive the consensus result sent by the master node through the communication process 27 . After the consensus is successful, the consensus process 24 can send the consensus result to the management process 26 .
  • the management process 26 can group multiple transactions of the block in parallel based on their respective pre-execution read and write sets and pre-execution sequences to obtain multiple transaction groups. Then, multiple transaction groups are assigned to the calculation process 28. There may be multiple calculation processes 28, and the multiple calculation processes 28 may execute the transaction groups in parallel after the consensus is completed. When executing a transaction, the calculation process 28 may obtain the status values of each variable in the read set of the transaction from the storage process 25 . After each transaction group is executed, the calculation process 28 can verify the pre-execution write set based on the execution result of the transaction group. If the verification passes, the status of the blockchain in the storage process 25 is updated based on the execution result of the transaction group. database. If the verification fails, it means that the master node is evil. The computing process 28 can notify the management process 26, and the management process 26 initiates a master change request to other slave nodes through the consensus process 24 to replace the master node.
  • the management process 26 generates the block data of the block based on the transaction bodies of the multiple transactions of the block, the pre-execution read-write set, the execution read-write set, the grouping information and other information, and stores the block data in Stored in the block database in process 25.
  • the master node at least includes pre-execution process e11, cache process e12, consensus process e13, management process e14, storage process e15 and calculation process e16.
  • the slave node at least includes the consensus process e21, the management process e22, the calculation process e23 and the storage process e24.
  • the pre-execution process e11 pre-executes multiple transactions belonging to block N.
  • the multiple transactions include, for example, transactions Tx1-transaction Tx6, and obtains the corresponding pre-execution data of transactions Tx1-transaction Tx6.
  • the pre-execution read-write set of a transaction includes a read set and a write set, where the read set includes key-value pairs of variables read when pre-executing the transaction, and the write set includes a pre-execution 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 pre-executing the transaction
  • the write set may include the version number of the variable written, where in the blockchain
  • the state data of the world state stores, for example, each written value of the variable and the version number corresponding to each written value, so that the values read and written by the transaction can be determined by including the version number of the variable in the read-write set.
  • the pre-execution process e11 pre-executes each transaction, it can be determined whether the pre-executed transaction is a preset type of transaction.
  • the preset type of transaction is, for example, a transaction that includes a preset variable in the read set.
  • the preset variable is Random numbers are used as uncertain variables of state values.
  • the preset interface may be, for example, an interface used to obtain random numbers.
  • block N includes a preset type of transaction
  • the pre-execution process e11 can randomly obtain a random number as the state value of the preset variable involved in the preset type of transaction, and pre-execute the preset type of transaction to obtain the Pre-execution read and write sets for transactions of preset types.
  • a pre-execution process e11 serially pre-executes transactions Tx1-transaction Tx6, then after each pre-execution of a transaction, if the transaction is not a default type of transaction, the pre-execution process e11 can directly read and write the pre-execution of the transaction.
  • the cache process e12 uses the pre-execution write set of the transaction to update its stored world state. If the transaction is a preset type of transaction, the pre-execution process e11 can transmit the pre-execution read and write set of the transaction to the cache process e12, and instruct the cache process e12 to mark the transaction.
  • transactions Tx1 to Tx6 are pre-executed by multiple pre-execution processes e11 in parallel, after each transaction is pre-executed, it is necessary to verify whether the read set of the transaction has a read-write conflict with other transactions pre-executed in parallel.
  • the pre-execution read set of transaction Tx2 includes variable A
  • the pre-execution write set includes variable B.
  • the value of variable A read is Va
  • transaction Tx2 is pre-executed based on Va.
  • transaction Tx2 can be re-executed based on Vb. It should be noted that in addition to verifying read-write conflicts through the value of the variable, the read-write conflict can also be verified through the version number of the variable.
  • the pre-execution process e11 can directly transfer the pre-execution read-write set of the transaction to the cache process e12, and the cache process e12 uses the pre-execution of the transaction The write set updates its stored world state. If the transaction is a preset type of transaction, the pre-execution process e11 can transmit the pre-execution read and write set of the transaction to the cache process e12, and instruct the cache process e12 to mark the transaction.
  • the consensus process e13 obtains the pre-execution read and write sets corresponding to transactions Tx1-transaction Tx6 from the cache process e12, generates a consensus proposal for block N, and broadcasts the consensus proposal to the slave node.
  • the consensus proposal includes the pre-execution read and write sets corresponding to transactions Tx1-Tx6.
  • the consensus proposal may also include information such as the order in which the pre-execution process e11 pre-executes transactions Tx1-transaction Tx6 and the hash values of transactions Tx1-transaction Tx6. If there is a preset type of transaction in the transactions Tx1 to Tx6, the consensus proposal may also include information on the preset variables involved in the preset type of transaction.
  • the slave node After receiving the consensus proposal, the slave node completes the consensus on block N together with the master node.
  • the consensus process e13 of the master node and the consensus process e21 of the slave node obtain the consensus results.
  • the slave node can return a consensus message to the master node and receive the consensus result sent by the master node (after the consensus is successful, the consensus process e21 of the slave node can send the consensus result to the management process e22).
  • the consensus result may include unified values of preset variables involved in the transactions of the preset type.
  • transaction Tx3 is a preset type of transaction.
  • Transaction Tx3 includes variable C.
  • the value of variable C is a random number.
  • the consensus result can include the value of variable C. Take a unified value k. Later, when the slave node executes transaction Tx3, it will uniformly use k as the state value of variable C.
  • step 505 the management process e14 obtains the pre-execution write set in the pre-execution read-write set obtained from the pre-execution transaction Tx1-transaction Tx6 from the consensus process e13.
  • the management process e14 can In parallel, the state database stored in storage process e15 is updated based on the pre-execution write set of transactions of non-default types. Specifically, the management process e14 updates the status database using the latest status values of variables in the pre-execution write set of transactions Tx1-transaction Tx2.
  • the pre-execution write set of transaction Tx1 includes variable C, but the pre-execution write set of transactions Tx2 to Tx6 does not involve variable C. Therefore, the status value of variable C in the pre-execution write set of transaction Tx1 can be directly used to update the state database.
  • the pre-execution write sets of transaction Tx1 and transaction Tx2 both include variable D, and the pre-execution sequence of transaction Tx2 is after transaction Tx1. Therefore, the state value of variable D in the pre-execution write set of transaction Tx2 is the latest state of variable D. value, the state database can be updated using the state value of variable D in the pre-execution write set of transaction Tx2. Since transaction Tx3 is a preset type of transaction, the pre-execution write set of transaction Tx3-transaction Tx6 is not needed to update the state database.
  • step 507 after completing the consensus on block N, the management process e14 sends the transactions Tx3-transaction Tx6 to the calculation process e16, and sends the unified value k of the variable C included in the transaction Tx3 to the calculation process e16.
  • the calculation process e16 re-executes the transaction Tx3-transaction Tx6 based on the value k of the variable C, and updates the state database in the storage process e15 based on the re-execution result.
  • the calculation process e16 can also send a re-execution event notification to the cache process e12, and the re-execution event notification can include the execution write set obtained by re-executing the transaction Tx3-transaction Tx6.
  • the cache process e12 can update its stored state data using the execution write set of transactions Tx3-transaction Tx6.
  • the management process e14 performs a block writing operation on block N. Specifically, the management process e14 generates the block header and block body of block N, and stores the block header and block body of block N in the block database in the storage process e15.
  • the block body includes, for example, the transaction body, receipt and other data of each transaction Tx1-transaction Tx6.
  • the block header can include data such as status root, receipt root, and transaction root.
  • the consensus process e21 of the slave node can send information such as the pre-execution read-write set of transactions Tx1-transaction Tx6 included in the received consensus proposal, the pre-execution sequence, and the unified value k of variable C included in transaction Tx3.
  • the management process e22 groups the transactions Tx1 to Tx6 of the block in parallel based on the above-mentioned pre-execution read-write set and pre-execution order to obtain multiple transaction groups. This ensures that transactions in different transaction groups do not have conflicting variables, and the order of transactions in the same transaction group is consistent with the pre-execution order.
  • Each transaction group is then executed in parallel. For example, transactions Tx1, Tx2, and Tx4 are transaction group a, and transactions Tx3, Tx5, and Tx6 are transaction group b.
  • the management process e22 can assign multiple transaction groups, such as transaction group a and transaction group b, to multiple calculation processes e23, and the multiple calculation processes e23 execute transaction group a and transaction group b in parallel at the same time, in the order of pre-execution.
  • the transactions in transaction group a are executed serially, and the transactions in transaction group b are executed serially in pre-execution order.
  • each time the calculation process e23 completes executing a transaction group it updates the state database stored in the storage process e24 using the write set of the transaction group, and sends the execution result of the transaction group to the management process e22. For example, after the execution of transaction group a is completed, the calculation process e23 can obtain the latest status values of all variables involved in the execution write set of transactions Tx1, transaction Tx2, and transaction Tx4, and update the status database with the obtained latest status values of these variables.
  • the management process e22 performs a block writing operation on block N. The specific process of writing block operations is similar to that of the master node and will not be described again here.
  • the above embodiments of this specification provide a method for executing transactions in a blockchain. After the master node completes pre-execution of the current block, if it is determined that there are preset types of transactions in multiple transactions of the current block, then in After completing the consensus on the current block, the preset type of transaction is re-executed. This effectively improves the execution speed of blocks in the blockchain and improves the performance of the blockchain system.
  • this specification also provides embodiments of a device for executing transactions in a blockchain.
  • Figure 6 is a block diagram of a master node in a blockchain shown in this specification according to an exemplary embodiment.
  • the blockchain also includes slave nodes.
  • the master node may include: pre-execution process 601 , consensus process 602 and calculation process 603.
  • the pre-execution process 601 is used to pre-execute multiple transactions belonging to the first block, and determine the first transaction among the multiple transactions to be a preset type of transaction.
  • the consensus process 602 is used to reach consensus on the first block with the slave node after pre-executing multiple transactions.
  • the calculation process 603 is used to re-execute the first transaction after completing the consensus on the first block.
  • the above-mentioned preset type of transaction is a transaction that includes a preset variable in the read set, and the preset variable uses a random number as the state value.
  • the pre-execution process 601 can determine that the first transaction among the above-mentioned multiple transactions is a preset type of transaction in the following manner: during the process of pre-executing the first transaction, it is determined that the first transaction calls the smart contract, When calling the smart contract, it is determined whether to call the default interface. If the default interface is called, the first transaction is determined to be a transaction of the default type.
  • the consensus process 602 can re-execute the first transaction in the following manner: obtain a consensus result, which includes a target state value after consensus, and the target state value is the above-mentioned predetermined value in the read set of the first transaction. Set the state value of the variable and re-execute the first transaction based on the target state value.
  • the first transaction is the first pre-executed transaction of a preset type among multiple transactions in the first block.
  • the calculation process 602 after re-executing the first transaction, the calculation process 602 also re-executes the transactions that were pre-executed after the first transaction among the multiple transactions.
  • the master node also includes a cache process (not shown in the figure), and the cache process stores state data of the latest world state of the blockchain.
  • the pre-execution process 601 after the pre-execution process 601 pre-executes multiple transactions, the pre-execution process 601 submits the pre-execution read-write set of each transaction obtained by pre-executing the multiple transactions to the cache process, and the cache process performs the pre-execution read-write set of each transaction according to the pre-execution read-write set of each transaction.
  • the pre-execution write set updates the state data of the stored world state.
  • the computing process 603 after the computing process 603 re-executes the first transaction, the computing process 603 sends a re-execution event notification to the cache process.
  • the re-execution event notification includes the execution write set obtained by re-executing the first transaction.
  • the cache process uses Perform a write set to re-update the state data of the stored world state.
  • the pre-execution process 601 is configured to: read pre-execution read sets of multiple transactions from the cache process, and pre-execute multiple transactions using the read pre-execution read sets.
  • the device embodiment since it basically corresponds to the method embodiment, please refer to the partial description of the method embodiment for relevant details.
  • the device embodiments described above are only illustrative.
  • the units described as separate components may or may not be physically separated.
  • the components shown as units may or may not be physical units, that is, they may be located in One location, or it can be distributed across multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of one or more embodiments of this specification. Persons of ordinary skill in the art can understand and implement the method without any creative effort.
  • One or more embodiments of this specification also provide a computer-readable storage medium, which stores a computer program.
  • the computer program can be used to execute the execution in the blockchain provided by any of the embodiments of Figures 2 to 5. trading methods.
  • One or more embodiments of this specification also provide a computing device, including a memory and a processor.
  • the memory stores executable code.
  • the processor executes the executable code, the above-mentioned Figures 2 to 2 are implemented. 5.
  • the method for executing transactions in the blockchain provided by any embodiment.
  • 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), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic Cassettes, tape magnetic disk 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)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Multimedia (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本说明书提供一种在区块链中执行交易的方法及区块链的主节点，所述区块链包括主节点和从节点，其中，在区块链中执行交易的方法由所述主节点执行，所述方法包括：预执行属于第一区块的多个交易；确定所述多个交易中的第一交易为预设类型的交易；在预执行所述多个交易之后，与所述从节点对所述第一区块进行共识；在完成对所述第一区块的共识之后，重新执行所述第一交易。

Description

在区块链中执行交易的方法及区块链的主节点
本申请要求于2022年5月30日提交中国国家知识产权局、申请号为2022106004424、申请名称为“在区块链中执行交易的方法及区块链的主节点”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本说明书一个或多个实施例涉及区块链技术领域，特别涉及一种在区块链中执行交易的方法及区块链的主节点。
背景技术
区块链(Blockchain)是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。在区块链中按照时间顺序将数据区块以顺序相连的方式组合成链式数据结构，并以密码学方式保证数据区块不可篡改和不可伪造。由于区块链具有去中心化、信息不可篡改、自治性等特性，区块链也受到人们越来越多的重视和应用。
目前来说，交易的执行效率难以提升，需要一种高效执行交易的方案。
发明内容
本说明书一个或多个实施例提供一种在区块链中执行交易的方法及区块链的主节点。
根据第一方面，提供一种在区块链中执行交易的方法，所述区块链包括主节点和从节点，所述方法由所述主节点执行，所述方法包括：
预执行属于第一区块的多个交易；
确定所述多个交易中的第一交易为预设类型的交易；
在预执行所述多个交易之后，与所述从节点对所述第一区块进行共识；
在完成对所述第一区块的共识之后，重新执行所述第一交易。
根据第二方面，提供一种区块链中的主节点，所述区块链还包括从节点，主节点包括：
预执行进程，用于预执行属于第一区块的多个交易，并确定所述多个交易中的第一交易为预设类型的交易；
共识进程，用于在预执行所述多个交易之后，与所述从节点对所述第一区块进行共识；
计算进程，用于在完成对所述第一区块的共识之后，重新执行所述第一交易。
根据第三方面，提供一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面中任一项所述的方法。
根据第四方面，提供一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述第一方面中任一项所述的方法。
本说明书的实施例提供的技术方案可以包括以下有益效果：
本说明书的实施例提供的在区块链中执行交易的方法及区块链的主节点，在主节点对当前区块进行预执行完成之后，如果确定当前区块的多个交易中存在预设类型的交易，则在完成对当前区块的共识之后，重新执行预设类型的交易。从而有效提高了区块链中区块的执行速度，以及提高了区块链系统的性能。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限 制本申请。
附图说明
为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本说明书实施例所应用的区块链架构图；
图2是本说明书根据一示例性实施例示出的PBFT共识算法中的共识过程示意图；
图3是本说明书根据一示例性实施例示出的一种区块链中执行交易的过程示意图；
图4是本说明书根据一示例性实施例示出的一种区块链的主节点和从节点的结构图；
图5是本说明书根据一示例性实施例示出的一种在区块链中执行交易的方法流程图；
图6是本说明书根据一示例性实施例示出的一种区块链中的主节点的框图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。
区块链一般被划分为三种类型：公有链(Public Blockchain)，私有链(Private Blockchain)和联盟链(Consortium Blockchain)。此外，还有多种类型的结合，比如私有链+联盟链、联盟链+公有链等不同组合形式。其中去中心化程度最高的是公有链。公有链以比特币、以太坊为代表，加入公有链的参与者可以读取链上的数据记录、参与交易以及通过共识竞争新区块的记账权等。在私有链中，网络的写入权限由某个组织或者机构控制，数据读取权限受组织规定。联盟链是介于公有链以及私有链之间的区块链，可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织；参与者通过授权加入网络并组成利益相关联盟，共同维护区块链运行。
如图1所示，是本说明书实施例所应用的区块链架构图。
在图1所示的区块链架构图中，区块链中例如包含主节点1、从节点2～从节点6共6个节点。节点之间的连线示意性的表示P2P(Peer to Peer，点对点)连接。这些节点上可存储全量的账本，即存储全部区块和全部账户的状态。其中，区块链中的每个节点可通过执行相同的交易而产生区块链中的相同的状态，区块链中的每个节点可存储相同的状态数据库。所不同的是，主节点1可负责对接收的交易进行预执行，并向各个从节点发起共识提议，该共识提议中例如包括将要成块的区块(例如区块B1)中的多个交易及各个交易的预执行读写集和预执行顺序等信息。在区块链中的各个节点对共识提议共识成功之后，各个从节点可根据共识提议中的预执行顺序执行该多个交易，从而生成区块B1。
可以理解，图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在存在一个恶意节点的情况下仍可以实现对共识提议的共识成功，完成对区块的执行。
目前来说，存在一种依赖不确定性数据执行的不确定性交易，该不确定性数据例如可以是分布式随机数。因此，在共识之前预执行不确定性交易得到的预执行写集不能用于更新状态数据库。在相关技术中，需要对不确定性数据进行共识，得到各个节点一致的数据。并在共识之后由区块链的每个节点利用一致的数据对不确定性交易正式执行，得到用于更新状态数据库的写集。但是，由于不确定性交易所占数量较少，为了不确定性交易而 将所有交易重新执行的方式，使得区块的执行效率难以提升，也影响了区块链系统的性能。本说明书实施例提供了一种在图1所示区块链中执行交易的方案，可有效提高区块链中区块的执行速度，从而提高区块链系统的性能。
图3是根据一示例性实施例示出的一种区块链中执行交易的过程示意图。
如图3所示，可以将区块的执行流程分成预执行，共识，交易执行，状态更新及写块5个过程。针对每个过程，可以按照区块的顺序依次对各个区块各自的交易进行处理。可选地，可以通过不同进程完成对不同过程的流程。
具体来说，区块链的主节点获取区块N的多个交易之后，首先对区块N的各个交易进行预执行，从而得到各个交易各自对应的预执行读写集，该预执行读写集可以用于对区块N的多个交易进行分组。在预执行任一交易的过程中，可以判断该交易是否是预设类型的交易(即上述不确定性交易)，如果该交易是预设类型的交易，则可以对该交易进行标记，或者将该交易的标识记录下来。
在完成对区块N的各个交易进行的预执行之后，一方面，主节点可以对区块N进行共识的预备阶段(以下简称PP阶段)，即生成针对区块N的共识提议，并向各个从节点广播该共识提议，该共识提议例如可以包括区块N的各个交易的哈希值，各个交易的预执行读写集以及区块N的各个交易的预执行顺序。另一方面，主节点还可以并行地继续获取区块N+1的多个交易，预执行区块N+1的多个交易，并对区块N+1进行共识的PP阶段。
各个从节点接收到该共识提议之后，和主节点对区块N进行共识的准备阶段(以下简称P阶段)和提交阶段(以下简称C阶段)(具体可参考图2的过程)。其间，如果区块N的多个交易中包括预设类型的交易，可以共识得到执行预设类型的交易所依赖的统一数据。在共识完成之后，主节点获取共识结果，并至少重新执行预设类型的交易。可以理解，如果区块N的多个交易中未包括预设类型的交易，则无需重新执行区块N中的交易。
在对区块N进行共识的过程中，主节点还可以并行地基于区块N的各个交易的预执行写集，更新状态数据库中的世界状态，并并行地对区块N进行写块。其中，如果区块N的多个交易中包括预设类型的交易，则可以先利用预设类型的交易之前的交易的预执行写集，更新状态数据库中的世界状态。等共识完成之后，并重新执行完成预设类型的交易之后，再利用重新执行预设类型的交易得到的执行写集，继续更新状态数据库中的世界状态。
需要说明的是，主节点完成对区块N+1的预执行之后，需要等待主节点完成对区块N的写块之后，才可以继续基于区块N+1的各个交易的预执行写集，更新状态数据库中的世界状态。
各个从节点在接收到主节点发送的共识提议之后，在对区块N共识的过程中，可以并行地基于主节点发送的预执行读写集以及预执行顺序对区块N的交易进行分组，并按照分组并行地执行区块N的各个交易。可选地，各个从节点还可以在执行交易的过程中，同时并行地基于执行写集更新状态数据库。例如，从节点每执行完区块N的一组交易，可以在执行下一组交易的过程中，并行地基于执行完的该组交易的执行写集更新状态数据库。各个从节点在基于区块N的各个交易的执行写集更新状态数据库的过程中，可以并行地对区块N进行写块。
需要说明的是，如果区块N的多个交易中包括预设类型的交易，可以共识得到执行预设类型的交易所依赖的统一数据。在完成对区块N的共识之后，各个从节点可以获取共 识结果，并基于共识结果并行执行预设类型的交易。另外，从节点需要等待完成对区块N的写块之后，才可以继续根据区块N+1的各个交易的执行写集更新状态数据库。
本实施例中，在主节点对当前区块进行预执行完成之后，如果确定当前区块的多个交易中存在预设类型的交易，则在完成对当前区块的共识之后，重新执行预设类型的交易。从而有效提高了区块链中区块的执行速度，以及提高了区块链系统的性能。
图4示出了本说明书实施例提供的区块链的主节点和从节点的结构图。
如图4所示，主节点中可以包括接入进程11、预执行进程12、缓存进程13、共识进程14、存储进程15、管理进程16、通信进程17和计算进程18，从节点中可以包括接入进程21、预执行进程22、缓存进程23、共识进程24、存储进程25、管理进程26、通信进程27和计算进程28。
其中，主节点例如可以通过接入进程11与客户端交互，接入进程11可以从客户端接收多个交易，并将多个交易传输给缓存进程13，由缓存进程13将接收到的交易放入交易队列中。另外，缓存进程13中还存储有区块链当前最新的世界状态的状态数据。预执行进程12每隔预设时段从缓存进程13的交易队列中获取一批交易，并对获取的交易进行预执行，得到各个交易的预执行读写集。任一交易的预执行读写集可以包括预执行读集和预执行写集，预执行读集具体可以为在预执行交易的过程中生成的读取的变量的键值对，预执行写集具体可以为在预执行交易的过程中生成的写入的变量的键值对。在预执行交易的过程中，可以从缓存进程13存储的最新状态数据中获取交易的读集中各个变量的状态值。每预执行完一个交易，可以将该交易的预执行读写集提交给缓存进程13进行存储，并利用预执行该交易得到的写集中各个变量的状态值更新缓存进程13中存储的状态数据。
需要说明的是，主节点可以设置多个预执行进程，多个预执行进程可以并行地预执行交易。如果由多个预执行进程并行地预执行交易，则每执行完一个交易，在更新缓存进程13中存储的状态数据之前，需要对预执行的交易的读集进行验证。例如，在预执行完成交易Tx1之后，可以验证交易Tx1的读集中各个变量在缓存进程13中存储的状态值与预执行之前的状态值相比，是否发生变化。如果未发生变化，可以直接利用预执行该交易得到的写集中各个变量的状态值更新缓存进程13中存储的状态数据。如果发生了变化，则需要利用交易Tx1的读集中各个变量在缓存进程13中新的状态值重新预执行交易Tx1。
另外，预执行进程12在预执行任一交易的过程中，如果确定该交易为预设类型的交易，则可以在将该交易的预执行读写集提交给对缓存进程13时，通知缓存进程13该交易为预设类型的交易，缓存进程13可以对该交易进行标记。
缓存进程13中不仅存储有各个交易，还存储有预执行各个交易得到的预执行读写集以及各个交易的预执行顺序。每隔一段时间，共识进程14可以从缓存进程13中获取一个区块对应的待共识数据，该待共识数据可以包括该区块的各个交易各自的哈希值/交易标识/交易体、各个交易各自的预执行读写集以及各个交易的预执行顺序。如果该区块中包括预设类型的交易，该待共识数据还可以包括预设类型的交易中涉及的不确定变量的信息。
共识进程14可以生成携带待共识数据的共识提议，并通过通信进程17将该共识提议广播给区块链中的其它从节点，其它从节点对该区块进行共识的过程中，可以通过通信进程17向共识进程14返回共识产生的信息。此外，共识进程14还可以将该区块的多个交易的交易体，预执行读写集以及预执行顺序发送给管理进程16。如果区块中包括预设类 型的交易，共识进程14还可以将预设类型的交易的信息发送给管理进程16。在完成共识之后，共识进程14可以将共识结果也发送给管理进程16。
在一种实现方式中，管理进程16可以基于该区块的多个交易的预执行读写集对交易进行分组，得到分组信息。在另一种实现方式中，管理进程16还可以从其他从节点获取对交易的分组信息。可以理解，本实施例对管理进程获取分组信息的具体方式方面不限定。接着，管理进程16可以利用预执行该区块得到的写集中各个变量的状态值更新存储进程15中的状态数据库。并基于该区块的多个交易的交易体，预执行读写集以及分组信息等信息，生成该区块的区块数据，并将该区块数据存入存储进程15中的区块数据库。
其中，如果区块中包括预设类型的交易，在完成共识之后，管理进程16可以将预设类型的交易发送给计算进程18，并基于共识结果将预设类型的交易中涉及的不确定变量的统一取值发送给计算进程18。由计算进程18基于预设类型的交易中涉及的不确定变量的统一取值重新执行该预设类型的交易，可选地，计算进程18还可以重新执行该区块中该预设类型的交易之后的各个交易。一方面，计算进程18可以利用重新执行交易得到的写集更新存储进程15中的状态数据库。另一方面，计算进程18还可以向缓存进程13发送重新执行事件通知，该重新执行事件通知包括重新执行各个交易得到的执行写集。缓存进程13可以利用该执行写集重新更新存储的世界状态的状态数据。
其中，从节点例如可以通过接入进程21与客户端交互，接入进程21可以从客户端接收多个交易，并将多个交易传输给缓存进程23，由缓存进程23将接收到的交易放入交易队列中。预执行进程22每隔预设时段从缓存进程23的交易队列中获取一批交易，并对获取的交易进行验证，将验证通过的交易返回给缓存进程23。缓存进程23可以通过通信进程27将验证通过的交易广播给主节点和其它从节点，同时，缓存进程23也可以通过通信进程27接收来自其它节点的交易。
一方面，共识进程24可以通过通信进程27接收主节点发起的共识提议，并基于共识提议对区块进行共识。同时，共识进程24可以将共识提议包括的区块的多个交易各自的预执行读写集以及预执行顺序等信息发送给管理进程26。在共识的过程中，共识进程24可以通过通信进程27向主节点返回共识消息，以及通过通信进程27接收主节点发送的共识结果。共识成功之后，共识进程24可以将共识结果发送给管理进程26。
另一方面，管理进程26可以并行地基于区块的多个交易各自的预执行读写集以及预执行顺序，对区块的多个交易进行分组，得到多个交易组。然后，将多个交易组分配给计算进程28，计算进程28可以有多个，多个计算进程28可以在共识完成后并行地执行交易组。计算进程28在执行交易时，可以从存储进程25中获取交易的读集中各个变量的状态值。每执行完成一个交易组之后，计算进程28可以基于该交易组的执行结果对预执行的写集进行验证，如果验证通过，就基于该交易组的执行结果更新存储进程25中区块链的状态数据库。如果验证未通过，说明主节点作恶，计算进程28可以通知管理进程26，由管理进程26通过共识进程24向其他从节点发起换主请求，以更换主节点。
最后，管理进程26基于该区块的多个交易的交易体，预执行读写集，执行读写集以及分组信息等信息，生成该区块的区块数据，并将该区块数据存入存储进程25中的区块数据库中。
下文将参考图5所示的执行交易的方法流程图详细描述上述流程。在图5中示出的 是主节点和任一从节点在对一个区块进行执行的过程。其中，主节点至少包括预执行进程e11，缓存进程e12，共识进程e13，管理进程e14，存储进程e15以及计算进程e16。从节点至少包括共识进程e21，管理进程e22，计算进程e23以及存储进程e24。
如图5所示，首先，在步骤501中，预执行进程e11预执行属于区块N的多个交易，该多个交易例如包括交易Tx1-交易Tx6，得到交易Tx1-交易Tx6各自对应的预执行读写集。在一种实施方式中，一个交易的预执行读写集中包括读集和写集，其中，读集包括预执行该交易时读取的变量的键值对(key-value)，写集包括预执行该交易时写入的变量的键值对。在另一种实施方式中，该预执行读写集的读集中可包括预执行该交易时读取的变量的版本号，写集中可包括写入的变量的版本号，其中，在区块链的世界状态的状态数据中例如存储了变量的各个写入值及各个写入值对应的版本号，从而通过在读写集中包括变量的版本号即可以确定交易读取和写入的值。
在预执行进程e11预执行各个交易的过程中，可以判断预执行的该交易是否是预设类型的交易，该预设类型的交易例如是读集中包括预设变量的交易，该预设变量为采用随机数作为状态值的不确定变量。具体来说，可以通过如下方式确定预执行的交易是否是预设类型的交易：在预执行该交易的过程中，确定该交易调用智能合约，在调用该智能合约时，判断该智能合约是否调用预设接口。若调用预设接口，则确定该交易为预设类型的交易。其中，该预设接口例如可以是用于获取随机数的接口。如果区块N包括预设类型的交易，预执行进程e11可以随机获取一个随机数作为该预设类型的交易所涉及的预设变量的状态值，并预执行该预设类型的交易，得到该预设类型的交易的预执行读写集。
如果由一个预执行进程e11串行地预执行交易Tx1-交易Tx6，则每预执行完一个交易，若该交易不是预设类型的交易，预执行进程e11可以直接将该交易的预执行读写集传输给缓存进程e12，缓存进程e12利用该交易的预执行写集更新其存储的世界状态。若该交易是预设类型的交易，预执行进程e11可以将该交易的预执行读写集传输给缓存进程e12，并指示缓存进程e12对该交易进行标记。
如果由多个预执行进程e11并行地预执行交易Tx1-交易Tx6，则每预执行完一个交易，需要验证该交易的读集是否和其它并行预执行的交易存在读写冲突。例如，交易Tx2的预执行读集中包括变量A，预执行写集中包括变量B。预执行交易Tx2时，读取的变量A的值为Va，并基于Va预执行交易Tx2。完成对交易Tx2的预执行之后，检验缓存进程e12中变量A的值，如果变量A的值还是Va，则确定不存在读写冲突。如果变量A的值不再是Va，而变成了Vb，则可以基于Vb重新预执行交易Tx2。需要说明的是，除了可以通过变量的值验证读写冲突，也可以通过变量的版本号验证读写冲突。在不存在读写冲突的情况下，若该交易不是预设类型的交易，预执行进程e11可以直接将该交易的预执行读写集传输给缓存进程e12，缓存进程e12利用该交易的预执行写集更新其存储的世界状态。若该交易是预设类型的交易，预执行进程e11可以将该交易的预执行读写集传输给缓存进程e12，并指示缓存进程e12对该交易进行标记。
接着，在步骤503中，共识进程e13从缓存进程e12获取交易Tx1-交易Tx6各自对应的预执行读写集，生成针对区块N的共识提议，并向从节点广播该共识提议。该共识提议包括交易Tx1-交易Tx6各自对应的预执行读写集。可选地，该共识提议还可以包括预执行进程e11预执行交易Tx1-交易Tx6的顺序以及交易Tx1-交易Tx6的哈希值等信息。如 果交易Tx1-交易Tx6中有预设类型的交易，该共识提议还可以包括预设类型的交易中所涉及的预设变量的信息。从节点接收到该共识提议之后，和主节点一起完成对区块N的共识。主节点的共识进程e13和从节点的共识进程e21获取共识结果。具体是，从节点可以向主节点返回共识消息，以及接收主节点发送的共识结果(在共识成功之后，从节点的共识进程e21可以将共识结果发送给管理进程e22)。其中，如果交易Tx1-交易Tx6中有预设类型的交易，则共识结果中可以包括预设类型的交易中所涉及的预设变量的统一取值。
例如，交易Tx3为预设类型的交易，交易Tx3包括变量C，变量C的取值为一个随机数，经过共识后，确定变量C的统一取值为k，则共识结果中可以包括变量C的统一取值k。后面从节点在执行交易Tx3时，统一采用k作为变量C的状态值。
然后，在步骤505中，管理进程e14从共识进程e13获取预执行交易Tx1-交易Tx6得到的预执行读写集中的预执行写集，在对区块N进行共识的过程中，管理进程e14可以并行地基于非预设类型的交易的预执行写集，对存储于存储进程e15中的状态数据库进行更新。具体是，管理进程e14利用交易Tx1-交易Tx2的预执行写集中变量的最新状态值更新状态数据库。例如，交易Tx1的预执行写集包括变量C，而交易Tx2-交易Tx6的预执行写集中均不涉及变量C，因此，可以直接利用交易Tx1的预执行写集中变量C的状态值更新状态数据库。又例如，交易Tx1和交易Tx2的预执行写集均包括变量D，而交易Tx2的预执行顺序在交易Tx1之后，因此，交易Tx2的预执行写集中变量D的状态值为变量D的最新状态值，可以利用交易Tx2的预执行写集中变量D的状态值更新状态数据库。由于交易Tx3为预设类型的交易，因此，不用交易Tx3-交易Tx6的预执行写集更新状态数据库。
在步骤507中，在完成对区块N的共识之后，管理进程e14将交易Tx3-交易Tx6发送给计算进程e16，并将交易Tx3包括的变量C的统一取值k发送给计算进程e16。计算进程e16基于变量C的取值k重新执行交易Tx3-交易Tx6，并基于重新执行的结果更新存储进程e15中的状态数据库。另外，计算进程e16还可以向缓存进程e12发送重新执行事件通知，该重新执行事件通知可以包括重新执行交易Tx3-交易Tx6得到的执行写集。缓存进程e12可以利用交易Tx3-交易Tx6的执行写集更新其存储的状态数据。
在步骤509中，在完成对存储进程e15中的状态数据库的更新之后，管理进程e14进行对区块N的写块操作。具体是，管理进程e14生成区块N的区块头和区块体，并将区块N的区块头和区块体存入存储进程e15中的区块数据库中。其中，区块体例如包括交易Tx1-交易Tx6各自的交易体、收据等数据。区块头可以包括状态根、收据根、交易根等数据。
在步骤511中，从节点的共识进程e21可以将接收到的共识提议包括的交易Tx1-交易Tx6的预执行读写集、预执行顺序及交易Tx3包括的变量C的统一取值k等信息发送给管理进程e22。在共识的过程中，管理进程e22并行地基于上述预执行读写集以及预执行顺序，对区块的交易Tx1-交易Tx6进行分组，得到多个交易组。使得不同交易组的交易不存在冲突的变量，同一交易组的交易顺序与预执行的顺序一致。然后，并行地执行各个交易组。例如，交易Tx1、交易Tx2、交易Tx4为交易组a，交易Tx3、交易Tx5、交易Tx6为交易组b。
然后，管理进程e22可以将多个交易组例如交易组a和交易组b分配给多个计算进 程e23，由多个计算进程e23并行地同时执行交易组a和交易组b，按预执行的顺序串行地执行交易组a中的交易，以及按预执行的顺序串行地执行交易组b中的交易。
在步骤513中，计算进程e23每执行完成一个交易组，利用该交易组的写集更新存储于存储进程e24中的状态数据库，并将该交易组的执行结果发送给管理进程e22。例如，当交易组a执行完成之后，计算进程e23可以获取交易Tx1、交易Tx2、交易Tx4的执行写集中涉及的所有变量的最新状态值，并利用获取的这些变量的最新状态值更新状态数据库。最后，在步骤513中，从节点的计算进程e23完成对存储进程e24中的状态数据库的更新之后，管理进程e22进行对区块N的写块操作。写块操作的具体过程与主节点类似，在此不再赘述。
本说明书的上述实施例提供的在区块链中执行交易的方法，在主节点对当前区块进行预执行完成之后，如果确定当前区块的多个交易中存在预设类型的交易，则在完成对当前区块的共识之后，重新执行预设类型的交易。从而有效提高了区块链中区块的执行速度，以及提高了区块链系统的性能。
应当注意，尽管在上述实施例中，以特定顺序描述了本说明书实施例的方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。相反，流程图中描绘的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。
与前述在区块链中执行交易的方法实施例相对应，本说明书还提供了在区块链中执行交易的装置的实施例。
如图6所示，图6是本说明书根据一示例性实施例示出的一种区块链中的主节点的框图，该区块链还包括从节点，该主节点可以包括：预执行进程601，共识进程602和计算进程603。
其中，预执行进程601，用于预执行属于第一区块的多个交易，并确定该多个交易中的第一交易为预设类型的交易。
共识进程602，用于在预执行多个交易之后，与从节点对第一区块进行共识。
计算进程603，用于在完成对第一区块的共识之后，重新执行第一交易。
在一些实施方式中，上述预设类型的交易为读集中包括预设变量的交易，该预设变量采用随机数作为状态值。
在另一些实施方式中，预执行进程601可以通过如下方式确定上述多个交易中的第一交易为预设类型的交易：在预执行第一交易的过程中，确定第一交易调用智能合约，在调用该智能合约时，判断是否调用预设接口，若调用预设接口，则确定第一交易为预设类型的交易。
在另一些实施方式中，共识进程602可以通过如下方式重新执行第一交易：获取共识结果，该共识结果中包括经过共识后的目标状态值，该目标状态值为第一交易的读集中上述预设变量的状态值，并基于目标状态值重新执行第一交易。
在另一些实施方式中，上述第一交易为第一区块的多个交易中首个被预执行的预设类型的交易。其中，在重新执行第一交易之后，计算进程602还重新执行多个交易中在第一交易之后被预执行的交易。
在另一些实施方式中，主节点还包括缓存进程(图中未示出)，缓存进程存储有区块链的最新世界状态的状态数据。其中，在预执行进程601预执行多个交易之后，预执行进程601将预执行多个交易得到的各个交易的预执行读写集提交给缓存进程，缓存进程根据各个交易的预执行读写集中的预执行写集更新存储的世界状态的状态数据。
在另一些实施方式中，在计算进程603重新执行第一交易之后，计算进程603向缓存进程发送重新执行事件通知，该重新执行事件通知包括重新执行第一交易得到的执行写集，缓存进程利用执行写集重新更新存储的世界状态的状态数据。
在另一些实施方式中，预执行进程601被配置用于：从缓存进程读取多个交易的预执行读集，并利用读取的预执行读集预执行多个交易。
对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书一个或多个实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
本说明书一个或多个实施例还提供了一种计算机可读存储介质，该存储介质存储有计算机程序，计算机程序可用于执行上述图2至图5任一实施例提供的在区块链中执行交易的方法。
本说明书一个或多个实施例还提供了一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现上述图2至图5任一实施例提供的在区块链中执行交易的方法。
在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 (22)

  1. 一种在区块链中执行交易的方法，所述区块链包括主节点和从节点，所述方法由所述主节点执行，所述方法包括：
    预执行属于第一区块的多个交易；
    确定所述多个交易中的第一交易为预设类型的交易；
    在预执行所述多个交易之后，与所述从节点对所述第一区块进行共识；
    在完成对所述第一区块的共识之后，重新执行所述第一交易。
  2. 根据权利要求1所述的方法，其中，所述预设类型的交易为读集中包括预设变量的交易，所述预设变量采用随机数作为状态值。
  3. 根据权利要求2所述的方法，其中，所述确定所述多个交易中的第一交易为预设类型的交易，包括：
    在预执行所述第一交易的过程中，确定所述第一交易调用智能合约；
    在调用所述智能合约时，判断是否调用预设接口；
    若调用所述预设接口，则确定所述第一交易为预设类型的交易。
  4. 根据权利要求2所述的方法，其中，所述重新执行所述第一交易，包括：
    获取共识结果；所述共识结果中包括经过共识后的目标状态值；所述目标状态值为所述第一交易的读集中所述预设变量的状态值；
    基于所述目标状态值重新执行所述第一交易。
  5. 根据权利要求1所述的方法，其中，在确定所述多个交易中的第一交易为预设类型的交易之后，所述方法还包括：对所述第一交易进行标记。
  6. 根据权利要求1所述的方法，其中，所述第一交易为所述第一区块的多个交易中首个被预执行的预设类型的交易；其中，在重新执行所述第一交易之后，所述方法还包括：
    重新执行所述多个交易中在所述第一交易之后被预执行的交易。
  7. 根据权利要求1所述的方法，其中，所述主节点包括预执行进程，共识进程和计算进程；所述主节点通过所述预执行进程预执行所述多个交易，并确定所述多个交易中的第一交易为预设类型的交易；所述主节点通过所述共识进程对所述第一区块进行共识；所述主节点通过所述计算进程重新执行所述第一交易。
  8. 根据权利要求7所述的方法，其中，所述主节点还包括缓存进程，所述缓存进程存储有所述区块链的最新世界状态的状态数据；
    其中，在所述预执行进程预执行所述多个交易之后，还包括：
    所述预执行进程将预执行所述多个交易得到的各个交易的预执行读写集提交给所述缓存进程，所述缓存进程根据所述各个交易的预执行读写集中的预执行写集更新存储的世界状态的状态数据。
  9. 根据权利要求8所述的方法，在所述计算进程重新执行所述第一交易之后，还包括：
    所述计算进程向所述缓存进程发送重新执行事件通知，所述重新执行事件通知包括重新执行所述第一交易得到的执行写集；
    所述缓存进程利用所述执行写集重新更新存储的世界状态的状态数据。
  10. 根据权利要求8所述的方法，其中，所述预执行进程预执行所述多个交易，包括：
    所述预执行进程从所述缓存进程读取所述多个交易的预执行读集，并利用读取的所述预执行读集预执行所述多个交易。
  11. 根据权利要求10所述的方法，其中，所述主节点还包括管理进程和存储进程；所述存储进程存储有所述区块链的状态数据库；所述方法还包括：
    所述共识进程从所述缓存进程获取所述各个交易的预执行读写集；
    所述管理进程从所述共识进程获取所述各个交易的预执行读写集中的预执行写集；
    在对所述第一区块进行共识的过程中，所述管理进程并行地基于所述预执行写集，更新所述存储进程存储的所述区块链的状态数据库。
  12. 一种区块链中的主节点，所述区块链还包括从节点，所述主节点包括：
    预执行进程，用于预执行属于第一区块的多个交易，并确定所述多个交易中的第一交易为预设类型的交易；
    共识进程，用于在预执行所述多个交易之后，与所述从节点对所述第一区块进行共识；
    计算进程，用于在完成对所述第一区块的共识之后，重新执行所述第一交易。
  13. 根据权利要求12所述的主节点，其中，所述预设类型的交易为读集中包括预设变量的交易，所述预设变量采用随机数作为状态值。
  14. 根据权利要求13所述的主节点，其中，所述预执行进程通过如下方式确定所述多个交易中的第一交易为预设类型的交易：
    在预执行所述第一交易的过程中，确定所述第一交易调用智能合约；
    在调用所述智能合约时，判断是否调用预设接口；
    若调用所述预设接口，则确定所述第一交易为预设类型的交易。
  15. 根据权利要求13所述的主节点，所述计算进程通过如下方式重新执行所述第一交易：
    获取共识结果；所述共识结果中包括经过共识后的目标状态值；所述目标状态值为所述第一交易的读集中所述预设变量的状态值；
    基于所述目标状态值重新执行所述第一交易。
  16. 根据权利要求12所述的主节点，其中，所述第一交易为所述第一区块的多个交易中首个被预执行的预设类型的交易；其中，在重新执行所述第一交易之后，所述计算进程还重新执行所述多个交易中在所述第一交易之后被预执行的交易。
  17. 根据权利要求12所述的主节点，其中，所述主节点还包括缓存进程，所述缓存进程存储有所述区块链的最新世界状态的状态数据；
    其中，在所述预执行进程预执行所述多个交易之后，所述预执行进程将预执行所述多个交易得到的各个交易的预执行读写集提交给所述缓存进程，所述缓存进程根据所述各个交易的预执行读写集中的预执行写集更新存储的世界状态的状态数据。
  18. 根据权利要求17所述的主节点，其中，在所述计算进程重新执行所述第一交易之后，所述计算进程向所述缓存进程发送重新执行事件通知，所述重新执行事件通知包括重新执行所述第一交易得到的执行写集；所述缓存进程利用所述执行写集重新更新存储的世界状态的状态数据。
  19. 根据权利要求17所述的主节点，其中，所述预执行进程被配置用于：从所述缓存进程读取所述多个交易的预执行读集，并利用读取的所述预执行读集预执行所述多个交 易。
  20. 根据权利要求10所述的主节点，其中，所述主节点还包括管理进程和存储进程；所述存储进程存储有所述区块链的状态数据库；
    所述共识进程，还用于从所述缓存进程获取所述各个交易的预执行读写集；
    所述管理进程，用于从所述共识进程获取所述各个交易的预执行读写集中的预执行写集；并在对所述第一区块进行共识的过程中，并行地基于所述预执行写集，更新所述存储进程存储的所述区块链的状态数据库。
  21. 一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令所述计算机执行权利要求1-11中任一项所述的方法。
  22. 一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现权利要求1-11中任一项所述的方法。
PCT/CN2022/135259 2022-05-30 2022-11-30 在区块链中执行交易的方法及区块链的主节点 WO2023231335A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210600442.4A CN114936092A (zh) 2022-05-30 2022-05-30 在区块链中执行交易的方法及区块链的主节点
CN202210600442.4 2022-05-30

Publications (1)

Publication Number Publication Date
WO2023231335A1 true WO2023231335A1 (zh) 2023-12-07

Family

ID=82866867

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135259 WO2023231335A1 (zh) 2022-05-30 2022-11-30 在区块链中执行交易的方法及区块链的主节点

Country Status (2)

Country Link
CN (1) CN114936092A (zh)
WO (1) WO2023231335A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114936092A (zh) * 2022-05-30 2022-08-23 蚂蚁区块链科技(上海)有限公司 在区块链中执行交易的方法及区块链的主节点
CN114936094A (zh) * 2022-05-30 2022-08-23 蚂蚁区块链科技(上海)有限公司 在区块链中执行交易的方法、区块链的主节点和从节点

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210004777A1 (en) * 2018-03-23 2021-01-07 Blockchain Labs Inc. Blockchain system to which proof-of-transaction consensus algorithm is applied, and method therefor
CN113743940A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链、主节点和从节点
CN113743941A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 一种在区块链中执行交易的方法、区块链和主节点
CN113743942A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 交易执行方法、区块链、主节点和主存储设备
CN114529417A (zh) * 2022-02-25 2022-05-24 蚂蚁区块链科技(上海)有限公司 执行交易的方法、区块链、主节点和从节点
CN114936092A (zh) * 2022-05-30 2022-08-23 蚂蚁区块链科技(上海)有限公司 在区块链中执行交易的方法及区块链的主节点

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210004777A1 (en) * 2018-03-23 2021-01-07 Blockchain Labs Inc. Blockchain system to which proof-of-transaction consensus algorithm is applied, and method therefor
CN113743940A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链、主节点和从节点
CN113743941A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 一种在区块链中执行交易的方法、区块链和主节点
CN113743942A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 交易执行方法、区块链、主节点和主存储设备
CN114529417A (zh) * 2022-02-25 2022-05-24 蚂蚁区块链科技(上海)有限公司 执行交易的方法、区块链、主节点和从节点
CN114936092A (zh) * 2022-05-30 2022-08-23 蚂蚁区块链科技(上海)有限公司 在区块链中执行交易的方法及区块链的主节点

Also Published As

Publication number Publication date
CN114936092A (zh) 2022-08-23

Similar Documents

Publication Publication Date Title
TWI735820B (zh) 資產管理方法及裝置、電子設備
TWI759563B (zh) 資產管理方法及裝置、電子設備
WO2023231335A1 (zh) 在区块链中执行交易的方法及区块链的主节点
WO2023231337A1 (zh) 在区块链中执行交易的方法、区块链的主节点和从节点
WO2020211483A1 (zh) 区块链中智能合约的存储、执行方法及装置和电子设备
WO2023231336A1 (zh) 执行交易的方法和区块链节点
TWI738046B (zh) 區塊鏈的智慧型合約執行方法及裝置和電子設備
TW201822033A (zh) 資源處理方法及裝置
US11201870B2 (en) Using commit tokens to coordinate permissions submissions to address transaction conflict in blockchain systems
WO2024001024A1 (zh) 在区块链系统中执行交易的方法、区块链系统和节点
WO2023185059A1 (zh) 一种共识方法和区块链节点
WO2023231345A1 (zh) 对多个交易进行分组的方法和区块链节点
CN113743950B (zh) 在区块链系统中执行交易的方法、节点和区块链系统
WO2020220744A1 (zh) 基于区块链的数据处理方法、装置和区块链节点
WO2023160085A1 (zh) 执行交易的方法、区块链、主节点和从节点
WO2023160083A1 (zh) 执行交易的方法、区块链、主节点和从节点
CN114936256A (zh) 在区块链中执行交易的方法和区块链节点
US20200202355A1 (en) Storage and execution of smart contracts in blockchains
US20210073197A1 (en) Byzantine consensus without centralized ordering
CN110490742B (zh) 一种区块链中的交易执行方法及装置
CN113744062B (zh) 在区块链中执行交易的方法、区块链节点和区块链
WO2024001032A1 (zh) 在区块链系统中执行交易的方法、区块链系统和节点
WO2024001025A1 (zh) 一种预执行缓存数据清理方法和区块链节点
WO2023240933A1 (zh) 一种基于区块链的分布式应用部署方法及装置
CN115174572B (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: 22944636

Country of ref document: EP

Kind code of ref document: A1