Issues

• Long commitments add risk/cost to SPs or their financiers due to long pledge lock-up. May discourage CC and paid deals. See Protocol-induced risks to storage providers.
• Current behaviour is for sectors to auto-expire by default if no action taken. Extending a sector actually costs the SP (gas, possibly higher pledge).
• Data deletion or replacement is hard to implement in a way to support product needs of markets etc. Re-snap needs to be constrained.
• We want some friction to quickly on/offboarding capacity and pledge, to smooth. See Motivation and design goals for termination fees.

Things we might want:

• No/short commitments for CC and unverified data
• Don’t auto-expire sectors, extend by default at no cost (manual expiration)
• FIL+ still needs an end date, not indefinite
• Commitments are for data, not capacity
• Markets/deals need to rely on sector content being maintained

New core ideas:

• Data commitment epoch: SP cannot remove data before that epoch
• Data expiration: SP must remove data by that epoch

What can we build with these?

• Each sector has a DataCommitmentEpoch and DataExpiryEpoch, both optional.
  • If set, each are assumed to apply to all non-zero data in the sector. This is a simplification over tracking commitments to individual pieces.
  • Also implicit proof expiration epoch: ActivationEpoch + 5y (same as current)
• Data commitment/expiration are not relevant to CC sectors
  • CC sectors have no commitment or expiration except the 5y proof expiration (implicit from activation epoch)