DataDAO pattern + primitives to enable them

[ychiaoli18]

DataDAO Pattern

Below is an example of a DataDAO that FVM should be able to support.

Note: one of many such DAOs that can be created. The category is too vast to catalog all DAO structures on FVM.

DataDAO contributors collectively contribute their funds to maintain the replications of the data, and the storage providers receive rewards by replicating the deals specified by the DataDAO.

Mechanism

• DAO admins should be able to specify the storage deals, specified by CIDs, to be replicated
• DAO admins should be able to specify the number of replications for each CID
• DAO members should be able to contribute funds to DAO and receive a certificate, likely in the form of token
• DAO members should be able to withdraw the funds they contribute to the DAO
• Storage providers should be able to find out the CIDs that the DAO wants more replication
• (off-chain) Storage providers should be able to fetch the content of the CID and create a new deal
• Storage providers should be able to claim rewards based on the storage deal they provide
  • Note: reward can be recurring or one-time
  • Note: there are many varieties of the reward structure: it could decline with each new SP that replicates X, it could be time-delayed to make sure the SP can store it long term, etc
• Token holders should be able to trade the token, (likely on AMM)

Primitives needed

• Smart contracts should be able to find out the current number of replications of a CID
• Smart contracts should be able to find out the storage providers who store a given CID

[ychiaoli18]

cc @trruckerfling @hammertoe @aashidham @arajasek @raulk

[anorth]

Smart contracts should be able to find out the current number of replications of a CID
Smart contracts should be able to find out the storage providers who store a given CID

I don't think you need either of those primitives, if I interpret them as across the network, vs in the storage DAOs own state. The same data might be stored incidentally by other parties, but the DAO has no control of the terms of those deals etc, and I don't think they're relevant.

A storage DAO should track for itself how many deals it has done for a CID, which are still active, etc. That give the number of trusted replications. Similarly, it should track which SP it made the deals with.

Indexing CID->sector for the whole network is not going to be technically feasible within the L1 state.

[cameronfyfe]

DAO admins should be able to specify the number of replications for each CID

So far I've been imagining this happening in 2 ways:

1. DAO has its own logic for initiating and maintaining N storage deals for X CID
2. DAO initates and maintains meta-deals through some other FVM actors implementing more advanced storage markets that may include things like duplication and handles the underlying native deals. (similar to bidbot or evergreen, but in FVM)

Curious to hear if there is currently any discussion/traction around 2) since that could affect how we think about some of these Data DAO workflows.

[anorth]

Yes I'm really looking forward to (2), I think that will be a great architecture in the future. It's not possible just yet: see #298.

[ZenGround0]

So far I've been imagining this happening in 2 ways:

1. DAO has its own logic for initiating and maintaining N storage deals for X CID
2. DAO initates and maintains meta-deals through some other FVM actors implementing more advanced storage markets that may include things like duplication and handles the underlying native deals. (similar to bidbot or evergreen, but in FVM)

As mentioned above 2 is out of reach for FVM M2 launch. However there is active work for 1) here: https://github.com/lotus-web3/client-contract

FYI @cameronfyfe and @ychiaoli18

[ZenGround0]

The DealClient contract here should be the basic scaffolding for most of this. I'm hoping to collect forks of this contract with various improvements, including many mentioned above, in this repo.

Also note the lotus team is additionally starting to prototype:

Storage providers should be able to find out the CIDs that the DAO wants more replication
(off-chain) Storage providers should be able to fetch the content of the CID and create a new deal

which will obviously be living somewhere other than a user contract. We're hoping to prototype something out and eventually propose a change to the deal proposal protocol to enable this and also the second patter of the DAO being a proper storage market i.e. usage of patterns sketched out in #298