A blockchain-based metadata management method and system

Abstract

The application belongs to the technical field of computer storage, and specifically discloses a metadata management method and system based on a block chain. In the application, a client sends a first request to a consistent hash ring of a storage location for storing target metadata and target check data corresponding to the target metadata in the block chain; the block chain acquires the target metadata or the target check data according to the storage location of the target metadata to be queried and the target check data corresponding to the target metadata carried in the first request sent by the client; the client receives the target metadata or the target check data sent by the block chain, and acquires the target metadata to be queried according to the received target metadata or target check data. Compared with the existing direct query mode of the block chain, the application does not need to traverse the entire block chain, reduces the query overhead, and improves the query efficiency. Compared with the existing indirect query mode of the block chain, the nodes in the block chain do not need to store an additional complete ledger data, thereby reducing the storage overhead.

Description

Technical Field

[0001] This application belongs to the field of computer storage technology, and more specifically, relates to a blockchain-based metadata management method and system. Background Technology

[0002] With the advent of the big data era, new technologies such as cloud computing, 5G, the Internet of Things, and artificial intelligence are booming, leading to ever-increasing storage scale. Compared to traditional storage methods, cloud storage has become the mainstream data storage solution due to its low cost (no need to purchase and maintain storage devices), ease of use (pay-as-you-go, pay-to-use), and high data availability (relying on data fault tolerance technology, it can be remotely deployed). Many enterprises are choosing a multi-cloud strategy for their cloud storage architecture. How to integrate multiple clouds to achieve efficient and reliable data sharing in a multi-cloud environment has always been a core issue in multi-cloud data management.

[0003] Blockchain, due to its immutability, is used to solve the problem of trusted data sharing. Existing blockchain storage management systems typically store metadata on the blockchain to reduce data storage overhead. However, as cloud storage scales up, the volume of metadata becomes enormous (for example, petabyte-level data often generates terabyte-level metadata). Each node in the blockchain needs to store a complete copy of the metadata, resulting in high storage overhead for the entire system. But without storing metadata, metadata security cannot be guaranteed, thus affecting data security.

[0004] In current blockchain storage systems, the blockchain ledger primarily records metadata of data stored by various cloud storage systems, and the query efficiency of this metadata determines the overall system performance. When querying data in the blockchain ledger, there are typically two query methods: direct query and indirect query. Direct query first checks the most recent block. If the data being searched for is not found in the most recent block, it iterates through the entire blockchain until the target data is found. For example, if you need to find data blocks stored in the first few blocks of the blockchain, you need to backtrack from the last block of the current blockchain, and each backtracking block needs to be verified, resulting in significant query overhead. Indirect query, on the other hand, uses a key-value pair database to store an additional copy of the ledger data. It performs a fast lookup of the ledger data using the key-value pair database and then verifies it using the blockchain. However, when the amount of stored data is too large, the amount of metadata is also enormous (for example, petabyte-level data often generates terabyte-level metadata). Since each node in the blockchain network stores a complete copy of the blockchain ledger, directly using the blockchain ledger to store metadata incurs high storage overhead, and indirect query further increases storage overhead. Summary of the Invention

[0005] In view of the shortcomings of existing technologies, the purpose of this application is to provide a blockchain-based metadata management method and system, which aims to solve the problems of low query efficiency and high storage overhead in existing blockchain query methods.

[0006] To achieve the above objectives, firstly, this application provides a blockchain-based metadata management method, comprising:

[0007] Send a first request to the consistent hash ring in the blockchain. The consistent hash ring is used to store the target metadata to be queried or the target verification data corresponding to the target metadata. The first request carries the target metadata.

[0008] Receive target metadata or target verification data sent by the blockchain;

[0009] Obtain the target metadata based on the target metadata or target verification data.

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

[0011] A second request is sent to the blockchain, which is used to audit the integrity of the metadata stored on the servers corresponding to each node.

[0012] The root hash value of the Merkle tree in the server corresponding to each node of the blockchain is received. The leaf nodes of the Merkle tree are used to store the hash value of metadata or the verification data corresponding to the metadata.

[0013] Based on the root hash value of the Merkle tree in the server corresponding to each node sent by the blockchain, the integrity audit of the metadata stored in the server corresponding to each node is performed.

[0014] Secondly, this application provides a blockchain-based metadata management method, including:

