Data Management Method, Apparatus, System, and Storage Medium

Abstract

The present application provides a data management method, apparatus, system, and storage medium, relating to the field of blockchain technology, and is used to solve the problem that the use of MPT to store account data and contract data affects the overall performance of the blockchain. The solution includes: creating a target transaction; if the target transaction includes a storage instruction for account data, storing the account data in the data node of a single Merkle B+ tree; if the target transaction includes a storage instruction for the contract data of a contract account, storing the contract data in the data node of the Merkle B+ tree corresponding to a contract account, and different contract accounts correspond to different Merkle B+ trees; the last layer of the Merkle B+ tree is the data node, and the other layers of the Merkle B+ tree are index nodes; the root of the Merkle B+ tree corresponding to a contract account is stored in the root field of the account data of a contract account. Using different Merkle B+ trees to store account data and contract data respectively improves the overall performance of the blockchain.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular, to a data management method, apparatus, system, and storage medium. Background Art

[0002] In the Ethereum public blockchain platform, the Merkle Patricia Tree (MPT) is usually used to store account data and contract data. The underlying layer of the MPT uses the leveldb database to store data, and the key of each data is the hash value of the node, which means that Ethereum stores all data, resulting in problems of poor read / write performance and scalability, affecting the overall performance of the blockchain. Summary of the Invention

[0003] This application provides a data management method, apparatus, system, and storage medium, which solves the problem that the use of MPT to store account data and contract data affects the overall performance of the blockchain.

[0004] To achieve the above object, this application adopts the following technical solutions:

[0005] In a first aspect, an embodiment of this application provides a data management method. The method includes:

[0006] Create a target transaction;

[0007] If the target transaction includes a storage instruction for account data, store the account data in the data node of the single Merkle B+ tree;

[0008] If the target transaction includes a storage instruction for contract data of a contract account, store the contract data in the data node of the Merkle B+ tree corresponding to the contract account, and different contract accounts correspond to different Merkle B+ trees;

[0009] Among them, the last layer of the Merkle B+ tree is the data node, and the other layers of the Merkle B+ tree are index nodes; the root of the Merkle B+ tree corresponding to a contract account is stored in the root field of the account data of the contract account.

[0010] In some embodiments, the method further includes:

[0011] Receive a proof request for a target key;

[0012] Based on the proof request, splice all the nodes on the path from the node where the target key is located to the root node of the Merkle B+ tree to generate a Merkle proof of the target key;

[0013] Traverse all the nodes on the path, and for each node, execute:

[0014] Calculate the verification hash value of each node;

[0015] When the verification hash value of each node is equal to the hash value stored in each node, search for the target key in each node;

[0016] When the target key meets the target conditions, the proof request is successfully verified;

[0017] Among them, the target conditions include: the target key hits a key in the child node list of each index node on the path, and the hit key is equal to the minimum key in the child node list of the next node of each index node; the target key hits a key in the child node list of the data node on the path.

[0018] In some embodiments, the target key value is the key value in the Merkle B+ tree corresponding to a contract account;

[0019] Before the proof request is successfully verified, the method further includes:

[0020] Verify that the root of the Merkle B+ tree corresponding to a contract account is equal to the root field of the account data of a contract account.

[0021] In some embodiments, the method further includes:

[0022] After the target transaction is completed, starting from the last layer of the Merkle B+ tree and ending at the top layer of the Merkle B+ tree, judge whether the number of key-value pairs of each node in each layer is greater than or equal to a preset value layer by layer;

[0023] When the number of key-value pairs of a data node is greater than or equal to the preset value, split a data node into multiple data nodes with the number of key-value pairs less than the preset value.

[0024] In some embodiments, the index node of the Merkle B+ tree stores the minimum key and hash value of the child node;

[0025] The method further includes:

[0026] After the target transaction ends, starting from the top layer of the Merkle B+ tree and ending at the last layer of the Merkle B+ tree, calculate the hash values of all child nodes of each node in each layer in parallel and update the hash values;

[0027] Among them, the hash value of each node is determined by the hash value of the sum of its child node list.

[0028] In some embodiments, each node of the Merkle B+ tree includes an ID;

[0029] The method further includes:

[0030] In the case of creating or updating a new node, if there is an ID in the free ID list that meets the conditions, an ID in the free ID list is assigned to the new node; or, if there is no ID in the free ID list that meets the conditions, the maximum page ID is assigned to the new node, and the maximum page ID is incremented as the new maximum page ID.

