ToBeRemoved The Basics
The CID bounty is an idea that has been floating around for a while. This note explores why I think they are a good thing and how to support them.
In its simplest form it is a contract with a state containing a CID. When a storage provider proves a sector that stores the CID’s data that sector and the provider satisfies the bounty. If providers can provide proof that they satisfy the bounty the contract will pay them the bounty reward.
The CID bounty is a sort of inversion of the state of the art filecoin deal. Clients don’t push data, providers search for and pull data. They could still find it by going to the client over a filecoin deal protocol. But they could also find it on IPFS or a public archive. Or the data could be on the filecoin network, already sealed in a sector. In this last case a provider need only provide proof of an existing sector’s satisfaction to satisfy the bounty, no data transfer sealing or updating necessary. Where the data can be found is non-essential from the perspective of CID bounties. Basically they take content addressing seriously.
As smart contracts CID bounties are programmable. A few straightforward enhancements are:
- Bounties with state describing how to locate their data with a web address, ipfs peer id or telephone number
- A reward that only pays out to the first satisfying provider in order to incentivize fast onboarding
- Rewards for the first n providers only satisfiable by different sectors or provider addresses
- Reward updated from on chain market price discovery or oracles of data storage cost
Market Actors
A more expressive satisfaction interface includes verification of sector metadata, in particular sector lifetime. With this in place we can imagine a CID bounty that wants to pay out
***construct existing market actor
***demonstrate how you can do want list stuff
*** what’s the difference anyway?
Time dependent: data could have been in sector already, Use dependent: decoupling of satisfaction from all other satisfaction or other uses
*** key characteristics in support
market actor specific information dropped from sector (as in architecture for programmable deals)
market actor specific call pattern is now also dropped
FIL+ subsidy as a system CID bounty
Supporting the CID Bounty Primitive
*** storage provider is able and responsible for proving verified ownership of a cid
*** interface is VerifyDataInSector(sectorID, proof)
This is always possible in practice! With a reevaluation of porep and a resubmission of piece infos commD can be regenerated and commR can be proven to contain it.
The problem is efficiency if we don’t store commD since PoRep is expensive.
Delegating to a particular market is bad because it spreads out intrinsic information about the sector to one user. Key characteristics stop being met. Sectors are now coupled to their uses.
Key idea: commD is inherent property of sector invariant to how its used so it should be kept with the provider state.
Because of this its always going to be easy to support proofs.
Problems
In general similar problems similar solutions in Architecture for programmable storage market
*** Faults,
Basic most blockchain native thing is proof of fault and proof of recovery provided by incentivized watchtower parties. Cron like things and registration. Leading to problems with miner actor starting to track market state internally. Another level of indirection may be a good way out.
*** Mutable sectors
CID bounty primitive highlights the problem but seem to exist in other framings too. Can’t trust storage provider not to overwrite sector if it is allowed to. Immutiblitiy is the easy solution. Selective mutability requires involving market actor information into storage provider state