Deal Pre-Activation
🗼

Deal Pre-Activation

Authors
Luca Irene
Creator
Luca
Created
Mar 23, 2023 10:57 AM

We present here a proposal for Deal PreActivation, a change in the deal application semantics which allows for better consistency guarantees.

Background

In Filecoin, deals are assigned to sectors and are activated when the SP starts proving he is storing the file. Nevertheless, this process requires time (note that in principle it can take 30+ days for a sector ProveCommit to happen).

Additionally, there is no storage guarantee for a deal that has been accepted until activation. Indeed ProviderDealCollateral (which is slashed if an accepted deal is not activated), could might be too small to enforce cryptoeconomic guarantees (note that ProviderDealCollateral is lower than sector Initial Pledge and, currently, we have ProviderDealCollateral for verified deals being 0.008 FIL and InitialPledge = 0.216 FIL).

This fact represent a downside of Filecoin with respect to other Web2 storage systems (like S3) where consistency is immediately guaranteed

Deal Flow

In Filecoin, the deal flow works as follows

  1. Client and Provider negotiate off-chain;
  2. Client sends a signed StorageDealProposal which contains StartEpoch, StoragePricePerEpoch and ProviderDealCollateral (minimun is set to 1/100*normalizedCirculatingSupply );
  3. Client sends data;
  4. Provider locks down ProviderDealCollateral ;
  5. Provider sends the onchain message to accept the proposal;
  6. Provider locks down InitialPledge and starts to seal a sectors (with the data from the deal), once sealing is completed the deal is considered active. Note if activation is after StartEpoch, then ProviderDealCollateral is burnt.

More details in the specs https://spec.filecoin.io/#section-systems.filecoin_markets.onchain_storage_market.storage_deal_flow

Deal Structure

A deal proposal contains what follows:

PieceCID PieceSize VerifiedDeal (boolean) ClientAddress ProviderAddress

Label , a label for the deal arbitrarily chosen by the client

StartEpoch, the nominal start epoch agreed by Client and Provider.

EndEpoch

StoragePricePerEpoch

ProviderDealCollateral . Minimum is set to 1/100*normalizedCirculatingSupply

ClientCollateral, currently set to 0 Note that

  • Deal payment is linear between StartEpoch and EndEpoch
  • The total deal amount is StoragePricePerEpoch * (EndEpoch - StartEpoch)
  • The Storage deal must appear in a sealed (proven) sector no later than StartEpoch, otherwise the deal is invalid. In this scenario, ClientCollateral is returned to the Client, while ProviderDealCollateral is burnt (see here)

Problem

We want Filecoin to ensure that data is stored (similarly to what happens to other Web2 solutions like S3) from the moment the deal is accepted.

Proposal

On one hand, it is clear that we can not grant a data is stored inside a sector up until the sector is proven (and this can take up to 30+ days).

On the other hand, we could introduce economic guarantees that the data is stored even before being encoded into a sector.

It is true that there already exists a ProviderDealCollateral which is burnt if the deal is not activated in time, but it seems too low to rely on it for rationally ensuring that the SPs are actually storing (and thus activating) all the deals they accept. Current ProviderDealCollateral for verified deals is 0.008 FIL

  • One way can be to increase that collateral to something close to InitialPledge (not asking to SPs to put down IP anymore). Note that today we have InitialPledge = 0.216 FIL.
  • Another way can be to relate ProviderDealCollateral with deal amount (StoragePricePerEpoch * (EndEpoch - StartEpoch)
  • Another way can be to relate ProviderDealCollateral with the expected reward

Today ProverDealCollateral is based on normalizedCirculatingSupply . Ideally it seems we should make it depending on either InitialPledge or total deal amount (that is: StoragePricePerEpoch * (EndEpoch - StartEpoch)) rather than circulating supply.

Open questions:

  • Considering ProviderDealCollateral ~ InitialPledge (or ~ deal amount or ~ expected reward) to get storage guarantees before activation, there are some open points to consider:
    • Is having ProviderDealCollateral ~ InitialPledge too much of an entry barrier for SP to accept deals?
      • How big should ProviderDealCollateral be in order to have economic storage guarantees before activation?
        • What absolute value?
        • What InitialPledge (or deal amount or expected reward)percentage?
        • Is a percentage of total deal amount/ Expected reward the most logical option (instead of InitialPledge )?
    • If using InitialPledge as the reference, how would we deal with pieces smaller than sector size which are incorporated in a unique sector?
      • Having per-piece IP and eventually top up at ProveCommit to reach the expected overall IP?
  • Is what proposed above a solution for the use case highlighted by Lauren?
    • If not, what is missing in order to meet the expectation?
      • Retrievability guarantee needed?
      • Other?

Why 30 days?

How do snap deals impact?

Since clients are not putting up funds initially, if SP pays providerdealcollateral and can’t get data, dispute?

For reference, Boost description of deal steps — https://boost.filecoin.io/boost-architecture

CryptoNet is a Protocol Labs initiative.