A high-efficient provable blockchain data storage verification method, device and system

Abstract

The embodiment of the present specification relates to the technical field of block chain, especially to a kind of efficient provable block chain data storage verification method, device and system.The data providing node receives the verification request sent by data providing node, obtains original file block from data providing node randomly, generates challenge information, sends challenge information to data storage node;Data storage node obtains the storage file block corresponding to the original file block from the data stored in itself, generates the storage proof of the storage file block according to the content of the storage file block, sends the hash value of the storage file block and the storage proof to data verification node;Data verification node verifies hash value and storage proof respectively.The efficient provable block chain data storage method of the embodiment of the present specification discards the control of on-chain file hash or connection permission through on-chain smart contract, thereby reducing the security management risk and improving the security of data file.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of blockchain technology, and in particular to an efficient method, apparatus and system for storing and verifying provable blockchain data. Background Technology

[0002] As blockchain technology gradually sees large-scale application and the development trend of new Web3 technologies, new demands have arisen for the return of data ownership to users. How decentralized systems like blockchain can prove the authenticity of stored, provided, and used user data in open networks is a pressing issue. Currently, blockchains do not facilitate the rapid retrieval of execution history and are not convenient for verifying the authenticity of data storage.

[0003] Because data files stored on blockchain storage nodes may be scattered across different consortium participants, and real-time consistency verification is not performed through on-chain consensus, issues such as data deletion, disconnections, and hard drive failures may arise. Decentralized network node collaboration is costly, and it's difficult to promptly detect service anomalies or disconnections of storage nodes. Existing solutions involve sharing storage nodes across all consortium blockchain participants and achieving public verification between nodes by obtaining and downloading file links on-chain. However, this method relies heavily on fine-grained control of on-chain file hashes or connection permissions through smart contracts. This verification method is prone to security management risks in the open environment of a consortium blockchain, potentially leading to data privacy leaks.

[0004] There is an urgent need for an efficient and provable blockchain data storage method to address the security management risks and data privacy leaks associated with existing technologies where storage nodes are shared among consortium blockchain participants and public verification between storage nodes is achieved by obtaining file links and downloading them on-chain. Summary of the Invention

[0005] To address the problems in the prior art, this specification provides an efficient method, apparatus, and system for storing and verifying provable blockchain data. It ensures the consistency of on-chain data based on an on-chain distributed consensus mechanism, guarantees the authenticity of off-chain stored data, and introduces smart contracts to ensure that the processing flow of on-chain and off-chain interactive data is tamper-proof.

[0006] To solve any of the above-mentioned technical problems, the specific technical solutions of the embodiments in this specification are as follows:

[0007] On one hand, the embodiments of this specification provide an efficient method for storing and verifying provable blockchain data, executed by a data verification node, the method comprising:

[0008] The system receives a verification request sent by a data provider node. The verification request is used to verify whether the original file blocks of the data provider node are stored on the data storage node. The data provider node pre-divides the file into multiple original file blocks and stores the original file blocks on the data storage node.

[0009] The data providing node randomly obtains the original file block and generates challenge information based on the original file block;

[0010] The challenge information is sent to the data storage node, so that the data storage node can obtain the storage file block corresponding to the original file block in the challenge information from its own stored data, generate the storage proof of the storage file block according to the content of the storage file block, and send the hash value of the storage file block and the storage proof to the data verification node.

[0011] A first verification is performed based on the hash value and the corresponding original file block, and a second verification is performed based on the storage proof and the Merkle tree of storage proofs for all storage file blocks of the file that are stored in advance. After both the first and second verifications are passed, it is determined that the storage file block on the data storage node is the same as the original file block.

[0012] Furthermore, generating challenge information based on the original file block further includes:

[0013] Generate a random number corresponding to the original file block;

[0014] The original file block is concatenated with the random number to obtain the challenge information. The data storage node then retrieves the storage file block corresponding to the original file block in the challenge information from its own stored data. The hash value of the challenge information is then concatenated with the hash value of the storage file block to obtain the challenge response information, which is then sent to the data verification node.

[0015] Furthermore, the first verification based on the hash value and the corresponding original file block further includes:

[0016] The hash value of the stored file block is determined based on the hash value of the response information and the hash value of the challenge information;

[0017] Determine whether the hash value of the stored file block is the same as the hash value of the original file block;

[0018] If they are the same, the result of the first verification is passed.

[0019] Furthermore, the value of the leaf node of the storage proof Merkle tree is the storage proof of all storage file blocks of the file;

[0020] The second verification, based on the storage proof and the pre-stored Merkle tree of storage proofs for all storage file blocks of the file, further includes:

[0021] The calculated value of the corresponding parent node is calculated based on the received storage proof and the value of the leaf node corresponding to the received storage proof in the Merkle tree of the storage proof;

[0022] A second verification is performed based on the calculated value of the parent node and the actual value of the parent node in the stored proof Merkle tree.

[0023] Based on the same inventive concept, embodiments of this specification also provide an efficient method for storing and verifying provable blockchain data, executed by a data storage node, the method comprising:

[0024] The data verification node receives challenge information sent by the data verification node. The challenge information is generated by the data verification node after receiving a verification request sent by the data provider node, randomly obtaining an original file block from the data provider node, and based on the original file block. The verification request is used to verify whether the original file block of the data provider node is stored on the data storage node. The data provider node pre-divides the file into multiple original file blocks and stores the original file blocks on the data storage node.

[0025] Retrieve the storage file block corresponding to the original file block in the challenge information from the data stored within itself;

[0026] Generate a storage proof for the storage file block based on its contents;

[0027] The hash value of the stored file block and the storage proof are sent to the data verification node, so that the data verification node performs a first verification based on the hash value and the corresponding original file block, and a second verification based on the storage proof and the Merkle tree of storage proofs of all stored file blocks of the file in the pre-stored data storage node; after both the first verification and the second verification are passed, it is determined that the stored file block on the data storage node is the same as the original file block.

[0028] Furthermore, the challenge information is obtained by the data verification node concatenating the original file block with a generated random number;

[0029] After retrieving the storage file block corresponding to the original file block in the challenge information from its own stored data, the method further includes:

[0030] The hash value of the challenge information is concatenated with the hash value of the stored file block to obtain the challenge response information;

[0031] Sending the hash value of the stored file block and the storage proof to the data verification node also includes:

[0032] The challenge response information is sent to the data verification node, so that the data verification node determines the hash value of the stored file block based on the response information and the hash value of the challenge information, and determines whether the hash value of the stored file block is the same as the hash value of the original file block. If they are the same, the result of the first verification is passed.

[0033] Furthermore, the value of the leaf node of the storage proof Merkle tree is the storage proof of all storage file blocks of the file;

