🌐  Context We currently have a retrievability assurance protocol (Retriev.org, details here) which works as follows:

1. There is a consortium of providers that sign up to participate in our system;
2. There is a fixed set of referees for which we can say that half of them are honest (eg, 5 referees and we trust 3 of them);
3. Client and Provider agree on a retrievability deal (aka the assurance policy for the retrieval service); providers lock down a collateral for each deal and client locks down a payment for the service;
4. When a client does not get the requested file, it appeals to the referees. One of them tries to retrieve the file asking it again to the provider, if this works the file is forwarded to the client (the provider gets paid); If not, we try again. After some failed attempts, the provider is penalized: the collateral is taken away (and no payment is provided).

Referee Network and its Invocation

Create appeal

While the deal is active, the client can appeal to the referees (n referees in total) at any instant on time for requesting the assured storage. The appeal is considered valid if all the following is true:

• The deal is active
• For this deal, the number of appeals already created is less the the maximum allowed by the protocol (eg, 5)
• There is no active appeal already
• It includes the payment of an appeal fee. This is the amount of token that the client pays to the referees for their service.

Start and Process appeal

If an appeal is created, any referee that is free can start the appeal process.

The protocol to process an appeal is made by k (eg, 12) rounds each. In each rounds the referees try to retrieve the file in this way:

• Step 1: a retrieval leader is chosen at random.
• Step 2: the leader asks the file to the provider.
  • Step 2.a: If the leader does not get the correct file in time, he sends a signed “failure msg” on chain; the other referees see the message and do nothing for this round; in the next round all starts from Step 1;
  • Step 2.b: If the leader gets the file it forwards it to the client and to the other referees. Each referee does the following:

    • If the correct file is received, forward it to the client;

    • If the correct file is not received before the end of the round, sign a “failure vote” and broadcast it to the other referees;

    • Count the number of failure votes received, if they are ≥n/2, then send a “failure msg” on chain; at the next round, start from Step 1. Otherwise, do nothing for the remaining rounds. Note that only the first “failure msg” goes through.

      ≥n/2

After the k rounds are over, the contract checks the total number of “failure messages”.