[0015] The first request sent by the client to the consistent hashing ring is received. The consistent hashing ring is used to store the target metadata to be queried or the target verification data corresponding to the target metadata. The first request carries the target metadata.

[0016] In response to the first request, target metadata or target verification data is sent to the client so that the client can obtain the target metadata based on the target metadata or target verification data.

[0017] In some embodiments, the above method further includes:

[0018] Receive a second request sent by the client. The second request is used to perform an integrity audit on the metadata stored on the server corresponding to each node.

[0019] In response to the second request, the root hash value of the Merkle tree in the server corresponding to each node is sent to the client, so that the client can perform integrity audit on the metadata stored in the server corresponding to each node based on the root hash value of the Merkle tree in the server corresponding to each node sent by the blockchain. The leaf nodes of the Merkle tree are used to store the hash value of the metadata or the verification data corresponding to the metadata.

[0020] In some embodiments, sending target metadata or target verification data to the client in response to a first request includes:

[0021] In response to the first request, a target stable node for storing target metadata is determined from the various stable nodes included in the storage location, and a target unstable node for storing target verification data is determined from the various unstable nodes included in the storage location.

[0022] Send the target metadata from the target stable node and / or the target verification data from the target unstable node to the client.

[0023] In some embodiments, the above method further includes:

[0024] Based on the frequency of server failures for each node, the nodes are divided into stable nodes and unstable nodes. Stable nodes are used to store metadata, while unstable nodes are used to store the verification data corresponding to the metadata.

[0025] Thirdly, this application provides a blockchain-based metadata management system, including:

[0026] The first sending module is used to send a first request to the consistent hash ring in the blockchain. The consistent hash ring is used to store the target metadata to be queried or the target verification data corresponding to the target metadata. The first request carries the target metadata.

[0027] The first receiving module is used to receive target metadata or target verification data sent by the blockchain.

[0028] The data acquisition module is used to acquire target metadata based on target metadata or target verification data.

[0029] Fourthly, this application provides a blockchain-based metadata management system, including:

[0030] The second receiving module is used to receive the first request sent by the client to the consistent hashing ring. The consistent hashing ring is used to store the target metadata to be queried or the target verification data corresponding to the target metadata. The first request carries the target metadata.

[0031] The second sending module is used to respond to the first request by sending the target metadata or target verification data to the client so that the client can obtain the target metadata based on the target metadata or target verification data.

[0032] Fifthly, this application provides an electronic device, comprising: at least one memory for storing a program; and at least one processor for executing the program stored in the memory, wherein when the program stored in the memory is executed, the processor is configured to perform the methods described in any of the embodiments of the first or second aspect.

[0033] In a sixth aspect, this application provides a computer-readable storage medium storing a computer program that, when run on a processor, causes the processor to perform the methods described in any of the embodiments of the first or second aspect.

[0034] In a seventh aspect, this application provides a computer program product that, when run on a processor, causes the processor to perform the methods described in any of the embodiments of the first or second aspect.

[0035] Overall, the technical solutions conceived in this application have the following beneficial effects compared with the prior art:

[0036] This application provides a blockchain-based metadata management method and system. The client sends a first request to a consistent hash ring in the blockchain used to store target metadata and its corresponding target verification data. The blockchain retrieves the target metadata or target verification data based on the storage location of the target metadata to be queried and its corresponding target verification data carried in the first request sent by the client. The client receives the target metadata or target verification data sent by the blockchain and retrieves the target metadata to be queried based on the received target metadata or target verification data. Compared with existing direct blockchain query methods, this method eliminates the need to traverse the entire blockchain, reducing query overhead and improving query efficiency. Compared with existing indirect blockchain query methods, nodes in the blockchain do not need to store an additional copy of the complete ledger data, reducing storage overhead. Attached Figure Description

[0037] Figure 1 This is one of the flowcharts illustrating the blockchain-based metadata management method provided in this application embodiment;

[0038] Figure 2 This is the second flowchart illustrating the blockchain-based metadata management method provided in this application embodiment;

[0039] Figure 3 This is a schematic diagram of the atomic hash ring and the check hash ring provided in the embodiments of this application;

[0040] Figure 4 This is the third flowchart illustrating the blockchain-based metadata management method provided in this application embodiment;

[0041] Figure 5 This is a schematic diagram comparing the blockchain-based metadata management method provided in this application embodiment with the traditional blockchain method for storing metadata;