[0034] Generating a storage proof for a storage file block based on its contents further includes:

[0035] Based on the number of stored file blocks, the content of each stored file block, and its own public key, the formula m[i] = H(Kpub||K) is used. i The first storage proof set Gm = {m[0], m[1], m[2], ..., m[k1]} is generated by mod N, where m[i] represents the first storage proof of the i-th storage file block, H() represents the hash operation, Kpub represents the public key, and K i Let || represent the i-th storage file block, || represent the concatenation operation, mod represent the modulo operator, N represent the total number of original file blocks of the file, and k1 represent the number of storage file blocks of the stored file.

[0036] Sending the hash value of the stored file block and the storage proof to the data verification node further includes:

[0037] The hash value of the storage file block and the first storage proof set are sent to the data verification node, so that the data verification node calculates the calculated value of one or more parent nodes based on each first storage proof in the storage proof set and the value of the leaf node corresponding to each first storage proof in the storage proof Merkle tree, and performs a second verification based on the calculated value of each parent node and the actual value of each parent node in the storage proof Merkle tree.

[0038] Furthermore, the value of the leaf node of the storage proof Merkle tree is the storage proof of all storage file blocks of the file;

[0039] Generating a storage proof for a storage file block based on its contents further includes:

[0040] Based on the predetermined number of verification sub-file blocks, the content of each storage file block, its own public key, the hash value of the last block of the current blockchain, and the content of a storage file block determined by the consensus mechanism, the formula n[i]=m[H(Kpub||Z||K] is used. i ||s)modk1] Generate a second storage proof set Gn={n[0],n[1],n[2],...n[k2]}, where n[i] represents the second storage proof of the i-th storage file block, m represents the first storage proof, H() represents the hash operation, Kpub represents the public key, Z represents the hash value of the last block of the current blockchain, K i Let represent the i-th storage file block, || represent the concatenation operation, s represent the content of a storage file block determined by the consensus mechanism, mod represent the modulo operator, k2 represent the predetermined number of verification sub-file blocks, k1 represent the number of storage file blocks of the stored file, and k2 < k1;

[0041] Sending the hash value of the stored file block and the storage proof to the data verification node further includes:

[0042] The hash value of the storage file block and the second storage proof set are sent to the data verification node, so that the data verification node calculates the calculated value of one or more parent nodes based on each second storage proof in the storage proof set and the value of the leaf node corresponding to each second storage proof in the storage proof Merkle tree, and performs a second verification based on the calculated value of each parent node and the actual value of each parent node in the storage proof Merkle tree.

[0043] On the other hand, embodiments of this specification also provide an efficient storage and verification device for provable blockchain data, the device comprising:

[0044] The verification request receiving unit is used to receive a verification request sent by the data providing node. The verification request is used to verify whether the original file block of the data providing node is stored on the data storage node. The data providing node pre-divides the file into multiple original file blocks and stores the original file blocks on the data storage node.

[0045] The challenge information generation unit is used to randomly obtain the original file block from the data providing node and generate challenge information based on the original file block;

[0046] The challenge information sending unit is used to send the challenge information to the data storage node, so that the data storage node can obtain the storage file block corresponding to the original file block in the challenge information from its own stored data, generate the storage proof of the storage file block according to the content of the storage file block, and send the hash value of the storage file block and the storage proof to the data verification node.

[0047] The verification unit is configured to perform a first verification based on the hash value and the corresponding original file block, and a second verification based on the storage proof and the Merkle tree of storage proofs of all storage file blocks of the file stored in advance; after both the first and second verifications are passed, it is determined that the storage file block on the data storage node is the same as the original file block.

[0048] Based on the same inventive concept, embodiments of this specification also provide an efficient storage and verification device for provable blockchain data, the device comprising:

[0049] The challenge information receiving unit is used to receive challenge information sent by the data verification node. The challenge information is generated by the data verification node after receiving a verification request sent by the data provider node, randomly obtaining an original file block from the data provider node, and based on the original file block. The verification request is used to verify whether the original file block of the data provider node is stored on the data storage node. The data provider node pre-divides the file into multiple original file blocks and stores the original file blocks on the data storage node.

[0050] The storage file block acquisition unit is used to acquire the storage file block corresponding to the original file block in the challenge information from its own stored data;

[0051] A storage proof generation unit is used to generate a storage proof for the storage file block based on the content of the storage file block;

[0052] The verification information sending unit is used to send the hash value of the stored file block and the storage proof to the data verification node, so that the data verification node performs a first verification based on the hash value and the corresponding original file block, and performs a second verification based on the storage proof and the Merkle tree of storage proofs of all stored file blocks of the file that are stored in advance; after both the first verification and the second verification are passed, it is determined that the stored file block on the data storage node is the same as the original file block.

[0053] Based on the same inventive concept, embodiments of this specification also provide an efficient storage and verification system for provable blockchain data, including a data providing node, a data verification node, and a data storage node;

[0054] The data providing node pre-divides the file into multiple raw file blocks, stores the raw file blocks on the data storage node, and sends verification requests to the data providing node as needed;

[0055] The data providing node receives a verification request sent by the data providing node. The verification request is used to verify whether the original file block of the data providing node is stored on the data storage node.

[0056] The data providing node randomly obtains the original file block from the data providing node, generates challenge information based on the original file block, and sends the challenge information to the data storage node;

[0057] The data storage node retrieves the storage file block corresponding to the original file block in the challenge information from its own stored data, generates a storage proof of the storage file block based on the content of the storage file block, and sends the hash value of the storage file block and the storage proof to the data verification node.

[0058] The data verification node performs a first verification based on the hash value and the corresponding original file block, and a second verification based on the storage proof and the Merkle tree of storage proofs for all storage file blocks of the file stored in advance; after both the first and second verifications are passed, it is determined that the storage file block on the data storage node is the same as the original file block.

[0059] On the other hand, embodiments of this specification also provide a computer device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the above-described method.

[0060] On the other hand, embodiments of this specification also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0061] Finally, this specification also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described method.

[0062] Using the embodiments of this specification, the data verification node performs a first verification to determine whether the data storage node truly stores the original file block by comparing the hash value of the original file block of the data provider node with the hash value of the stored file block of the data storage node. If the first verification passes, it indicates that the hash value of the stored file block is the same as the hash value of the original file block. However, to prevent the data storage node from merely storing the hash value of the stored file block instead of the actual stored file block, the data storage node also generates a storage proof of the stored file block based on its content. The data verification node performs a second verification based on the storage proof and the Merkle tree of storage proofs of all stored file blocks of the pre-stored file. If the second verification passes, it indicates that the information related to the stored file block is consistent with the relevant information of the stored file block in the Merkle tree of the pre-stored storage proof on the data verification node. Therefore, if and only if both the first and second verifications pass, it is determined that the stored file block on the data storage node is the same as the original file block of the data provider node, indicating that the data storage node truly stores the file block of the data provider node's file. The efficient provable blockchain data storage method described in this specification eliminates the need to control on-chain file hashes or connection permissions through on-chain smart contracts, thereby reducing security management risks and improving the security of data files. Attached Figure Description

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

