A file retrieval method and device based on a decentralized storage network protocol, equipment and medium

Abstract

The application discloses a file retrieval method and device based on a decentralized storage network protocol, equipment and medium, and relates to the field of blockchains, comprising: constructing a mapping relationship between a file index and a corresponding file identifier; when file retrieval is performed based on a preset privacy information retrieval protocol supporting a single storage node, a file retrieval vector is obtained by using a single storage node so that the single storage node constructs a target database according to the mapping relationship between the file index and the corresponding file identifier, and determines a target retrieval result based on the target database and the file retrieval vector, and the target retrieval result is sent to a user end; when file retrieval is performed based on a preset privacy information retrieval protocol supporting multiple storage nodes, a file retrieval vector is obtained by using multiple storage nodes so that the multiple storage nodes respectively construct their own corresponding target databases, and determine a target retrieval result based on the target databases and the file retrieval vector, and the target retrieval result is sent to a user end.

Description

Technical Field

[0001] The present application relates to the field of blockchain, and in particular to a file retrieval method, apparatus, device and medium based on a decentralized storage network protocol. Background Art

[0002] The Decentralized Storage Network (DSN) is an innovative storage system that combines peer-to-peer storage networks with blockchain technology. DSNs aggregate idle storage resources from global storage providers (i.e., storage nodes) to create a fault-tolerant decentralized network. In a DSN, clients upload files to storage nodes and retrieve them when needed. In recent years, DSNs have emerged as key infrastructure for Web 3.0, supporting the storage needs of applications such as non-fungible tokens (NFTs) and decentralized artificial intelligence (AI). However, privacy leakage remains a long-standing issue in DSNs, primarily concerning data privacy and user privacy. Currently, research on user privacy in DSNs remains limited. In current DSNs, users retrieve files by sending file identifiers (FIDs) to storage nodes. However, this method exposes user habits and preferences to storage nodes, posing the risk of sensitive information leakage. For example, if DSN is used as the basic storage facility for media transmission systems such as Tik Tok, when users retrieve short video files, their sensitive information such as their video viewing habits and interests may be leaked to the storage node. Summary of the Invention

[0003] In view of this, the purpose of this application is to provide a file retrieval method, apparatus, device, and medium based on a decentralized storage network protocol, which can improve the DSN's ability to protect user privacy and effectively enhance the security and resilience of the decentralized network file retrieval process. The specific solution is as follows:

[0004] In a first aspect, the present application provides a file retrieval method based on a decentralized storage network protocol, comprising:

[0005] Determining a target vector corresponding to a file identifier stored in a vector set; wherein the vector set includes file vectors, each file vector corresponds to a Merkle tree; and the Merkle tree is used to store the file identifier corresponding to the stored target file.

[0006] Using the membership evidence corresponding to the file identifier, and traversing from the next vector of the target vector in the vector set until the vector set is completely traversed, to determine the file index corresponding to the file identifier based on a preset index determination process, and construct a mapping relationship between the file index and the file identifier; the membership evidence is used to represent the path of the file identifier in the corresponding Merkle tree;

[0007] When performing file retrieval based on a preset privacy information retrieval protocol supporting a single storage node, a single storage node is used to obtain a file retrieval vector sent by a user terminal, so that the single storage node constructs a target database based on a mapping relationship between a file index and a corresponding file identifier, determines a target retrieval file corresponding to the file retrieval vector from the target database, determines a target retrieval result based on the target retrieval file, and sends the target retrieval result to the user terminal; the file retrieval vector is a vector determined based on the file index;

[0008] When performing file retrieval based on a preset privacy information retrieval protocol that supports multiple storage nodes, multiple storage nodes are used to obtain the file retrieval vector sent by the user terminal, so that the multiple storage nodes respectively construct their own corresponding target databases based on the mapping relationship between the file index and the corresponding file identifier, and determine the target retrieval file corresponding to the file retrieval vector from the target database, determine the target retrieval result based on the target retrieval file, and send the target retrieval result to the user terminal.

[0009] Optionally, the utilizing the member evidence corresponding to the file identifier and traversing from a vector next to the target vector in the vector set until the vector set is completely traversed to determine the file index corresponding to the file identifier based on a preset index determination process includes:

[0010] Initialize the target counter to 1, and start traversing from the next vector of the target vector in the vector set;

[0011] If the currently traversed vector is not empty, determining the vector sequence number corresponding to the currently traversed vector, and increasing the current target counter based on the vector sequence number until the vector set is completely traversed;

[0012] Determine the member evidence corresponding to the file identifier, traverse the position information corresponding to each target element in the member evidence, and if the current position information is represented as left, increase the current target counter based on the element serial number corresponding to the current position information until all target elements in the member evidence are traversed, and use the value corresponding to the current target counter as the file index corresponding to the file identifier.

[0013] Optionally, after constructing the mapping relationship between the file index and the file identifier, the method further includes:

[0014] Using a storage node storing the target file corresponding to the file identifier to construct a file upload proof based on the vector set corresponding to the file identifier, the target vector, the member evidence, the file identifier, the file index, and a state hash value, and using the storage node to submit the file upload proof to a blockchain so that the blockchain determines whether the file upload proof has passed verification; the state hash value is a previous state hash value generated by the storage node when the storage node last stored or deleted a file;

[0015] Accordingly, determining whether the file upload certificate has passed verification using the blockchain includes:

[0016] Determining, using the blockchain based on the vector set in the file upload proof, the target vector, the membership evidence, and the file identifier, whether the file identifier exists in the Merkle tree corresponding to the target vector and whether the mapping relationship between the file index and the file identifier is correct, to obtain a first verification result;

[0017] Using the blockchain based on the vector set, the target vector, and the member evidence, and according to the preset index determination process, obtaining a first target file index to determine whether the first target file index matches the file index, thereby obtaining a second verification result;

[0018] Comparing a current preset cryptographic accumulator state with a previous preset cryptographic accumulator state using the blockchain based on the vector set, the membership evidence, and the state hash value to verify whether a state can be transferred from the previous preset cryptographic accumulator state to the current preset cryptographic accumulator state, thereby obtaining a third verification result; the preset cryptographic accumulator includes a vector set and a file identifier, and is used to establish a mapping relationship between a file index and a corresponding file identifier;

[0019] If the first verification result, the second verification result, and the third verification result are all characterized as passed, the file upload certificate passes the verification, and the file upload certificate is saved in the blockchain.

[0020] Optionally, the file retrieval method based on the decentralized storage network protocol further includes:

[0021] In the file deletion phase, the file identifier corresponding to the target deleted file is deleted from the preset cryptographic accumulator, a corresponding file deletion certificate is generated for the file identifier corresponding to the target deleted file, and the file deletion certificate is uploaded to the blockchain so that the blockchain verifies whether the file deletion certificate passes verification;

[0022] If the file deletion certificate passes the verification, the file deletion certificate is saved in the blockchain.

[0023] Optionally, the process of file storage and file deletion performed by the storage node when using the preset privacy information retrieval protocol supporting a single storage node is consistent with the process of file storage and file deletion performed by the storage node when using the preset privacy information retrieval protocol supporting multiple storage nodes.

[0024] Optionally, the file retrieval method based on the decentralized storage network protocol further includes:

[0025] Obtaining a target file upload certificate corresponding to the file to be retrieved from the blockchain, and determining a file index of a file identifier corresponding to the file to be retrieved in a corresponding target storage node from the target file upload certificate;

[0026] Determine the database size corresponding to the target storage node based on the maximum file index of the file identifier stored in the target storage node;