[0042] Figure 6 This is the fourth flowchart illustrating the blockchain-based metadata management method provided in this application embodiment;

[0043] Figure 7 This is one of the structural schematic diagrams of a blockchain-based metadata management device provided in the embodiments of this application;

[0044] Figure 8 This is a second schematic diagram of the structure of the blockchain-based metadata management device provided in the embodiments of this application;

[0045] Figure 9 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0047] In this article, the term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The symbol " / " in this article indicates that the related objects are in an "or" relationship; for example, A / B means A or B.

[0048] The terms "first" and "second," etc., used in the specification and claims herein are used to distinguish different objects, not to describe a specific order of the objects. For example, "first request" and "second request," etc., are used to distinguish different requests, not to describe a specific order of the requests.

[0049] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0050] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more.

[0051] The embodiments of this application are described below with reference to the accompanying drawings.

[0052] Please see Figure 1 This application provides a blockchain-based metadata management method, including steps 110, 120 and 130.

[0053] Step 110 sends a first request to the consistent hash ring in the blockchain. The consistent hash ring is used to store the target metadata to be queried or the target verification data corresponding to the target metadata. The first request carries the target metadata.

[0054] Step 120: Receive target metadata or target verification data sent by the blockchain;

[0055] Step 130: Obtain target metadata based on target metadata or target verification data.

[0056] It should be noted that the above method can be executed by the client.

[0057] The blockchain-based metadata management method provided in this application can be applied to a distributed cloud storage environment, enabling efficient metadata storage and management.

[0058] In this embodiment of the application, the blockchain is responsible for storing the root hash value of the Merkle tree in the consistent hash ring and the servers of each node. The immutability of the data stored in the blockchain protects the security of metadata routing, and the security of metadata is guaranteed by metadata integrity verification.

[0059] A consistent hash ring consists of a metadata hash ring and a check hash ring. The metadata hash ring is used to manage stable nodes, while the check hash ring is used to manage unstable nodes.

[0060] Stable nodes are used to store metadata, more specifically, to store metadata blocks corresponding to the metadata. These metadata blocks are obtained by packaging the metadata stored within each node into fixed-size data blocks using the servers corresponding to those nodes.

[0061] Unstable nodes are used to store verification data corresponding to metadata, more specifically, to store verification data blocks corresponding to metadata. These verification data blocks are generated by encoding the metadata blocks using erasure coding.

[0062] In this embodiment, distributed storage of metadata is achieved through two consistent hash rings (a metadata hash ring and a verification data ring). Consistent hashing is used to manage metadata, while the blockchain stores the consistent hashes and the Merkle root hashes of each node's metadata to ensure metadata security. To address the issue of frequent system entry and exit caused by node instability, a multi-hash ring redundancy strategy based on erasure coding is used to organize system nodes. Through a divide-and-conquer approach, stable and unstable nodes are managed in two separate consistent hash rings, achieving efficient storage and management of metadata. This improves reliability while reducing additional system storage costs, significantly enhancing system performance and reliability.

[0063] In this embodiment, each server in the decentralized metadata server cluster acts as a node in the blockchain. This decentralized metadata server cluster includes multiple servers, which can be used to store metadata or corresponding verification data. Both metadata and verification data can be stored using a Merkle tree. Specifically, the leaf nodes of the Merkle tree are used to store the hash values ​​of the metadata or corresponding verification data, and the root hash value is used for rapid auditing of metadata integrity. The decentralized metadata server cluster exchanges data and collaborates with each other through a secure communication protocol.

[0064] In this embodiment, metadata and corresponding verification data are mapped to corresponding nodes in the consistent hashing ring of the blockchain using a consistent hashing algorithm module for storage. The node location for storing metadata or verification data is determined based on the position of the hash value of the metadata or verification data mapped to the consistent hashing ring.

[0065] This consistent hashing algorithm module is used to map metadata and verification data to corresponding nodes of the consistent hashing ring for storage.

[0066] Specifically, the encoding / decoding module integrates metadata into fixed-size data blocks (i.e., metadata blocks), and erasure coding is used to encode the metadata blocks into check data blocks. The metadata blocks and check data blocks are mapped to the metadata hash ring and check hash ring, respectively, through the consistent hashing algorithm module.

