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
- Client and Provider negotiate off-chain;
- Client sends a signed
StorageDealProposal
which containsStartEpoch
,StoragePricePerEpoch
andProviderDealCollateral
(minimun is set to 1/100*normalizedCirculatingSupply
); - Client sends data;
- Provider locks down
ProviderDealCollateral
; - Provider sends the onchain message to accept the proposal;
- 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 afterStartEpoch
, thenProviderDealCollateral
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
andEndEpoch
- 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, whileProviderDealCollateral
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 haveInitialPledge
= 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