WO2022233274A1 - Procédé et appareil de stockage de données de chaîne de blocs, et dispositif électronique - Google Patents

Procédé et appareil de stockage de données de chaîne de blocs, et dispositif électronique Download PDF

Info

Publication number
WO2022233274A1
WO2022233274A1 PCT/CN2022/090294 CN2022090294W WO2022233274A1 WO 2022233274 A1 WO2022233274 A1 WO 2022233274A1 CN 2022090294 W CN2022090294 W CN 2022090294W WO 2022233274 A1 WO2022233274 A1 WO 2022233274A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
data
tree
key
value
Prior art date
Application number
PCT/CN2022/090294
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 WO2022233274A1 publication Critical patent/WO2022233274A1/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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • 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

Definitions

  • One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a method and apparatus for storing blockchain data, 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 the block data and the account status data corresponding to the blockchain account in the blockchain; and the block data can further include the block data.
  • the various blockchain data can usually be organized into a Merkle tree in the form of key-value pairs and stored in the database.
  • the data can be efficiently queried by traversing the above-mentioned Merkle tree by using the key of the above-mentioned various blockchain data as a query index.
  • This specification proposes a method for storing data in a blockchain, including: obtaining a key-value key-value pair of the blockchain data to be stored; converting the key-value key-value pair of the blockchain data to be stored
  • the root node, the intermediate node and the leaf node on the logical tree structure; the root node and the intermediate node include a plurality of positions for storing the characters in the key of the blockchain data, and each position includes multiple positions.
  • a slot for storing the characters in the key of the blockchain data is used to store the hash value of the next-layer node linked to the node; the root node, the intermediate node and the leaf node are The key-value key-value pair is stored in the database; in the key-value key-value pair of the leaf node, the intermediate node and the root node, the value is the storage content of the node, and the key is the hash of the storage content of the node value.
  • This specification also proposes a device for storing data in a blockchain, comprising: an acquisition module, which acquires a key-value pair of blockchain data to be stored; a conversion module, which converts the data of the blockchain data to be stored.
  • the key-value key-value pair is converted into a root node, an intermediate node and a leaf node on a logical tree structure;
  • the root node and the intermediate node include a plurality of positions for storing characters in the key of the blockchain data , each position includes a plurality of slots for storing characters in the key of the blockchain data; the slots are used to store the hash value of the next layer node linked to the node;
  • the storage module the The key-value key-value pairs of the root node, the intermediate node and the leaf node are stored in the database; in the key-value key-value pairs of the leaf node, the intermediate node and the root node, the value is the storage of the node Content, the key is the hash value of the node's storage
  • each root node and intermediate node in the logical tree structure include multiple positions representing different characters respectively; and each position further includes multiple slots representing different characters respectively Therefore, through this design, each root node and intermediate node will have a larger data storage capacity and data carrying capacity, so that the root node and intermediate node in the above-mentioned logical tree structure are written into the database.
  • the data storage capacity of the root node and the intermediate node can be compared with the single IO read and write of the storage medium carrying the above database.
  • the capacity of the above-mentioned database is more suitable, so that the IO read and write capabilities of the storage medium carrying the above database can be fully utilized to improve the efficiency of data read and write; moreover, the data storage capacity and data carrying capacity of the nodes on the above-mentioned logical tree structure are improved.
  • the number of layers of intermediate nodes is always in a relatively stable state; thirdly, due to this design, each root node and intermediate node will have greater data storage capacity and data carrying capacity; and, the above-mentioned logical tree
  • the number of layers of root nodes and intermediate nodes contained in the tree-like structure will be in a relatively stable state; therefore, the improvement of the storage capacity of the root nodes and intermediate nodes and the relative stability of the layers of the root nodes and intermediate nodes, in To some extent, it can be ensured that the root node and intermediate node of the above-mentioned logical tree structure will have fewer layers; thus, the root node and intermediate node have greater data storage capacity and data carrying capacity, and the above logical
  • the root node and intermediate nodes of the tree structure have fewer layers, when the system performs a cold start, it is necessary to convert the root nodes of the first N layers of the above logical tree structure from the storage medium carrying the above database.
  • FIG. 1 is a schematic diagram of organizing account state data of a blockchain into an MPT state tree provided by an exemplary embodiment
  • FIG. 2 is a schematic diagram of organizing contract data stored in a storage space corresponding to a contract account into an MPT storage tree provided by an exemplary embodiment
  • FIG. 3 is a flowchart of a method for storing blockchain data provided by an exemplary embodiment
  • FIG. 4 is a tree structure diagram of a FDMT tree provided by an exemplary embodiment
  • FIG. 5 is a tree structure diagram of another FDMT tree provided by an exemplary embodiment
  • Fig. 6 is the structure diagram of a kind of Tree 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 schematic diagram of setting a node ID for a node on an FDMT tree provided by an exemplary embodiment
  • FIG. 9 is a schematic diagram of writing account status data into an FDMT 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 blockchain data storage device provided by an exemplary embodiment.
  • Blockchains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain.
  • the most decentralized is the public chain.
  • Participants who join 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.
  • each node can freely join or leave the network and perform related operations.
  • the private chain is on the contrary, 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 within a specific institution.
  • the consortium chain is a blockchain between the public chain and the private chain, which can achieve "partial decentralization".
  • Each node in the alliance chain usually has a corresponding entity or organization; the node joins the network through authorization and forms a stakeholder alliance to jointly maintain the operation of the blockchain.
  • the blockchain is usually composed of several blocks. Timestamps corresponding to the creation time of the blocks are respectively recorded in these blocks, and all blocks form a time-ordered data chain strictly according to the timestamps recorded in the blocks.
  • 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. After the consensus, the node device in the blockchain as the accounting node will package the transaction into the block and store the certificate persistently in the blockchain.
  • a structure is usually used to maintain the account state of the account.
  • the state of the account associated with that transaction in the blockchain usually changes as well.
  • the structure of the account 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 be processed only once, effectively avoiding replay attacks
  • the Code field is used to maintain the contract code of the account; in practical applications, the Code field usually only maintains the hash value of the contract code; 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 the 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 referred to as the account storage of the contract account.
  • the storage content of the contract account is usually stored in the above-mentioned independent storage space in the form of a key-value key-value pair constructed as an MPT (Merkle Patricia Trie) tree data structure.
  • 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 also commonly referred to as 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.
  • a Merkle tree is usually used; or a logical tree structure such as a Merkle tree variant based on the data structure of the Merkle tree is used to store and maintain data.
  • the MPT tree is a Merkle tree variant that combines the tree structure of the Trie dictionary tree for storing and maintaining blockchain data.
  • the contract data stored in the storage space corresponding to the contract account is usually constructed as 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 data of all accounts (including external accounts and contract accounts) in the blockchain in the form of 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 corresponding to each transaction generated after the transaction in the block is executed. ) receipt, an MPT tree organized in the form of 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.
  • both the MPT transaction tree and the 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.
  • the node device executes the transaction in the latest block generated by the blockchain, since the account status in the current blockchain has changed, the node device needs to construct the current account status data 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 that after the transaction in the block is executed, all accounts in the blockchain are up-to-date. account status.
  • FIG. 1 is a schematic diagram of organizing the account status data of each blockchain account in the blockchain into an MPT state tree in the form of key-value pairs.
  • MPT tree is a more traditional and improved variant of Merkle tree, which combines the advantages of two tree structures of Merkle tree and Trie dictionary tree (also called prefix tree).
  • the root node of the MPT tree can usually be an extension node; the middle node of the MPT tree can usually be a branch node or other extension nodes.
  • the extension nodes and branch nodes may be collectively referred to as character nodes, which are used to store the character prefix part of the character string corresponding to the key (ie the account address) of the account status data; 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 the keys of all account status data (ie, blockchain account addresses) have.
  • the above leaf nodes are used to store the character suffix part of the character string corresponding to the key of the blockchain data and the Value (that is, the specific account status 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 in the next layer linked to the extension node (that is, the one shown in Figure 1).
  • Next node containing 17 slots, the first 16 slots correspond to the 16 possible hexadecimal characters in the key, one character corresponds to a nibble (nibble), each of the first 16 slots Bits, which 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 usually an empty value.
  • the leaf node is used to store the character suffix of the account address (that is, the key-end shown in FIG. 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 are The shared character prefix of , together forms 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 lines is an external account, and the fields of Codehash and Storage root are empty.
  • the blockchain account corresponding to the account address in line 4 is the contract account.
  • 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 consists of 4 leaf nodes, 2 branch nodes, and 2 extension nodes (one of which is the extension node as the root). node) composition.
  • the prefix field is a prefix field shared by 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 extension node containing an even number of nibbles; as mentioned above, a nibble represents a nibble, which is composed of 4-bit binary, and a nibble can correspond to a character that constitutes an account address.
  • the value of the prefix field is 1, which means that the extension node contains an odd number of nibble(s); the value of the prefix field is 2, which means that the leaf node contains an even number of nibbles; the value of the prefix field is 3, which means that it contains an odd number of nibbles. (s) leaf nodes.
  • the branch node because it is a parallel single nibble character node, does not have the above 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 Next Node field is filled with the hash value (hash pointer) of the next node.
  • 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 in the MPT tree, the branch node
  • the Value field can be null.
  • the Key-end in the leaf node corresponds to the key value of the key-value pair contained in the leaf node, and represents 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 structure composed of the 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 shown in Figure 1 are ultimately stored in the database in the form of Key-Value key-value pairs; among them, 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 entire node), and the calculated hash value can be used as the key.
  • the content of the data is used as value, and a Key-Value key-value pair is generated; then, the generated Key-Value key-value pair is stored in the database.
  • 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 When a node on the MPT state tree is used, content addressing can usually be performed based on the hash value of the data content contained in the node as a key.
  • 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 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; among them, 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 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 variable value corresponding to the state variable can be used as the value.
  • the branch node can store one of the characters in 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 character length of the shared character prefix of the keys of all data stored in the MPT tree is usually not fixed; moreover, when the newly added data is written to the MPT tree, the characters of the above shared character prefix may be caused
  • the length will also change accordingly; therefore, this may cause the expansion node on the MPT tree to split and split into new branch nodes; that is, the split condition of the nodes on the MPT tree is that the above-mentioned shared character prefix
  • the character length changes; for example, taking the MPT state tree shown in Figure 1 as an example, assuming that the above-mentioned MPT state tree adds an account state data of an account address whose first two characters of the account address are "a8", then the figure
  • the shared character prefix stored in the "Shared nible" field of the extended node as the root node shown in 1 will be changed from "a7" to "a”; according to the splitting conditions of the nodes of the MPT state tree, this is used as the root node.
  • the number of node layers in the MPT tree may also change, resulting in an unstable number of nodes in the MPT tree. Because the character length of the shared character prefix of the keys of all the data stored in the above-mentioned MPT tree will frequently change as new data is written into the above-mentioned MPT tree; therefore, according to the node splitting method shown above, there will be This causes frequent splitting of nodes, which in turn affects the data storage efficiency when writing new data to the MPT tree.
  • this specification proposes a new logical tree structure design solution.
  • the above-mentioned logical tree structure may still include a root node, an intermediate node and a leaf node; wherein, the above-mentioned root node and intermediate node are used to store characters in the key of the blockchain data; the above-mentioned leaf node is used for the storage area The value of the blockchain data.
  • the above-mentioned root node and intermediate node may include multiple locations for storing characters in the key of blockchain data, and each location may further include multiple locations for storing blockchain data.
  • the slot of the character in the key; the above slot can be used to store the hash value of the next layer node linked to the node.
  • the node device in the blockchain can obtain the key-value key-value pair of the blockchain data to be stored, and then convert the blockchain data to be stored into the above-mentioned logical tree structure
  • the root node, the intermediate node and the leaf node on the node then, the key-value key-value pairs of the above-mentioned root node, the intermediate node and the leaf node are further stored in the database; the above-mentioned leaf node, the intermediate node and the root node are further stored in the database;
  • the value can be the storage content of the node, and the key can be the hash value of the storage content of the node.
  • each root node and intermediate node in the logical tree structure include multiple positions representing different characters respectively; and each position further includes multiple positions representing different characters respectively. slot; therefore, through this design, each root node and intermediate node will have a larger data storage capacity and data carrying capacity, so that the root node and intermediate node in the above-mentioned logical tree structure will be written into the database.
  • the data storage capacity of the root node and the intermediate node can be compared with the single IO read of the storage medium carrying the above-mentioned database.
  • the write capacity is more suitable, so that the IO read and write capabilities of the storage medium carrying the above database can be fully utilized to improve the data read and write efficiency; moreover, the data storage capacity and data carrying capacity of the nodes in the above-mentioned logical tree structure are improved.
  • each root node and intermediate nodes will have larger data storage capacity and data carrying capacity; and, the above logic
  • the number of layers of the root node and intermediate node contained in the tree structure of the tree structure will be in a relatively stable state; therefore, the storage capacity of the root node and the intermediate node is improved and the number of layers of the root node and the intermediate node is relatively stable,
  • the root node and intermediate nodes of the above-mentioned logical tree structure will have fewer layers; thus, the root node and intermediate nodes have greater data storage capacity and data carrying capacity, and the above logic
  • the root node and intermediate nodes of the tree structure have fewer layers, when the system performs a cold start, it is necessary to transfer the roots of the first N layers of the above logical tree structure from the storage medium carrying the above database.
  • the number of IO reads when the root nodes and intermediate nodes of the top N layers stored in the above storage medium are read into the memory can be significantly reduced, and The overall read time when the root nodes and intermediate nodes of the first N layers of the logical tree structure are loaded into the memory, thereby fundamentally shortening the startup delay when the system is cold-started.
  • FIG. 3 is a flowchart of a method for storing blockchain data provided by an exemplary embodiment.
  • the method is applied to a block chain node device; the method includes the following steps: step 302, obtaining a key-value key-value pair of the block chain data to be stored; step 304, storing the block chain data to be stored
  • the key-value key-value pair is converted into a root node, an intermediate node and a leaf node on a logical tree structure; the root node and the intermediate node include a plurality of characters used to store the characters in the key of the blockchain data.
  • each location includes a plurality of slots for storing characters in the key of the blockchain data; the slots are used to store the hash value of the next-layer node linked to the node; Step 306,
  • the key-value key-value pairs of the root node, the intermediate node and the leaf node are stored in the database; in the key-value key-value pairs of the leaf node, the intermediate node and the root node, the value is the value of the node.
  • Storage content the key is the hash value of the storage content of the node.
  • the so-called logical tree structure means that in the underlying physical storage of the database, there is no physical storage structure completely corresponding to the tree structure, but only the physical data of each node on the above tree structure is stored in the database. and link relationship data between each node, so that the above tree structure can be restored on a logical level based on the physical data and link relationship data of each node stored in the database.
  • the above-mentioned logical tree-like structure may specifically include a root node, an intermediate node and a leaf node; wherein, the nodes on the above-mentioned logical tree-like structure may be linked with the nodes of the upper layer through their own hash values.
  • the above-mentioned root node and intermediate node are specifically used to store at least one character in the key in the key-value key-value pair of the blockchain data; the above-mentioned leaf nodes are specifically used to store the value of the blockchain data (that is, the blockchain data specific content).
  • the number of layers of the intermediate nodes may be one or more layers, and is not particularly limited in this specification.
  • the key of the above blockchain data can still include a character prefix part (Shared nibble) and a character suffix part (key-end); in this case, the root node and intermediate nodes can be used for storage The characters in the above character prefixes; and the above leaf nodes can be used to store the above character suffixes and the value of blockchain data.
  • a character prefix part Shared nibble
  • a character suffix part key-end
  • the above-mentioned logical tree structure can store the characters in the key of the blockchain data; therefore, the above-mentioned logical tree structure has the characteristics of Trie dictionary tree; on the other hand, the above-mentioned The nodes on the logical tree structure can be linked with the nodes of the upper layer through their own hash values; therefore, the above logical tree structure also has the characteristics of Merkle tree.
  • the logical tree structure described in this specification is actually a Merkle tree variant similar to the MPT tree that incorporates the tree structure of the Trie dictionary tree.
  • Fig. 4 is a tree structure diagram of a FDMT (Fixed Depth Merkle Tree) tree shown in this specification.
  • the above FDMT tree is a Merkle tree variant incorporating the tree structure of the Trie dictionary tree.
  • the tree structure of the FDMT tree shown in this specification includes the Tree nodes of the first N layers (the three layers shown in FIG. 4 are only illustrative), and the Leaf of the last layer. node (ie leaf node).
  • the first layer is the Tree node as the root node
  • the other layers are the Tree node as the intermediate node.
  • each Tree node that is, the root node and the intermediate node in the first N layers of the above-mentioned FDMT tree will adopt a unified data structure, so that each Tree node in the first N layers of the above-mentioned FDMT tree will be , node splitting can no longer occur because the length of stored characters changes due to newly written data.
  • the tree nodes of the first N layers on the above-mentioned FDMT tree may include multiple blocks representing different characters respectively; the above-mentioned blocks are the "positions" of the characters in the key used to store the blockchain data. And each block may further include a plurality of slots representing different characters; the above slots are also used to store the characters in the key of the blockchain data.
  • each Tree node includes N blocks; each block further includes N slots.
  • the method 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 in the above-mentioned FDMT tree are linked to the nodes of the upper layer through their own hash values.
  • the above slot can be specifically used to fill the hash value of the next layer node linked by the current Tree node.
  • the next-level node of the Tree node can still be a Tree node or a Leaf node.
  • the above-mentioned Tree node can specifically adopt the data structure of the main block (ie the main position) and multiple sub-blocks (ie the sub-positions).
  • FIG. 5 is a tree structure diagram of another FDMT tree shown in this specification.
  • the tree structure of the FDMT tree shown in this specification still includes the Tree nodes of the first N layers and the leaf nodes of the last layer.
  • the tree nodes of the first N layers on the above-mentioned FDMT tree shown in FIG. 5 may include the main block (that is, the root shown in FIG. 5 ). block) and a plurality of sub-blocks representing different characters respectively; and each block may further include a plurality of slots; for example, as shown in FIG. 5, each Tree node includes a main block and N sub-blocks; and each sub-block The block further includes N slots.
  • the functions of the slots included in the above-mentioned main block and sub-blocks may be different; as shown in FIG. 5 , for the main block, it may include a plurality of slots corresponding to each sub-block, and each slot Specifically, it can be used to fill the hash of the data content stored in the corresponding sub-block; for example, when calculating the hash of any sub-block, the hash values filled in each slot in the sub-block can be spliced together, and then spliced together The hash of the sub-block performs a secondary hash calculation to obtain the hash of the sub-block.
  • the sub-block can contain multiple slots representing different characters, and each slot can be used to fill the hash value of the next-level node linked by the tree node.
  • the hash value of the main block in the Tree node can be used to represent the hash value of the Tree node; thus, in this case, when the above-mentioned FDMT tree After the hash value filled in the slot in any sub-block in the tree node above is updated, when recalculating the hash value of the tree node, it is only necessary to update the data in each slot in the sub-block.
  • the filled hash value is spliced, and the spliced hash value is used as a calculation parameter to re-hash calculation, and then the calculated hash value is filled into the slot corresponding to the sub-block in the main block in the tree node, and then The hash of each slot in the main block is spliced, and the spliced hash value is used as a calculation parameter to re-calculate the hash to obtain the hash of the tree node.
  • the hash value filled in each slot in other sub-blocks without data update will no longer need to be spliced and used as a calculation parameter to participate in the hash calculation, which can reduce the time when the hash value of the tree node is recalculated.
  • the hash calculation amount and calculation time are improved, and the calculation efficiency of hash calculation is improved.
  • Each tree node on the above-mentioned FDMT tree shown in Fig. 4 and Fig. 5 can be used to store at least some characters in the key of the above-mentioned blockchain data.
  • the characters actually stored can be specifically the characters represented by blocks in the Tree node (that is, at least one slot is filled with a non-empty block with a hash value), A string generated by splicing with the character represented by the slot filled with the hash value (ie, the non-empty slot) in the block.
  • the characters actually stored can be specifically the characters represented by the sub-blocks in the Tree node, and the characters represented by the slots filled with hash values in the block. character, the string generated by concatenation.
  • each block in the Tree node can only represent one character; that is, based on the storage format of the Tree node shown in Figures 4 and 5, the above-mentioned blockchain actually stored by each Tree node Part of the characters in the character prefix of the key of the data is a string of 2 characters in length.
  • FIG. 6 is a structural diagram of a Tree node shown in this specification; as shown in FIG. 6, the Tree node contains 16 sub-blocks representing different hexadecimal characters; each sub-block It further includes 16 slots that represent different hexadecimal characters respectively (only 16 slots included in block6 are shown in Figure 6); it is assumed that the sub-block6 (representing the hexadecimal character 6) in the tree node is not Empty block, slot4 (representing the hexadecimal character 4), slot6 (representing the hexadecimal character 6) and slot9 (representing the hexadecimal character 9) in the sub-block are filled with the next tree node link
  • the number of sub-blocks contained in the above-mentioned Tree node, and the number of slots contained in each sub-block are not particularly limited in this specification;
  • the number of sub-blocks contained in the above-mentioned tree node and the number of slots contained in the above-mentioned sub-blocks can be kept the same; for example, in an example, the characters corresponding to the keys of the above-mentioned blockchain data are used
  • the string is a hexadecimal string as an example.
  • the above-mentioned tree nodes of the first N layers can each include 16 sub-blocks representing different hexadecimal characters; and each sub-block can further include 16 sub-blocks. Slots representing different hexadecimal characters.
  • the Tree node on the FDMT tree shown in Figure 4 is relative to Figure 1. In terms of the nodes used to store character prefixes on the MPT tree, it will have a larger storage capacity.
  • the number of sub-blocks contained in the above-mentioned tree node may be different from the number of slots contained in the above-mentioned sub-blocks;
  • the character string corresponding to the key of the above-mentioned blockchain data can also be a character string composed of two different base characters; for example, the character string corresponding to the key of the above-mentioned blockchain data can be is a string composed of a mixture of hexadecimal characters and hexadecimal characters.
  • the above-mentioned tree nodes of the first N layers can each include 16 sub-blocks representing different hexadecimal characters; and Each sub-block may further include 10 slots representing different decimal characters; or, the above-mentioned tree nodes of the first N layers may include 10 sub-blocks representing different decimal characters respectively; and each The sub-block may further include 16 slots representing different hexadecimal characters.
  • the number of layers of Tree nodes included in the above-mentioned FDMT tree may be a fixed value; in practical applications, the value of the above-mentioned N may be an integer greater than or equal to 1; or That is, the above-mentioned FDMT tree may specifically be a Merkle tree including at least one layer of Tree nodes, and the number of layers of the included Tree nodes is relatively fixed.
  • the first 6 address characters of the blockchain account address can be used as the character prefix of the blockchain account address; moreover, since the length of the characters in the character prefix of the blockchain account address stored by the Tree node is 2-bit character; therefore, the above FDMT tree can be designed as a tree structure containing three levels of Tree nodes.
  • each Tree node in the FDMT tree includes a plurality of blocks representing different characters respectively; and each block further includes a plurality of Slots representing different characters respectively; therefore, through this design, each Tree node will have a larger data storage capacity and data carrying capacity, so that when the Tree node in the above FDMT tree is written into the database for storage;
  • the data storage capacity of the Tree node 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 bearing capacity can be fully utilized.
  • the IO read and write capability of the storage medium of the above-mentioned database improves the efficiency of data read and write; moreover, the improvement of the data storage capacity and data carrying capacity of a single tree node on the above-mentioned FDMT tree will inevitably lead to the overall data storage capacity of the above-mentioned FDMT tree. and the improvement of data carrying capacity, so that more blockchain data can be stored on the above FDMT tree; for example, taking the storage medium carrying the above database as a disk with a single physical sector of 4KB as an example, it is assumed that the disk has a single IO
  • the capacity of reading and writing is 4kb (one sector).
  • each Tree node in the tree structure of FDMT shown in Figure 4 and 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 of the disk itself. Read and write ability, improve data read and write efficiency.
  • each Tree node in FDMT adopts a unified data structure; for the Tree nodes of each layer in the above-mentioned FDMT, the character length of the character prefix of the key of the actually stored blockchain data will also remain unchanged. Fixed; therefore, through this design, frequent splitting of nodes caused by the fact that the length of characters actually stored in each layer of Tree nodes is not fixed can be avoided, thereby ensuring the number of layers of Tree nodes contained in the tree structure of FDMT. , is always in a relatively stable state.
  • each Tree node will have greater data storage capacity and data carrying capacity; and, the number of layers of Tree nodes contained in the tree structure of the FDMT will be in a relatively stable state. Therefore, the improvement of the storage capacity of the Tree node and the number of layers of the Tree node are relatively stable, to some extent, it can be ensured that the Tree node of the above FDMT will have fewer layers; thus, the Tree node has a larger data storage On the basis of the capacity and data carrying capacity, and the tree node of the above FDMT has fewer layers, the system needs to use the tree node of the first N layers of the above FDMT from the storage medium carrying the above database as the cold start.
  • the data that needs to be read frequently When the data that needs to be read frequently is loaded into the memory, it can significantly reduce the number of IO reads when reading the tree nodes of the first N layers stored in the above storage medium into the memory, and the tree nodes of the first N layers of the FDMT can be read into the memory.
  • the overall read time when the node is loaded into memory thereby fundamentally shortening the startup delay when the system is cold started.
  • the FDMT shown in Fig. 4 and Fig. 5 is fixed as a 3-layer Tree node, and the Tree node of each layer includes 16 blocks representing different hexadecimal characters; each block further includes 16 blocks representing different hexadecimal characters.
  • Has a larger number of layers for example, the MPT tree can reach up to 64 layers, which is much larger than 3 layers).
  • the storage capacity of a single Branch Node node on the MPT tree is 512 bytes, only the single physical sector carrying the above database is one-eighth of 4KB, and the reading efficiency is very low; therefore, even according to the MPT tree and The FDMT tree shown in Figures 4 and 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 Figures 4 and 5 times.
  • the character string corresponding to the key of the above-mentioned blockchain data may still include character prefixes and character suffixes; in this case, the above-mentioned Tree node can be used to store the The character in the character prefix of the key; the leaf node can be used to store the character suffix of the key of the blockchain data and the Value of the blockchain data.
  • the data actually stored by the above-mentioned leaf nodes usually has a larger data capacity than the above-mentioned Tree 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.
  • the original content of the above-mentioned blockchain data also occupies a larger storage space; therefore, in this specification, in order to ensure that the above-mentioned leaf nodes can have more For large data capacity, the above leaf nodes can specifically store data in the form of large data blocks.
  • the above-mentioned leaf node may specifically be in the form of a bucket data bucket; wherein, the above-mentioned bucket data bucket specifically Can be 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 FIG. 7 , the above-mentioned bucket data bucket (ie, the bucket node shown in FIG. 7 ) may include several Data records; wherein, the above-mentioned several data records contained in the above-mentioned bucket data buckets may not logically be a whole, but logically separated several different data records.
  • Each data record corresponds to a piece of blockchain data, which is used to store the value of the above-mentioned blockchain data; that is, a data record refers to a storage record whose data content includes the value of the blockchain data. .
  • each data record can correspond to an independent query key value (key), so that the query key of each data record can be based on value, to perform precise query for each data record in the above bucket data bucket, instead of reading all the data records stored in the above bucket data bucket as a whole.
  • key independent query key value
  • the specific form and specific content of the query key value corresponding to each data record are not particularly limited in this specification, and can be any form of character string that can be used as a query index for each data record.
  • the query key value corresponding to each data record may specifically be the hash value of the data content contained in each data record;
  • the above-mentioned data record contained in the above-mentioned bucket data bucket may specifically include the following: A key-value key-value pair formed by the hash value of the value of the above blockchain data and the data content corresponding to the value of the above blockchain data.
  • the query key value corresponding to each data record may also be a string other than the hash value that can be used as the query index of each data record, which is not particularly limited in this description; for example, , in an example, the query key value corresponding to each data record may also be a unique identifier (such as a serial number) respectively set by the node device for each data record.
  • the above-mentioned Tree node is used to store the characters in the character prefix of the key of the above-mentioned blockchain data; then the above-mentioned leaf node is used to store the character suffix of the key of the above-mentioned blockchain data and the above-mentioned
  • the value of the blockchain data correspondingly, the above data records contained in the above bucket data buckets may specifically be the data content corresponding to the character suffix in the key of the above blockchain data and the value of the above blockchain data as a whole.
  • the hash value obtained by the hash calculation is a key-value key-value pair formed by the character suffix of the key of the above-mentioned blockchain data and the data content corresponding to the value of the above-mentioned blockchain data.
  • the above data records may also be other types of data forms other than key-value pairs, which will not be listed one by one in this specification.
  • the above FDMT since several data records contained in the leaf nodes in the FDMT tree are no longer a whole logically, they are logically separated several key-value pairs; therefore, the above FDMT
  • the data contained in the leaf nodes in the tree will no longer be accessed as a whole access unit in the database, and each key-value pair contained in the above leaf nodes will be used as an independent access unit, so that the data access to the above-mentioned database will be more flexible;
  • the value of the above-mentioned blockchain data is the latest account status data corresponding to the blockchain account in the blockchain
  • the value of the above-mentioned blockchain data is
  • the key is the blockchain account address.
  • the key of the key-value key-value pair corresponding to the above data record contained in the above bucket data bucket can be the character suffix of the blockchain account address and the corresponding The hash value of the two parts of the account status data; the value of the key-value pair can be the character suffix of the blockchain account address and the data content of the corresponding account status data.
  • the state data can construct a key-value key-value pair, and write the key-value key-value pair into the above bucket data bucket; or, based on the character suffix of the specific account address and the corresponding account status data two parts of the data content
  • the hash value of the account address perform 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 number of data records contained in the above-mentioned bucket data bucket is not particularly limited in this specification; in the illustrated implementation manner, the number of data records contained in the above-mentioned bucket data bucket may specifically be Custom configuration by the user.
  • the above blockchain data is the latest account status data corresponding to the blockchain account in the blockchain, and the key of the above blockchain data is the blockchain account address.
  • the above bucket data Each data record in the bucket corresponds to the account status of a blockchain account; the number of data records in the above bucket data bucket actually represents that the bucket data bucket can accommodate the account bearer of the blockchain account Therefore, by customizing the number of data records that the above bucket data bucket can hold, 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 it can be configured by the user to be 16 or 64, so that a single bucket can carry the status data of 16 or 64 blockchain accounts.
  • the total storage capacity of the data records stored in the above bucket data bucket is not particularly limited in this specification; in an implementation manner shown, the total storage capacity of the data records stored in the above bucket data bucket Capacity, which can be customized by the user.
  • the storage medium carrying the above-mentioned database is a disk with a single physical sector of 4KB. It is set to 4KB; or an integer multiple of 4KB, so that the maximum storage capacity of the bucket data bucket can be adapted to the storage capacity of a single physical sector of the storage medium.
  • each Tree node of the first N layers on the above-mentioned FDMT tree adopts a unified data structure; therefore, each Tree node of the first N layers on the above-mentioned FDMT tree will no longer be split. .
  • the leaf nodes on the above-mentioned FDMT tree can still perform node splitting when certain splitting conditions are met.
  • the leaf nodes on the above-mentioned FDMT tree when they are split, they can no longer be split according to the change of the character length of the shared character prefix, but according to the storage capacity of the leaf node. split.
  • an intermediate node ie, the Extend node shown in FIG. 5
  • the split intermediate node is the upper-level node of the above leaf node. For the same leaf node, multiple splits can be performed.
  • the above-mentioned node splitting condition may include any form of condition related to the storage capacity of the above-mentioned leaf node, which is not particularly limited in this specification; in the illustrated embodiment, the above-mentioned node splitting condition may specifically be: Condition 1 and Condition 2 shown below; or a combination of Condition 1 and Condition 2 shown below: Condition 1: The total number of data records stored in the above leaf nodes is greater than the threshold; Condition 2: The total storage capacity of the data records stored in the above leaf nodes is greater than the threshold.
  • the above-mentioned node splitting condition may be set as, when the total number of data records stored in the above-mentioned leaf nodes is greater than 64; and/or, the total storage capacity of the data records stored in the above-mentioned leaf nodes is greater than 4KB , the intermediate node is split from the leaf node.
  • the above-mentioned Extend node which is also the intermediate node of the above-mentioned FDMT tree, can adopt the exact same data structure as the above-described Tree node, and is specifically used to store the characters split from the character suffixes stored in the above-mentioned leaf nodes; for example , please refer to Figure 4 and Figure 5, the Extend node split from the leaf node may also include multiple blocks representing different characters; and each block may further include multiple slots representing different characters; the slot The bit can be used to fill in the hash value of the next layer node linked by this node.
  • the next-layer node is the above-mentioned leaf node; therefore, the slot contained in the block in the Extend node can be used to fill the hash value of the next-layer leaf node linked by the Extend node.
  • an Extend node split from the above-mentioned leaf nodes it may also be merged with the lower-level leaf nodes linked to the Extend node according to the storage capacity of the Extend node.
  • the Extend node can be merged into the lower-level leaf node linked to it.
  • merging the Extend node into the lower-level leaf node linked to it means that the character stored in the Extend node is used as the above-mentioned character suffix and written into one or more leaf nodes of the lower layer linked with the Extend node.
  • the above-mentioned node merging condition may also include any form of condition related to the storage capacity of the above-mentioned Extend node, which is not particularly limited in this specification; in the illustrated embodiment, the above-mentioned node merging condition may specifically be is any one of Condition 3 and Condition 4 shown below; or, it can also be a combination of Condition 3 and Condition 3 shown below: Condition 1: The total number of characters stored in the Extend node above is less than or equal to the threshold ; That is, the total number of non-empty slots (that is, slots filled with hash values) in each block in the Extend node above; Condition 2: The total storage capacity of the characters stored in the Extend node above is less than or equal to the threshold.
  • the above node merging condition can be set as, when the total number of characters stored in the Extend node above Less than or equal to 1; and/or, when the total storage capacity of the characters stored in the Extend node is less than or equal to 1KB, the characters stored in the Extend node are used as character suffixes, and are written into one of the lower layers of the Extend node link or multiple leaf nodes.
  • the Extend node described in this specification can be a dynamically scalable intermediate node on the above-mentioned FDMT tree; when the storage capacity of any leaf node on the above-mentioned FDMT tree satisfies the node splitting condition, it can be used from the leaf node. At least one Extend node and at least one leaf node are split in the middle; when the storage capacity of any Extend node satisfies the node merging condition, the Extend node can be merged into the lower-level leaf node linked to it.
  • the blockchain data to be stored may specifically include at least the following four types of data: transactions included in the block; Transaction receipt; after the transaction in the block is executed, the latest account status data corresponding to the blockchain account in the blockchain; the storage content of the smart contract account;
  • the above-mentioned FDMT tree may also specifically include: A transaction tree used to store transactions included in the block; a receipt tree used to store transaction receipts corresponding to transactions included in the block; used to store the latest account corresponding to the blockchain account in the blockchain A state tree for state data; a storage tree for storing the storage content of smart contract accounts.
  • the tree structure of the above FDMT tree can be used to store some types of data in the above four types of data; for example, only the above FDMT tree can be used to store the latest account status corresponding to the above blockchain account Data, other types of data can be stored using other forms of binary trees (such as MPT or other forms of binary trees).
  • the hash value of the root node of the above transaction tree, receipt tree and state tree can be stored in the block header; the hash value of the root node of the above storage tree can be stored in the structure of the contract account corresponding to the storage tree. in the Storage field.
  • the key of the above-mentioned blockchain data may specifically refer to the corresponding search key value of the blockchain data in the database; correspondingly, the value of the above-mentioned blockchain data may specifically be the original content of the above-mentioned blockchain data; wherein, In practical applications, the above-mentioned search key may be a string corresponding to the blockchain data; when the above-mentioned blockchain data is of different types, the corresponding keys will also be different; for example, when the above-mentioned blockchain data is of different types
  • the above blockchain data is the transaction included in the block; or, after the transaction in the block is executed, when the transaction receipt corresponding to the transaction included in the block is the transaction receipt, the key corresponding to the blockchain data at this time , which can be the sequence number of the transaction in the block; or, a transaction identifier in other forms.
  • the key corresponding to the blockchain data at this time can be specifically The account address of the blockchain account.
  • the key corresponding to the blockchain data at this time may specifically be the account address of the contract account and the storage location of the above-mentioned storage content in the account storage of the contract account.
  • Hash value for example, in an example, the above storage content can usually be a state variable, then 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.
  • the node device in the blockchain when it is storing blockchain data, it can first obtain the key-value pair of the blockchain data to be stored; for example, in an example, the node device can be stored in the When the blockchain data to be stored is obtained, the blockchain data is processed into key-value key-value pairs; after the key-value key-value pairs of the blockchain data to be stored are obtained, the to-be-stored blockchain data can be The key-value key-value pair of the blockchain data is converted into the root node, intermediate node and leaf node on the above-mentioned logical tree structure; for example, in an example, the above-mentioned node device can carry a corresponding FDMT tree.
  • the storage interface or storage service can specifically be used to convert the key-value key-value pair of the blockchain data to be stored into a node on the FDMT tree; After the key-value key-value pair of the blockchain data, the key-value of the blockchain data to be stored can be stored according to the tree structure of the FDMT tree shown in Figure 4 or Figure 5 by calling the storage interface or storage service. The value key-value pair is converted into the root node, intermediate node and leaf node in Figure 4 or Figure 5.
  • the key-value pair is stored in the database; for example, 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 the physical storage corresponding to the above-mentioned database;
  • the above-mentioned FDMT tree is stored in the database, specifically, by executing the commit command, the nodes on the above-mentioned FDMT tree can be further written into the storage carrying the above-mentioned database from the memory of the node device in the form of a Key-Value key-value pair. medium.
  • the specific type of the above-mentioned database is not particularly limited in this specification, and those skilled in the art can flexibly choose based on actual needs; in an implementation manner, the above-mentioned database can be specifically a Key-Value type database;
  • the above database may be a LevelDB database using a multi-layer storage structure; or, a database based on a LevelDB architecture; for example, a Rocksdb database is a typical database based on a LevelDB database architecture.
  • the key of the above-mentioned Key-Value key-value pair may specifically be the node ID of the node on the above-mentioned FDMT tree; wherein, The above-mentioned node ID may specifically include identification information that can uniquely identify the node on the above-mentioned FDMT 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 FDMT tree; in this In this case, when a node on the FDMT tree needs to be queried, content addressing can be performed based on the hash value of the data content contained in the node as a key.
  • the node ID may specifically include path information of the node on the FDMT tree in the FDMT tree; that is, the path information of the node on the FDMT tree in the FDMT tree is used as the The node ID of the node; wherein, the above-mentioned path information may specifically include information in any form that can describe the link relationship between the node and other nodes, and the position of the node on the above-mentioned FDMT tree; for example, please refer to FIG. 8, FIG.
  • FIG. 8 A schematic diagram of setting a node ID for a node on the FDMT tree shown in this specification; for a FDMT tree containing a three-layer Tree node as shown in Figure 8, it is assumed 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 8 can be represented 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 in the FDMT tree; 12 refers to the second slot of the first block of the first layer tree node; 34 represents the 4th slot of the 3rd block of the second-level tree node; 56 represents the 6th slot of the 5th block of the third-level 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 on the above FDMT tree; for example, based on the node ID, it can be clarified that the bucket node is linked to the third-level tree
  • the sixth slot of the fifth block of the node; and the tree node of the third layer is linked to the fourth slot of the third block of the second layer of the tree node; 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 in the FDMT tree where the node is located can be precisely located.
  • the node ID may specifically include the relative position of the node on the FDMT tree in the FDMT tree, and the hash value of the data content contained in the node (at this time, the node ID can also be used as The hash identifier of the node); that is, the relative position of the node on the FDMT tree in the FDMT tree and the hash value of the data content contained in the node are used as the node ID of the node.
  • the relative position of the node in the above-mentioned FDMT tree and the hash value of the data content contained in the node can be concatenated with the generated string as the node ID of the node; of course, in practical applications, in In the process of splicing, other types of information other than the above-mentioned relative position and the above-mentioned hash value can also be further introduced to generate a node ID; they will not be listed one by one in this specification.
  • the node ID when the node ID is used to retrieve the node stored in the FDMT tree, the node can be precisely located in the FDMT The specific slot on the tree.
  • the storage medium used to carry the above-mentioned database on the above-mentioned node device may specifically be a persistent storage medium; for example, it may be a disk, memory or other forms of storage medium capable of persistently storing data, which is not described in this specification. List them one by one.
  • the nodes on the FDMT tree can also be encoded in advance, and then the key of the encoded node can be encoded. -value key-value pairs are stored in the database.
  • both the Tree node and Extend node on the above-mentioned FDMT tree contain multiple blocks, and each block further includes a data structure of multiple slots; therefore, in this specification, coding is performed for the above-mentioned FDMT tree.
  • bitmap encoding can be performed for the blocks in the Tree node and Extend node on the above FDMT tree.
  • bitmap encoding Information which can be a hexadecimal string used to identify whether each slot in the block is filled with a hash value; it is assumed that the block to be encoded (can be a main block or a sub-block) contains a total of 16 slots ; The 0th, 8th, 9th, 10th, and 11th bits in the 16 slots are filled with hash values respectively; then whether each slot in the block is filled with the hash statistics, you can use The binary string 0000 1111 0000 0001 represents; the leftmost of the binary string is the highest 15th bit, and the rightmost is the lowest 0th bit; finally, the binary string can be converted into a hexadecimal string 0x0f01; At this time, the hexadecimal string 0x
  • bitmap encoding when bitmap encoding is performed on the blocks in the Tree node and Extend node on the above-mentioned FDMT tree, whether it is the main block or the sub-block, the bitmap encoding process is exactly the same.
  • the blocks contained in the Tree node and Extend node in the encoded FDMT tree are added, it can indicate whether each slot in the block is filled with bitmap encoding information of the hash value;
  • the non-empty slot in the block can be determined through the bitmap encoding information in the block, and there is no need to traverse each slot in the block. , which can improve the search efficiency.
  • the leaf nodes on the above-mentioned FDMT tree use a completely different data structure from the Tree node and Extend node; therefore, when encoding the leaf nodes on the above-mentioned FDMT tree, it can also be completely different from the above-mentioned Tree node and Extend node. different encodings.
  • RLP Recursive Length Prefix, recursive length prefix encoding
  • the encoding method used when encoding the leaf nodes on the above-mentioned FDMT tree may also be encoding methods other than RLP encoding. In practical applications, it can be flexibly selected. will not be listed one by one.
  • the key-value pairs of the nodes on the FDMT tree may be stored in the database.
  • the encoded bitmap information is added to the block in the Tree node and Extend node after encoding to determine the empty slots in the block that are not filled with hash values, and then delete the determined empty slots from the block.
  • bitmap encoding information contained in the encoded block and the hash value filled with the non-empty character slot can be used as a whole for hash calculation; of course, you can also Exclude bitmap encoding information.
  • leaf nodes used to store the character suffix and value of the blockchain data have not been split, it is only necessary to change the leaf nodes of the character suffix and value used to store the blockchain data on the above FDMT tree, and The tree node of the character prefix of the key used to store the blockchain data can be updated separately.
  • the node device can search the above-mentioned database for the node corresponding to the above-mentioned blockchain data that needs to be updated; wherein, the specific search method will not be repeated; and then read the found node from the above-mentioned database to In the memory, these nodes are modified and updated in the memory, and then the updated nodes are further written into the above database to update the original updated nodes.
  • updating the leaf node on the FDMT tree whose data is updated may specifically include updating the value of the blockchain data stored in the leaf node.
  • the hash value of the leaf node can be recalculated, and based on the hash value, it can be re-linked with the nodes in the upper layer of the node.
  • updating the Extend node or Tree node on the upper layer of the leaf node where the data update occurs on the above-mentioned FDMT tree may specifically include updating the slot in the Extend node or Tree node filled with the hash value of the leaf node; After completion, you can recalculate the hash value of the Extend node or Tree node, and continue to re-link with the node on the layer above the node based on the hash value.
  • the hash value of the leaf node can be recalculated, and based on the hash value and the previous leaf node
  • the node of the layer (which can be a Tree node or an Extend node) is re-linked.
  • the node device can determine whether the leaf node on the above-mentioned FDMT tree is updated with data, and if any leaf node on the above-mentioned FDMT tree is updated with data, the node device can recalculate the hash value of the leaf node, And based on the hash value, before relinking with the Tree node or Extend node on the upper layer of the leaf node, further determine whether the storage capacity of the leaf node meets the node splitting condition; if the storage capacity of the leaf node meets the node splitting condition, you can further from The leaf node is split into at least one Extend node.
  • the leaf node when the storage capacity of the leaf node satisfies the node splitting condition, in order to rapidly reduce the storage capacity of the leaf node, the leaf node may be split into one Extend node and multiple leaf nodes.
  • the splitting strategy for splitting the Extend node from the above-mentioned leaf nodes is not particularly limited in this specification. In practical applications, users can customize settings according to specific splitting requirements; in the one shown in the In an embodiment, the above-mentioned splitting strategy may specifically include: splitting the latest data record written into the leaf node in the current block cycle, splitting it from the leaf node, and additionally creating an Extend node and a leaf based on the latest data. node.
  • the latest data records written to the target leaf node in the current block cycle can be determined; Delete the node from the node, and split the character prefix from the character suffix contained in these latest data records; for example, in one example, the first two digits of these latest data records can be split by default; or, in these latest data records If there is a shared character prefix in the character suffix included in the data record, and when the length of the shared character prefix reaches two digits, the shared character prefix is split.
  • At least one Extend node for storing the split character prefix and at least one leaf node for storing the latest data record after splitting the character prefix are further created.
  • At least one Extend node and At least one leaf node is used as a split node; therefore, for the target leaf node, after the node split is performed, the data records actually stored by the target leaf node will be the same as the data records stored by the target leaf node in the previous block cycle.
  • the data records are completely consistent; the hash value of the target leaf node will not change from the previous block cycle.
  • the target leaf node when the target leaf node writes new blockchain data in the current block cycle, so that the storage capacity of the target leaf node satisfies the node splitting condition, it only needs to split the newly written data record and re-create it. It is enough to create additional Extend nodes and leaf nodes, and it is no longer necessary to recalculate the hash value of the target leaf node and relink the nodes of the previous layer; through this splitting method, not only the leaves that meet the node splitting conditions can be guaranteed The hash value of the node is in a stable state, and the number of times of recalculating the hash value of the leaf node can be reduced.
  • the splitting strategy may specifically include: splitting the shared character prefixes between the character suffixes included in several data records stored by the leaf node from the leaf node, and splitting the shared character prefixes from the leaf node based on the Shared character prefixes to additionally create Extend nodes.
  • the target leaf node when splitting any target leaf node, it can be determined whether there is a shared character prefix between the character suffixes contained in several data records stored by the target leaf node; If there is a shared character prefix between the character suffixes included in a data record, the shared character prefix can be deleted from the above-mentioned several data records, and at least one Extend node for storing the shared character prefix is created.
  • the characters stored in the above Extend node can also be the characters represented by the block and the slot filled with the hash value in the block.
  • a character string with a length of two digits then there is a shared character prefix among the character suffixes contained in several data records stored in the target leaf node, and when the length of the shared character prefix reaches two digits, the shared character prefix can be changed from The above-mentioned several data records are split out.
  • the hash value of the Extend node can also be recalculated, and based on the hash value and the Extend node on the The nodes of the layer undergo a relinking phase to complete.
  • the node device can determine whether the data update occurs on the Extend node on the FDMT tree. If the data update occurs on any Extend node split from the leaf node on the FDMY tree, the node device recalculates the data update.
  • the leaf node of the next layer of the link of the Extend node can be determined first; for example, the lower node of the link of the Extend node can be determined according to the hash value filled in the non-empty slot in the block contained in the Extend node. A leaf node of one layer; then, the character stored by the Extend node can be used as part of the above character suffix, and written to the determined leaf node of the next layer of the Extend node link.
  • the leaf node when a leaf node is split multiple times, the leaf node can be split into multiple layers of Extend nodes; in this case, when any Extend node satisfies the node merging condition, if its lower nodes still is an Extend node, not a leaf node, the Extend node cannot be merged temporarily; in this case, you can wait for the lower Extend node and the lower leaf node to complete the merge to form a new leaf node, and then merge with the lower layer. The new leaf node is merged twice, and the specific merging method will not be described again.
  • the following takes the above blockchain data as the latest account status data corresponding to the blockchain account, and the key of the above blockchain data is the blockchain account address as an example.
  • Form the writing adopts the specific process of the FDMT tree as shown in Figure 4 and Figure 5, which will be described in detail.
  • the user client connected to the blockchain can package the transaction data into a standard transaction format supported by the blockchain, and then publish it to the blockchain; while the node devices in the blockchain can be based on the The consensus algorithm and other node devices, together with other node devices, agree on these transactions published by the user client to the blockchain, so as to generate the latest block for the blockchain; the specific consensus process will not be repeated.
  • the account status of the target account related to the executed transaction in the blockchain usually changes accordingly; therefore, the node device in the target After the transaction in the block is executed, the latest account status data of the target account after account update (that is, the account status after the transaction in the target block is executed) can be obtained, and the obtained latest account status of the target account can be obtained.
  • the data is processed into key-value key-value pairs; wherein, the key of the key-value key-value pair is the account address of the target account; the value of the key-value key-value pair is the latest account status of the target account.
  • the key-value key-value pairs can be converted into Tree node, Extend node and Leaf node on the above FDMT tree, and the The key-value pairs of the above Tree node, Extend node and Leaf node are stored in the database.
  • Fig. 9 is a schematic diagram of writing account state data into the FDMT state tree shown in this specification; in the above-mentioned FDMT state tree shown in Fig. 9, the first three layers are Tree nodes, and the last layer is Leaf node; wherein, the above-mentioned leaf node may adopt the storage structure of the bucket data bucket described above.
  • the tree nodes of each layer include a main block and 16 sub-blocks representing different hexadecimal characters 1-f respectively; and each sub-block further includes 16 slots representing different hexadecimal characters 1-f respectively .
  • the Tree node as the root node on the FDMT tree can be located in the database (for example, according to The hash of the root node filled in the block header is used to locate the root node); if the data is written for the first time and the root node has not been created, the root node can be created at this time; then start from the root node Tree node1 of the first layer, and in turn in the third layer Determine the character slot corresponding to the character prefix "a71135" of the account address in the Tree node.
  • the character slot corresponding to the character prefix "a71135" of the account address specifically includes: the 8th slot (representing character 7) in the 11th sub-block (representing character a) of Tree node1; The second slot (representing character 1) in the second sub-block of Tree node2 (representing character 1); the sixth slot (representing character 5) in the fourth sub-block (representing character 3) of Tree node3.
  • the data record consisting of the character suffix "125" and the state data "state1" can be written in the bucket node linked by the sixth slot of the fourth sub-block of Tree node3; of course, if There is already a data record corresponding to the character suffix "125" in the bucket node, indicating that the value corresponding to the historical account status data of the above account address "a71135125" has been written to the FMDT tree; at this time, the value stored in the data record can be updated It can be "state1".
  • the hash value of the data content contained in the bucket node can be recalculated, and the hash value can be filled into the sixth slot of the fourth block of Tree node3, and the original hash value of the slot to update.
  • the original hash value of the slot is updated.
  • the original hash value of the slot is updated.
  • the hash value of the data content contained in the main block of the root node Tree node1 is recalculated, and based on the hash value The value updates the hash value of the root node of the FDMT state tree stored in the block header.
  • the hash value of the root node of the FDMT state tree stored in the block header is updated, and the update of the FDMT state tree is completed at this time, the key- The value key-value pair is successfully written to the FDMT state tree.
  • the present application also provides device embodiments.
  • this specification also provides an embodiment of a blockchain data storage device.
  • the embodiments of the blockchain data storage device of this specification can be applied to electronic devices.
  • the apparatus embodiment may be implemented by software, or may be implemented by hardware or a combination of software and hardware.
  • a device in a logical sense is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory for operation by the processor of the electronic device where the device is located.
  • FIG. 10 it is a hardware structure diagram of the electronic equipment where the blockchain data storage device of this specification is located, except for the processor, memory, network interface, and non-volatile shown in FIG. 10.
  • the electronic device in which the apparatus 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 a blockchain data storage device shown in an exemplary embodiment of the present specification.
  • the blockchain data storage device 110 can be applied to the electronic equipment shown in the aforementioned FIG. 10 , and the device 110 includes: an acquisition module 1101 for acquiring the key-value key of the blockchain data to be stored value pair; the conversion module 1102 converts the key-value key-value pair of the blockchain data to be stored into a root node, an intermediate node and a leaf node on a logical tree structure; the root node and the intermediate node include A plurality of positions for storing characters in the key of the blockchain data, and each position includes a plurality of slots for storing characters in the key of the blockchain data; the slots are used for Store the hash value of the next layer node linked to the node; the storage module 1103 stores the key-value pairs of the root node, the intermediate node and the leaf node in the database; the leaf node, the intermediate node In the key-value key-value pair with the root node, the value is the storage content of the node, and the key is the hash value of the storage
  • the number of layers of the root node and the intermediate node is a fixed value.
  • the root node and the intermediate node are used to store at least part of the characters in the key of the blockchain data; the at least part of the characters stored by the root node and the intermediate node are the root node ,
  • the character string represented by the position in the intermediate node is spliced with the character represented by the slot filled with the hash value in the position.
  • the leaf node is a bucket data bucket; the bucket data bucket contains several data records; the data content stored in the data record includes the value of the blockchain data.
  • the character string corresponding to the key of the blockchain data includes a character prefix and a character suffix;
  • the root node and the intermediate node include a plurality of locations for storing the characters in the character prefix, each The location includes a plurality of slots for storing characters in the character prefix;
  • the data content stored in the data record includes the character suffix and the value of the blockchain data.
  • the number of the positions included in the root node and the intermediate node is the same as the number of slots included in the positions.
  • the root node and the intermediate node include 16 positions that respectively represent different hexadecimal characters; the positions include 16 slots that respectively represent different hexadecimal characters.
  • the blockchain data includes any one of the following: transactions included in the block; transaction receipts corresponding to transactions included in the block; The latest account status data corresponding to the blockchain account; the storage content of the smart contract account.
  • the logical tree structure includes any one of the following: a transaction tree for storing transactions included in the block; a receipt for storing transaction receipts corresponding to transactions included in the block tree; a state tree used to store the latest account state data corresponding to the blockchain account in the blockchain; a storage tree used to store the storage content of the smart contract account.
  • a typical implementing device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, email sending and receiving device, game control desktop, tablet, wearable device, or a combination of any of these devices.
  • 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 forms of non-persistent memory, random access memory (RAM) and/or non-volatile memory in computer readable media, 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 includes both persistent and non-permanent, removable and non-removable media, and storage of information may be implemented by any method or technology.
  • Information may be computer readable instructions, data structures, modules of programs, or other data.
  • Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), Flash Memory or other memory technology, Compact Disc Read Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic tape cartridges, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices.
  • computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.
  • first, second, third, etc. may be used in this specification to describe various information, such information should not be limited by these terms. These terms are only used to distinguish the same type of information from each other.
  • first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information without departing from the scope of one or more embodiments of the present specification.
  • word "if” as used herein can be interpreted as "at the time of" or "when” or "in response to determining.”

