Retrievability Consortium Demo

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

https://rinkeby.etherscan.io/address/0xFC3849cf75D6f0b24bd831D011e8495430335b8d

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

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

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:

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

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

Testnet contract:

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

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

We’ve finalized a basic UI for the client to

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