[0067] The client sends a first request to the consistent hash ring in the blockchain, which carries the target metadata to be queried.

[0068] Upon receiving the first request, the consistent hash ring in the blockchain locates the node (i.e., the storage location) where the target metadata or the target verification data corresponding to the target metadata is stored.

[0069] In the blockchain, the node in the metadata hash ring that stores the target metadata and the node in the verification hash ring that stores the target verification data synchronously send the target metadata and target verification data to the client.

[0070] Since each node of the metadata hash ring stores the data block corresponding to the metadata, i.e., the metadata block, and each node of the verification hash ring stores the data block corresponding to the verification data, i.e., the verification data block, the target metadata and target verification data mentioned above are also sent to the client in the form of corresponding data blocks.

[0071] If the client first receives the data block corresponding to the target metadata, it can obtain the target metadata based on that data block.

[0072] If the client first receives the data block corresponding to the target verification data, it needs to decode the data block to obtain the target metadata corresponding to the data block.

[0073] When a node fails and goes offline, the data of that failed node can be recovered and stored on other nodes.

[0074] When a node fails and goes offline, the metadata can be read through the metadata blocks or verification data blocks stored on other nodes.

[0075] When a stable node goes offline, the information of the offline stable node is recorded, and the node's metadata is retrieved from the verification hash ring to restore the node.

[0076] When an unstable node goes offline, record the information of the unstable node and retrieve the node's metadata from the metadata hash ring.

[0077] The blockchain-based metadata management method provided in this application involves a client sending a first request to a consistent hash ring in the blockchain used to store target metadata and corresponding target verification data. The blockchain retrieves the target metadata or target verification data based on the storage location of the target metadata to be queried and its corresponding target verification data carried in the first request sent by the client. The client receives the target metadata or target verification data sent by the blockchain and retrieves the target metadata to be queried based on the received target metadata or target verification data. Compared to existing direct blockchain query methods, this method eliminates the need to traverse the entire blockchain, reducing query overhead and improving query efficiency. Compared to existing indirect blockchain query methods, nodes in the blockchain do not need to store an additional complete copy of the ledger data, reducing storage overhead.

[0078] Furthermore, in some embodiments, the above method further includes:

[0079] A second request is sent to the blockchain, which is used to audit the integrity of the metadata stored on the servers corresponding to each node.

[0080] The root hash value of the Merkle tree in the server corresponding to each node of the blockchain is received. The leaf nodes of the Merkle tree are used to store the hash value of metadata or the verification data corresponding to the metadata.

[0081] Based on the root hash value of the Merkle tree in the server corresponding to each node sent by the blockchain, the integrity audit of the metadata stored in the server corresponding to each node is performed.

[0082] In this embodiment, each node needs to audit whether the metadata stored by the node has been tampered with through the smart contract of the blockchain at regular intervals. During the audit, the root hash value of the Merkle tree of each node stored in the blockchain is used for fast auditing, and the specific implementation is as follows:

[0083] The client sends a second request to the blockchain, which can be used to perform an integrity audit of the metadata stored in the servers corresponding to each node.

[0084] Integrity auditing of metadata stored in the server can be achieved using the root hash value of the Merkle tree storing the hash values ​​of the metadata in the blockchain, or using the root hash value of the Merkle tree storing the hash values ​​of the verification data corresponding to the metadata in the blockchain.

[0085] The client receives the root hash value of the Merkle tree containing the hash values ​​of the stored metadata (hereinafter referred to as the first root hash value) or the root hash value of the Merkle tree containing the hash values ​​of the verification data corresponding to the stored metadata (hereinafter referred to as the second root hash value). The client compares the received first root hash value with the root hash value of the Merkle tree used to store the hash values ​​of the metadata in the server. If they match, the metadata passes the integrity audit; otherwise, the metadata fails the integrity audit.

[0086] The client compares the received second root hash value with the root hash value of the Merkle tree used by the server to store the hash values ​​of the verification data. If they match, the metadata passes the integrity audit; otherwise, the metadata fails the integrity audit.

[0087] Please see further. Figure 2 The method may include:

[0088] The client organizes metadata into fixed-size metadata blocks and uses erasure coding to encode the metadata blocks into corresponding check blocks, which together with the metadata blocks form stripes.