Abstract

L'invention concerne un procédé et un appareil de stockage de données de chaîne de blocs, ainsi qu'un dispositif électronique. Le procédé consiste : à obtenir des paires clé-valeur de données de chaîne de blocs à stocker ; à convertir les paires clé-valeur desdites données de chaîne de blocs en un nœud racine, un nœud intermédiaire, et un nœud feuille sur une structure d'arbre logique, le nœud racine et le nœud intermédiaire comprenant une pluralité de positions pour stocker des caractères dans des clés des données de chaîne de blocs, les positions comprenant chacune une pluralité de fentes pour stocker des caractères dans les clés des données de chaîne de blocs, et les fentes étant utilisées pour stocker des valeurs de hachage de la couche suivante de nœuds liés au nœud correspondant ; et à stocker dans une base de données les paires clé-valeur du nœud racine, du nœud intermédiaire, et du nœud feuille, dans les paires clé-valeur du nœud feuille, du nœud intermédiaire et du nœud racine, les valeurs étant le contenu de stockage des nœuds, et les clés étant les valeurs de hachage du contenu en stockage des nœuds.
PCT/CN2022/090294 2021-05-07 2022-04-29 Procédé et appareil de stockage de données de chaîne de blocs, et dispositif électronique WO2022233274A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110495070.9A CN112988910B (zh) 2021-05-07 2021-05-07 区块链数据存储方法及装置、电子设备
CN202110495070.9 2021-05-07

