Retrievability Consortium Demo

Demo [links + diagram + video]

After 4 weeks of work we’re ready with an MVP to be explored at https://pldr.dev/

At this link you can read and run the smart contract on the Ethereum testnet

This diagram introduces to the concept of the protocol as developed on the MVP

image

It start with the client visiting the Data Retrievability Oracle website and ends with the two possible scenarios of the deal either expiring or being cancelled (following the slashing of the provider)

The following video is a full presentation of the MVP, where the client via UI can create and manage deals, and the network of referees and provider can process the appeals

Future Features

There are some features we didn’t include in this MVP, but that we’ll be adding in the next phase of development - the followings are some of the ones we are thinking about and we still need to discuss:

  • Deals saved as NFTs

There will be two NFTs per deal, one non-transferable for the “owner/client” and one that can be transferred that represents the provider’s deal

  • Limit of appeals per deal

This is being discussed in order to define some economic parameters to let the protocol work within the market

MVP updates - week 2

Testnet contract:

Rounds can be processed on-chain (and leaders are elected randomly)

image
addresses of elected leaders (among a group of 5 referees)
addresses of elected leaders (among a group of 5 referees)

We are testing the different use cases, while working on a UI (CLI has already been developed)

The following video is about the setting up of the contract (first minute) and the creation of an “appeal” request which “resolves positively”: this means that the provider has given the file to the referees (so 12 rounds of “silence/no_slash_msg” on-chain, with 5 referees) and can redeem is payment once the deal expires.

As you can see at the end of the video, the balance of the provider is of 0.1 (payment received), that of the referee is 0.04 (0.2/5 referees), the owner (of the deal aka the client) has 0 as he pays both for the deal and the appeal. Also the protocol vault is 0 since no provider has been slashed.

In this next video the provider is slashed at every round, meaning that it has lost the deal.

So the balance at the end shows the provider loosing both the payment and the deposit, referees getting 0.04 each (same as above) and the owner being refunded 0.1. This time the protocol vault gets 1 from the provider slashed.

This is what an on-chain slash looks like

image

We’ve finalized a basic UI for the client to

  • Create a deal
  • Get deals from contract
  • Manage deals (cancel, create appeal)
  • Withdraw funds from contract (second video)

We are running a serie of tests to simulate the interaction between the node of the provider and of the referees. This prototypal ecosystem has 1 provider node and 5 referees nodes.

Here’s a draft UI for the provider to accept the deal