[0027] generating a file retrieval vector according to a file index of a file identifier corresponding to the to-be-retrieved file in the target storage node and a database size corresponding to the target storage node, so that the user terminal sends the file retrieval vector to the target storage node;

[0028] Correspondingly, after the target storage node receives the file retrieval vector, the process further includes:

[0029] Construct a target database, save a second target file index corresponding to the file identifier stored in the target database, and save the file corresponding to the second target file index in the target database; wherein, if the file corresponding to the second target file index is deleted, save a blank file in the target database.

[0030] Optionally, when performing file retrieval based on a preset privacy information retrieval protocol that supports multiple storage nodes, the following is also included:

[0031] Based on the Byzantine fault-tolerant state machine replication protocol, the honest nodes in the storage nodes are controlled to maintain a consistent database state;

[0032] File retrieval is performed using the Byzantine robust privacy information retrieval protocol and based on the preset privacy information retrieval protocol that supports multiple storage nodes.

[0033] In a second aspect, the present application provides a file retrieval device based on a decentralized storage network protocol, comprising:

[0034] a vector determination module, configured to determine a target vector corresponding to a file identifier stored in a vector set; wherein the vector set includes file vectors, each file vector corresponding to a Merkle tree; and wherein the Merkle tree is configured to store the file identifier corresponding to the stored target file.

[0035] an index determination module, configured to utilize a membership evidence corresponding to the file identifier and traverse from a vector next to the target vector in the vector set until the vector set is completely traversed, so as to determine a file index corresponding to the file identifier based on a preset index determination process, and to establish a mapping relationship between the file index and the file identifier; the membership evidence being used to represent a path of the file identifier in the corresponding Merkle tree;

[0036] A first result sending module is configured to, when performing a file search based on a preset privacy information retrieval protocol supporting a single storage node, obtain a file search vector sent by a user terminal using a single storage node, so that the single storage node constructs a target database based on a mapping relationship between a file index and a corresponding file identifier, determines a target search file corresponding to the file search vector from the target database, determines a target search result based on the target search file, and sends the target search result to the user terminal; the file search vector is a vector determined based on the file index;

[0037] The second result sending module is used to use multiple storage nodes to obtain the file retrieval vector sent by the user terminal when performing file retrieval based on a preset privacy information retrieval protocol that supports multiple storage nodes, so that the multiple storage nodes can respectively construct their own corresponding target databases based on the mapping relationship between the file index and the corresponding file identifier, and determine the target retrieval file corresponding to the file retrieval vector from the target database, determine the target retrieval result based on the target retrieval file, and send the target retrieval result to the user terminal.

[0038] In a third aspect, the present application provides an electronic device, comprising:

[0039] Memory, used to store computer programs;

[0040] A processor is used to execute the computer program to implement the aforementioned file retrieval method based on the decentralized storage network protocol.

[0041] In a fourth aspect, the present application provides a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the aforementioned file retrieval method based on a decentralized storage network protocol.

[0042] In the present application, a target vector corresponding to a file identifier stored in a vector set is determined; wherein the vector set includes file vectors, each file vector corresponds to a Merkle tree; the Merkle tree is used to store the file identifier corresponding to the stored target file; the member evidence corresponding to the file identifier is used, and traversal is started from the next vector of the target vector in the vector set until the vector set is completely traversed, so as to determine the file index corresponding to the file identifier based on a preset index determination process, and construct a mapping relationship between the file index and the file identifier; the member evidence is used to represent the path of the file identifier in the corresponding Merkle tree; when performing file retrieval based on a preset privacy information retrieval protocol that supports a single storage node, a single storage node is used to obtain the file retrieval vector sent by the user end, so that the A single storage node constructs a target database based on the mapping relationship between the file index and the corresponding file identifier, and determines the target retrieval file corresponding to the file retrieval vector from the target database, determines the target retrieval result based on the target retrieval file, and sends the target retrieval result to the user end; the file retrieval vector is a vector determined based on the file index; when performing file retrieval based on a preset privacy information retrieval protocol that supports multiple storage nodes, multiple storage nodes are used to obtain the file retrieval vector sent by the user end, so that the multiple storage nodes respectively construct their own corresponding target databases based on the mapping relationship between the file index and the corresponding file identifier, and determine the target retrieval file corresponding to the file retrieval vector from the target database, determine the target retrieval result based on the target retrieval file, and send the target retrieval result to the user end. As can be seen from the above, in this application, the user end does not directly send the FID, but generates a file retrieval vector through the file index, and sends the file retrieval vector to the storage node, so that the storage node cannot infer the file content or category corresponding to the FID from the file index, thereby protecting user privacy and effectively improving the security of the decentralized network file retrieval process. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without any creative work.

[0044] Figure 1 This is a flow chart of a file retrieval method based on a decentralized storage network protocol disclosed in this application;

[0045] Figure 2 This is a schematic diagram of a specific preset privacy information retrieval protocol architecture supporting a single storage node disclosed in this application;

[0046] Figure 3 A schematic diagram of a specific system implementation framework disclosed in this application;

[0047] Figure 4 This is a schematic diagram of a specific file upload time overhead test result disclosed in this application;

[0048] Figure 5 This is a schematic diagram of a specific file deletion time overhead test result disclosed in this application;

[0049] Figure 6 This is a schematic diagram of a specific proof verification time overhead test result disclosed in this application;

[0050] Figure 7 This is a schematic diagram of a specific file retrieval time overhead test result disclosed in this application;

[0051] Figure 8 (a) is a schematic diagram of a specific file upload throughput test result disclosed in this application;

[0052] Figure 8 (b) is a schematic diagram of a specific file upload delay test result disclosed in this application;

[0053] Figure 9 (a) is a schematic diagram of a throughput test result of a specific file deletion disclosed in this application;

[0054] Figure 9 (b) is a schematic diagram of a specific file deletion delay test result disclosed in this application;

[0055] Figure 10 (a) is a schematic diagram of a throughput test result of a specific file retrieval disclosed in this application;

[0056] Figure 10 (b) is a schematic diagram of a specific delay test result of file retrieval disclosed in this application;

[0057] Figure 11 This is a schematic diagram of the structure of a file retrieval device based on a decentralized storage network protocol disclosed in this application;

[0058] Figure 12 This is a schematic diagram of the structure of an electronic device disclosed in this application. DETAILED DESCRIPTION

[0059] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0060] Currently, research on user privacy in DSNs remains limited. In current DSNs, users retrieve files by sending file identifiers to storage nodes. However, this method exposes user habits and preferences to storage nodes, posing the risk of sensitive information leakage. Therefore, this application provides a file retrieval method based on a decentralized storage network protocol, which can improve DSN's ability to protect user privacy and effectively enhance the security and resilience of the decentralized network file retrieval process.

[0061] See also Figure 1 As shown, the embodiment of the present application discloses a file retrieval method based on a decentralized storage network protocol, including:

[0062] Step S11: Determine a target vector corresponding to a file identifier stored in a vector set; wherein the vector set includes file vectors, each file vector corresponds to a Merkle tree; and the Merkle tree is used to store the file identifier corresponding to the stored target file.

