WO2024066014A1 - Procédé et nœud d'exécution de transaction de système de chaîne de blocs - Google Patents

Procédé et nœud d'exécution de transaction de système de chaîne de blocs Download PDF

Info

Publication number
WO2024066014A1
WO2024066014A1 PCT/CN2022/135406 CN2022135406W WO2024066014A1 WO 2024066014 A1 WO2024066014 A1 WO 2024066014A1 CN 2022135406 W CN2022135406 W CN 2022135406W WO 2024066014 A1 WO2024066014 A1 WO 2024066014A1
Authority
WO
WIPO (PCT)
Prior art keywords
state
node
verification data
storage device
transaction
Prior art date
Application number
PCT/CN2022/135406
Other languages
English (en)
Chinese (zh)
Inventor
卓海振
Original Assignee
蚂蚁区块链科技(上海)有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 蚂蚁区块链科技(上海)有限公司 filed Critical 蚂蚁区块链科技(上海)有限公司
Publication of WO2024066014A1 publication Critical patent/WO2024066014A1/fr

Links

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 more particularly to a transaction execution method and node 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 consensus scheme in a blockchain system, which can greatly save storage resources in the blockchain system and improve system efficiency.
  • a first aspect of the present specification provides a transaction execution method in a blockchain system, which is executed by a node in the blockchain system, wherein multiple states in the blockchain system are stored in a storage device, and the node stores verification data, wherein the verification data corresponds to the multiple states, and the method comprises: reading a first state from the storage device according to a first transaction to be executed; verifying the first state based on the verification data; in the case where the verification passes, executing the first transaction based on the first state to obtain a second state to be written to the storage device; and updating the verification data based on the second state.
  • a node in a blockchain system wherein a plurality of states in the blockchain system are stored in a storage device, the node stores verification data, the verification data corresponds to the plurality of states, and the node comprises: a reading unit, for reading a first state from the storage device according to a first transaction to be executed; a verification unit, for verifying the first state based on the verification data; an execution unit, for executing the first transaction based on the first state to obtain a second state to be written to the storage device when the verification passes; and an updating unit, for updating the verification data based on the second state.
  • a third 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 fourth 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 solution of the embodiments of this specification only stores verification data in each LVP and maintains the status in the storage device, so that the LVP can verify the status read from the storage device based on the verification data, and thus can participate in the consensus and transaction execution process, which greatly saves the hardware cost and time cost of data storage in the blockchain system 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 schematic diagram of another verification data tree in LVP in an embodiment of this specification.
  • FIG8 is a schematic diagram of another verification data tree in LVP in an embodiment of this specification.
  • FIG9 is a flow chart of a transaction execution method in an embodiment of the present specification.
  • FIG10 is an architecture diagram of a node in a blockchain system according to 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 (PrevHash 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 BlockNum, 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 PrevHash 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 BlockNum
  • the state tree root hash State_Root the transaction tree root hash Transaction_Root
  • the PrevHash 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, which may be connected to multiple child nodes, and the branch node includes a 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 may 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 scheme of this specification is also applicable to this MPT tree variation.
  • the state tree may also include, for example, a sparse Merkle Tree (SMT), wherein the SMT tree includes multiple subtrees corresponding to multiple blocks, and the version number of the root node of each subtree corresponds to the block number.
  • the hash value of the root node of the state tree can be obtained by performing hash calculation based on the hash values of the root nodes of the multiple subtrees.
  • the leaf node in each subtree includes the state version number (version) of the node, the key corresponding to the node, and the state value (value). Among them, in the subtree with the largest version number of the subtree root node, the version number of each leaf node is the latest version of the account or variable corresponding to the leaf node.
  • a state can be uniquely determined based on the version number and key.
  • the hash value of the root node can also be obtained recursively based on the nodes of each layer.
  • the embodiment scheme of this specification is also applicable to this kind of SMT tree.
  • 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 status) 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, thereby storing the key-value mapping from the variable name (also called the state address) to the state value.
  • 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 the verification data of the state is saved, for example, the hash value data in the state tree and the storage tree is saved, but the value of each account or variable in the state tree and the storage tree (i.e., each state) is not saved, and the value of each account or variable in the state tree and the storage tree is stored in a storage device outside the blockchain system.
  • LVP Light Validating Peer
  • FIG. 5 is a schematic diagram of the state hash value tree in FIG5.
  • 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.
  • 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 in the state hash value tree except the leaf node and the root node can be generated using the same calculation method as in the state tree.
  • the hash (324, 74) in the node including "5" in FIG6 can be calculated by the above formula (1).
  • the storage hash value tree may also have a structure similar to the structure shown in FIG6.
  • the state hash value tree and storage hash value tree shown in FIG. 5 and FIG. 6 can be used to verify the state read from the storage device, so these data can be collectively referred to as verification data. It can be understood that the verification data is not limited to the structure shown in FIG. 5 or FIG. 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.
  • FIG. 7 is a schematic diagram of another verification data tree in LVP in an embodiment of this specification.
  • the leaf node in the verification data may include a content identifier (Content-ID, CID) of the state for verifying the state.
  • CID Content identifier
  • the verification data tree can be applied to a scenario where the state is stored in a decentralized network such as IPFS, where the state CID can be stored in association with the state, so that the state can be read from IPFS based on the state CID.
  • FIG8 is a schematic diagram of another verification data tree in LVP in an embodiment of the present specification.
  • the verification data tree corresponds to the SMT tree, and each node in the tree includes a version number, which indicates the number of times the data in the node has been updated.
  • the verification data tree may also include multiple subtrees.
  • FIG8 shows a subtree in the verification data tree, wherein the node s1 in FIG8 is the root node of the subtree.
  • Node s1 includes a version number and a hash value.
  • Each node under the root node of the subtree includes a version number, an index character, and a hash value.
  • the hash value included in the parent node in the verification data tree is also generated based on the data of all its child nodes, for example:
  • hash(324,74) hash(hash(50,324,hash(state1)),hash(70,74,hash(a,c))).
  • the leaf node s4 includes the version number 50 of state1, the index data of state1 (i.e., the characters in the key) 324, and the hash value hash(state1) of state1. Assuming that the version number 100 of the root node corresponds to the current maximum block number, the version number in each leaf node in the subtree is the latest version of the state of the account or variable. For example, the version number 50 in the leaf node s4 is the latest version of the state state1 of the account f5324, that is, the account f5324 has been written 50 times in 100 blocks.
  • the verification data tree can be applied to scenarios where the state is stored in a centralized network such as NAS, where the state version number and state key can be stored in association with the state, so that the state can be read from the NAS based on the version number and key.
  • FIG. 9 is a flow chart of the transaction execution method in the embodiment of this specification.
  • the method can be executed by multiple LVPs and storage devices in the blockchain system.
  • LVP1 among multiple LVPs is the master node, and the LVPs other than the master node in the blockchain system are slave nodes.
  • the master node is responsible for initiating a consensus proposal to reach a consensus on the consensus proposal with the slave nodes, and the master node can write the status to the storage device.
  • the slave node can read the status from the storage device, but does not write data to the storage device.
  • the other operations of the slave node (including steps S903, S905 and step S907) are the same as those of the master node.
  • the following description takes LVP1 as an example
  • step S901 LVP1 reads a first state from a storage device.
  • LVP1 can receive transactions sent by users from user clients or other FVPs.
  • the transaction can be a transfer transaction, or a transaction to call a contract, etc.
  • LVP1 After receiving a certain amount of transactions, LVP1 can select multiple transactions from the received transactions for consensus to generate new blocks.
  • the LVP1 can generate a consensus proposal for consensus on the order of arrangement of the multiple transactions.
  • the consensus proposal may include a transaction list of the multiple transactions, and the transaction list includes transaction bodies of multiple transactions arranged in sequence.
  • the consensus proposal may include transaction identifiers of multiple transactions arranged in sequence (such as hash values of each transaction), and at the same time, LVP1 can broadcast the transaction bodies of each of the multiple transactions to other nodes through broadcasting, thereby reducing the amount of data in the consensus proposal and saving the amount of calculation used for signatures during the consensus process.
  • the multiple transactions can be executed according to the order in which the multiple transactions in the consensus proposal are arranged.
  • LVP1 executes each of the multiple transactions, it can read the state from the storage device according to the read operation included in the transaction (in order to distinguish it from the state written below, the read state is referred to as the first state and the state written to the storage device is referred to as the second state in the embodiment of this specification) for executing the transaction.
  • transaction Tx1 among the multiple transactions includes an update to the balance of account A (e.g., reducing a preset amount)
  • the value of account A i.e., including Nonce and Balance
  • the Nonce value is increased by 1
  • 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, LVP1 needs to read the status of account A when executing this transaction, and the write set of this transaction also includes writing to account A.
  • LVP1 reads the status of account A in executing transaction Tx1 for the first time in the process of executing multiple transactions, that is, LVP1 does not cache the previously read status of account A locally, and LVP1 needs to read the status of account A from the storage device.
  • LVP1 stores verification data as shown in FIG6 , and the storage device associates the state hash value with the state.
  • LVP1 can obtain the state hash value hash(state1) corresponding to account A from the leaf node corresponding to account A in the verification data shown in FIG6 . Then, LVP1 can send a read request to the storage device, and the read request includes hash(state1) to read state1 corresponding to hash(state1) from the storage device.
  • LVP1 stores verification data as shown in FIG7
  • the storage device associates the CID of the state with the state
  • LVP1 can obtain the CID (state1) corresponding to account A from the leaf node corresponding to account A in the verification data shown in FIG7 .
  • LVP1 can send a read request to the storage device, and the read request includes CID (state1) to read state1 corresponding to CID (state1) from the storage device.
  • LVP1 stores the verification data shown in FIG8 , and the storage device associates the version number of the latest state (state1) of account A and the key of account A with state state1, and LVP1 can obtain the version number and key corresponding to the latest state of account A from the leaf node corresponding to account A in the verification data shown in FIG8 . Then, LVP1 can send a read request to the storage device, and the read request includes the version number (50) and the key of account A (i.e., f5324), so as to read the state1 corresponding to the version number (50) and the key of account A (i.e., f5324) from the storage device.
  • transaction Tx2 in 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 transaction In order to write to account B and variable a, the transaction needs to read the Key-Value pair of account B and the key-value pair of variable a when executing.
  • LVP1 can similarly read the status of account B and the status of variable a from the storage device.
  • the status of account B includes the values of each field of Nonce, Balance, CodeHash and Storage_root of account B.
  • the status of variable a includes the status value of variable a.
  • step S903 LVP1 verifies the first state based on the verification data.
  • LVP1 stores the hash value of each state in the blockchain system and the index data to the hash value (such as the account address or variable name) as verification data, such as the above hash(state1). After reading the state state1 of account A, LVP1 can use the hash(state1) in the verification data to verify the read state1.
  • the state hash value tree and storage hash value tree as shown in FIG5 are stored in the LVP as verification data.
  • the LVP can perform a simplified payment verification (SPV) on each state read based on the state hash value tree and the storage hash value tree.
  • SPV simplified payment verification
  • the read state includes the Value of account A.
  • the LVP can calculate the hash value of the read Value of account A (e.g., hash1), 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 the LVP. If they are consistent, the read Value of account A is considered to be correct.
  • LVP1 reads the Value of account B and the Value of variable a from the storage device
  • LVP1 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.
  • the read state can be similarly verified based on the verification data, which is not repeated here.
  • LVP1 stores verification data as shown in FIG. 7, and the verification data may also similarly include verification data trees corresponding to the state tree and the storage tree, respectively.
  • LVP may calculate the state CID of account A based on the read state of account A, and use CID (state1) in the verification data to verify the calculated state CID of account A to verify the read state of account A.
  • LVP1 may also perform SPV verification on the calculated state CID of account A according to the verification data shown in FIG. 7 to verify the read state of account A.
  • LVP1 stores verification data as shown in FIG8
  • the verification data may also similarly include verification data trees corresponding to the state tree and the storage tree.
  • LVP may verify the read state of account A based on hash (state1) in the leaf node corresponding to account A in the verification data (i.e., node s4 in FIG8 ).
  • LVP1 may also perform SPV verification on the read state of account A based on the verification data shown in FIG8 .
  • 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 S905 LVP1 executes a transaction according to the first state to obtain a written second state.
  • LVP1 can execute the transaction based on the state of the account or variable read from the storage device after verifying the state. According to the write operation on the account or contract variable in the transaction, the write set of the transaction is obtained, which 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 state of the corresponding account or contract variable. After reading the state of the account or contract variable from the storage device, LVP1 can cache the state, and when executing the write operation on the account or contract variable, update the state of the account or contract variable in the cache, so as to be used for the subsequent reading of the state of the account or contract variable in the process of executing the transaction.
  • transaction Tx1 among the multiple transactions described above includes an update to the balance of account A
  • the value of account A read by LVP1 from the storage device is V1
  • LVP1 updates V1 according to the transaction to obtain an updated value of account A (assuming that the value is V2), where V2 includes an updated Nonce value and an updated Balance value, so that the updated key-value pair of account A can be written in the write set of transaction Tx1, and the status value of account A in the cache can be updated.
  • transaction Tx2 among multiple transactions includes the writing of variable a of the contract corresponding to account B, and the value of account B read by LVP1 from the storage device is V3, and the value of variable a is V4.
  • V4 is processed according to the transaction to obtain the updated value of variable a (assumed to be V5), and the hash value of V5 is calculated. Substitute it into the storage hash value tree in Figure 5, calculate the hash value of the root node st1, and use 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 pairs of account B and the updated key-value pairs of variable a can be included in the write set of the transaction Tx2.
  • the multiple LVPs in the blockchain system can reach a consensus on the execution results of the multiple transactions.
  • the consensus node (i.e., LVP) 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 value, transaction tree root hash value, and receipt tree root hash value 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 value, transaction tree root hash value, receipt tree root hash value, and the block hash of the previous block (i.e., the block header hash value, as shown in Prev Hash in FIG3).
  • LVP1 can send a consensus proposal to other consensus nodes in the PP stage, and the consensus proposal includes the block hash of block B1.
  • the consensus proposal includes the block hash of block B1.
  • other LVPs can compare whether the block hash received from LVP1 is consistent with the block hash of block B1 calculated by themselves. If they are consistent, the block hash is signed and sent to other consensus nodes.
  • the consensus on the block hash is completed.
  • 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 verification data according to the execution results of multiple transactions.
  • step S907 LVP1 updates the verification data according to the second state.
  • LVP1 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 accounts or the key-value pairs of contract accounts and contract variables that will be used to update the status in the blockchain system according to the write operations of the multiple transactions, and the updated status in the write set wset1 is to be stored in the storage device.
  • each LVP (including LVP1) can update the verification data in the LVP based on each status in wset1 (i.e., the second status).
  • the verification data in the LVP includes the hash value of the state of each account and each contract variable.
  • LVP1 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, calculate the state hash value of account A in wset1, and write the hash value of the state of account A to the storage location. It can be understood that other LVPs also update local verification data similarly to LVP1.
  • LVP1 first calculates the updated state hash value according to the updated value of variable a, and updates the state hash value of variable a in the verification data. After that, LVP calculates the updated state hash value according to 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.
  • LVP1 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 verification data in the LVP includes verification data as shown in FIG7.
  • LVP1 may first calculate the CID of each state in the write set wset1, and update the CID in the leaf node corresponding to each state in the write set in the verification data. Then, based on the updated leaf node, the hash value included in each layer node in the verification data may be updated upward until the hash value of the root node of the verification data is updated.
  • the verification data in the LVP includes the verification data shown in FIG8.
  • LVP1 may first calculate the hash value of each state in the write set wset1, and update the state hash value in the leaf node corresponding to each state in the write set in the verification data. Then, based on the updated leaf node, the hash value included in each layer node in the verification data may be updated upward until the hash value of the root node of the verification data is updated.
  • each LVP can store the block header of the generated block for SPV verification and for generating the next block.
  • step S909 LVP1 stores the second state to the storage device.
  • the storage device may be a decentralized storage system, such as a distributed storage system (Inter Planetary File System, IPFS).
  • IPFS Inter Planetary File System
  • the state may be stored in association with the CID of the state.
  • the generated state CID may be stored in association with the state in the storage device, so that when LVP1 reads the state, it may obtain the CID corresponding to the state from the verification data and read the state from the storage device according to the CID.
  • the storage device shown may also be a centralized storage system, such as a Network Attached Storage (NAS).
  • NAS Network Attached Storage
  • the version number and key of the state may be stored in the storage device in association with the state.
  • the storage device is not limited to storing in the above manner.
  • the storage device can also store the hash value of the state in association with the state, or store the key of the state in association with the state, etc.
  • LVP1 also stores the generated blocks in the storage device.
  • the solution of the embodiments of this specification only stores verification data in each LVP and maintains the status in the storage device, so that the LVP can verify the status read from the storage device based on the verification data, and thus can participate in the consensus and transaction execution process, which greatly saves the hardware cost and time cost of data storage in the blockchain system and improves the performance and efficiency of the blockchain system.
  • Figure 10 is an architecture diagram of a node in a blockchain system in an embodiment of this specification, wherein multiple states in the blockchain system are stored in a storage device, and the node stores verification data, wherein the verification data corresponds to the multiple states, and the node is used to execute the method shown in Figure 9, including: a reading unit 101, used to read a first state from the storage device according to a first transaction to be executed; a verification unit 102, used to verify the first state based on the verification data; an execution unit 103, used to execute the first transaction based on the first state to obtain a second state to be written to the storage device when the verification passes; an update unit 104, used to update the verification data based on the second state.
  • 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. 9 .
  • the embodiment of the present specification also provides a 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. 9 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: ARC 625D, 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.
  • 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 manufactured 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