[0089] Metadata blocks and check blocks are mapped to different consistent hash rings, and different consistent hash rings include different storage nodes (e.g., Figure 3 The set of stable nodes (including stable nodes N1, N2, and N3) and the set of unstable nodes (including unstable nodes N4, N5, and N6) are shown.

[0090] The client queries the consistent hash ring stored in the blockchain to obtain the storage location of the target metadata or the target verification data corresponding to the target metadata, and sends the first request to the node corresponding to the storage location in the consistent hash ring.

[0091] The client receives target metadata or target verification data sent by the blockchain. Simultaneously, the client sends a first request to both the metadata hash ring and the verification hash ring. Upon receiving the first request, the nodes on both the metadata hash ring and the verification hash ring simultaneously return the target metadata or target verification data.

[0092] Please see further. Figure 4 The method also includes:

[0093] In a blockchain, nodes maintain a Merkle tree of their own metadata and periodically update the Merkle tree to the blockchain for metadata integrity auditing.

[0094] When a node fails, the faulty node information is recorded and the data stored on the faulty node (such as metadata or verification data) is recovered and migrated.

[0095] Preferably, in this step, a node with a fast response time is selected from both the metadata hash ring and the check hash ring for data recovery. The recovered data is then mapped to a new node for storage.

[0096] Update the consistent hash ring information and store the new consistent hash ring on the blockchain.

[0097] Please see further. Figure 5 This diagram illustrates a comparison between the blockchain-based metadata management method provided in this application and the traditional blockchain method for storing metadata. The traditional blockchain method stores all metadata on the blockchain, resulting in high query overhead. For example, to query metadata block A, the system needs to backtrack the entire blockchain, a time-consuming process. Furthermore, since all nodes in the blockchain must store a complete copy, storage overhead is also high. In contrast, this application only stores the consistent hash ring and the root hash value of the Merkle tree on the blockchain. When querying metadata, only the consistent hash of the last block in the blockchain is searched, thus reducing query overhead.

[0098] The blockchain-based metadata management method provided in this application uses the root hash value of the Merkle tree of the metadata or verification data stored on the server corresponding to each node to send a second request to the blockchain for integrity auditing of the metadata stored on the server. This ensures the security of metadata and is suitable for decentralized storage environments.

[0099] Please see Figure 6 This application provides a blockchain-based metadata management method, including steps 210 and 220.

[0100] Step 210 receives the first request sent by the client to the consistent hashing ring. The consistent hashing ring is used to store the target metadata to be queried or the target verification data corresponding to the target metadata. The first request carries the target metadata.

[0101] Step 220 responds to the first request by sending the target metadata or target verification data to the client so that the client can obtain the target metadata based on the target metadata or target verification data.

[0102] It should be noted that the above method is implemented by the blockchain.

[0103] In this embodiment of the application, the blockchain client sends a first request to the consistent hash ring, which carries the target metadata to be queried.

[0104] Upon receiving the first request, the consistent hash ring in the blockchain responds by locating the node location (i.e., storage location) where the target metadata or the target verification data corresponding to the target metadata is stored.

[0105] In the blockchain, the node in the metadata hash ring that stores the target metadata and the node in the verification hash ring that stores the target verification data synchronously send the target metadata and target verification data to the client.

[0106] Since each node of the metadata hash ring stores the data block corresponding to the metadata (i.e., metadata block), and each node of the verification hash ring stores the data block corresponding to the verification data (i.e., verification data block), the target metadata and target verification data are also sent to the client in the form of corresponding data blocks, so that the client can obtain the target metadata based on the data block corresponding to the target metadata or the data block corresponding to the target verification data.

[0107] If the client receives the data block corresponding to the target metadata first, it can obtain the target metadata based on that data block.

[0108] If the client receives the data block corresponding to the target verification data first, it needs to decode the data block to obtain the target metadata corresponding to the data block.

[0109] The blockchain-based metadata management method provided in this application embodiment involves the blockchain receiving a first request from a client for a consistent hash ring containing the storage location of target metadata and corresponding target verification data. Based on the target metadata to be queried and the storage location of its corresponding target verification data carried in the first request, the blockchain obtains the target metadata or target verification data. The target metadata or target verification data is then sent to the client, allowing the client to retrieve the target metadata to be queried based on the received target metadata or target verification data. Compared to existing direct blockchain query methods, this method eliminates the need to traverse the entire blockchain, reducing query overhead and improving query efficiency. Compared to existing indirect blockchain query methods, nodes in the blockchain do not need to store an additional complete copy of the ledger data, reducing storage overhead.

[0110] Furthermore, in some embodiments, the above method further includes:

[0111] Receive a second request sent by the client. The second request is used to perform an integrity audit on the metadata stored on the server corresponding to each node.

[0112] In response to the second request, the root hash value of the Merkle tree in the server corresponding to each node is sent to the client, so that the client can perform integrity audit on the metadata stored in the server corresponding to each node based on the root hash value of the Merkle tree in the server corresponding to each node sent by the blockchain. The leaf nodes of the Merkle tree are used to store the hash value of the metadata or the verification data corresponding to the metadata.

[0113] In this embodiment, each node needs to audit whether the metadata stored by the node has been tampered with through the smart contract of the blockchain at regular intervals. During the audit, the root hash value of the Merkle tree of each node stored in the blockchain is used for fast auditing, and the specific implementation is as follows:

[0114] Receive a second request sent by the client, which can be used to perform integrity auditing on the metadata stored in the servers corresponding to each node.

[0115] Integrity auditing of metadata stored in the server can be achieved using the root hash value of the Merkle tree storing the hash values ​​of the metadata in the blockchain, or using the root hash value of the Merkle tree storing the hash values ​​of the verification data corresponding to the metadata in the blockchain.

[0116] In response to the second request, the blockchain sends the root hash value of the Merkle tree storing the hash value of the metadata (hereinafter referred to as the first root hash value) or the root hash value of the Merkle tree storing the hash value of the verification data corresponding to the metadata (hereinafter referred to as the second root hash value) to the client, so that the client compares the received first root hash value with the root hash value of the Merkle tree used to store the hash value of the metadata in the server, and if they match, determines that the metadata has passed the integrity audit; if they do not match, determines that the metadata has not passed the integrity audit.

[0117] Alternatively, the client compares the received second root hash value with the root hash value of the Merkle tree used by the server to store the hash values ​​of the verification data, and if they match, determines that the metadata has passed the integrity audit; if they do not match, determines that the metadata has not passed the integrity audit.

[0118] The blockchain-based metadata management method provided in this application embodiment utilizes the root hash value of the Merkle tree of metadata or verification data stored on the server corresponding to each node to receive a second request sent by the client for integrity auditing of the metadata stored on the server, thereby ensuring metadata security and being suitable for decentralized storage environments.

[0119] Furthermore, in some embodiments, sending target metadata or target verification data to the client in response to the first request includes:

[0120] In response to the first request, a target stable node for storing target metadata is determined from the various stable nodes included in the storage location, and a target unstable node for storing target verification data is determined from the various unstable nodes included in the storage location.

[0121] Send the target metadata from the target stable node and / or the target verification data from the target unstable node to the client.

[0122] In this embodiment, in response to a first request sent by the client, the blockchain identifies a stable node from among the stable nodes storing the metadata to be queried, which is the target stable node. Similarly, it identifies an unstable node from among the unstable nodes storing the verification data corresponding to the metadata to be queried, which is the target unstable node.

[0123] Once the blockchain locates the node containing the target metadata or target verification data, it can send the target metadata from the stable node and / or the target verification data from the unstable node to the client.

[0124] Furthermore, in some embodiments, the above method further includes:

[0125] Based on the frequency of server failures for each node, the nodes are divided into stable nodes and unstable nodes. Stable nodes are used to store metadata, while unstable nodes are used to store the verification data corresponding to the metadata.

[0126] Please continue reading Figure 3 The original node set (i.e., the set of nodes corresponding to each server) is divided into a stable node set and an unstable node set. The stable node set (composed of stable nodes N1, N2, and N3) and the unstable node set (composed of unstable nodes N4, N5, and N6) are organized using two consistent hash rings. The stable node set is organized into a metadata hash ring to store metadata blocks, while the unstable node set is organized into a check hash ring to store checksum data blocks.

[0127] Specifically, the original node set is divided into a stable node set and an unstable node set using the following method based on Poisson distribution for judging stable and unstable nodes. By recording the failure frequency of the server corresponding to each node and rating the stability of the nodes according to Poisson distribution, stable nodes and unstable nodes are distinguished.

[0128] For example, suppose the number of times the server corresponding to each node fails each year is recorded via blockchain (annual failure frequency; the server cluster averaged 2.4 failures per year between 2010 and 2019). The average annual failure frequency of each node is calculated, and then the stability of the nodes is rated according to a Poisson distribution. The corresponding Poisson distribution formula is as follows:

[0129]

[0130] In the formula, X is a discrete random variable, which is a node here; λ is the variance, which is the average annual failure frequency here; and P(X=k) is the probability that node X will fail k times in one year.

[0131] Assuming a year is divided into n parts, the probability of a node failing within / 1n years approaches 0, thus allowing us to utilize the Poisson distribution. Here, λ equals the average annual failure frequency. Substituting this into the above formula yields the probability distribution of the number of failures of the corresponding node within a year. The stability of a node can then be assessed using the probability of k failures. For example, P(X=2)≤0.5 indicates that node X is a stable node, while P(X=2)≤0.5 indicates that node X is an unstable node.

[0132] In this embodiment, stable nodes are used to store metadata, and unstable nodes are used to store verification data corresponding to the metadata.

[0133] The following describes the blockchain-based metadata management system provided in this application. The blockchain-based metadata management system described below can be referred to in correspondence with the blockchain-based metadata management method described above.

[0134] Please see Figure 7 This application provides a blockchain-based metadata management system, including: a first sending module 710, a first receiving module 720, and a data acquisition module 730.

[0135] The first sending module 710 is used to send a first request to the consistent hash ring in the blockchain. The consistent hash ring is used to store the target metadata to be queried or the target verification data corresponding to the target metadata. The first request carries the target metadata.

[0136] The first receiving module 720 is used to receive target metadata or target verification data sent by the blockchain.

[0137] The data acquisition module 730 is used to acquire target metadata based on target metadata or target verification data.

[0138] The blockchain-based metadata management system provided in this application involves a client sending a first request to a consistent hash ring in the blockchain used to store target metadata and corresponding target verification data. The blockchain retrieves the target metadata or target verification data based on the storage location of the target metadata to be queried and its corresponding target verification data carried in the first request sent by the client. The client receives the target metadata or target verification data sent by the blockchain and retrieves the target metadata to be queried based on the received target metadata or target verification data. Compared to existing direct blockchain query methods, this method eliminates the need to traverse the entire blockchain, reducing query overhead and improving query efficiency. Compared to existing indirect blockchain query methods, nodes in the blockchain do not need to store an additional complete copy of the ledger data, reducing storage overhead.

[0139] Please see Figure 8 This application provides a blockchain-based metadata management system, including a second receiving module 810 and a second sending module 820.

[0140] The second receiving module 810 is used to receive a first request sent by the client to the consistent hash ring. The consistent hash ring is used to store the storage location of the target metadata to be queried or the target verification data corresponding to the target metadata. The first request carries the target metadata.

[0141] The second sending module 820 is used to send target metadata or target verification data to the client in response to the first request, so that the client can obtain the target metadata based on the target metadata or target verification data.

[0142] The blockchain-based metadata management system provided in this application embodiment utilizes the root hash value of the Merkle tree of metadata or verification data stored on the server corresponding to each node to receive a second request sent by the client for integrity auditing of the metadata stored on the server, thereby ensuring metadata security and being suitable for decentralized storage environments.

[0143] It is understood that the detailed functional implementation of each of the above units / modules can be found in the description in the aforementioned method embodiments, and will not be repeated here.

[0144] It should be understood that the above-described device is used to execute the methods in the above embodiments. The implementation principle and technical effect of the corresponding program modules in the device are similar to those described in the above methods. The working process of the device can be referred to the corresponding process in the above methods, and will not be repeated here.

[0145] Based on the methods in the above embodiments, this application provides an electronic device that may include: a processor 910, a communications interface 920, a memory 930, and a communication bus 940, wherein the processor 910, the communications interface 920, and the memory 930 communicate with each other through the communication bus 940. The processor 910 may call logical instructions in the memory 930 to execute the methods in the above embodiments.

[0146] Furthermore, the logical instructions in the aforementioned memory 930 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0147] Based on the methods in the above embodiments, this application provides a computer-readable storage medium storing a computer program that, when run on a processor, causes the processor to execute the methods in the above embodiments.

