Decentralized data security storage method and device, equipment and storage medium

Abstract

The invention discloses a decentralized data security storage method and device, equipment and a storage medium. The method is applied to a certification child node under a data storage node, and comprises the following steps: querying challenge information from a block chain network according to a preset time period, and judging whether a self-certification child node generates a challenge response certification according to a challenge node identifier in the challenge information; if yes, according to a data fragment identifier in the challenge information, acquiring an erasure code data fragment from an IPFS child node under the data storage node; the erasure code data fragments are generated and obtained by trusted nodes; generating a challenge response proof according to the erasure code data fragment and a pre-acquired random number; and the challenge response proof is stored on a chain, so that proof verification results are generated on the chain according to the challenge response proof, proof verification results corresponding to the proof child nodes are obtained from the trust node chain, and data integrity verification is performed on the data storage nodes based on the proof verification results.

Description

Technical Field

[0001] This invention relates to the field of data storage technology, and in particular to a decentralized data security storage method, apparatus, device, and storage medium. Background Technology

[0002] Currently, existing decentralized file storage systems, such as the content-addressed storage architecture based on IPFS (InterPlanetary File System), while enabling distributed file storage and access, still have many problems. In untrusted environments, users find it difficult to verify whether a node actually stores specific content, and the corresponding node also finds it difficult to prove that it has actually stored specific content.

[0003] Furthermore, during the verification of a specific content of a file by a node, a certain level of security and reliability needs to be ensured. In addition, traditional replication mechanisms have large redundancy overhead, serious resource waste, and lack efficient redundancy optimization strategies. Summary of the Invention

[0004] This invention provides a decentralized data security storage method, apparatus, device, and storage medium, enabling data storage nodes to self-certify that they have indeed stored a specific piece of information from a file, and ensuring a certain level of security and reliability during the verification process, thereby improving data storage efficiency.

[0005] According to one aspect of the present invention, a decentralized data security storage method is provided, applied to a proof sub-node under a data storage node, the method comprising:

[0006] The system queries challenge information from the blockchain network according to a preset time period, and determines whether to generate a challenge response proof by its own proof child node based on the challenge node identifier in the challenge information.

[0007] If so, then according to the data fragment identifier in the challenge information, erasure coding data fragments are obtained from the IPFS sub-nodes under the data storage node; the erasure coding data fragments stored in the IPFS sub-nodes are obtained by the trusted node performing erasure coding on the file data submitted by the user; the trusted node stores several erasure coding data fragments obtained after performing erasure coding on the file data under each IPFS sub-node in the IPFS network; each IPFS sub-node stores different erasure coding data fragments.

[0008] Based on the erasure coding data fragments and pre-acquired random numbers, a challenge response proof is generated; the random numbers are generated by the trusted node.

[0009] The challenge response proof is stored on the blockchain so that the blockchain can generate proof verification results based on the challenge response proof. The trusted node obtains the proof verification results corresponding to each proof sub-node on the blockchain and performs data integrity verification on each data storage node based on each proof verification result.

[0010] According to another aspect of the present invention, a decentralized data security storage method is provided, applied to trusted nodes, the method comprising:

[0011] The verification results of each proof sub-node are queried from the blockchain network according to a preset time period.

[0012] If the number of verified results in each of the aforementioned proofs is less than a preset threshold, erasure coding data fragments are obtained from the IPFS sub-nodes under each data storage node. Based on the obtained erasure coding data fragments, target file data is synthesized. Then, erasure coding data fragments are generated again based on the target file data and stored in each IPFS sub-node. The corresponding proof sub-nodes then perform challenge response proofs.

[0013] According to another aspect of the present invention, a decentralized data security storage device is provided, comprising a proof sub-node configured under a data storage node, the device comprising:

[0014] The proof generation and judgment module is used to query challenge information from the blockchain network according to a preset time period, and determine whether to generate a challenge response proof by its own proof child node based on the challenge node identifier in the challenge information.

[0015] The erasure coding data acquisition module is used to, if it is determined that the challenge response proof was generated by its own proof child node, retrieve erasure coding data fragments from the IPFS child nodes under the data storage node according to the data fragment identifier in the challenge information; the erasure coding data fragments stored in the IPFS child nodes are obtained by the trusted node performing erasure coding on the file data submitted by the user; the trusted node stores several erasure coding data fragments obtained after performing erasure coding on the file data under each IPFS child node in the IPFS network; each IPFS child node stores different erasure coding data fragments;

[0016] The challenge proof generation module is used to generate a challenge response proof based on the erasure coding data fragments and pre-acquired random numbers; the random numbers are generated by the trusted node.

[0017] The challenge proof on-chain module is used to store the challenge response proof on the chain so that the chain can generate proof verification results based on the challenge response proof, and the trusted node on the chain can obtain the proof verification results corresponding to each proof sub-node, and perform data integrity verification on each data storage node based on each proof verification result.

[0018] According to another aspect of the present invention, a decentralized data security storage device is provided, configured on a trusted node, the device comprising:

[0019] The verification result query module is used to query the verification results of each proof sub-node from the blockchain network according to a preset time period.

[0020] The target file synthesis module is used to obtain erasure coding data fragments from the IPFS sub-nodes under each data storage node if the number of verified results in each proof verification result is less than a preset threshold. Then, it synthesizes target file data based on the obtained erasure coding data fragments, and stores the target file data into erasure coding data fragments again after generating them in the target file data. The fragments are then stored in each IPFS sub-node, and the corresponding proof sub-nodes perform challenge response proofs.

[0021] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0022] At least one processor; and

[0023] A memory communicatively connected to the at least one processor; wherein,

[0024] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the decentralized data security storage method according to any embodiment of the present invention.

[0025] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions, the computer instructions being configured to cause a processor to execute and implement the decentralized data security storage method described in any embodiment of the present invention.