[0064] Figure 1 The diagram shown is a schematic representation of an implementation system for an efficient method for storing and verifying provable blockchain data, as described in this specification.

[0065] Figure 2 The diagram shown is a first flowchart of an embodiment of this specification of an efficient method for storing and verifying provable blockchain data.

[0066] Figure 3 The diagram shown is a second flowchart of an embodiment of this specification of an efficient method for storing and verifying provable blockchain data.

[0067] Figure 4 The diagram illustrates the steps for generating challenge information based on the original file block in an embodiment of this specification.

[0068] Figure 5 The diagram illustrates the steps of a data storage node generating challenge response information in another embodiment of this specification.

[0069] Figure 6 The diagram illustrates the steps of the first verification based on the hash value and the corresponding original file block in an embodiment of this specification.

[0070] Figure 7 The diagram illustrates the steps of the second verification performed in an embodiment of this specification based on the storage proof and the Merkle tree of storage proofs for all storage file blocks of the pre-stored file.

[0071] Figure 8 and Figure 9 The diagram shown is a structural schematic of an efficient storage and verification device for provable blockchain data according to an embodiment of this specification.

[0072] Figure 10 The diagram shown is a data flow diagram of an efficient storage and verification system for provable blockchain data in an embodiment of this specification.

[0073] Figure 11 The diagram shown is a structural schematic of the computer device in an embodiment of this specification.

[0074] [Explanation of Figure Markers]:

[0075] 101. Data providing node;

[0076] 102. Data storage node;

[0077] 103. Data verification node;

[0078] 801. Verification Request Receiving Unit;

[0079] 802. Challenge Information Generation Unit;

[0080] 803. Challenge Information Sending Unit;

[0081] 804, Verification Unit;

[0082] 901. Challenge Information Receiving Unit;

[0083] 902. Storage file block acquisition unit;

[0084] 903. Storage proof generation unit;

[0085] 904. Verification information sending unit;

[0086] 1102. Computer equipment;

[0087] 1104. Processing equipment;

[0088] 1106. Storage resources;

[0089] 1108. Drive mechanism;

[0090] 1110. Input / output module;

[0091] 1112. Input devices;

[0092] 1114. Output devices;

[0093] 1116. Presentation device;

[0094] 1118. Graphical User Interface;

[0095] 1120. Network interface;

[0096] 1122. Communication link;

[0097] 1124. Communication bus. Detailed Implementation

[0098] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the embodiments of this specification, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of the embodiments of this specification.

[0099] It should be noted that the terms "first," "second," etc., in the description, claims, and accompanying drawings of the embodiments herein 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 embodiments of the embodiments 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 non-exclusive inclusion; for example, a process, method, apparatus, product, or device that includes 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 devices.

[0100] It should be noted that the acquisition, storage, use, and processing of data in the technical solution of this application all comply with the relevant provisions of national laws and regulations.

[0101] like Figure 1The diagram illustrates an implementation system for an efficient and provable blockchain data storage and verification method according to an embodiment of this specification. The system includes a data provider node 101, a data storage node 102, and a data verification node 103. These nodes can be deployed in a blockchain network. The data provider node 101 corresponds to a data provider, who divides the file into blocks and stores these blocks in the data storage node 102. This embodiment of the blockchain supports on-chain and off-chain collaboration. Data in the data storage node 102 does not need to be stored on the blockchain; instead, it is stored locally on the data storage node. Verification is based on off-chain Merkle proofs and on-chain proofs. Only the final result needs to be uploaded to the blockchain, thereby improving both the security and feasibility of the blockchain network and its processing efficiency.

[0102] Off-chain decentralized storage in blockchain utilizes data storage nodes 102 distributed across a wide area network to provide storage space. Since these nodes may delete data, go offline, or experience hard drive failures, it is crucial to prevent objective or malicious actions by the blockchain's data storage nodes 102 and to promptly detect and recover any sporadic data loss. Therefore, an on-chain distributed consensus mechanism is needed to ensure the consistency of on-chain data and the authenticity of off-chain stored data. Furthermore, intelligent contracts should be introduced to ensure the immutability of data processing flows between on-chain and off-chain transactions.

[0103] It should be noted that, Figure 1 The example shown is merely one application environment provided by this disclosure. In practical applications, other application environments may also be included, and this specification does not impose any limitations.

[0104] Specifically, the embodiments of this specification provide an efficient method for storing and verifying provable blockchain data, wherein the data verification node verifies the hash value and storage proof of the stored file block in the data storage node. Figure 2 The diagram illustrates the first flow of an efficient and verifiable blockchain data storage and verification method according to an embodiment of this specification. The diagram depicts the process by which a data verification node verifies the authenticity of file blocks stored in a data storage node. The order of steps listed in the embodiment is merely one possible execution order among many and does not represent the only possible order. In actual system or device products, the methods shown in the embodiment or the accompanying drawings can be executed sequentially or in parallel. Specifically, as shown... Figure 2 As shown, the method can be executed by data verification node 103 and may include:

[0105] Step 201: Receive a verification request sent by the data provider node. The verification request is used to verify whether the original file block of the data provider node is stored on the data storage node. The data provider node pre-divides the file into multiple original file blocks and stores the original file blocks on the data storage node.

[0106] Step 202: Randomly obtain the original file block from the data providing node, and generate challenge information based on the original file block;

[0107] Step 203: Send the challenge information to the data storage node;

[0108] In this step, the data storage node retrieves the storage file block corresponding to the original file block in the challenge information from its own stored data, generates a storage proof of the storage file block based on the content of the storage file block, and sends the hash value of the storage file block and the storage proof to the data verification node.

[0109] Step 204: Perform a first verification based on the hash value and the corresponding original file block, and a second verification based on the storage proof and the Merkle tree of storage proofs for all storage file blocks of the file stored in advance; after both the first and second verifications are passed, determine that the storage file block on the data storage node is the same as the original file block.

[0110] Correspondingly, this specification also provides an efficient method for storing and verifying provable blockchain data, executed by the data storage node 102, such as... Figure 3 As shown, the method includes:

[0111] Step 301: Receive the challenge information sent by the data verification node;