[0063] In this embodiment, the storage node can store (i.e., upload) or delete the file data sent by the user, or perform file retrieval based on the file retrieval vector sent by the user. The storage node can perform file retrieval based on a preset privacy information retrieval protocol that supports a single storage node, or it can perform file retrieval based on a preset privacy information retrieval protocol that supports multiple storage nodes. The above-mentioned preset privacy information retrieval protocol that supports a single storage node is applicable to any scenario where files are retrieved from a single storage node, and the above-mentioned preset privacy information retrieval protocol that supports multiple storage nodes is applicable to scenarios where the client stores redundant file copies in multiple storage nodes to enhance storage elasticity. In this scenario, the preset privacy information retrieval protocol that supports multiple storage nodes has higher retrieval efficiency than the preset privacy information retrieval protocol that supports a single storage node. These two protocols together cover most DSN file retrieval needs.

[0064] It should be noted that the process of file storage and file deletion by the storage node when using the preset privacy information retrieval protocol that supports a single storage node is consistent with the process of file storage and file deletion by the storage node when using the preset privacy information retrieval protocol that supports multiple storage nodes.

[0065] When a storage node stores files, it can map the file identifier to a compact index range to build a mapping relationship between the file index and the file identifier. First, it is necessary to determine the target vector corresponding to the file identifier of the file to be stored in the vector set, that is, , indicating that the FID is inserted into In the Merkle tree with root , the vector set can be expressed as .

[0066] Step S12: Utilize the membership evidence corresponding to the file identifier and traverse from the next vector of the target vector in the vector set until the vector set is completely traversed, so as to determine the file index corresponding to the file identifier based on a preset index determination process, and construct a mapping relationship between the file index and the file identifier; the membership evidence is used to represent the path of the file identifier in the corresponding Merkle tree.

[0067] In this embodiment, the target counter can be initialized to 1 first, and traversal can be started from the next vector of the target vector in the vector set; if the currently traversed vector is not empty, the vector sequence number corresponding to the currently traversed vector is determined, and the current target counter is increased based on the vector sequence number until the vector set is traversed; then the member evidence corresponding to the file identifier is determined, and the position information corresponding to each target element in the member evidence is traversed. If the current position information is represented as left, the current target counter is increased based on the element sequence number corresponding to the current position information until each target element in the member evidence is traversed, and the value corresponding to the current target counter is used as the file index corresponding to the file identifier; finally, a mapping relationship between the file index and the corresponding file identifier is constructed.

[0068] After constructing the mapping relationship between the file index and the file identifier, the method may also include: using the storage node storing the target file corresponding to the file identifier to construct a file upload certificate based on the vector set corresponding to the file identifier, the target vector, the member evidence, the file identifier, the file index and the state hash value, and using the storage node to submit the file upload certificate to the blockchain so that the blockchain determines whether the file upload certificate passes the verification; wherein the state hash value is the previous state hash value generated by the storage node when the file was last stored or deleted.

[0069] Accordingly, using the blockchain to determine whether the file upload proof has passed verification may include: first, using the blockchain to determine whether the file identifier exists in the Merkle tree corresponding to the target vector and whether the mapping relationship between the file index and the file identifier is correct based on the vector set, target vector, member evidence and file identifier in the file upload proof, to obtain a first verification result; then, using the blockchain to obtain a first target file index based on the vector set, target vector and member evidence, and according to a preset index determination process, to determine whether the first target file index matches the file index, to obtain a second verification result; finally, using the blockchain to compare the current preset cryptographic accumulator state with the previous preset cryptographic accumulator state based on the vector set, member evidence and state hash value, so as to verify whether the state can be transferred from the previous preset cryptographic accumulator state to the current preset cryptographic accumulator state, to obtain a third verification result; wherein the preset cryptographic accumulator includes a vector set and a file identifier, which is used to construct a mapping relationship between the file index and the corresponding file identifier; if the first verification result, the second verification result and the third verification result are all characterized as passed, then the file upload proof passes verification, and the file upload proof is saved to the blockchain.

[0070] Understandably, the blockchain will only accept a file upload proof if all three of the aforementioned verification results are passed. Verifying the file upload proof ensures that each FID corresponds to a unique and correct index, providing a reliable mapping foundation for subsequent private retrieval. For example, if a storage node maliciously inserts FID2 into an index position already occupied by FID1, verification will fail due to an index conflict, preventing FID2 from being inserted into the index position already occupied by FID1 and preventing data corruption. Furthermore, the file upload proof verification process is open to all storage nodes. Any participant can query and verify the legitimacy of the file upload operation through the blockchain, establishing decentralized trust and avoiding the "single point of trust" risks found in traditional centralized systems. This ensures that storage nodes cannot forge or tamper with the mapping relationship. Furthermore, if the FID index is incorrect, the search vector generated by the user will point to the wrong location, resulting in retrieval failure or privacy exposure. This verification mechanism ensures that the index is strictly bound to the FID. For example, the search vector generated by the user accurately hits the target file, preventing storage nodes from misleading users through incorrect indexes.

[0071] When a storage node deletes a file, it can delete the file identifier corresponding to the target deleted file from the preset cryptographic accumulator, and then generate a corresponding file deletion certificate for the file identifier corresponding to the target deleted file, and upload the file deletion certificate to the blockchain so that the blockchain can verify whether the file deletion certificate is verified; if the file deletion certificate is verified, the file deletion certificate is saved to the blockchain.

[0072] By verifying the file deletion proof, on the one hand, only legitimate deletion requests initiated by users or authorized parties will be accepted, preventing storage nodes from privately deleting valid files; on the other hand, after the verification is passed, the preset cryptographic accumulator removes the deleted FID, freeing up the index space it occupies, and allowing subsequent FIDs to reuse the space, ensuring that the preset cryptographic accumulator always reflects the true file storage status and avoiding space waste or index confusion caused by "zombie indexes".

[0073] The following describes the process of file storage and file deletion using the preset privacy information retrieval protocol that supports a single storage node as an example.

[0074] In the file storage stage, the mapping relationship between the file index and the corresponding file identifier can be established through the preset asynchronous cryptographic accumulator (ACA). ACA includes a vector set and n FIDs (structured as a Merkle forest); where each element It can be the root of a Merkle tree or a placeholder. .if , then its Each leaf node stores either FID or placeholder ;if , it means that all Each leaf node stores . Through ACA, n FIDs can be mapped to In addition, ACA can be used to provide membership witnesses to generate proofs to confirm the validity of the mapping relationship between FID and the corresponding index, and record it on a bulletin board, such as a blockchain, to enable public verification of the correctness of the mapping relationship.

[0075] See also Figure 2 As shown, the initial state of the ACA vector set is ,in When inserting a FID, the following two situations may occur: 1. All leaf nodes in the ACA are occupied by FIDs. In this case, the ACA needs to be expanded to accommodate the additional FIDs; 2. At least one leaf node stores , indicating that there is a vacancy, in which case the new FID will be inserted into the first available vacancy. To do this, the ACA vector set can be traversed ,from arrive Find ,Should Elements Satisfaction or and The leaf nodes of the associated Merkle tree contain Specifically, if no matching conditions are found , it means that the ACA is full, and a new Merkle tree can be created. To provide additional index space. The new FID will be arrive Merkle tree leaf nodes are merged to form a The complete Merkle tree of leaf nodes. The root of the tree is stored in In the tree, the new FID is inserted into the rightmost leaf node. arrive The value of and all merged leaf nodes are set to .if If it exists, there are two possible situations: 1. , at this time FID is inserted into The leftmost leaf node of the associated Merkle tree; 2. At this point, you can use Depth First Search (DFS) to traverse the leaf nodes of the associated Merkle tree and insert the FID into the first storage The leaf node of .