[0031] In some embodiments, each node of the Merkle B+ tree includes an ID;

[0032] The method further includes:

[0033] In the case of a node splitting into multiple nodes or a node becoming a free node, the ID of the node is added to the free ID list.

[0034] In a second aspect, an embodiment of the present application provides a data management device, which includes:

[0035] A processing module, configured to create a target transaction;

[0036] A storage module, configured to store the account data in the data node of the single Merkle B+ tree if the target transaction includes a storage instruction for the account data; and store the contract data in the data node of the Merkle B+ tree corresponding to the contract account if the target transaction includes a storage instruction for the contract data of a contract account, where different contract accounts correspond to different Merkle B+ trees;

[0037] Wherein, the last layer of the Merkle B+ tree is a data node, and the other layers of the Merkle B+ tree are index nodes; the root of the Merkle B+ tree corresponding to a contract account is stored in the root field of the account data of the contract account.

[0038] In a third aspect, an embodiment of the present application provides a blockchain system, including a processor, a memory, and a computer program stored on the memory and executable on the processor. When the computer program is executed by the processor, it implements the data management method provided in the first aspect.

[0039] In a fourth aspect, an embodiment of the present application provides a storage medium, on which a computer program is stored. The computer program is loaded by a processor to execute the data management method provided in the first aspect.

[0040] In the embodiments of the present application, after creating a target transaction, if the target transaction includes a storage instruction for account data, the account data can be stored in the data node of a single Merkle B+ tree; if the target transaction includes a storage instruction for contract data of a contract account, the contract data can be stored in the data node of the Merkle B+ tree corresponding to the contract account, and different contract accounts correspond to different Merkle B+ trees. In this way, it is realized that the account data is stored by using a single Merkle B+ tree, and the contract accounts of multiple contract accounts are stored by using multiple Merkle B+ trees. Since the account data and the contract data are stored separately, the data volume of each database is reduced, and the read / write performance and the expansion performance are improved, thereby improving the overall performance of the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 It is a schematic diagram of a Merkle B+ tree provided by an embodiment of the present application;

[0042] Figure 2 It is a schematic flowchart of a data management method provided by an embodiment of the present application;

[0043] Figure 3 It is a schematic diagram of uniformly splitting the whole tree after batch insertion provided by an embodiment of the present application;

[0044] Figure 4 It is a schematic diagram of data rollback provided by an embodiment of the present application;

[0045] Figure 5 It is a schematic diagram of an account tree and a contract tree provided by an embodiment of the present application;

[0046] Figure 6 It is a schematic structural diagram of a data management device provided by an embodiment of the present application;

[0047] Figure 7 It is a schematic structural diagram of a blockchain system provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0048] In the following description, specific details such as specific system structures and technologies are presented for the purpose of illustration rather than limitation, so as to thoroughly understand the embodiments of the present application. However, those skilled in the art should clearly understand that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid unnecessary details from interfering with the description of the present application.

[0049] It should be understood that, as used in the specification of this application and the appended claims, the term "comprising" indicates the presence of the described features, integers, steps, operations, elements, and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or their groups.

[0050] As used in the specification of this application and the appended claims, the term "if" may be construed, depending on the context, as "when" or "once" or "in response to determining" or "in response to detecting". Similarly, the phrase "if determined" or "if [the described condition or event] is detected" may be construed, depending on the context, as meaning "once determined" or "in response to determining" or "once [the described condition or event] is detected" or "in response to detecting [the described condition or event]".

[0051] In the description of this application's specification and the appended claims, the terms "first", "second", "third", etc. are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0052] Reference to "one embodiment" or "some embodiments" or the like described in this application's specification means that a specific feature, structure, or characteristic described in connection with that embodiment is included in one or more embodiments of this application. Thus, statements such as "in one embodiment", "in some embodiments", "in other some embodiments", "in still other embodiments", etc. that appear in different places in this specification are not necessarily all referring to the same embodiment, but rather mean "one or more but not all embodiments", unless otherwise specifically emphasized in another way. The terms "comprising", "including", "having", and their variants all mean "including but not limited to", unless otherwise specifically emphasized in another way.

[0053] First, some nouns or terms involved in this application are explained.

