Storage Certification Mechanism
Storage nodes may damage user data due to sudden system failures, benefits collision, or other reasons. In this case, how can users ensure data integrity? CESS innovatively designs the proof of data reduplication and recovery mechanism (PoDR2), to regularly and efficiently verify data integrity in the network, and timely make adjustments to recover the data when damaged. The data always have a few backup copies, which greatly increases the security and availability of user data.
PoDR² The storage certification procedure is shown in figure 1.
After receiving the data object, the scheduler preprocesses the data, including slicing, replication (copy), marking (TEE environment processing), etc., and outputs several data segments. Finally, each data segment is randomly distributed to each storage miner.
The storage miner checks whether the segment information of the received data matches and stores the data locally if matching.
The blockchain network enters the challenge verification period from time to time. During the period, the network will generate random challenge information, and randomly designate several storage miners as the prover in the current period, who need to submit proof of the integrity of all local data segments to the network.
As the prover in this round, the storage miner obtains the challenge information from the chain, quickly generates the certificate, and submits it on the chain.
Anyone can verify the correctness of the submitted proofs. CESS uses the blockchain network as the verifier, responsible for verifying the proofs submitted by the storage miners.
Verification failures can be divided into the following two categories: 1. If the failed one is an idle proof, the blockchain network will cancel the idle data segment reward of this node for this round; 2. If the failed one is on service proof, it will open a time-limited error identification channel for the storage miner.
The storage miner needs to separately calculate the proof information for the data segment in service through the error identification channel and submit it to the chain. The blockchain network will verify the results (identify the unverified and failed data segments) and update the storage pool status of the corresponding storage miner. Alternatively, the storage miner can directly delete the unverified and failed data segments in the challenge period.
At the end of the challenge verification period, the storage miners with failed verification data segments need to be punished. At the same time, the blockchain network needs to issue a "repair deal" for the failed service data segment.
Any scheduler can claim a "repair deal", and each deal can only be claimed by one scheduling node at one time. After claiming the "repair deal", the scheduling node shall be responsible for repairing the corresponding data segment, and completing a "repair deal" will increase its "workload", and thus obtain more shares in each round of reward liquidation. The data segment repairing process is described as follows: 1) On the chain, the scheduling node obtains the storage miner information for the sibling data segment corresponding to the repairing data segment; 2) Next, retrieve the sibling data segment from the target storage node off the chain; 3) The data segment is then redistributed to the new storage miner.
The storage miner first checks whether the data segment received matches the deal, and then submits the necessary information on the chain while storing other data locally. Thus, the data segment has been successfully repaired.
Last updated