[0076] After the FID is correctly inserted, the ACA is updated and the index allocation process is performed. Assume that the FID is inserted into In a Merkle tree with FID as its root, the index corresponding to FID can be determined by the following three parameters: 、 and FID member evidence Member Evidence The Merkle path represents the FID, where each element consists of a hash value and position information (left or right). The index calculation method is as follows: First, initialize the counter index = 1; second, traverse the ACA vector set Zhongcong arrive If the element , then the index increases ; Finally, traverse the member evidence Every element of , if a If the position information is left, the index increases .

[0077] After the mapping is established, the storage node that inserts the FID can submit a proof to the blockchain to verify the correctness of the mapping. The proof can be expressed as: Where h represents the hash value of the previous state proof generated by the storage node during the last file storage or file deletion operation. The following three steps are required: First, use and FID to ensure that the FID exists in the ACA. Specifically, it is necessary to verify Is it The kth element in , and whether it can be obtained by and FID are calculated. Secondly, use Confirm the correctness of the index assignment by rerunning the index calculation process and ensuring that the calculation result matches the index. , Compare the current ACA status with h Compared to the pre-ACA status (Use h to obtain from the blockchain). By treating ACA as a state machine, it is possible to efficiently verify whether the state can be obtained from Transfer to , ensuring that newly inserted FIDs do not cause index conflicts.

[0078] During the file deletion phase, see Figure 2 As shown, the FID is deleted from the ACA, the ACA is updated and a certificate is generated for each deleted FID, and the certificate is recorded on the blockchain. This method ensures that the storage nodes in the DSN can publicly verify the integrity of the mapping deletion. Specifically, to delete a FID, first locate the leaf node containing the FID and the Merkle tree to which it belongs. , the file deletion process depends on Whether other FIDs are included can be divided into the following two situations: 1. Still contains other FIDs. At this time, the membership evidence of FID can be generated , and update the value stored in the leaf node where FID is located to . Then, recalculate the root of the Merkle tree and store the updated root value in ; 2. Does not include other FIDs. Membership evidence of FID is also generated at this time (at this time ) and updates the value stored in the leaf node where FID is located to At this time, due to All leaf nodes are , The value of is also set to .

[0079] After the mapping is deleted, the storage node that deleted the FID can submit a certificate to the blockchain to verify the correctness of the mapping deletion process. The certificate can be expressed as: .verify There are two steps to complete: First, use and h to confirm that the FID existed in the previous state of ACA before deletion, and that the mapping of other FIDs was not affected by the deletion operation. Specifically, the previous ACA state corresponding to h can be retrieved from the blockchain ,verify Can it be passed and FID are calculated to verify the existence of the FID in the previous ACA state and ensure Other FID mappings in remain unchanged. Also check and Are all elements except the kth element in the same Merkle tree completely consistent to confirm that the FID mapping in other Merkle trees has not been modified? and FID to verify that the mapping deletion operation is performed correctly. Specifically, you can check Is it equal to .if , it means that before deleting Still contains other FIDs, now verify Is it The kth element in , and whether it can be passed and Recalculate. If , then it means Before deleting, only the FID is included. In this case, further inspection can be done. To ensure the correctness of the deletion operation.

[0080] Step S13: When performing file retrieval based on a preset privacy information retrieval protocol that supports a single storage node, a single storage node is used to obtain a file retrieval vector sent by the user terminal, so that the single storage node constructs a target database based on a mapping relationship between a file index and a corresponding file identifier, and determines a target retrieval file corresponding to the file retrieval vector from the target database, determines a target retrieval result based on the target retrieval file, and sends the target retrieval result to the user terminal; the file retrieval vector is a vector determined based on the file index.

[0081] In this embodiment, a pre-configured privacy information retrieval protocol supporting a single storage node allows a user to retrieve files from a single storage node using a single-server private information retrieval protocol. Compared to existing file retrieval techniques in DSNs, this embodiment enhances user privacy during the retrieval process. Specifically, this embodiment determines the database size corresponding to the target storage node based on the maximum file index of the file identifier stored by the target storage node. It then generates a file retrieval vector based on the file index of the file identifier corresponding to the file to be retrieved in the target storage node and the database size corresponding to the target storage node, allowing the user to send the file retrieval vector to the target storage node.

[0082] It should be noted that when searching for a file, a user needs to generate a file retrieval vector and send it to the storage node. Generating a file retrieval vector for a specific FID requires two key parameters: 1. The FID's index on the storage node, which determines the location of the file to be retrieved; and 2. The size of the database held by the storage node, which determines the dimensionality (i.e., size) of the file retrieval vector. Both parameters can be obtained from the blockchain. The index corresponding to the FID is stored in the proof submitted by the storage node when inserting the FID. The database size is determined by the maximum index value when the storage node stores the FID, which is also obtained from the proof submitted by the storage node. After obtaining these parameters, the user client can construct a file retrieval vector using the single-server private information retrieval query algorithm, send it to the storage node, and wait for the storage node's response. If the user client retrieves the FID deletion proof submitted by the storage node on the blockchain, it will search for other storage nodes that store the file.

[0083] For example Figure 2 As shown, the user end obtains the index of FID1 and the size of the retrieval vector through on-chain proof to determine the retrieval vector q, and sends the retrieval vector q to the storage node. The storage node calculates the retrieval result ans through single-server privacy information retrieval technology and returns the retrieval result ans to the user end. The user end uses the retrieval result ans to reconstruct the required target file.

[0084] Correspondingly, after the target storage node receives the file retrieval vector, it can also include: constructing a target database, saving the second target file index corresponding to the file identifier stored in itself into the target database, and saving the file corresponding to the second target file index into the target database; wherein, if the file corresponding to the second target file index is deleted, a blank file is saved into the target database.

[0085] It should be noted that the storage node places the corresponding file in the corresponding entry of the target database according to the FID index. Due to the existence of file deletion operations, some entries in the target database may be empty. For these empty entries, the storage node can fill them with blank files. After building the target database, the storage node can use the Answer algorithm of single-server private information retrieval to determine the target retrieval file based on the target database and file retrieval vector, determine the target retrieval result based on the target retrieval file, and send the target retrieval result to the user end. After receiving the target retrieval result, the user end can use the Decrypt algorithm of single-server private information retrieval to obtain the corresponding file and use the FID to verify the file integrity, and check whether the storage node provides an incorrect query result.

[0086] Step S14: When performing file retrieval based on a preset privacy information retrieval protocol that supports multiple storage nodes, multiple storage nodes are used to obtain the file retrieval vector sent by the user terminal, so that the multiple storage nodes respectively construct their own corresponding target databases based on the mapping relationship between the file index and the corresponding file identifier, and determine the target retrieval file corresponding to the file retrieval vector from the target database, determine the target retrieval result based on the target retrieval file, and send the target retrieval result to the user terminal.

[0087] In this embodiment, the preset privacy information retrieval protocol supporting multiple storage nodes allows the user terminal to retrieve files from multiple storage nodes through the Multi-Server Private Information Retrieval (MPIR-DSN; MPIR, i.e., Multi-Server Private Information Retrieval) protocol.

[0088] In a DSN, files are typically stored redundantly across multiple storage nodes to enhance security, availability, and fault tolerance. While users can retrieve files from a single storage node using the SPIR-DSN protocol (i.e., the single-server private information retrieval protocol), the multi-storage node private file retrieval protocol further extends this functionality, enabling users to simultaneously retrieve files from any subset of the set of storage nodes storing the file. Unlike single-server private information retrieval, which primarily relies on computationally intensive homomorphic multiplication, multi-server private information retrieval utilizes more efficient computations, such as bitwise XOR operations and simple multiplications, resulting in better retrieval efficiency.

