The cross-block protocol is needed to check that replicators keep storing files through time. The protocol is developed to ensure data reliability and security. When the owner saves the new file, it forms the Merkle graph from its parts and applies it to the graph of the whole Drive. After, the owner sends the Upload transaction to Blockchain with the newly generated root hash of the whole Drive. Every replicator after transaction confirmation retrieves the difference including the new file from the owner and simultaneously verifies the validity of the formed Merkle graph. If everything is correct, then every replicator performs the next steps:
- Encrypts every retrieved data block with a secret key.
- Processes and prepares result block for future verifications through CPOR algorithm.
- Sends the encrypted block to another replicator chosen using the formula below.
- Waits for an encrypted block from another replicator, also using the formula.
- After the protocol round is finished every replicator stores the unique copy of the Drive with newly added file assembled from different pieces that were encrypted by different replicators with a secret key. That is, the stored data after the process can be easily fetched in the original form via decrypting the data with known public keys of replicators.
A Drive has 5 replicators. Every R splits each file into 4 parts. R0 requests from R1 the file part at number 1; from R2 the file part at number 2 and so on. Also, R0 sends the file part at number 1 to R1; the file part at number 2 to R2 and so on.
Every R has its number on the Drive contract. It gets the number according to the consensus algorithm.
Request a file
Rk requests from Ri the file part at the number (k - i mod N) where N is the number of replicators.
Send a file
Ri sends the j-th part to R at the number ((i + j) mod N) where N is the number of replicators.
The replicator that found a mismatch, creates the new transaction to ban the unfair replicator. This transaction should be signed by a percentage of signers (defined when creating). Other replicators request the same parts of the file and check them. If the unfair replicator fails the check one more time, the verifier signs the ban transaction. If the minimum percentage of approval is collected, the unfair replicator will be banned. If there are not enough signatures, the initiator will receive the results.