[0112] In this step, the challenge information is generated by the data verification node after receiving a verification request from the data provider node, randomly obtaining an original file block from the data provider node, and generating the challenge information based on the original file block. The verification request is used to verify whether the original file block of the data provider node is stored on the data storage node. The data provider node pre-divides the file into multiple original file blocks and stores the original file blocks on the data storage node.

[0113] Step 302: Obtain the storage file block corresponding to the original file block in the challenge information from the data stored in the device itself;

[0114] Step 303: Generate a storage certificate for the storage file block based on its contents;

[0115] Step 304: Send the hash value of the storage file block and the storage proof to the data verification node.

[0116] In this step, the data verification node performs a first verification based on the hash value and the corresponding original file block, and a second verification based on the storage proof and the Merkle tree of storage proofs for all storage file blocks of the file stored in advance; after both the first and second verifications pass, it is determined that the storage file block on the data storage node is the same as the original file block.

[0117] Using the embodiments of this specification, the data verification node performs a first verification to determine whether the data storage node truly stores the original file block by comparing the hash value of the original file block of the data provider node with the hash value of the stored file block of the data storage node. If the first verification passes, it indicates that the hash value of the stored file block is the same as the hash value of the original file block. However, to prevent the data storage node from merely storing the hash value of the stored file block instead of the actual stored file block, the data storage node also generates a storage proof of the stored file block based on its content. The data verification node performs a second verification based on the storage proof and the Merkle tree of storage proofs of all stored file blocks of the pre-stored file. If the second verification passes, it indicates that the information related to the stored file block is consistent with the relevant information of the stored file block in the Merkle tree of the pre-stored storage proof on the data verification node. Therefore, if and only if both the first and second verifications pass, it is determined that the stored file block on the data storage node is the same as the original file block of the data provider node, indicating that the data storage node truly stores the file block of the data provider node's file.

[0118] The efficient provable blockchain data storage method described in this specification eliminates the need to control on-chain file hashes or connection permissions through on-chain smart contracts, thereby reducing security management risks and improving the security of data files.

[0119] In the embodiments described in this specification, the data providing node segments the original file into multiple original file blocks, and generates a Merkle tree of storage proofs for all original file blocks of the file based on the content of each original file block. The data providing node then sends the multiple original file blocks to multiple data storage nodes for storage, distributing the original file blocks of the file across multiple data storage nodes. Finally, the Merkle tree of storage proofs is sent to the data verification node.

[0120] Data storage nodes can provide file block query services to data users (which can be nodes on the blockchain or off-chain nodes), offering the file blocks of the file they store to the data users who need them. It should be noted that the processor performance of the data storage node can be superior to that of the data provider's processor, thus enabling the provision of file blocks to multiple data users.

[0121] When verifying whether a data storage node actually stores file blocks, the data provider node can randomly challenge one or more original file blocks through the data verification node. Specifically, the data provider node sends a verification request to the data verification node, which may include the number of the original file block to be verified. The verification request is used to verify whether the data storage node stores the corresponding numbered file block. Because the data provider node randomly challenges one or more original file blocks, the data storage node cannot predict which numbered file blocks will be verified. Therefore, the random verification will only pass if multiple file blocks of the file stored on the data storage node are identical to the corresponding original file blocks. Thus, if the data storage node passes the verification of the original file block with the specified number in the data provider node's verification request, it indicates that the data storage node has actually stored multiple file blocks of the file; otherwise, it is considered that the data storage node has not actually stored multiple file blocks of the file.

[0122] In the embodiments of this specification, because the data storage node needs to send the hash value of the stored file block to the data verification node, the data verification node needs to determine which original file block the received hash value corresponds to. Therefore, when sending the hash value to the data verification node, the data storage node needs to attach unique identification information such as the storage file block number. However, during the transmission of the hash value, it may be maliciously intercepted because the numbering structure of the file block is relatively simple and easily cracked by an interceptor. The interceptor can then modify the hash value and send it to the data verification node for verification, at which point the data verification node's verification of the hash value will be invalid. To prevent the hash value sent by the data storage node to the data verification node from being cracked by an interceptor, the embodiments of this specification increase the complexity of the storage file block numbering. Specifically, according to one embodiment of this specification, as follows... Figure 4 As shown, generating challenge information based on the original file block further includes:

[0123] Step 401: Generate a random number corresponding to the original file block;

[0124] Step 402: Concatenate the original file block with the random number to obtain the challenge information.

[0125] Correspondingly, such as Figure 5As shown, after the data storage node retrieves the storage file block corresponding to the original file block in the challenge information from its own stored data, the method further includes:

[0126] Step 501: Concatenate the hash value of the challenge information with the hash value of the stored file block to obtain the challenge response information;

[0127] Sending the hash value of the stored file block and the storage proof to the data verification node also includes:

[0128] Step 502: Send the challenge response information to the data verification node.

[0129] For example, suppose file F is divided into N blocks, s is any random value in the set {1,2,...,N}, and r is any random number. Then the challenge information is challenge=(F[s]||r), where challenge represents the challenge information, F[s] represents the s-th block of file F, and || represents concatenation.

[0130] Then the challenge information is sent to the data storage node, and the storage node can obtain the s value. If the data storage node has actually saved the s-th block, it can provide the correct hash value of the F[s] file block to the data verification node.

[0131] It also requires data storage nodes to generate challenge response information response=(h||πF[s]) based on the hash value of the F[s] file block, where h=H(challenge), H() represents hash operation, and πF[s] represents the hash value of the F[s] file block.

[0132] Then the data verification node performs a first verification based on the hash value and the corresponding original file block, specifically, as follows: Figure 6 As shown, it may include the following steps:

[0133] Step 601: Determine the hash value of the stored file block based on the hash value of the response information and the hash value of the challenge information;

[0134] Step 602: Determine whether the hash value of the stored file block is the same as the hash value of the original file block;

[0135] Step 603: If they are the same, the result of the first verification is passed.

[0136] After receiving the challenge response information, the data verification node can obtain the hash value of the F[s] file block based on the hash value h of the challenge information, and then compare it with the hash value of the original file block F[s]. If they are the same, the first verification is successful.

[0137] This specification can be understood as follows: the embodiment uses the hash value of the challenge information as the unique identifier of the stored file block. The challenge information is obtained by concatenating the original file block and a random number. The content and length of the original file block and the length of the random number cannot be cracked. The challenge response information is obtained by concatenating the hash value of the challenge information and the hash value of the stored file block. The content and length of the stored file block cannot be cracked either. Therefore, the challenge response information is in the form of an uncrackable hash value. Even if an interceptor intercepts the challenge response information, they cannot crack which part of the challenge response information belongs to the unique identifier of the file block, thus improving security.