[0054] A single Merkle B+-tree, abbreviated as Merkle B+-tree, contains two types of nodes:

[0055] Data nodes at the last layer of the Merkle B+-tree;

[0056] Index nodes at other layers of the Merkle B+-tree.

[0057] Generally, the Merkle B+-tree has the following characteristics:

[0058] 1. Each node contains an identity document number (ID);

[0059] 2. The child node list of the index node stores the minimum key of the child node and the hash value;

[0060] 3. The list of child nodes of a data node stores [key, value] state data key-value pairs;

[0061] 4. The hash value of each node is derived from the hash value of the sum of its list of child nodes.

[0062] Exemplarily, Figure 1 FIG. is a schematic diagram of a Merkle B+ tree provided by an embodiment of the present application.

[0063] As Figure 1 shown, nodes n1 to n3 are index nodes, and nodes n4 to n6 are data nodes. Taking the root node n1 as an example, node n1 is the parent node of node n2 and node n3. The ID of node n1 is 1. Node n1 stores the minimum key Key: "a" and hash value Hash: H(n4) of child node n2, and the minimum key Key: "e" and hash value Hash: H(n6) of child node n3.

[0064] The data is stored in the data node in the form of key-value pairs, and each node is stored on the disk in the form of a page. To better adapt to the disk read-write strategy, the maximum size of each page is 4K. In this way, by calculating the offset of the page ID * page size, the data of a certain node can be read from the disk.

[0065] In the embodiment of the present application, a single Merkle B+ tree is used to store account data; multiple Merkle B+ trees are used to store contract data of multiple contract accounts, and different contract accounts correspond to different Merkle B+ trees. The data management method, device, system, and storage medium provided by the present application will be described by way of example below.

[0066] As Figure 2 shown, an embodiment of the present application provides a data management method. The method includes:

[0067] S201. Create a target transaction.

[0068] In the embodiment of the present application, a transaction may include several execution instructions, such as storage instructions, deletion instructions, modification instructions, query instructions, etc. When the created target transaction includes a storage instruction, the account data and contract data can be stored respectively, that is, the following S202 and S203 are executed.

[0069] S202. If the target transaction includes a storage instruction for account data, store the account data in the data node of the single Merkle B+ tree.

[0070] S203. If the target transaction includes a storage instruction for the contract data of a contract account, store the contract data in the data node of the Merkle B+ tree corresponding to the contract account. Different contract accounts correspond to different Merkle B+ trees.

[0071] There are many accounts in the blockchain system, some of which are contract accounts and some are non - contract accounts. In the embodiments of the present application, the data of contract accounts and non - contract accounts are collectively referred to as account data, that is, account data includes the data of all accounts in the blockchain, such as addresses, balances, Nounce values, etc. Blockchain smart contracts are deployed under the accounts of contract accounts, and the data generated by the smart contracts is called the contract data of the contract account. The contract data of all contract accounts constitutes the contract data of the blockchain, such as variable a, etc.

[0072] To store the above two types of data, the embodiments of the present application provide two types of databases, namely: single Merkle B+ tree and multi - Merkle B+ tree. Each Merkle B+ tree in the multi - Merkle B+ tree is a table, corresponding to the contract data of a contract account respectively, and is called a sub - tree. The single Merkle B+ tree is used to manage the information of these sub - trees and is called the root tree.

[0073] Among them, each node of each Merkle B+ tree contains an ID. The index node of each Merkle B+ tree stores the minimum key and hash value of the child nodes. The child node list of the data node of each Merkle B+ tree stores the [key, value] state data key - value pair. The hash value of each node of each Merkle B+ tree is obtained from the hash value of the sum of its child node list.

[0074] It should be noted that in the data node of the rootTree, the key is the name of the table, and the value is the page ID of the root node of the sub - tree corresponding to the table. When looking up a certain key in a certain table, you can first query the page ID of the root node corresponding to this table in the rootTree, then find the sub - tree according to this page ID, and then query a certain key in this tree.

[0075] The data management method provided by the embodiments of the present application uses a single Merkle B+ tree to store account data and a multi - Merkle B+ tree to store the contract data of multiple contract accounts. Since the account data and the contract data are stored separately, the data volume of each database is reduced, the read - write performance and the expansion performance are improved, and thus the overall performance of the blockchain is improved.