[0089] It should be noted that the multi-server private information retrieval protocol operates in the following environment: Assume there is a subnet consisting of N storage nodes, used to process multi-server private file retrieval. At most N / 3 of these storage nodes may be malicious. All storage nodes in the subnet simultaneously process user file storage, deletion, and retrieval requests.

[0090] The primary challenge addressed in the multi-server private information retrieval protocol is how to ensure that all honest nodes maintain a consistent database state after any file is stored or deleted. This consistent database state is a prerequisite for correctly retrieving files using the multi-server private information retrieval protocol. This can be achieved by controlling the honest nodes in the storage nodes to maintain a consistent database state based on a Byzantine fault-tolerant state machine replication protocol. File retrieval can then be performed using the Byzantine robust private information retrieval protocol based on the multi-server private information retrieval protocol.

[0091] For example, the consistency of the storage node database within a subnet can be achieved based on the BFT-SMR protocol (Byzantine Fault-Tolerant State Machine Replication). BFT-SMR ensures that even in the presence of Byzantine nodes (i.e., malicious nodes), all honest nodes can reach consensus on the order in which user requests are processed. For multi-server private information retrieval protocols, the Hotstuff protocol can be used. Hotstuff is widely used for efficient consensus in partially synchronous environments. Furthermore, multi-server private information retrieval protocols are not limited to Hotstuff; other BFT-SMR protocols, such as Tendermint or PBFT (Practical Byzantine Fault Tolerance), can also be used to achieve the aforementioned database state replication based on actual needs.

[0092] Specifically, file storage or deletion requests are broadcast to all storage nodes within the subnet. Each storage node processes these requests locally and reaches consensus according to the following steps to ensure the consistency of the order of user requests: First, storage nodes within the subnet take turns acting as the master node. The master node sorts the received user requests, updates its local ACA, and generates corresponding proofs. These proofs are packaged into a block and broadcast to other storage nodes in the subnet. After receiving the block from the master node, other storage nodes verify each proof in the block and confirm receipt of the corresponding user request. If verification passes, the storage node broadcasts a PREPARE message. Finally, when any storage node receives at least 2 / 3N PREPARE messages from other nodes, it broadcasts a COMMIT message. When any node receives at least 2 / 3N COMMIT messages, it finalizes the block and processes user requests in order. If no storage node begins processing a user request within a predetermined time, the BFT-SMR view change protocol is triggered to elect a new master node to ensure the liveness of the consensus process.

[0093] In the file retrieval phase, a Byzantine-Robust Private Information Retrieval (BR-PIR) protocol can be integrated. BR-PIR is a protocol specifically designed for multi-server private information retrieval. The protocol has three important parameters: ;in Represents the number of storage nodes participating in the retrieval, The maximum number of colluding storage nodes allowed by the protocol to ensure that the user's privacy is not leaked, The maximum number of storage nodes that the protocol can identify that provide error responses or no responses. In this embodiment, the BR-PIR protocol needs to meet , which allows users to send queries to all N storage nodes and retrieve the correct files privately while detecting storage nodes that do not respond or return incorrect results, provided that the subnet can reach consensus through the database state replication method. To this end, the BR-PIR scheme proposed by Goldberg can be selected. Can tolerate up to The Byzantine fault tolerance capability of the malicious storage node exceeds N / 3 required by this embodiment.

[0094] Specifically, the user first obtains the file index and database size from the proof stored on the blockchain. They then invoke the Query algorithm of the selected BR-PIR scheme to generate N file retrieval vectors and distribute them to N storage nodes. Each storage node that receives the file retrieval vectors constructs a target database and uses the BR-PIR scheme's Answer algorithm to calculate the target retrieval results, returning them to the user. After receiving all retrieval results or after a preset timeout, the user invokes the BR-PIR scheme's Reconstruct algorithm to reconstruct the target file and identify storage nodes that returned incorrect retrieval results or failed to respond, thereby detecting and penalizing malicious storage nodes.

[0095] As can be seen from the above, in this embodiment, the storage node generates proofs when processing a file upload request or a file deletion request. These proofs ensure that when the storage node processes a file upload request, the newly generated mapping for the uploaded file's FID does not conflict with the existing mapping. When the storage node performs a file deletion operation, the protocol-specified mechanism ensures that the mapping relationship between the FID and the index is correctly removed or updated, and this process can be verified by other nodes, thereby enhancing public verifiability. On the other hand, in this embodiment, based on the preset privacy information retrieval protocol supporting a single storage node and the preset privacy information retrieval protocol supporting multiple storage nodes, the user end does not directly send the FID. Instead, it generates a file retrieval vector based on the file index and sends the file retrieval vector to the storage node. Even if the storage node can obtain all the query information sent by the user end during the file retrieval process, it cannot reversely infer the file content or category corresponding to the FID, thus protecting user privacy. At the same time, the storage node uses any polynomial time algorithm for inference, and the probability of successfully inferring the FID of the file the user wants to query is no better than random guessing, thereby improving the privacy of file retrieval. At the same time, when using a single-server privacy information retrieval protocol to retrieve files from a single storage node, it ensures that the user end either successfully retrieves the correct file or can detect that the storage node provides an incorrect answer or fails to respond; when using a multi-server privacy information retrieval protocol to retrieve files from multiple storage nodes, it ensures that the user end can not only successfully retrieve the correct file, but also identify which storage nodes returned incorrect results or failed to respond, thereby improving the auditability of the retrieval.

[0096] See also Figure 3 As shown below, Filecoin is taken as an example to illustrate the technical solution in this application.

[0097] This embodiment implements the file retrieval based on the decentralized storage network protocol proposed in this application on Filecoin, where Filecoin is currently the most widely used DSN implementation. Filecoin is developed using Golang. The architecture of the protocol is as follows: Figure 3 As shown in the figure, the file upload and deletion module, node authentication module, message pool, and gateway are components inherited from Filecoin, the file retrieval module, file storage module, and consensus module are components modified based on Filecoin, and the privacy file retrieval module is a newly developed component.

[0098] On the user side (i.e., user node), the file retrieval module was modified to enable users to obtain the index of the target file from the blockchain and call the newly introduced private file retrieval module, which is responsible for generating file retrieval vectors and reconstructing files based on the target retrieval results. The single-server PIR and BR-PIR solutions use SealPIR provided by Microsoft and percy++ developed by Goldberg, respectively. On the storage node side, the file storage module was modified to implement the mapping construction and mapping deletion methods proposed in this application. In addition, the file retrieval module was adapted to enable it to process user-generated file retrieval vectors and call the newly introduced private file retrieval module, which implements the Answer algorithm of the PIR protocol. On the public service side, the consensus module was modified to integrate a database state replication method based on HotStuff; the Hotstuff algorithm was provided by Resilient Systems Lab.

[0099] As can be seen from the above, this embodiment improves DSN's ability to protect user privacy by modifying Filecoin's original file retrieval module, file storage module, and consensus module, and adding a privacy file retrieval module, effectively improving the security and resilience of the decentralized network file retrieval process.

[0100] The technical solution in this application is described below with a specific experimental process.

[0101] Experimental environment:

