Add a ProofExpiration parameter to each sector, and describes a policy to be adopted in case a flaw is discovered in the theory or implementation of proof-of-replication (PoRep).
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 processing all sectors, and describes (but does not implement) a policy that uses the mechanism.
expiration (renamed to CommitmentExpiration) and proof expiration (a new sector property is introduced called ProofExpiration), and introduce a method RefreshProofExpiration() that can be used to request a refreshed proof expiration. A sector’s commitment may then be longer than its proof expiration.RefreshProofExpiration method is disallowed for sectors sealed with the vulnerable code. In order to maintain power, a provider must seal a new replacement sector before each existing sector’s ProofExpriration epoch is reached. If not replaced, a sector with a proof expiration before its commitment expiration will incur a termination fee (for example, the current sector early-termination penalty).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.