L'invention concerne un procédé d'exécution de transaction de système de chaîne de blocs et un nœud de chaîne de blocs. Dans un système de chaîne de blocs, une pluralité d'états sont stockés dans un dispositif de stockage, et un nœud stocke des données de vérification, les données de vérification correspondant à la pluralité d'états. Le procédé consiste : selon une première transaction à exécuter, à lire un premier état à partir du dispositif de stockage ; sur la base des données de vérification, à vérifier le premier état ; lorsque la vérification est réussie, sur la base du premier état, à exécuter la première transaction, et à obtenir un second état à écrire dans le dispositif de stockage ; sur la base du second état, à mettre à jour les données de vérification.
PCT/CN2022/135406 2022-09-30 2022-11-30 Procédé et nœud d'exécution de transaction de système de chaîne de blocs WO2024066014A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211213568.2 2022-09-30
CN202211213568.2A CN115658806A (zh) 2022-09-30 2022-09-30 区块链系统中的交易执行方法和节点

Publications (1)

Publication Number Publication Date
WO2024066014A1 true WO2024066014A1 (fr) 2024-04-04

Family

ID=84985086

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135406 WO2024066014A1 (fr) 2022-09-30 2022-11-30 Procédé et nœud d'exécution de transaction de système de chaîne de blocs

