Data Retrievability - Research effort for on-chain solutions

Creator

Irene

Created

Mar 3, 2022 2:46 PM

Project

Retrieval incentives

Stage

Graduated from Notebook

Problem
Goal
Outcome
Timeline
Team
Protocol (WIP, brainstorming phase).

Problem

The data retrievability problem:

📌

How can clients delegating data storage to a network of SPs have the guarantee that the retrieval requests are fulfilled (ie, guaranteed retrieval)?

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).