[0138] Furthermore, since the challenge information is obtained by concatenating the original file block and the random number, the data storage node cannot know the length of the original file block and the length of the random number. Therefore, the data storage node cannot parse the original file block from the challenge information, and thus cannot use the original file block to construct the hash value of the stored file block to pass the verification.

[0139] It should be noted that the embodiments in this specification only challenge one or a few file blocks instead of directly challenging all file blocks of the file stored by the data storage node. This is an efficiency trade-off. If all file blocks of the file stored by the data storage node are challenged, the computational load of verification will be greatly increased and the verification efficiency will be reduced. If the randomly challenged file blocks F[s] are random enough, then s will be evenly distributed in the set {1,2,...N}, so that malicious file storage nodes cannot determine the specific challenge distribution.

[0140] According to one embodiment of this specification, the storage proof Merkle tree can be a simple binary tree structure, with one storage proof Merkle tree corresponding to each file. The leaf node values ​​of the storage proof Merkle tree represent the storage proofs corresponding to all file blocks of the file. When generating the storage proof Merkle tree, the actual values ​​of the parent nodes corresponding to the storage proofs of adjacent file blocks are calculated according to the file block order, where no two adjacent file blocks overlap. Then, the values ​​of the parent nodes corresponding to the values ​​of the two parent nodes are calculated, and so on, until the value of the root node is calculated.

[0141] like Figure 7 As shown, the second verification based on the storage proof and the Merkle tree of storage proofs for all storage file blocks of the pre-stored file further includes:

[0142] Step 701: Calculate the calculated value of the corresponding parent node based on the received storage proof and the value of the leaf node corresponding to the received storage proof in the Merkle tree of the storage proof;

[0143] Step 702: Perform a second verification based on the calculated value of the parent node and the actual value of the parent node in the stored proof Merkle tree.

[0144] In the embodiments described in this specification, after receiving a storage proof, the storage proof belonging to the same parent node as the received storage proof is determined in the storage proof Merkle tree. Then, the calculated value of the corresponding parent node is calculated based on the received storage proof and the storage proof belonging to the same parent node. If the calculated value of the parent node is the same as the actual value, it indicates that the received storage proof is the same as the storage proof of the original file block. Since the storage proof is calculated by the data storage node based on the content of the stored file block, it can prove that the content of the stored file block is the same as the content of the original file block. That is, it proves that the information of the stored file block is consistent with the relevant information of the stored file block in the storage proof Merkle tree pre-stored on the data verification node. This relevant information may include the public key of the data storage node and the content of the stored file block. This also prevents malicious data storage nodes that have stolen the correct stored file block from participating in off-chain decentralized storage.

[0145] Furthermore, the step of the data storage node generating storage proofs for storage file blocks may include:

[0146] Based on the number of stored file blocks, the content of each stored file block, and its own public key, the formula m[i] = H(Kpub||K i The first storage proof set Gm = {m[0], m[1], m[2], ..., m[k1]} is generated by mod N, where m[i] represents the first storage proof of the i-th storage file block, H() represents the hash operation, Kpub represents the public key, and K i Let || represent the i-th storage file block, || represent the concatenation operation, mod represent the modulo operator, N represent the total number of original file blocks of the file, and k1 represent the number of storage file blocks of the stored file.

[0147] Then the data storage node sends the hash value of the storage file block and the first storage proof set to the data verification node, so that the data verification node calculates the calculated value of one or more parent nodes based on each first storage proof in the storage proof set and the value of the leaf node corresponding to each first storage proof in the storage proof Merkle tree, and performs a second verification based on the calculated value of each parent node and the actual value of each parent node in the storage proof Merkle tree.

[0148] In the embodiments described in this specification, when the data storage node generates a storage certificate for the second verification, it can generate a storage certificate for all storage blocks of the file stored by the data storage node, and then send the storage certificate to the data verification node. Therefore, the security of the data storage node and the correctness of all storage blocks of the file stored by the data storage node can be ensured.

[0149] In the embodiments of this specification, the computational load required for the data storage node to generate the storage proof of all storage file blocks of the file may be large, and the computational load for the data verification node to verify may also be large. Therefore, according to some other embodiments of this specification, generating the storage proof of the storage file block based on the content of the storage file block further includes:

[0150] Based on the predetermined number of verification sub-file blocks, the content of each storage file block, its own public key, the hash value of the last block of the current blockchain, and the content of a storage file block determined by the consensus mechanism, the formula n[i]=m[H(Kpub||Z||K] is used. i ||s)modk1] Generate the second storage proof set Gn={n[0],n[1],n[2],...n[k2]}, where n[i] represents the second storage proof of the i-th storage file block, Z represents the hash value of the last block of the current blockchain, s represents the content of a storage file block determined by the consensus mechanism, k2 represents the predetermined number of verification sub-file blocks, k2<k1;

[0151] Sending the hash value of the stored file block and the storage proof to the data verification node further includes:

[0152] The hash value of the storage file block and the second storage proof set are sent to the data verification node, so that the data verification node calculates the calculated value of one or more parent nodes based on each second storage proof in the storage proof set and the value of the leaf node corresponding to each second storage proof in the storage proof Merkle tree, and performs a second verification based on the calculated value of each parent node and the actual value of each parent node in the storage proof Merkle tree.

[0153] In the embodiments of this specification, the data storage node performs consensus verification with other on-chain nodes on the blockchain to determine a storage file block s. Then, a second storage proof set is generated according to the predetermined number of verification sub-file blocks (i.e., the minimum number of storage file blocks that the data storage node is set to verify). The number of second storage proofs in the second storage proof set is much smaller than that in the first storage proof set, thereby reducing the workload of the data storage node and the data verification node.

[0154] Meanwhile, the generation of the second storage proof set by the data storage node involves a certain degree of randomness. Therefore, the verification can only be passed when the data storage node actually stores the file block, thus ensuring the accuracy of the verification.

[0155] Based on the same inventive concept, embodiments of this specification also provide an efficient storage and verification device for provable blockchain data, such as... Figure 8 As shown, it includes:

[0156] The verification request receiving unit 801 is used to receive a verification request sent by the data providing node. The verification request is used to verify whether the original file block of the data providing node is stored on the data storage node. The data providing node pre-divides the file into multiple original file blocks and stores the original file blocks on the data storage node.

[0157] The challenge information generation unit 802 is used to randomly obtain the original file block from the data providing node and generate challenge information based on the original file block;

[0158] The challenge information sending unit 803 is used to send the challenge information to the data storage node, so that the data storage node can obtain the storage file block corresponding to the original file block in the challenge information from its own stored data, generate the storage proof of the storage file block according to the content of the storage file block, and send the hash value of the storage file block and the storage proof to the data verification node.