Publications (1)

Publication Number Publication Date
WO2022233274A1 true WO2022233274A1 (fr) 2022-11-10

Family

ID=76337213

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/090294 WO2022233274A1 (fr) 2021-05-07 2022-04-29 Procédé et appareil de stockage de données de chaîne de blocs, et dispositif électronique

Country Status (2)

Country Link
CN (1) CN112988910B (fr)
WO (1) WO2022233274A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112988910B (zh) * 2021-05-07 2021-09-24 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160335299A1 (en) * 2015-05-11 2016-11-17 Apple Inc. Hierarchical Data Storage
CN110334154A (zh) * 2019-06-28 2019-10-15 阿里巴巴集团控股有限公司 基于区块链的分级存储方法及装置、电子设备
CN111488614A (zh) * 2020-04-08 2020-08-04 北京瑞策科技有限公司 基于业务数据区块链的数字身份存储方法及装置
CN111837115A (zh) * 2019-07-11 2020-10-27 创新先进技术有限公司 共享的区块链数据存储
CN112905607A (zh) * 2021-05-07 2021-06-04 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN112988909A (zh) * 2021-05-07 2021-06-18 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN112988761A (zh) * 2021-05-07 2021-06-18 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN112988912A (zh) * 2021-05-07 2021-06-18 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN112988910A (zh) * 2021-05-07 2021-06-18 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN112988908A (zh) * 2021-05-07 2021-06-18 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN112988911A (zh) * 2021-05-07 2021-06-18 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN113220685A (zh) * 2021-05-11 2021-08-06 支付宝(杭州)信息技术有限公司 智能合约存储内容的遍历方法及装置、电子设备

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108446376B (zh) * 2018-03-16 2022-04-08 众安信息技术服务有限公司 数据存储方法与装置
CA3058225C (fr) * 2019-03-04 2022-04-12 Alibaba Group Holding Limited Mise a jour d'un sous-arbre merkle-patricia-trie d'etat du monde de chaine de blocs
CN110275884B (zh) * 2019-05-31 2020-08-04 阿里巴巴集团控股有限公司 数据存储方法及节点
CN112632077A (zh) * 2020-12-28 2021-04-09 深圳壹账通智能科技有限公司 基于redis的数据存储方法、装置、设备及存储介质

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160335299A1 (en) * 2015-05-11 2016-11-17 Apple Inc. Hierarchical Data Storage
CN110334154A (zh) * 2019-06-28 2019-10-15 阿里巴巴集团控股有限公司 基于区块链的分级存储方法及装置、电子设备
CN111837115A (zh) * 2019-07-11 2020-10-27 创新先进技术有限公司 共享的区块链数据存储
CN111488614A (zh) * 2020-04-08 2020-08-04 北京瑞策科技有限公司 基于业务数据区块链的数字身份存储方法及装置
CN112988761A (zh) * 2021-05-07 2021-06-18 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN112988909A (zh) * 2021-05-07 2021-06-18 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN112905607A (zh) * 2021-05-07 2021-06-04 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN112988912A (zh) * 2021-05-07 2021-06-18 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN112988910A (zh) * 2021-05-07 2021-06-18 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN112988908A (zh) * 2021-05-07 2021-06-18 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN112988911A (zh) * 2021-05-07 2021-06-18 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN114153848A (zh) * 2021-05-07 2022-03-08 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN113220685A (zh) * 2021-05-11 2021-08-06 支付宝(杭州)信息技术有限公司 智能合约存储内容的遍历方法及装置、电子设备

