WO2023231337A1 - 在区块链中执行交易的方法、区块链的主节点和从节点 - Google Patents

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

Info

Publication number
WO2023231337A1
WO2023231337A1 PCT/CN2022/135264 CN2022135264W WO2023231337A1 WO 2023231337 A1 WO2023231337 A1 WO 2023231337A1 CN 2022135264 W CN2022135264 W CN 2022135264W WO 2023231337 A1 WO2023231337 A1 WO 2023231337A1
Authority
WO
WIPO (PCT)
Prior art keywords
execution
consensus
transaction
block
transactions
Prior art date
Application number
PCT/CN2022/135264
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 WO2023231337A1 publication Critical patent/WO2023231337A1/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, a master node and a slave 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 of executing transactions in a blockchain, a master node and a slave node of the blockchain.
  • a method for executing transactions in a blockchain includes a master node and a slave node, the master node includes a pre-execution process and a first consensus process, the method consists of the The master node executes the method including:
  • the pre-execution process pre-executes a plurality of first transactions of the first block to obtain a pre-execution read and write set of each first transaction;
  • the first consensus process generates a first consensus proposal for the first block and broadcasts the first consensus proposal to the slave node; the first consensus proposal includes the pre-execution of each first transaction literacy set;
  • the pre-execution process pre-executes a plurality of second transactions of the second block; the first block is before the second block .
  • a method for executing transactions in a blockchain includes a master node and a slave node, the slave node includes a second consensus process, a second management process and a computing process, the A method is executed by the slave node, and the method includes:
  • the slave node receives the first consensus proposal broadcast by the master node through the second consensus process;
  • the first consensus proposal includes each of the first transactions obtained by the master node pre-executing a plurality of first transactions of the first block.
  • the pre-execution read and write set of the first transaction;
  • the second management process obtains the pre-execution read and write set of each first transaction from the second consensus process, and the second consensus process and the slave node agree on the first block;
  • the second management process groups the multiple first transactions in parallel to obtain multiple transaction groups, and sends the multiple transaction groups to all Describe the calculation process;
  • the calculation process executes the plurality of transaction groups in parallel.
  • 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 first transactions of the first block and obtain the pre-execution read and write sets of each first transaction;
  • Consensus process used to generate a first consensus proposal for the first block and broadcast the first consensus proposal to the slave node;
  • the first consensus proposal includes pre-execution reads of each first transaction writing collection;
  • the pre-execution process pre-executes a plurality of second transactions of the second block; the first block is before the second block .
  • a slave node in a blockchain is provided, the blockchain further includes a master node, and the slave node includes:
  • Consensus process used to receive the first consensus proposal broadcast by the master node;
  • the first consensus proposal includes the pre-execution of each first transaction obtained by the master node pre-executing multiple first transactions of the first block. Read and write sets; obtain the pre-execution read and write sets of each first transaction, and reach consensus on the first block with the master node;
  • a management process configured to group the plurality of first transactions in parallel to obtain multiple transaction groups during the consensus process 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 first aspect or the second aspect is implemented.
  • a computing device including a memory, a processor, and a computer program stored in the memory and executable on the processor.
  • the processor executes the program, the first aspect or the second aspect is implemented. any one of the methods.
  • the embodiments of this specification provide a method for executing transactions in a blockchain, a master node and a slave node of the blockchain.
  • a pre-execution process and a consensus process are set in the master node, and the pre-execution process pre-executes the current block.
  • the consensus process will consensus on the current block, and during the process of consensus on the current block, the pre-execution process will pre-execute the next block of the current block.
  • the slave node can group and execute the block in parallel without waiting for the consensus on the block to be completed, further improving the speed of transaction execution in the blockchain.
  • 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
  • Figure 7 is a block diagram of a slave 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.
  • 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.
  • 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 can update the world state in the state database based on the pre-execution write set of each transaction of block N in parallel, and perform block N in parallel. Write blocks.
  • 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.
  • 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.
  • the master node after the master node completes the pre-execution of the current block, during the PP phase of consensus on the current block, the master node can perform the pre-execution of the next block and the PP phase of consensus. And the slave node can group and execute the block in parallel without waiting for the consensus on the block to be completed. This effectively improves the speed of transaction execution in the blockchain and improves the performance of the blockchain system.
  • 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 and communication process 17, 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 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.
  • 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.
  • 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 . 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. Finally, 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 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 multiple calculation processes 28 may execute the transaction groups in parallel. 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 and storage process e15.
  • 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.
  • a pre-execution process e11 serially pre-executes transactions Tx1-transaction Tx6, then after each pre-execution of a transaction, the pre-execution process e11 can directly transfer the pre-execution read and write set of the transaction to the cache process e12, and the cache Process e12 updates its stored world state using the pre-execution write set of this transaction. If 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.
  • 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.
  • the slave node completes the consensus on block N together with the master node. Specifically, 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 management process e14 obtains the pre-execution write set of the pre-execution read and write set obtained from the pre-execution transaction Tx1-transaction Tx6 from the consensus process e13.
  • the management process e14 runs in parallel.
  • the state database stored in the storage process e15 is updated.
  • the management process e14 updates the status database using the latest status values of variables in the pre-execution write set of transactions Tx1 to Tx6.
  • 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.
  • 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 Tx3 and transaction Tx5 both include variable D, and the pre-execution sequence of transaction Tx3 is after transaction Tx5. Therefore, the state value of variable D in the pre-execution write set of transaction Tx3 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 Tx3.
  • 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 may send the pre-execution read-write set and pre-execution sequence of transactions Tx1 to Tx6 included in the received consensus proposal to the management process e22.
  • 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.
  • 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 and consensus process 602.
  • the pre-execution process 601 is used to pre-execute multiple first transactions of the first block to obtain the pre-execution read and write sets of each first transaction.
  • the consensus process 602 is used to generate a first consensus proposal for the first block and broadcast the first consensus proposal to the slave node.
  • the first consensus proposal includes a pre-execution read and write set of each first transaction.
  • the pre-execution process 601 pre-executes a plurality of second transactions of the second block, and the first block is before the second block.
  • the first consensus proposal further includes the pre-execution process 601 pre-executing a pre-execution sequence of a plurality of first transactions.
  • the first consensus proposal further includes identifiers of multiple first transactions.
  • Figure 7 is a block diagram of a slave node in a blockchain shown in this specification according to an exemplary embodiment.
  • the blockchain also includes a master node.
  • the slave node may include: consensus process 701, Management process 702 and calculation process 703.
  • the consensus process 701 is used to receive the first consensus proposal broadcast by the master node.
  • the first consensus proposal includes the pre-execution reading and writing of each first transaction obtained by the master node pre-executing multiple first transactions of the first block. Set, obtain the pre-execution read and write set of each first transaction, and reach consensus on the first block with the master node.
  • the management process 702 is used to group multiple first transactions in parallel to obtain multiple transaction groups during the consensus process on the first block.
  • the calculation process 703 is used to execute multiple transaction groups in parallel.
  • the slave node further includes: a stored process (not shown in the figure).
  • the storage process is used to store the state database of the blockchain.
  • the calculation process 703 updates the state database stored by the storage process in parallel based on the execution write sets of the executed transaction groups.
  • the computing process updates the state database stored in the storage process in the following manner: after executing any transaction group, obtains the pre-execution write set corresponding to the transaction group, and uses the execution to complete the execution of the transaction group.
  • the write set verifies the pre-execution write set corresponding to the transaction group. If the verification is passed, the state database of the blockchain is updated according to the execution write set of the transaction group.
  • 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)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Multimedia (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种在区块链中执行交易的方法、区块链的主节点和从节点，区块链包括主节点和从节点，主节点包括预执行进程和第一共识进程，方法由主节点执行，方法包括：预执行进程预执行第一区块的多个第一交易，得到各个第一交易的预执行读写集；第一共识进程生成针对第一区块的第一共识提议，并向从节点广播第一共识提议；第一共识提议包括各个第一交易的预执行读写集；在第一共识进程生成第一共识提议的过程中，预执行进程预执行第二区块的多个第二交易；第一区块在第二区块之前。

Description

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

  1. 一种在区块链中执行交易的方法，所述区块链包括主节点和从节点，所述主节点包括预执行进程和第一共识进程，所述方法由所述主节点执行，所述方法包括：
    所述预执行进程预执行第一区块的多个第一交易，得到各个第一交易的预执行读写集；
    所述第一共识进程生成针对所述第一区块的第一共识提议，并向所述从节点广播所述第一共识提议；所述第一共识提议包括所述各个第一交易的预执行读写集；
    在所述第一共识进程生成所述第一共识提议的过程中，所述预执行进程预执行第二区块的多个第二交易；所述第一区块在所述第二区块之前。
  2. 根据权利要求1所述的方法，所述第一共识提议还包括所述预执行进程预执行所述多个第一交易的预执行顺序。
  3. 根据权利要求1所述的方法，所述第一共识提议还包括所述多个第一交易的标识。
  4. 根据权利要求1所述的方法，其中，所述主节点还包括缓存进程，所述缓存进程存储有所述区块链的最新世界状态的状态数据；
    其中，在所述预执行进程预执行所述多个第一交易之后，还包括：
    所述预执行进程将所述各个第一交易的预执行读写集提交给所述缓存进程；
    所述缓存进程根据所述各个第一交易的预执行读写集中的预执行写集更新存储的世界状态的状态数据。
  5. 根据权利要求4所述的方法，所述预执行进程预执行第二区块的多个第二交易，包括：
    所述预执行进程从所述缓存进程读取所述多个第二交易的预执行读集，并利用读取的所述预执行读集预执行所述多个第二交易。
  6. 根据权利要求4所述的方法，其中，所述第一共识进程生成针对所述第一区块的第一共识提议，包括：
    所述第一共识进程从所述缓存进程至少获取所述各个第一交易的预执行读写集，并基于所述各个第一交易的预执行读写集生成所述第一共识提议。
  7. 根据权利要求6所述的方法，其中，所述主节点还包括第一管理进程和第一存储进程；所述第一存储进程存储有所述区块链的状态数据库；所述方法还包括：
    所述主节点通过所述第一共识进程与所述从节点对所述第一区块进行共识；
    所述第一管理进程从所述第一共识进程获取所述各个第一交易的预执行读写集中的预执行写集；
    在对所述第一区块进行共识的过程中，所述第一管理进程并行地基于所述预执行写集，更新所述第一存储进程存储的所述区块链的状态数据库。
  8. 根据权利要求7所述的方法，其中，所述方法还包括：
    在对所述第一区块进行共识的过程中，且在所述预执行进程完成对所述第二交易的预执行之后，所述第一共识进程并行地生成针对所述第二区块的第二共识提议。
  9. 根据权利要求7所述的方法，其中，所述方法还包括：
    在对所述第一区块进行共识的过程中，且在所述第一共识进程向所述从节点广播所述第二共识提议之后，所述主节点通过所述第一共识进程与所述从节点对所述第二区块进行共识。
  10. 一种在区块链中执行交易的方法，所述区块链包括主节点和从节点，所述从节点包括第二共识进程，第二管理进程和计算进程，所述方法由所述从节点执行，所述方法包括：
    所述从节点通过所述第二共识进程接收所述主节点广播的第一共识提议；所述第一共识提议包括所述主节点预执行第一区块的多个第一交易而得到的各个第一交易的预执行读写集；
    所述第二管理进程从所述第二共识进程获取所述各个第一交易的预执行读写集，以及所述第二共识进程与所述从节点对所述第一区块进行共识；
    在对所述第一区块进行共识的过程中，所述第二管理进程并行地对所述多个第一交易进行分组，得到多个交易组，并将所述多个交易组发送给所述计算进程；
    所述计算进程并行地执行所述多个交易组。
  11. 根据权利要求10所述的方法，其中，所述从节点还包括第二存储进程；所述第二存储进程存储有所述区块链的状态数据库；所述方法还包括：
    所述计算进程在执行所述多个交易组的过程中，并行地基于执行完成的交易组的执行写集，更新所述第二存储进程存储的所述状态数据库。
  12. 根据权利要求11所述的方法，其中，所述计算进程通过如下方式更新所述第二存储进程存储的所述状态数据库：
    所述计算进程在执行完任一交易组之后，从所述第二管理进程获取该交易组对应的预执行写集，并利用执行完成该交易组得到的执行写集对该交易组对应的预执行写集进行验证；
    在所述验证通过的情况下，根据该交易组的执行写集更新所述区块链的状态数据库。
  13. 根据权利要求11所述的方法，其中，在所述计算进程执行所述多个交易组之前，所述方法还包括：
    所述计算进程确定所述第一区块的前一个区块的状态数据是否存储完成；
    若所述第一区块的前一个区块的状态数据存储完成，所述计算进程从所述第二存储进程存储的状态数据库中读取所述多个交易组的读集。
  14. 一种区块链中的主节点，所述区块链还包括从节点，所述主节点包括：
    预执行进程，用于预执行第一区块的多个第一交易，得到各个第一交易的预执行读写集；
    共识进程，用于生成针对所述第一区块的第一共识提议，并向所述从节点广播所述第一共识提议；所述第一共识提议包括所述各个第一交易的预执行读写集；
    其中，在所述共识进程生成所述第一共识提议的过程中，所述预执行进程预执行第二区块的多个第二交易；所述第一区块在所述第二区块之前。
  15. 根据权利要求14所述的主节点，所述第一共识提议还包括所述预执行进程预执行所述多个第一交易的预执行顺序。
  16. 根据权利要求14所述的主节点，所述第一共识提议还包括所述多个第一交易的标识。
  17. 一种区块链中的从节点，所述区块链还包括主节点，所述从节点包括：
    共识进程，用于接收所述主节点广播的第一共识提议；所述第一共识提议包括所述主 节点预执行第一区块的多个第一交易而得到的各个第一交易的预执行读写集；获取所述各个第一交易的预执行读写集，并与所述主节点对所述第一区块进行共识；
    管理进程，用于在共识进程对所述第一区块进行共识的过程中，并行地对所述多个第一交易进行分组，得到多个交易组；
    计算进程，用于并行地执行所述多个交易组。
  18. 根据权利要求17所述的从节点，其中，所述从节点还包括：
    存储进程，用于存储所述区块链的状态数据库；
    其中，所述计算进程在执行所述多个交易组的过程中，并行地基于执行完成的交易组的执行写集，更新所述存储进程存储的所述状态数据库。
  19. 根据权利要求18所述的从节点，其中，所述计算进程通过如下方式更新所述存储进程存储的所述状态数据库：
    在执行完任一交易组之后，获取该交易组对应的预执行写集，并利用执行完成该交易组得到的执行写集对该交易组对应的预执行写集进行验证；
    在所述验证通过的情况下，根据该交易组的执行写集更新所述区块链的状态数据库。
  20. 一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令所述计算机执行权利要求1-13中任一项所述的方法。
  21. 一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现权利要求1-13中任一项所述的方法。
PCT/CN2022/135264 2022-05-30 2022-11-30 在区块链中执行交易的方法、区块链的主节点和从节点 WO2023231337A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210602808.1A CN114936094A (zh) 2022-05-30 2022-05-30 在区块链中执行交易的方法、区块链的主节点和从节点
CN202210602808.1 2022-05-30

Publications (1)

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

Family

ID=82867669

Family Applications (1)

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

Country Status (2)

Country Link
CN (1) CN114936094A (zh)
WO (1) WO2023231337A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114936094A (zh) * 2022-05-30 2022-08-23 蚂蚁区块链科技(上海)有限公司 在区块链中执行交易的方法、区块链的主节点和从节点
CN115658808A (zh) * 2022-09-30 2023-01-31 蚂蚁区块链科技(上海)有限公司 一种共识节点类型的转换方法和共识节点

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113744062A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链节点和区块链
CN113744063A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 区块链中执行交易的方法及装置
CN113743943A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链、主节点和从节点
CN114936092A (zh) * 2022-05-30 2022-08-23 蚂蚁区块链科技(上海)有限公司 在区块链中执行交易的方法及区块链的主节点
CN114936094A (zh) * 2022-05-30 2022-08-23 蚂蚁区块链科技(上海)有限公司 在区块链中执行交易的方法、区块链的主节点和从节点

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113744062A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链节点和区块链
CN113744063A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 区块链中执行交易的方法及装置
CN113743943A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链、主节点和从节点
CN114936092A (zh) * 2022-05-30 2022-08-23 蚂蚁区块链科技(上海)有限公司 在区块链中执行交易的方法及区块链的主节点
CN114936094A (zh) * 2022-05-30 2022-08-23 蚂蚁区块链科技(上海)有限公司 在区块链中执行交易的方法、区块链的主节点和从节点

Also Published As

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

Similar Documents

Publication Publication Date Title
WO2023231337A1 (zh) 在区块链中执行交易的方法、区块链的主节点和从节点
WO2023231335A1 (zh) 在区块链中执行交易的方法及区块链的主节点
WO2023231336A1 (zh) 执行交易的方法和区块链节点
WO2023231345A1 (zh) 对多个交易进行分组的方法和区块链节点
WO2023185059A1 (zh) 一种共识方法和区块链节点
WO2024001024A1 (zh) 在区块链系统中执行交易的方法、区块链系统和节点
TWI738046B (zh) 區塊鏈的智慧型合約執行方法及裝置和電子設備
WO2023160085A1 (zh) 执行交易的方法、区块链、主节点和从节点
WO2023160083A1 (zh) 执行交易的方法、区块链、主节点和从节点
CN114936256A (zh) 在区块链中执行交易的方法和区块链节点
WO2021239087A1 (zh) 一种数据处理方法、装置、设备及介质
WO2023207080A1 (zh) 一种区块链中的数据处理方法及区块链节点
CN110992040A (zh) 交易处理方法、装置及设备
US20210073197A1 (en) Byzantine consensus without centralized ordering
CN113744062B (zh) 在区块链中执行交易的方法、区块链节点和区块链
WO2024001032A1 (zh) 在区块链系统中执行交易的方法、区块链系统和节点
WO2024001025A1 (zh) 一种预执行缓存数据清理方法和区块链节点
CN115941262A (zh) 区块链系统中的交易执行方法和节点
CN116366666A (zh) 区块链系统中的链状态更新方法和区块链节点
CN115398397A (zh) 区块链交易处理系统和方法
CN115174572B (zh) 区块链中的数据组播方法、区块链节点和存储介质
CN114697344B (zh) 区块链系统中共识节点的确定方法、区块链系统、节点、存储介质及计算设备
WO2024092932A1 (zh) 交易执行方法和区块链节点
CN115086325A (zh) 区块链节点分组方法和区块链节点
CN115098595A (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: 22944638

Country of ref document: EP

Kind code of ref document: A1