FIP-0110: Shorter minimum deal duration

[willscott]

Problem

Today, the minimum deal duration is 6 months. This is a constant in the builtin actor code.
The problem with that minimum length is that there are a number of cases where clients may want to onboard data with lower initial commitments. We don't have the flexibility to experiment with other programmatic incentive mechanisms around deal lengths and extensions with full granularity because of the inflexible deal duration minimum.

Proposal

This proposal, per the accompanying FIP Proposal, is to reduce the deal duration to 1 month.

This supports the additional use cases requested by on-boarding clients.

Discussion

There are a couple reasons we might suspect for why the constant was set initially at 6 months. We will discuss each here, and why we think the lower minimum should be an acceptable adjustment.

6 month minimum is a result of amortization of sealing costs.

It is likely true that the overhead associated with sealing and proving around poreps is not well amortized for deal duration shorter than 6 months. This will continue to serve to make these shorter deals non-profitable, and non attractive to storage providers, even if they are allowed by the protocol.

The protocol change here allows the client to commit to lower in the protocol, but we would expect surrounding mechanisms to still lead to a situation where the expectation is for longer deals in general in order for them to be profitable to the storage provider. The negotiated collateral / terms can be expressed in FVM contracts now however, and do not need to be enforced in the builtin actor.

Shorter deal terms can lead to more messages on chain / chain congestion.

Deal extensions currently account for ~3% of overall messages on chain (consisting of ExtendClaimTerms and ExtendSectorExpiration2.

Gas limits for these two methods can be somewhat high, as they are typically batched messages for many sectors, but they remain lower than most FVM activity.

Increasing the rate of these two methods by 6x, as the worst case outcome of the change proposed here (if all deals went from 6 month terms to 1 month terms, which they will not) - would not be a significant imposition on chain bandwidth.

[LesnyRumcajs]

Is there any other constants that might be relying on those 6 months? For example TERMINATION_LIFETIME_CAP set to 140 days (Existing constant) This constant maintains the linear increase in termination fee for young sectors. as per https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0098.md#specification.

I guess there could be more of those, and changing them could trigger even more changes that might have some economic concomitants.

[BigLep]

For visibility, there was discussion about this FIP in filecoin-project/core-devs#208.