Also Published As

Publication number Publication date
CN112988910B (zh) 2021-09-24
CN112988910A (zh) 2021-06-18

Similar Documents

Publication Publication Date Title
TWI731595B (zh) 區塊鏈狀態資料儲存方法及裝置、電子設備
TWI732463B (zh) 區塊鏈狀態資料恢復方法及裝置、電子設備
TWI737157B (zh) 基於區塊鏈的分級儲存方法及裝置、電子設備
WO2021017436A1 (fr) Procédé et appareil de synchronisation de données d'état de chaîne de blocs, et dispositif électronique
TWI737152B (zh) 基於區塊鏈的分級儲存方法及裝置、電子設備
US11113272B2 (en) Method and apparatus for storing blockchain state data and electronic device
WO2022237596A1 (fr) Procédé et appareil de traversée pour contenu de stockage de contrat intelligent, 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
CN112988912B (zh) 区块链数据存储方法及装置、电子设备
CN112988761B (zh) 区块链数据存储方法及装置、电子设备
CN112988909B (zh) 区块链数据存储方法及装置、电子设备
CN112988908B (zh) 区块链数据存储方法及装置、电子设备
WO2022233274A1 (fr) Procédé et appareil de stockage de données de chaîne de blocs, et dispositif électronique
CN114706848A (zh) 区块链数据存储、更新、读取方法及装置、电子设备
WO2024021419A1 (fr) Procédé et appareil de stockage de données de chaîne de blocs, et dispositif électronique
CN112988911B (zh) 区块链数据存储方法及装置、电子设备
CN112905607B (zh) 区块链数据存储方法及装置、电子设备
CN111695136A (zh) 业务数据区块链的实现方法及其系统
CN111488607A (zh) 业务数据区块链的数据处理方法及其装置
CN115982781A (zh) 一种在区块链中创建账户的方法和区块链节点
CN116188160A (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: 22798615

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE