Cross-Block Protocol

Overview

The cross-block protocol is needed to check that Storage Replicator Nodes 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. Afterwards, the owner sends the Upload transaction to Blockchain with the newly generated root hash of the whole Drive. Every Storage Replicator Node 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 Storage Replicator Node performs the next steps:

  1. Encrypts every retrieved data block with a secret key.
  2. Processes and prepares result block for future verifications through CPOR algorithm.
  3. Sends the encrypted block to another Storage Replicator Node chosen using the formula below.
  4. Waits for an encrypted block from another Storage Replicator Node, also using the formula.
  5. After the protocol round is finished every Storage Replicator Node stores the unique copy of the Drive with newly added file assembled from different pieces that were encrypted by different Storage Replicator Nodes 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 Storage Replicator Nodes.

Example

A Drive has 5 Storage Replicator Nodes. 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.

Note
Every R has its number on the Drive contract. It gets the number according to the consensus algorithm.

Formulas

Request a file

Rk requests from Ri the file part at the number (k - i mod N) where N is the number of Storage Replicator Nodes.

Send a file

Ri sends the j-th part to R at the number ((i + j) mod N) where N is the number of Storage Replicator Nodes.

Retransmitting protocol

The Storage Replicator Node that found a mismatch, creates the new transaction to ban the unfair Storage Replicator Node. This transaction should be signed by a percentage of signers (defined when creating). Other Storage Replicator Nodes request the same parts of the file and check them. If the unfair Storage Replicator Node fails the check one more time, the verifier signs the ban transaction. If the minimum percentage of approval is collected, the unfair Storage Replicator Node will be banned. If there are not enough signatures, the initiator will receive the results.

← SupercontractsFair Streaming →