This is a proposal to decouple commitments to storing data from sector lifetimes, allowing sector data to be replaced after being stored for some defined duration. Constraints on replacing data allow markets and other contracts to rely on data commitments, while giving SPs freedom to re-use sector capacity outside those commitments.

This idea was outlined in this presentation at Fil Dev Summit 2023, Singapore.

Motivations

• Make re-snap possible to re-use capacity, without compromising ability of contracts and people to rely on prior commitments to data. Increase utility of storage capacity for SPs.
• Flexible deal durations for clients, independent of sector lifetimes.
• Reduce cost, risk, and operational overhead for SPs adding and maintaining capacity.
• Retain some friction to rapid on-/off-boarding of capacity and pledge, for stability.

Impacts of the proposal below

• The default behaviour of committed sectors is to stay alive on the network, rather than expire. SPs don’t have to take any action or incur cost to keep their sectors on the network for as long as we trust the sectors’ PoRep proofs.
• Re-snap can replace capacity that was empty or holding data no longer needed
• Markets and other smart contract can rely on commitments to store data for some duration
• SPs can more easily match deals to CC sectors.
  • No need to extend existing CC sector to make room for deal term requirements.
• Lower risk to onboarding additional capacity.
  • SPs don’t need to lock in sector durations up front or attempt to balance cost of extension with optionality to expire.
  • Reduced duration-risk for pledge on CC sectors, SPs have option to terminate any time with a known cost.
  • Similar penalty for early termination of data as today
• No significant change to Fil+ costs, rewards, or incentives.
• [With transferrable commitments] Deals in new market contracts can be longer than 5 years, and be satisfied by different sectors over time.

Technical design sketch

The word “commitment” below means the informal sense of an indication of what duration/epoch some sector/data is to be maintained for, rather than the cryptographic meaning.

Perpetual sectors (up to PoRep security bounds)

The sector ExpirationEpoch is removed, along with the ExtendSectorExpiration method. SPs don’t have to perform any action to maintain power for their onboarded sectors. Sectors expire only 5 years (a protocol parameter) after their ActivationEpoch. Note that a future protocol change could increase that 5 years to a longer period if we deem the current PoRep proofs still secure.

<aside> 💡 Longer periods require re-working the pre-commit deposit, which assumes a maximum sector reward, and hence lifetime. Non-interactive PoRep could obviate this.

</aside>