WO2022237596A1 - Procédé et appareil de traversée pour contenu de stockage de contrat intelligent, et dispositif électronique - Google Patents

Procédé et appareil de traversée pour contenu de stockage de contrat intelligent, et dispositif électronique Download PDF

Info

Publication number
WO2022237596A1
WO2022237596A1 PCT/CN2022/090486 CN2022090486W WO2022237596A1 WO 2022237596 A1 WO2022237596 A1 WO 2022237596A1 CN 2022090486 W CN2022090486 W CN 2022090486W WO 2022237596 A1 WO2022237596 A1 WO 2022237596A1
Authority
WO
WIPO (PCT)
Prior art keywords
character
node
tree
merkle
value
Prior art date
Application number
PCT/CN2022/090486
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 WO2022237596A1 publication Critical patent/WO2022237596A1/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
    • G06F16/2228—Indexing structures
    • G06F16/2246—Trees, e.g. B+trees
    • 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/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • 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

Definitions

  • One or more embodiments of this specification relate to the field of blockchain technology, and in particular to a method and device for traversing content stored in smart contracts, and electronic equipment.
  • Blockchain technology also known as distributed ledger technology, is an emerging technology in which several node devices jointly participate in “bookkeeping” and jointly store and maintain a complete distributed database.
  • the blockchain data that needs to be stored and maintained usually includes block data, account status data corresponding to the blockchain account in the blockchain; and the block data can further include block Block header data, block transaction data in the block, and transaction receipts corresponding to the block transaction data in the block, and so on.
  • the node device of the blockchain When the node device of the blockchain stores the various blockchain data shown above, it can usually organize the above various blockchain data in the form of key-value key-value pairs into a Merkle tree and store them in the database.
  • the key of the above-mentioned various blockchain data can be used as a query index, and the above-mentioned Merkle tree can be traversed to efficiently query the data.
  • the contract data stored in the storage space corresponding to the smart contract is organized into a Merkle tree in the form of key-value key-value pairs and stored in the database; the Merkle The data content stored in each leaf node of the tree is further organized into a Merkle subtree corresponding to the Merkle tree; wherein, the Merkle tree and the Merkle subtree are multi Layer tree storage structure, including at least one layer of character nodes and one layer of leaf nodes; the character nodes are used to store the characters in the string corresponding to the key of the contract data; the leaf nodes are used to store the contract data Value; the nodes on the Merkle tree and the Merkle subtree are linked to the nodes on the upper layer by filling the hash value of the node in the nodes on the upper layer; the method includes: receiving A query request for the contract data stored in the storage space corresponding to the smart contract; wherein, the query request includes the key of the queried target contract data; the string
  • This specification also proposes a traversal device for smart contract storage content, and the contract data stored in the storage space corresponding to the smart contract is organized into a Merkle tree in the form of key-value key-value pairs and stored in the database;
  • the data content stored in each leaf node of the Merkle tree is further organized into a Merkle subtree corresponding to the Merkle tree; wherein, the Merkle tree and the Merkle subtree are both tree structures that incorporate a Trie dictionary tree
  • a multi-layer tree storage structure including at least one layer of character nodes and one layer of leaf nodes; the character nodes are used to store the characters in the string corresponding to the key of the contract data; the leaf nodes are used to store the contract
  • the Value of the data; the nodes on the Merkle tree and the Merkle subtree are linked to the nodes on the upper layer by filling the hash value of the node in the nodes on the upper layer;
  • the device includes: a receiving module , receiving a query request for the contract data stored in the storage
  • the contract data is When querying, the traversal of the data content stored in the leaf node will be converted into the traversal of a Merkle subtree, so the traversal efficiency of the data content stored in the leaf node can be improved.
  • Fig. 1 is a schematic diagram of organizing blockchain data into an MPT state tree provided by an exemplary embodiment
  • Fig. 2 is a schematic diagram of organizing the contract data stored in the storage space corresponding to the contract account into an MPT storage tree provided by an exemplary embodiment
  • Fig. 3 is a flow chart of a method for traversing smart contract storage content provided by an exemplary embodiment
  • Fig. 4 is a schematic diagram of extending a two-layer Merkle Tree architecture to a three-layer Merkle Tree architecture provided by an exemplary embodiment
  • FIG. 5 is a tree structure diagram of an FDMT tree provided by an exemplary embodiment
  • Fig. 6 is a structural diagram of a character node provided by an exemplary embodiment
  • Fig. 7 is a structural diagram of a bucket data bucket provided by an exemplary embodiment
  • Fig. 8 is a structural diagram of another bucket data bucket provided by an exemplary embodiment
  • Fig. 9 is a schematic diagram of setting node IDs for nodes on the Merkle tree provided by an exemplary embodiment
  • Fig. 10 is a schematic structural diagram of an electronic device provided by an exemplary embodiment
  • Fig. 11 is a block diagram of a device for traversing smart contract storage content provided by an exemplary embodiment.
  • Blockchains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain.
  • Public Blockchain Private Blockchain
  • Consortium Blockchain there can be a combination of the above types, such as private chain + alliance chain, alliance chain + public chain, etc.
  • the public chain has the highest degree of decentralization. Participants joining the public chain (also known as nodes in the blockchain) can read data records on the chain, participate in transactions, and compete for the accounting rights of new blocks. Moreover, each node can freely join or exit the network and perform related operations.
  • the private chain the write permission of the network is controlled by an organization or institution, and the data read permission is regulated by the organization.
  • a private chain can be a weakly centralized system with strict restrictions on nodes and a small number of nodes. This type of blockchain is more suitable for internal use by specific institutions.
  • the alliance chain is a blockchain between the public chain and the private chain, which can realize "partial decentralization".
  • Each node in the consortium chain usually has a corresponding entity or organization; nodes join the network through authorization and form an alliance of stakeholders to jointly maintain the operation of the blockchain.
  • the blockchain is usually composed of several blocks. Time stamps corresponding to the creation time of the block are respectively recorded in these blocks, and all blocks form a time-ordered data chain in strict accordance with the time stamps recorded in the block.
  • the data generated outside the chain it can be constructed into a standard transaction format supported by the blockchain, and then published to the blockchain.
  • the node devices in the blockchain will agree on the transaction and reach a After the consensus, the node device as the bookkeeping node in the blockchain will pack the transaction into a block and store the certificate persistently in the blockchain.
  • Account In the field of blockchain, an important concept is account (Account); in practical applications, accounts can usually be divided into two types: external accounts and contract accounts; external accounts are accounts directly controlled by users, also known as A user account; a contract account is an account created by a user through an external account and contains a contract code (that is, a smart contract).
  • external accounts are accounts directly controlled by users, also known as A user account
  • contract account is an account created by a user through an external account and contains a contract code (that is, a smart contract).
  • a structure is usually used to maintain the account status of the account.
  • the state of the account associated with the transaction in the blockchain usually also changes.
  • the account structure usually includes fields such as Balance, Nonce, Code, and Storage.
  • the Balance field is used to maintain the current account balance of the account
  • the Nonce field is used to maintain the number of transactions of the account; it is a counter used to ensure that each transaction can and can only be processed once, effectively avoiding replay attacks
  • the Code field is used to maintain the contract code of the account; in practical applications, only the hash value of the contract code is usually maintained in the Code field; therefore, the Code field is usually also called the Codehash field.
  • the Storage field is used to maintain the storage content of the account; for a contract account, an independent persistent storage space is usually allocated to store the contract data stored in the storage space corresponding to the contract account; the independent storage The space is usually called the account storage of the contract account.
  • the storage content of the contract account is usually constructed as a MPT (Merkle Patricia Trie) tree data structure in the form of key-value key-value pairs and stored in the above independent storage space.
  • the MPT tree is a logical tree structure used to store and maintain blockchain data in the blockchain field. This tree structure usually includes root nodes, intermediate nodes, and leaf nodes.
  • the MPT tree constructed based on the storage content of the contract account is usually also called the Storage tree.
  • the Storage field usually only maintains the hash value of the root node of the Storage tree; therefore, the Storage field is usually also called the Storage Root hash field.
  • the field values of the Code field and the Storage field shown above are all null values.
  • Merkle trees are usually used; or logical tree structures such as Merkle tree variants based on the Merkle tree data structure are used to store and maintain data.
  • the MPT tree is a Merkle tree variant that is used to store and maintain blockchain data and incorporates the tree structure of the Trie dictionary tree.
  • MPT state tree ie world state
  • MPT transaction tree and MPT receipt tree in the form of key-value key-value pairs respectively.
  • the contract data stored in the storage space corresponding to the contract account is usually constructed into an MTP Storage tree (hereinafter referred to as the Storage tree).
  • the hash value of the root node of the Storage tree will be added to the Storage field in the above structure of the contract account corresponding to the Storage tree.
  • the MPT state tree is an MPT tree organized by the account state (state) data of all accounts (including external accounts and contract accounts) in the blockchain in the form of key-value key-value pairs; the MPT transaction tree is composed of The transaction data in the block chain is an MPT tree organized in the form of key-value key-value pairs; the MPT receipt tree is the transaction (receipt) corresponding to each transaction generated after the transaction in the block is executed. ) receipt, an MPT tree organized in the form of key-value key-value pairs.
  • the hash values of the root nodes of the MPT state tree, MPT transaction tree and MPT receipt tree shown above will eventually be added to the block header of the corresponding block.
  • the MPT transaction tree and MPT receipt tree correspond to blocks, that is, each block has its own MPT transaction tree and MPT receipt tree.
  • the MPT state tree is a global MPT tree, which does not correspond to a specific block, but covers the account state data of all accounts in the blockchain. Every time the blockchain generates a newest block, after the transactions in the latest block are executed, the account status of the accounts (which can be external accounts or contract accounts) related to these executed transactions in the blockchain, usually It will also change accordingly.
  • the balances of the transfer-out account and transfer-in account related to the "transfer transaction” usually also Will change accordingly.
  • the node device After the transaction of the node device in the latest block generated by the blockchain is completed, because the account status in the current blockchain has changed, the node device needs to build an account based on the current account status data of all accounts in the blockchain.
  • the MPT state tree is used to maintain the latest state of all accounts in the blockchain.
  • each block in the blockchain has a corresponding MPT state tree; the MPT state tree maintains all accounts in the blockchain after the transactions in the block are executed. account status.
  • FIG. 1 is a schematic diagram of organizing the account state data of each blockchain account in the blockchain into an MPT state tree in the form of key-value key-value pairs shown in this specification.
  • the MPT tree is a more traditional and improved variant of the Merkle tree, which combines the advantages of the two tree structures of the Merkle tree and the Trie dictionary tree (also known as the prefix tree).
  • nodes in the MPT tree There are usually three kinds of nodes in the MPT tree, which are leaf nodes, extension nodes and branch nodes.
  • the root node of the MPT tree may generally be an extended node; the intermediate node of the MPT tree may generally be a branch node or other extended nodes.
  • the extension node and the branch node can be collectively referred to as a character node, which is used to store the character prefix part of the string corresponding to the key of the account state data (that is, the account address); wherein, for the MPT tree, the above character prefix part usually refers to Shared character prefix:
  • the shared character prefix refers to a prefix composed of the same one or more characters that all account state data keys (ie blockchain account addresses) have.
  • the above-mentioned leaf nodes are used to store the character suffix part and Value (that is, the specific account status data) of the character string corresponding to the key of the blockchain data.
  • the extension node is used to store one or more characters in the shared character prefix of the account address (that is, the shared nibble shown in Figure 1), and the hash value of the node on the next layer linked to the extension node (that is, the hash value shown in Figure 1 Next node).
  • Branch node including 17 slots, the first 16 slots correspond to 16 possible hexadecimal characters in the key, one character corresponds to a nibble (nibble), each of the first 16 slots Bits, respectively represent a character in the shared character prefix of an account address, and these slots are used to fill the hash value of the node of the next layer linked by the branch node.
  • the last slot is the value slot, which is generally empty.
  • the leaf node is used to store the character suffix of the account address (that is, the key-end shown in Figure 1), and the value of the account status data (that is, the structure of the account described above); wherein, the character suffix of the account address and the account address
  • the shared character prefixes together form a complete account address; the character suffix refers to the suffix composed of the last one or more characters except the shared character prefix of the account address.
  • the blockchain account corresponding to the account address in the first three rows is an external account, and the Codehash and Storage root fields are empty.
  • the blockchain account corresponding to the account address in line 4 is a contract account, and the Codehash field maintains the hash value of the contract code corresponding to the contract account; the Storage root field maintains the root node of the Storage tree composed of the storage content of the contract account hash value.
  • the MPT state tree is organized according to the account state data in Table 1, as shown in Figure 1; the MPT state tree is composed of 4 leaf nodes, 2 branch nodes, and 2 extension nodes (one of the extension nodes is used as the root node) form.
  • the prefix field is a prefix field common to both the extension node and the leaf node. Different field values of the prefix field can be used to represent different node types.
  • the value of the prefix field is 0, indicating an extended node that contains an even number of nibbles; as mentioned above, a nibble represents a nibble, which is composed of 4 binary bits, and a nibble can correspond to a character that constitutes an account address.
  • the value of the prefix field is 1, which means the expansion node contains an odd number of nibble(s); the value of the prefix field is 2, which means the leaf node contains an even number of nibbles; the value of the prefix field is 3, which means it contains an odd number of nibbles (s) leaf node.
  • the branch node since it is a character node with a single nibble in parallel, the branch node does not have the above-mentioned prefix field.
  • the Shared nibble field in the extension node corresponds to the key value of the key-value pair contained in the extension node, indicating the common character prefix between account addresses; for example, all account addresses in the above table have a common character prefix a7.
  • the hash value (hash pointer) of the next node is filled in the Next Node field.
  • the hexadecimal character 0 ⁇ f field in the branch node corresponds to the key value of the key-value pair contained in the branch node; if the branch node is an intermediate node on the search path of the account address on the MPT tree, the branch node
  • the Value field can be empty. The hash value used to fill the next layer of nodes in the 0 ⁇ f field.
  • Key-end in the leaf node corresponds to the key value of the key-value pair contained in the leaf node, indicating the last few characters of the account address (the character suffix of the account address).
  • the key value of each node on the search path from the root node to the leaf node constitutes a complete account address.
  • the Value field of the leaf node is filled with the account status data corresponding to the account address; for example, the above-mentioned structure composed of fields such as Balance, Nonce, Code, and storage can be encoded and then filled into the Value field of the leaf node.
  • the nodes on the MPT state tree as shown in Figure 1 are finally stored in the database in the form of Key-Value key-value pairs; wherein, when the nodes on the MPT state tree are stored in the database, the MPT state
  • the key in the key-value pair of the node on the tree can be the hash value of the data content contained in the node; the Value in the key-value pair of the node on the MPT state tree is the data content contained in the node.
  • the hash value of the data content contained in the node can be calculated (that is, the hash calculation is performed on the node as a whole), and the calculated hash value can be used as the key to store the data contained in the node.
  • the data content of the key is used as value to generate a Key-Value key-value pair; then, the generated Key-Value key-value pair is stored in the database.
  • the nodes on the MPT state tree are stored in the form of Key-value key-value pairs; among them, the Key can be the hash value of the data content contained in the node, and the Value can be the data content contained in the node; therefore, when you need to query For nodes on the MPT state tree, content addressing can usually be performed based on the hash value of the data content contained in the node as a key.
  • Figure 2 is a schematic diagram of organizing the contract data stored in the storage space corresponding to the contract account into an MPT storage tree shown in this specification.
  • the account whose account address is "a77d397" shown in Table 1 is a contract account, so the contract data stored in the storage space corresponding to the contract account will be organized into a storage tree; where the storage tree The hash value S1 of the root node will be added to the storage root field in the leaf node corresponding to the contract account in the MTP state tree shown in Figure 1.
  • the contract data stored in the storage space of the contract account can usually be in the form of state variables; when storing, the state variable names can be organized into a storage tree as shown in Figure 2 in the form of key-value key-value pairs for storage .
  • the account address of the contract account and the hash value of the storage location of the state variable in the account storage of the contract account can be used as the key, and the value of the variable corresponding to the state variable can be used as the value.
  • the basic structure of the storage tree shown in FIG. 2 is similar to the MTP state tree shown in FIG. 1 , and will not be repeated in this specification. From the descriptions in Figure 1 and Figure 2 above, it can be known that based on the tree structure design of the MPT tree, the branch node can store one of the shared character prefixes of all account addresses; and the extension node can store the shared character prefixes of all account addresses One or more characters in .
  • the bucket data bucket structure is usually used, which can store several key-value key-value pairs;
  • the contract account since the contract account usually has a larger storage space than the external account; therefore, a large amount of user data is usually stored in the account storage space corresponding to the contract account, and based on actual business needs, it may also be necessary to Traversing several key-value key-value pairs stored in the leaf nodes on the above storage tree; For the smart contract, store the data in the account storage space corresponding to the smart contract.
  • the user needs to query the user data stored in the account storage space corresponding to the smart contract, he can find the leaf node where the data is located on the above storage tree, and then traverse several key-value key-value pairs stored in the leaf node.
  • the key in the key-value key-value pair corresponding to the contract data is usually not used
  • the original key of the contract data but the hash value of the original key of the contract data is used as the key; for example, the contract data can no longer be organized into the above storage tree in the form of ⁇ key, Value>; instead, it can be organized in the form of ⁇ Hash(key), The form of Value> is organized into the above storage tree.
  • the key-value key corresponding to the account state data usually does not use the original key of the account status data, but uses the hash value of the original key of the account status data as the key, so I won’t repeat it here.
  • this specification proposes a way to organize the data content stored on the leaf nodes of the Merkle tree that stores contract data into Merkle subtrees corresponding to the Merkle tree, so as to improve the accuracy of the above-mentioned leaves.
  • a technical solution for the efficiency of traversing the data content stored on the node proposes a way to organize the data content stored on the leaf nodes of the Merkle tree that stores contract data into Merkle subtrees corresponding to the Merkle tree, so as to improve the accuracy of the above-mentioned leaves.
  • the two-layer Merkle Tree architecture shown in Figure 1 and Figure 2 can be transformed into a three-layer Merkle Tree architecture.
  • the contract data stored in the storage space corresponding to the smart contract it can still be organized into a Merkle tree in the form of key-value key-value pairs and stored in the database; wherein, the data content stored in each leaf node of the Merkle tree can be It is further organized into a Merkle subtree corresponding to the Merkle tree; the above Merkle tree and the above Merkle subtree can still be a multi-layer tree storage structure similar to the MPT tree, which combines the tree structure of the Trie dictionary tree, and can Contains at least one layer of character nodes and one layer of leaf nodes; the above-mentioned character nodes are used to store at least part of the characters in the string corresponding to the key of the contract data; the above-mentioned leaf nodes are used to store the Value of the contract data; for example, in In an example, the character string corresponding to the key of the above-mentioned contract data can include a character prefix and a character suffix; the character node of the above-mentioned Merkle
  • a query request for the above-mentioned contract data can be received; wherein, the query request includes the key of the target contract data to be queried; the key of the above-mentioned contract data corresponds to
  • the character string can include a character prefix and a character suffix; further, starting from the root node of the above Merkle tree, traversing the above Merkle tree, searching in the above Merkle tree, character nodes matching the characters in the above character prefix, and searching The first leaf node corresponding to the above-mentioned character node obtained; after finding the above-mentioned first leaf node, the Merkle subtree corresponding to the data content stored in the above-mentioned first leaf node can be further traversed, from the root node of the above-mentioned Merkle subtree At the beginning, search in the above Merkle subtree, the character node matching the character in the above character suffix, and the
  • FIG. 3 is a flowchart of a method for traversing smart contract storage content provided by an exemplary embodiment.
  • the method is applied to a blockchain node device; the contract data stored in the storage space corresponding to the smart contract is organized into a Merkle tree in the form of a key-value key-value pair and stored in the database; wherein, the Merkle The data content stored in each leaf node of the tree is further organized into a Merkle subtree corresponding to the Merkle tree; the method includes the following steps: Step 302, receiving the contract data stored in the storage space corresponding to the smart contract query request; wherein, the query request includes the key of the queried target contract data; the string corresponding to the key of the contract data includes a character prefix and a character suffix; step 304, in response to the query request, from the Starting from the root node of the Merkle tree, traversing the Merkle tree, searching in the Merkle tree, the character node matching the character in the character prefix, and the first leaf node corresponding to
  • the above-mentioned Merkle tree may specifically include Merkle tree variants of any form that incorporates the tree structure of the Trie dictionary tree; The MPT tree; or, it can also be other types of Merkle tree variants that incorporate the tree structure of the Trie dictionary tree.
  • the node devices in the blockchain can organize the contract data stored in the storage space corresponding to the smart contract into a Merkle tree (that is, the above-mentioned Storage tree) in the form of key-value key-value pairs for storage; for example, in the initial state , the blockchain node device can initialize an empty Merkle tree in memory. After obtaining the contract data that needs to be stored, it can process the contract data into key-value key-value pairs, and then the key-value key The value pair is written into the empty Merkle tree, and finally the nodes on the Merkle tree in memory are persistently stored in the database by executing commands such as commit.
  • a Merkle tree that is, the above-mentioned Storage tree
  • the blockchain node device can initialize an empty Merkle tree in memory. After obtaining the contract data that needs to be stored, it can process the contract data into key-value key-value pairs, and then the key-value key The value pair is written into the empty Merkle tree, and finally the nodes on the Merkle tree in memory are persistently stored
  • the above-mentioned Merkle tree is still a logical tree, and the storage structure of the nodes on the above-mentioned Merkle tree is also a logical storage structure;
  • the so-called logical tree structure refers to the In the underlying physical storage of the database, there is no physical storage structure that completely corresponds to the tree structure, but only the physical data of each node on the above tree structure and the link relationship data between each node are stored in the database, so that Based on the physical data and link relationship data of each node stored in the database, the above tree structure is restored on a logical level.
  • the key of the above contract data may specifically refer to the search key value corresponding to the contract data in the database; in practical applications, the above search key value may specifically be a string corresponding to the contract data; for example, the above search key value may specifically be The string corresponding to the contract address; correspondingly, the Value of the above-mentioned contract data can be the original content of the above-mentioned contract data; for example, in an example, the above-mentioned key can be the hash value of the state variable name; the above-mentioned Value can be specifically The variable value of the state variable.
  • the key of the above-mentioned contract data can still include the character prefix part (Shared nibble) and the character suffix part (key-end); wherein, the character prefix part of the key of the contract data can be the key and the character suffix part of the contract data
  • the shared character prefix of the keys of other contract data for example, see the contract data "fa99365" and “fa6be33" in Table 2 above have a shared character prefix "f”.
  • the character suffix part of the key of the above-mentioned contract data can be the character part of the character string corresponding to the key of the contract data, except the part of the above-mentioned character prefix.
  • the character prefix part of the key of the contract data may not be a shared character prefix; for example, for the MPT tree, the character prefix part of the above key is usually a shared Merkle tree variant of the tree structure of the Trie dictionary tree, the character prefix part of the above key may not be the shared character prefix.
  • the character length of the character prefix part of the above contract data key can also be exactly the same as the character length corresponding to the above contract data key; in this case, the character suffix part of the above contract data key can be a null value (ie does not include the suffix part); at this time, the above-mentioned leaf nodes can only store the value corresponding to the contract data.
  • the first N layers of the above-mentioned Merkle tree can be character nodes used to store the characters in the string corresponding to the key of the above-mentioned contract data; the last layer of the above-mentioned Merkle tree can be used to store the above-mentioned contract data The leaf node of value.
  • the character nodes in the first N layers of the above-mentioned Merkle tree can also store at least part of the characters in the string corresponding to the key of the above-mentioned contract data; then the leaf nodes in the last layer of the above-mentioned Merkle tree can store Store key-value key-value pairs consisting of at least some characters other than the above-mentioned characters and the value of the above-mentioned contract data; in practical applications, the above-mentioned leaf nodes can usually adopt the structure of a bucket data bucket, and can store several items for storing the above-mentioned contracts The data record of the value of the data.
  • the above-mentioned data record includes the above-mentioned A key-value key-value pair composed of at least some characters other than the remaining characters and the value of the above contract data.
  • the above two-layer Merkle Tree architecture can be further extended to a three-layer Merkle Tree architecture.
  • Fig. 4 is a schematic diagram of further extending the above-mentioned two-layer Merkle Tree architecture to a three-layer Merkle Tree architecture shown in this specification;
  • the data content stored in each leaf node of the above-mentioned storage tree can be further organized into storage subtrees corresponding to the above-mentioned storage tree (ie, the above-mentioned Merkle subtree); for example , in one embodiment shown, because the key of the above-mentioned contract data usually includes a character prefix part and a character suffix part; therefore, the data content stored in the character node in the above-mentioned storage tree can be the character in the above-mentioned character prefix;
  • the data content stored in the leaf nodes of the above-mentioned storage tree can be used to store key-value key-value pairs composed of the above-mentioned character suffix and the value of the above-mentioned contract data
  • the blockchain node device When the blockchain node device organizes the data content stored in the leaf nodes of the above storage tree into a storage subtree, it can initialize an empty Merkle tree in memory as the above storage subtree, and store the data that should have been stored in the leaf node The above key-value key-value pairs stored in , are further written into the above empty storage subtree, and finally the storage subtree in the memory is persistently stored in the database by executing commands such as commit, and then the above Figure 1 and The architecture of the two-layer Merkle Tree shown in Figure 2 is extended to the architecture of the three-layer Merkle Tree shown in Figure 4.
  • the three-layer Merkle Tree architecture shown in Figure 4 the upper Merkle Tree is still a state tree organized by the state data corresponding to all blockchain accounts, and the middle layer is each contract on the above state tree The storage tree organized by the contract data stored in the account storage space corresponding to the account; and the bottom layer is the storage subtree corresponding to the above storage tree organized by the data content stored by each leaf node on the above storage tree.
  • the quantity of the above-mentioned storage subtree usually corresponds to the quantity of the leaf nodes contained in the above-mentioned storage tree.
  • the storage structure of the above-mentioned storage subtree is the same as the above-mentioned storage tree, and the first N layers of the above-mentioned storage subtree can still be character nodes used to store the characters in the string corresponding to the key of the above-mentioned contract data; the above-mentioned storage subtree The last layer of can be the leaf node used to store the value of the above contract data.
  • the key of the above-mentioned contract data usually includes a character prefix part and a character suffix part; therefore, the character nodes in the above-mentioned storage tree can be used to store the characters in the above-mentioned character prefix; the above-mentioned storage tree
  • the leaf node of can be used to store key-value key-value pairs composed of the above character suffix and the value of the above contract data.
  • the character nodes in the above storage subtree can be used to store the characters in the above character suffix; the leaf nodes of the above storage subtree can be used to store the value of the above contract data.
  • the character node of the above-mentioned storage subtree can also be used to store some characters in the above-mentioned character suffix; in this case, if the character node in the above-mentioned storage tree stores the characters in the above-mentioned character suffix
  • the leaf nodes of the above-mentioned storage subtree can be used to store key-value pairs consisting of the remaining characters in the above-mentioned character suffix other than the above-mentioned partial characters and the value of the above-mentioned contract data.
  • the hash value of the root node of the above Storage tree is usually written into the Storage field in the account structure of the contract account corresponding to the above Storage tree in the above state tree; correspondingly, in the above Storage tree
  • the hash value of the root node of the storage subtree can also be filled into the upper layer character node linked to the leaf node.
  • the upper layer prefix node linked to the leaf node on the Storage tree above is usually filled with the hash value of the leaf node; while the data content stored in the leaf node in the Storage tree above is organized into After the storage subtree corresponding to the above Storage tree, the hash value of the leaf node filled in the character node of the upper layer linked to the leaf node can be replaced with the hash value of the root node of the storage subtree.
  • the above-mentioned storage sub-tree may also specifically include any form of Merkle tree variant that combines the tree structure of the Trie dictionary tree; in one embodiment shown, the above-mentioned storage tree and the above-mentioned storage
  • the subtrees can all be the MPT trees described above in Figure 1 and Figure 2; or, at least one of the above storage trees and the above storage subtrees can be the above MPT trees, while the other can be other types of integrated Trie Merkle tree variant of the trie tree structure.
  • the storage tree and the storage subtree may use the same type of Merkle tree variants, or different types of Merkle tree variants.
  • the above-mentioned storage tree and the above-mentioned storage subtree may also be FDMT (Fixed Depth Merkle Tree) trees; or, at least one of the above-mentioned storage tree and the above-mentioned storage subtree may be the above-mentioned
  • the FDMT tree and the other can be other types of Merkle tree variants (such as MPT trees) that incorporate the tree structure of the Trie dictionary tree.
  • the FDMT tree is a Merkle tree variant with a fixed number of layers of character nodes in the first N layers and a tree structure of the Trie dictionary tree that is proposed to avoid frequent splitting of the character nodes in the first N layers. .
  • FIG. 5 is a tree structure diagram of an FDMT tree shown in this specification.
  • each character node in the first N layers of the above-mentioned FDMT tree will adopt a unified data structure, so that each character node in the first N layers of the above-mentioned FDMT tree will no longer undergo node splitting.
  • the character nodes of the first N layers on the above-mentioned FDMT tree can include a plurality of blocks representing different characters respectively; and each block can further include a plurality of slots representing different characters respectively; for example, 5 shows that each character node includes N blocks; each block further includes N slots.
  • the way of filling the hash value (hash pointer) of the node of the next layer in the node of the upper layer can still be used to carry out the link between the nodes. That is, the nodes on the FDMT tree are still linked to the nodes on the upper layer through their hash values; it should be explained that the link relationship between the nodes on the above-mentioned FDMT tree shown in Figure 5 is only for illustration It does not refer to a special limitation on the link relationship between the nodes of each layer on the above-mentioned FDMT tree.
  • the above slots can be specifically used to fill the hash value of the next layer node to which the current character node is linked.
  • the next layer node of the character node can still be the character node of the next layer or the leaf node of the next layer.
  • each character node on the above-mentioned FDMT tree shown in FIG. 5 can be used to store at least some characters in the character prefix of the key of the above-mentioned blockchain data.
  • the character actually stored in each character node can be specifically the character represented by a block (that is, a non-empty block with at least one slot filled with a hash value) in the character node, and the slot filled with a hash value in the block ( That is, characters represented by non-empty slots) are spliced to generate a string.
  • each block in the character node can only represent a character; that is, based on the specific storage format of the character node shown in Figure 5, the above-mentioned blockchain data actually stored in each character node Part of the characters in the character prefix of the key is a string of 2 characters.
  • Fig. 6 is a structural diagram of a character node shown in this specification; as shown in Fig. 6, the character node contains 16 blocks representing different hexadecimal characters; each block further includes 16 slots representing different hexadecimal characters respectively (only 16 slots contained in block6 are shown in Figure 6); assuming that block6 (representing the hexadecimal character 6) in the character node is a non-empty block, slot4 (representing hexadecimal character 4), slot6 (representing hexadecimal character 6) and slot9 (representing hexadecimal character 9) in this block are the hashes of the next layer nodes that are filled with the character node link The non-empty slot of the value; then some characters in the character prefix of the key of the above blockchain data stored by the character node are the hexadecimal strings "64", "66” and "69".
  • the number of blocks contained in the above-mentioned character nodes and the number of slots contained in each block are not particularly limited in this specification; in practical applications, the key corresponding to the above-mentioned blockchain data can be used
  • the number of types of character elements contained in the string is used to determine the number of blocks contained in the above character nodes; and the number of slots contained in the block; for example, suppose the key corresponding to the above blockchain data is a hexadecimal character At this time, the number of types of character elements contained in the character string corresponding to the key of the above blockchain data is 16; then the number of blocks contained in the above character node and the number of slots contained in each block are the same as Can be 16.
  • the number of blocks contained in the above-mentioned character nodes and the number of slots contained in the above-mentioned blocks can remain the same; for example, in an example, the string corresponding to the key of the above-mentioned blockchain data is Hexadecimal character strings are taken as an example.
  • the above-mentioned character nodes of the first N layers may each include 16 blocks representing different hexadecimal characters; and each block may further include 16 blocks representing different Slots for hexadecimal characters.
  • the character nodes on the FDMT tree shown in FIG. 5 are compared to those shown in FIG. 1
  • the node used to store the character prefix on the MPT tree will have a larger storage capacity.
  • the number of blocks contained in the above-mentioned character nodes and the number of slots contained in the above-mentioned blocks may also be different; for example, in practical applications, the key corresponding to the above-mentioned blockchain data
  • a string can also be a string composed of two different base characters; for example, the string corresponding to the key of the above-mentioned blockchain data can be specifically composed of a mixture of hexadecimal characters and decimal characters character string, in this case, the above-mentioned character nodes of the first N layers may each include 16 blocks representing different hexadecimal characters; and each block may further include 10 blocks representing different decimal characters respectively slots; or, the above-mentioned character nodes of the first N layers may each include 10 blocks representing different decimal characters; and each block may further include 16 slots representing different hexadecimal characters.
  • the number of layers of character nodes contained in the FDMT tree may be a fixed value; in practical applications, the value of N may be an integer greater than or equal to 1; That is, the above-mentioned FDMT tree may specifically be a Merkle tree containing at least one layer of character nodes, and the number of layers of the character nodes contained is relatively fixed.
  • the contract account address supported by the blockchain system is designed so that the first 6 address characters can be the same, then in this case, you can
  • the address characters of the first 6 digits of the blockchain account address are used as the character prefix of the blockchain account address; moreover, the length of the characters in the character prefix of the contract account address stored by the character node is 2 characters; therefore, the above Merkle
  • the tree can be designed as a tree structure containing three layers of character nodes.
  • each character node in the above-mentioned FDMT tree includes a plurality of blocks representing different characters respectively; Slots of different characters; therefore, through this design, each character node will have greater data storage capacity and data carrying capacity, so that when the character nodes in the above-mentioned FDMT tree are written into the database for storage; or, When accessing the character nodes in the above-mentioned Merkle tree stored in the database, the data storage capacity of the character nodes can be more adapted to the capacity of a single IO read and write of the storage medium carrying the above-mentioned database, so that the above-mentioned database can be fully utilized
  • the IO read and write capabilities of the storage medium itself improve the efficiency of data read and write; for example, taking the storage medium carrying the above database as a disk with a single physical sector size of 4KB as an example, assuming that the single IO read and write capacity of the disk is 4kb (one sector),
  • each character node in the tree structure of the FDMT tree shown in Figure 5 is more suitable for the single IO read and write capacity of the above-mentioned disk, and can make full use of the IO read and write of the disk itself ability to improve data read and write efficiency.
  • each character node in the FDMT tree adopts a unified data structure; for the character nodes of each layer in the above-mentioned FDMT tree, the character length of the character prefix of the key of the blockchain data actually stored is also will remain fixed; therefore, through this design, it is possible to avoid the frequent splitting of nodes due to the fact that the actual length of characters stored in each layer of character nodes is not fixed, so that the character nodes contained in the tree structure of the FDMT tree can be guaranteed
  • the number of layers is always in a relatively stable state; thirdly, due to this design, each character node will have greater data storage capacity and data carrying capacity; and, the tree structure of the above FDMT tree contains The number of layers of character nodes will be in a relatively stable state; therefore, the improvement of the storage capacity of character nodes and the relatively stable number of layers of character nodes can ensure that the character nodes of the above FDMT tree will have fewer The number of layers; thus, on the basis that the character nodes have greater data storage capacity
  • the storage medium when the character nodes of the first N layers of the above-mentioned FDMT tree are loaded into the memory as data that needs to be frequently read, it can significantly reduce the number of character nodes stored in the above-mentioned storage medium.
  • the FDMT tree shown in Figure 5 is fixed for 3 layers of character nodes, and the character nodes of each layer include 16 blocks representing different hexadecimal characters; each block further includes 16 blocks representing different 16 characters
  • the system is cold started and reads the first N layers of the Merkle tree into the memory, it usually reads them layer by layer; therefore, based on the MPT tree shown in Figure 1,
  • the reading efficiency is very low; therefore, even according to the MPT tree and
  • the FDMT tree shown in FIG. 5 stores the same data, and the number of IO reads for the MPT tree during the cold start of the system may be at least 8 times the number of IO reads for the FDMT tree shown in FIG. 5 .
  • the leaf node of the last layer in the tree structure of the FDMT tree shown in Figure 5 (that is, the Leaf node shown in Figure 5) is specifically used to store the character of the key of the above-mentioned blockchain data suffix; and the value of the above blockchain data.
  • the data actually stored by the above-mentioned leaf nodes usually has a larger data capacity than the above-mentioned character nodes; for example, the value of the above-mentioned blockchain data actually stored by the above-mentioned leaf nodes is usually the above-mentioned blockchain data Compared with the character prefix of the above-mentioned blockchain data, the original content of the above-mentioned blockchain data occupies a larger storage space; therefore, in this specification, in order to ensure that the above-mentioned leaf nodes can have more Large data capacity, the above-mentioned leaf nodes can specifically store data in the form of large data blocks.
  • the specific form and storage structure of the above-mentioned data blocks are not particularly limited in this specification; in one embodiment shown, the above-mentioned leaf nodes can still adopt the storage form of bucket data buckets; wherein, the above-mentioned buckets can specifically It is a container or storage space for storing data.
  • FIG 7 is a structural diagram of a bucket data bucket shown in this specification; as shown in Figure 7, in the above bucket data bucket (ie, the bucker node shown in Figure 7), several Data records; wherein, the above-mentioned several data records contained in the above-mentioned bucket data bucket are logically no longer a whole, but several different data records that are logically separated.
  • Each data record corresponds to a block chain data, which is used to store the character suffix (key-end) in the key of the above block chain data and the value of the above block chain data; that is, a data record refers to A storage record containing the character suffix in the key of the above blockchain data and the value of the above blockchain data.
  • the above-mentioned data record contained in the above-mentioned bucket data bucket may specifically be used to store the character suffix in the key of the above-mentioned blockchain data and the key-value of the value of the above-mentioned blockchain data Key-value pair;
  • the value of this key-value key-value pair can be the character suffix in the key of above-mentioned block chain data (namely the key-end shown in Fig.
  • the data content corresponding to the value two parts of the chain data; and the key of the key-value key-value pair can be the character suffix in the key of the above blockchain data and the data content corresponding to the value two parts of the above blockchain data hash value.
  • the key of the key-value key-value pair corresponding to the above data record contained in the bucket data bucket can be the character suffix of the blockchain account address and the corresponding account status
  • the hash value of the data content of the two parts of the data; the value of the key-value key-value pair can be the character suffix of the blockchain account address and the data content of the corresponding account status data.
  • All the contained data content is read into the memory as a whole, and then the character suffix of the account address to be read and the corresponding account status data are further searched in the memory; correspondingly, if it is necessary to write a new The character suffix of the account address and the corresponding account status data, or to update the account status data corresponding to a specific account address contained in the above bucket data bucket, you can directly use the character suffix of the new account address and the corresponding account State data to construct a key-value key-value pair, and write the key-value key-value pair to the above bucket data bucket; or, based on the character suffix of the specific account address and the corresponding account state data two parts of the data content
  • the hash value, content addressing in the database find the corresponding key-value key-value pair, and then write the updated account status data corresponding to the specific account address, and the original key-value key-value pair value can be updated.
  • the several key-value key-value pairs contained in the above-mentioned bucket data bucket in addition to logically separated data, for each key-value key-value pair key and value
  • it can also be logically separated data; that is, in practical applications, further logic can be performed on the key and value in each key-value key-value pair contained in the above bucket data bucket separate.
  • the specific way of further logically separating the key and value in each key-value key-value pair contained in the above-mentioned bucket data bucket is not limited in this specification; for example, in the illustrated implementation
  • the storage structure of the above bucket data bucket can be divided into a logically isolated data header part and a data body part, and the above data header part can centrally store the key, which centrally stores the value of each key-value key-value pair contained in the above bucket data bucket in the above data body part.
  • FIG. 8 is a structural diagram of another bucket data bucket shown in this specification; in the structure of the bucket data bucket shown in FIG. part) and the data body part (that is, the Body part shown in FIG. 8 ); the above-mentioned data header part and the above-mentioned data body part are two parts that are logically completely separated.
  • the above data header part is used to centrally store the keys in several key-value key-value pairs contained in the bucket data bucket;
  • the key is uniformly stored in the data header part of the bucket data bucket.
  • the above data body part is used to centrally store the values of several key-value key-value pairs contained in the bucket data bucket; that is, the several key-value key-value pairs contained in the bucket data bucket
  • the value in is stored uniformly in the data body part of the bucket data bucket.
  • the above-mentioned data header part and the above-mentioned data body part can respectively contain several logically separated data records; the data records contained in the above-mentioned data header part are used to store several keys contained in the bucket data bucket -value The key in the key-value pair; correspondingly, the data records contained in the above data body are used to store the values in several key-value key-value pairs contained in the bucket data bucket.
  • the number of data records included in the data header part and the number of data records included in the data body part can be in a one-to-one correspondence; for example, as shown in Figure 8, each data record included in the data header part, There may be a one-to-one correspondence with each data record included in the data body part in sequence; for example, the Nth data record included in the data header part corresponds to the Nth data record included in the data body part.
  • the data header part in the leaf nodes in the above-mentioned FDMT tree can be included
  • the hash value of the data content is used as the hash value of the leaf node; at this time, the leaf node on the above-mentioned FDMT tree can be linked to the character node on the upper layer through the hash value of the data content contained in its own data header.
  • the hash value is calculated for the content; because the data content contained in the data header part of the above bucket data bucket is usually much smaller than the data content contained in the data body part of the above bucket data bucket; therefore, in this way, the hash calculation can be significantly reduced The amount of calculation, thereby reducing the time required for hash calculation and improving the calculation efficiency of hash calculation;
  • the number of data records contained in the above-mentioned bucket data bucket is not particularly limited in this specification; in one implementation shown, the number of data records contained in the above-mentioned bucket data bucket can specifically be Custom configuration by the user.
  • the above-mentioned blockchain data as the latest account status data corresponding to the blockchain account in the blockchain
  • the key of the above-mentioned blockchain data is the address of the blockchain account as an example.
  • the above-mentioned bucket data Each data record in the bucket corresponds to the account status of a blockchain account; the number of data records in the bucket data bucket above actually represents that the bucket data bucket can accommodate the account carrying capacity of the blockchain account.
  • the user can flexibly customize the account carrying capacity of the above bucket data bucket; for example, in an example, the above bucket data bucket
  • the number of data records contained in can be configured by the user as 16 or 64, so that a single bucket data bucket can carry the status data of 16 or 64 blockchain accounts.
  • the above-mentioned node device is used to store the specific type of database of the above-mentioned Merkle tree, which is not particularly limited in this specification, and those skilled in the art can make flexible choices based on actual needs; in one implementation,
  • the above-mentioned database can specifically be a Key-Value type database; for example, in an example, the above-mentioned database can be a LevelDB database using a multi-layer storage structure; or a database based on the LevelDB architecture; for example, the Rocksdb database is a typical one based on A database for the LevelDB database schema.
  • the nodes on the above-mentioned Merkle tree may be further stored in the above-mentioned database in the form of Key-Value key-value pairs.
  • the above-mentioned database is usually stored in a persistent storage medium (such as a storage disk) carried on the above-mentioned node device;
  • the above-mentioned storage medium is a physical storage corresponding to the above-mentioned database;
  • the nodes on the above-mentioned Merkle tree can be further written into the storage medium carrying the above-mentioned database from the memory of the node device in the form of Key-Value key-value pairs.
  • the key of the above-mentioned Key-Value key-value pairs can specifically be the node ID of the node on the Merkle state tree;
  • the above-mentioned node ID may specifically include identification information that can uniquely identify the node on the above-mentioned Merkle tree; for example, in an implementation manner, the above-mentioned node ID may specifically be the hash value of the data content contained in the node on the above-mentioned Merkle tree; In this case, when it is necessary to query the nodes on the above Merkle tree, content addressing can be performed based on the hash value of the data content contained in the nodes as the key.
  • the above-mentioned node ID may specifically include the path information of the nodes on the above-mentioned Merkle tree in the above-mentioned Merkle tree; that is, the path information of the nodes on the above-mentioned Merkle tree in the above-mentioned Merkle tree is used as the The node ID of the node; wherein, the above-mentioned path information may specifically include any form of information that can describe the link relationship between the node and other nodes, and the position of the node on the above-mentioned Merkle tree; for example, please refer to Figure 9, Figure 9 A schematic diagram of setting node IDs for nodes on the Merkle tree shown in this specification; for a Merkle tree containing three-layer character nodes as shown in Figure 7, assuming that the node ID of the tree node as the root node is represented by 0x00, then The node ID of the bucket node shown in Figure 7 can be expressed as 0x00123456.
  • 0x00 is the node ID of the root node; 123456 refers to the path information of the above bucket node from the root node to the bucket node on the Merkle tree; 12 represents the second slot of the first block of the first layer tree node; 34 represents the fourth slot of the third block of the tree node on the second layer; 56 represents the sixth slot of the fifth block of the third layer tree node.
  • the link relationship between the bucket node and other nodes can be clarified, as well as the specific location of the bucket node in the above Merkle tree; for example, based on the node ID, it can be clarified that the bucket node link is in the third layer tree
  • the 6th slot of the 5th block of node; and the tree node of the third layer is linked to the 4th slot of the 3rd block of the tree node of the second layer; the tree node of the second layer is further linked in The first layer is the second slot of the first block of the tree node of the root node.
  • the specific slot where the node is located in the Merkle tree can be precisely located.
  • the above-mentioned node ID may specifically include the path information of the node on the above-mentioned Merkle tree in the above-mentioned Merkle tree, and the hash value of the data content contained in the node; that is, the above-mentioned Merkle tree
  • the path information of the node in the above Merkle tree, and the hash value of the data content contained in the node are used as the node ID of the node.
  • the string generated by concatenating the path information of the node in the above Merkle tree and the hash value of the data content contained in the node can be used as the node ID of the node; of course, in practical applications, in During the splicing process, other types of information other than the above-mentioned path information and the above-mentioned hash value can also be further introduced to generate a node ID; this description will not list them one by one.
  • the data query party when it needs to query the contract data stored in the storage space corresponding to the smart contract, it can generate a query request containing the key of the target contract data to be queried, wherein, as mentioned above, the target contract
  • the data key may include a character prefix part and a character suffix part; then, the query request may be sent to the node device.
  • the node device can respond to the query request, start from the root node of the above storage tree corresponding to the smart contract, traverse the storage tree, and search in the storage tree for the key of the above target contract data
  • the character node matched by the characters in the prefix of the character, and the first leaf node corresponding to the found character node; further, after the first leaf node is found, since the data content stored in the first leaf node has been It is organized into a storage subtree corresponding to the above storage tree; at this time, the storage subtree corresponding to the data content stored in the first leaf node can be further traversed, starting from the root node of the storage subtree and continuing in In the storage subtree, search for a character node matching the characters in the character suffix of the key of the target contract data, and a second leaf node corresponding to the found character node.
  • the node device After finding the above-mentioned second leaf node, the node device can further read the Value of the above-mentioned target contract data stored in the second leaf node, and return the found Value of the above-mentioned target contract data to the above-mentioned data query party That's it.
  • the hash value of the original key of the contract data can still be used as the key in the key-value key-value pair corresponding to the above contract data; but in practical applications, as a data query On the other hand, in its specific business process, it may be necessary to know the original key of the above contract data.
  • the original key of the above contract data can also be stored; that is, in the leaf node of the above storage subtree, store The corresponding relationship between the value of the above contract data and the original key of the above contract data.
  • the node device finds the above-mentioned second leaf node by traversing the above-mentioned storage tree and the above-mentioned storage subtree, it reads the original key of the above-mentioned target contract data and the Value of the above-mentioned contract data stored in the second leaf node, and reads The obtained original key of the above-mentioned target contract data and the value of the above-mentioned target contract data are returned to the above-mentioned data query party together.
  • the data content stored on the leaf node of the storage tree storing the contract data is also organized into a storage tree subtree corresponding to the storage tree; therefore, the data content stored in the leaf node is traversed
  • the traversal of the data content stored in the leaf node will be converted into a traversal of a storage tree subtree, so the traversal efficiency of the data content stored in the leaf node can be improved.
  • this specification also provides an embodiment of a smart contract storage content traversal device.
  • the embodiment of the device for traversing smart contract storage content in this specification can be applied to electronic equipment.
  • the device embodiments can be implemented by software, or by hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory for operation through the processor of the electronic device where it is located.
  • FIG. 10 it is a hardware structure diagram of the electronic device where the traversal device for traversing the stored content of the smart contract in this specification is located, except for the processor, memory,
  • the electronic device in which the device in the embodiment is located usually may also include other hardware according to the actual function of the electronic device, which will not be repeated here.
  • Fig. 11 is a block diagram of an apparatus for traversing smart contract storage content according to an exemplary embodiment of this specification.
  • the device 110 for traversing the content stored in the smart contract can be applied to the electronic device shown in Fig. 10, wherein the contract data stored in the storage space corresponding to the smart contract is represented by The form of the pair is organized into a Merkle tree and stored in the database; the data content stored in each leaf node of the Merkle tree is further organized into a Merkle subtree corresponding to the Merkle tree; wherein, the Merkle tree and the The Merkle sub-trees are all multi-layer tree-like storage structures that incorporate the tree structure of the Trie dictionary tree, including at least one layer of character nodes and one layer of leaf nodes; the character nodes are used to store the characters corresponding to the key of the contract data The characters in the string; the leaf node is used to store the Value of the contract data; the nodes on the Merkle tree and the Merkle subtree, by filling the hash value of the node in the node of the upper layer, and The nodes on the upper layer are linked; the device 110 includes: a receiving
  • the character nodes in the Merkle tree are used to store the characters in the character prefix; the leaf nodes of the Merkle tree are used to store the characters composed of the character suffix and the value of the contract data.
  • key-value key-value pair the character node in the Merkle subtree is used to store the character in the character suffix; the leaf node of the Merkle subtree is used to store the value of the contract data.
  • the leaf nodes of the Merkle subtree are used to store the characters in the character suffix A key-value key-value pair composed of the remaining characters other than some characters and the value of the contract data.
  • the hash value of the leaf node filled in the upper character node of the leaf node on the Merkle tree is the hash of the root node of the Merkle subtree corresponding to the data content stored by the leaf node value.
  • the Merkle tree; and/or, the Merkle subtree is an MPT tree.
  • the Merkle tree; and/or, the Merkle subtree is an FDMT tree; wherein, each character node in the FDMT tree includes a plurality of blocks representing different characters respectively; the block It further includes a plurality of slots respectively representing different characters; the slots are used to fill the hash value of the next layer node linked to the character node.
  • the number of layers of character nodes included in the FDMT tree is a fixed value.
  • the character stored in any character node in the FDMT tree is the character represented by the block in the character node, and the character represented by the slot filled with the hash value in the block, The string generated by splicing.
  • the number of blocks included in the character node is the same as the number of slots included in the block.
  • the character node includes 16 blocks respectively representing different hexadecimal characters; the block includes 16 slots respectively representing different hexadecimal characters.
  • the key of the contract data stored in the Merkle tree is the hash value obtained by performing hash calculation on the original key of the contract data;
  • the leaf node of the Merkle subtree also stores the key of the contract data The corresponding relationship between the original key and the value of the contract data;
  • the search module 1102 read the original key of the target contract data stored in the second leaf node and the value of the contract data, and read The obtained original key of the target contract data and the value of the target contract data are returned to the query party corresponding to the query request.
  • a typical implementing device is a computer, which may take the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, e-mail device, game control device, etc. desktops, tablets, wearables, or any combination of these.
  • a computer includes one or more processors (CPUs), input/output interfaces, network interfaces and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • Memory may include non-permanent storage in computer-readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • Computer-readable media including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information.
  • Information may be computer readable instructions, data structures, modules of a program, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by computing devices.
  • computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.
  • first, second, third, etc. may be used in one or more embodiments of the present specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of one or more embodiments of this specification, first information may also be called second information, and similarly, second information may also be called first information. Depending on the context, the word “if” as used herein may be interpreted as “at” or "when” or "in response to a determination.”