[0159] Verification unit 804 is used to perform a first verification based on the hash value and the corresponding original file block, and a second verification based on the storage proof and the Merkle tree of storage proofs of all storage file blocks of the file stored in advance; after both the first verification and the second verification are passed, it is determined that the storage file block on the data storage node is the same as the original file block.

[0160] Correspondingly, embodiments of this specification also provide an efficient storage and verification device for provable blockchain data, such as... Figure 9 As shown, it includes:

[0161] The challenge information receiving unit 901 is used to receive challenge information sent by the data verification node. The challenge information is generated by the data verification node after receiving a verification request sent by the data provider node, randomly obtaining an original file block from the data provider node, and based on the original file block. The verification request is used to verify whether the original file block of the data provider node is stored on the data storage node. The data provider node pre-divides the file into multiple original file blocks and stores the original file blocks on the data storage node.

[0162] The storage file block acquisition unit 902 is used to acquire the storage file block corresponding to the original file block in the challenge information from its own stored data;

[0163] Storage proof generation unit 903 is used to generate a storage proof for the storage file block based on the content of the storage file block;

[0164] The verification information sending unit 904 is used to send the hash value of the stored file block and the storage proof to the data verification node, so that the data verification node performs a first verification based on the hash value and the corresponding original file block, and performs a second verification based on the storage proof and the Merkle tree of storage proofs of all stored file blocks of the file in a pre-stored manner; after both the first verification and the second verification are passed, it is determined that the stored file block on the data storage node is the same as the original file block.

[0165] Since the principle of the above-mentioned device in solving the problem is similar to that of the above-mentioned method, the implementation of the above-mentioned device can refer to the implementation of the above-mentioned method, and the repeated parts will not be described again.

[0166] This specification also provides an efficient storage and verification system for provable blockchain data, including a data providing node, a data verification node, and a data storage node. Figure 10 The diagram shown is a data flow diagram of an efficient storage and verification system for provable blockchain data in an embodiment of this specification, which may include the following steps:

[0167] Step 1001: The data providing node pre-divides the file into multiple raw file blocks;

[0168] Step 1002: Store the original file blocks on the data storage node;

[0169] Step 1003: Send a verification request to the data provider node as needed;

[0170] Step 1004: The data verification node receives the verification request sent by the data providing node;

[0171] In this step, the verification request is used to verify whether the original file blocks of the data providing node are stored on the data storage node;

[0172] Step 1005: The data verification node randomly obtains original file blocks from the data providing node;

[0173] Step 1006: The data verification node generates challenge information based on the original file blocks;

[0174] Step 1007: The data provider node sends the challenge information to the data storage node;

[0175] Step 1008: The data storage node retrieves the storage file block corresponding to the original file block in the challenge information from its own stored data;

[0176] Step 1009: The data storage node generates a storage certificate for the storage file block based on the content of the storage file block;

[0177] Step 1010: The data storage node sends the hash value of the stored file block and the storage proof to the data verification node;

[0178] Step 1011: The data verification node performs the first verification based on the hash value and the corresponding original file block;

[0179] Step 1012: The data verification node performs a second verification based on the storage proof and the Merkle tree of the storage proofs of all storage file blocks of the pre-stored file;

[0180] In this step, after the data verification node passes both the first and second verifications, it determines that the stored file block on the data storage node is the same as the original file block.

[0181] Step 1013: If both the first and second verifications pass, the data verification node will send the verification result back to the data providing node.

[0182] like Figure 11 The diagram illustrates the structure of a computer device according to an embodiment of this specification. The apparatus described in this specification can be the computer device in this embodiment, executing the methods described above. The computer device 1102 may include one or more processing devices 1104, such as one or more central processing units (CPUs), each of which can implement one or more hardware threads. The computer device 1102 may also include any storage resource 1106 for storing information of any kind, such as code, settings, data, etc. Without limitation, for example, the storage resource 1106 may include any one or more combinations of the following: any type of RAM, any type of ROM, flash memory, hard disk, optical disk, etc. More generally, any storage resource can use any technology to store information. Furthermore, any storage resource can provide volatile or non-volatile retention of information. Further, any storage resource may represent a fixed or removable component of the computer device 1102. In one case, when the processing device 1104 executes associated instructions stored in any storage resource or combination of storage resources, the computer device 1102 can perform any operation of the associated instructions. The computer device 1102 also includes one or more drive mechanisms 1108 for interacting with any storage resource, such as hard disk drive mechanism, optical disk drive mechanism, etc.

[0183] Computer device 1102 may also include an input / output module 1110 (I / O) for receiving various inputs (via input device 1112) and providing various outputs (via output device 1114). A specific output mechanism may include a presentation device 1116 and an associated graphical user interface (GUI) 1118. In other embodiments, the input / output module 1110 (I / O), input device 1112, and output device 1114 may be omitted, and the device may function solely as a computer device within a network. Computer device 1102 may also include one or more network interfaces 1120 for exchanging data with other devices via one or more communication links 1122. One or more communication buses 1124 couple the components described above together.

[0184] Communication link 1122 can be implemented in any way, such as via a local area network, a wide area network (e.g., the Internet), a point-to-point connection, or any combination thereof. Communication link 1122 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.

[0185] This specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0186] This specification also provides computer-readable instructions, wherein when a processor executes the instructions, the program therein causes the processor to perform the above-described method.

[0187] It should be understood that in the various embodiments of this specification, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this specification.

[0188] It should also be understood that, in the embodiments of this specification, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the embodiments of this specification, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0189] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this specification can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of the embodiments in this specification.

[0190] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0191] In the embodiments provided in this specification, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, or they may be electrical, mechanical, or other forms of connection.

[0192] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments described in this specification, depending on actual needs.

[0193] Furthermore, the functional units in the various embodiments of this specification can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0194] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this specification, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this specification. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0195] This specification describes the principles and implementation methods of the embodiments using specific examples. The above descriptions of the embodiments are only for the purpose of helping to understand the methods and core ideas of the embodiments in this specification. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the embodiments in this specification. Therefore, the content of this specification should not be construed as a limitation on the embodiments in this specification.

Claims

