PoRep Security Policy & Replacement Sealing Enforcement (FIP-0067)

[Kubuxu]

Simple Summary

Describes a policy to be adopted in case a flaw is discovered in the theory or implementation of proof-of-replication.

Link: FIP-0067

This proposal builds on and supersedes FIP-0047.
Discussion of FIP-0047: #415

Abstract

We are not aware of any PoRep issues at this time, but it is crucial to have a plan to deal with any possibility.
This proposal introduces a concrete mechanism for enforcing replacement sealing for sectors with a commitment longer than 1.5 years and describes (but does not implement) a policy that uses the mechanism.

• The mechanism is to note the number of active sectors on-boarded using vulnerable PoRep (InitialOldSectors) for each Storage Provider when introducing the replacement sealing mechanism. Escalating penalties are applied to Storage Providers when the number of active old sectors exceeds the PermittedOldSectors(InitialOldSectors, epoch).
• The policy is that, in case of a PoRep flaw, the value of the PermittedOldSectors function decreases over time, reaching zero 1.5 years after introducing replacement sealing.
  In order to maintain power and continue producing blocks, a Storage Provider must seal a new replacement sector, thus deactivating an old sector. Alternatively, a Storage Provider can terminate old sectors such that the number of active old sectors is less or equal to the PermittedOldSectors.

Mechanism

• New Miner state properties are introduced:
  • IntialOldSectors - the number of sectors that must be deactivated. Sectors with expiration before the DeactivationTarget will not be counted towards InitialOldSectors.
  • DeactivatedOldSectors - the number of old sectors with expiration beyond DeactivationTarget which have been deactivated.
• New parameters are introduced:
  • GracePeriod - duration in epochs during which the replacement sealing is active, but no enforcement actions are taken. Initial proposal 60 days.
  • DeactivationTarget - duration in epochs after which all old sectors should have been deactivated. Initial proposal 1.5yr.
  • StartEpoch - upgrade epoch when the replacement sealing is enabled, and the deactivation timeline starts.
• New computable property DeactivationProgress of the Miner state is introduced:
  • DeactivationProgress(InitialOldSectors, DeactivatedOldSectors) takes the value of the progress of a given Miner actor instance along the deactivation timeline. It values from 0 to DeactivationTarget.
  • If InitialOldSectors is zero, DeacivationProgress takes the value of DeactivationTarget.
  • No enforcement actions are taken against the Storage Provider if DeactivationProgress(...) == DeactivationTarget.
  • No enforcement actions are taken against the Storage Provider if
    StartEpoch + DeactivationProgress(...) >= CurrentEpoch()
  • Definition of DeactivationProgress is as follows:
    DeactivationProgress(InitialOldSectors, DeactivatedOldSectors) := GracePeriod + (DeactivationTarget - GracePeriod) * DeactivatedOldSectors // InitialOldSectors
• When a sector with Expiration > StartEpoch + DeactivationTarget is deactivated, either through replacement sealing or explicit termination, the DeactivatedOldSector is incremented.
• To facilitate sector replacement and deactivation policy, following enforcement actions are introduced:
  • Block Production Eligibility - Miner actor is not eligible to produce new blocks if StartEpoch + DeactivationProgress(...) < CurrentEpoch()
    This has a drawback of power table inflation which is resolved by the following enforcement policy.
  • Deadline Faults - if during deadline validation DeactivationProgerss is detected to be more than 24h (discuss) behind schedule, the deadline is marked as faulty. The deadline can be recovered when the deactivation is back on track. As in StartEpoch + DeactivationProgress(...) >= CurrentEpoch(). Fault fees are charged until the deadline is recovered.
  • Deadline Termination - if during deadline validation DeactivationProgress is detected to be more than 7d behind schedule (discuss), the deadline is terminated. The deadline cannot be recovered, and the Miner instance is charged termination fees.

Parameters

Two new protocol parameters are defined:

