Idea/Proposal: Perpetual Storage Contracts

[jcace]

Proposal: Perpetual Storage Contracts

Author	@gmelodie @elijaharita @jcace
Status	Draft
Revision	0.0.1

Proposal/Overview

This document outlines a potential scheme for perpetual Filecoin storage contracts on the Filecoin Virtual Machine (FVM).

Background

Currently, Filecoin deals are limited in length to 540 days. While there is discussion about increasing this up to 5 years, there still remains a situation where a Storage Client would like to store data for a much longer term, potentially several times the length of a single storage deal.

Benefits

A reference implementation / example for perpetual, auto-renewing storage deals would be a useful building block for others building on Filecoin and FVM

Goals

• Outline, at a high level, how a perpetual storage contract on FVM could work
• Call out certain areas of complexity / considerations that must be addressed for it to function
• Link back to relevant code snippets that would be used for the contract

Design Overview

Use Lotus web3 client contract to make deals with storage provider

Construct DealProposal

Client Inputs

• CID*
• number of replicas
• Initial balance
• End epoch
• Max. price
• Fil+/Datacap

*Every parameter is configurable once the contract is deployed, except for the CID.

Detailed Design

Smart Contract Functions

Client-Side

• Change Bounty
• Change # of replicas
• Suspend/cancel (stop renewals, refund balance)

SP-Side

• Claim deal
• Publish deal
• Terminate deal

Functionality

Initial Replica

1. Client deploys the contract using the initial params
2. Client must "seed" the file, keeping it available and downloadable until first replicas have been sealed
3. SPs call claimDeal() function, indicating they want to seal and store it, and receive the download information
4. SP downloads the CID from the "seed" location
5. SP seals the CID into a sector
6. SP calls the publishDeal() function, indicating they have successfully on-boarded the data
7. Contract tracks the expiry epoch of the deal, opens up another replica slot before it expires.

Once all replicas have been claimed, the claimDeal() function simply returns the next expected epoch when the soonest one will expire.

Subsequent Replica
After a deal expires, a slot is opened up. claimDeal() returns a list of all other SPs that the CID has been replicated to, for retrieval and the next deal.
SPs can call claimDeal() and the flow is the same as detailed in Initial Replica

Dependencies

• Deal needs to have another SP specified as the source location for file transfer

Performance Implications

• Gas costs for various transactions

Questions

• How do providers find the address / methods of the deployed smart contracts with deals available?
• What happens if the storage provider fails to seal after claiming the deal?
• What happens if a deal gets slashed/lost? How do we ensure the contract is synchronized with the actual state of deals on chain?

Assumptions / Considerations

• Once perpetual deal is kicked off, file has to be retrievable. SP has to serve retrievals in the future.
• Smart Contract "owns" the storage deals, pay for them using their internal wallet and/or datacap
• There needs to be enough of a window between one deal ending at the next one starting to allow for a new SP to claim it. As it gets closer to the deadline, smart contract could increase the bounty to incentivize providers to pick it up

[10d9e]

https://github.com/lotus-web3/deal-bounty-contract