[0102] The experiment was divided into two parts. In the first part, the time overhead of file upload, file deletion, proof verification, and retrieval was measured. Because this part of the experiment is less sensitive to bandwidth, it can be tested in a local environment. Specifically, the systems built based on the methods described in this application (i.e., Ours_SPIR and Ours_MPIR), Filecoin, Sia, and Storj were deployed on a Dell PowerEdge R740 server (running Ubuntu 22.04 LTS). The server was equipped with two 12-core CPUs (Central Processing Units), 16GB of memory, and a 300GB SSD (Solid State Disk), running Ubuntu 22.04 LTS. Each DSN consisted of four storage nodes and one user node. When testing the MPIR-DSN, the four storage nodes were treated as a subnet. The experimental dataset consisted of 300 randomly generated text files, each 7.5MB in size, created using the Linux dd command. To ensure a fair comparison, all four DSN systems stored only a single copy of each file and generated proofs for all the file data.

[0103] In the second part of the experiment, the throughput and latency of file upload, deletion, and retrieval were evaluated. These metrics are significantly affected by bandwidth. Therefore, the system built based on the methods described in this application, along with Filecoin, Sia, and Storj, can be deployed in a wide area network environment. Specifically, 125 SA5.MEDIUM8 instances were deployed, each equipped with a dual-core CPU, 8GB of memory, and a 50GB SSD, running the Ubuntu 22.04 LTS operating system. Of these 125 instances, 100 served as storage nodes, and the remaining 25 served as user nodes. When testing the MPIR-DSN, the 100 storage nodes were divided into 25 subnets, each containing four storage nodes. The experimental dataset was the same as in the first part. The client request rate was controlled to vary between 1 and 5 requests per second, with each request sent to either four storage nodes or one MPIR-DSN subnet. Furthermore, in the file retrieval experiments, all storage nodes in the DSN system were ensured to store 50 files.

[0104] Time overhead of file operation process:

[0105] In terms of file upload, such as Figure 4As shown, the upload times for SPIR-DSN and MPIR-DSN are essentially the same as those for Filecoin, demonstrating that the systems built based on this application introduce minimal overhead. Specifically, mapping establishment adds only 0.04 to 0.21 milliseconds, while database state replication in MPIR-DSN consumes only an additional 0.03 seconds. These additional costs are negligible compared to the 33 seconds required to generate a storage proof in Filecoin. Both Sia and Storj systems have lower file upload time overhead, but are less secure than the systems built based on this application.

[0106] In terms of file deletion, such as Figure 5 As shown, SPIR-DSN's deletion time is slightly longer than Filecoin, mainly because the mapping deletion introduces an additional overhead of 0.11 to 1.56 milliseconds. MPIR-DSN's deletion time is about 0.03 seconds longer than SPIR-DSN and Filecoin, which is due to the additional overhead of database state replication. Overall, the system built based on this application only introduces very little additional overhead in the file deletion process. Storj's deletion overhead is slightly higher than the system built based on this application, while Sia's deletion process does not involve actually deleting files on the storage node. It only deletes the file identifier on the user side, making the file unretrievable. Therefore, its deletion process time overhead is very small.

[0107] In terms of proof verification, Figure 6 As shown, the system built based on this application has the shortest verification time during the file deletion process, indicating that the overhead of mapping deletion verification is extremely low. The system built based on this application takes slightly longer to verify proofs during the file upload phase than Filecoin because it needs to verify both the storage proof and the mapping establishment proof. This also shows that the additional overhead of mapping establishment verification is extremely small and has a limited impact on overall verification time. Sia and Storj need to split files into multiple 256KB sectors, so verifying the complete file storage requires multiple proofs, resulting in higher proof verification time overhead.

[0108] In terms of file retrieval, such as Figure 7As shown, the retrieval time of the system built based on the present application increases linearly with the number of stored files. This is because the storage node needs to process the entire database when executing the Answer algorithm of the PIR protocol, resulting in a proportional increase in the amount of computation with the number of stored files. The retrieval time of SPIR-DSN is higher than that of MPIR-DSN because SealPIR relies on computationally intensive homomorphic multiplication, which results in a large computational overhead. The retrieval time of the system built based on the present application is higher than that of Filecoin because Filecoin's storage nodes directly return files without the need for additional calculations. In addition, Sia's retrieval method is similar to Filecoin, and its file retrieval time is basically the same as Filecoin. However, Storj uses AES-GCM encryption and sets the encrypted and decrypted file block size to 1KB, which results in a slower decryption process during file retrieval and adds additional overhead.

[0109] Throughput and latency of file operations:

[0110] In terms of file upload, such as Figure 8 (a) and Figure 8 As shown in (b), the upload throughput of the system built based on this application is approximately 1.19 times higher than that of Filecoin, while the latency remains similar, indicating that the additional overhead of the mapping process is minimal. Because both Filecoin and the system built based on this application involve a computationally intensive packaging process, the throughput of the two tends to converge when the storage node processes 5 files simultaneously. Sia's throughput increases linearly and its latency is stable, indicating its good scalability. Storj relies on satellite nodes to distribute and audit sectors, and its throughput remains unchanged while its latency increases linearly.

[0111] In terms of file deletion, such as Figure 9 (a) and Figure 9 As shown in (b), the deletion throughput of the system built based on this application increases linearly, approximately 1.97 times that of Filecoin, while the deletion latency is almost constant, comparable to Filecoin. This demonstrates that the file deletion process of the system built based on this application has good scalability and minimal overhead for mapping deletions. Storj relies on satellite nodes to manage deletion requests, so the throughput remains constant while the deletion latency increases linearly. Sia does not participate in this experiment because it does not perform actual file deletions at storage nodes.

[0112] In terms of file retrieval, such as Figure 10 (a) and Figure 10As shown in (b), MPIR-DSN's throughput is slightly lower than Filecoin due to the additional computation required for multi-server PIR, while SPIR-DSN's throughput is even lower due to the greater computational overhead of single-server PIR. Furthermore, both MPIR-DSN and SPIR-DSN have higher data transfer volumes than Filecoin. When retrieving a file from four storage nodes, MPIR-DSN transfers approximately four times the file size, while SPIR-DSN transfers approximately 5.7 times the file size. This means that while Filecoin's throughput is 1.02 times higher than MPIR-DSN and approximately 2.17 times higher than SPIR-DSN, the latencies of MPIR-DSN and SPIR-DSN are approximately 4.51 times and 13.16 times higher than Filecoin, respectively. Sia's throughput is approximately 32.78 Mbps, and its retrieval latency increases linearly from 1.86 seconds to 10.13 seconds. Due to poor parameter configuration, Storj's throughput is approximately 14.77 Mbps, and its latency increases linearly from 17.26 seconds to 77.49 seconds.

[0113] As can be seen from the above, this embodiment uses two parts of experiments to compare the system built based on the method in this application with other systems in terms of time overhead, throughput and delay in file deletion, proof verification and retrieval processes, and proves the superiority of the comprehensive performance of the system built based on the method in this application.

[0114] See also Figure 11 As shown, the embodiment of the present application also discloses a file retrieval device based on a decentralized storage network protocol, including:

[0115] A vector determination module 11 is configured to determine a target vector corresponding to a file identifier stored in a vector set; wherein the vector set includes file vectors, each file vector corresponds to a Merkle tree; and the Merkle tree is configured to store the file identifier corresponding to the stored target file.

[0116] An index determination module 12 is configured to utilize a membership evidence corresponding to the file identifier and traverse the vector set starting from a vector next to the target vector until the vector set is completely traversed, thereby determining a file index corresponding to the file identifier based on a preset index determination process, and constructing a mapping relationship between the file index and the file identifier; the membership evidence is used to represent a path of the file identifier in the corresponding Merkle tree;