[0076] In some embodiments, since each node can hold at most 4K of data, if a data node inserts too many key-value pairs and exceeds 4K, the data node will split into multiple new data nodes that do not exceed 4K, and the information of the corresponding new nodes will be inserted into the child node list of the original parent node. Then, recursively check whether the parent node, i.e., the index node, exceeds 4K. If it does, the splitting process will be repeated. Since splitting has a greater impact on performance, the embodiments of the present application propose a batch insertion scheme: that is, for each key-value insertion within the target transaction, node splitting will not be triggered. We will record the dirty child nodes generated by each key-value pair insertion. After all the key-values within the target transaction are inserted, the entire tree will be split uniformly based on the dirty child nodes.

[0077] Exemplarily, after the target transaction is completed, the data management method provided by the embodiments of the present application may further include the following S204 to S205.

[0078] S204: Starting from the last layer of the Merkle B+ tree as the starting layer and the topmost layer of the Merkle B+ tree as the ending layer, layer by layer, determine whether the number of key-value pairs of each node in each layer is greater than or equal to a preset value.

[0079] Since the size of a disk page is usually 4K, the above embodiments take the preset value as 4K as an example for illustration. It should be understood that in actual implementation, the preset value can also be other values, such as 8K or 16K, etc., which are not limited in the embodiments of the present application.

[0080] S205: When the number of key-value pairs of a data node is greater than or equal to the preset value, split one data node into multiple data nodes with the number of key-value pairs less than the preset value.

[0081] It should be noted that if the root node is split, a new root node will be created.

[0082] The following takes Figure 3 as an example to exemplarily illustrate the process of uniformly splitting the entire tree after batch insertion provided by the embodiments of the present application. As shown in (a) of Figure 3 , before the target transaction is executed, the entire database is the first tree. After the target transaction is completed, as shown in (b) of Figure 3 , since the underlying data nodes A and B have inserted key-value pairs and become dirty child nodes, and the number of key-value pairs exceeds the preset value, as shown in (c) of Figure 3 , data node A is split into node A1 and node A2, and data node B is split into node B1 and node B2, and the information of the new nodes is inserted into node C. At this time, node C becomes a dirty node due to the insertion of new child node information. Assuming that the number of key-value pairs of node C also exceeds the preset value, then as shown in Figure 3As shown in (d) therein, node C is further split into node C1 and node C2, and a new root node D is created as the parent node.

[0083] It can be understood that node splitting is not performed within the target transaction, but rather is unified after all transactions are completed, which can reduce the computational resource occupancy of the instructions executed within the transaction.

[0084] In some embodiments, based on the Merkle B+ tree supporting the Merkle feature, after the target transaction ends, parallel hash calculations still need to be performed on the new tree. The data management method provided by the embodiments of the present application may further include the following S206.

[0085] S206: After the target transaction ends, starting from the top layer of the Merkle B+ tree as the starting layer and the last layer of the Merkle B+ tree as the ending layer, calculate the hash values of all child nodes of each node in each layer in parallel and update the hash values.

[0086] Among them, the hash value of each node is determined by the hash value of the sum of its child node list.

[0087] Still taking (d) above Figure 3 as an example for exemplary illustration. The top layer of the Merkle B+ tree is node D. Therefore, starting from node D, calculate the hash values of node C1 and node C2 in parallel. For node C1, the hash values of nodes A1, A2, and B1 will be calculated in parallel.

[0088] It can be understood that after the target transaction ends, calculating the hash values of all child nodes of each node in each layer from top to bottom in parallel greatly speeds up the process of calculating the hash.

[0089] In some embodiments, since each node of the Merkle B+ tree includes an ID, the embodiments of the present application provide a maximum page ID and a free ID list to manage the page IDs. The data management method provided by the embodiments of the present application may further include the following S207 and S208.

[0090] S207: In the case of creating or updating a new node, if there is an ID in the free ID list that meets the conditions, assign one ID from the free ID list to the new node; or, if there is no ID in the free ID list that meets the conditions, assign the maximum page ID to the new node and increment the maximum page ID as the new maximum page ID.

[0091] S208: In the case of a node splitting into multiple nodes or a node becoming a free node, add the ID of the node to the free ID list.

