Syllabus - WIP

Parties

• Clients
• They are the data owners, they want to store data with Filecoin providers
• They want to retrieve data (out of scope here?)
• Providers
• They have the hardware for storage
• Dealers (new!)
• Nodes that acts as intermediaries between providers and clients
• Storage Market Actor (?)
• Data Preparations Nodes (?)

Protocols

Data Client Contract MVP

1. addCID : a way to add cids to its authorized set.
2. An authorization policy (eg, one provider per cid)
3. A mechanism of rewarding storage of cids on its wishlist (MVP doesn't have a place for this in its code and relies on the filecoin builtin market for payments).

Perpetual Storage

• depositTo(amount): This function adds tokens to the internal balance of the perpetual storage contract.
• activatePerpetualStorage(file_id):
1. Call createDealProposal(file_id, ...) ->deal_id from Bounty contract; and then start listening to the logs (onchain events),
• If dealAccepted(deal_id) event, then get the deal_id_start_epoch and go to step 2,
• If the deal notice goes in timeout, go back to step 1;
2. At each epoch after activation, do the following
• (Repair) If dealTerminated(deal_id) event is on chain: check internal balance, if there is enough tokens then invokes createDealProposal from Bounty contract again;
• (Renew) If current_epoch = deal_id_start_epoch + deal_duration : check internal balance, if there is enough tokens then invokes createDealProposal from Bounty contract again.
• (add a mechanism for provider selection?)
• first come first claim ?
• (selection based on a power threshold ?)

Protocol for pooling storage resources (”Pool Contract”?)

• (SP) Members governance : how do you become a member?
• Writers governance (who can store data): who is allowed to decide who to store with
• SLA governance (rules, eg if a provider is in a poll but do not store, slash the deposit?)

Data Persistence (DP)

Data availability (DA)

Extra (related stuff)

Crowdfunding

Repair/Renewal Contracts