A Distributed Storage Challenge Approach

Abstract

The present invention discloses a distributed storage challenge method, which includes four stages, namely storage preparation, storage proof, challenge notarization and arbitration; the storage preparation stage includes the following steps: the verifier divides the original data into blocks to calculate the Merkle tree, and then sends the Merkle tree root to the notary, and sends the original data to the service party at the same time; the service party divides the original data provided by the verifier into blocks to calculate the Merkle tree, and then sends the Merkle tree root to the notary; the notary party compares the Merkle tree roots submitted by the verifier and the service party, confirms that the Merkle tree root submitted by the service party is consistent with that submitted by the verifier, confirms that the Merkle tree root is valid, etc. The present invention realizes the steps of checking whether the service party has stored the verifier's file when the verifier and the service party are not trusted, and confirming whether the verifier has submitted real and valid data when initiating the storage challenge, and has the advantages of high security and high credibility of verification results.

Description

Technical Field

[0001] The present invention relates to the field of data storage challenge methods, and in particular to a distributed storage challenge method. Background Art

[0002] At present, with the development of digitalization, massive data has put forward new requirements for storage. Distributed storage technology has emerged in the market, and more and more users are choosing distributed storage. At this time, a problem arises: how to ensure that the service provider has stored the verifier's files completely. The traditional data content verification method is to determine whether the file is complete by comparing the file hash value, but the verification result is only reliable if both the verifier and the service provider are trustworthy. However, the verifier and service provider of distributed storage are not trustworthy. Therefore, when the verifier initiates a storage challenge in order to verify whether the service provider has truly stored the complete file, a method is needed to prove that neither party has done anything malicious and that the file does exist in its entirety. Summary of the invention

[0003] In view of this, the present invention proposes a distributed storage challenge method.

[0004] The technical solution provided by the present invention is:

[0005] A distributed storage challenge method, which includes four stages: storage preparation, storage proof, challenge notarization and arbitration;

[0006] The storage preparation stage includes the following steps:

[0007] 1.1 The verifier divides the original data into blocks and calculates the Merkle tree, then sends the Merkle tree root to the notary and sends the original data to the service provider;

[0008] 1.2 The service provider calculates the Merkle tree in blocks based on the original data provided by the verifier, and then sends the root of the Merkle tree to the notary;

[0009] 1.3 The notary compares the Merkle tree roots submitted by the verifier and the service provider, confirms that the Merkle tree root submitted by the service provider is consistent with that submitted by the verifier, and confirms that the Merkle tree root is valid; if they are inconsistent, the storage preparation is terminated;

[0010] The storage proof phase includes the following steps:

[0011] 2.1 The verifier initiates a random storage challenge: randomly extracts a data block and sends a random number and ID to the service provider;

[0012] 2.2 The service provider receives the storage challenge from the verifier and needs to respond according to the challenge requirements within a limited time. The calculation formula is: hash(Block(H,ID)+random number);

[0013] 2.3 The verifier receives the response from the service provider and verifies the signature of the challenge. If the verification is successful, the response from the service provider is deemed valid. If the verification fails, the response from the service provider is deemed invalid and the verifier can initiate a challenge notarization.

[0014] 2.4 If the service provider fails to send a response to the verifier within the specified time or refuses to respond, the verifier may initiate a challenge notarization;

[0015] The challenge notarization phase includes the following steps:

[0016] 3.1 The verifier initiates a random storage challenge: randomly extract a data block, add the current timestamp, then sign the entire block and send it to the notary;

[0017] 3.2 After the verifier submits a challenge to the notary, the service provider must respond according to the challenge requirements within a limited time. The calculation formula is: hash(Block(H,ID)+random number);

[0018] 3.3 The notary receives the response from the service provider and verifies the signature challenged by the verifier. If the verification is successful, the response from the service provider is deemed valid; if the verification fails, the response from the service provider is deemed invalid.

[0019] 3.4 If the service provider fails to send a response to the notary within the specified time or refuses to respond, the service provider’s response will be deemed invalid;

[0020] 3.5 If the service provider believes that the challenge from the verifier is invalid, it may initiate arbitration against the notary regarding the challenge;

[0021] The arbitration phase includes the following steps:

[0022] 4.1 After the service provider submits arbitration to the notary, the verifier shall submit the original data of the specified data block and the corresponding pruned Merkle tree to the notary within the specified time;

[0023] 4.2 If the Verifier fails to submit the challenge proof within the specified time, the verification challenge will be deemed invalid, indicating that the Verifier has breached the contract;

[0024] 4.3 The notary verifies that the original Merkle tree root is consistent with the pruned Merkle tree root submitted by the verifier. If they are inconsistent, the challenge of the verifier is invalid, indicating that the verifier has breached the contract.

[0025] 4.4 The notary verifies the pruned Merkle tree provided by the verifier; if they are inconsistent, the challenge of the verifier is invalid, indicating that the verifier has breached the contract;

