owned this note changed 2 years ago
Published Linked with GitHub

Web3.Storage Bounty v0 (MVP)

Short Intro

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →
Problem definition:
Web3.storage offers the possibility of storing a file on Filecoin and IPFS by simply uploading it to the website interface.
Nevertheless, we want to consider here the scenario where a client of another Blockchain Network (the host chain) want to use Web3.Storage as a channel to store a generic file on Filecoin/IPFS directly from the host chain.

Note that here we are considering any kind of files. If you are interested in a specific contract that handles the storage of NFTs only see (LINK to be added).

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →
Proposed solution:
We pick an EVM-compatible blockchain as the host chain and we design an Web3.Storage "bridge" as specified below.

The protocol in inspired by the Bounty Contract, with some simplifications.
The Bounty Contract is a smart contract that clients can use to create a “bounty” on storing files on a decentralized storage network. "Dealers" , which are parties that can read the host chain and has access to the storage network, use the contract to accept the "bounty deal" and also to claim the bounty. Notice that in order to successfully claim the bounty a dealer needs to submit one or more storage proofs. These are statements signed by a Storage Oracle that attest that given files are marked as stored on the network.
The simplifications that we propose for this MVP are the following:

  • There is only one dealer: Web3.storage;
  • There is no bounty (ie, bounty payment = 0), since storing file on IPFS/Filecoin via Web3.storage is currently free;
  • Web3.storage is a trusted dealer, we do not need a Storage Oracle (or in other words, Web3.storage is the oracle itself).
    • In particular the function ClaimBounty from Bounty Contract is not nedded (however we keep it for compatibility) and does not check the oracle signature.

In other words, our solution is a smart contract on the host chain that clients use to propose a deal for storing a file on Filecoin/IPFS in the same way Web3.Storage allows for storing a file in IPFS/Filecoin via browser; Web3.Storage periodically checks for proposals, accepts them and confirms that the file has been put on Filecoin/IPFS (ie, Web3.Storage acts as a trusted “Storage Dealer”).

Protocol Description

Parties:

  • Host chain Clients: An hostchain Client is the user of our protocol. He wants to store a file on Filecoin/IPFS directly from its node on the host chain (for example Ethereum, Polygon etc). To do so the client proposes a deal on the host chain specifying the file to be stored.

  • Web3.Storage: takes the role of the Storage Dealer, with a set of Addresses that could use depending on the workload. This means Web3.storage has a way to interact with the EVM and can store files on Filecoin/IPFS. Once the deal proposal is satisfied, Web3.Storage provides a confirmation in the host chain about its activity, acting a Storage Oracle.

    • The list of Addresses is stored in the smart contract;

Note, we assume that a filesharing tool that can make the file available from the client to the storage dealer is used (eg, this can be done via IPFS).

SLA

The protocol aims to move Web3.Storage deal requests from the browser to an host chain. This means that an hostchain client will be able to store informations on Web3.Storage directly on the host chain, but the informations about Filecoin's deals are retrieved off-chain using the APIs. The service is free of charge.

Smart Contract:

Create Deal Proposal

The host chain client creates a deal proposal to request storage to Filecoin/IPFS for a file or folder of files identified by data_uri (no ownership check). We do it by using a function

  • createDealProposal(string data_uri) -> uint256 deal_id

A deal proposal specifies these parameters:

  • The payment: amount (in native tokens) paid by the client to the dealer; at the moment of the proposal creation, the payment is "locked down" (ie, taken from the client's account and deposited to the smart contract);
  • The duration: for how long the deal is active, starting from when it is accepted (expressed in seconds); the proposal is valid only if duration is in a range specified by the smart contract code (max_duration).

NOTE: In the current Client UI, the client does not choose payment and duration, which are respectively set to 0 and 365 days by defualt. This reflects the fact that currently web3.storage gives free storage for any period of time. Future changes on Web3.Storage will potentially lead to an evolution of this part of the protocol.

Cancel Deal Proposal

A client can cancel a proposal (not accepted yet) at any time, and this action will release the payment

Moreover, proposals have a timeout after which they are not valid anymore (ie, can not be accepted).

Accept Deal Proposal

This function takes in input the deal_id as long as the data_uri.

  • acceptDealProposal(uint256 deal_id, string data_uri)

The dealer (Web3.storage) can accept the terms specified in a proposal if all the following is true:

  • It can access to the files.
  • The proposal is active (no timeout, no cancel message);

After the dealer (Web3.Storage) has accepted and sent confirmation, we say there is an active deal between Web3.Storage and the client who crated the deal proposal.

Also, we timestamp this on-chain, and we consider the deal active from this moment onward (timestamp_start).

Claim Bounty

claimBounty(deal_id, data_uri, oracle_signature)

This function can be called by a dealer to get the payment.

Note:

  1. As long as payment=0, this function will not be used;
  2. As web3.storage is a trusted dealer, oracle_signauture is not required here (we have it just to be compatibility with the general Bounty Contract).

List of events in the smart contract:

  • DealProposalCreated(string deal_uri, uint256 deal_id): Event emitted when new request is created by the client;
  • DealAccepted(uint256 deal_id): Event emitted when a deal is created by the dealer accepting the terms of a request (defines timestamp_start);
  • DealProposalCanceled(uint256 deal_id): Event emitted when a request is canceled by the client before being accepted;
  • BountyClaimed(uint256 deal_id)
Select a repo