[0026] This invention's technical solution involves erasure coding fragmentation of file data and storing it on various IPFS child nodes. Each proving child node responds to a challenge based on a random number, proving that its data storage node indeed stores the corresponding erasure-coded data fragments. Trust nodes then verify the data integrity and security of the proof results from each proving child node. The trusted node retrieves the user-submitted file data and distributes the erasure-coded data fragments. Since the trusted node is trusted by both the data storage nodes and the user, data processing and distribution have a certain degree of security and reliability. Furthermore, erasure coding data fragmentation achieves a natural connection between content addressing and file fragmentation. Simultaneously, file fragmentation and encoding significantly improve data storage redundancy efficiency, increasing availability while reducing storage costs. This allows data storage nodes to self-prove that they have indeed stored specific content information of a file, with a certain degree of security and reliability during the verification process, while also improving data storage efficiency.

[0027] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 This is a flowchart of a decentralized data security storage method provided in Embodiment 1 of the present invention;

[0030] Figure 2 This is a flowchart of a decentralized data security storage method provided according to Embodiment 2 of the present invention;

[0031] Figure 3 This is an interactive flowchart of a decentralized data security storage method provided in Embodiment 3 of the present invention;

[0032] Figure 4 This is a schematic diagram of the structure of a decentralized data security storage device according to Embodiment 4 of the present invention;

[0033] Figure 5 This is a schematic diagram of the structure of a decentralized data security storage device according to Embodiment 5 of the present invention;

[0034] Figure 6 This is a schematic diagram of the structure of an electronic device that implements the decentralized data security storage method of this invention. Detailed Implementation

[0035] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0036] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0037] Example 1

[0038] Figure 1 This is a flowchart of a decentralized data security storage method provided in Embodiment 1 of the present invention. This embodiment is applicable to the secure and reliable storage of decentralized data. The method can be executed by a decentralized data security storage device, which can be implemented in hardware and / or software and can be configured in an electronic device.

[0039] like Figure 1 As shown, this method is applied to the proof child node under the data storage node, including:

[0040] S110. Query challenge information from the blockchain network according to the preset time period, and determine whether to generate challenge response proof by its own proof child node based on the challenge node identifier in the challenge information.

[0041] S120. If so, then according to the data fragment identifier in the challenge information, obtain erasure coding data fragments from the IPFS sub-nodes under the data storage node; the erasure coding data fragments stored in the IPFS sub-nodes are obtained by the trusted node after erasure coding the file data submitted by the user; the trusted node stores several erasure coding data fragments obtained after erasure coding the file data to each IPFS sub-node in the IPFS network; each IPFS sub-node stores different erasure coding data fragments.

[0042] S130. Generate a challenge response proof based on erasure coding data fragments and pre-acquired random numbers; the random numbers are generated by trusted nodes.

[0043] S140. Store the challenge response proof on the blockchain so that the blockchain can generate proof verification results based on the challenge response proof. The trusted node on the blockchain can obtain the proof verification results corresponding to each proof sub-node and perform data integrity verification on each data storage node based on each proof verification result.

[0044] The data storage node includes a proof sub-node and an IPFS sub-node. The proof sub-node is used to prove that a specific data fragment exists in the IPFS sub-node of the data storage node, and the IPFS sub-node is used to store the data fragment sent by the trusted node.

[0045] Among them, trusted nodes are reliable nodes trusted by the majority of users. They can be deployed by servers trusted by users and can be considered as a trusted program. If there are users who do not trust the trusted node, they can redeploy the trusted node themselves.

[0046] The preset time period can be pre-set by relevant technical personnel according to actual needs, meaning that the proof child node can periodically query challenge information from the blockchain network. The challenge information is generated by trusted nodes and stored on the blockchain periodically.

[0047] The trusted node obtains the file data submitted by the user for storage and performs erasure coding fragmentation on the file data, resulting in several erasure-coded data fragments. Each erasure-coded data fragment is then distributed to different IPFS child nodes in the IPFS network. It should be noted that different IPFS child nodes store different erasure-coded data fragments.

[0048] Trusted nodes generate data shard identifiers corresponding to erasure coding data shards. These identifiers uniquely identify the erasure coding data shard, meaning subsequent proof-generating child nodes can uniquely retrieve the corresponding erasure coding data shard from IPFS child nodes based on this identifier. Trusted nodes can also generate metadata information corresponding to the erasure coding data shards and store this metadata on the blockchain. Specifically, the blockchain network can invoke a business contract to store the metadata information of the erasure coding data shards. This metadata information may include the data shard identifier, shard length, shard hash value, and URL (Uniform Resource Locator) information.

[0049] It should be noted that before the trusted node periodically challenges the blockchain, the proving child node needs to register information with the trusted node.

[0050] In an optional embodiment, before querying challenge information from the blockchain network according to a preset time period and determining whether the challenge response proof should be generated by the self-proving sub-node based on the challenge node identifier in the challenge information, the method further includes: generating a node registration request based on the blockchain user address information of the self-proving sub-node; and sending the node registration request to a trusted node so that the trusted node can generate the challenge node identifier of the corresponding proof sub-node based on the blockchain user address information in the node registration request.

[0051] Specifically, the proof child node generates a node registration request based on its own blockchain user address information and sends the request to the trusted node. Upon receiving the node registration request, the trusted node parses it to obtain the blockchain user address information of the proof child node. The trusted node stores the blockchain user address information of each proof child node for subsequent zero-knowledge proofs.

[0052] Trusted nodes periodically initiate challenges to the blockchain. Specifically, the trusted node generates challenge information, which is then stored by the blockchain network through a business contract. This challenge information includes a challenge node identifier and a data shard identifier. The challenge node identifier specifies the proof child node that must provide the challenge response proof; the data shard identifier indicates that the proof child node must prove that the corresponding data shard is indeed stored in the IPFS child node of the data storage node.

[0053] The proof sub-node periodically queries challenge information from the blockchain network. If the challenge node identifier in the query challenge information is an identifier generated based on its own blockchain user address information, then it is determined that its own proof sub-node should respond to the challenge and generate a challenge response proof. If the challenge node identifier in the query challenge information is not an identifier generated based on its own blockchain user address information, then it is determined that the challenge is not a challenge that its own proof sub-node needs to complete, and therefore no response is required.

[0054] If the proof sub-node determines, based on the challenge node identifier in the challenge information, that it should generate the challenge response proof, then it retrieves the erasure coding data shard corresponding to the data shard identifier from the IPFS sub-node under the data storage node, based on the data shard identifier in the challenge information. The challenge response proof is then generated based on the erasure coding data shard and a pre-obtained random number. The random number can be generated by the trusted node and sent directly to the proof sub-node, or it can be generated by the trusted node and stored as metadata information of the erasure coding data shard in the blockchain network, which the proof sub-node then retrieves from the chain. This embodiment does not impose any restrictions on this.

