IreneProblem
The data retrievability problem:
Goal
We have already designed an MVP to guarantee retrieval (see Retriev.org). That protocol relies on the help of semi-trusted parties (”referees”). In this effort, we want to design a protocol without dependency on “special parties” (eg, referees) to improve the decentralization feature of our solution to the data retrievability problem.
Outcome
No clear yet (paper + proof of concept implementation? FIP?)
Timeline
No clear yet, developed in Q2
Team
Researchers: @Irene(DRI), @Luca Nizzardo, @Nicola
Engineers: ?
PM: ?
Protocol (WIP, brainstorming phase).
Intuition:
in order to mine a block, the provider needs to add a “proof of delivery” for the retrieval requests it received. If we have this, we can state that the blockchain itself takes the place of the referee committee and “slash” the bad providers (ie, they don’t win the block reward if they do not provide the retrieval service).
Protocol (just a draft for now):
- Retrieval deals: A client that is interested in accessing a file with public tag T that is stored by the network proposes a retrieval deal. Any SP can accept the deal (the acceptance messages are on-chain) and from now it is responsible for answering retrieval requests for the file from the client.
- On-chain retrieval requests: The client asks for the file to theSP with an on-chain message. SP sends the file privately to the client, who answers with a retrieval receipt sent to the SP. (There can be the possibility of paying the SP for the retrieval service, but we consider this out of scope for now).
- Change the block validation rule: The block validation checks if the SP producing the block has received any reliability requests during the day before the election and in case there was a request, the blocks needs to contain a valid retrieval receipt.
- Why is this the incentive for SPs? A malicious SP, which does not send the file when requested, risks losing the next day’s block rewards.
- Problem/ToDo: checking the entire blockchain status from the day before is too inefficient, what can we do instead?
- Problem: a malicious client who refuses to send the retrieval receipt will make an honest SP loses reward. How can we prevent this?
- If the original client refuses to sign the receipt, we can choose another client (or miner) at random (eg, using drand) and ask to sign (after having received the file).