[0026] 4.5 The notary calculates the hash of the specified original data block based on the specified original data block provided by the verifier to confirm whether it is consistent with the hash of the corresponding leaf node in the pruned Merkle tree; if not, it proves that the challenge of the verifier is invalid, indicating that the verifier has breached the contract;

[0027] 4.6 The notary verifies the signature provided by the verifier; if the results are consistent, it proves that the challenge of the verifier is valid, indicating that the response of the service provider is invalid; if the comparison results are inconsistent, it proves that the challenge of the verifier is invalid, indicating that the verifier has breached the contract.

[0028] Furthermore, the calculation formula in step 3.1 is: hash(Block(H,ID)+random number), and the random number and ID are sent at the same time.

[0029] Furthermore, the calculation formula in step 3.2 is: hash(Block(H,ID)+random number).

[0030] Furthermore, the four stages of storage preparation, storage proof, challenge notarization and arbitration include a verifier, a service provider and a notary, and the notary is an authoritative organization or a blockchain smart contract.

[0031] The advantages of the present invention compared with the prior art are:

[0032] The present invention can check whether the service party has stored the file of the verifier when the verifier and the service party are untrustworthy, and confirm whether the verifier has submitted authentic and valid data when initiating a storage challenge, and has the advantages of high security and high credibility of verification results. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 A flowchart of the storage preparation phase of the present invention;

[0034] Figure 2 A flowchart of the storage proof phase of the present invention;

[0035] Figure 3 A flowchart of the notarization phase of the challenge for the present invention;

[0036] Figure 4 FIG. 1 is a flow chart of the arbitration stage of the present invention. DETAILED DESCRIPTION

[0037] A distributed storage challenge method, which includes four stages: storage preparation, storage proof, challenge notarization and arbitration;

[0038] The storage preparation stage includes the following steps:

[0039] 1.1 The verifier divides the original data into blocks and calculates the Merkle tree, then sends the Merkle tree root to the notary and sends the original data to the service provider;

[0040] 1.2 The service provider calculates the Merkle tree in blocks based on the original data provided by the verifier, and then sends the root of the Merkle tree to the notary;

[0041] 1.3 The notary compares the Merkle tree roots submitted by the verifier and the service provider, confirms that the Merkle tree root submitted by the service provider is consistent with that submitted by the verifier, and confirms that the Merkle tree root is valid; if they are inconsistent, the storage preparation is terminated;

[0042] The storage proof phase includes the following steps:

[0043] 2.1 The verifier initiates a random storage challenge: randomly extracts a data block and sends a random number and ID to the service provider;

[0044] 2.2 The service provider receives the storage challenge from the verifier and needs to respond according to the challenge requirements within a limited time. The calculation formula is: hash(Block(H,ID)+random number);

[0045] 2.3 The verifier receives the response from the service provider and verifies the signature of the challenge. If the verification is successful, the response from the service provider is deemed valid. If the verification fails, the response from the service provider is deemed invalid and the verifier can initiate a challenge notarization.

[0046] 2.4 If the service provider fails to send a response to the verifier within the specified time or refuses to respond, the verifier may initiate a challenge notarization;

[0047] The challenge notarization phase includes the following steps:

[0048] 3.1 The verifier initiates a random storage challenge: randomly extract a data block, add the current timestamp, then sign the entire block and send it to the notary;

[0049] 3.2 After the verifier submits a challenge to the notary, the service provider must respond according to the challenge requirements within a limited time. The calculation formula is: hash(Block(H,ID)+random number);

[0050] 3.3 The notary receives the response from the service provider and verifies the signature challenged by the verifier. If the verification is successful, the response from the service provider is deemed valid; if the verification fails, the response from the service provider is deemed invalid.

[0051] 3.4 If the service provider fails to send a response to the notary within the specified time or refuses to respond, the service provider’s response will be deemed invalid;

[0052] 3.5 If the service provider believes that the challenge from the verifier is invalid, it may initiate arbitration against the notary regarding the challenge;

[0053] The arbitration phase includes the following steps:

[0054] 4.1 After the service provider submits arbitration to the notary, the verifier shall submit the original data of the specified data block and the corresponding pruned Merkle tree to the notary within the specified time;

[0055] 4.2 If the Verifier fails to submit the challenge proof within the specified time, the verification challenge will be deemed invalid, indicating that the Verifier has breached the contract;

[0056] 4.3 The notary verifies that the original Merkle tree root is consistent with the pruned Merkle tree root submitted by the verifier. If they are inconsistent, the challenge of the verifier is invalid, indicating that the verifier has breached the contract.

[0057] 4.4 The notary verifies the pruned Merkle tree provided by the verifier; if they are inconsistent, the challenge of the verifier is invalid, indicating that the verifier has breached the contract;

[0058] 4.5 The notary calculates the hash of the specified original data block based on the specified original data block provided by the verifier to confirm whether it is consistent with the hash of the corresponding leaf node in the pruned Merkle tree; if not, it proves that the challenge of the verifier is invalid, indicating that the verifier has breached the contract;