[0148] Based on the methods in the above embodiments, this application provides a computer program product that, when run on a processor, causes the processor to execute the methods in the above embodiments.

[0149] It is understood that the processor in the embodiments of this application can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor can be a microprocessor or any conventional processor.

[0150] The method steps in this application embodiment can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an ASIC.

[0151] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0152] It is understood that the various numerical designations used in the embodiments of this application are merely for the convenience of description and are not intended to limit the scope of the embodiments of this application.

[0153] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A blockchain-based metadata management method, characterized in that, include: A first request is sent to the consistent hash ring in the blockchain, the consistent hash ring being used to store the target metadata to be queried or the target verification data corresponding to the target metadata, and the first request carries the target metadata. The system receives the target metadata or the target verification data sent by the blockchain. The target metadata is stored in a stable node, and the target verification data is stored in an unstable node. The stable and unstable nodes are divided according to the failure frequency of the servers corresponding to each node of the consistent hash ring. Obtain the target metadata based on the target metadata or the target verification data; The step of receiving the target metadata or the target verification data sent by the blockchain includes: The original set of nodes of the consistent hash ring is divided into a stable set of nodes and an unstable set of nodes. The stable set of nodes and the unstable set of nodes are organized by two consistent hash rings respectively. The stable set of nodes is organized into a metadata hash ring for storing the target metadata, and the unstable set of nodes is organized into a verification hash ring for storing the target verification data.