[0117] A first result sending module 13 is configured to, when performing a file search based on a preset privacy information retrieval protocol supporting a single storage node, obtain a file search vector sent by a user terminal using a single storage node, so that the single storage node constructs a target database based on a mapping relationship between a file index and a corresponding file identifier, determines a target search file corresponding to the file search vector from the target database, determines a target search result based on the target search file, and sends the target search result to the user terminal; the file search vector is a vector determined based on the file index;

[0118] The second result sending module 14 is used to use multiple storage nodes to obtain the file retrieval vector sent by the user terminal when performing file retrieval based on a preset privacy information retrieval protocol that supports multiple storage nodes, so that the multiple storage nodes can respectively construct their own corresponding target databases according to the mapping relationship between the file index and the corresponding file identifier, and determine the target retrieval file corresponding to the file retrieval vector from the target database, determine the target retrieval result based on the target retrieval file, and send the target retrieval result to the user terminal.

[0119] As can be seen from the above, in this application, the user end does not send the FID directly, but generates a file retrieval vector through the file index and sends the file retrieval vector to the storage node, so that the storage node cannot reversely infer the file content or category corresponding to the FID from the file index, thereby protecting user privacy and effectively improving the security of the decentralized network file retrieval process.

[0120] In some specific implementations, the index determination module 12 includes:

[0121] an initialization unit, configured to initialize a target counter to 1 and start traversing from a vector next to the target vector in the vector set;

[0122] a first traversal unit, configured to determine a vector sequence number corresponding to the currently traversed vector if the currently traversed vector is not empty, and to increase a current target counter based on the vector sequence number until the vector set is completely traversed;

[0123] The second traversal unit is used to determine the member evidence corresponding to the file identifier, traverse the position information corresponding to each target element in the member evidence, and if the current position information is represented as left, increase the current target counter based on the element serial number corresponding to the current position information until all target elements in the member evidence are traversed, and use the value corresponding to the current target counter as the file index corresponding to the file identifier.

[0124] In some specific implementations, the index determination module 12 further includes:

[0125] a proof submission submodule, configured to construct a file upload proof using a storage node storing the target file corresponding to the file identifier based on the vector set corresponding to the file identifier, the target vector, the member evidence, the file identifier, the file index, and a state hash value, and to submit the file upload proof to a blockchain using the storage node so that the blockchain determines whether the file upload proof has passed verification; the state hash value being a previous state hash value generated by the storage node when the file was last stored or deleted;

[0126] Correspondingly, the proof submission submodule includes:

[0127] a first verification result determining unit, configured to determine, using the blockchain, based on the vector set in the file upload certificate, the target vector, the member evidence, and the file identifier, whether the file identifier exists in the Merkle tree corresponding to the target vector and whether a mapping relationship between the file index and the file identifier is correct, so as to obtain a first verification result;

[0128] a second verification result determining unit, configured to obtain a first target file index using the blockchain based on the vector set, the target vector, and the member evidence, and according to the preset index determination process, to determine whether the first target file index matches the file index, thereby obtaining a second verification result;

[0129] a third verification result determining unit, configured to compare a current preset cryptographic accumulator state with a previous preset cryptographic accumulator state using the blockchain based on the vector set, the member evidence, and the state hash value, to verify whether a state can be transferred from the previous preset cryptographic accumulator state to the current preset cryptographic accumulator state, thereby obtaining a third verification result; the preset cryptographic accumulator includes a vector set and a file identifier, and is configured to establish a mapping relationship between a file index and a corresponding file identifier;

[0130] The first proof storage unit is configured to store the file upload proof in the blockchain if the first verification result, the second verification result, and the third verification result are all characterized as passed.

[0131] In some specific implementations, the file retrieval device based on the decentralized storage network protocol further includes:

[0132] a proof verification unit, configured to, during a file deletion phase, delete a file identifier corresponding to a target deleted file from the preset cryptographic accumulator, generate a corresponding file deletion proof for the file identifier corresponding to the target deleted file, and upload the file deletion proof to the blockchain so that the blockchain verifies whether the file deletion proof has passed verification;

[0133] The second proof storage unit is used to store the file deletion proof in the blockchain if the file deletion proof passes the verification.

[0134] In some specific embodiments, the process of file storage and file deletion by the storage node when using the preset privacy information retrieval protocol that supports a single storage node is consistent with the process of file storage and file deletion by the storage node when using the preset privacy information retrieval protocol that supports multiple storage nodes.

[0135] In some specific implementations, the file retrieval device based on the decentralized storage network protocol further includes:

[0136] An index determination unit, configured to obtain a target file upload certificate corresponding to the file to be retrieved from the blockchain, and determine a file index of a file identifier corresponding to the file to be retrieved in a corresponding target storage node from the target file upload certificate;

[0137] a database size determining unit, configured to determine a database size corresponding to the target storage node based on a maximum file index of a file identifier stored in the target storage node;

[0138] a vector sending unit, configured to generate a file retrieval vector according to a file index of a file identifier corresponding to the to-be-retrieved file in the target storage node and a database size corresponding to the target storage node, so that the user terminal sends the file retrieval vector to the target storage node;

[0139] Correspondingly, after the target storage node receives the file retrieval vector, the process further includes:

[0140] The database construction unit is used to construct a target database, save a second target file index corresponding to the file identifier stored in the database into the target database, and save a file corresponding to the second target file index into the target database; wherein, if the file corresponding to the second target file index is deleted, a blank file is saved into the target database.

[0141] In some specific implementations, the second result sending module 14 further includes:

[0142] The database state unification unit is used to control the honest nodes in the storage nodes to maintain a consistent database state based on the Byzantine fault-tolerant state machine replication protocol;

[0143] The file retrieval unit is used to perform file retrieval using the Byzantine robust privacy information retrieval protocol and based on the preset privacy information retrieval protocol supporting multiple storage nodes.

[0144] Furthermore, the embodiment of the present application also discloses an electronic device, Figure 12 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content in the diagram should not be considered as any limitation to the scope of application of the present application.

[0145] Figure 12 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps of the file retrieval method based on the decentralized storage network protocol disclosed in any of the aforementioned embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0146] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device. The communication protocol it follows is any communication protocol that can be applied to the technical solution of this application and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world. Its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0147] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or CD, etc. The resources stored thereon can include an operating system 221, a computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0148] The operating system 221 is used to manage and control the hardware devices and computer program 222 on the electronic device 20, and can be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of implementing the file retrieval method based on the decentralized storage network protocol performed by the electronic device 20 as disclosed in any of the aforementioned embodiments, the computer program 222 may further include a computer program capable of implementing other specific tasks.

[0149] Furthermore, this application discloses a computer-readable storage medium for storing a computer program; wherein, when executed by a processor, the computer program implements the aforementioned disclosed method for file retrieval based on a decentralized storage network protocol. The specific steps of this method can be found in the corresponding contents disclosed in the aforementioned embodiments and will not be further described here.

[0150] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. Reference can be made to the descriptions of the identical or similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions of the methods.