Country Status (2)

Country Link
CN (1) CN115658806A (fr)
WO (1) WO2024066014A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107833060A (zh) * 2017-11-13 2018-03-23 中国银行股份有限公司 一种区块链中智能合约交易的验证方法以及系统
US20200177393A1 (en) * 2017-06-02 2020-06-04 Nokia Technologies Oy Positioning Information Verification
CN113988845A (zh) * 2021-08-12 2022-01-28 腾讯科技（深圳）有限公司 基于智能合约的数据处理方法、设备以及可读存储介质
CN115098594A (zh) * 2022-06-29 2022-09-23 蚂蚁区块链科技(上海)有限公司 在区块链系统中执行交易的方法、区块链系统和节点

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200177393A1 (en) * 2017-06-02 2020-06-04 Nokia Technologies Oy Positioning Information Verification
CN107833060A (zh) * 2017-11-13 2018-03-23 中国银行股份有限公司 一种区块链中智能合约交易的验证方法以及系统
CN113988845A (zh) * 2021-08-12 2022-01-28 腾讯科技（深圳）有限公司 基于智能合约的数据处理方法、设备以及可读存储介质
CN115098594A (zh) * 2022-06-29 2022-09-23 蚂蚁区块链科技(上海)有限公司 在区块链系统中执行交易的方法、区块链系统和节点