[0092] When creating a new node or updating a node, it is equivalent to creating a new node. At this time, an ID needs to be assigned to the new node. You can first query the free ID list to see if there is an ID that meets the conditions. If there is, take it out and assign it to the new node. Otherwise, the maximum page ID will be assigned to the new node, and the maximum page ID will be incremented. There is also ID recycling. When node A splits into nodes B and C, the page IDs of node A will be recycled and incorporated into the free ID list. When it is found that a certain node becomes an empty node, its page ID will also be recycled.

[0093] It can be understood that by using the maximum page ID and the free ID list, IDs can be assigned to new nodes and free IDs can be recycled, thus realizing the intelligent management of IDs.

[0094] In some embodiments, for the Merkle B+ tree, multi-version control is equivalent to saving multiple logical trees on the disk. When the data needs to be rolled back to a certain version, as long as the root of the tree is pointed to the root of a certain saved tree. Assume that the database provided by the embodiments of the present application supports the rollback of two versions of data. For example, when transaction 4 is completed, it can be rolled back to the state of transaction 3 at most.

[0095] The following will be described in conjunction with Figure 4 For illustration, assume that each node is represented by an ID.

[0096] First, transaction 1 is completed. The maximum page ID is 4, the free page ID list is empty, and there is no ID to be released in the list of free pages to be released.

[0097] Secondly, after transaction 2 updates the key value, nodes 2 and 3 become dirty nodes. Node 2 splits into nodes 4 and 5. At this time, the free page list is empty, so the maximum page ID is incremented for assignment. The two IDs of nodes 2 and 3 will not be immediately released and added to the free page ID list, but are placed in the list of free pages to be released. After the data nodes are updated, the root node also needs to perform repeated operations, that is, node 1 also needs to be updated, which will not be elaborated here. The final result is that the maximum page ID is 8, the free page ID list is empty, and in the list of free pages to be released, transaction 1 has IDs 1, 2, and 3.

[0098] When transaction 3 starts, since only two versions of rollback are supported, transaction 1 in the list to be released needs to be released, and IDs 1, 2, and 3 are put into the free page ID list. After transaction 3 is updated, if node 6 becomes a dirty node, correspondingly, root node 7 will also become a dirty node. Therefore, IDs 1 and 2 can be taken out from the free page ID list and assigned to the new node, and node 6 is placed in the list to be released. The final result is that the free page ID has ID 3, and in the list to be released, transaction 2 has IDs 6 and 7.

[0099] At this time, if it is necessary to roll back to Transaction 2, since the root node of Transaction 2 is recorded as ID7, the free page list and the list to be released, the root node is pointed to ID7, and the free page list and the list to be released are replaced, thus realizing the rollback of two versions of data.

[0100] Theoretically, since more versions can be saved, the above method can support more version control and data rollback.

[0101] In some embodiments, it is stipulated that there is a field root in each account to represent the Merkle root of the contract data under the account, as follows:

[0102]

[0103] For the contract data under an account, it is placed in a table in the multi-Merkle B+-tree database, and the name of this table is the account address address. Since a table is a Merkle B+-tree, the Merkle root of each table, that is, the root of subTree, can be placed in the root field of each corresponding account. Then, the root of the account database is used as the world state.

[0104] It should be noted that the root of the rootTree in the multi-Merkle B+-tree database is meaningless and is only used as an index entry for data.

[0105] Exemplarily, as shown in (a) of Figure 5 The nodes a1, a2, and a3 of the single-Merkle B+-tree are the nodes of the account data of three contract users. As shown in (b) of Figure 5 The roots of the multi-Merkle tree B+-trees are root1, root2, and root3 respectively. root1, root2, and root3 are placed in the root fields of a1, a2, and a3, so that the root root of the account database becomes the world state.

[0106] In some embodiments, an account data structure is designed to generate a double-layer proof to support the Merkle proof for contract data. The data management method provided in the embodiments of the present application may further include the following S209 to S211.

[0107] S209. Receive a proof request for the target key key.

[0108] S210. Based on this proof request, splice all the nodes on the path from the node where the target key key is located to the root node of the Merkle B+-tree to generate the Merkle proof of the target key.

[0109] S211. Traverse all the nodes on this path, and for each node, execute:

[0110] Calculate the verification hash value of each node;

[0111] When the verification hash value of each node is equal to the hash value stored in each node, search for the target key in each node;

[0112] When the target key meets the target conditions, the proof request is successfully verified.