[0059] 4.6 The notary verifies the signature provided by the verifier; if the results are consistent, it proves that the challenge of the verifier is valid, indicating that the response of the service provider is invalid; if the comparison results are inconsistent, it proves that the challenge of the verifier is invalid, indicating that the verifier has breached the contract.

[0060] The calculation formula in step 3.1 is: hash(Block(H,ID)+random number), and the random number and ID are sent at the same time.

[0061] The calculation formula in step 3.2 is: hash(Block(H,ID)+random number).

[0062] The four stages of storage preparation, storage proof, challenge notarization and arbitration include a verifier, a service provider and a notary, and the notary is an authoritative organization or a blockchain smart contract.

[0063] The symbols involved in the above content are as follows: hash: hash; Block: block; H: original data; ID: data block number; sign: signature.

[0064] The present invention and its embodiments are described above, and such description is not restrictive. The drawings show only one embodiment of the present invention, and the actual structure is not limited thereto. In short, if ordinary technicians in the field are inspired by it, without departing from the purpose of the invention, they can design a structure and embodiment similar to the technical solution without creativity, which should belong to the protection scope of the present invention.

Claims

1. A distributed storage challenge method, It is characterized in that Specifically, it includes four stages: storage preparation, storage proof, challenge notarization and arbitration; The storage preparation stage includes the following steps: 1.1 The verifier divides the original data into blocks and calculates the Merkle tree, then sends the Merkle tree root to the notary and sends the original data to the service provider; 1.2 The service provider calculates the Merkle tree in blocks based on the original data provided by the verifier, and then sends the root of the Merkle tree to the notary; 1.3 The notary compares the Merkle tree roots submitted by the verifier and the service provider, confirms that the Merkle tree root submitted by the service provider is consistent with that submitted by the verifier, and confirms that the Merkle tree root is valid; if they are inconsistent, the storage preparation is terminated; The storage proof phase includes the following steps: 2.1 The verifier initiates a random storage challenge: randomly extracts a data block and sends a random number and ID to the service provider; 2.2 The service provider receives the storage challenge from the verifier and needs to respond according to the challenge requirements within a limited time. The calculation formula is: hash(Block(H,ID)+random number); 2.3 The verifier receives the response from the service provider and verifies the signature of the challenge. If the verification is successful, the response from the service provider is deemed valid. If the verification fails, the response from the service provider is deemed invalid and the verifier can initiate a challenge notarization. 2.4 If the service provider fails to send a response to the verifier within the specified time or refuses to respond, the verifier may initiate a challenge notarization; The challenge notarization phase includes the following steps: 3.1 The verifier initiates a random storage challenge: randomly extract a data block, add the current timestamp, then sign the entire block and send it to the notary; 3.2 After the verifier submits a challenge to the notary, the service provider must respond according to the challenge requirements within a limited time. The calculation formula is: hash(Block(H,ID)+random number); 3.3 The notary receives the response from the service provider and verifies the signature challenged by the verifier. If the verification is successful, the response from the service provider is deemed valid; if the verification fails, the response from the service provider is deemed invalid. 3.4 If the service provider fails to send a response to the notary within the specified time or refuses to respond, the service provider’s response will be deemed invalid; 3.5 If the service provider believes that the challenge from the verifier is invalid, it may initiate arbitration against the notary regarding the challenge; The arbitration phase includes the following steps: 4.1 After the service provider submits arbitration to the notary, the verifier shall submit the original data of the specified data block and the corresponding pruned Merkle tree to the notary within the specified time; 4.2 If the Verifier fails to submit the challenge proof within the specified time, the verification challenge will be deemed invalid, indicating that the Verifier has breached the contract; 4.3 The notary verifies that the original Merkle tree root is consistent with the pruned Merkle tree root submitted by the verifier. If they are inconsistent, the challenge of the verifier is invalid, indicating that the verifier has breached the contract. 4.4 The notary verifies the pruned Merkle tree provided by the verifier; if they are inconsistent, the challenge of the verifier is invalid, indicating that the verifier has breached the contract; 4.5 The notary calculates the hash of the specified original data block based on the specified original data block provided by the verifier to confirm whether it is consistent with the hash of the corresponding leaf node in the pruned Merkle tree; if not, it proves that the challenge of the verifier is invalid, indicating that the verifier has breached the contract; 4.6 The notary verifies the signature provided by the verifier; if the results are consistent, it proves that the challenge of the verifier is valid, indicating that the response of the service provider is invalid; if the comparison results are inconsistent, it proves that the challenge of the verifier is invalid, indicating that the verifier has breached the contract.

2. A distributed storage challenge method according to claim 1, It is characterized in that The calculation formula in step 3.1 is: hash(Block(H,ID)+random number), and the random number and ID are sent at the same time.

3. A distributed storage challenge method according to claim 1, It is characterized in that The calculation formula in step 3.2 is: hash(Block(H,ID)+random number).

4. A distributed storage challenge method according to claim 1, It is characterized in that The four stages of storage preparation, storage proof, challenge notarization and arbitration include a verifier, a service provider and a notary, and the notary is an authoritative organization or a blockchain smart contract.

Images