Abstract

Un procédé de traversée pour un contenu de stockage de contrat intelligent consiste à : recevoir une demande d'interrogation pour des données de contrat stockées dans un contrat intelligent, la demande d'interrogation comprenant une clé de données de contrat cibles ; en réponse à la demande d'interrogation, démarrer à partir d'un nœud racine d'un arbre de Merkle correspondant au contrat intelligent, traverser l'arbre de Merkle, et rechercher dans l'arbre de Merkle un nœud de caractère correspondant à un caractère dans un préfixe de caractères de la clé, et un premier nœud feuille correspondant au nœud de caractère recherché ; et après avoir recherché le premier nœud feuille, traverser en outre un sous-arbre de Merkle correspondant à un contenu de données stocké dans le premier nœud feuille, démarrer à partir d'un nœud racine du sous-arbre de Merkle, rechercher dans le sous-arbre de Merkle un nœud de caractère correspondant à un caractère dans un suffixe de caractères de la clé, et un second nœud feuille correspondant au nœud de caractère, et lire en outre la valeur des données de contrat cibles stockées dans le second nœud feuille.
PCT/CN2022/090486 2021-05-11 2022-04-29 Procédé et appareil de traversée pour contenu de stockage de contrat intelligent, et dispositif électronique WO2022237596A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110510926.5 2021-05-11
CN202110510926.5A CN113220685B (zh) 2021-05-11 2021-05-11 智能合约存储内容的遍历方法及装置、电子设备