[0113] Among them, the target conditions include: the target key hits a key in the sub-node list of each index node on the path, and the hit key is equal to the minimum key in the sub-node list of the next node of each index node; the target key hits a key in the sub-node list of the data node on the path.

[0114] It should be noted that "hitting" in the embodiments of the present application means that there is an equal key in the list.

[0115] Take Figure 1 as an example. Assume that the target key is key: "a". The Merkle proof of the target key includes node n1, node n2, and node n4. First, calculate the verification hash value of node n1 and check if it is equal to the hash value stored in node n1; if equal, then calculate the verification hash value of node n2 and check if it is equal to the hash value stored in node n2; if equal, then calculate the verification hash value of node n4 and check if it is equal to the hash value stored in node n4.

[0116] When the verification hash value of each node is equal to the hash value stored in each node, search for key: "a" in node n1, node n2, and node n4. First, key: "a" can be hit in the sub-node list of node n1 and is equal to the minimum key in the sub-node list of node n2. Then, key: "a" can be hit in the sub-node list of node n2 and is equal to the minimum key in the sub-node list of node n4. Finally, key: "a" can be hit in the sub-node list of node n4. Therefore, the proof request is successfully verified.

[0117] It should be noted that the above S209 to S211 are applicable to both the generation and verification of proofs for the account database and the generation and verification of proofs for the contract database. If the proof for the account database is called a single-layer proof, then the proof for the contract database can be called a double-layer proof. The double-layer proof consists of the proof for the account database and the single-table proof for the contract database.

[0118] Exemplarily, the structures of the proof for the account database and the proof for the contract database are as follows:

[0119] type Proof struct{

[0120] AccountProofPath / / Account database proof

[0121] StateProofPath / / Contract database proof

[0122] }

[0123] Take Figure 5 as an example. If you want to generate a two - layer proof of contract data s2, then the AccountProofPath of this proof = [root of the account tree, a2], and StateProofPath = [root2, s2].

[0124] Therefore, verifying the two - layer proof is also to verify the two layers of proof separately. It should be noted that it is also necessary to verify that the root of the Merkle B + tree corresponding to a contract account is equal to the root field of the account data of a contract account, that is, to verify that the root of the account in AccountProofPath needs to be equal to the root of the tree in StateProofPath.

[0125] It can be understood that the embodiment of the present application designs an account data structure, generates a two - layer proof to support the Merkle proof for contract data, and the generation and verification of the proof are simple and efficient.

[0126] As Figure 6 shown, the embodiment of the present application also provides a data management device 60. The device includes:

[0127] A processing module 61, which can be used to create a target transaction.

[0128] A storage module 62, which can be used to store the account data to the data node of the single Merkle B + tree if the target transaction includes a storage instruction for the account data; if the target transaction includes a storage instruction for the contract data of a contract account, then store the contract data to the data node of the Merkle B + tree corresponding to the contract account, and different contract accounts correspond to different Merkle B + trees.

[0129] Among them, the last layer of the Merkle B + tree is the data node, and the other layers of the Merkle B + tree are index nodes. The root of the Merkle B + tree corresponding to a contract account is stored in the root field of the account data of the contract account.

[0130] In some embodiments, the processing module 61 can also be used to:

[0131] Receive a proof request for a target key;

[0132] Based on the proof request, splice all the nodes on the path from the node where the target key is located to the root node of the Merkle B + tree to generate a Merkle proof of the target key;

[0133] Traverse all the nodes on this path and perform the following for each node:

[0134] Calculate the verification hash value of each node;

[0135] When the verification hash value of each node is equal to the hash value stored in each node, search for the target key in each node;

[0136] When the target key meets the target conditions, the proof request is successfully verified;

[0137] Wherein, the target conditions include: the target key hits a key in the list of children of each index node on this path, and the hit key is equal to the minimum key in the list of children of the next node of each index node; the target key hits a key in the list of children of the data node on this path.

[0138] In some embodiments, the target key value is the key value in the Merkle B+ tree corresponding to a contract account. The processing module 61 can also be used to: before the proof request is successfully verified, verify that the root of the Merkle B+ tree corresponding to a contract account is equal to the root field of the account data of a contract account.

[0139] In some embodiments, the processing module 61 can also be used to:

[0140] After the target transaction is completed, starting from the last layer of the Merkle B+ tree as the starting layer and the topmost layer of the Merkle B+ tree as the ending layer, layer by layer, determine whether the number of key-value pairs of each node in each layer is greater than or equal to a preset value;

