owned this note
owned this note
Published
Linked with GitHub
# Web3.Storage Bounty v0 (MVP)
<!---
*Disclaimer: In this doc we considered NFT.storage, but the same (or very similar) bounty contract can be designed to interact with Web3.storage*
--->
## Short Intro
:mag: **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).
:bulb: **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**](https://hackmd.io/2W6e_sAGTL-RBLYb1NsNUg), 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](https://hackmd.io/2W6e_sAGTL-RBLYb1NsNUg) 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”).
<!--In this context, NFT.Storage acts as a “trusted oracle” with respect to storage confirmation.
-->
<!--
Note that we do not need to set up a bounty given that dealer is Web3.Storage, and by design Web3.Storage provides the service free of charge for its clients. Moreover, given that Web3.Storage also acts as a Oracle, no fee is charged to clients.
-->
<!--
Future changes on Web3.Storage will potentially lead to an evolution of the current protocol, specified in this doc.
-->
## 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`).
<!--
Web3.Storage sends back `compressed_data_uri` after compressing the file so there's a specific link between `data_uri` and final storage position.
-->
<!--
### Check Status
This function takes the `deal_id` and asks for the current status to Web3.Storage which emits an event with the request
- `checkStatus(uint256 deal_id)`
### Status Update
This function takes the `request_id` and a `status_update` and publishes the requested storage data in the blockchain.
- `statusUpdate(uint256 request_id, string status_update)`
-->
#### 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](https://hackmd.io/2W6e_sAGTL-RBLYb1NsNUg?both)).
### 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)`
<!--
- - `UpdateRequested (uint256 deal_id)`: Event emitted when some customer asks for an update on the storage status.
- `UpdateSent (uint256 deal_id, uint256 update_id, string status_update)`: Event emitted when an oracle sends a notification for a specific storage request.
-->
