WO2024066007A1 - Transaction execution method in blockchain system, consensus node, and blockchain system - Google Patents
Transaction execution method in blockchain system, consensus node, and blockchain system Download PDFInfo
- Publication number
- WO2024066007A1 WO2024066007A1 PCT/CN2022/135255 CN2022135255W WO2024066007A1 WO 2024066007 A1 WO2024066007 A1 WO 2024066007A1 CN 2022135255 W CN2022135255 W CN 2022135255W WO 2024066007 A1 WO2024066007 A1 WO 2024066007A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- consensus
- node
- state
- read
- data
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 74
- 238000012795 verification Methods 0.000 claims abstract description 98
- 238000004590 computer program Methods 0.000 claims description 11
- 238000001428 flash vacuum thermolysis Methods 0.000 description 26
- 230000008569 process Effects 0.000 description 23
- 238000010586 diagram Methods 0.000 description 21
- 230000006870 function Effects 0.000 description 15
- 101100233916 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) KAR5 gene Proteins 0.000 description 9
- 238000004422 calculation algorithm Methods 0.000 description 9
- 230000006872 improvement Effects 0.000 description 9
- 238000005516 engineering process Methods 0.000 description 8
- 238000012545 processing Methods 0.000 description 7
- 238000013500 data storage Methods 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 5
- 238000002360 preparation method Methods 0.000 description 5
- 239000000047 product Substances 0.000 description 5
- 238000012546 transfer Methods 0.000 description 5
- 101001121408 Homo sapiens L-amino-acid oxidase Proteins 0.000 description 4
- 101000827703 Homo sapiens Polyphosphoinositide phosphatase Proteins 0.000 description 4
- 102100026388 L-amino-acid oxidase Human genes 0.000 description 4
- 102100023591 Polyphosphoinositide phosphatase Human genes 0.000 description 4
- 101100012902 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) FIG2 gene Proteins 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- OKTJSMMVPCPJKN-UHFFFAOYSA-N Carbon Chemical compound [C] OKTJSMMVPCPJKN-UHFFFAOYSA-N 0.000 description 1
- 241000712062 Patricia Species 0.000 description 1
- 108010001267 Protein Subunits Proteins 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 239000006227 byproduct Substances 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 229910021389 graphene Inorganic materials 0.000 description 1
- 239000003999 initiator Substances 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 229920001296 polysiloxane Polymers 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 239000010979 ruby Substances 0.000 description 1
- 229910001750 ruby Inorganic materials 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- 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/22—Indexing; Data structures therefor; Storage structures
-
- 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
-
- 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
- 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
-
- 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
-
- 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
-
- 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
Definitions
- the embodiments of this specification belong to the field of blockchain technology, and in particular, relate to a transaction execution method, a consensus node, and a blockchain system in a blockchain system.
- Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc.
- data blocks are combined into a chain data structure in a sequential manner according to time order, and a distributed ledger that cannot be tampered with or forged is guaranteed by cryptography. Due to the characteristics of decentralization, information cannot be tampered with, and autonomy, blockchain has also received more and more attention and application.
- the full node is generally used as the minimum facility to participate in the consensus. The full node needs to include the full amount of data to support the consensus function.
- the purpose of the present invention is to provide a light consensus node and transaction execution solution in a blockchain system, which can greatly save storage resources in the blockchain system and improve system efficiency.
- the present specification provides a transaction execution method in a blockchain system, the blockchain system comprising a first type of consensus node and a second type of consensus node, the first type of consensus node storing state data, the state data comprising a plurality of states, the second type of consensus node storing verification data, the verification data corresponding to the plurality of states, the method being executed by the second type of consensus node, comprising:
- the verification data is updated according to the write set.
- a second aspect of the present specification provides a blockchain system, including a first type of consensus node and a second type of consensus node, wherein the first type of consensus node stores state data, wherein the state data includes multiple states, and the second type of consensus node stores verification data, wherein the verification data corresponds to the multiple states.
- the first type of consensus node is used to send a read set of multiple transactions to be executed to the second type of consensus node, where the read set includes a first state read according to the multiple transactions;
- the second type of consensus node is used to verify the read set based on the verification data; if the verification passes, the multiple transactions are executed according to the read set to obtain a write set, and the write set includes a second state for updating the state data; and the verification data is updated according to the write set.
- a third aspect of the present specification provides a consensus node in a blockchain system, the blockchain system comprising a first type of consensus node and a second type of consensus node, the first type of consensus node stores state data, the state data includes multiple states, the second type of consensus node stores verification data, the verification data corresponds to the multiple states, and the second type of consensus node includes:
- an acquisition unit configured to acquire, from a consensus node of the first type, a read set of a plurality of transactions to be executed, the read set comprising a first state read according to the plurality of transactions;
- a verification unit configured to verify the read set based on the verification data
- an execution unit configured to execute the plurality of transactions according to the read set to obtain a write set when the verification passes, wherein the write set includes a second state for updating the state data
- An updating unit is used to update the verification data according to the write set.
- a fourth aspect of the present specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method described in the first aspect.
- a fifth aspect of this specification provides a consensus node, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in the first aspect is implemented.
- the full consensus node sends the read set of the transaction to be executed to the light consensus node, so that the light consensus node can verify the read set based on the verification data, and then execute the transaction according to the read set after the verification is passed, which greatly saves the hardware cost and time cost of data storage and improves the performance and efficiency of the blockchain system.
- FIG1 shows a diagram of a blockchain architecture in one embodiment
- FIG. 2 is a schematic diagram of the consensus process in the PBFT consensus algorithm
- FIG3 is a schematic diagram of the structure of blockchain data storage of consensus nodes in the related art
- FIG4 is a schematic diagram of the structure of an MPT tree
- FIG5 is a schematic diagram of a state hash value tree and a storage hash value tree in an LVP in an embodiment of this specification;
- FIG6 is a schematic diagram of a state hash value tree in an embodiment of this specification.
- FIG7 is a flow chart of a transaction execution method in an embodiment of the present specification.
- FIG8 is a structural diagram of a light consensus node in a blockchain system in an embodiment of this specification.
- FIG1 shows a diagram of a blockchain architecture in an embodiment.
- a blockchain 100 includes N nodes, and FIG1 schematically shows nodes 1 to 8.
- the lines between the nodes schematically represent a P2P (Peer to Peer) connection, and the connection may be, for example, a TCP connection, etc., for transmitting data between nodes.
- P2P Peer to Peer
- Transactions in the blockchain field can refer to task units executed and recorded in the blockchain.
- Transactions usually include a send field (From), a receive field (To), and a data field (Data).
- the From field indicates the account address that initiates the transaction (i.e., initiates a transfer task to another account)
- the To field indicates the account address that receives the transaction (i.e., receives the transfer)
- the Data field includes the transfer amount.
- the blockchain can provide the function of smart contracts.
- 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, so that each node in the blockchain can run the smart contract code in a distributed manner.
- Bob sends a transaction containing information about creating a smart contract (i.e., deploying a contract) to the blockchain 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), and the to field of the transaction is empty to indicate that the transaction is used to deploy a contract.
- the contract address "0x6f8ae93" of the contract is determined.
- Each node adds a contract account corresponding to the contract address of the smart contract to the state database, allocates the state storage corresponding to the contract account, and stores the contract code.
- the hash value of the contract code is saved in the state storage of the contract, so that the contract is successfully created.
- each node in the blockchain can execute the transaction separately, thereby executing the contract separately, and updating the status database based on the execution of the contract.
- the consensus mechanism in the blockchain is a mechanism for blockchain nodes to reach a consensus on block information (or block data) across the entire network, which can ensure that the latest block is 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
- consensus proposal usually after a preset number of consensus nodes reach an agreement on the data to be treated as consensus (i.e., consensus proposal), the consensus on the consensus proposal is determined to be successful.
- each node in the blockchain can generate the same state in the blockchain by executing the same transaction, so that each node in the blockchain stores the same state database.
- FIG2 is a schematic diagram of the consensus process in the PBFT consensus algorithm.
- the consensus process can be divided into four stages: request, pre-prepare (PP), prepare (P) and commit (C).
- a blockchain includes four consensus nodes, node n1-node n4, wherein node n1 is, for example, a master node, and node n2-node n4 are, for example, slave nodes.
- f 1 malicious nodes can be tolerated in node n1-node n4.
- a user of the blockchain can send a request to node n1 through his user device, and the request is, for example, in the form of a blockchain transaction.
- node n1 can package the multiple transactions into a consensus proposal, and send the consensus proposal and the signature of node n1 on the consensus proposal to other consensus nodes (i.e., node n2-node n4) for generating blocks.
- the consensus proposal may include information such as the transaction body of the multiple transactions and the submission order of the multiple transactions.
- each slave node can sign the consensus proposal and send it to each other node.
- each consensus node signs the consensus proposal in the submission phase and sends it to other consensus nodes.
- each consensus node can determine that the submission phase is completed and the consensus is successful. For example, after receiving and verifying the signatures of the submission phase of nodes n2 and n3, node n1 determines that the submission phase is completed, so that node n1 can execute the multiple transactions according to the consensus proposal, generate and store blocks (such as block N) including the multiple transactions, update the world state according to the execution results of the multiple transactions, and return the execution results of the multiple transactions to the user device.
- blocks such as block N
- nodes n2 and n3 execute the multiple transactions, update the world state according to the execution results of the multiple transactions, and generate and store block N.
- nodes n1-n4 can still achieve consensus on the consensus proposal successfully and complete the execution of the block in the presence of a malicious node.
- FIG3 is a schematic diagram of the structure of the blockchain data storage of the consensus node in the related art.
- the block header of each block includes several fields, such as the previous block hash previous_Hash (Prev Hash in the figure), the random number Nonce (in some blockchain systems, this Nonce is not a random number, or in some blockchain systems, the Nonce in the block header is not enabled), the timestamp Timestamp, the block number Block Num, the state tree root hash State_Root, the transaction tree root hash Transaction_Root, the receipt tree root hash Receipt_Root, etc.
- the previous block hash previous_Hash Prev Hash in the figure
- the random number Nonce in some blockchain systems, this Nonce is not a random number, or in some blockchain systems, the Nonce in the block header is not enabled
- the timestamp Timestamp the block number Block Num
- the state tree root hash State_Root the transaction tree root hash Transaction_Root
- the Prev Hash in the block header of the next block points to the previous block (such as block N), which is the block hash value of the previous block (i.e., the hash value of the block header).
- the next block on the blockchain is locked to the previous block through the block header.
- state_root is the hash value of the root of the state trie consisting of the states of all accounts in the current block, such as the Merkle Patricia Tree (MPT Tree).
- the MPT tree is a tree structure that combines the Merkle tree and the Patricia tree (a compressed prefix tree, a more space-saving Trie tree, a dictionary tree).
- the Merkle Tree algorithm calculates a hash value for each leaf node, and then connects two nodes to calculate the hash again until the top Merkle root.
- Ethereum uses an improved MPT tree, which is a 16-way tree structure.
- the state tree contains key-value pairs (key and value pairs) of the storage content corresponding to each account in the Ethereum network.
- the "key" in the state tree can be a 160-bit identifier (the address of the Ethereum account), and the characters contained in this account address are distributed in each node in the path from the root node of the state tree to the leaf node.
- the leaf nodes of the MPT state tree (such as node t4 and node t5) also include the Value of each account.
- the account is a user account (also known as an external account), such as account A in FIG3, the Value of the account includes a counter (Nonce) and a balance (Balance).
- the Value of the account includes a counter (Nonce), a balance (Balance), a contract code hash value (CodeHash) and a storage tree root hash value (Storage_root).
- the counter for an external account, represents the number of transactions sent from the account address; for a contract account, it is the number of contracts created by the account.
- FIG. 4 is a schematic diagram of the structure of the MPT tree. Assume that the node marked "t2" in Figure 4 corresponds to the node t2 in the state tree in Figure 3, and the node marked "t4" corresponds to the leaf node t4 in the state tree in Figure 3. As shown in Figure 4, the states included in each leaf node in Figure 4 are respectively represented as state1, state2, state3, and state4, and each state is also the Value of each account.
- each node between the leaf node where state1 is located and the root node includes the characters "f", "5" and "324", so that the account address corresponding to state1 can be obtained as "f5324".
- the child nodes of the node including “5” include leaf nodes.
- the following formula (1) can be used for calculation:
- hash(324,74) hash(hash(324,hash(state1)),hash(74,hash(a,c))) (1)
- the hash value of the node in the state tree is a hash value calculated based on all the data of the node, and the hash value included in the node that is not a leaf node and a non-root node in the state tree is a hash value obtained by concatenating the hash values of all its child nodes and hashing them.
- the hash value included in each node between the leaf node and the root node can be calculated from bottom to top in the state tree, so that the calculated hash value of node t2 in Figure 3 can be concatenated with the hash value of node t3, and the concatenated data is hashed to generate the hash value of node t1.
- the hash value of node t1 is the state root of the state tree, which is recorded in the State_Root field of block N.
- a branch node may be included, and the branch node may be connected to multiple child nodes, and the branch node includes the hash value of the data in each child node connected to it, that is, the branch node includes multiple hash values corresponding to multiple main nodes, and the leaf node is connected after the branch node.
- This variation also includes an extension node, which can be connected before or after the branch node, and the extension node has a child node, and the extension node includes the hash value of all data in the child nodes connected to it.
- the hash value of the root node can also be recursively obtained based on the nodes of each layer. The embodiment of this specification is also applicable to this MPT tree variation.
- This contract account generally has some states, which are defined by the state variables in the smart contract and generate new values when the smart contract is created and executed.
- the relevant states of the contract are stored in the storage trie
- Figure 3 schematically shows the storage trie of the contract corresponding to account B.
- the hash value of the root node st1 of the storage tree is stored in the above storage_root, so that all states of the contract are locked to the Value (i.e., account state) of the contract account in the state tree through the root hash.
- the storage tree can also have an MPT tree structure.
- each node in the path from the root node to the leaf node can include characters for addressing the variable name, and the leaf node stores the value of the variable, so that the key-value mapping from the variable name (also called the state address) to the state value is stored in the storage tree.
- the leaf nodes st2 and st3 of the storage tree include the Value of variable a, the Value of variable b, etc.
- the characters included in each node in the node path from the root node to the leaf node st2 in the storage tree constitute the variable name of variable a, and the variable name can similarly be composed of hexadecimal characters.
- the calculation of the hash value of each node in the storage tree can refer to the method for calculating the hash value of the node in the state tree. Specifically, when calculating the hash value of a leaf node in the storage tree, the hash value of the partial key included in the leaf node and the state in the leaf node are spliced, and then the hash value of the spliced data is calculated to obtain the hash value of the leaf node.
- the data in the node is directly spliced, and then the hash value of the spliced data is calculated to obtain the hash value of the node.
- the FVP node includes tree-like state data, the leaf nodes of which include the state of the account or contract variable, each node in the path from the root node to the leaf node in the state data includes the key of the state, and the parent node in the state data includes a hash value calculated based on the data in its child nodes.
- the nodes in the blockchain reach a consensus on the next batch of transactions, and execute block N+1 after the consensus is passed, thereby generating state data corresponding to block N+1 similarly to the execution of block N, and the state data includes a state tree and storage trees corresponding to each contract.
- the data of the state data of block N+1 that is repeated with the state data of block N can refer to the data in block N without repeated storage. In this way, when each consensus node stores complete block data and state data, a large storage space is required.
- the embodiment of this specification provides a light consensus node (Light Validating Peer, LVP), in which only part of the state data is saved, for example, the hash value data in the state tree and the storage tree is saved, but the Value (i.e., each state) of each account or variable in the state tree and the storage tree is not saved.
- LVP Light Validating Peer
- the blockchain also includes a full consensus node (Full Validating Peer, FVP) that is the same as the consensus node in the related art.
- FIG5 is a schematic diagram of the state hash value tree and the storage hash value tree in the LVP in the embodiment of this specification.
- FIG5 is a schematic diagram of the state hash value tree in FIG5.
- the leaf node in the state hash value tree, includes the last character of the account address and the state hash value of the corresponding leaf node in the state tree.
- the leaf node t4 in the state hash value tree includes the hash (state1) of "state1" in the leaf node t4 in the state tree.
- the hash values included in each node other than the leaf node and the root node in the state hash value tree can be generated using the same calculation method as in the state tree.
- the hash (324, 74) in the node including "5" in Figure 6 can be calculated by the above formula (1).
- the storage hash value tree can also have a structure similar to the structure shown in Figure 6.
- the data included in the state hash value tree and the storage hash value tree other than the leaf node in Figure 5 is consistent with the corresponding nodes in the state tree and storage tree in Figure 3, so the root hash value of the node t1 in Figure 5 is consistent with the root hash value of the node t1 in Figure 3.
- the state hash value tree and storage hash value tree shown in Figures 5 and 6 can be used to verify the read set received from the FVP, so these data can be collectively referred to as verification data. It can be understood that the verification data is not limited to including the structure shown in Figure 5 or Figure 6.
- the verification data may at least include the hash value of the state of each leaf node in the state tree and the storage tree.
- the verification data may at least include the hash value of the state of each leaf node in the state tree and the storage tree.
- it is only necessary to delete the state in the leaf node in the MPT tree variant, that is, the hash value tree after the deletion can be used as the verification data in the LVP node.
- the following will use the state data and verification data shown in Figures 3-6 as examples to describe the consensus and transaction execution scheme in the embodiments of this specification.
- LVP can participate in transaction execution and update the locally stored hash value data based on the transaction execution results, which can greatly save storage resources in LVP and reduce the storage cost of the blockchain system.
- FIG7 is a flow chart of a transaction execution method in an embodiment of the present specification.
- the method may be executed by a FVP (schematically shown as an FVP in FIG7 ) and one or more LVPs as a master node in a blockchain system, and FIG7 shows an LVP as an example.
- the blockchain system may include at least one FVP, and the at least one FVP may jointly determine an FVP as a master node, and nodes other than the master node in the blockchain system are slave nodes.
- the master node may initiate a consensus proposal to reach a consensus on the consensus proposal together with the slave nodes.
- step S701 the consensus nodes in the blockchain system reach a consensus on the consensus proposal.
- FVP1 in the blockchain system is the master node
- FVP1 is used as an example in the following description.
- FVP1 can receive transactions sent by users from user clients or other FVPs.
- the transaction can be a transfer transaction, or a transaction that calls a contract, etc.
- FVP1 After receiving a certain amount of transactions, FVP1 can select multiple transactions from the received transactions for consensus to generate a new block.
- the FVP1 first generates a consensus proposal, which includes the arrangement order of the multiple transactions for sequencing the multiple transactions.
- the consensus proposal may include a transaction list of the multiple transactions, and the transaction list includes the transaction bodies of the multiple transactions arranged in sequence.
- the consensus proposal may include a list of transaction hash values of the multiple transactions.
- the master node can broadcast each transaction to each other consensus node through broadcasting, which can reduce the amount of data in the consensus proposal, thereby reducing the amount of data that needs to be signed during the consensus process and accelerating the consensus process.
- each consensus node in the blockchain can, for example, reach consensus on the consensus proposal through the consensus process shown in Figure 2, which will not be repeated here.
- step S703 the FVP sends the read-set status of multiple transactions to the LVP.
- FVP1 may obtain read sets corresponding to the multiple transactions by pre-executing the multiple transactions. FVP1 may pre-execute the multiple transactions according to a preset arrangement order of the multiple transactions, or FVP1 may pre-execute the multiple transactions according to the order in which each transaction is received, and determine the arrangement order of the multiple transactions in the consensus proposal according to the pre-execution order of each transaction.
- FVP1 When FVP1 reads the value of an account or contract variable for the first time during the pre-execution of multiple transactions, it reads it from the state data and generates a read set of the multiple transactions based on the value of the account or contract variable read for the first time. At the same time, FVP1 caches the value of the account or contract variable read for the first time. When the value of these first-read account or contract variables is updated during the pre-execution of multiple transactions, the value of these account or contract variables is updated in the cache. When the value of these account or contract variables is read again during the pre-execution of multiple transactions, the value of these account or contract variables in the cache is read, wherein the value of these account or contract variables read again does not need to be written into the read set of the multiple transactions.
- the read set includes the status of the account and/or contract variables read from the state data according to the read operations included in the multiple transactions.
- the read set is also the status of the account and/or contract variables that need to be read from the state data when the multiple transactions are executed, wherein the state data, for example, includes the state tree and storage tree shown in Figure 3.
- FVP1 can obtain the read sets of multiple transactions, and then merge the read sets of each transaction, that is, select the key-value pairs of the variables read from the state data when reading each variable (including account and contract variables) for the first time from the read sets of multiple transactions, so as to obtain the read sets corresponding to the multiple transactions. Assuming that one of the multiple transactions includes an update to the balance of account A (for example, reducing a preset amount), the transaction needs to first read the value of account A (that is, including Nonce and Balance) when executing, and then obtain the new value of account A according to the read value of account A.
- the Nonce value is added by 1, and the Balance value is reduced by a preset amount to obtain the updated Nonce value and Balance value of account A, which constitute the updated Value of account A. Therefore, the read set of the transaction includes the key-value pairs of account A read, and the write set of the transaction includes the key-value pairs of account A written.
- the read set of the multiple transactions includes the Key-Value pair of account A read from the status data, where the Key is the account address of account A, and the Value is the status of account A, which includes the Nonce value and Balance value in the leaf node corresponding to account A.
- one of the multiple transactions includes an update operation on variable a in the contract corresponding to account B. Since writing to variable a will result in an update to Storage_root in account B, the transaction also includes a write operation on account B.
- the read set of the transaction needs to include the Key-Value pair of account B and the key-value pair of variable a. Assuming that the reading of account B and variable a by the transaction is the first reading from the state data, the read sets of multiple transactions also include the key-value pair of account B and the key-value pair of variable a read from the state data based on the transaction.
- the key in the Key-Value pair of account B is the account address of account B, and the Value is the state of account B, which includes the values of the Nonce, Balance, CodeHash and Storage_root fields in the leaf node corresponding to account B.
- the key in the Key-Value pair of variable a is the variable name of variable a, and the Value is the state value of variable a.
- the updated Storage_root can be calculated according to the updated value of variable a and merged with the Nonce, Balance, and CodeHash of account B in the read set to obtain the updated value of account B.
- the updated value of variable a and the updated value of account B will be recorded in the write set of the transaction for updating the status data.
- FVP1 may send the read sets to each LVP.
- FVP1 may send the read sets together with the consensus proposal to each LVP.
- each LVP may perform consensus on the consensus proposal and verification of the read sets in parallel, thereby improving system efficiency.
- LVP may perform static analysis on multiple transactions involved in the consensus proposal, analyze the transaction body of the transaction and the contract code of the contract called in the transaction, so as to determine the account and/or variable name that each transaction needs to read when executing, that is, the key in the read set of the multiple transactions. Afterwards, LVP may request the state corresponding to the key from one or more FVPs based on the key in the obtained read set. In the case where LVP requests the state of the read set from multiple FVPs, LVP may request different states from multiple FVPs in parallel, thereby improving the efficiency of obtaining the read set. After obtaining all the states in the read set from the FVP, LVP generates the read set corresponding to the multiple transactions based on the state obtained from the FVP.
- step S705 the LVP verifies whether the read set is correct based on the verification data.
- the state tree in FIG. 3 and the hash value of each state in the storage tree, as well as the index data to the hash value are stored in LVP as verification data.
- LVP can use the hash values of each state to verify each state in the read set.
- the read set includes the Value of account A.
- LVP can obtain the state hash value of account A from the verification data and use the state hash value to verify the Value of account A, that is, verify whether the Value of account A in the read set corresponds to the state hash value of account A stored locally. If so, it can be determined that the Value of account A in the read set is the correct state.
- LVP can obtain the state hash value of account B and the state hash value of variable a from the verification data to verify the Value of account B and the Value of variable a in the read set, respectively.
- the state hash value tree and storage hash value tree as shown in FIG5 are stored in LVP as verification data.
- LVP can perform Simplified Payment Verification (SPV) on each state in the read set based on the state hash value tree and the storage hash value tree.
- SPV Simplified Payment Verification
- the read set includes the Value of account A.
- LVP can calculate the hash value (e.g., hash1) of the Value of account A in the read set, and calculate the hash value of each node layer by layer based on the values of other leaf nodes in the state hash value tree (i.e., the state hash value) and hash1 until the root hash value of the state hash value tree (e.g., root1) is calculated, and it is determined whether root1 is consistent with the root hash value of the state hash value tree stored in LVP. If they are consistent, the Value of account A in the read set is considered to be correct. In the case where the read set includes the Value of account B and the Value of variable a, LVP can similarly perform SPV verification on the Value of account B and the Value of variable a based on the state hash value tree and the storage hash value tree.
- LVP after receiving the consensus proposal and the read sets of multiple transactions from FVP1, LVP can verify the read sets based on the verification data in parallel while reaching consensus on the consensus proposal.
- LVP receives the consensus proposal and obtains the read sets of the multiple transactions from FVP according to the consensus proposal, since the consensus process is long, the consensus process may not be completed after LVP obtains the read sets of multiple transactions. Therefore, LVP can also verify the read sets based on the verification data in parallel while reaching consensus on the consensus proposal.
- the read set can be similarly verified based on the verification data, which will not be repeated here.
- block headers of each block can also be stored in LVP.
- the block header can include the root hash value of the state tree, the root hash value of the transaction tree, and the root hash value of the receipt tree.
- the block header can be used to perform SPV verification on transaction, receipt and other data, and can be used to generate the block header of the next block.
- step S707 the LVP executes multiple transactions according to the read set.
- the LVP can execute multiple transactions in the consensus proposal based on the status in the read set. Specifically, when the LVP needs to read the status of an account or variable in the process of executing a transaction, if it is the first time to read the account or variable, the status of the account or variable can be found from the read set, and the transaction is executed based on the status of the account or variable. According to the write operation on the account or contract variable in the transaction, the write set of the transaction is obtained, and the write set includes the key-value pair of the account or the key-value pair of the contract account and the contract variable, which is used to update the status in the status data.
- the LVP can cache the status, and when executing the write to the account or contract variable, update the status of the account or contract variable in the cache, so as to be used for the subsequent reading of the status of the account or contract variable in the process of executing the transaction. Since the status of the account or variable in the read set has been verified, that is, it is the current correct status of the account or variable, the execution result obtained by executing the transaction based on the status in the read set is consistent with the execution result obtained by FVP executing the transaction based on the status in the status data.
- LVP first reads the value of account A from the read set of multiple transactions (assuming the read value is V1), and updates V1 according to the transaction to obtain the updated value of account A (assuming the value is V2), where V2 includes the updated Nonce value and the updated Balance value, so that the updated key-value pair of account A can be written in the write set of the transaction.
- one of the multiple transactions includes the writing of variable a of the contract corresponding to account B
- LVP first reads the value of account B (assumed to be V3) and the value of variable a (assumed to be V4) from the read set of multiple transactions, processes V4 according to the transaction, obtains the updated value of variable a (assumed to be V5), calculates the hash value of V5, substitutes it into the storage hash value tree in Figure 5, calculates the hash value of the root node st1, and uses the hash value of the root node st1 as the updated storage_root of account B.
- the updated value of account B (assumed to be V6) is calculated, so that the updated key-value pair of account B and the updated key-value pair of variable a can be included in the write set of the transaction.
- each consensus node including FVP and LVP
- it can reach a consensus on the execution results of the multiple transactions.
- the consensus nodes can similarly reach consensus on the execution results of multiple transactions through the consensus process shown in FIG2. Specifically, after executing multiple transactions and obtaining the write sets and receipts of each transaction, each consensus node can calculate the state tree root hash values, transaction tree root hash values, and receipt tree root hash values corresponding to the multiple transactions based on the transaction bodies, write sets, and receipts of the multiple transactions.
- the block hash i.e., the block header hash value of block B1 corresponding to the multiple transactions is calculated based on the state tree root hash values, transaction tree root hash values, receipt tree root hash values, and the block hash of the previous block (i.e., the block header hash value, as shown in Prev Hash in FIG3).
- FVP1 can send a consensus proposal to other consensus nodes in the PP phase, and the consensus proposal includes the block hash of block B1.
- LVP can compare whether the block hash received from FVP1 is consistent with the block hash of block B1 calculated by itself. If they are consistent, the block hash is signed and sent to other consensus nodes. After completing the PP stage, P stage, and C stage in Figure 3, the consensus on the block hash is completed. After the consensus nodes complete the consensus on the block hash, it can be ensured that the execution results of multiple transactions by each consensus node are consistent, so that each node can update the storage according to the execution results of multiple transactions.
- step S709 the LVP updates the verification data according to the write sets of the multiple transactions.
- LVP after obtaining the write sets of each transaction, LVP obtains the write sets corresponding to the multiple transactions (e.g., wset1) according to the write sets of each transaction, and the write set wset1 includes the key-value pairs of the accounts or the key-value pairs of the contract accounts and contract variables that will be used to update the state data according to the write operations of the multiple transactions.
- LVP can update the verification data in LVP based on the hash values of each state in wset1.
- the verification data in LVP includes the hash value of the state of each account and each contract variable. Assuming that the write set wset1 includes the key-value pair of account A to be written, LVP can find the storage location of the value hash value corresponding to the key in the verification data based on the key of account A in wset1, and write the hash value of the state corresponding to the key in wset1 to the storage location.
- LVP first calculates the updated state hash value based on the updated value of variable a, and updates the state hash value of variable a in the verification data. Afterwards, LVP calculates the updated state hash value based on the updated value of account B, and updates the state hash value of account B in the verification data.
- the verification data in the LVP includes a state hash value tree and a storage hash value tree as shown in FIG5 , and the LVP may first update the state hash values in the leaf nodes corresponding to the multiple states in the write set in the state hash value tree and the storage hash value tree as described in the previous embodiment. Then, based on the updated leaf nodes, the hash values included in the nodes at each level in the state hash value tree and the storage hash value tree may be updated upward until the hash values of the root nodes of the state hash value tree and the storage hash value tree are updated.
- the block header can include the root hash value of the state tree, the root hash value of the transaction tree, and the root hash value of the receipt tree.
- the block header can be used to perform SPV verification on data such as transactions and receipts, and can be used to generate the block header of the next block.
- FVP1 While LVP is updating the storage, FVP1 is also updating the storage according to the execution results of multiple transactions. Specifically, FVP1 updates the state tree and storage tree shown in FIG3 according to the write sets of multiple transactions, and stores the block B1 corresponding to the multiple transactions, which includes a block header and a block body.
- the block body includes, for example, transaction bodies, receipts and other data of multiple transactions.
- LVP obtains the read set from FVP, thereby verifying the read set based on the verification data, so that the transaction execution process can be performed according to the read set after the verification is passed, which greatly saves the hardware cost and time cost of data storage and improves the performance and efficiency of the blockchain system.
- LVP may include a consensus device, a storage device, and an execution device, which may be separate units in a single computing device, or may be multiple separate computing devices.
- the storage device stores data such as verification data and block headers in the LVP.
- the FVP sends the consensus proposal to the consensus device to reach a consensus on the consensus proposal.
- the consensus device can also obtain a read set of multiple transactions from the FVP and send the read set to the storage device.
- the storage device can verify whether the read set is correct based on the verification data.
- the consensus device reaches a consensus on the consensus proposal, the storage device can verify the read set in parallel.
- the storage device returns the verification result of the verification to the consensus device.
- the consensus device sends a transaction list and a read set of multiple transactions to the execution device, and the transaction list includes the transaction bodies of each of the multiple transactions and the arrangement order of the multiple transactions.
- the execution device executes multiple transactions according to the read set to obtain the execution results of each transaction, and the execution results include, for example, the write set and receipt of each transaction.
- the execution device returns the execution results of the multiple transactions to the consensus device, and the consensus device generates block hash values corresponding to the multiple transactions according to the execution results of the multiple transactions.
- the consensus nodes (including FVP and LVP) reach a consensus on the block hash value. That is, the consensus devices of each consensus node reach a consensus on the block hash value.
- the consensus device sends the generated block header and updated verification data to the storage device for storage.
- the updated verification data may include, for example, the state hash value tree shown in FIG5 and the updated node value in the storage hash value tree.
- FIG8 is an architecture diagram of a light consensus node in a blockchain system in an embodiment of the present specification, wherein the blockchain system includes a first type of consensus node and a second type of consensus node, wherein the first type of consensus node stores state data, wherein the state data includes multiple states, and the second type of consensus node stores verification data, wherein the verification data corresponds to the multiple states, and the second type of consensus node includes:
- An acquisition unit 81 is configured to acquire a read set of multiple transactions to be executed from a consensus node of the first type, wherein the read set includes a first state read according to the multiple transactions;
- a verification unit 82 configured to verify the read set based on the verification data
- An execution unit 83 is used for executing the multiple transactions according to the read set to obtain a write set when the verification passes, wherein the write set includes a second state for updating the state data;
- the updating unit 84 is configured to update the verification data according to the write set.
- the embodiments of this specification also provide a computer-readable storage medium on which a computer program is stored.
- the computer program is executed in a computer, the computer is caused to execute the method shown in FIG. 7 .
- the embodiment of this specification also provides a consensus node, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method shown in FIG. 7 is implemented.
- a programmable logic device such as a field programmable gate array (FPGA)
- FPGA field programmable gate array
- HDL Hardware Description Language
- HDL Very-High-Speed Integrated Circuit Hardware Description Language
- ABEL Advanced Boolean Expression Language
- AHDL Altera Hardware Description Language
- HDCal Joint CHDL
- JHDL Java Hardware Description Language
- Lava Lava
- Lola MyHDL
- PALASM RHDL
- VHDL Very-High-Speed Integrated Circuit Hardware Description Language
- Verilog Verilog
- the controller may be implemented in any suitable manner, for example, the controller may take the form of a microprocessor or processor and a computer readable medium storing a computer readable program code (e.g., software or firmware) executable by the (micro)processor, a logic gate, a switch, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, and the memory controller may also be implemented as part of the control logic of the memory.
- a computer readable program code e.g., software or firmware
- the controller may be implemented in the form of a logic gate, a switch, an application specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, such a controller may be considered as a hardware component, and the means for implementing various functions included therein may also be considered as a structure within the hardware component. Or even, the means for implementing various functions may be considered as both a software module for implementing the method and a structure within the hardware component.
- 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, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
- one or more embodiments of the present specification provide method operation steps as described in the embodiments or flow charts, more or less operation steps may be included based on conventional or non-creative means.
- the order of steps listed in the embodiments is only one way of executing the order of many steps, and does not represent the only execution order.
- the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment).
- each module can be implemented in the same or more software and/or hardware, or the module implementing the same function can be implemented by a combination of multiple sub-modules or sub-units, etc.
- the device embodiments described above are only schematic.
- the division of the units is only a logical function division. There may be other division methods in actual implementation.
- multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed.
- Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
- each process and/or box in the flowchart and/or block diagram, as well as the combination of the process and/or box in the flowchart and/or block diagram can be implemented by computer program instructions.
- These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.
- These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.
- These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.
- a computing device includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.
- processors CPU
- input/output interfaces network interfaces
- memory volatile and non-volatile memory
- Memory may include non-permanent storage in a computer-readable medium, in the form of random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
- RAM random access memory
- ROM read-only memory
- flash RAM flash memory
- Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information.
- Information can be computer readable instructions, data structures, program modules or other data.
- Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device.
- computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.
- one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
- computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
- One or more embodiments of the present specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules.
- program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
- One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network.
- program modules may be located in 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)
- General Business, Economics & Management (AREA)
- Databases & Information Systems (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- General Engineering & Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Computing Systems (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
A transaction execution method in a blockchain system, a consensus node, and a blockchain system. The blockchain system comprises a first-type consensus node and a second-type consensus node. The first-type consensus node stores state data, which comprises a plurality of states, and the second-type consensus node stores verification data, which is used for verifying the plurality of states. The method is executed by the second-type consensus node, and comprises: acquiring from the first-type consensus node a read set of a plurality of transactions to be executed, the read set comprising a first state that is read according to the plurality of transactions; on the basis of the verification data, verifying the read set; in cases in which verification succeeds, executing the plurality of transactions according to the read set, and obtaining a write set, the write set comprising a second state for updating the state data; and according to the write set, updating the verification data.
Description
本申请要求于2022年09月30日提交中国国家知识产权局、申请号为202211214892.6、申请名称为“区块链***中的交易执行方法、共识节点和区块链***”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on September 30, 2022, with application number 202211214892.6 and application name “Transaction Execution Method, Consensus Node and Blockchain System in Blockchain System”, the entire contents of which are incorporated by reference in this application.
本说明书实施例属于区块链技术领域,尤其涉及一种区块链***中的交易执行方法、共识节点和区块链***。The embodiments of this specification belong to the field of blockchain technology, and in particular, relate to a transaction execution method, a consensus node, and a blockchain system in a blockchain system.
区块链(Blockchain)是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链***中按照时间顺序将数据区块以顺序相连的方式组合成链式数据结构,并以密码学方式保证的不可篡改和不可伪造的分布式账本。由于区块链具有去中心化、信息不可篡改、自治性等特性,区块链也受到人们越来越多的重视和应用。在区块链***中,一般通过全节点作为参与共识的最小设施,全节点需要包括全量数据,以支持共识功能。Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. In the blockchain system, data blocks are combined into a chain data structure in a sequential manner according to time order, and a distributed ledger that cannot be tampered with or forged is guaranteed by cryptography. Due to the characteristics of decentralization, information cannot be tampered with, and autonomy, blockchain has also received more and more attention and application. In the blockchain system, the full node is generally used as the minimum facility to participate in the consensus. The full node needs to include the full amount of data to support the consensus function.
发明内容Summary of the invention
本发明的目的在于提供一种区块链***中的轻共识节点和交易执行方案,可以大大节省区块链***中的存储资源,提供***效率。The purpose of the present invention is to provide a light consensus node and transaction execution solution in a blockchain system, which can greatly save storage resources in the blockchain system and improve system efficiency.
本说明书第一方面提供一种区块链***中的交易执行方法,所述区块链***包括第一类型的共识节点和第二类型的共识节点,所述第一类型的共识节点存储有状态数据,所述状态数据中包括多个状态,所述第二类型的共识节点存储有验证数据,所述验证数据与所述多个状态对应,所述方法由所述第二类型的共识节点执行,包括:In a first aspect, the present specification provides a transaction execution method in a blockchain system, the blockchain system comprising a first type of consensus node and a second type of consensus node, the first type of consensus node storing state data, the state data comprising a plurality of states, the second type of consensus node storing verification data, the verification data corresponding to the plurality of states, the method being executed by the second type of consensus node, comprising:
从所述第一类型的共识节点获取待执行的多个交易的读集,所述读集包括根据所述多个交易读取的第一状态;Obtaining a read set of multiple transactions to be executed from a consensus node of the first type, the read set including a first state read according to the multiple transactions;
基于所述验证数据对所述读集进行验证;verifying the read set based on the verification data;
在验证通过的情况中,根据所述读集执行所述多个交易,得到写集,所述写集包括用于更新所述状态数据的第二状态;If the verification passes, executing the multiple transactions according to the read set to obtain a write set, wherein the write set includes a second state for updating the state data;
根据所述写集更新所述验证数据。The verification data is updated according to the write set.
本说明书第二方面提供一种区块链***,包括第一类型的共识节点和第二类型的共识节点,所述第一类型的共识节点存储有状态数据,所述状态数据中包括多个状态,所述第二类型的共识节点存储有验证数据,所述验证数据与所述多个状态对应,A second aspect of the present specification provides a blockchain system, including a first type of consensus node and a second type of consensus node, wherein the first type of consensus node stores state data, wherein the state data includes multiple states, and the second type of consensus node stores verification data, wherein the verification data corresponds to the multiple states.
所述第一类型的共识节点用于将待执行的多个交易的读集发送给所述第二类型的共识节点,所述读集包括根据所述多个交易读取的第一状态;The first type of consensus node is used to send a read set of multiple transactions to be executed to the second type of consensus node, where the read set includes a first state read according to the multiple transactions;
所述所述第二类型的共识节点用于基于所述验证数据对所述读集进行验证;在验证通过的情况中,根据所述读集执行所述多个交易,得到写集,所述写集包括用于更新所述状态数据的第二状态;根据所述写集更新所述验证数据。The second type of consensus node is used to verify the read set based on the verification data; if the verification passes, the multiple transactions are executed according to the read set to obtain a write set, and the write set includes a second state for updating the state data; and the verification data is updated according to the write set.
本说明书第三方面提供一种区块链***中的共识节点,所述区块链***包括第一类型的共识节点和第二类型的共识节点,所述第一类型的共识节点存储有状态数据,所述状态数据中包括多个状态,所述第二类型的共识节点存储有验证数据,所述验证数据与所述多个状态对应,所述所述第二类型的共识节点包括:A third aspect of the present specification provides a consensus node in a blockchain system, the blockchain system comprising a first type of consensus node and a second type of consensus node, the first type of consensus node stores state data, the state data includes multiple states, the second type of consensus node stores verification data, the verification data corresponds to the multiple states, and the second type of consensus node includes:
获取单元,用于从所述第一类型的共识节点获取待执行的多个交易的读集,所述读集包括根据所述多个交易读取的第一状态;an acquisition unit, configured to acquire, from a consensus node of the first type, a read set of a plurality of transactions to be executed, the read set comprising a first state read according to the plurality of transactions;
验证单元,用于基于所述验证数据对所述读集进行验证;a verification unit, configured to verify the read set based on the verification data;
执行单元,用于在验证通过的情况中,根据所述读集执行所述多个交易,得到写集,所述写集包括用于更新所述状态数据的第二状态;an execution unit, configured to execute the plurality of transactions according to the read set to obtain a write set when the verification passes, wherein the write set includes a second state for updating the state data;
更新单元,用于根据所述写集更新所述验证数据。An updating unit is used to update the verification data according to the write set.
本说明书第四方面提供一种计算机可读存储介质,其上存储有计算机程序,当所述计算机程序在计算机中执行时,令计算机执行第一方面所述的方法。A fourth aspect of the present specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method described in the first aspect.
本说明书第五方面提供一种共识节点,包括存储器和处理器,所述存储器中存储有可执行代码,所述处理器执行所述可执行代码时,实现第一方面所述的方法。A fifth aspect of this specification provides a consensus node, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in the first aspect is implemented.
在本说明书实施例的方案中,在轻共识节点中只保存状态的验证数据,通过由全共识节点将待执行的交易的读集发送给轻共识节点,使得轻共识节点可基于验证数据对读集进行验证,从而可在验证通过之后根据读集执行交易,大大节省了数据存储的硬件成本和时间成本,提高了区块链***的性能和效率。In the scheme of the embodiments of the present specification, only the verification data of the state is saved in the light consensus node. The full consensus node sends the read set of the transaction to be executed to the light consensus node, so that the light consensus node can verify the read set based on the verification data, and then execute the transaction according to the read set after the verification is passed, which greatly saves the hardware cost and time cost of data storage and improves the performance and efficiency of the blockchain system.
为了更清楚地说明本说明书实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本说明书中记载的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.
图1示出了一实施例中的区块链架构图;FIG1 shows a diagram of a blockchain architecture in one embodiment;
图2为PBFT共识算法中的共识过程示意图;Figure 2 is a schematic diagram of the consensus process in the PBFT consensus algorithm;
图3是相关技术中的共识节点的区块链数据存储的结构示意图;FIG3 is a schematic diagram of the structure of blockchain data storage of consensus nodes in the related art;
图4为MPT树的结构示意图;FIG4 is a schematic diagram of the structure of an MPT tree;
图5为本说明书实施例中的LVP中的状态哈希值树和存储哈希值树的示意图;FIG5 is a schematic diagram of a state hash value tree and a storage hash value tree in an LVP in an embodiment of this specification;
图6是本说明书实施例中的状态哈希值树的示意图;FIG6 is a schematic diagram of a state hash value tree in an embodiment of this specification;
图7为本说明书实施例中的交易执行方法的流程图;FIG7 is a flow chart of a transaction execution method in an embodiment of the present specification;
图8为本说明书实施例中的一种区块链***中的轻共识节点的结构图。FIG8 is a structural diagram of a light consensus node in a blockchain system in an embodiment of this specification.
为了使本技术领域的人员更好地理解本说明书中的技术方案,下面将结合本说明书实施例中的附图,对本说明书实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本说明书一部分实施例,而不是全部的实施例。基于本说明书中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本说明书保护的范围。In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.
图1示出了一实施例中的区块链架构图。在图1所示的区块链架构图中,区块链100中包括N个节点,图1中示意示出节点1-节点8。节点之间的连线示意性的表示P2P(Peer to Peer,点对点)连接,所述连接例如可以为TCP连接等,用于在节点之间传输数据。FIG1 shows a diagram of a blockchain architecture in an embodiment. In the diagram of the blockchain architecture shown in FIG1 , a blockchain 100 includes N nodes, and FIG1 schematically shows nodes 1 to 8. The lines between the nodes schematically represent a P2P (Peer to Peer) connection, and the connection may be, for example, a TCP connection, etc., for transmitting data between nodes.
区块链领域中的交易可以指在区块链中执行并记录在区块链中的任务单元。交易中通常包括发送字段(From)、接收字段(To)和数据字段(Data)。其中,在交易为转账交易的情况中,From字段表示发起该交易(即发起对另一个账户的转账任务)的账户地址,To字段表示接收该交易(即接收转账)的账户地址,Data字段中包括转账金额。Transactions in the blockchain field can refer to task units executed and recorded in the blockchain. Transactions usually include a send field (From), a receive field (To), and a data field (Data). Among them, in the case of a transfer transaction, the From field indicates the account address that initiates the transaction (i.e., initiates a transfer task to another account), the To field indicates the account address that receives the transaction (i.e., receives the transfer), and the Data field includes the transfer amount.
区块链中可提供智能合约的功能。区块链上的智能合约是在区块链***上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。在区块链中调用智能合约,是发起一笔指向智能合约地址的交易,使得区块链中每个节点分布式地运行智能合约代码。The blockchain can provide the function of smart contracts. 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, so that each node in the blockchain can run the smart contract code in a distributed manner.
在部署合约的场景中,例如,Bob将一个包含创建智能合约信息(即部署合约)的交 易发送到如图1所示的区块链中,该交易的data字段包括待创建的合约的代码(如字节码或者机器码),交易的to字段为空,以表示该交易用于部署合约。节点间通过共识机制达成一致后,确定合约的合约地址“0x6f8ae93…”,各个节点在状态数据库中添加与该智能合约的合约地址对应的合约账户,分配与该合约账户对应的状态存储,并存储合约代码,将合约代码的哈希值保存在该合约的状态存储中,从而合约创建成功。In the scenario of deploying a contract, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying a contract) to the blockchain 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), and the to field of the transaction is empty to indicate that the transaction is used to deploy a contract. After the nodes reach an agreement through the consensus mechanism, the contract address "0x6f8ae93..." of the contract is determined. Each node adds a contract account corresponding to the contract address of the smart contract to the state database, allocates the state storage corresponding to the contract account, and stores the contract code. The hash value of the contract code is saved in the state storage of the contract, so that the contract is successfully created.
在调用合约的场景中,例如,Bob将一个用于调用智能合约的交易发送到如图1所示的区块链中,该交易的from字段是交易发起方(即Bob)的账户的地址,to字段为上述“0x6f8ae93…”,即被调用的智能合约的地址,交易的data字段包括调用智能合约的方法和参数。在区块链中对该交易进行共识之后,区块链中的各个节点可分别执行该交易,从而分别执行该合约,基于该合约的执行更新状态数据库。In the scenario of calling a contract, for example, Bob sends a transaction for calling a smart contract to the blockchain shown in Figure 1. The from field of the transaction is the address of the account of the transaction initiator (i.e. Bob), the to field is the above-mentioned "0x6f8ae93...", that is, the address of the smart contract being called, and the data field of the transaction includes the method and parameters for calling the smart contract. After consensus is reached on the transaction in the blockchain, each node in the blockchain can execute the transaction separately, thereby executing the contract separately, and updating the status database based on the execution of the contract.
区块链中的共识机制是区块链节点就区块信息(或称区块数据)达成全网一致共识的机制,可以保证最新区块被准确添加至区块链。当前主流的共识机制包括:工作量证明(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个节点达成一致时,可确定共识成功。在相关技术中,为了实现共识功能,在共识节点上存储全量的账本,即存储全部区块和全部账户的状态。从而,区块链中的每个节点可通过执行相同的交易而产生区块链中的相同的状态,以使得区块链中的每个节点存储相同的状态数据库。The consensus mechanism in the blockchain is a mechanism for blockchain nodes to reach a consensus on block information (or block data) across the entire network, which can ensure that the latest block is accurately added to the blockchain. The current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, etc. Among them, in various consensus algorithms, usually after a preset number of consensus nodes reach an agreement on the data to be treated as consensus (i.e., consensus proposal), the consensus on the consensus proposal is determined to be successful. Specifically, in the PBFT algorithm, for N≥3f+1 consensus nodes, f malicious nodes can be tolerated, that is, when 2f+1 nodes among N consensus nodes reach an agreement, the consensus can be determined to be successful. In related technologies, in order to realize the consensus function, the full amount of ledgers is stored on the consensus node, that is, the status of all blocks and all accounts is stored. Thus, each node in the blockchain can generate the same state in the blockchain by executing the same transaction, so that each node in the blockchain stores the same state database.
图2为PBFT共识算法中的共识过程示意图。如图2所示,根据PBFT共识算法,可将共识过程划分为请求(Request)、预备(Pre-Prepare,PP)、准备(Prepare,P)和提交(Commit,C)四个阶段。假设一区块链中包括节点n1-节点n4四个共识节点,其中,节点n1例如为主节点,节点n2-节点n4例如为从节点,根据PBFT算法,在节点n1-节点n4中可容忍f=1个恶意节点。具体是,在请求阶段,区块链的用户可通过其用户设备向节点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可根据共识提议执行所述多个交易,生成并存储包括所述多个交易的区块(例如区块N),根据多个交易的执行结果更新世界状态,并将多个交易的执行结果返回给用户设备。类似地,节点n2和节点n3在确定提交阶段完成之后,执行所述多个交易,根据多个交易的执行结果更新世界状态,并生成并存储区块N。通过上述过程,实现了节点n1、节点n2和节点n3的存储一致性。也就是说,节点n1-节点n4在存在一个恶意节点的情况下仍可以实现对共识提议的共识成功,完成对区块的执行。FIG2 is a schematic diagram of the consensus process in the PBFT consensus algorithm. As shown in FIG2, according to the PBFT consensus algorithm, the consensus process can be divided into four stages: request, pre-prepare (PP), prepare (P) and commit (C). Assume that a blockchain includes four consensus nodes, node n1-node n4, wherein node n1 is, for example, a master node, and node n2-node n4 are, for example, slave nodes. According to the PBFT algorithm, f=1 malicious nodes can be tolerated in node n1-node n4. Specifically, in the request stage, a user of the blockchain can send a request to node n1 through his user device, and the request is, for example, in the form of a blockchain transaction. In the preparation stage, after receiving multiple transactions from one or more user devices, node n1 can package the multiple transactions into a consensus proposal, and send the consensus proposal and the signature of node n1 on the consensus proposal to other consensus nodes (i.e., node n2-node n4) for generating blocks. The consensus proposal may include information such as the transaction body of the multiple transactions and the submission order of the multiple transactions. In the preparation stage, each slave node can sign the consensus proposal and send it to each other node. Assuming that node n4 is a malicious node, node n1, node n2, and node n3 can determine that the preparation phase is completed and can enter the submission phase after receiving the signatures of 2f=2 other consensus nodes on the consensus proposal. For example, as shown in Figure 2, after node n1 receives the signatures of node n2 and node n3, it verifies that the signatures of node n2 and node n3 are correct signatures on the consensus proposal, and then determines that the preparation phase is completed. After node n2 receives the signature of node n3 and the signature of node n1 in the preparatory phase and verifies them, it determines that the preparation phase is completed. In the submission phase, each consensus node signs the consensus proposal in the submission phase and sends it to other consensus nodes. After receiving the signatures of 2f=2 other consensus nodes in the submission phase, each consensus node can determine that the submission phase is completed and the consensus is successful. For example, after receiving and verifying the signatures of the submission phase of nodes n2 and n3, node n1 determines that the submission phase is completed, so that node n1 can execute the multiple transactions according to the consensus proposal, generate and store blocks (such as block N) including the multiple transactions, update the world state according to the execution results of the multiple transactions, and return the execution results of the multiple transactions to the user device. Similarly, after determining that the submission phase is completed, nodes n2 and n3 execute the multiple transactions, update the world state according to the execution results of the multiple transactions, and generate and store block N. Through the above process, the storage consistency of nodes n1, n2, and n3 is achieved. In other words, nodes n1-n4 can still achieve consensus on the consensus proposal successfully and complete the execution of the block in the presence of a malicious node.
图3是相关技术中的共识节点的区块链数据存储的结构示意图。在图3所示的区块链 数据存储中,每一区块的区块头包括若干字段,例如上一区块哈希previous_Hash(图中的Prev Hash),随机数Nonce(在一些区块链***中这个Nonce不是随机数,或者在一些区块链***中不启用区块头中的Nonce),时间戳Timestamp,区块号Block Num,状态树根哈希State_Root,交易树根哈希Transaction_Root,收据树根哈希Receipt_Root等。其中,下一区块(如区块N+1)的区块头中的Prev Hash指向上一区块(如区块N),即为上一区块的区块hash值(即区块头的哈希值)。通过这种方式,区块链上通过区块头实现了下一区块对上一区块的锁定。特别的,如前所述,state_root是当前区块中所有账户的状态组成的状态树(state trie)的根的哈希值,该状态树例如为MPT树(Merkle Patricia Tree)。FIG3 is a schematic diagram of the structure of the blockchain data storage of the consensus node in the related art. In the blockchain data storage shown in FIG3, the block header of each block includes several fields, such as the previous block hash previous_Hash (Prev Hash in the figure), the random number Nonce (in some blockchain systems, this Nonce is not a random number, or in some blockchain systems, the Nonce in the block header is not enabled), the timestamp Timestamp, the block number Block Num, the state tree root hash State_Root, the transaction tree root hash Transaction_Root, the receipt tree root hash Receipt_Root, etc. Among them, the Prev Hash in the block header of the next block (such as block N+1) points to the previous block (such as block N), which is the block hash value of the previous block (i.e., the hash value of the block header). In this way, the next block on the blockchain is locked to the previous block through the block header. In particular, as mentioned above, state_root is the hash value of the root of the state trie consisting of the states of all accounts in the current block, such as the Merkle Patricia Tree (MPT Tree).
MPT树是结合了Merkle Tree(默克尔树)和Patricia Tree(压缩前缀树,一种更节省空间的Trie树,字典树)的一种树形结构。Merkle Tree算法对每个叶子节点都计算一个Hash(哈希)值,然后两两连接再次计算Hash,一直到最顶层的Merkle根。以太坊中采用改进的MPT树,MPT树例如是16叉树的结构。The MPT tree is a tree structure that combines the Merkle tree and the Patricia tree (a compressed prefix tree, a more space-saving Trie tree, a dictionary tree). The Merkle Tree algorithm calculates a hash value for each leaf node, and then connects two nodes to calculate the hash again until the top Merkle root. Ethereum uses an improved MPT tree, which is a 16-way tree structure.
状态树中包含以太坊网络中每个账户所对应的存储内容的键值对(key and value pair)。状态树中的“键”可以是一个160位的标识符(以太坊账户的地址),这个账户地址中包含的字符分布于从状态树的根节点到叶子节点的路径中的各个节点中。参考图3中所示,MPT状态树的叶子节点(例如节点t4和节点t5)还包括各个账户的Value。其中,当账户为用户账户(又称为外部账户)时,例如图3中的账户A,账户的Value中包括计数器(Nonce)和余额(Balance)。当账户为合约账户时,例如图3中的账户B,账户的Value中包括计数器(Nonce)、余额(Balance)、合约代码哈希值(CodeHash)和存储树根哈希值(Storage_root)。其中,所述计数器,对于外部账户代表从账户地址发送的交易数量;对于合约账户,是账户创建的合约数量。The state tree contains key-value pairs (key and value pairs) of the storage content corresponding to each account in the Ethereum network. The "key" in the state tree can be a 160-bit identifier (the address of the Ethereum account), and the characters contained in this account address are distributed in each node in the path from the root node of the state tree to the leaf node. Referring to FIG3, the leaf nodes of the MPT state tree (such as node t4 and node t5) also include the Value of each account. Among them, when the account is a user account (also known as an external account), such as account A in FIG3, the Value of the account includes a counter (Nonce) and a balance (Balance). When the account is a contract account, such as account B in FIG3, the Value of the account includes a counter (Nonce), a balance (Balance), a contract code hash value (CodeHash) and a storage tree root hash value (Storage_root). Among them, the counter, for an external account, represents the number of transactions sent from the account address; for a contract account, it is the number of contracts created by the account.
状态树中的节点通过哈希进行连接,具体是,可以基于父节点的子节点中的数据生成哈希值,将该生成的哈希值存储在父节点中。图4为MPT树的结构示意图。假设图4中的标示“t2”的节点对应于图3中的状态树中的节点t2,标示“t4”的节点对应于图3中的状态树中的叶子节点t4。如图4所示,图4中的各个叶子节点中包括的状态分别表示为state1、state2、state3、state4,各个状态也即为各个账户的Value。图4中各个节点中的左侧框中的字符用于对账户进行索引,叶子节点到根节点之间的路径中的各个节点中包括的字符拼接起来即为该叶子节点对应的账户地址。例如,state1所在叶子节点到根节点之间的各个节点包括字符“f”、“5”和“324”,从而可以得到state1对应的账户地址为“f5324”。The nodes in the state tree are connected by hashing. Specifically, a hash value can be generated based on the data in the child node of the parent node, and the generated hash value is stored in the parent node. Figure 4 is a schematic diagram of the structure of the MPT tree. Assume that the node marked "t2" in Figure 4 corresponds to the node t2 in the state tree in Figure 3, and the node marked "t4" corresponds to the leaf node t4 in the state tree in Figure 3. As shown in Figure 4, the states included in each leaf node in Figure 4 are respectively represented as state1, state2, state3, and state4, and each state is also the Value of each account. The characters in the left box of each node in Figure 4 are used to index the account, and the characters included in each node in the path between the leaf node and the root node are concatenated to form the account address corresponding to the leaf node. For example, each node between the leaf node where state1 is located and the root node includes the characters "f", "5" and "324", so that the account address corresponding to state1 can be obtained as "f5324".
在图4中,包括“5”的节点的子节点中包括叶子节点,在计算该节点中包括的hash(324,74)时,可通过如下的公式(1)计算:In FIG4 , the child nodes of the node including “5” include leaf nodes. When calculating the hash (324, 74) included in the node, the following formula (1) can be used for calculation:
hash(324,74)=hash(hash(324,hash(state1)),hash(74,hash(a,c))) (1)hash(324,74)=hash(hash(324,hash(state1)),hash(74,hash(a,c))) (1)
也就是说,在计算图4中的叶子节点t4的哈希值hash(324,hash(state1)时,对节点t4中的“324”和state1的哈希值hash(state1)进行拼接,然后对拼接的数据计算哈希值,得到叶子节点的哈希值。在计算图4中的非叶子节点(例如包括“74”的节点)的哈希值hash(74,hash(a,c))时,对该节点中的数据直接拼接,然后对拼接得到的数据计算哈希值。可以理解,状态树中的节点的哈希值为基于节点的全部数据计算得到的哈希值,状态树中的非叶子节点、且非根节点的节点中包括的哈希值是对其全部子节点的哈希值拼接之后取哈希得到的哈希值。That is, when calculating the hash value hash(324, hash(state1) of the leaf node t4 in FIG4, "324" in the node t4 and the hash value hash(state1) of state1 are concatenated, and then the hash value of the concatenated data is calculated to obtain the hash value of the leaf node. When calculating the hash value hash(74, hash(a, c)) of the non-leaf node in FIG4 (for example, the node including "74"), the data in the node is directly concatenated, and then the hash value of the concatenated data is calculated. It can be understood that the hash value of the node in the state tree is a hash value calculated based on all the data of the node, and the hash value included in the node that is not a leaf node and a non-root node in the state tree is a hash value obtained by concatenating the hash values of all its child nodes and hashing them.
如此可在状态树中从下至上计算叶子节点与根节点之间的每个节点中包括的哈希值,从而最后可将计算得到的图3中的节点t2的哈希值与节点t3的哈希值拼接,并对拼接得到的数据取哈希,从而生成节点t1的哈希值。该节点t1的哈希值即为该状态树的状态根,记录在区块N的State_Root字段中。In this way, the hash value included in each node between the leaf node and the root node can be calculated from bottom to top in the state tree, so that the calculated hash value of node t2 in Figure 3 can be concatenated with the hash value of node t3, and the concatenated data is hashed to generate the hash value of node t1. The hash value of node t1 is the state root of the state tree, which is recorded in the State_Root field of block N.
在MPT树的一种变型中,可以包括分支节点,分支节点可以连接多个子节点,且分支节点中包括其连接的每个子节点中的数据的哈希值,即,分支节点中包括与多个主节点 分别对应的多个哈希值,叶子节点连接在分支节点之后。该变型中还包括扩展节点,扩展节点可连接于分支节点之前或之后,扩展节点具有一个子节点,扩展节点中包括与其连接的子节点中的全部数据的哈希值。在该MPT树变型中,同样地可基于各层节点递归得到根节点的哈希值。本说明书实施例方案也同样适用于该种MPT树变型。In a variation of the MPT tree, a branch node may be included, and the branch node may be connected to multiple child nodes, and the branch node includes the hash value of the data in each child node connected to it, that is, the branch node includes multiple hash values corresponding to multiple main nodes, and the leaf node is connected after the branch node. This variation also includes an extension node, which can be connected before or after the branch node, and the extension node has a child node, and the extension node includes the hash value of all data in the child nodes connected to it. In this MPT tree variation, the hash value of the root node can also be recursively obtained based on the nodes of each layer. The embodiment of this specification is also applicable to this MPT tree variation.
智能合约在区块链上完成部署后,会产生一个对应的合约账户。这个合约账户一般会具有一些状态,这些状态由智能合约中的状态变量所定义、并在智能合约创建、执行时产生新的值。如图3所示,合约的相关状态保存在存储树(storage trie)中,图3中示意示出了账户B对应的合约的存储树。存储树根节点st1的hash值即存储于上述storage_root中,从而将该合约的所有状态通过根hash锁定到状态树中该合约账户的Value(即账户状态)下。存储树也可以具有MPT树形结构,与图4所示状态树类似地,从根节点到叶子节点的路径中的每个节点可包括用于寻址变量名的字符,叶子节点中存储有变量的Value,从而存储树中存储了变量名(也可以称为状态地址)到状态值的key-value映射。例如,参考图3中的存储树,该存储树的叶子节点st2、st3例如包括变量a的Value、变量b的Value等,以变量a为例,在存储树中的根节点到叶子节点st2的节点路径中的各个节点包括的字符构成变量a的变量名称,该变量名称可以类似地由16进制字符构成。After the smart contract is deployed on the blockchain, a corresponding contract account will be generated. This contract account generally has some states, which are defined by the state variables in the smart contract and generate new values when the smart contract is created and executed. As shown in Figure 3, the relevant states of the contract are stored in the storage trie, and Figure 3 schematically shows the storage trie of the contract corresponding to account B. The hash value of the root node st1 of the storage tree is stored in the above storage_root, so that all states of the contract are locked to the Value (i.e., account state) of the contract account in the state tree through the root hash. The storage tree can also have an MPT tree structure. Similar to the state tree shown in Figure 4, each node in the path from the root node to the leaf node can include characters for addressing the variable name, and the leaf node stores the value of the variable, so that the key-value mapping from the variable name (also called the state address) to the state value is stored in the storage tree. For example, referring to the storage tree in Figure 3, the leaf nodes st2 and st3 of the storage tree include the Value of variable a, the Value of variable b, etc. Taking variable a as an example, the characters included in each node in the node path from the root node to the leaf node st2 in the storage tree constitute the variable name of variable a, and the variable name can similarly be composed of hexadecimal characters.
其中,对存储树中的各个节点的哈希值的计算可参考对状态树中的节点的哈希值计算方法。具体是,在计算存储树中的叶子节点的哈希值时,对该叶子节点中包括的部分key和叶子节点中的状态的哈希值进行拼接,然后对拼接的数据计算哈希值,得到叶子节点的哈希值。在计算存储树中的非叶子节点且非根节点的节点的哈希值时,对该节点中的数据直接拼接,然后对拼接得到的数据计算哈希值,得到该节点的哈希值。Among them, the calculation of the hash value of each node in the storage tree can refer to the method for calculating the hash value of the node in the state tree. Specifically, when calculating the hash value of a leaf node in the storage tree, the hash value of the partial key included in the leaf node and the state in the leaf node are spliced, and then the hash value of the spliced data is calculated to obtain the hash value of the leaf node. When calculating the hash value of a node that is not a leaf node and a non-root node in the storage tree, the data in the node is directly spliced, and then the hash value of the spliced data is calculated to obtain the hash value of the node.
概括地说,FVP节点中包括树状的状态数据,该状态数据的叶子节点中包括账户或合约变量的状态,状态数据中的从根节点到叶子节点的路径中的各个节点包括所述状态的key,所述状态数据中的父节点中包括基于其子节点中的数据计算得到的哈希值。In general, the FVP node includes tree-like state data, the leaf nodes of which include the state of the account or contract variable, each node in the path from the root node to the leaf node in the state data includes the key of the state, and the parent node in the state data includes a hash value calculated based on the data in its child nodes.
仍参考图3,区块链中的节点在执行完成区块N之后,进行对下一批交易的共识,并在共识通过之后执行区块N+1,从而与执行区块N类似地生成与区块N+1对应的状态数据,该状态数据包括状态树及各个合约对应的存储树。其中,区块N+1的状态数据与区块N的状态数据重复的数据可以引用区块N中的数据,而不需要重复存储。如此,在每个共识节点都存储完整的区块数据和状态数据的情况下,需要占用较大的存储空间。Still referring to Figure 3, after executing block N, the nodes in the blockchain reach a consensus on the next batch of transactions, and execute block N+1 after the consensus is passed, thereby generating state data corresponding to block N+1 similarly to the execution of block N, and the state data includes a state tree and storage trees corresponding to each contract. Among them, the data of the state data of block N+1 that is repeated with the state data of block N can refer to the data in block N without repeated storage. In this way, when each consensus node stores complete block data and state data, a large storage space is required.
本说明书实施例提供一种轻共识节点(Light Validating Peer,LVP),LVP中仅保存部分状态数据,例如,保存状态树和存储树中的哈希值数据,而不保存状态树和存储树中的各个账户或变量的Value(即各个状态),同时区块链中还包括与相关技术中的共识节点相同的全共识节点(Full Validating Peer,FVP)。图5为本说明书实施例中的LVP中的状态哈希值树和存储哈希值树的示意图。如图5所示,在LVP中的状态哈希值树和存储哈希值树中,与图3中的FVP中的状态树和存储树相比,将状态树和存储树中的叶子节点中的状态替换为了该状态的哈希值,例如,将状态树中的节点t4中的state1替换为状态哈希值树的节点t4中的hash(state1),将存储树中的节点st2中的state5替换为存储哈希值树中节点st2中的hash(state5)。图6为图5中的状态哈希值树的示意图。如图6中所示,在状态哈希值树中,叶子节点中包括账户地址的末尾字符、及状态树中的对应的叶子节点的状态哈希值。如,状态哈希值树中的叶子节点t4中包括状态树中的叶子节点t4中“state1”的hash(state1)。状态哈希值树中的除叶子节点和根节点之外的各个节点中包括的哈希值可使用与状态树中相同的计算方法生成。例如,图6中的包括“5”的节点中的hash(324,74)可通过上述公式(1)计算得到。存储哈希值树也可以具有与图6所示的结构类似的结构。通过如此,图5中的状态哈希值树和存储哈希值树中除了叶子节点以外的其他节点包括的数据与图3中的状态树和存储树中的对应节点是一致的,因此图5中的节点t1的根哈希值与图3中的节点t1的根哈希值一致。The embodiment of this specification provides a light consensus node (Light Validating Peer, LVP), in which only part of the state data is saved, for example, the hash value data in the state tree and the storage tree is saved, but the Value (i.e., each state) of each account or variable in the state tree and the storage tree is not saved. At the same time, the blockchain also includes a full consensus node (Full Validating Peer, FVP) that is the same as the consensus node in the related art. FIG5 is a schematic diagram of the state hash value tree and the storage hash value tree in the LVP in the embodiment of this specification. As shown in FIG5, in the state hash value tree and the storage hash value tree in the LVP, compared with the state tree and the storage tree in the FVP in FIG3, the state in the leaf node in the state tree and the storage tree is replaced with the hash value of the state, for example, state1 in node t4 in the state tree is replaced with hash(state1) in node t4 in the state hash value tree, and state5 in node st2 in the storage tree is replaced with hash(state5) in node st2 in the storage hash value tree. FIG6 is a schematic diagram of the state hash value tree in FIG5. As shown in Figure 6, in the state hash value tree, the leaf node includes the last character of the account address and the state hash value of the corresponding leaf node in the state tree. For example, the leaf node t4 in the state hash value tree includes the hash (state1) of "state1" in the leaf node t4 in the state tree. The hash values included in each node other than the leaf node and the root node in the state hash value tree can be generated using the same calculation method as in the state tree. For example, the hash (324, 74) in the node including "5" in Figure 6 can be calculated by the above formula (1). The storage hash value tree can also have a structure similar to the structure shown in Figure 6. In this way, the data included in the state hash value tree and the storage hash value tree other than the leaf node in Figure 5 is consistent with the corresponding nodes in the state tree and storage tree in Figure 3, so the root hash value of the node t1 in Figure 5 is consistent with the root hash value of the node t1 in Figure 3.
图5和图6中所示的状态哈希值树和存储哈希值树可用于对从FVP接收的读集进行验证,因此,可将这些数据统称为验证数据。可以理解,验证数据不限于包括如图5或图6所示的结构,例如,为了对读集进行验证,验证数据中可至少包括状态树和存储树中各个叶子节点的状态的哈希值。对于上述MPT树变型,仅需要将MPT树变型中的叶子节点中的状态删除,即可以将经过该删除后的哈希值树用作为LVP节点中的验证数据。下文将以图3-图6所示的状态数据和验证数据作为示例描述本说明书实施例中的共识和交易执行方案。The state hash value tree and storage hash value tree shown in Figures 5 and 6 can be used to verify the read set received from the FVP, so these data can be collectively referred to as verification data. It can be understood that the verification data is not limited to including the structure shown in Figure 5 or Figure 6. For example, in order to verify the read set, the verification data may at least include the hash value of the state of each leaf node in the state tree and the storage tree. For the above-mentioned MPT tree variant, it is only necessary to delete the state in the leaf node in the MPT tree variant, that is, the hash value tree after the deletion can be used as the verification data in the LVP node. The following will use the state data and verification data shown in Figures 3-6 as examples to describe the consensus and transaction execution scheme in the embodiments of this specification.
在基于FVP和LVP的区块链***中,通过本说明书实施例提供的交易执行方案,LVP可参与交易执行,并基于交易执行结果更新本地存储的哈希值数据,如此可大大节省LVP中的存储资源,减少了区块链***的存储成本。In a blockchain system based on FVP and LVP, through the transaction execution solution provided in the embodiments of this specification, LVP can participate in transaction execution and update the locally stored hash value data based on the transaction execution results, which can greatly save storage resources in LVP and reduce the storage cost of the blockchain system.
图7为本说明书实施例中的交易执行方法的流程图。该方法可由区块链***中的作为主节点的FVP(图7中以FVP示意示出)及一个或多个LVP执行,图7中示出一个LVP作为示例。其中,区块链***中可包括至少一个FVP,该至少一个FVP可共同确定一个FVP作为主节点,区块链***中的除主节点之外的节点为从节点。主节点可发起共识提议,以与从节点一起进行对该共识提议的共识。FIG7 is a flow chart of a transaction execution method in an embodiment of the present specification. The method may be executed by a FVP (schematically shown as an FVP in FIG7 ) and one or more LVPs as a master node in a blockchain system, and FIG7 shows an LVP as an example. Among them, the blockchain system may include at least one FVP, and the at least one FVP may jointly determine an FVP as a master node, and nodes other than the master node in the blockchain system are slave nodes. The master node may initiate a consensus proposal to reach a consensus on the consensus proposal together with the slave nodes.
如图7所示,首先,在步骤S701,区块链***中的共识节点进行对共识提议的共识。As shown in FIG. 7 , first, in step S701 , the consensus nodes in the blockchain system reach a consensus on the consensus proposal.
假设区块链***中的FVP1为主节点,下文中以FVP1作为示例进行描述。FVP1可以从用户客户端或者其他FVP接收用户发送的交易。该交易可以为转账交易,或者可以为调用合约的交易等。FVP1在接收到一定量的交易之后,可以在接收到的交易中选出多个交易进行共识,以用于生成新的区块。Assuming that FVP1 in the blockchain system is the master node, FVP1 is used as an example in the following description. FVP1 can receive transactions sent by users from user clients or other FVPs. The transaction can be a transfer transaction, or a transaction that calls a contract, etc. After receiving a certain amount of transactions, FVP1 can select multiple transactions from the received transactions for consensus to generate a new block.
FVP1首先生成共识提议,该共识提议中包括该多个交易的排列顺序,以用于对该多个交易进行定序。具体是,共识提议中可包括所述多个交易的交易列表,所述交易列表中包括顺序排列的所述多个交易各自的交易体。或者,所述共识提议中可包括所述多个交易的交易哈希值的列表,在该种实施方式中,主节点可通过广播将各个交易广播给各个其它共识节点,通过这样可减少共识提议的数据量,从而减少共识过程中的需要签名的数据量,加速共识过程。区块链中的各个共识节点在接收到共识提议之后,例如可通过图2所示的共识过程对该共识提议进行共识,在此不再赘述。FVP1 first generates a consensus proposal, which includes the arrangement order of the multiple transactions for sequencing the multiple transactions. Specifically, the consensus proposal may include a transaction list of the multiple transactions, and the transaction list includes the transaction bodies of the multiple transactions arranged in sequence. Alternatively, the consensus proposal may include a list of transaction hash values of the multiple transactions. In this embodiment, the master node can broadcast each transaction to each other consensus node through broadcasting, which can reduce the amount of data in the consensus proposal, thereby reducing the amount of data that needs to be signed during the consensus process and accelerating the consensus process. After receiving the consensus proposal, each consensus node in the blockchain can, for example, reach consensus on the consensus proposal through the consensus process shown in Figure 2, which will not be repeated here.
在步骤S703,FVP向LVP发送多个交易的读集中的状态。In step S703, the FVP sends the read-set status of multiple transactions to the LVP.
在一种实施方式中,FVP1在选出多个交易之后,可通过预执行所述多个交易而获取该多个交易对应的读集。FVP1可按照多个交易的预设的排列顺序预执行多个交易,或者FVP1可根据各个交易的接收顺序预执行多个交易,并根据各个交易的预执行顺序确定共识提议中的该多个交易的排列顺序。In one embodiment, after selecting multiple transactions, FVP1 may obtain read sets corresponding to the multiple transactions by pre-executing the multiple transactions. FVP1 may pre-execute the multiple transactions according to a preset arrangement order of the multiple transactions, or FVP1 may pre-execute the multiple transactions according to the order in which each transaction is received, and determine the arrangement order of the multiple transactions in the consensus proposal according to the pre-execution order of each transaction.
FVP1在预执行多个交易时,当首次读取账户或合约变量的value时,从状态数据中进行读取,并根据该首次读取账户或合约变量的value生成该多个交易的读集。同时,FVP1缓存首次读取的账户或合约变量的value,当在对多个交易的预执行中对这些首次读取账户或合约变量的value进行更新时,在缓存中更新这些账户或合约变量的value,当在预执行多个交易中再次读取这些账户或合约变量的value时,则读取缓存中的这些账户或合约变量的value,其中,再次读取的这些账户或合约变量的value不需要写入该多个交易的读集中。When FVP1 reads the value of an account or contract variable for the first time during the pre-execution of multiple transactions, it reads it from the state data and generates a read set of the multiple transactions based on the value of the account or contract variable read for the first time. At the same time, FVP1 caches the value of the account or contract variable read for the first time. When the value of these first-read account or contract variables is updated during the pre-execution of multiple transactions, the value of these account or contract variables is updated in the cache. When the value of these account or contract variables is read again during the pre-execution of multiple transactions, the value of these account or contract variables in the cache is read, wherein the value of these account or contract variables read again does not need to be written into the read set of the multiple transactions.
该读集包括根据该多个交易包括的读操作从状态数据中读取的账户和/或合约变量的状态,该读集也即为该多个交易在被执行时需要从状态数据中读取的账户和/或合约变量的状态,其中,状态数据例如包括图3中所示的状态树和存储树。The read set includes the status of the account and/or contract variables read from the state data according to the read operations included in the multiple transactions. The read set is also the status of the account and/or contract variables that need to be read from the state data when the multiple transactions are executed, wherein the state data, for example, includes the state tree and storage tree shown in Figure 3.
在一种实施方式中,FVP1可以获取多个交易各自的读集,然后可以对各个交易的读集进行合并,也即从多个交易各自的读集中选取在首次读取各个变量(包括账户和合约变量)时从状态数据中读取的该变量的键值对,从而得到多个交易对应的读集。假设所述多 个交易中的一个交易包括对账户A的余额的更新(例如减少预设金额),该交易在执行时需要首先读取账户A的value(即包括Nonce和Balance),然后根据读取的账户A的value获取账户A的新的value,例如,根据该交易对Nonce值加1,对Balance值减少预设金额,得到账户A的更新的Nonce值和Balance值,其构成了账户A的更新的Value。从而,该交易的读集包括读取的账户A的键值对,该交易的写集包括写入的账户A的键值对。则该多个交易的读集中包括从状态数据读取的账户A的Key-Value键值对,其中Key为账户A的账户地址,Value为账户A的状态,该状态中包括账户A对应的叶子节点中的Nonce值和Balance值。In one embodiment, FVP1 can obtain the read sets of multiple transactions, and then merge the read sets of each transaction, that is, select the key-value pairs of the variables read from the state data when reading each variable (including account and contract variables) for the first time from the read sets of multiple transactions, so as to obtain the read sets corresponding to the multiple transactions. Assuming that one of the multiple transactions includes an update to the balance of account A (for example, reducing a preset amount), the transaction needs to first read the value of account A (that is, including Nonce and Balance) when executing, and then obtain the new value of account A according to the read value of account A. For example, according to the transaction, the Nonce value is added by 1, and the Balance value is reduced by a preset amount to obtain the updated Nonce value and Balance value of account A, which constitute the updated Value of account A. Therefore, the read set of the transaction includes the key-value pairs of account A read, and the write set of the transaction includes the key-value pairs of account A written. The read set of the multiple transactions includes the Key-Value pair of account A read from the status data, where the Key is the account address of account A, and the Value is the status of account A, which includes the Nonce value and Balance value in the leaf node corresponding to account A.
假设该多个交易中的一个交易包括对账户B对应的合约中的变量a的更新操作,由于对变量a的写入会导致对账户B中的Storage_root的更新,因此,该交易也包括对账户B的写入操作。为了对账户B和变量a进行写入,该交易的读集中需要包括账户B的Key-Value键值对和变量a的键值对。假设该交易对账户B和变量a的读取为首次从状态数据读取的情况,则多个交易的读集中也包括基于该交易从状态数据中读取的账户B的键值对和变量a的键值对。其中,账户B的Key-Value键值对中的key为账户B的账户地址,Value为账户B的状态,该状态中包括账户B对应的叶子节点中的Nonce、Balance、CodeHash和Storage_root各个字段的值。变量a的Key-Value键值对中的key为变量a的变量名称,Value为变量a的状态值。根据该多个交易的读集,当在执行该交易中对账户B进行写入时,可以根据变量a的更新的value计算更新的Storage_root,并与读集中的账户B的Nonce、Balance、CodeHash合并,得到账户B的更新的value,该变量a的更新的value和账户B的更新的value将记录在该交易的写集中,以用于更新状态数据。Assume that one of the multiple transactions includes an update operation on variable a in the contract corresponding to account B. Since writing to variable a will result in an update to Storage_root in account B, the transaction also includes a write operation on account B. In order to write to account B and variable a, the read set of the transaction needs to include the Key-Value pair of account B and the key-value pair of variable a. Assuming that the reading of account B and variable a by the transaction is the first reading from the state data, the read sets of multiple transactions also include the key-value pair of account B and the key-value pair of variable a read from the state data based on the transaction. Among them, the key in the Key-Value pair of account B is the account address of account B, and the Value is the state of account B, which includes the values of the Nonce, Balance, CodeHash and Storage_root fields in the leaf node corresponding to account B. The key in the Key-Value pair of variable a is the variable name of variable a, and the Value is the state value of variable a. According to the read sets of the multiple transactions, when writing to account B in the execution of the transaction, the updated Storage_root can be calculated according to the updated value of variable a and merged with the Nonce, Balance, and CodeHash of account B in the read set to obtain the updated value of account B. The updated value of variable a and the updated value of account B will be recorded in the write set of the transaction for updating the status data.
FVP1在如上所述生成所述多个交易的读集之后,可将所述读集发送给各个LVP。FVP1可将读集与共识提议一起发送给各个LVP。从而各个LVP可并行地进行对共识提议的共识和对读集的验证,提高了***效率。After generating the read sets of the multiple transactions as described above, FVP1 may send the read sets to each LVP. FVP1 may send the read sets together with the consensus proposal to each LVP. Thus, each LVP may perform consensus on the consensus proposal and verification of the read sets in parallel, thereby improving system efficiency.
在另一种实施方式中,LVP在接收到共识提议之后,可以对共识提议涉及的多个交易进行静态分析,分析交易的交易体以及交易中调用的合约的合约代码,从而确定各个交易在执行时需要读取的账户和/或变量名称,即所述多个交易的读集中的key。之后,LVP可根据所得到的读集中的key从一个或多个FVP请求所述key对应的状态。在LVP从多个FVP请求读集的状态的情况中,LVP可并行从多个FVP请求不同的状态,从而可提高获取读集的效率。LVP在从FVP获取到读集中的全部状态之后,根据从FVP获取的状态生成该多个交易对应的读集。In another embodiment, after receiving the consensus proposal, LVP may perform static analysis on multiple transactions involved in the consensus proposal, analyze the transaction body of the transaction and the contract code of the contract called in the transaction, so as to determine the account and/or variable name that each transaction needs to read when executing, that is, the key in the read set of the multiple transactions. Afterwards, LVP may request the state corresponding to the key from one or more FVPs based on the key in the obtained read set. In the case where LVP requests the state of the read set from multiple FVPs, LVP may request different states from multiple FVPs in parallel, thereby improving the efficiency of obtaining the read set. After obtaining all the states in the read set from the FVP, LVP generates the read set corresponding to the multiple transactions based on the state obtained from the FVP.
在步骤S705,LVP基于验证数据验证读集是否正确。In step S705, the LVP verifies whether the read set is correct based on the verification data.
在一种实施方式中,LVP中存储了图3中的状态树和存储树中的各个状态的哈希值、以及到该哈希值的索引数据(例如账户地址或变量名称)作为验证数据。LVP在如上所述获取多个交易的读集之后,可使用各个状态的哈希值对读集中的各个状态进行验证。例如,读集中包括账户A的Value,LVP可从验证数据中获取账户A的状态哈希值,使用该状态哈希值对账户A的Value进行验证,即验证读集中的账户A的Value与本地存储的账户A的状态哈希值是否对应,如果对应,则可确定读集中的账户A的Value为正确的状态。在读集中包括账户B的Value和变量a的Value的情况下,LVP可从验证数据中获取账户B的状态哈希值和变量a的状态哈希值,以分别对读集中的账户B的Value和变量a的Value进行验证。In one embodiment, the state tree in FIG. 3 and the hash value of each state in the storage tree, as well as the index data to the hash value (such as an account address or a variable name) are stored in LVP as verification data. After obtaining the read sets of multiple transactions as described above, LVP can use the hash values of each state to verify each state in the read set. For example, the read set includes the Value of account A. LVP can obtain the state hash value of account A from the verification data and use the state hash value to verify the Value of account A, that is, verify whether the Value of account A in the read set corresponds to the state hash value of account A stored locally. If so, it can be determined that the Value of account A in the read set is the correct state. In the case where the read set includes the Value of account B and the Value of variable a, LVP can obtain the state hash value of account B and the state hash value of variable a from the verification data to verify the Value of account B and the Value of variable a in the read set, respectively.
在另一种实施方式中,LVP中存储了如图5所示的状态哈希值树和存储哈希值树作为验证数据。LVP在从共识提议中获取读集之后,可基于状态哈希值树和存储哈希值树对读集中的各个状态进行简单支付验证(Simplified Payment Verification,SPV)。例如,读集中包括账户A的Value,LVP可计算读集中的账户A的Value的哈希值(例如hash1),基于状态哈希值树中的其他叶子节点的值(即状态哈希值)与hash1向上层层计算各个节 点的哈希值,直到计算状态哈希值树的根哈希值(例如root1),确定root1与LVP中存储的状态哈希值树的根哈希值是否一致,如果一致,则认为该读集中的账户A的Value为正确的。在读集中包括账户B的Value和变量a的Value的情况下,LVP可类似地基于状态哈希值树和存储哈希值树对账户B的Value和变量a的Value进行spv验证。In another embodiment, the state hash value tree and storage hash value tree as shown in FIG5 are stored in LVP as verification data. After obtaining the read set from the consensus proposal, LVP can perform Simplified Payment Verification (SPV) on each state in the read set based on the state hash value tree and the storage hash value tree. For example, the read set includes the Value of account A. LVP can calculate the hash value (e.g., hash1) of the Value of account A in the read set, and calculate the hash value of each node layer by layer based on the values of other leaf nodes in the state hash value tree (i.e., the state hash value) and hash1 until the root hash value of the state hash value tree (e.g., root1) is calculated, and it is determined whether root1 is consistent with the root hash value of the state hash value tree stored in LVP. If they are consistent, the Value of account A in the read set is considered to be correct. In the case where the read set includes the Value of account B and the Value of variable a, LVP can similarly perform SPV verification on the Value of account B and the Value of variable a based on the state hash value tree and the storage hash value tree.
在一种实施方式中,LVP在从FVP1接收到共识提议和多个交易的读集之后,可在对共识提议进行共识的同时,并行地基于验证数据对读集进行验证。或者,LVP在接收到共识提议、且根据共识提议从FVP获取到所述多个交易的读集之后,由于共识过程较长,LVP在获取到多个交易的读集之后,可能共识过程还未结束,因此LVP也可以在对共识提议进行共识的同时,并行地基于验证数据对读集进行验证。In one embodiment, after receiving the consensus proposal and the read sets of multiple transactions from FVP1, LVP can verify the read sets based on the verification data in parallel while reaching consensus on the consensus proposal. Alternatively, after LVP receives the consensus proposal and obtains the read sets of the multiple transactions from FVP according to the consensus proposal, since the consensus process is long, the consensus process may not be completed after LVP obtains the read sets of multiple transactions. Therefore, LVP can also verify the read sets based on the verification data in parallel while reaching consensus on the consensus proposal.
在一种实施方式中,在LVP中存储有与上述MPT树变型对应的验证数据时,由于该验证数据中类似地包括MPT树变型中的各个状态的哈希值,并且验证数据中的各层节点通过哈希进行连接,因此,可类似地基于该验证数据对读集进行验证,在此不再赘述。In one embodiment, when verification data corresponding to the above-mentioned MPT tree variant is stored in the LVP, since the verification data similarly includes hash values of each state in the MPT tree variant, and each layer of nodes in the verification data is connected by hash, the read set can be similarly verified based on the verification data, which will not be repeated here.
除此之外,LVP中还可以存储有各个区块的区块头,如图3中所示,区块头中可以包括状态树的根哈希值、交易树的根哈希值和收据树的根哈希值,区块头可用于对交易、收据等数据进行spv验证,并可用于生成下一个区块的区块头。In addition, the block headers of each block can also be stored in LVP. As shown in Figure 3, the block header can include the root hash value of the state tree, the root hash value of the transaction tree, and the root hash value of the receipt tree. The block header can be used to perform SPV verification on transaction, receipt and other data, and can be used to generate the block header of the next block.
在步骤S707,LVP根据读集执行多个交易。In step S707 , the LVP executes multiple transactions according to the read set.
在对共识提议共识成功、且LVP对所述读集的验证通过之后,LVP可基于读集中的状态执行共识提议中的多个交易。具体是,LVP在执行交易的过程中需要读取账户或变量的状态时,如果是对该账户或变量的首次读取,可从该读集中找到账户或变量的状态,基于该账户或变量的状态进行对该交易的执行,根据该交易中的对账户或合约变量的写操作,得到该交易的写集,该写集中包括账户的键值对或合约账户和合约变量的键值对,用于更新状态数据中的状态。LVP在从读集中读取账户或合约变量的状态之后,可以缓存该状态,并在执行对该账户或合约变量的写入时,在缓存中更新该账户或合约变量的状态,以用于后续在执行交易过程中的对该账户或合约变量的状态的读取。由于该读集中的账户或变量的状态已经经过验证,即为该账户或变量当前的正确状态,因此,基于读集中的状态执行交易得到的执行结果与FVP基于状态数据中的状态执行交易得到的执行结果一致。After the consensus proposal is successfully reached and the LVP passes the verification of the read set, the LVP can execute multiple transactions in the consensus proposal based on the status in the read set. Specifically, when the LVP needs to read the status of an account or variable in the process of executing a transaction, if it is the first time to read the account or variable, the status of the account or variable can be found from the read set, and the transaction is executed based on the status of the account or variable. According to the write operation on the account or contract variable in the transaction, the write set of the transaction is obtained, and the write set includes the key-value pair of the account or the key-value pair of the contract account and the contract variable, which is used to update the status in the status data. After reading the status of the account or contract variable from the read set, the LVP can cache the status, and when executing the write to the account or contract variable, update the status of the account or contract variable in the cache, so as to be used for the subsequent reading of the status of the account or contract variable in the process of executing the transaction. Since the status of the account or variable in the read set has been verified, that is, it is the current correct status of the account or variable, the execution result obtained by executing the transaction based on the status in the read set is consistent with the execution result obtained by FVP executing the transaction based on the status in the status data.
具体是,假设如上文所述多个交易中的一个交易包括对账户A的余额的更新,LVP首先从多个交易的读集中读取账户A的value(假设读取的value为V1),根据该交易对V1进行更新,从而得到账户A的更新的value(假设该value为V2),其中V2中包括更新的Nonce值和更新的Balance值,从而可在该交易的写集中写入账户A的更新的键值对。Specifically, assuming that one of the multiple transactions described above includes an update to the balance of account A, LVP first reads the value of account A from the read set of multiple transactions (assuming the read value is V1), and updates V1 according to the transaction to obtain the updated value of account A (assuming the value is V2), where V2 includes the updated Nonce value and the updated Balance value, so that the updated key-value pair of account A can be written in the write set of the transaction.
假设如上文所述,多个交易中的一个交易包括对账户B对应的合约的变量a的写入,LVP首先从多个交易的读集中读取账户B的value(假设为V3)和变量a的value(假设为V4),根据该交易对V4进行处理,得到变量a的更新的value(假设为V5),计算V5的哈希值,代入图5中的存储哈希值树,计算根节点st1的哈希值,以根节点st1的哈希值作为账户B的更新的storage_root,结合该交易的读集中的账户B的Nonce、Balance和CodeHash,计算出账户B的更新的value(假设为V6),从而可在该交易的写集中包括账户B的更新的键值对和变量a的更新的键值对。Assuming that as described above, one of the multiple transactions includes the writing of variable a of the contract corresponding to account B, LVP first reads the value of account B (assumed to be V3) and the value of variable a (assumed to be V4) from the read set of multiple transactions, processes V4 according to the transaction, obtains the updated value of variable a (assumed to be V5), calculates the hash value of V5, substitutes it into the storage hash value tree in Figure 5, calculates the hash value of the root node st1, and uses the hash value of the root node st1 as the updated storage_root of account B. Combined with the Nonce, Balance and CodeHash of account B in the read set of the transaction, the updated value of account B (assumed to be V6) is calculated, so that the updated key-value pair of account B and the updated key-value pair of variable a can be included in the write set of the transaction.
在LVP根据读集执行多个交易的同时,FVP1如果在先前已经预执行多个交易,由于如前文所述,FVP1预执行该多个交易的顺序与共识提议中的多个交易的排列顺序对应,因此FVP1在预执行多个交易时对状态的读取、更新和写入与执行多个交易时一致,从而,可以将预执行多个交易得到的写集用作为执行所述多个交易的写集,并根据该写集得到多个交易的收据。FVP1如果在先前未预执行多个交易,则可以根据所述读集、或者通过从状态数据中读取状态,而按照共识提议中的多个交易的排列顺序来执行该多个交易。上述两种方式中,FVP1中得到的多个交易的写集和收据与LVP执行多个交易的写集和收据是一致的。While LVP is executing multiple transactions according to the read set, if FVP1 has previously pre-executed multiple transactions, since, as mentioned above, the order in which FVP1 pre-executes the multiple transactions corresponds to the arrangement order of the multiple transactions in the consensus proposal, the reading, updating, and writing of the state by FVP1 when pre-executing multiple transactions are consistent with those when executing multiple transactions, so that the write set obtained by pre-executing multiple transactions can be used as the write set for executing the multiple transactions, and the receipts of the multiple transactions can be obtained based on the write set. If FVP1 has not previously pre-executed multiple transactions, the multiple transactions can be executed according to the read set or by reading the state from the state data in the arrangement order of the multiple transactions in the consensus proposal. In the above two methods, the write set and receipts of the multiple transactions obtained in FVP1 are consistent with the write set and receipts of the multiple transactions executed by LVP.
可选地,区块链***中的各个共识节点(包括FVP和LVP)完成对所述多个交易的执行之后,可对多个交易的执行结果进行共识。Optionally, after each consensus node (including FVP and LVP) in the blockchain system completes the execution of the multiple transactions, it can reach a consensus on the execution results of the multiple transactions.
共识节点可类似地通过图2所示的共识过程进行对多个交易的执行结果的共识。具体是,各个共识节点在执行多个交易得到各个交易的写集和收据之后,可根据多个交易的交易体、各个交易的写集和收据计算该多个交易对应的状态树根哈希值、交易树根哈希值和收据树根哈希值。基于该多个交易对应的状态树根哈希值、交易树根哈希值、收据树根哈希值、以及上一个区块的区块哈希(即区块头哈希值,如图3中的Prev Hash所示)计算该多个交易对应的区块(区块B1)的区块哈希(即区块B1的区块头哈希值)。FVP1可在PP阶段向其他共识节点发送共识提议,该共识提议中包括区块B1的区块哈希。LVP在接收到该共识提议之后,可比较从FVP1接收的区块哈希与自己计算的区块B1的区块哈希是否一致,如果一致,则对该区块哈希进行签名并发送给其他各个共识节点。如此在完成图3中的PP阶段、P阶段和C阶段之后,完成对区块哈希的共识。在共识节点完成对区块哈希的共识之后,从而可保证各个共识节点对多个交易的执行结果一致,从而各个节点可根据多个交易的执行结果更新存储。The consensus nodes can similarly reach consensus on the execution results of multiple transactions through the consensus process shown in FIG2. Specifically, after executing multiple transactions and obtaining the write sets and receipts of each transaction, each consensus node can calculate the state tree root hash values, transaction tree root hash values, and receipt tree root hash values corresponding to the multiple transactions based on the transaction bodies, write sets, and receipts of the multiple transactions. The block hash (i.e., the block header hash value of block B1) corresponding to the multiple transactions is calculated based on the state tree root hash values, transaction tree root hash values, receipt tree root hash values, and the block hash of the previous block (i.e., the block header hash value, as shown in Prev Hash in FIG3). FVP1 can send a consensus proposal to other consensus nodes in the PP phase, and the consensus proposal includes the block hash of block B1. After receiving the consensus proposal, LVP can compare whether the block hash received from FVP1 is consistent with the block hash of block B1 calculated by itself. If they are consistent, the block hash is signed and sent to other consensus nodes. After completing the PP stage, P stage, and C stage in Figure 3, the consensus on the block hash is completed. After the consensus nodes complete the consensus on the block hash, it can be ensured that the execution results of multiple transactions by each consensus node are consistent, so that each node can update the storage according to the execution results of multiple transactions.
在步骤S709,LVP根据多个交易的写集更新验证数据。In step S709, the LVP updates the verification data according to the write sets of the multiple transactions.
具体是,LVP在得到各个交易的写集之后,根据各个交易的写集得到该多个交易对应的写集(例如wset1),该写集wset1中包括根据所述多个交易的写操作而将用于更新状态数据的账户的key-value对或合约账户和合约变量的key-value对。在对多个交易的执行结果成功共识之后,LVP可基于wset1中各个状态的哈希值更新LVP中的验证数据。Specifically, after obtaining the write sets of each transaction, LVP obtains the write sets corresponding to the multiple transactions (e.g., wset1) according to the write sets of each transaction, and the write set wset1 includes the key-value pairs of the accounts or the key-value pairs of the contract accounts and contract variables that will be used to update the state data according to the write operations of the multiple transactions. After successfully reaching a consensus on the execution results of multiple transactions, LVP can update the verification data in LVP based on the hash values of each state in wset1.
在一种实施方式中,LVP中的验证数据包括各个账户和各个合约变量的状态的哈希值。假设写集wset1中包括将写入的账户A的键值对,LVP可基于wset1中的账户A的key找到验证数据中该key对应的value哈希值的存储位置,将wset1中的key对应的状态的哈希值写入到所述存储位置处。In one embodiment, the verification data in LVP includes the hash value of the state of each account and each contract variable. Assuming that the write set wset1 includes the key-value pair of account A to be written, LVP can find the storage location of the value hash value corresponding to the key in the verification data based on the key of account A in wset1, and write the hash value of the state corresponding to the key in wset1 to the storage location.
假设写集wset1中包括将写入的账户B的键值对和变量a的键值对,LVP首先根据变量a的更新的value,计算更新的状态哈希值,在验证数据中更新变量a的状态哈希值。之后,LVP根据账户B的更新value,计算更新的状态哈希值,在验证数据中更账户B的状态哈希值。Assuming that the write set wset1 includes the key-value pair of account B to be written and the key-value pair of variable a, LVP first calculates the updated state hash value based on the updated value of variable a, and updates the state hash value of variable a in the verification data. Afterwards, LVP calculates the updated state hash value based on the updated value of account B, and updates the state hash value of account B in the verification data.
在另一种实施方式中,LVP中的验证数据包括如图5所示的状态哈希值树和存储哈希值树,LVP可首先如在上一种实施方式中所述更新状态哈希值树和存储哈希值树中的与写集中多个状态对应的叶子节点中的状态哈希值。然后可基于更新的叶子节点,向上更新状态哈希值树和存储哈希值树中的各层节点中包括的哈希值,直到更新状态哈希值树和存储哈希值树的根节点的哈希值。In another embodiment, the verification data in the LVP includes a state hash value tree and a storage hash value tree as shown in FIG5 , and the LVP may first update the state hash values in the leaf nodes corresponding to the multiple states in the write set in the state hash value tree and the storage hash value tree as described in the previous embodiment. Then, based on the updated leaf nodes, the hash values included in the nodes at each level in the state hash value tree and the storage hash value tree may be updated upward until the hash values of the root nodes of the state hash value tree and the storage hash value tree are updated.
另外,LVP在对区块哈希完成共识之后,可存储所生成的区块的区块头。如图3中所示,区块头中可以包括状态树的根哈希值、交易树的根哈希值和收据树的根哈希值,区块头可用于对交易、收据等数据进行spv验证,并可用于生成下一个区块的区块头。In addition, after LVP completes consensus on the block hash, it can store the block header of the generated block. As shown in Figure 3, the block header can include the root hash value of the state tree, the root hash value of the transaction tree, and the root hash value of the receipt tree. The block header can be used to perform SPV verification on data such as transactions and receipts, and can be used to generate the block header of the next block.
在LVP更新存储的同时,FVP1也根据多个交易的执行结果更新存储,具体是,FVP1根据多个交易的写集更新如图3所示的状态树和存储树,以及存储该多个交易对应的区块B1,该区块包括区块头和区块体,区块体中例如包括多个交易的交易体、收据等数据。在区块链***中的LVP和FVP都根据多个交易的执行结果更新存储之后,LVP中的验证数据仍与FVP中的状态数据相对应,以用于继续对下一批多个交易进行共识。While LVP is updating the storage, FVP1 is also updating the storage according to the execution results of multiple transactions. Specifically, FVP1 updates the state tree and storage tree shown in FIG3 according to the write sets of multiple transactions, and stores the block B1 corresponding to the multiple transactions, which includes a block header and a block body. The block body includes, for example, transaction bodies, receipts and other data of multiple transactions. After both LVP and FVP in the blockchain system update the storage according to the execution results of multiple transactions, the verification data in LVP still corresponds to the state data in FVP, so as to continue to reach consensus on the next batch of multiple transactions.
本说明书实施例的方案,在LVP中只保存轻量存储,LVP通过从FVP获取读集,从而可基于验证数据对读集进行验证,从而可在验证通过之后根据读集进行交易执行过程,大大节省了数据存储的硬件成本和时间成本,提高了区块链***的性能和效率。The solution of the embodiments of this specification only stores lightweight storage in LVP. LVP obtains the read set from FVP, thereby verifying the read set based on the verification data, so that the transaction execution process can be performed according to the read set after the verification is passed, which greatly saves the hardware cost and time cost of data storage and improves the performance and efficiency of the blockchain system.
在一种实施方式中,LVP可包括共识装置、存储装置和执行装置,所述共识装置、存储装置和执行装置可以为单个计算设备中的分离的单元,或者可以为多个分离的计算设 备。其中,存储装置中存储有LVP中的验证数据和区块头等数据。In one embodiment, LVP may include a consensus device, a storage device, and an execution device, which may be separate units in a single computing device, or may be multiple separate computing devices. The storage device stores data such as verification data and block headers in the LVP.
在该实施方式中,FVP将共识提议发送给共识装置,以进行对共识提议的共识。共识装置还可以从FVP获取多个交易的读集,并将该读集发送给存储装置。从而存储装置可基于验证数据验证读集是否正确。其中,在共识装置进行对共识提议的共识的同时,存储装置可并行地进行对读集的验证。在验证通过的情况中,存储装置将验证通过的验证结果返回给共识装置。在共识成功的情况中,共识装置将多个交易的交易列表和读集发送给执行装置,该交易列表中包括多个交易各自的交易体、以及多个交易的排列顺序。执行装置根据读集执行多个交易,得到各个交易的执行结果,该执行结果例如包括各个交易的写集和收据。执行装置将多个交易的执行结果返回给共识装置,共识装置根据多个交易的执行结果,生成多个交易对应的区块哈希值。共识节点(包括FVP和LVP)进行对区块哈希值的共识。也即各个共识节点的共识装置对区块哈希值进行共识。在对区块哈希值共识成功的情况下,共识装置将生成的区块头和更新的验证数据发送给存储装置以进行存储。其中,更新的验证数据例如可包括图5所示的状态哈希值树和存储哈希值树中的更新的节点值。In this embodiment, the FVP sends the consensus proposal to the consensus device to reach a consensus on the consensus proposal. The consensus device can also obtain a read set of multiple transactions from the FVP and send the read set to the storage device. Thus, the storage device can verify whether the read set is correct based on the verification data. Wherein, while the consensus device reaches a consensus on the consensus proposal, the storage device can verify the read set in parallel. In the case of successful verification, the storage device returns the verification result of the verification to the consensus device. In the case of successful consensus, the consensus device sends a transaction list and a read set of multiple transactions to the execution device, and the transaction list includes the transaction bodies of each of the multiple transactions and the arrangement order of the multiple transactions. The execution device executes multiple transactions according to the read set to obtain the execution results of each transaction, and the execution results include, for example, the write set and receipt of each transaction. The execution device returns the execution results of the multiple transactions to the consensus device, and the consensus device generates block hash values corresponding to the multiple transactions according to the execution results of the multiple transactions. The consensus nodes (including FVP and LVP) reach a consensus on the block hash value. That is, the consensus devices of each consensus node reach a consensus on the block hash value. When the consensus on the block hash value is successful, the consensus device sends the generated block header and updated verification data to the storage device for storage. The updated verification data may include, for example, the state hash value tree shown in FIG5 and the updated node value in the storage hash value tree.
图8为本说明书实施例中的一种区块链***中的轻共识节点的架构图,所述区块链***包括第一类型的共识节点和第二类型的共识节点,所述第一类型的共识节点存储有状态数据,所述状态数据中包括多个状态,所述第二类型的共识节点存储有验证数据,所述验证数据与所述多个状态对应,所述所述第二类型的共识节点包括:FIG8 is an architecture diagram of a light consensus node in a blockchain system in an embodiment of the present specification, wherein the blockchain system includes a first type of consensus node and a second type of consensus node, wherein the first type of consensus node stores state data, wherein the state data includes multiple states, and the second type of consensus node stores verification data, wherein the verification data corresponds to the multiple states, and the second type of consensus node includes:
获取单元81,用于从所述第一类型的共识节点获取待执行的多个交易的读集,所述读集包括根据所述多个交易读取的第一状态;An acquisition unit 81 is configured to acquire a read set of multiple transactions to be executed from a consensus node of the first type, wherein the read set includes a first state read according to the multiple transactions;
验证单元82,用于基于所述验证数据对所述读集进行验证;A verification unit 82, configured to verify the read set based on the verification data;
执行单元83,用于在验证通过的情况中,根据所述读集执行所述多个交易,得到写集,所述写集包括用于更新所述状态数据的第二状态;An execution unit 83 is used for executing the multiple transactions according to the read set to obtain a write set when the verification passes, wherein the write set includes a second state for updating the state data;
更新单元84,用于根据所述写集更新所述验证数据。The updating unit 84 is configured to update the verification data according to the write set.
本说明书实施例还提供一种计算机可读存储介质,其上存储有计算机程序,当所述计算机程序在计算机中执行时,令计算机执行如图7所示的方法。The embodiments of this specification also provide a computer-readable storage medium on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to execute the method shown in FIG. 7 .
本说明书实施例还提供一种共识节点,包括存储器和处理器,所述存储器中存储有可执行代码,所述处理器执行所述可执行代码时,实现如图7所示的方法。The embodiment of this specification also provides a consensus node, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method shown in FIG. 7 is implemented.
在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。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到 实现该逻辑方法流程的硬件电路。In the 1990s, it was very clear whether the improvement of a technology was hardware improvement (for example, improvement of the circuit structure of diodes, transistors, switches, etc.) or software improvement (improvement of the method flow). However, with the development of technology, many of the improvements of the method flow today can be regarded as direct improvements of the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be implemented with hardware entity modules. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming themselves, without having to ask chip manufacturers to design and make dedicated integrated circuit chips. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing programs. The original code before compilation must also be written in a specific programming language, which is called Hardware Description Language (HDL). There is not only one kind of HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., and the most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that realizes the logic method flow.
控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit,ASIC)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:ARC625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。The controller may be implemented in any suitable manner, for example, the controller may take the form of a microprocessor or processor and a computer readable medium storing a computer readable program code (e.g., software or firmware) executable by the (micro)processor, a logic gate, a switch, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, and the memory controller may also be implemented as part of the control logic of the memory. It is also known to those skilled in the art that in addition to implementing the controller in a purely computer readable program code manner, the controller may be implemented in the form of a logic gate, a switch, an application specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, such a controller may be considered as a hardware component, and the means for implementing various functions included therein may also be considered as a structure within the hardware component. Or even, the means for implementing various functions may be considered as both a software module for implementing the method and a structure within the hardware component.
上述实施例阐明的***、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为服务器***。当然,本申请不排除随着未来计算机技术的发展,实现上述实施例功能的计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present application does not exclude that with the development of computer technology in the future, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
虽然本说明书一个或多个实施例提供了如实施例或流程图所述的方法操作步骤,但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式,不代表唯一的执行顺序。在实际中的装置或终端产品执行时,可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境,甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下,并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。例如若使用到第一,第二等词语用来表示名称,而并不表示任何特定的顺序。Although one or more embodiments of the present specification provide method operation steps as described in the embodiments or flow charts, more or less operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps, and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "include", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any specific order.
为了描述的方便,描述以上装置时以功能分为各种模块分别描述。当然,在实施本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现,也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个***,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。For the convenience of description, the above devices are described in various modules according to their functions. Of course, when implementing one or more of the present specification, the functions of each module can be implemented in the same or more software and/or hardware, or the module implementing the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
本发明是参照根据本发明实施例的方法、装置(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。The present invention is described with reference to the flowchart and/or block diagram of the method, device (system), and computer program product according to the embodiment of the present invention. It should be understood that each process and/or box in the flowchart and/or block diagram, as well as the combination of the process and/or box in the flowchart and/or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个 方框中指定的功能。These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。In a typical configuration, a computing device includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。Memory may include non-permanent storage in a computer-readable medium, in the form of random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁盘存储、石墨烯存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined in this article, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.
本领域技术人员应明白,本说明书一个或多个实施例可提供为方法、***或计算机程序产品。因此,本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。It should be understood by those skilled in the art that one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书一个或多个实施例,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。One or more embodiments of the present specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于***实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外,在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the description of the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples without contradiction.
以上所述仅为本说明书一个或多个实施例的实施例而已,并不用于限制本说明书一个或多个实施例。对于本领域技术人员来说,本说明书一个或多个实施例可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在权利要求范围之内。The above description is only an example of one or more embodiments of the present specification and is not intended to limit one or more embodiments of the present specification. For those skilled in the art, one or more embodiments of the present specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present specification shall be included in the scope of the claims.
Claims (15)
- 一种区块链***中的交易执行方法,所述区块链***包括第一类型的共识节点和第二类型的共识节点,所述第一类型的共识节点存储有状态数据,所述状态数据中包括多个状态,所述第二类型的共识节点存储有验证数据,所述验证数据与所述多个状态对应,所述方法由所述第二类型的共识节点执行,包括:A transaction execution method in a blockchain system, the blockchain system comprising a first type of consensus node and a second type of consensus node, the first type of consensus node storing state data, the state data comprising a plurality of states, the second type of consensus node storing verification data, the verification data corresponding to the plurality of states, the method being executed by the second type of consensus node, comprising:从所述第一类型的共识节点获取待执行的多个交易的读集,所述读集包括根据所述多个交易读取的第一状态;Obtaining a read set of multiple transactions to be executed from a consensus node of the first type, the read set including a first state read according to the multiple transactions;基于所述验证数据对所述读集进行验证;verifying the read set based on the verification data;在验证通过的情况中,根据所述读集执行所述多个交易,得到写集,所述写集包括用于更新所述状态数据的第二状态;If the verification passes, executing the multiple transactions according to the read set to obtain a write set, wherein the write set includes a second state for updating the state data;根据所述写集更新所述验证数据。The verification data is updated according to the write set.
- 根据权利要求1所述的方法,还包括,在从所述第一类型的共识节点获取待执行的多个交易的读集之前,从主节点接收共识提议,以进行对所述共识提议的共识,所述共识提议中包括所述多个交易的排列顺序,所述主节点为所述第一类型的共识节点;The method according to claim 1, further comprising, before obtaining the read set of the plurality of transactions to be executed from the consensus node of the first type, receiving a consensus proposal from a master node to reach a consensus on the consensus proposal, wherein the consensus proposal includes an arrangement order of the plurality of transactions, and the master node is a consensus node of the first type;所述在验证通过的情况中,根据所述读集执行所述多个交易,包括:In the case where the verification is passed, executing the multiple transactions according to the read set includes:在验证通过、且所述共识成功的情况中,根据所述读集和所述多个交易的排列顺序执行所述多个交易。When the verification passes and the consensus succeeds, the multiple transactions are executed according to the read set and the order in which the multiple transactions are arranged.
- 根据权利要求2所述的方法,所述从所述第一类型的共识节点获取待执行的多个交易的读集包括:从所述主节点接收所述读集,所述读集由所述主节点预执行所述多个交易而生成,所述多个交易的预执行顺序与所述排列顺序相对应。According to the method of claim 2, obtaining a read set of multiple transactions to be executed from the first type of consensus node includes: receiving the read set from the master node, the read set is generated by the master node pre-executing the multiple transactions, and the pre-execution order of the multiple transactions corresponds to the arrangement order.
- 根据权利要求2所述的方法,所述基于所述验证数据对所述读集进行验证包括:在对所述共识提议进行共识的同时,并行地基于所述验证数据对所述读集进行验证。According to the method of claim 2, the verifying the read set based on the verification data comprises: while reaching consensus on the consensus proposal, verifying the read set based on the verification data in parallel.
- 根据权利要求1所述的方法,所述从所述第一类型的共识节点获取待执行的多个交易的读集包括:根据所述多个交易确定待读取的状态,向所述区块链***中的一个或多个第一类型的共识节点请求读取所述待读取的状态。According to the method of claim 1, obtaining a read set of multiple transactions to be executed from the first type of consensus node includes: determining a state to be read based on the multiple transactions, and requesting one or more first type of consensus nodes in the blockchain system to read the state to be read.
- 根据权利要求1所述的方法,还包括:The method according to claim 1, further comprising:与所述区块链中的其他共识节点进行对所述写集的共识;Reaching consensus on the write set with other consensus nodes in the blockchain;所述根据所述写集更新所述验证数据包括:在对所述写集的共识成功的情况下,根据所述写集更新所述验证数据。The updating of the verification data according to the write set includes: updating the verification data according to the write set when the consensus on the write set is successful.
- 根据权利要求6所述的方法,所述与所述区块链***中的其他共识节点进行对所述写集的共识包括:According to the method of claim 6, the consensus on the write set with other consensus nodes in the blockchain system includes:基于所述多个交易的执行结果生成与所述多个交易对应的区块头,所述多个交易的执行结果包括所述写集;计算所述区块头的哈希值;与所述区块链***中的其他共识节点进行对所述区块头哈希值的共识。Based on the execution results of the multiple transactions, block headers corresponding to the multiple transactions are generated, and the execution results of the multiple transactions include the write set; a hash value of the block header is calculated; and consensus on the hash value of the block header is reached with other consensus nodes in the blockchain system.
- 根据权利要求7所述的方法,还包括:存储所述区块头。The method according to claim 7, further comprising: storing the block header.
- 根据权利要求1所述的方法,所述验证数据包括所述多个状态各自的哈希值。The method according to claim 1, wherein the verification data includes a hash value of each of the plurality of states.
- 根据权利要求9所述的方法,所述验证数据包括树形结构的哈希值数据,所述哈希值数据的多个叶子节点中分别包括所述多个状态各自的哈希值,所述基于所述验证数据对所述读集进行验证包括:基于所述哈希值数据对所述第一状态进行SPV验证。According to the method of claim 9, the verification data includes hash value data in a tree structure, multiple leaf nodes of the hash value data respectively include hash values of the multiple states, and the verification of the read set based on the verification data includes: performing SPV verification on the first state based on the hash value data.
- 根据权利要求4所述的方法,所述第二类型的共识节点包括共识装置和存储装置,所述存储装置中存储有所述验证数据,所述在对所述共识提议进行共识的同时,并行地基于所述验证数据对所述读集进行验证,包括:According to the method of claim 4, the second type of consensus node comprises a consensus device and a storage device, the storage device stores the verification data, and while reaching consensus on the consensus proposal, the read set is verified based on the verification data in parallel, comprising:所述共识装置在对从所述主节点获取的所述共识提议进行共识的同时,所述存储装置并行地基于所述验证数据对从所述共识装置接收的所述读集进行验证。While the consensus device is reaching consensus on the consensus proposal obtained from the master node, the storage device is concurrently verifying the read set received from the consensus device based on the verification data.
- 一种区块链***,包括第一类型的共识节点和第二类型的共识节点,所述第一类 型的共识节点存储有状态数据,所述状态数据中包括多个状态,所述第二类型的共识节点存储有验证数据,所述验证数据与所述多个状态对应,A blockchain system includes a first type of consensus node and a second type of consensus node, wherein the first type of consensus node stores state data, wherein the state data includes a plurality of states, and the second type of consensus node stores verification data, wherein the verification data corresponds to the plurality of states.所述第一类型的共识节点用于将待执行的多个交易的读集发送给所述第二类型的共识节点,所述读集包括根据所述多个交易读取的第一状态;The first type of consensus node is used to send a read set of multiple transactions to be executed to the second type of consensus node, where the read set includes a first state read according to the multiple transactions;所述所述第二类型的共识节点用于基于所述验证数据对所述读集进行验证;在验证通过的情况中,根据所述读集执行所述多个交易,得到写集,所述写集包括用于更新所述状态数据的第二状态;根据所述写集更新所述验证数据。The second type of consensus node is used to verify the read set based on the verification data; if the verification passes, execute the multiple transactions according to the read set to obtain a write set, and the write set includes a second state for updating the state data; update the verification data according to the write set.
- 一种区块链***中的共识节点,所述区块链***包括第一类型的共识节点和第二类型的共识节点,所述第一类型的共识节点存储有状态数据,所述状态数据中包括多个状态,所述第二类型的共识节点存储有验证数据,所述验证数据与所述多个状态对应,所述所述第二类型的共识节点包括:A consensus node in a blockchain system, the blockchain system comprising a first type of consensus node and a second type of consensus node, the first type of consensus node storing state data, the state data comprising a plurality of states, the second type of consensus node storing verification data, the verification data corresponding to the plurality of states, the second type of consensus node comprising:获取单元,用于从所述第一类型的共识节点获取待执行的多个交易的读集,所述读集包括根据所述多个交易读取的第一状态;an acquisition unit, configured to acquire, from a consensus node of the first type, a read set of a plurality of transactions to be executed, the read set comprising a first state read according to the plurality of transactions;验证单元,用于基于所述验证数据对所述读集进行验证;a verification unit, configured to verify the read set based on the verification data;执行单元,用于在验证通过的情况中,根据所述读集执行所述多个交易,得到写集,所述写集包括用于更新所述状态数据的第二状态;an execution unit, configured to execute the plurality of transactions according to the read set to obtain a write set when the verification passes, wherein the write set includes a second state for updating the state data;更新单元,用于根据所述写集更新所述验证数据。An updating unit is used to update the verification data according to the write set.
- 一种计算机可读存储介质,其上存储有计算机程序,当所述计算机程序在计算机中执行时,令计算机执行权利要求1-11任一项所述的方法。A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to any one of claims 1 to 11.
- 一种共识节点,包括存储器和处理器,所述存储器中存储有可执行代码,所述处理器执行所述可执行代码时,实现权利要求1-11任一项所述的方法。A consensus node comprises a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in any one of claims 1 to 11 is implemented.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211214892.6 | 2022-09-30 | ||
CN202211214892.6A CN115640356A (en) | 2022-09-30 | 2022-09-30 | Transaction execution method in blockchain system, consensus node and blockchain system |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2024066007A1 true WO2024066007A1 (en) | 2024-04-04 |
Family
ID=84942150
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2022/135255 WO2024066007A1 (en) | 2022-09-30 | 2022-11-30 | Transaction execution method in blockchain system, consensus node, and blockchain system |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN115640356A (en) |
WO (1) | WO2024066007A1 (en) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117808466A (en) * | 2024-02-28 | 2024-04-02 | 中国信息通信研究院 | Transaction pre-execution method and device based on blockchain |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110602116A (en) * | 2019-09-19 | 2019-12-20 | 腾讯科技(深圳)有限公司 | Block chain based data verification method, device and computer readable storage medium |
US20200195441A1 (en) * | 2018-12-13 | 2020-06-18 | International Business Machines Corporation | Compact state database system |
CN112035475A (en) * | 2020-08-28 | 2020-12-04 | 平安科技(深圳)有限公司 | Block storage method and device of block chain, node equipment and storage medium |
CN114511319A (en) * | 2021-12-29 | 2022-05-17 | 壹链盟生态科技有限公司 | Block chain consensus method |
CN114936256A (en) * | 2022-05-30 | 2022-08-23 | 蚂蚁区块链科技(上海)有限公司 | Method for executing transaction in block chain and block chain link point |
-
2022
- 2022-09-30 CN CN202211214892.6A patent/CN115640356A/en active Pending
- 2022-11-30 WO PCT/CN2022/135255 patent/WO2024066007A1/en unknown
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20200195441A1 (en) * | 2018-12-13 | 2020-06-18 | International Business Machines Corporation | Compact state database system |
CN110602116A (en) * | 2019-09-19 | 2019-12-20 | 腾讯科技(深圳)有限公司 | Block chain based data verification method, device and computer readable storage medium |
CN112035475A (en) * | 2020-08-28 | 2020-12-04 | 平安科技(深圳)有限公司 | Block storage method and device of block chain, node equipment and storage medium |
CN114511319A (en) * | 2021-12-29 | 2022-05-17 | 壹链盟生态科技有限公司 | Block chain consensus method |
CN114936256A (en) * | 2022-05-30 | 2022-08-23 | 蚂蚁区块链科技(上海)有限公司 | Method for executing transaction in block chain and block chain link point |
Also Published As
Publication number | Publication date |
---|---|
CN115640356A (en) | 2023-01-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6875557B2 (en) | Methods and devices for writing service data to the blockchain system | |
CN107577427B (en) | data migration method, device and storage medium for blockchain system | |
EP3561674B1 (en) | Method and apparatus for verifying block data in a blockchain | |
CN114827165B (en) | Method and block link point for grouping multiple transactions | |
WO2023231336A1 (en) | Method for executing transaction and blockchain node | |
CN112261163B (en) | State storage method in block chain system, block chain system and node | |
WO2024066007A1 (en) | Transaction execution method in blockchain system, consensus node, and blockchain system | |
WO2023231337A1 (en) | Method for executing transaction in blockchain, and master node and slave node of blockchain | |
WO2023231335A1 (en) | Method for executing transaction in blockchain, and master node of blockchain | |
WO2023207080A1 (en) | Data processing method in blockchain, and blockchain node | |
CN114936256A (en) | Method for executing transaction in block chain and block chain link point | |
TW202226019A (en) | Generating and validating blockchain transactions | |
WO2024092930A1 (en) | Transaction execution method in blockchain system, and node | |
WO2024066019A1 (en) | Transaction execution method in blockchain system, consensus node, and blockchain system | |
WO2024066011A1 (en) | Consensus node type conversion method and consensus node | |
WO2024066006A1 (en) | Consensus method and consensus node in blockchain system, and blockchain system | |
WO2024066014A1 (en) | Blockchain system transaction execution method and node | |
WO2024066012A1 (en) | Method and apparatus for converting peer type in blockchain system, and blockchain system | |
WO2024066009A1 (en) | State verification method and apparatus in blockchain system, and node and blockchain | |
WO2024066010A1 (en) | Method and apparatus for transaction processing in blockchain system, and blockchain system | |
CN115150409A (en) | Method for executing transaction in block chain system, block chain system and node | |
WO2024092932A1 (en) | Transaction execution method and blockchain node | |
CN116881361A (en) | Transaction execution method, node and blockchain system | |
CN115982781A (en) | Method for creating account in block chain and block chain link point | |
Choi et al. | LMPT: A Novel Authenticated Data Structure to Eliminate Storage Bottlenecks for High Performance Blockchains |
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: 22960603 Country of ref document: EP Kind code of ref document: A1 |