Flexible sector commitments sketch

Creator

Alex North

Created

May 31, 2023 3:13 AM

Project

Storage Programmability

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)
• Sector termination fee only applies to the first 30 days (parameter) after activation of capacity, and is equal to 30d rewards. After that, no penalty for offboarding capacity outside of data commitments.
• Alt: capacity offboarding always costs 30d reward, until proof expiry?
• We might want pledge rebasing first (not yet written up)
• SP can set either or both DataCommitmentEpoch and DataExpiryEpoch when onboarding data. Constraints:
• DataCommitmentEpoch ≤ DataExpiryEpoch
• NewDataCommitmentEpoch ≥ OldDataCommitmentEpoch
• NewDataExpiryEpoch ≤ OldDataExpiryEpoch
• Constraints on updating sector data with re-snap:
• Before DataCommitmentEpoch, miner cannot remove/replace data, but can replace zero data
• Or maybe can but with penalty? TBD handling client-authorised deletion
• After DataCommitmentEpoch, miner can replace data freely. May also set a new DataCommitmentEpoch
• If at any point SP replaces all non-zero data in a sector (all at once), they may reset DataExpirationEpoch too
• Sector offboarding (termination):
• Sectors stay active by default, regardless of data commitments.
• Before DataCommitmentEpoch, terminating a sector attracts data termination penalty (💻Data termination penalty—design sketch, but possibly larger)
• After DataCommitmentEpoch, SP can terminate sector with no penalty.
• At DataExpiryEpoch, a sector faults
• SP had committed to removing the data, but hasn’t (if sector has zero data it has no data expiry epoch)
• SP must Re-snap to remove all data before being allowed to recover from fault
• Need to allow replica update while faulty generally
• FIL+
• Miner actor ensures that sector data commitments honour FIL+ terms.

What do we get?

• Lower commitment/risk for CC sectors
• Sectors don’t expire - retain capacity by default
• User programmed markets can rely on commitments from miner actor, enforced by known penalty amounts
• Re-snap can replace capacity no longer used by deals (i.e. outside commitments)
• FIL+ keeps working as usual