[0055] In one optional embodiment, generating a challenge response proof based on erasure coding data fragments and pre-acquired random numbers includes: obtaining a first public hash value; and generating a second public hash value based on erasure coding data fragments and random numbers; performing block processing on the erasure coding data fragments to obtain first private data; and performing block processing on the random numbers to obtain second private data; generating a proof input file based on the first private data, the second private data, the first public hash value, and the second public hash value; performing circuit calculation processing on the proof input file based on a preset proof generation function and a pre-generated circuit proof key to obtain a core proof file and a core public file; and generating a challenge response proof including the core proof file and the core public file.

[0056] The first public hash value can be obtained from the blockchain network; it is the data obtained by hashing the erasure coding data shards. Trusted nodes can store this parameter value as metadata information of the erasure coding data shards on the chain. The proof child node concatenates the erasure coding data shards with a random number to obtain concatenated data, and then performs a hash value calculation on the concatenated data to obtain the second public hash value.

[0057] The proof sub-node divides the erasure coding data into blocks to obtain the first private data, and divides the random numbers into blocks to obtain the second private data. The specific number of blocks can be defined by relevant technical personnel when designing the constraint circuit. For example, the erasure coding data can be divided into 133 blocks, with zero elements added if there are fewer than 133 blocks, to obtain the first private data; the random numbers can be divided into 2 blocks to obtain the second private data.

[0058] Based on the first private data, the second private data, the first public hash value, and the second public hash value, a proof input file, input.json, is generated. A proof generation function specifically designed for generating zero-knowledge proofs and the Groth16 algorithm of the zero-knowledge proof protocol are invoked. Based on the pre-generated circuit proof key, circuit calculations are performed on the proof input file to obtain the core proof file proof.json and the core public file public.json. A challenge response proof including the core proof file and the core public file is then generated.

[0059] In the above technical solution, random numbers are introduced during the generation of challenge response proofs, making the generation process more unpredictable. Compared to existing challenge response proofs generated based on timestamps, which are predictable and have lower security, for example, if a challenge is initiated within a fixed time period, the timestamp can be prepared in advance and the content of the file to be proved can be calculated to forge the challenge response proof. However, the file content may have already been discarded. Therefore, the challenge response proof generation method of this solution has higher security and reliability, thus providing strong proof that a node has stored specific data, further improving the security of decentralized storage.

[0060] In an optional embodiment, before generating the challenge response proof based on erasure coding data shards and pre-acquired random numbers, the method further includes: constructing a constraint circuit based on zero-knowledge proof; compiling the constraint circuit of zero-knowledge proof into a zero-knowledge proof circuit template using a preset compilation algorithm, generating corresponding circuit proof keys and circuit verification keys; storing the circuit proof keys in the proof sub-node, and embedding the circuit verification keys into the on-chain smart contract.

[0061] The constraint circuit for zero-knowledge proof can be pre-constructed by relevant technical personnel based on actual verification requirements. Verification requirements refer to verifying that a specific data fragment is actually stored within the data storage node. Specifically, the constructed constraint circuit can include the following modules: an input variable definition module, a pre-verification module, a circuit verification module, and an output signal definition module.

[0062] Private input parameters and public key input parameters are defined in the input variable definition module. Among them, elems

[133] : private input parameter, which divides the erasure coding data into 133 blocks, and fills in 0 elements if there are less than 133 blocks. rand[2]: private input parameter, which divides the random number (nonce) into 2 blocks. expected_chunk_hash: public input parameter, which is the expected poseidon (hash function) hash value generated based on elems. This value needs to be stored on the chain in advance and can be used for verification. expected_hash: public input parameter, which is the expected hash of this input and is used to verify whether the input value meets the expectation.

[0063] The pre-verification module includes two types of pre-verification: the first is to verify the proof submitter, that is, whether the proof child node is the specified submitter; the second is to verify whether the current proof has been proven.

[0064] The circuit verification module includes circuit constraints for defining the verification strategy, including a first constraint and a second constraint. The first constraint is poseidon(elems) == expected_chunk_hash, which ensures that the data provided by the person being proven does indeed match the original hash registered on the chain. The second constraint is poseidon(elems||rand) == expected_hash, which ensures that the proof is unique to a specific challenge random number and identity, preventing forgery and replay.

[0065] The output signal module includes the definition of the output signal, which is a Boolean variable indicating whether the constraint is satisfied.

[0066] The zero-knowledge proof constraint circuit is compiled into a zero-knowledge proof circuit template using the pre-defined Groth16 compilation algorithm, and corresponding circuit proof key and circuit verification key are generated. The circuit proof key is stored in the proof sub-node, and the circuit verification key is embedded in the on-chain smart contract.

[0067] Optionally, the challenge response proof can be stored on the blockchain for on-chain verification of the proof based on the challenge response proof. This includes storing the challenge response proof on the blockchain for on-chain smart contracts to verify the challenge response proof based on the circuit verification key and generate a verification result.

[0068] Specifically, the blockchain network invokes a smart contract, which uses a built-in circuit verification key to verify the challenge response proof submitted by the proof sub-node, thus obtaining a proof verification result. This result includes either successful or unsuccessful verification.

[0069] Trusted nodes query the blockchain network for the verification results of each proof sub-node according to a preset time period. If the number of verified results is not less than a preset threshold, the data integrity verification of each data storage node is considered successful. This threshold can be preset by technical personnel based on actual needs; for example, if the total number of erasure coding data shards is 100, the threshold can be set to 70. It should be noted that if the number of verified results is not less than the preset threshold, it can be assumed that each data storage node truly stores the corresponding erasure coding data shards, indicating that this round of decentralized file data storage has a certain degree of integrity and security.

[0070] If the number of verified results is less than a preset threshold, it indicates that most data storage nodes do not actually store erasure coding data fragments, or that data loss has occurred, resulting in data incompleteness. Therefore, the trusted nodes need to reassemble the original file and then re-fragment and distribute the reassembled original file for storage and verification.

[0071] Specifically, the trusted node retrieves erasure coding data fragments from the IPFS child nodes under each data storage node, essentially re-downloading the remaining erasure coding data fragments, and then synthesizes the target file data based on the retrieved erasure coding data fragments. It should be noted that the merged target file data is usually the original file data submitted by the user to the trusted node. The trusted node then performs erasure coding again on the merged target file data, generates erasure coding data fragments, and distributes them to each IPFS child node. The corresponding proof child node then challenges the data again, generating a challenge response proof.

[0072] This invention's technical solution involves erasure coding fragmentation of file data and storing it on various IPFS child nodes. Each proving child node responds to a challenge based on a random number, proving that its data storage node indeed stores the corresponding erasure-coded data fragments. Trust nodes then verify the data integrity and security of the proof results from each proving child node. The trusted node retrieves the user-submitted file data and distributes the erasure-coded data fragments. Since the trusted node is trusted by both the data storage nodes and the user, data processing and distribution have a certain degree of security and reliability. Furthermore, erasure coding data fragmentation achieves a natural connection between content addressing and file fragmentation. Simultaneously, file fragmentation and encoding significantly improve data storage redundancy efficiency, increasing availability while reducing storage costs. This allows data storage nodes to self-prove that they have indeed stored specific content information of a file, with a certain degree of security and reliability during the verification process, while also improving data storage efficiency.

[0073] Example 2

[0074] Figure 2 This is a flowchart of a decentralized data security storage method provided in Embodiment 2 of the present invention. This embodiment is applicable to the secure and reliable storage of decentralized data. The method can be executed by a decentralized data security storage device, which can be implemented in hardware and / or software and can be configured in an electronic device.

[0075] like Figure 2 As shown, this method is applied to trusted nodes and includes:

[0076] S210. Query the proof verification results corresponding to each proof sub-node from the blockchain network according to the preset time period.

[0077] S220. If the number of verified results in each proof is less than the preset threshold, erasure coding fragments are obtained from the IPFS sub-nodes under each data storage node. Based on the obtained erasure coding fragments, the target file data is synthesized. Then, erasure coding fragments are generated again based on the target file data and stored in each IPFS sub-node. The corresponding proof sub-nodes then perform challenge response proofs.

[0078] Trust nodes query the blockchain network for the proof verification results corresponding to each proof sub-node according to a preset time period.

[0079] Optionally, after querying the proof verification results corresponding to each proof sub-node from the blockchain network according to a preset time period, the method further includes: if the number of verified results in each proof verification result is not less than a preset number threshold, then the data integrity verification of each data storage node is determined to be passed.

[0080] Specifically, if the number of verified data pieces in each proof verification result is not less than a preset threshold, then the data integrity verification of each data storage node is considered successful. This threshold can be preset by relevant technical personnel based on actual needs; for example, if the total number of erasure coding data shards is 100, the threshold can be set to 70. It should be noted that if the number of verified data pieces in each proof verification result is not less than the preset threshold, it can be considered that each data storage node truly stores the corresponding erasure coding data shards, indicating that this round of decentralized file data storage has a certain degree of integrity and security.

[0081] If the number of verified results is less than a preset threshold, it indicates that most data storage nodes do not actually store erasure coding data fragments, or that data loss has occurred, resulting in data incompleteness. Therefore, the trusted nodes need to reassemble the original file and then re-fragment and distribute the reassembled original file for storage and verification.

[0082] Specifically, the trusted node retrieves erasure coding data fragments from the IPFS child nodes under each data storage node, essentially re-downloading the remaining erasure coding data fragments, and then synthesizes the target file data based on the retrieved erasure coding data fragments. It should be noted that the merged target file data is usually the original file data submitted by the user to the trusted node. The trusted node then performs erasure coding again on the merged target file data, generates erasure coding data fragments, and distributes them to each IPFS child node. The corresponding proof child node then challenges the data again, generating a challenge response proof.

[0083] The data storage node includes a proof sub-node and an IPFS sub-node. The proof sub-node is used to prove that a specific data fragment exists in the IPFS sub-node of the data storage node, and the IPFS sub-node is used to store the data fragment sent by the trusted node.

[0084] Among them, trusted nodes are reliable nodes trusted by the majority of users. They can be deployed by servers trusted by users and can be considered as a trusted program. If there are users who do not trust the trusted node, they can redeploy the trusted node themselves.

[0085] The preset time period can be pre-set by relevant technical personnel according to actual needs, meaning that the proof child node can periodically query challenge information from the blockchain network. The challenge information is generated by trusted nodes and stored on the blockchain periodically.

[0086] The trusted node obtains the file data submitted by the user for storage and performs erasure coding fragmentation on the file data, resulting in several erasure-coded data fragments. Each erasure-coded data fragment is then distributed to different IPFS child nodes in the IPFS network. It should be noted that different IPFS child nodes store different erasure-coded data fragments.

[0087] Optionally, the system acquires file data submitted by the user, performs erasure coding on the file data to obtain erasure-coded data fragments, generates a data fragment identifier corresponding to the erasure-coded data fragment, generates a challenge node identifier based on the blockchain user address information, generates challenge information based on the data fragment identifier and the challenge node identifier, and stores the challenge information on the blockchain.

[0088] Trusted nodes generate data shard identifiers corresponding to erasure coding data shards. These identifiers uniquely identify the erasure coding data shard, ensuring that subsequent child nodes can uniquely retrieve the corresponding erasure coding data shard from IPFS child nodes. Trusted nodes can also generate metadata information corresponding to the erasure coding data shards and store this metadata on the blockchain. Specifically, the blockchain network can invoke a business contract to store the metadata information of the erasure coding data shards. This metadata information may include the data shard identifier, shard length, shard hash value, and URL (Uniform Resource Locator) information.

[0089] It should be noted that before the trusted node periodically challenges the blockchain, the proving child node needs to register information with the trusted node.

[0090] In one optional embodiment, the node registration request of the proof sub-node is obtained, and the node registration request is parsed to obtain the blockchain user address information of the proof sub-node; the blockchain user address information of each proof sub-node is stored.

[0091] Specifically, the proof child node generates a node registration request based on its own blockchain user address information and sends the request to the trusted node. Upon receiving the node registration request, the trusted node parses it to obtain the blockchain user address information of the proof child node. The trusted node stores the blockchain user address information of each proof child node for subsequent zero-knowledge proofs.

[0092] Trusted nodes periodically initiate challenges to the blockchain. Specifically, the trusted node generates challenge information, which is then stored by the blockchain network through a business contract. This challenge information includes a challenge node identifier and a data shard identifier. The challenge node identifier specifies the proof child node that must provide the challenge response proof; the data shard identifier indicates that the proof child node must prove that the corresponding data shard is indeed stored in the IPFS child node of the data storage node.

[0093] The proof sub-node periodically queries challenge information from the blockchain network. If the challenge node identifier in the query challenge information is an identifier generated based on its own blockchain user address information, then it is determined that its own proof sub-node should respond to the challenge and generate a challenge response proof. If the challenge node identifier in the query challenge information is not an identifier generated based on its own blockchain user address information, then it is determined that the challenge is not a challenge that its own proof sub-node needs to complete, and therefore no response is required.

[0094] If the proof sub-node determines, based on the challenge node identifier in the challenge information, that it should generate the challenge response proof, then it retrieves the erasure coding data shard corresponding to the data shard identifier from the IPFS sub-node under the data storage node, based on the data shard identifier in the challenge information. The challenge response proof is then generated based on the erasure coding data shard and a pre-obtained random number. The random number can be generated by the trusted node and sent directly to the proof sub-node, or it can be generated by the trusted node and stored as metadata information of the erasure coding data shard in the blockchain network, which the proof sub-node then retrieves from the chain. This embodiment does not impose any restrictions on this.

[0095] In one optional embodiment, generating a challenge response proof based on erasure coding data fragments and pre-acquired random numbers includes: obtaining a first public hash value; and generating a second public hash value based on erasure coding data fragments and random numbers; performing block processing on the erasure coding data fragments to obtain first private data; and performing block processing on the random numbers to obtain second private data; generating a proof input file based on the first private data, the second private data, the first public hash value, and the second public hash value; performing circuit calculation processing on the proof input file based on a preset proof generation function and a pre-generated circuit proof key to obtain a core proof file and a core public file; and generating a challenge response proof including the core proof file and the core public file.

[0096] The first public hash value can be obtained from the blockchain network; it is the data obtained by hashing the erasure coding data shards. Trusted nodes can store this parameter value as metadata information of the erasure coding data shards on the chain. The proof child node concatenates the erasure coding data shards with a random number to obtain concatenated data, and then performs a hash value calculation on the concatenated data to obtain the second public hash value.

[0097] The proof sub-node divides the erasure coding data into blocks to obtain the first private data, and divides the random numbers into blocks to obtain the second private data. The specific number of blocks can be defined by relevant technical personnel when designing the constraint circuit. For example, the erasure coding data can be divided into 133 blocks, with zero elements added if there are fewer than 133 blocks, to obtain the first private data; the random numbers can be divided into 2 blocks to obtain the second private data.

[0098] Based on the first private data, the second private data, the first public hash value, and the second public hash value, a proof input file, input.json, is generated. A proof generation function specifically designed for generating zero-knowledge proofs and the Groth16 algorithm of the zero-knowledge proof protocol are invoked. Based on the pre-generated circuit proof key, circuit calculations are performed on the proof input file to obtain the core proof file proof.json and the core public file public.json. A challenge response proof including the core proof file and the core public file is then generated.

[0099] In the above technical solution, random numbers are introduced during the generation of challenge response proofs, making the generation process more unpredictable. Compared to existing challenge response proofs generated based on timestamps, which are predictable and have lower security, for example, if a challenge is initiated within a fixed time period, the timestamp can be prepared in advance and the content of the file to be proved can be calculated to forge the challenge response proof. However, the file content may have already been discarded. Therefore, the challenge response proof generation method of this solution has better security and reliability, thus providing strong proof that a node has stored specific data, further improving the security of decentralized storage.

[0100] In an optional embodiment, before generating the challenge response proof based on erasure coding data shards and pre-acquired random numbers, the method further includes: constructing a constraint circuit based on zero-knowledge proof; compiling the constraint circuit of zero-knowledge proof into a zero-knowledge proof circuit template using a preset compilation algorithm, generating corresponding circuit proof keys and circuit verification keys; storing the circuit proof keys in the proof sub-node, and embedding the circuit verification keys into the on-chain smart contract.

[0101] The constraint circuit for zero-knowledge proof can be pre-constructed by relevant technical personnel based on actual verification requirements. Verification requirements refer to verifying that a specific data fragment is actually stored within the data storage node. Specifically, the constructed constraint circuit can include the following modules: an input variable definition module, a pre-verification module, a circuit verification module, and an output signal definition module.

[0102] Private input parameters and public key input parameters are defined in the input variable definition module. Among them, elems

[133] : private input parameter, which divides the erasure coding data into 133 blocks, and fills in 0 elements if there are less than 133 blocks. rand[2]: private input parameter, which divides the random number (nonce) into 2 blocks. expected_chunk_hash: public input parameter, which is the expected poseidon (hash function) hash value generated based on elems. This value needs to be stored on the chain in advance and can be used for verification. expected_hash: public input parameter, which is the expected hash of this input and is used to verify whether the input value meets the expectation.

[0103] The pre-verification module includes two types of pre-verification: the first is to verify the proof submitter, that is, whether the proof child node is the specified submitter; the second is to verify whether the current proof has been proven.

[0104] The circuit verification module includes circuit constraints for defining the verification strategy, including a first constraint and a second constraint. The first constraint is poseidon(elems) == expected_chunk_hash, which ensures that the data provided by the person being proven does indeed match the original hash registered on the chain. The second constraint is poseidon(elems||rand) == expected_hash, which ensures that the proof is unique to a specific challenge random number and identity, preventing forgery and replay.

[0105] The output signal module includes the definition of the output signal, which is a Boolean variable indicating whether the constraint is satisfied.

[0106] The zero-knowledge proof constraint circuit is compiled into a zero-knowledge proof circuit template using the pre-defined Groth16 compilation algorithm, and corresponding circuit proof key and circuit verification key are generated. The circuit proof key is stored in the proof sub-node, and the circuit verification key is embedded in the on-chain smart contract.

[0107] Optionally, the challenge response proof can be stored on the blockchain for on-chain verification of the proof based on the challenge response proof. This includes storing the challenge response proof on the blockchain for on-chain smart contracts to verify the challenge response proof based on the circuit verification key and generate a verification result.

[0108] Specifically, the blockchain network invokes a smart contract, which uses a built-in circuit verification key to verify the challenge response proof submitted by the proof sub-node, thus obtaining a proof verification result. This result includes either successful or unsuccessful verification.

[0109] This invention's technical solution involves erasure coding fragmentation of file data and storing it on various IPFS child nodes. Each proving child node responds to a challenge based on a random number, proving that its data storage node indeed stores the corresponding erasure-coded data fragments. Trust nodes then verify the data integrity and security of the proof results from each proving child node. The trusted node retrieves the user-submitted file data and distributes the erasure-coded data fragments. Since the trusted node is trusted by both the data storage nodes and the user, data processing and distribution have a certain degree of security and reliability. Furthermore, erasure coding data fragmentation achieves a natural connection between content addressing and file fragmentation. Simultaneously, file fragmentation and encoding significantly improve data storage redundancy efficiency, increasing availability while reducing storage costs. This allows data storage nodes to self-prove that they have indeed stored specific content information of a file, with a certain degree of security and reliability during the verification process, while also improving data storage efficiency.

[0110] Example 3

[0111] Figure 3 This is an interactive flowchart of a decentralized data security storage method provided in Embodiment 3 of the present invention. Based on the above embodiments, this embodiment provides a preferred example.

[0112] like Figure 3 As shown, the method includes the following specific steps:

[0113] S31. All proof child nodes register with the trusted node and submit blockchain user address information.

[0114] S32. The trusted node completes the registration of the proof sub-node based on the blockchain user address information of the proof sub-node.

[0115] S33. The trusted node receives the file data submitted by the user and performs erasure coding on the file data to obtain several erasure coding fragments.

[0116] S34. The trusted node submits the erasure coding shard data to the IPFS child node and submits the metadata of the generated erasure coding shard data to the blockchain network storage.

[0117] S35. Trusted nodes periodically launch challenges to the blockchain network, generate challenge information, and upload it to the chain.

[0118] S36. The proof child node periodically queries the chain for challenge information. If there is challenge information about this node, it obtains the erasure coding data fragment that needs to be proved from the IPFS child node according to the challenge information and generates a challenge response proof.

[0119] S37. Prove that the child node will upload the challenge response proof to the blockchain for storage.

[0120] S38. The blockchain network verifies the challenge response proof uploaded by the proof child node and obtains the corresponding proof verification result.

[0121] S39. Trusted nodes periodically obtain the proof verification results from the proof child nodes on the chain.

[0122] S40. The trusted node determines whether the number of successful verification results is less than the set threshold. If so, it re-downloads the erasure coding data fragments from each IPFS child node, synthesizes them into a new target file, and resubmits it, repeating steps S34-S39. If not, it repeats steps S33-S39.

[0123] Example 4

[0124] Figure 4 This is a schematic diagram of a decentralized data security storage device provided in Embodiment 4 of the present invention. The decentralized data security storage device provided in this embodiment of the present invention is applicable to the secure and reliable storage of decentralized data. This decentralized data security storage device can be implemented in hardware and / or software, such as... Figure 4 As shown, the device is configured as a proof sub-node under the data storage node, including: a proof generation and judgment module 401, an erasure coding data acquisition module 402, a challenge proof generation module 403, and a challenge proof on-chain module 404. Among them,

[0125] The proof generation and judgment module 401 is used to query challenge information from the blockchain network according to a preset time period, and determine whether the challenge response proof is generated by its own proof child node according to the challenge node identifier in the challenge information.

[0126] The erasure coding data acquisition module 402 is used to, if it is determined that the challenge response proof is generated by its own proof child node, obtain erasure coding data fragments from the IPFS child nodes under the data storage node according to the data fragment identifier in the challenge information; the erasure coding data fragments stored in the IPFS child nodes are obtained by the trusted node performing erasure coding on the file data submitted by the user; the trusted node stores several erasure coding data fragments obtained after performing erasure coding on the file data under each IPFS child node in the IPFS network; each IPFS child node stores different erasure coding data fragments respectively;

[0127] The challenge proof generation module 403 is used to generate a challenge response proof based on the erasure coding data fragments and a pre-acquired random number; the random number is generated by the trusted node.

[0128] The challenge proof on-chain module 404 is used to store the challenge response proof on the chain so that the chain can generate a proof verification result based on the challenge response proof, and the trust node on the chain can obtain the proof verification result corresponding to each proof sub-node, and perform data integrity verification on each data storage node based on each proof verification result.

[0129] This invention's technical solution involves erasure coding fragmentation of file data and storing it on various IPFS child nodes. Each proving child node responds to a challenge based on a random number, proving that its data storage node indeed stores the corresponding erasure-coded data fragments. Trust nodes then verify the data integrity and security of the proof results from each proving child node. The trusted node retrieves the user-submitted file data and distributes the erasure-coded data fragments. Since the trusted node is trusted by both the data storage nodes and the user, data processing and distribution have a certain degree of security and reliability. Furthermore, erasure coding data fragmentation achieves a natural connection between content addressing and file fragmentation. Simultaneously, file fragmentation and encoding significantly improve data storage redundancy efficiency, increasing availability while reducing storage costs. This allows data storage nodes to self-prove that they have indeed stored specific content information of a file, with a certain degree of security and reliability during the verification process, while also improving data storage efficiency.

[0130] Optionally, the challenge proof generation module 403 includes:

[0131] A public-private value generation unit is used to obtain a first public hash value and generate a second public hash value based on the erasure coding data fragment and the random number.

[0132] The block processing unit is used to perform block processing on the erasure coding data fragments to obtain first private data, and to perform block processing on the random number to obtain second private data.

[0133] The proof input file generation unit is used to generate a proof input file based on the first private data, the second private data, the first public hash value, and the second public hash value.

[0134] The circuit calculation unit is used to perform circuit calculation processing on the proof input file according to the preset proof generation function and based on the pre-generated circuit proof key, to obtain the core proof file and the core public file;

[0135] The challenge proof generation unit is used to generate challenge response proofs that include the core proof file and the core public file.

[0136] Optionally, the challenge proof generation module 403 further includes:

[0137] A constraint circuit construction unit is used to construct a constraint circuit based on zero-knowledge proof before generating a challenge response proof based on the erasure coding data fragments and the pre-acquired random numbers.

[0138] The proof and verification key generation unit is used to compile the constraint circuit of the zero-knowledge proof into a zero-knowledge proof circuit template through a preset compilation algorithm, and generate the corresponding circuit proof key and circuit verification key.

[0139] A key storage unit is used to store the circuit proof key in the proof sub-node and to embed the circuit verification key into the on-chain smart contract.

[0140] Optional, the challenge proof on-chain module 404, specifically used for:

[0141] The challenge response proof is stored on the blockchain so that on-chain smart contracts can verify the challenge response proof based on the circuit verification key and generate a proof verification result.

[0142] Optionally, the device further includes:

[0143] The node registration request generation module is used to generate a node registration request based on the blockchain user address information of the self-proving sub-node before querying challenge information from the blockchain network according to a preset time period and determining whether to generate a challenge response proof based on the challenge node identifier in the challenge information.

[0144] The node registration request sending module is used to send the node registration request to the trusted node, so that the trusted node can generate the challenge node identifier of the corresponding proof child node based on the blockchain user address information in the node registration request.

[0145] The decentralized data security storage device provided in the embodiments of the present invention can execute the decentralized data security storage method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0146] Example 5

[0147] Figure 5This is a schematic diagram of a decentralized data security storage device provided in Embodiment 5 of the present invention. The decentralized data security storage device provided in this embodiment of the present invention is applicable to the secure and reliable storage of decentralized data. This decentralized data security storage device can be implemented in hardware and / or software, such as... Figure 5 As shown, the device is configured on a trusted node and includes: a verification result query module 501 and a target file synthesis module 502. Among them,

[0148] The verification result query module 501 is used to query the verification results of each proof sub-node from the blockchain network according to a preset time period.

[0149] The target file synthesis module 502 is used to obtain erasure coding data fragments from the IPFS sub-nodes under each data storage node if the number of verified results in each of the proof verification results is less than a preset number threshold. Then, it synthesizes target file data based on the obtained erasure coding data fragments, and stores the target file data into each IPFS sub-node after generating erasure coding data fragments again. The corresponding proof sub-nodes then perform challenge response proofs.

[0150] This invention's technical solution involves erasure coding fragmentation of file data and storing it on various IPFS child nodes. Each proving child node responds to a challenge based on a random number, proving that its data storage node indeed stores the corresponding erasure-coded data fragments. Trust nodes then verify the data integrity and security of the proof results from each proving child node. The trusted node retrieves the user-submitted file data and distributes the erasure-coded data fragments. Since the trusted node is trusted by both the data storage nodes and the user, data processing and distribution have a certain degree of security and reliability. Furthermore, erasure coding data fragmentation achieves a natural connection between content addressing and file fragmentation. Simultaneously, file fragmentation and encoding significantly improve data storage redundancy efficiency, increasing availability while reducing storage costs. This allows data storage nodes to self-prove that they have indeed stored specific content information of a file, with a certain degree of security and reliability during the verification process, while also improving data storage efficiency.

[0151] Optionally, the device further includes:

[0152] The result verification module is used to determine that the data integrity verification of each data storage node has passed if, after querying the proof verification results corresponding to each proof sub-node from the blockchain network according to a preset time period, the number of verified results is not less than a preset threshold.

[0153] Optionally, the device further includes:

[0154] The registration request acquisition module is used to acquire the node registration request of the proof child node, and to parse the node registration request to obtain the blockchain user address information of the proof child node.

[0155] The address information storage module is used to store the blockchain user address information of each proof sub-node.

[0156] Optionally, the device further includes:

[0157] The file data acquisition module is used to acquire file data submitted by the user and perform erasure coding fragmentation on the file data to obtain erasure coding data fragments.

[0158] The fragment identifier generation module is used to generate data fragment identifiers corresponding to erasure coding data fragments;

[0159] The node identifier generation module is used to generate challenge node identifiers based on the blockchain user address information;

[0160] The challenge information generation module is used to generate challenge information based on the data shard identifier and the challenge node identifier, and store the challenge information on the blockchain.

[0161] The decentralized data security storage device provided in the embodiments of the present invention can execute the decentralized data security storage method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0162] Example 6

[0163] Figure 6 A schematic diagram of an electronic device 60 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0164] like Figure 6As shown, the electronic device 60 includes at least one processor 61 and a memory, such as a read-only memory (ROM) 62 and a random access memory (RAM) 63, communicatively connected to the at least one processor 61. The memory stores computer programs executable by the at least one processor. The processor 61 can perform various appropriate actions and processes based on the computer program stored in the ROM 62 or loaded into the RAM 63 from storage unit 68. The RAM 63 may also store various programs and data required for the operation of the electronic device 60. The processor 61, ROM 62, and RAM 63 are interconnected via a bus 64. An input / output (I / O) interface 65 is also connected to the bus 64.

[0165] Multiple components in electronic device 60 are connected to I / O interface 65, including: input unit 66, such as keyboard, mouse, etc.; output unit 67, such as various types of monitors, speakers, etc.; storage unit 68, such as disk, optical disk, etc.; and communication unit 69, such as network card, modem, wireless transceiver, etc. Communication unit 69 allows electronic device 60 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0166] Processor 61 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 61 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 61 performs the various methods and processes described above, such as decentralized data security storage methods.

[0167] In some embodiments, the decentralized data security storage method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 68. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 60 via ROM 62 and / or communication unit 69. When the computer program is loaded into RAM 63 and executed by processor 61, one or more steps of the decentralized data security storage method described above may be performed. Alternatively, in other embodiments, processor 61 may be configured to perform the decentralized data security storage method by any other suitable means (e.g., by means of firmware).

[0168] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0169] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0170] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0171] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0172] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0173] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through a communication network. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and Virtual Private Servers (VPS) in terms of management difficulty and weak business scalability.

