RESTORE

In order to ensure the availability of user data and the rights of the miners, CESS network based on fragments redundancy technology has a complete restoration mechanism for active data.

Restore mechanism

Each file is firstly divided into segments with the same specifications. Then each file segment is sliced into fragments for redundancy, and the resulting file fragments are stored on different storage nodes. According to the current 1.5 times redundancy rule, as long as the number of missing or damaged fragments in any segment does not exceed 1/3, the network can restore the file based on other fragments. The process is as following.

Miner self-check

Miners who fails the audit cannot receive rewards, and those who consecutively fails will be punished. In order to protect their rights and interests, miners can enter commands to conduct self-check, or the mining machine can trigger self-check after a random challenge verification failure. Self-check will compare all idle and active data fragments stored locally, and screen out non compliant data fragments based on the meta information on the chain. Idle data fragments will be discarded directly, and a transaction will be initiated to delete the corresponding idle data on the chain. For active file fragments, miners will first attempt to restore the data on their own. If restoration fails, a transaction will be initiated to generate a restoral order.

Restoral target

When voluntarily or passively quit mining, the miner needs to transfer its currently stored active data to other miners, and a restoral target will be created for this miner's account for public disclosure. Because there may be too much active data to restore, restoral orders will not be created by the chain. Other miners will search for active data stored in the restoral target, and initiate transactions to declare restoral orders.

After all the active data in the restoral target have been transferred to other miner nodes for storage, the restoral target will end publicly.

Restoral order

Restoral orders are all restoral tasks currently being executed on the network, with two status: claimed and unclaimed. Restoral orders are declared by miners, and the declaration conditions are as follows:

• Must be for active file fragments.

• The order currently does not exist on the network.

• The declared target must be the current restoral target or the miner itself.

When the declared target is the miner itself, the order will be changed to unclaimed state after generation, waiting for other miners to come and claim it. When the declared target is the restoral target, the order will directly be changed to claimed state, and the claimant is the initiator of this transaction.

If a miner fails to complete the restoral task, the claimed restoral order will be changed to unclaimed state within its validity period, and wait for other miners to claim it again.

Restoral process

At the same time, only one miner can claim an order and perform the restoral task. During the restoral process, the miner will prioritize the transferring of active file fragments and tags stored on the original miner. If the transferring fails, it will then try to restore the file fragments by downloading the file fragments from other miners to construct the file segment. After fragmenting with redundancy, and storing the file fragment specified in the order, it will request TEE Worker to calculate the tag of the file fragment.

Reporting of restoral results

After completing the restoral task, it is necessary to call a transaction within the validity period to report the restoral results to the chain, before the restoral task is considered complete. Then the miners' computing power will be increased and the corresponding meta information of the file will be updated.

File lost

When a restoral order is generated, the chain network will check the current status of the corresponding file segment. If more than 1/3 of its file fragments are under restoring, the belonging file will be marked as suspected lost and a timing task will be started.

When the time reaches the interval defined in the timing task, and the file segment still has more than 1/3 of file fragments under restoring, the file will be marked as lost.

The current timing task interval is fixed to 3 times the time required by the restoral order execution.