Publications (1)

Publication Number Publication Date
WO2022237596A1 true WO2022237596A1 (fr) 2022-11-17

Family

ID=77094649

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/090486 WO2022237596A1 (fr) 2021-05-11 2022-04-29 Procédé et appareil de traversée pour contenu de stockage de contrat intelligent, et dispositif électronique

Country Status (2)

Country Link
CN (1) CN113220685B (fr)
WO (1) WO2022237596A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117056342A (zh) * 2023-10-10 2023-11-14 腾讯科技（深圳）有限公司 一种基于区块链的数据处理方法及相关设备

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112988910B (zh) * 2021-05-07 2021-09-24 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN113220685B (zh) * 2021-05-11 2022-04-19 支付宝(杭州)信息技术有限公司 智能合约存储内容的遍历方法及装置、电子设备
CN115174582B (zh) * 2022-09-06 2022-11-18 中国中金财富证券有限公司 数据调度方法及相关装置
CN116832439A (zh) * 2023-05-17 2023-10-03 广州三七极梦网络技术有限公司 一种游戏数据刷新系统的处理方法、装置、设备及介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190303541A1 (en) * 2018-04-02 2019-10-03 Ca, Inc. Auditing smart contracts configured to manage and document software audits
CN110569305A (zh) * 2019-08-27 2019-12-13 网易（杭州）网络有限公司 区块同步方法、装置、介质和计算设备
CN110800255A (zh) * 2019-03-04 2020-02-14 阿里巴巴集团控股有限公司 更新区块链世界状态默克尔帕特里夏字典树子树
CN110800008A (zh) * 2019-03-04 2020-02-14 阿里巴巴集团控股有限公司 构建区块链世界状态默克尔帕特里夏字典树子树
CN111488349A (zh) * 2020-04-08 2020-08-04 北京瑞策科技有限公司 基于业务数据区块链的数据查询方法及装置
CN113220685A (zh) * 2021-05-11 2021-08-06 支付宝(杭州)信息技术有限公司 智能合约存储内容的遍历方法及装置、电子设备

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108846133B (zh) * 2018-07-04 2020-11-27 东北大学 基于b-m树的区块链存储结构、b-m树建立算法及查找算法
US11734259B2 (en) * 2019-05-31 2023-08-22 International Business Machines Corporation Anonymous database rating update
US11294875B2 (en) * 2019-05-31 2022-04-05 Advanced New Technologies Co., Ltd. Data storage on tree nodes
US10778452B2 (en) * 2019-06-03 2020-09-15 Alibaba Group Holding Limited Blockchain ledger authentication
CN110334154B (zh) * 2019-06-28 2020-07-21 阿里巴巴集团控股有限公司 基于区块链的分级存储方法及装置、电子设备
US11113272B2 (en) * 2019-07-31 2021-09-07 Advanced New Technologies Co., Ltd. Method and apparatus for storing blockchain state data and electronic device
CN111737726A (zh) * 2020-04-08 2020-10-02 北京瑞策科技有限公司 基于业务数据区块链的关系数据查询方法及装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190303541A1 (en) * 2018-04-02 2019-10-03 Ca, Inc. Auditing smart contracts configured to manage and document software audits
CN110800255A (zh) * 2019-03-04 2020-02-14 阿里巴巴集团控股有限公司 更新区块链世界状态默克尔帕特里夏字典树子树
CN110800008A (zh) * 2019-03-04 2020-02-14 阿里巴巴集团控股有限公司 构建区块链世界状态默克尔帕特里夏字典树子树
CN110569305A (zh) * 2019-08-27 2019-12-13 网易（杭州）网络有限公司 区块同步方法、装置、介质和计算设备
CN111488349A (zh) * 2020-04-08 2020-08-04 北京瑞策科技有限公司 基于业务数据区块链的数据查询方法及装置
CN113220685A (zh) * 2021-05-11 2021-08-06 支付宝(杭州)信息技术有限公司 智能合约存储内容的遍历方法及装置、电子设备

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117056342A (zh) * 2023-10-10 2023-11-14 腾讯科技（深圳）有限公司 一种基于区块链的数据处理方法及相关设备
CN117056342B (zh) * 2023-10-10 2024-01-26 腾讯科技（深圳）有限公司 一种基于区块链的数据处理方法及相关设备