[0174] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0175] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A decentralized data security storage method, characterized in that, The proof child nodes applied under the data storage node include: The system queries challenge information from the blockchain network according to a preset time period, and determines whether to generate a challenge response proof by its own proof child node based on the challenge node identifier in the challenge information. If so, then according to the data fragment identifier in the challenge information, erasure coding data fragments are obtained from the IPFS sub-nodes under the data storage node; the erasure coding data fragments stored in the IPFS sub-nodes are obtained by the trusted node performing erasure coding on the file data submitted by the user; the trusted node stores several erasure coding data fragments obtained after performing erasure coding on the file data under each IPFS sub-node in the IPFS network; each IPFS sub-node stores different erasure coding data fragments. Based on the erasure coding data fragments and pre-acquired random numbers, a challenge response proof is generated; the random numbers are generated by the trusted node. The challenge response proof is stored on the blockchain so that the blockchain can generate proof verification results based on the challenge response proof. The trusted node on the blockchain obtains the proof verification results corresponding to each proof sub-node and performs data integrity verification on each data storage node based on each proof verification result.

2. The method according to claim 1, characterized in that, The step of generating a challenge response proof based on the erasure coding data fragments and pre-acquired random numbers includes: Obtain the first public hash value, and generate the second public hash value based on the erasure coding data fragment and the random number; The erasure coding data fragments are divided into blocks to obtain first private data, and the random number is divided into blocks to obtain second private data; Based on the first private data, the second private data, the first public hash value, and the second public hash value, generate a proof input file; Based on the preset proof generation function and the pre-generated circuit proof key, the proof input file is processed by circuit calculation to obtain the core proof file and the core public file. Generate a challenge response proof that includes the core proof file and the core public file.

3. The method according to claim 2, characterized in that, Before generating the challenge response proof based on the erasure coding data fragments and pre-acquired random numbers, the method further includes: Construct constraint circuits based on zero-knowledge proofs; The constraint circuit of the zero-knowledge proof is compiled into a zero-knowledge proof circuit template using a preset compilation algorithm, and the corresponding circuit proof key and circuit verification key are generated. The circuit proof key is stored in the proof sub-node, and the circuit verification key is embedded in the on-chain smart contract.

4. The method according to claim 3, characterized in that, The challenge response proof is stored on the blockchain so that the blockchain can generate proof verification results based on the challenge response proof, including: The challenge response proof is stored on the blockchain so that on-chain smart contracts can verify the challenge response proof based on the circuit verification key and generate a proof verification result.

5. The method according to claim 1, characterized in that, Before querying challenge information from the blockchain network according to a preset time period and determining whether a challenge response proof should be generated by its own proof child node based on the challenge node identifier in the challenge information, the method further includes: Generate a node registration request based on the blockchain user address information of its own child nodes; The node registration request is sent to the trusted node, so that the trusted node can generate a challenge node identifier for the corresponding proof child node based on the blockchain user address information in the node registration request.

6. A decentralized data security storage method, characterized in that, Applied to trusted nodes, including: The verification results of each proof sub-node are queried from the blockchain network according to a preset time period. If the number of verified results in each of the aforementioned proofs is less than a preset threshold, erasure coding data fragments are obtained from the IPFS sub-nodes under each data storage node. Based on the obtained erasure coding data fragments, target file data is synthesized. Then, erasure coding data fragments are generated again based on the target file data and stored in each IPFS sub-node. The corresponding proof sub-nodes then perform challenge response proofs.

7. The method according to claim 6, characterized in that, After querying the proof verification results corresponding to each proof sub-node in the blockchain network according to a preset time period, the method further includes: If the number of verified results in each of the aforementioned proofs is not less than a preset threshold, then the data integrity verification of each data storage node is determined to be successful.

8. The method according to claim 6, characterized in that, The method further includes: Obtain the node registration request of the proof child node, and parse the node registration request to obtain the blockchain user address information of the proof child node; Stores the blockchain user address information of each proof sub-node.

9. The method according to claim 8, characterized in that, The method further includes: Obtain the file data submitted by the user, and perform erasure coding fragmentation on the file data to obtain erasure coded data fragments; Generate data fragment identifiers corresponding to erasure-coded data fragments; A challenge node identifier is generated based on the blockchain user address information; Based on the data shard identifier and the challenge node identifier, challenge information is generated and stored on the blockchain.

10. A decentralized data security storage device, characterized in that, The proof sub-nodes configured under the data storage node include: The proof generation and judgment module is used to query challenge information from the blockchain network according to a preset time period, and determine whether to generate a challenge response proof by its own proof child node based on the challenge node identifier in the challenge information. The erasure coding data acquisition module is used to, if it is determined that the challenge response proof was generated by its own proof child node, retrieve erasure coding data fragments from the IPFS child nodes under the data storage node according to the data fragment identifier in the challenge information; the erasure coding data fragments stored in the IPFS child nodes are obtained by the trusted node performing erasure coding on the file data submitted by the user; the trusted node stores several erasure coding data fragments obtained after performing erasure coding on the file data under each IPFS child node in the IPFS network; each IPFS child node stores different erasure coding data fragments; The challenge proof generation module is used to generate a challenge response proof based on the erasure coding data fragments and pre-acquired random numbers; the random numbers are generated by the trusted node. The challenge proof on-chain module is used to store the challenge response proof on the chain so that the chain can generate proof verification results based on the challenge response proof, and the trusted node on the chain can obtain the proof verification results corresponding to each proof sub-node, and perform data integrity verification on each data storage node based on each proof verification result.

11. A decentralized data security storage device, characterized in that, Configured on trusted nodes, including: The verification result query module is used to query the verification results of each proof sub-node from the blockchain network according to a preset time period. The target file synthesis module is used to obtain erasure coding data fragments from the IPFS sub-nodes under each data storage node if the number of verified results in each proof verification result is less than a preset threshold. Then, it synthesizes target file data based on the obtained erasure coding data fragments, and stores the target file data into erasure coding data fragments again after generating them in the target file data. The fragments are then stored in each IPFS sub-node, and the corresponding proof sub-nodes perform challenge response proofs.

12. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the decentralized data security storage method according to any one of claims 1-5 and / or claims 6-9.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the decentralized data security storage method of any one of claims 1-5 and / or claims 6-9.

Images