Simple Summary
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.
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 thePermittedOldSectors(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 thePermittedOldSectors
.
Motivation
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.
Current policy
The network today has an implicit policy on what to do if another such bug is detected:
- Implement a new, fixed PoRep algorithm
- In a network upgrade, the old algorithm is disallowed and the new one mandated for new sectors
- Old sectors are prohibited extension beyond the 1.5-year maximum commitment
- The power attributed to old sectors decreases as they expire and is extinct after 18 months. As new sectors are sealed, the insecure proportion diminishes even faster.
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.
Changing the maximum sector commitment duration
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). 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.
Specification
Mechanism
- New Miner state properties are introduced:
IntialOldSectors
- the number of sectors which have to be deactivated.DeactivatedOldSectors
- the number of old sectors 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 toDeactivationTarget
.- If
InitialOldSectors
is zero,DeacivationProgress
takes the value ofDeactivationTarget
. - 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
- 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 behind schedule, the deadline is marked as faulty. The deadline can be recovered when the deactivation is back on track. As inStartEpoch + 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, 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.
A new, larger, value for MaxSectorExpirationExtension
may be considered.
- If the current value of 1.5 years is retained, then a sector's initial commitment will always expire before its proof expiration is reached.
- If the value is increased, then a sector may take an initial commitment longer than the proof expiration, and so must be refreshed.
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.
Policy
If we were to discover a flaw in PoRep theory or implementation:
- A new, fixed PoRep algorithm would be implemented;
- In a network upgrade, the old algorithm is disallowed and the new one mandated for new sectors;
NOT DONE BEYOND THIS POINT
- A new method
ReplaceSector(OldSector, NewSector)
can be called by a provider to replace an old sector with a newly-sealed one. This requires a Storage Provider to run the sealing procedure with the new PoRep algorithm on the new sector (ie, successful call toPreCommitSector
andProveCommitSector
). Note that: - If the replacement sealing procedure is successful, the old sector is removed with no termination fee;
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.
Migration
During migration at network upgrade, each sector’s ProofExpiration is set to that value it would have
if it had initially been set to SectorActiviation + MaxProofDuration
and then refreshed
until the proof expiration is no less than the commitment expiration.
The ExpirationQueue
that exists in each miner partition will have the field early_sectors
renamed to faulty_sectors
, and will have a new field proof_expiring_sectors
that will consist of an empty bitfield at migraiton.
Design Rationale
Decoupling of sector commitment duration from proof duration allow providers to make long sector commitments (see FIP0036) without comprising the possibility of executing an “emergency” PoRep algorithm upgrade. The mechanism of explicit proof refresh must be implemented prior to recognizing any sectors with longer commitments, because it would be generally infeasible to schedule an orderly iteration over all sectors after the fact. This design implements a way to cycle over all sectors every 1.5 years. Note that, in response to a serious PoRep flaw, it would be possible to speed up the cycling by processing the proof expiration queue faster than 1 epoch per epoch.
A sector’s ProofExpiration
epoch is strictly derived from its activation epoch
in order to spread expirations out relatively evenly,
and with limited opportunity for storage providers to overload the network by scheduling them all at once.
The cost of this approach is approximately the same as the existing process for extending sector expirations every 1.5 years.
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.
Backwards Compatibility
This upgrade changes the schema for sectors and the miner expiration queue, and thus requires a network upgrade and sector state migration.
Impact on tooling should be minimal beyond changes to sector management software.
Test Cases
Will be included with implementation to be presented.
Security Considerations
Decoupling sector proof expiration from their commitment duration 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.
Analysis was conducted on the economic preference for a
reseal vs terminate early and re-onboard strategy in the context of a
PoRep bug requiring replacement sealing. Our aim was to understand the
tradeoffs and identify values for the ProofRefreshWindow
and Termination Fee Cap, such that the utility of a storage provider is
maximised when they conduct replacement sealing for their sectors. Our
results suggest that:
- A
ProofRefreshWindow
of approximately 30-60 days is optimal even in scenarios where the termination fee penalty is revised in the future, and SDM scaling of fee cap is implemented. A value of 60 days is thus adopted in order to guarantee operational convenience for storage providers during normal operations. - A 50-100 day block reward per sector termination fee is sufficient to drive storage providers towards the intended behaviour of resealing their sector in the case of a PoRep bug. But note that in the near future termination fees will likely need to be revised upwards: the current termination fees were set in the context of 6 month sectors, and revision soon after sector duration multiplier implementation (if accepted) is high priority.
A more detailed summary of our analysis can be found here
Incentive Considerations
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.
Product Considerations
If the maximum sector commitment duration is increased, then a sector committed for longer than its initial proof expiration must be refreshed, or it will be terminated with a penalty. This is a different operational position than a sector committed only as as long as the proof duration, and then extended. In the latter case, because the sector was not committed to a longer period, no termination penalty is applied if the extension is missed. Committing a sector for longer than the initial proof duration thereby introduces some operational risk to the provider, which must remember to and succeed in refreshing the proof within the refresh window.
Implementations
The CommitmentExpiration
and ProofExpiration
separation implementation is available at
filecoin-project/builtin-actors#518.
The replacement sealing implementation is deferred until needed.
Copyright
Copyright and related rights waived via CC0.