[0141] When the number of key-value pairs of a data node is greater than or equal to the preset value, split a data node into multiple data nodes with the number of key-value pairs less than the preset value.

[0142] In some embodiments, the index node of the Merkle B+ tree stores the minimum key and hash value of the child nodes. The processing module 61 can also be used to:

[0143] After the target transaction ends, starting from the topmost layer of the Merkle B+ tree as the starting layer and the last layer of the Merkle B+ tree as the ending layer, layer by layer, calculate the hash values of all child nodes of each node in each layer in parallel and update the hash values; wherein, the hash value of each node is determined by the hash value of the sum of its child node list.

[0144] In some embodiments, each node of the Merkle B+ tree includes an ID. The processing module 61 can also be used to:

[0145] In the case of creating or updating a new node, if there is an ID in the free ID list that meets the conditions, an ID in the free ID list is assigned to the new node; or, if there is no ID in the free ID list that meets the conditions, the maximum page ID is assigned to the new node, and the maximum page ID is incremented as the new maximum page ID.

[0146] In some embodiments, each node of the Merkle B+ tree includes an ID. The processing module 61 can also be used for:

[0147] In the case of a node splitting into multiple nodes or a node becoming a free node, the ID of the node is added to the free ID list.

[0148] In the data management device provided by the embodiments of the present application, after creating a target transaction, if the target transaction includes a storage instruction for account data, the account data can be stored in the data node of the single Merkle B+ tree; if the target transaction includes a storage instruction for contract data of a contract account, the contract data can be stored in the data node of the Merkle B+ tree corresponding to a contract account, and different contract accounts correspond to different Merkle B+ trees. In this way, the account data is stored using a single Merkle B+ tree, and the contract data of multiple contract accounts is stored using multiple Merkle B+ trees. Since the account data and the contract data are stored separately, the data volume of each database is reduced, and the read / write performance and scalability are improved, thereby improving the overall performance of the blockchain.

[0149] As Figure 7 shown, the embodiments of the present invention further provide a blockchain system 700, including the shown processor 701, a memory 702, and a computer program stored on the memory 702 and executable on the processor 701. When the computer program is executed by the processor, each process of the above method embodiments is implemented, and the same technical effects can be achieved. To avoid repetition, it will not be described here again.

[0150] Exemplarily, the computer program can be divided into one or more modules / units. One or more modules / units are stored in the memory and executed by the processor to complete the present application. One or more modules / units can be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer program in the server. For example, the computer program can be divided into a request receiving unit, an information obtaining unit, an information searching unit, and a data processing unit.

[0151] The processor can be a central processing unit (CPU), or it can also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0152] The memory can be an internal storage unit of the server, such as the hard disk or memory of the server. The memory can also be an external storage device of the server, such as a plug-in hard disk equipped on the server, a smart media card (SMC), a secure digital (SD) card, a flash card, etc.

[0153] Furthermore, the memory can also include both the internal storage unit of the server and the external storage device. The memory is used to store computer programs and other programs and data required by the server. The memory can also be used to temporarily store the data that has been output or will be output.

[0154] The embodiments of the present invention also provide a storage medium on which a computer program is stored. When the computer program is executed by a processor, it implements each process of the above method embodiments and can achieve the same technical effects. To avoid repetition, it will not be elaborated here. Among them, the computer-readable storage medium is, for example, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disc, etc.

[0155] It should be noted that in this article, the term "including", "comprising", or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article, or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or further includes elements inherent to such process, method, article, or device. Without further limitations, an element defined by the statement "including one..." does not exclude the existence of another identical element in the process, method, article, or device including the element.

[0156] Through the description of the above embodiments, those skilled in the art can clearly understand that the above-described embodiment methods can be implemented by means of software plus a necessary general hardware platform. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions for causing an electronic device to execute the methods described in various embodiments of the present invention.

[0157] The embodiments of the present invention have been described above in conjunction with the accompanying drawings. However, the present invention is not limited to the above specific embodiments. The above specific embodiments are merely illustrative and not restrictive. Under the inspiration of the present invention, those of ordinary skill in the art can also make many forms without departing from the spirit and scope protected by the claims of the present invention, and all of them fall within the protection scope of the present invention.

Claims