1. A method for storing and verifying efficient provable blockchain data, characterized in that, The method, executed by the data verification node, includes: The system receives a verification request sent by a data provider node. The verification request is used to verify whether the original file blocks of the data provider node are stored on the data storage node. The data provider node pre-divides the file into multiple original file blocks and stores the original file blocks on the data storage node. The data providing node randomly obtains the original file block and generates challenge information based on the original file block; The challenge information is sent to the data storage node, so that the data storage node can obtain the storage file block corresponding to the original file block in the challenge information from its own stored data, generate the storage proof of the storage file block according to the content of the storage file block, and send the hash value of the storage file block and the storage proof to the data verification node. A first verification is performed based on the hash value and the corresponding original file block, and a second verification is performed based on the storage proof and the Merkle tree of storage proofs for all storage file blocks of the file that are stored in advance; after both the first and second verifications are passed, it is determined that the storage file block on the data storage node is the same as the original file block; The value of the leaf node of the storage proof Merkle tree is the storage proof of all storage file blocks of the file; The step of generating a storage proof for the storage file block based on the content of the storage file block further includes: generating a second storage proof set based on a predetermined number of verification sub-file blocks, the content of each storage file block, its own public key, the hash value of the last block of the current blockchain, the content of a storage file block determined by the consensus mechanism, and a first storage proof, wherein the predetermined number of verification sub-file blocks is less than the number of storage file blocks of the stored file, and the first storage proof is generated based on the number of stored storage file blocks, the content of each storage file block, and its own public key; Sending the hash value of the storage file block and the storage proof to the data verification node further includes: sending the hash value of the storage file block and the second set of storage proofs to the data verification node, so that the data verification node calculates the calculated value of one or more parent nodes based on each second storage proof in the storage proof set and the value of the leaf node corresponding to each second storage proof in the storage proof Merkle tree, and performs a second verification based on the calculated value of each parent node and the actual value of each parent node in the storage proof Merkle tree.

2. The method according to claim 1, characterized in that, The challenge information generated based on the original file block further includes: Generate a random number corresponding to the original file block; The original file block is concatenated with the random number to obtain the challenge information. The data storage node then retrieves the storage file block corresponding to the original file block in the challenge information from its own stored data. The hash value of the challenge information is then concatenated with the hash value of the storage file block to obtain the challenge response information, which is then sent to the data verification node.

3. The method according to claim 2, characterized in that, The first verification based on the hash value and the corresponding original file block further includes: The hash value of the stored file block is determined based on the hash value of the response information and the hash value of the challenge information; Determine whether the hash value of the stored file block is the same as the hash value of the original file block; If they are the same, the result of the first verification is passed.

4. The method according to claim 1, characterized in that, The value of the leaf node of the storage proof Merkle tree is the storage proof of all storage file blocks of the file; The second verification, based on the storage proof and the pre-stored Merkle tree of storage proofs for all storage file blocks of the file, further includes: The calculated value of the corresponding parent node is calculated based on the received storage proof and the value of the leaf node corresponding to the received storage proof in the Merkle tree of the storage proof; A second verification is performed based on the calculated value of the parent node and the actual value of the parent node in the stored proof Merkle tree.

5. A method for storing and verifying efficient provable blockchain data, characterized in that, The method, executed by the data storage node, includes: The data verification node receives challenge information sent by the data verification node. The challenge information is generated by the data verification node after receiving a verification request sent by the data provider node, randomly obtaining an original file block from the data provider node, and based on the original file block. The verification request is used to verify whether the original file block of the data provider node is stored on the data storage node. The data provider node pre-divides the file into multiple original file blocks and stores the original file blocks on the data storage node. Retrieve the storage file block corresponding to the original file block in the challenge information from the data stored within itself; Generate a storage proof for the storage file block based on its contents; The hash value of the stored file block and the storage proof are sent to the data verification node, so that the data verification node performs a first verification based on the hash value and the corresponding original file block, and a second verification based on the storage proof and the Merkle tree of storage proofs of all stored file blocks of the file in the pre-stored data storage node; after both the first verification and the second verification are passed, it is determined that the stored file block on the data storage node is the same as the original file block. The value of the leaf node of the storage proof Merkle tree is the storage proof of all storage file blocks of the file; The step of generating a storage proof for the storage file block based on the content of the storage file block further includes: generating a second storage proof set based on a predetermined number of verification sub-file blocks, the content of each storage file block, its own public key, the hash value of the last block of the current blockchain, the content of a storage file block determined by the consensus mechanism, and a first storage proof, wherein the predetermined number of verification sub-file blocks is less than the number of storage file blocks of the stored file, and the first storage proof is generated based on the number of stored storage file blocks, the content of each storage file block, and its own public key; Sending the hash value of the storage file block and the storage proof to the data verification node further includes: sending the hash value of the storage file block and the second set of storage proofs to the data verification node, so that the data verification node calculates the calculated value of one or more parent nodes based on each second storage proof in the storage proof set and the value of the leaf node corresponding to each second storage proof in the storage proof Merkle tree, and performs a second verification based on the calculated value of each parent node and the actual value of each parent node in the storage proof Merkle tree.

6. The method according to claim 5, characterized in that, The challenge information is obtained by the data verification node by concatenating the original file block with a generated random number; After retrieving the storage file block corresponding to the original file block in the challenge information from its own stored data, the method further includes: The hash value of the challenge information is concatenated with the hash value of the stored file block to obtain the challenge response information; Sending the hash value of the stored file block and the storage proof to the data verification node also includes: The challenge response information is sent to the data verification node, so that the data verification node determines the hash value of the stored file block based on the response information and the hash value of the challenge information, and determines whether the hash value of the stored file block is the same as the hash value of the original file block. If they are the same, the result of the first verification is passed.

7. The method according to claim 5, characterized in that, Generating a storage proof for a storage file block based on its contents further includes: Based on the number of stored file blocks, the content of each stored file block, and its own public key, the formula m[i]=H(Kpub||K i The first storage proof set Gm={m[0],m[1],m[2],...m[k1]} is generated by mod N, where m[i] represents the first storage proof of the i-th storage file block, H() represents the hash operation, Kpub represents the public key, and K i Let || represent the i-th storage file block, || represent the concatenation operation, mod represent the modulo operator, N represent the total number of original file blocks of the file, and k1 represent the number of storage file blocks of the stored file. Sending the hash value of the stored file block and the storage proof to the data verification node further includes: The hash value of the storage file block and the first storage proof set are sent to the data verification node, so that the data verification node calculates the calculated value of one or more parent nodes based on each first storage proof in the storage proof set and the value of the leaf node corresponding to each first storage proof in the storage proof Merkle tree, and performs a second verification based on the calculated value of each parent node and the actual value of each parent node in the storage proof Merkle tree.

8. The method according to claim 5, characterized in that, The process of generating a second set of storage proofs based on a predetermined number of verification sub-file blocks, the content of each storage file block, its own public key, the hash value of the last block of the current blockchain, the content of a storage file block determined through the consensus mechanism, and the first storage proof includes: Based on the predetermined number of verification sub-file blocks, the content of each storage file block, its own public key, the hash value of the last block of the current blockchain, and the content of a storage file block determined by the consensus mechanism, the formula n[i]=m[H(Kpub||Z||K] is used. i ||s)modk1] Generate a second storage proof set Gn={n[0],n[1],n[2],...n[k2]}, where n[i] represents the second storage proof of the i-th storage file block, m represents the first storage proof, H() represents the hash operation, Kpub represents the public key, Z represents the hash value of the last block of the current blockchain, K i Let represent the i-th storage file block, || represent the concatenation operation, s represent the content of a storage file block determined by the consensus mechanism, mod represent the modulo operator, k2 represent the predetermined number of verification sub-file blocks, k1 represent the number of storage file blocks of the stored file, and k2 < k1.

