⏳

Decoupling data commitments from sector lifetime

Creator

Alex North

Created

Oct 24, 2023 10:19 PM

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.
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.

💡

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

❓

Alternative: If we think PoRep is good for a long time, and we expect a long warning period before it deteriorates, we could remove sector/proof expiration altogether and invoke the FIP-0067 mechanism when needed.

Data commitments

Each sector gains two new items of metadata:

DataCommitmentEpoch: an epoch until which all data in the sector must be maintained
DataExpiryEpoch: an epoch by which all data in the sector must be removed/replaced

Both these items are optional. They are always nil/zero for sectors with zero data (CC sectors).

Both these epochs apply to all data in a sector (This is a simplifying compromise over recording commitments to individual pieces).

An SP can set either or both DataCommitmentEpoch and DataExpiryEpoch when updating data (including onboarding, replacing, and deleting). The values are constrained so that:

DataCommitmentEpoch ≤ DataExpiryEpoch, if the latter is not nil
New DataCommitmentEpoch ≥ previous DataCommitmentEpoch, unless

the new commitment may be nil if the old commitment is nil or has elapsed, or
the new commitment must be nil if the sector is empty (zero data)

New DataExpiryEpoch ≤ previous DataExpiryEpoch, unless

the new expiry may be nil if the old expiry is nil or has elapsed, or
the new expiry must be nil if the sector is empty

Note that there is no constraint that either of these values be sooner than the sector’s expected PoRep expiration epoch. A commitment may exceed a sector’s life because it can be transferred to another sector later. See transferring commitments below.

Data update constraints

The data commitments constrain when an SP can update date in a sector.

An SP cannot replace or delete non-zero data in a sector before its DataCommitmentEpoch has elapsed. Zero data can always be replaced (and will be automatically subject to any data/expiry commitments already in place for the sector).
An SP can freely replace or delete any data after DataCommitmentEpoch has elapsed. While doing so, it may set a new DataCommitmentEpoch and DataExpiryEpoch subject to the constraints listed above.

Data expiration

Sectors with a non-nil data expiry epoch are queued for expiration processing at that epoch. This replaces and re-uses the mechanism for sector expiration today, but applies only to some sectors.

If a sector passes its data expiry epoch with non-zero data it is immediately faulted. It pays a fault fee and will pay that fee again every proving period until it is recovered. A sector with a data expiry epoch cannot be recovered until its data is entirely replaced in a single operation (with zeros or other data) and its data expiry epoch consequently set to a nil or future value.

💡

This implies replica-update needs to be able to target faulty sectors when clearing data. TBC whether this is reasonable, or we need a separate method to do this.

❓

Alternative: The sector is immediately terminated, and pays the full sector+data termination fee.

Sector termination

Sectors don’t expire until their PoRep proof does, but an SP can remove them from the network sooner. Termination may be explicit or as a result of a continued fault, as today. Termination incurs a cost of a small amount of pledge collateral. The cost is independent of sector age.

Capacity termination fee

The fee for removing a sector’s capacity from the network prior to PoRep proof expiration is 30 days expected reward for the sector at the point of termination.

This is subtracted from the pledge returned to the SP upon termination. It could be considered an onboarding cost that is deferred and discounted with longer tenure.

❓

30 days is a parameter, to be decided. The proposed value is less than the 90 days currently charged because it’s only for the capacity. There is no motivation of data persistence.

Data termination fee

If a sector is terminated for any reason (including PoRep proof expiration) before its DataCommitmentEpoch, and additional fee of 60 days expected reward for the sector is subtracted from returned pledge collateral.

❓

60 days is also a parameter to be decided. This value is chosen to roughly align with current sector termination fee outcomes.

Note that these mechanisms automatically charge 10x fees for termination of Fil+ data, in line with the multiplied sector rewards, as today.

Filecoin Plus claims

The miner actor enforces that the DataCommitmentEpoch for any sector claiming a Fil+ verified allocation is no less than that required to satisfy an allocation’s minimum term. A Fil+ allocation doesn’t constrain the DataExpirationEpoch.

Built-in storage market

The data commitment epoch replaces the sector expiration epoch in the message from the miner actor to market actor when activating deals. A deal is only activated if the data commitment epoch is sufficient to satisfy the deal’s term.

Transferring commitments

A data commitment may be transferred from one sector to another, along with the data. This permits indefinite continuity even beyond PoRep proof expirations.

During replica update, an SP may nominate a source sector from which to transfer a data commitment and expiration. The destination sector must have exactly the same data as the source sector, for any non-zero source data. If the data matches, the destination sector may take:

Any DataCommitmentEpoch ≥ the source DataCommitmentEpoch
Any DataExpirationEpoch ≤ the source DataExpirationEpoch

subject to the usual constraints on these values.

If the transfer is successful, the source sector’s commitments are both set to nil.

💡

This mechanism doesn’t solve the problem of notifying clients (on- and off-chain) about the transfer. SPs will probably be incentivised to opt in to such notification to on-chain contracts by deal satisfaction requirements, but we should think about it some more.

💡

Showing that the destination data is the same will require the source unsealed CID (CommD) to be present on-chain, which we don’t have yet.

Internal changes

Implementation details to support the above.

Per-sector ExpectedDayReward, ExpectedStoragePledge and ReplacedDayReward are all removed from state (this 20% of all network state size today).
Sector ExpirationEpoch is removed. Proof expiration is calculated when needed as ActivationEpoch + 5 * EPOCHS_IN_YEAR.
Migration may be required for expiration queues, but maybe we can do it on the fly too.