Direct Storage Deal Dispute for user-defined markets

[Fatman13]

Simple Summary

Add an interface(s) to miner actor which allows user-defined storage market to dispute storage deal(s) directly.

Abstract

Disclaimer: Ideas borrowed from Venus dev team

In order to enable a variety of new innovations on L2 and more flexible storage deal terms between clients and SPs, we propose to add the following protocol API to miner. Note that this FIP separating sector from commD might be pre-requisite for this proposal?

Get states of the sector that stores requested pieceCID(s).

/*
  Get states of a sector and see if it contains certain pieceCID
*/
GetSectorStates(params GetSectorStatesParams) return GetSectorStatesReturn;

Change Motivation

The two pillars of Filecoin's proof of storage system, PoRep and Post, have been enabling SPs to cryptographically prove its commitment to a storage deal. More specifically, PoRep is a one-time proof that guarantees client's data (pieces) get sealed into a sector, while PoST proof is required to be done by SPs everyday to demonstrate to the network that client's data stored in the sector is still there.

After the introduction of F(E)VM, programable data storage on top of the Filecoin core protocol is now possible. This is an especially important step towards a decentralized storage network for both private and enterprise data storage on the user layer of Filecoin protocol. Developers can build their own storage market and shape custom deal terms according to their unique data storage use case. To unleash a new wave of innovation on data storage incentives and deal terms, smart contracts on F(E)VM need to be able to query chain states on whether SPs are still actively tending to the storage deal data they claim to store.

By exposing GetSectorStates API from core protocol to above L2 applications, smart contracts will be able to enforce the storage deal terms agreed by both clients and SPs, releasing token rewards or slashing pledges accordingly.

Specification

Method 1

GetSectorStates(params GetSectorStatesParams) return GetSectorStatesReturn;

GetSectorStatesParams is defined as the following...

/*
  Params for GetSectorStates
  pieceCID: target CID for checking its existence in the sector;
  sectorID: target sector to be be checked;
*/
type GetSectorStatesParams struct {
  pieceCID          pieceCID    // optional?
  sectorID          int
}

GetSectorStatesReturn is defined as the following...

/*
  Return value for GetSectorStates
  isPieceInSector: true if pieceCID exists in the sector, false otherwise;
  sectorState: same as sector states defined;
  cumulatedFaultDays: cumulated fault days that the sector has suffered;
*/
type GetSectorStatesReturn struct {
  isPieceInSector        bool
  sectorState            SectorState
  cumulatedFaultDays     int
}

Method 2

If the gas cost associated with method 1 is much higher than expected, we might consider more direct APIs to achieve direct storage deal dispute. For example...

/*
  Check if a given pieceCID is stored in the sector
*/
IsPieceInSector(pieceCID, sectorID) return bool;

/*
  Check if the sector has finished PoRep, ie sealing, step of the proof of storage
  Optional
*/
HasSectorPoReped(sectorID) return bool; 

/*
  Check if the sector has properly done PoST, ie the 24h daily proof, step of the proof of storage
  Optional
*/
HasSectorPoSted(sectorID) return(notFault bool, cumulatedFaultDays int);

Method 3

Or we could have a more generic GetStatebyHead to get the root of the actor and leave the burden of finding and calling each methods within the actor to SDKs or Dapp developers.

Method 4

Elaborated by @ZenGround0 here.

Method 5?

We are very much open to ideas on how to achieve Direct storage deal dispute (DSDD) if there is more elegant way of doing so.

Design Rationale

Note: storage deals in this context means the mapping of deals and SPs within a user-defined storage market (smart contract).

Right now, Filecoin built-in market put on massive limitations on how storage clients and storage provider could interact with each other. For example, pledge is arbitrarily determined by the network core protocol regardless how the storage client values its data and how much skin the client would like the provider to have in the storage deal. When we carefully examine the current storage deal workflow, there is no easy way for a Dapp to check if a storage provider is still actively honoring a deal in a decentralized way. We then deducted that by simply allowing user-defined contracts to dispute/enforce a storage deal between client and provider we can circumvent the built-in storage market completely and build more flexible storage deal terms on L2.