9. A highly efficient storage and verification device for provable blockchain data, characterized in that, The device includes: The verification request receiving unit is used to receive a verification request sent by the data providing node. The verification request is used to verify whether the original file block of the data providing node is stored on the data storage node. The data providing node pre-divides the file into multiple original file blocks and stores the original file blocks on the data storage node. The challenge information generation unit is used to randomly obtain the original file block from the data providing node and generate challenge information based on the original file block; The challenge information sending unit is used to send the challenge information to the data storage node, so that the data storage node can obtain the storage file block corresponding to the original file block in the challenge information from its own stored data, generate the storage proof of the storage file block according to the content of the storage file block, and send the hash value of the storage file block and the storage proof to the data verification node. The verification unit is configured to perform a first verification based on the hash value and the corresponding original file block, and a second verification based on the storage proof and the Merkle tree of storage proofs of all storage file blocks of the file stored in advance; after both the first and second verifications are passed, it is determined that the storage file block on the data storage node is the same as the original file block; The value of the leaf node of the storage proof Merkle tree is the storage proof of all storage file blocks of the file; The step of generating a storage proof for the storage file block based on the content of the storage file block further includes: generating a second storage proof set based on a predetermined number of verification sub-file blocks, the content of each storage file block, its own public key, the hash value of the last block of the current blockchain, the content of a storage file block determined by the consensus mechanism, and a first storage proof, wherein the predetermined number of verification sub-file blocks is less than the number of storage file blocks of the stored file, and the first storage proof is generated based on the number of stored storage file blocks, the content of each storage file block, and its own public key; Sending the hash value of the storage file block and the storage proof to the data verification node further includes: sending the hash value of the storage file block and the second set of storage proofs to the data verification node, so that the data verification node calculates the calculated value of one or more parent nodes based on each second storage proof in the storage proof set and the value of the leaf node corresponding to each second storage proof in the storage proof Merkle tree, and performs a second verification based on the calculated value of each parent node and the actual value of each parent node in the storage proof Merkle tree.

10. A highly efficient storage and verification device for provable blockchain data, characterized in that, The device includes: The challenge information receiving unit is used to receive challenge information sent by the data verification node. The challenge information is generated by the data verification node after receiving a verification request sent by the data provider node, randomly obtaining an original file block from the data provider node, and based on the original file block. The verification request is used to verify whether the original file block of the data provider node is stored on the data storage node. The data provider node pre-divides the file into multiple original file blocks and stores the original file blocks on the data storage node. The storage file block acquisition unit is used to acquire the storage file block corresponding to the original file block in the challenge information from its own stored data; A storage proof generation unit is used to generate a storage proof for the storage file block based on the content of the storage file block; The verification information sending unit is used to send the hash value of the stored file block and the storage proof to the data verification node, so that the data verification node performs a first verification based on the hash value and the corresponding original file block, and performs a second verification based on the storage proof and the Merkle tree of storage proofs of all stored file blocks of the file in a pre-stored manner; after both the first verification and the second verification are passed, it is determined that the stored file block on the data storage node is the same as the original file block; The value of the leaf node of the storage proof Merkle tree is the storage proof of all storage file blocks of the file; The step of generating a storage proof for the storage file block based on the content of the storage file block further includes: generating a second storage proof set based on a predetermined number of verification sub-file blocks, the content of each storage file block, its own public key, the hash value of the last block of the current blockchain, the content of a storage file block determined by the consensus mechanism, and a first storage proof, wherein the predetermined number of verification sub-file blocks is less than the number of storage file blocks of the stored file, and the first storage proof is generated based on the number of stored storage file blocks, the content of each storage file block, and its own public key; Sending the hash value of the storage file block and the storage proof to the data verification node further includes: sending the hash value of the storage file block and the second set of storage proofs to the data verification node, so that the data verification node calculates the calculated value of one or more parent nodes based on each second storage proof in the storage proof set and the value of the leaf node corresponding to each second storage proof in the storage proof Merkle tree, and performs a second verification based on the calculated value of each parent node and the actual value of each parent node in the storage proof Merkle tree.

11. A highly efficient storage and verification system for provable blockchain data, characterized in that, This includes data providing nodes, data verification nodes, and data storage nodes; The data providing node pre-divides the file into multiple raw file blocks, stores the raw file blocks on the data storage node, and sends verification requests to the data providing node as needed; The data verification node receives a verification request sent by the data provider node. The verification request is used to verify whether the original file block of the data provider node is stored on the data storage node. The data verification node randomly obtains the original file block from the data providing node, generates challenge information based on the original file block, and sends the challenge information to the data storage node; The data storage node retrieves the storage file block corresponding to the original file block in the challenge information from its own stored data, generates a storage proof of the storage file block based on the content of the storage file block, and sends the hash value of the storage file block and the storage proof to the data verification node. The data verification node performs a first verification based on the hash value and the corresponding original file block, and a second verification based on the storage proof and the Merkle tree of storage proofs for all storage file blocks of the file stored in advance; after both the first and second verifications are passed, it is determined that the storage file block on the data storage node is the same as the original file block; The value of the leaf node of the storage proof Merkle tree is the storage proof of all storage file blocks of the file; The step of generating a storage proof for the storage file block based on the content of the storage file block further includes: generating a second storage proof set based on a predetermined number of verification sub-file blocks, the content of each storage file block, its own public key, the hash value of the last block of the current blockchain, the content of a storage file block determined by the consensus mechanism, and a first storage proof, wherein the predetermined number of verification sub-file blocks is less than the number of storage file blocks of the stored file, and the first storage proof is generated based on the number of stored storage file blocks, the content of each storage file block, and its own public key; Sending the hash value of the storage file block and the storage proof to the data verification node further includes: sending the hash value of the storage file block and the second set of storage proofs to the data verification node, so that the data verification node calculates the calculated value of one or more parent nodes based on each second storage proof in the storage proof set and the value of the leaf node corresponding to each second storage proof in the storage proof Merkle tree, and performs a second verification based on the calculated value of each parent node and the actual value of each parent node in the storage proof Merkle tree.

12. A computer device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 8.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

14. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

Images