Also Published As

Publication number Publication date
CN115658806A (zh) 2023-01-31

Similar Documents

Publication Publication Date Title
JP6875557B2 (ja) サービス・データをブロックチェーン・システムに書き込むための方法およびデバイス
CN107577427B (zh) 用于区块链系统的数据迁移方法、设备和存储介质
WO2023231336A1 (fr) Procédé d'exécution de transaction et nœud de chaîne de blocs
CN114827165B (zh) 对多个交易进行分组的方法和区块链节点
WO2023231337A1 (fr) Procédé d'exécution d'une transaction dans une chaîne de blocs, et nœud maître et nœud esclave de chaîne de blocs
WO2023231335A1 (fr) Procédé d'exécution d'une transaction dans une chaîne de blocs, et nœud maître de chaîne de blocs
WO2024066007A1 (fr) Procédé d'exécution de transaction dans un système de chaîne de blocs, nœud de consensus et système de chaîne de blocs
CN114780640A (zh) 一种区块链中的数据处理方法及区块链节点
WO2024066014A1 (fr) Procédé et nœud d'exécution de transaction de système de chaîne de blocs
WO2024001032A1 (fr) Procédé d'exécution d'une transaction dans un système de chaîne de blocs, et système et nœuds de chaîne de blocs
WO2024066011A1 (fr) Procédé de conversion de type de nœud de consensus, et nœud de consensus
WO2024066019A1 (fr) Procédé d'exécution de transaction dans un système de chaîne de blocs, nœud de consensus et système de chaîne de blocs
WO2024066006A1 (fr) Procédé de consensus et nœud de consensus dans un système de chaîne de blocs, et système de chaîne de blocs
WO2024066009A1 (fr) Procédé et appareil de vérification d'état dans un système de chaîne de blocs, et nœud et chaîne de blocs
CN116366666A (zh) 区块链系统中的链状态更新方法和区块链节点
CN116167099A (zh) 区块链系统中的数据访问方法和区块链节点
WO2024066012A1 (fr) Procédé et appareil de conversion de type pair dans un système de chaîne de blocs, et système de chaîne de blocs
WO2024066010A1 (fr) Procédé et appareil de traitement de transaction dans un système de chaîne de blocs, et système de chaîne de blocs
CN116303425A (zh) 一种在区块链中创建账户的方法和区块链节点
WO2024092932A1 (fr) Procédé d'exécution de transaction et nœud de chaîne de blocs
WO2024092930A1 (fr) Procédé d'exécution de transaction dans un système de chaîne de blocs, et nœud
CN115760386A (zh) 区块链系统中的交易执行方法和区块链节点
CN116186763A (zh) 在区块链系统中处理区块数据的方法和装置
CN116668002A (zh) 区块链系统中的交易分发方法、区块链节点和区块链系统
CN116049170A (zh) 区块链状态的存储、验证方法及区块链节点

Legal Events

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

Ref document number: 22960610

Country of ref document: EP

Kind code of ref document: A1