2. The blockchain-based metadata management method as described in claim 1, characterized in that, The method further includes: A second request is sent to the blockchain, the second request being used to perform an integrity audit on the metadata stored on the servers corresponding to each node; The root hash value of the Merkle tree in the server corresponding to each node sent by the blockchain is received. The leaf nodes of the Merkle tree are used to store the hash value of the metadata or the verification data corresponding to the metadata. Based on the root hash value of the Merkle tree in the server corresponding to each node sent by the blockchain, an integrity audit is performed on the metadata stored in the server corresponding to each node.

3. A blockchain-based metadata management method, characterized in that, include: The system receives a first request sent by a client to a consistent hashing ring, wherein the consistent hashing ring is used to store the storage location of the target metadata to be queried or the target verification data corresponding to the target metadata, and the first request carries the target metadata. In response to the first request, a target stable node for storing the target metadata is determined from the stable nodes included in the storage location, and a target unstable node for storing the target verification data is determined from the unstable nodes included in the storage location. The target metadata in the target stable node and / or the target verification data in the target unstable node are sent to the client so that the client can obtain the target metadata based on the target metadata or the target verification data; The stable nodes and unstable nodes are divided according to the failure frequency of the servers corresponding to each node of the consistent hash ring. The stable nodes are used to store metadata, and the unstable nodes are used to store the verification data corresponding to the metadata.

