Replacement Sealing Forcing Function & PoRep Security Policy (FIP-47prime)

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

This proposal builds on and supersedes FIP-0047.

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 Filecoin network uses cryptographic techniques to provide assurance of the physical uniqueness of sectors of data (proof of replication, or PoRep) and their ongoing availability (proof of space-time, PoSt). These mechanisms provide the proof of resources underlying the blockchain’s security (in addition to the security offered by pledge collateral stake). Some of the cryptography involved has been developed relatively recently. It is possible that there are errors in either the theory or implementation, or that errors may be introduced one day, that undermine the desired assurances. The result of such an error would most likely be that storage providers could “cheat” the network to claim they were maintaining more committed storage than they in fact possessed. This would reduce network security as consensus power could be gained without the expected physical infrastructure commitment. It is also unfair to non-cheating providers, assuming knowledge of the flaw was limited. In the case of an error in PoRep, it is likely that there would be no possible protocol change that could detect the cheating sectors after commitment.

This situation has already arisen once in the life of the Filecoin network. The v1.1 PoRep algorithm patched a bug in the v1 PoRep implementation that weakened the security assurances of sectors. The bug was responsibly reported to the Filecoin team and it is unknown if it was ever exploited by a provider. We are not aware of any similar bugs at this time. Filecoin storage is secure as far as we can ascertain.

The network today has an implicit policy on what to do if another such bug is detected:

The policy might thus be summarised as: put up with the potentially-insecure power for a limited period of time, but retain existing commitments of providers to the network and vice-versa. The 1.5-year window was selected as a compromise: a longer maximum commitment would be beneficial for storage stability, but a shorter bound improves the response time in case of a bug.

This policy depends on the 1.5y commitment expiration, and would lose effectiveness if the maximum commitment duration were raised.

The sector commitment duration (currently 1.5 years) is the period availability a provider commits to when first proving a sector. When a sector is close to expiration, a provider can extend the sector for up to the same duration again. This can be repeated until the sector maximum lifetime (currently 5 years), after which further extensions are prohibited.

It would be desirable to allow storage providers to make longer commitments to sectors (e.g. as proposed in FIP-0036, FIP-0056). Longer commitments support stability of network’s committed storage, could immediately support longer deals, and generally reduce the overheads of cycling sectors into the future. A higher possible maximum commitment duration would be beneficial regardless of any incentives toward longer commitments.

The authors assert that the implementation of a concrete mechanism, and rough consensus around policy, should be pre-requisite to increasing the maximum sector commitment duration.

Two new protocol parameters are defined:

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.

If we were to discover a flaw in PoRep theory or implementation:

This proposal does not require implementing the sector replacement mechanism until such time as it’s needed. Details of that mechanism may depend on the new PoRep algorithm.

However, acceptance of this proposal should be considered as ratification of this policy in general, so that emergency-response implementers can immediately design towards it.

No immediate migration is necessary. To decrease the complexity of the upgrade that implements the Replacement Sealing mechanism, the Miner state can begin tracking InitialOldSectors before the need for vulnerable sector deactivation arises.

This proposal is an evolution of FIP-0047, a proposal for a similar policy with a different execution method. While examining possible ways of optimizing the proof expiration schedule, we discovered a false core assumption. This assumption was “We need an expiration schedule.”.

This proposal removes the expiration schedule and replaces it with a forcing function mechanism by which Storage Providers must follow a sector replacement schedule. Otherwise, the network will impose incrementally severe penalties on them. This significantly simplifies the on-chain mechanism and doesn’t introduce gas-expensive operations in the critical period.

This reevaluation happened after the implementation of FIP-0047 was completed. During the implementation, the complexity of the additional scheduling mechanism was discovered when combined with the existing sector expiration mechanism. The currently existing sector expiration scheduling mechanism was designed to support two kinds of exclusive expirations: on-time and faults, the addition of a third, orthogonal type turned out to break numerous core constraints of this mechanism and lead to an explosion of complexity.

The forcing function mechanism presents much lesser implementation complexity due to not interacting with every sector but treating them as fungible. This reduced on-chain complexity has the drawback of requiring Storage Providers who choose not to seal replacement sectors to terminate them actively. This increases the operational complexity for these Storage Providers during the transitory period, but the dangers of that complexity can be reduced by SPs giving themselves headroom (i.e. SP can choose to stay three days ahead of schedule).

In our view, this is a worthwhile tradeoff, as the proof expiration mechanism would be a permanent increase to the complexity of the whole network (increased complexity of the expiration queue, periodic extension for every sector).

This proposal also outlines the policy for a disaster-response upgrade in order to align the community on a carefully designed plan and establish a foundation for a smooth network upgrade in the event of discovery of an insecure PoRep. The proposed Policy disallows extending the proof duration for any sectors sealed with vulnerable code in order to have the power attributed to insecure sectors decreases gradually as their proof validities expire. On the other side, sealing new secure sectors in order to maintain power is allowed by the replacement sealing and incentivized by applying a fee for sectors that are not replaced.

We hope that broad policy agreement now can facilitate smooth governance in response to any future emergency.

This upgrade can introduce necessary state changes in the Miner Actor instance, although these changes are not required for ratification of this FIP.

Impact on tooling should be minimal beyond changes to sector management software.

Will be included with the implementation to be presented.

Accepting the introduction of the enforcement mechanism for replacement sealing allows longer commitment durations without compromising the network’s ability to respond to flaws in PoRep.

If a flaw is discovered, an increased commitment duration would create the need for replacement sealing, or penalties for non-replaced sectors.

This proposal does not adjust incentives for providers or clients, but it does make longer sector commitments possible. Other proposals may then introduce incentives for such commitments.

In case of an emergency response, charging some termination fee when a sector proof is not refreshed creates an incentive to seal replacement sectors vs let old sectors expired un-replaced. Further analysis is warranted into the ideal termination penalty in this case. However, such analysis need not prevent us adopting this mechanism, for its other advantages, and policy, in order to provide greater clarity for storage provider business operations.

If the maximum sector commitment duration is increased, then a sector committed for longer than the DeactivationTarget period can be required to perform replacement sealing. This is a different operational position than a sector committed only for the DeactivationTarget period and then extended. In the latter case, because the sector was not committed to a longer period, no termination penalty if an enforcement mechanism is enabled. Committing a sector for longer than the DeactivationTarget period thereby introduces some operational risk to the provider.

The replacement sealing implementation is deferred until needed.

Copyright and related rights waived via CC0.