• GracePeriod - duration in epochs during which the replacement sealing is active, but no enforcement actions are taken. Initial proposal 60 days.
• DeactivationTarget - duration in epochs after which all old sectors should have been deactivated. Initial proposal 1.5yr.

Given this change, a new, larger value for MaxSectorExpirationExtension may be considered.

If MaxSectorExpirationExtension is increased, then the built-in storage market's
maximum deal duration is increased to match. This could permit deals up to 5 years in duration.

[luckyparadise]

Hey @Kubuxu thanks for this. How quickly are you hoping this can be shipped and included as part of a network upgrade? I am asking so I know if this can make it in time for nv21. Are other teams aware and part of the spec design for this new FIP?

[Kubuxu]

This FIP would primarily establish a mechanism for responding to PoRep breakage for alignment purposes. Its immediate implementation in the form of code is not required.

[anorth]

Thank @Kubuxu. I think it is worth highlighting the distinction of this proposal from FIP-0047. Note that FIP-0047 is already accepted by governance, but (thankfully) not yet implemented. Proposing penalties sounds harsh, but in my view this new proposal is much more friendly to SPs while still achieving the goals of an orderly turnover of potentially-compromised sectors.

FIP-0047

• Each sector is given a specific epoch by which it must be replaced/terminated.
• An SP has ~no control over which epoch each specific sector is assigned, hence the sequence of replacements
• An SP with limited sealing capacity cannot necessarily allocate it to the highest-replacement-value sectors, if they are bunched together
• An SP might face highly uneven distribution of replacement obligations over the 1.5y period
• The network replacement load is not uniform over time, just hoped-for kind-of by averaging across SPs
• Failure to replace on schedule leads to immediate termination

This proposal

• An SP has complete freedom over the sequence of replacing sectors, so long as they stay on schedule in aggregate
• An SP with limited sealing capacity can dedicate it to their highest value sectors, and terminate only low value ones
• An SPs replacement schedule is uniform over the 1.5y period
• The network replacement load is uniform over the 1.5y period
• Failure to replace on schedule initially leads only to recoverable faults, before eventually termination

This is all thanks to an error in FIP-0047, which states "it would be generally infeasible to schedule an orderly iteration over all sectors after the fact". We found a way to do just that.

[anorth]

A discussion for core devs: if we accept this as a policy, how much of the mechanism, if any, should we implement now, ahead of possibly discovering a flaw that would use it?

We could implement this entire mechanism (but set InitialOldSectors to zero). Then in case of emergency, all we need to do is calculate InitialOldSectors and set the epoch parameters.

But it's most likely the mechanism will never be used. So we could also do nothing now. Then in case of emergency we will have to do more complex implementation work in a hurry.

[Tanisha-fil]

Hello everyone,

I propose converting FIP 0067 from a Filecoin Improvement Proposal to a Filecoin Request for Comments (FRC).

The content of this proposal is better suited as an informational document or standard specification rather than a protocol-changing improvement that requires network consensus.

This conversion will not change the core content or objectives of the proposal, but will ensure it receives the appropriate level of community discourse and follows the most suitable governance pathway.

If there are no objections, this change will be actioned after the Core Devs call on 5th June, 2025.

Note: This is also posted on the Slack Channel #fil-fips for community visibility.

[jsoares]

Deferring to core devs here, but I wonder what's to be gained from this reclassification. This is an old, accepted, and deferred proposal. I agree it isn't an exact fit for a core FIP, but, per FIP-0001, this would likely be more of a FOP than an FRC, in that it defines an accepted procedure to respond to a critical issue. Not that we've ever done one of those.

[irenegia]

Based on the description of FOP, especially the part about "unlike Informational FIPs, {FOPs} they are more than recommendations, and users are typically not free to ignore them.", I agree with @jsoares 's comment and propose keep fip 0067 in the FIP list (classifying it as a FOP)!

[Kubuxu]

It is a FIP (possibly FOP), certainly not FRC. This document outlines the community consensus on what to do in case of PoRep breakage.
The fact that it carried no immediate changes to consensus-critical code should not affect its classification.