1. A data management method, characterized in that, the method includes: creating a target transaction; if the target transaction includes a storage instruction for account data, storing the account data in a data node of a single Merkle B+ tree; if the target transaction includes a storage instruction for contract data of a contract account, storing the contract data in a data node of a Merkle B+ tree corresponding to the contract account, where different contract accounts correspond to different Merkle B+ trees; wherein, each Merkle B+ tree in the multi-Merkle B+ tree is a table, corresponding to the contract data of a contract account respectively, called a subtree, and the single Merkle B+ tree is used to manage the information of the subtree, called the root tree; wherein, the last layer of the Merkle B+ tree is the data node, and the other layers of the Merkle B+ tree are index nodes; the root of the Merkle B+ tree corresponding to a contract account is stored in the root field of the account data of the contract account.

2. The data management method according to claim 1, characterized in that, the method further includes: receiving a proof request for a target key; based on the proof request, splicing all nodes on the path from the node where the target key is located to the root node of the Merkle B+ tree to generate a Merkle proof of the target key; traversing all nodes on the path, and for each node, performing: calculating a verification hash value of each node; when the verification hash value of each node is equal to the hash value stored in each node, looking up the target key in each node; when the target key meets the target conditions, the proof request is successfully verified; wherein, the target conditions include: the target key hits a key in the child node list of each index node on the path, and the hit key is equal to the minimum key in the child node list of the next node of each index node; the target key hits a key in the child node list of the data node on the path.

3. The data management method according to claim 2, characterized in that, the target key value is a key value in a Merkle B+ tree corresponding to a contract account; before the proof request is successfully verified, the method further includes: verifying that the root of the Merkle B+ tree corresponding to a contract account is equal to the root field of the account data of the contract account.

4. The data management method according to claim 1, characterized in that, the method further includes: after completing the target transaction, starting from the last layer of the Merkle B+ tree and ending at the topmost layer of the Merkle B+ tree, judging layer by layer whether the number of key-value pairs of each node in each layer is greater than or equal to a preset value; when the number of key-value pairs of a data node is greater than or equal to the preset value, splitting the data node into multiple data nodes with the number of key-value pairs less than the preset value.

5. The data management method according to claim 4, characterized in that, the index node of the Merkle B+ tree stores the minimum key and hash value of the child node; the method further includes: After the target transaction ends, starting from the top layer of the Merkle B+ tree and ending at the last layer of the Merkle B+ tree, calculate the hash values of all child nodes of each node on each layer in parallel and update the hash values. Among them, the hash value of each node is determined by the hash value of the sum of its child node list.

6. The data management method according to claim 4, characterized in that each node of the Merkle B+ tree includes an ID; the method further includes: in the case of creating a new node or updating an existing node, if there is an ID in the free ID list that meets the conditions, assign one ID from the free ID list to the new node; or, if there is no ID in the free ID list that meets the conditions, assign the maximum page ID to the new node and increment the maximum page ID as the new maximum page ID.

7. The data management method according to claim 4, characterized in that each node of the Merkle B+ tree includes an ID; the method further includes: in the case of a node splitting into multiple nodes or a node becoming a free node, add the ID of the node to the free ID list.

8. A data management device, characterized in that the device includes: a processing module for creating a target transaction; a storage module for storing the account data in the data node of the single Merkle B+ tree if the target transaction includes a storage instruction for the account data; and storing the contract data in the data node of the Merkle B+ tree corresponding to the contract account if the target transaction includes a storage instruction for the contract data of a contract account, where different contract accounts correspond to different Merkle B+ trees; among them, each Merkle B+ tree in the multiple Merkle B+ trees is a table corresponding to the contract data of a contract account, called a subtree, and the single Merkle B+ tree is used to manage the information of the subtree, called the root tree; wherein, the last layer of the Merkle B+ tree is the data node, and the other layers of the Merkle B+ tree are index nodes; the root of the Merkle B+ tree corresponding to a contract account is stored in the root field of the account data of the contract account.

9. A blockchain system, characterized in that it includes a processor, a memory, and a computer program stored on the memory and executable on the processor, and when the computer program is executed by the processor, it implements the data management method according to any one of claims 1 to 7.

10. A storage medium, characterized in that a computer program is stored on the storage medium, and the computer program is loaded by a processor to execute the data management method according to any one of claims 1 to 7.

Images