Also Published As

Publication number Publication date
CN113220685A (zh) 2021-08-06
CN113220685B (zh) 2022-04-19

Similar Documents

Publication Publication Date Title
WO2022237596A1 (fr) Procédé et appareil de traversée pour contenu de stockage de contrat intelligent, et dispositif électronique
TWI731595B (zh) 區塊鏈狀態資料儲存方法及裝置、電子設備
WO2020258855A1 (fr) Procédé et appareil de stockage hiérarchique basé sur une chaîne de blocs, et dispositif électronique
TWI705351B (zh) 一種基於區塊鏈的跨鏈資料存取方法和裝置
WO2021017421A1 (fr) Procédé et dispositif de récupération de données d'état de chaîne de blocs, et dispositif électronique
WO2021017436A1 (fr) Procédé et appareil de synchronisation de données d'état de chaîne de blocs, et dispositif électronique
US10878052B2 (en) Blockchain-based cross-chain data operation method and apparatus
CN110275884B (zh) 数据存储方法及节点
US20200167345A1 (en) Method and apparatus for storing blockchain state data and electronic device
JP6362316B2 (ja) バッファ・プールをメモリ常駐型データのための常在インメモリ・ストレージとして用いた、ハイブリッド・テーブル実装のための方法、システム、およびコンピュータ・プログラム製品
WO2020258853A1 (fr) Procédé et appareil de stockage hiérarchique basé sur une chaîne de blocs, et dispositif électronique
WO2020258856A1 (fr) Procédé et appareil de stockage hiérarchique sur la base d'une chaîne de blocs et dispositif électronique
CN112988761B (zh) 区块链数据存储方法及装置、电子设备
US11294875B2 (en) Data storage on tree nodes
CN112988912B (zh) 区块链数据存储方法及装置、电子设备
US11036720B2 (en) Blockchain-based hierarchical data storage
CN114706848A (zh) 区块链数据存储、更新、读取方法及装置、电子设备
CN112988909B (zh) 区块链数据存储方法及装置、电子设备
CN112988908B (zh) 区块链数据存储方法及装置、电子设备
WO2022233274A1 (fr) Procédé et appareil de stockage de données de chaîne de blocs, et dispositif électronique
WO2024021419A1 (fr) Procédé et appareil de stockage de données de chaîne de blocs, et dispositif électronique
CN112905607B (zh) 区块链数据存储方法及装置、电子设备
CN112988911B (zh) 区块链数据存储方法及装置、电子设备
CN117591031A (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: 22806564

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE