FIP draft: Extend sector fault cutoff period from 2 weeks to 6 weeks #190
Conversation
extend the cc sector fault period
IPFSUnion
requested review from
arajasek,
dignifiedquire,
jennijuju,
kaitlin-beegle,
momack2 and
whyrusleeping
as code owners
FIPS/fip-0025.md
Outdated
| ## Implementation | ||
| <!--The implementations must be completed before any core FIP is given status "Final", but it need not be completed before the FIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.--> | ||
|
|
||
| TODO in all related Filecoin implementations. |
There was a problem hiding this comment.
One note - to avoid complicated implementation in spec actor that needs state migration(will require heavy testing), we are proposing to only raise FaultMaxAge to the extended period. However, this means, for any sector is declared as faulty before the upgrade epoch, their expiration period stays 14 days.
There was a problem hiding this comment.
@ZenGround0 do you have a draft PR for this change?
|
We can differentiate between CC and non-CC sectors, but we'd need to do a state migration that would take time to develop and test. If we don't differentiate between the two, this would be a pretty raw deal for clients. They'd be stuck with locked up funds for 42 days and no way to know if they'll eventually get them back or not. Honestly, even 14 days is too long for that. It may be possible to allow clients to "cancel" their deals if a sector is faulty for some period of time, but the UX is of that is pretty poor. |
FIPS/fip-0025.md
Outdated
|
|
||
| Any country in the world is likely to face force majeure factors such as major natural disasters or social abnormal events, causing storage providers to be unable to provide services normally for a long period of time. To this end, we must plan ahead. | ||
| In the current implementation of the protocol, the sector will be forcibly terminated if there are two consecutive weeks of faults. However, two weeks is not enough for a large storage provider to complete the data migration and restart the service. If appropriate measures are not taken, it will not only cause huge economic losses to the storage provider, but also cause large fluctuations in the storage power of the entire Filecoin network. | ||
| Therefore, it is necessary to make some adjustments to the sector fault period. Regarding the deal sector, the current data of all transactions is about 32 PiB. It is not a big problem to complete the real data migration within two weeks, but it is far from enough for the EiB level of cc sector to complete the migration within two weeks, so we propose to extend the cc sector fault period from 2 weeks to 6 weeks. |
There was a problem hiding this comment.
| Therefore, it is necessary to make some adjustments to the sector fault period. Regarding the deal sector, the current data of all transactions is about 32 PiB. It is not a big problem to complete the real data migration within two weeks, but it is far from enough for the EiB level of cc sector to complete the migration within two weeks, so we propose to extend the cc sector fault period from 2 weeks to 6 weeks. | |
| Therefore, it is necessary to make some adjustments to the sector fault period. Regarding the deal sector, the current data of all transactions is about 32 PiB. It is not a big problem to complete the real data migration within two weeks, but it is far from enough for the EiB level of cc sector to complete the migration within two weeks, so we propose to extend the sector fault period from 2 weeks to 6 weeks. | |
such a change needs to apply to both cc and deal sectors equally from a cryptoeconomic perspective. But agree that SPs can and should prioritize migrating deal sectors faster
There was a problem hiding this comment.
all cc have been removed in the commit below.(1aff8d5)
|
I believe this FIP and its various comments/suggestions needs to be resolved & merged by end of week and approved in the Core Devs meeting on Thursday to be included in the upcoming Chocolate v14 network upgrade. Otherwise, this improvement proposal will be deferred to the next scheduled network upgrade in ~2022. |
Co-authored-by: MollyM <[email protected]>
Co-authored-by: Jiaying Wang <[email protected]>
Co-authored-by: MollyM <[email protected]>
Co-authored-by: MollyM <[email protected]>
Co-authored-by: MollyM <[email protected]>
FIPS/fip-0025.md
Outdated
| ## Product Considerations | ||
| <!--All FIPs must contain a section that discusses the product implications/considerations relative to the proposed change. Include information that might be important for product discussion. A discussion on how the proposed change will enable better storage-related goods and services to be developed on Filecoin. FIP submissions missing the "Product Considerations" section will be rejected. An FIP cannot proceed to status "Final" without a Product Considerations discussion deemed sufficient by the reviewers.--> | ||
|
|
||
| Increasing the sector forced termination window increases the potential time between when a storage provider could stop storing/proving data to the network, and when storage clients would have their payment refunded. This could be annoying/frustrating from a sector repair perspective, since there is a longer window before it is clear whether a storage provider is coming back online, which the client isn't compensated for. |
There was a problem hiding this comment.
What does sector repair mean here?
There was a problem hiding this comment.
i am pretty confident it means:
from the perspective of restoring the storage/deal replication scheme a client uses
but i am not sure either.
as a client you have a choice to make to keep your data stored in a "safe" manner. if a storage provider faults the sector the deal is in you can:
- wait for the sector to come back - up to 14 days
- store a new copy in < 14 days, declare the old copy dead
expanding 14 days to 42 will change the calculation when re-storing (in the sense of: store it again) a deal makes financial sense - if a sector recovers from a fault the client will have to resume payment and with 42 days, i plain assume this, the financial risks of "over storing" is bigger for the client then with 14 days.
[edit]
this has terrible consequences for platforms/facilitators that guarantee a certain service level of storage replication.
FIPS/fip-0025.md
Outdated
| @@ -0,0 +1,80 @@ | |||
| --- | |||
| fip: "0025" | |||
There was a problem hiding this comment.
This is FIP0026.
It's not a problem, but for the future, do not worry about adding a FIP number. A FIP editor will do this for you.
FIPS/fip-0026.md
Outdated
| ## Implementation | ||
| <!--The implementations must be completed before any core FIP is given status "Final", but it need not be completed before the FIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.--> | ||
|
|
||
| TODO in all related Filecoin implementations. |
There was a problem hiding this comment.
We should note that this proposal would be implemented in the v14 Chocolate network upgrade, and that the proposal will not go into effect until that time.
If a storage provider were to fault on their Window PoSt submission before the upgrade (scheduled for the end of October), they would still be bound to the 14 day fault sector period. On day 15, for example, they could experience sector termination even if this FIP had been approved.
It is important that this detail be clarified so that storage providers who imminently seek to relocate their data do not miscalculate their financial exposure during migration.
|
|
||
| The maintained FaultFee structure provides strong incentives for storage providers to maintain great quality of service and keep any downtime to a bare minimum. | ||
|
|
||
|
|
There was a problem hiding this comment.
Emphasizing that this proposal seeks to extend the fault window without recalculating the fault fees schedule.
As pointed out by @Stebalien, @ZenGround0, and others on the 10/7 Core Devs call, it remains fundamentally irrational for storage providers to choose to fault on sectors for an extended period of time. This reinforces the idea that this extended fault period ought to be viewed as a worst-case-scenario provision, rather than a benchmark for how long someone could reasonably take data offline. It would still be prohibitively expensive to do so (it's been suggested that this cost approximates half a year's profit as a storage provider) and is therefore unlikely to incentivize unreliable storage behavior.
There was a problem hiding this comment.
It would still be prohibitively expensive to do so (it's been suggested that this cost approximates half a year's profit as a storage provider) and is therefore unlikely to incentivize unreliable storage behavior.
that depends on the FIL price and what amount of FIL the storage provider asks for for deals.
if the FIl price is 1$ and the storage provider asks for 50$ in FIL / 10TB / month then not proving is the way way way better option than termination.
how expensive that is is unknown for everything that is not on chain yet.
There was a problem hiding this comment.
Good point, Patrick. However the incentive hierarchy of reliable storage >> temporarily unproven storage >> terminated/failed storage is still strongly maintained by the fee structure -- which mirrors the user needs too =]
jennijuju
changed the title
|
FYI you can update implementation and test info with links and info here: Implementation: filecoin-project/specs-actors#1504 |
| discussions-to: https://github.com/filecoin-project/FIPs/issues/189 | ||
| status: Draft | ||
| type: Technical (Core) | ||
| created: 2021-10-01 |
There was a problem hiding this comment.
please add spec-sections and update the spec upon the fip acceptance filecoin-project/specs#1279
Co-authored-by: Aayush Rajasekaran <[email protected]>
No description provided.