4. The blockchain-based metadata management method as described in claim 3, characterized in that, The method further includes: Receive a second request sent by the client, the second request being used to perform an integrity audit on the metadata stored on the server corresponding to each node; In response to the second request, the root hash value of the Merkle tree in the server corresponding to each node is sent to the client, so that the client can perform integrity audit on the metadata stored in the server corresponding to each node based on the root hash value of the Merkle tree in the server corresponding to each node sent by the blockchain. The leaf nodes of the Merkle tree are used to store the hash value of the metadata or the verification data corresponding to the metadata.

5. A blockchain-based metadata management system, characterized in that, include: The first sending module is used to send a first request to the consistent hash ring in the blockchain. The consistent hash ring is used to store the target metadata to be queried or the target verification data corresponding to the target metadata. The first request carries the target metadata. The first receiving module is used to receive the target metadata or the target verification data sent by the blockchain; The data acquisition module is used to acquire the target metadata based on the target metadata or the target verification data.

6. A blockchain-based metadata management system, characterized in that, include: The second receiving module is used to receive a first request sent by the client to the consistent hashing ring, wherein the consistent hashing ring is used to store the storage location of the target metadata to be queried or the target verification data corresponding to the target metadata, and the first request carries the target metadata. The second sending module is used to send the target metadata or the target verification data to the client in response to the first request, so that the client can obtain the target metadata based on the target metadata or the target verification data.

7. An electronic device, characterized in that, include: At least one memory for storing computer programs; At least one processor is configured to execute a program stored in the memory, wherein when the program stored in the memory is executed, the processor is configured to perform the method as described in any one of claims 1-2 or 3-4.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is run on the processor, it causes the processor to perform the method as described in any one of claims 1-2 or 3-4.

Images