Alleviate network penality

[ozhtdong]

Two FIPs are included in this PR

FIP0016 - Emergency and temporary measure before FIP0017 is realized, network wide penalty alleviation, should only happen when majority of the network power will be cut in short time period and those power can be restored afterward.

FIP0017 - A more sophisticated solution which will allow miners to choose their own maintenance window based on their own situation.

[jennijuju]

Thanks for submitting!

[mxz9102]

If I store files with a miner and its owner declares the miner is in maintenance, how can I retrieve files during the maintenance window? Can the miner just take the storage payment and declare maintenance based on their own needs? This will not be good for clients because the maintenance is unpredictable and it can decrease quality of file storage service.

[ozhtdong]

If I store files with a miner and its owner declares the miner is in maintenance, how can I retrieve files during the maintenance window? Can the miner just take the storage payment and declare maintenance based on their own needs? This will not be good for clients because the maintenance is unpredictable and it can decrease quality of file storage service.

A force majeure event might cause retrieve files impossible for the time being whatever if miner declare maintenance or not. To your second point, a daily penalty fee need to be introduced during maintenance to make it economically inefficient for the miners to abuse it, while penalty is not too hash (3.51 br per sector) that miner rather abandon their node and client lose their data once for all.

[ZenGround0]

My reading of the proposed implementation is that we will need a v15 state migration to correctly implement this FIP: https://github.com/filecoin-project/specs-actors/pull/1440/files#r644859590. If we move forward with this FIP it will need more actor implementation details to move forward.

[arajasek]

Thanks for submitting this PR and the great discussion in the Core Devs meeting. Summarizing some discussion as well as my own opinion:

• The proposal is well-motivated, natural disasters are rare but do occur
• Unfortunately, compromises Filecoin's storage guarantees about proving storage
• Security considerations definitely need a lot of analysis too
• @jbenet flags that integrating a Natural Disaster Oracle would make this better

I would vote against landing this PR, but we can definitely get more feedback from the community.

[Stebalien]

(my opinion, not official)

First, "maintenance" windows are usually on the order of a few hours at most. If a storage provider told me my data wasn't going to be available for many days, I'd walk away. Filecoin's primary goal is to become a decentralized storage network, so any form of extended maintenance window would set a very bad precedent.

Second, depending on the actual problem, downtime may not even be necessary. There are three core operations performed by Filecoin miners:

1. Sealing (adding new storage).
   • This process is power intensive.
   • This process does not need access to existing sectors and can be moved quickly.
   • This process can be done by a third-party without handling cryptocurrencies.
2. Proving (proving existing storage, proving "winning" tickets).
   • This process is (relatively) low-power, as far as I understand.
   • This process requires low-latency access to existing sectors.
   • This process can be done by a third-party without handling cryptocurrencies.
3. Mining (creating new blocks)
   • This process is very low-power.
   • Block production does not require access to existing sectors.
   • This process generally involves FIL (cryptocurrencies).

The difficult part of "moving" is moving the proving operation (sealed sectors). While it would require some implementation work, it's entirely possible to pause/move sealing/mining with no downtime and no protocol changes.

So:

1. If the problem is electricity, this can be solved without downtime by sealing all new sectors somewhere else.
2. If the problem is cryptocurrencies, everything but proving (window post and winning post) can be moved elsewhere.

[momack2]

I think the question @Stebalien is asking above is "are there better ways to achieve the goals of this FIP that don't create forced downtime for Filecoin storage clients?"

1. The Filecoin Network cannot offer an effective decentralized storage service to clients if it can't prove that Filecoin storage providers are correctly storing client data over time.
2. An unreliably storage system is much less valuable to potential clients, so being highly reliable is in the best interest of the network as a whole.
3. Therefore - solutions to any current challenges for storage providers that continue to prove that client storage is reliably being maintained (and made accessible for retrieval!) over time should be highly preferred by all network actors.

This is one proposal - but potentially there are other mitigations that achieve the same desired goal?

[jennijuju]

Seems like this FIP needs more discussion before a Draft FIP - moving the conversation to #103. please reopen the PR later when there is a revised the proposal!