The significant improvement of DMC decentralized storage lies in transaction matching. However, its improvement in storage technology essentially penetrates every link of the storage process. DMC advocates real storage and aspires to build a benign decentralized storage trading market, while real storage requires the verification of blockchain-based smart contracts. After DMC users reach a trading contract, they can transmit the storage data point to point at this stage, while concurrently initiating a storage challenge to miners at any time to verify whether they possess the real storage capacity. A smart contract of storage challenge is completed in four stages, through the division of roles among the verifier, the service provider, and the notary.
Stage 1: Storage Preparation
1. The verifier partitions the original data into blocks, calculates the Merkle Tree, and then sends the Merkle Root to the notary. At the same time, it also sends the original data to the service provider. Compared with the case of the storage challenge encapsulated by Filecoin, miners need to submit a Filecoin encapsulation certificate and the Merkle Root. DMC can effectively reduce the link time.
2. The service provider calculates the Merkel Tree block by block according to the original data provided by the verifier, and then sends the Merkel Root to the notary;
3. The notary compares the Merkel Root submitted by the verifier with the Merkel Root submitted by the service provider to confirm that they are consistent, in which case, the Merkel Root can be confirmed to be valid; otherwise, the storage preparation will be terminated.
Stage 2: Storage Proof
1. The verifier initiates a random storage challenge: The verifier can randomly extract a data block, and send a random number and ID to the service provider;
2. After receiving the storage challenge sent by the verifier, the service provider needs to respond within the specified time limit according to the requirements of the challenge. The calculation formula is: hash (Block (H, ID) + random number);
3. After receiving the response from the service provider, the verifier verifies the challenged signature. If the verification is successful, the response from the service provider will be deemed as valid; if the verification fails, the response from the service provider will be deemed as invalid, in which case, the verifier may initiate a notarization challenge;
4. If the service provider fails to send a response to the verifier within the specified time limit or refuses to respond, the verifier may initiate a notarization challenge.
Stage 3: Notarization Challenge
1. The verifier initiates a random storage challenge: The verifier can randomly extract a data block, add the current time stamp to it, sign it as a whole and then send it to the notary. The calculation formula is: Sign (hash (Block (H, ID) + random number)), and the verifier needs to send a random number and ID at the same time;
2. After the verifier initiates a notarization challenge to the notary, the service provider needs to respond within the specified time limit according to the requirements of the challenge. The calculation formula is: hash (Block (H, ID) + random number);
3. After receiving the response from the service provider, the notary verifies the signature challenged by the verifier. If the verification is successful, it will be deemed that the response from the service provider is valid; if the verification fails, it will be deemed that the response from the service provider is invalid;
4. If the service provider fails to send a response to the notary within the specified time limit or refuses to respond, it will be deemed that the response of the service provider is invalid;
5. If the service provider believes that the challenge of the verifier is invalid, it may initiate an application for arbitration with the notary against this challenge.
Stage 4: Arbitration
1. After the service provider lodges an application for arbitration to the notary, the verifier needs to submit the original data of the specified data block and the corresponding pruned Merkel Tree to the notary within the specified time;
2. If the verifier fails to submit a challenge certificate within the specified time, the verification challenge will be deemed as invalid, which indicates that the verifier is in breach of contract;
3. The notary verifies that the original Merkel Root is consistent with the pruned Merkel Root submitted by the verifier. In case of inconsistency, it proves that the challenge of the verifier is invalid, which indicates that the verifier is in breach of contract;
4. The notary verifies the pruned Merkel Tree provided by the verifier. In case of inconsistency, it proves that the challenge of the verifier is invalid, which indicates that the verifier is in breach of contract;
5. The notary calculates the hash of the specified original data block according to the specified original data block provided by the verifier, and confirms whether it is consistent with the hash of the corresponding leaf node in the pruned Merkel Tree. In case of inconsistency, it proves that the challenge of the verifier is invalid, which indicates that the verifier is in breach of contract;
6. The notary checks the signature provided by the verifier. If the results are consistent, it proves that the challenge of the verifier is valid, which indicates 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, which indicates that the verifier is in breach of contract.
Fairness and justice are guaranteed across all the links of the DMC decentralized storage challenge. The protection of property and data makes users feel more at ease, while false transactions are punished and arbitration purifies the trading environment. A rigorous smart contract of storage challenge is adopted to spur the growth of real storage supply capacity, and incentivizes the harmonious development of a healthy ecosystem for DMC and even the whole decentralized storage trading market.