[0151] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0152] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0153] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0154] The above is a detailed introduction to the technical solution provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for those skilled in the art, according to the ideas of the present application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A file retrieval method based on a decentralized storage network protocol, characterized in that: include: Determining a target vector corresponding to a file identifier stored in a vector set; wherein the vector set includes file vectors, each file vector corresponds to a Merkle tree; and the Merkle tree is used to store the file identifier corresponding to the stored target file. Using the membership evidence corresponding to the file identifier, and traversing from the next vector of the target vector in the vector set until the vector set is completely traversed, to determine the file index corresponding to the file identifier based on a preset index determination process, and construct a mapping relationship between the file index and the file identifier; the membership evidence is used to represent the path of the file identifier in the corresponding Merkle tree; When performing file retrieval based on a preset privacy information retrieval protocol supporting a single storage node, a single storage node is used to obtain a file retrieval vector sent by a user terminal, so that the single storage node constructs a target database based on a mapping relationship between a file index and a corresponding file identifier, determines a target retrieval file corresponding to the file retrieval vector from the target database, determines a target retrieval result based on the target retrieval file, and sends the target retrieval result to the user terminal; The file retrieval vector is a vector determined based on the file index; When performing file retrieval based on a preset privacy information retrieval protocol that supports multiple storage nodes, multiple storage nodes are used to obtain the file retrieval vector sent by the user terminal, so that the multiple storage nodes respectively construct their own corresponding target databases based on the mapping relationship between the file index and the corresponding file identifier, and determine the target retrieval file corresponding to the file retrieval vector from the target database, determine the target retrieval result based on the target retrieval file, and send the target retrieval result to the user terminal.

2. The file retrieval method based on the decentralized storage network protocol according to claim 1 is characterized in that: The method of utilizing the member evidence corresponding to the file identifier and traversing from a vector next to the target vector in the vector set until the vector set is completely traversed to determine the file index corresponding to the file identifier based on a preset index determination process includes: Initialize the target counter to 1, and start traversing from the next vector of the target vector in the vector set; If the currently traversed vector is not empty, determining the vector sequence number corresponding to the currently traversed vector, and increasing the current target counter based on the vector sequence number until the vector set is completely traversed; Determine the member evidence corresponding to the file identifier, traverse the position information corresponding to each target element in the member evidence, and if the current position information is represented as left, increase the current target counter based on the element serial number corresponding to the current position information until all target elements in the member evidence are traversed, and use the value corresponding to the current target counter as the file index corresponding to the file identifier.

3. The file retrieval method based on the decentralized storage network protocol according to claim 1, characterized in that: After constructing the mapping relationship between the file index and the file identifier, the method further includes: Using a storage node storing the target file corresponding to the file identifier to construct a file upload proof based on the vector set corresponding to the file identifier, the target vector, the member evidence, the file identifier, the file index, and a state hash value, and using the storage node to submit the file upload proof to a blockchain so that the blockchain determines whether the file upload proof has passed verification; the state hash value is a previous state hash value generated by the storage node when the storage node last stored or deleted a file; Accordingly, determining whether the file upload certificate has passed verification using the blockchain includes: Determining, using the blockchain based on the vector set in the file upload proof, the target vector, the membership evidence, and the file identifier, whether the file identifier exists in the Merkle tree corresponding to the target vector and whether the mapping relationship between the file index and the file identifier is correct, to obtain a first verification result; Using the blockchain based on the vector set, the target vector, and the member evidence, and according to the preset index determination process, obtaining a first target file index to determine whether the first target file index matches the file index, thereby obtaining a second verification result; Comparing a current preset cryptographic accumulator state with a previous preset cryptographic accumulator state using the blockchain based on the vector set, the membership evidence, and the state hash value to verify whether a state can be transferred from the previous preset cryptographic accumulator state to the current preset cryptographic accumulator state, thereby obtaining a third verification result; the preset cryptographic accumulator includes a vector set and a file identifier, and is used to establish a mapping relationship between a file index and a corresponding file identifier; If the first verification result, the second verification result, and the third verification result are all characterized as passed, the file upload certificate passes the verification, and the file upload certificate is saved in the blockchain.

4. The file retrieval method based on the decentralized storage network protocol according to claim 3 is characterized in that: Also includes: In the file deletion phase, the file identifier corresponding to the target deleted file is deleted from the preset cryptographic accumulator, a corresponding file deletion certificate is generated for the file identifier corresponding to the target deleted file, and the file deletion certificate is uploaded to the blockchain so that the blockchain verifies whether the file deletion certificate passes verification; If the file deletion certificate passes the verification, the file deletion certificate is saved in the blockchain.

5. The file retrieval method based on the decentralized storage network protocol according to claim 1, characterized in that: The process of storing and deleting files by a storage node when using the preset privacy information retrieval protocol supporting a single storage node is consistent with the process of storing and deleting files by a storage node when using the preset privacy information retrieval protocol supporting multiple storage nodes.

6. The file retrieval method based on the decentralized storage network protocol according to claim 3 is characterized in that: Also includes: Obtaining a target file upload certificate corresponding to the file to be retrieved from the blockchain, and determining a file index of a file identifier corresponding to the file to be retrieved in a corresponding target storage node from the target file upload certificate; Determine the database size corresponding to the target storage node based on the maximum file index of the file identifier stored in the target storage node; generating a file retrieval vector according to a file index of a file identifier corresponding to the to-be-retrieved file in the target storage node and a database size corresponding to the target storage node, so that the user terminal sends the file retrieval vector to the target storage node; Correspondingly, after the target storage node receives the file retrieval vector, the process further includes: Construct a target database, save a second target file index corresponding to the file identifier stored in the target database, and save the file corresponding to the second target file index in the target database; wherein, if the file corresponding to the second target file index is deleted, save a blank file in the target database.

7. The file retrieval method based on a decentralized storage network protocol according to any one of claims 1 to 6, characterized in that: When performing file retrieval based on a preset privacy information retrieval protocol that supports multiple storage nodes, it also includes: Based on the Byzantine fault-tolerant state machine replication protocol, the honest nodes in the storage nodes are controlled to maintain a consistent database state; File retrieval is performed using the Byzantine robust privacy information retrieval protocol and based on the preset privacy information retrieval protocol that supports multiple storage nodes.

8. A file retrieval device based on a decentralized storage network protocol, characterized in that: include: a vector determination module, configured to determine a target vector corresponding to a file identifier stored in a vector set; wherein the vector set includes file vectors, each file vector corresponding to a Merkle tree; and wherein the Merkle tree is configured to store the file identifier corresponding to the stored target file. an index determination module, configured to utilize a membership evidence corresponding to the file identifier and traverse from a vector next to the target vector in the vector set until the vector set is completely traversed, so as to determine a file index corresponding to the file identifier based on a preset index determination process, and to establish a mapping relationship between the file index and the file identifier; the membership evidence being used to represent a path of the file identifier in the corresponding Merkle tree; A first result sending module is configured to, when performing a file search based on a preset privacy information retrieval protocol supporting a single storage node, obtain a file search vector sent by a user terminal using a single storage node, so that the single storage node constructs a target database based on a mapping relationship between a file index and a corresponding file identifier, determines a target search file corresponding to the file search vector from the target database, determines a target search result based on the target search file, and sends the target search result to the user terminal; the file search vector is a vector determined based on the file index; The second result sending module is used to use multiple storage nodes to obtain the file retrieval vector sent by the user terminal when performing file retrieval based on a preset privacy information retrieval protocol that supports multiple storage nodes, so that the multiple storage nodes can respectively construct their own corresponding target databases based on the mapping relationship between the file index and the corresponding file identifier, and determine the target retrieval file corresponding to the file retrieval vector from the target database, determine the target retrieval result based on the target retrieval file, and send the target retrieval result to the user terminal.

9. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the file retrieval method based on the decentralized storage network protocol according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that Used to store a computer program, which, when executed by a processor, implements the file retrieval method based on a decentralized storage network protocol as described in any one of claims 1 to 7.

Images