The actual dispute would work much like optimistic windowPost. An entity (could be storage market deployer or the client) could run off-chain analytics on sector states. Once a breach of contract is detected, the entity could then use GetSectorStates to verify and trigger dispute to either slash or follow some other user-defined contract logic.

The proposed design would also allow easy transfer of storage deal from one SP to another as you would just need to make changes to the internal mapping of the deal to a SP in a contract instead of FIPing a core protocol change. For example, SP A could propose to a contract to take over the deal terms, and SP B could approve and allow SP A to take over the deal from then on.

Product Considerations

Direct storage deal dispute (DSDD) will allow many innovative user-defined storage terms use cases...

1. A storage client wants to use Filecoin as their cold storage solution to store some archived data. The client would like to store 10 copies of each data piece (pieceCID). The client wants free storage from SP for a year as they have obtained Datacap from its LDN application themselves. A 5 fil/TiB pledge and a 0.1fil/TiB/day sector fault fee term, for example, could be negotiated between the parties to proceed with the storage deals.

2. Again, a storage client wants to use Filecoin as their cold storage solution to store some archived data, but they don't have either DataCap or Fil. A 3 USDT/TiB/Month fee and 0.1 USDT/TiB/day sector fault fee term, for example, could be negotiated between the parties to proceed with the storage deals.

3. A DataDao organization wants to mimic f+ program to incentivize valuable data on-boarding to Filecoin network using their own coin, FilStar. The DataDao would have its own notaries to approve datasets and the value of the Dao would be reflected by the market cap of FilStar.

4. There could also be many opportunities for perpetual storage use cases because of easier deal ownership transfer as mentioned in the design rationale. If properly incentivized, a SP would be always willing to pick up a perpetual storage deal from another SP.

[ZenGround0]

This is an excellent idea.

The interface should include space for a proof in the parameters:

type ProvePieceInSectorParams struct {
  pieceCID          pieceCID 
  sectorID          int
  proof               []byte
}

/*
  Check if a given pieceCID is stored in the sector
*/
IsPieceInSector(pieceCID, sectorID, proof) return bool;

This is required because the miner actor will not have access to pieceCIDs in its state.

Exposing sector states to user contracts is clearly useful but potentially problematic. We want to design very stable interfaces for contracts so we don't break user code. Since scaling the miner actor involves keeping less information on chain it is useful to imagine a the limiting case where all miner actor state is kept offchain in something like a zk rollup. An interface that works in this limiting case is:

VerifyState(sectorID, state, proof) bool 

Basically the miner actor can safely be assumed to be able to verify a statement given a proof and a witness but not provide availability for its own data.

The tweak I'm proposing above to GetSectorStatesParams follows exactly this pattern because miner actors don't have data availability on the many CommPs composing a CommD

The clearest path forward to achieve what's proposed here is to optionally allow saving CommD to the miner actor's state upon prove commit. This is required for this approach to work at all. This is a change I've been planning to propose in the coming weeks and is feasible to land in the next upgrade alongside direct data onboarding. If you're interested in joining in I'd be happy to work with you on the FIP.

[ZenGround0]

CommD has the nice property that it is the minimal amount of data needed to prove inclusion of data within a sector. My opinion is that the miner actor should be responsible for ensuring continued storage of data and providing the minimum requirements for proving data membership. Beyond this consumers of sector storage should be the place to track additional information for more efficient operations, for example the way f05 tracks CommP today. The hope with the direct data onboarding change is to create an interface allowing any consumer contract to learn about CommP on sector commitment. My hope with a change like the one being proposed here is it allows consumer contracts to construct a set of CommPs in their own state after sector commitment.

[steven004]

I have a different opinion on this matter. I would prefer to use PieceCID instead of commD in Chain State, with the implementation based on an opt-in mechanism. Here are the reasons for my preference:

1. Filecoin is fundamentally built on the concept of ProveOfStorage, with the aim of providing verifiable storage for users. However, using CommD alone provides verifiable storage only from the Storage Provider's perspective, meaning that the SP's storage is verifiable but not from the client's point of view. To ensure verifiable storage for users, PieceCID is necessary.
2. In the current network, in most cases, a sector contains only one piece. This is a choice made by the SP, and in these cases, using PieceCID instead of commD would not require additional storage space.
3. It's important to consider the economic aspect here. We should aim to provide valuable use cases for users in the design, and with a reasonable charging mechanism in place. which can help deter abuse. If we believe that the opt-in PieceCID mechanism is less efficient than commD, perhaps we need to work on improving the storage-based gas mechanism.
4. I do not believe that Filecoin can scale to become a network capable of handling trillions of deals or pieces, regardless of whether commD or PieceCID is allowed to be saved in the chain state. Scalability issues cannot be effectively addressed by simply reducing what is stored on-chain (which should be discouraged by gas costs). Instead, scalability should be tackled through architectural redefinitions, such as implementing subnets or parallel chains.

[ZenGround0]

In the current network, in most cases, a sector contains only one piece. This is a choice made by the SP, and in these cases, using PieceCID instead of commD would not require additional storage space.

This also means that users will get basically what they need immediately by storing just CommD as a first step since single CommP == CommD. So practically there is little to lose in implementing only CommD first. Then we can observe how users use this interface, what their painpoints are, and then we can come back and reevaluate.

[steven004]

From users' point of view, CommP is more useful than CommD. That's why I am more preferring CommP on chain.
One case I can image is: in a user-defined market, a user can have deal with an SP to store data with terms in which the client can get compensation when faults happen. If its CommP on chain, it would be easy to prove the piece is in fault state when disputing. But if it's CommD on chain, the dispute would provide all other CommPs in that particular CommD to prove.

Another point I could think of is who will pay the cost for the opt-in CommD? it looks nobody, since it's CommD which may contain pieces from different clients, even different markets. It would be different if it's commP, the client would take the cost, or a particular market will define it.

I put the similar comments in #819 .

[ZenGround0]

From users' point of view, CommP is more useful than CommD. That's why I am more preferring CommP on chain.

I don't disagree with this, I just disagree that it is worth the cost of mixing separation of concerns. I think that either this CommP should 1) be stored in a different actor as part of notification during sector activation (as part of planned extension to Direct Data Onboarding) or 2) the user pays the cost of proving CommP is in CommD later.

But if it's CommD on chain, the dispute would provide all other CommPs in that particular CommD to prove.

This is not true, to prove inclusion in CommD we'll only need logarithmic CommPs. An FVM contract can implement merkle inclusion proofs into CommD today. And by leveraging FVM SHA256 precompile this can be efficient.

Another point I could think of is who will pay the cost for the opt-in CommD? it looks nobody, since it's CommD which may contain pieces from different clients, even different markets. It would be different if it's commP, the client would take the cost, or a particular market will define it.

I don't understand this. If CommP cost is covered by different client agreements than CommD cost is also covered by client agreements, clients just have to pay less since they all benefit from the same cost.

[anorth]

While a sector ID is sufficient to address a sector's content (CommR/D), it's not enough to address its workflow status, like faults. Sector fault status is not indexed by sector ID on chain, but by deadline and partition. A method like HasSectorPoSted needs to provide the path to find the sector state on chain. This exposure of deep Window PoSt scheduling internals is one reason we have not exposed such a method previously.

Taking this with @ZenGround0's points about future data availability, a similar pattern would be necessary but could work for determining fault status. The method would be something like SectorIsFaulty(sectorID, proof), where the proof would encapsulate pathing to the sector's partition.

This would still introduce coupling that would make it very hard to change these internals in the future. However I'm now weakly of the opinion that it's worth it. We would then face the prospect of implementing an all-new miner actor if we ever wanted to change this internals.

[ZenGround0]

Another thought along these lines: if we keep dline/partition index in the proof then we can change the internals and expose this to the user by versioning the proof. If user contracts are careful to always solicit proofs from offchain then this becomes an offchain infrastructure upgrade.

[Kubuxu]

I would feel better if the sector identifier was opaque because we might want to use something different than integer IDs for sectors for some solutions.