FIP Discussion: Reduce CC Sector Lifetime

[neogeweb3]

Summary

Allow storage providers to reduce/cut/slash CC sectors down to a minimum lifetime of 180 days.

Motivation

For the good of Filecoin network in the long run, granting reduce/cut/slash CC to storage providers combined with existing extend CC will give storage providers more tools to adjust their storage strategies when facing changes in network parameter, force majeure or other concerns. The filecoin network will in turn be benefiting from a collection of more nimble storage providers who could properly react to the general storage "climate" during any particular time.

Use Cases

1. As network parameters changes, storage providers may find shorter CC lifespan to be more favorable, adapting their storage strategies.

2. Storage providers may be out of cash flow, have trouble sustaining its business or simply go bankrupt.

3. IDC hosting storage provider's hardware may go out of business or evict storage provider for some reason.

4. Natural disaster.

5. Local regulation/law forcing closure of storage providing business.

Considerations

To conform to security and token economics of filecoin, CC sectors should only be allowed to reduce to a minimum lifetime of 180 days. For a CC sector that has already lived more than 180 days, reduce/cut/slash CC effectively "terminate" the CC sector without incurring penalties. For a more conservative design, a small penalty may be imposed but should be less than using terminate command.

[kaitlin-beegle]

Hi @neogeweb3! Thanks for submitting this idea!

At first glance, this proposal seems to enable storage providers to 'slash' CC sector lifetimes to 180 days without penalty. Given the the current longevity of many CC sector lifetimes, this would allow storage providers to effectively retire many CC sectors instantaneously and without penalty.

Such a change could prove to be a significant threat to the stability of overall network power. As such, I've shared your idea with the CryptoEconLab so they can provide more guidance on the cryptoeconomic feasibility of this proposal.

[Fatman13]

Hello, @kaitlin-beegle,

At first glance, this proposal seems to enable storage providers to 'slash' CC sector lifetimes to 180 days without penalty.

The expectation is that storage providers wouldn't invoke reduce CC frequently unless they would like to change their storage strategy. Besides, the gas fee incurred can't just be ignored if it adopts the same gas model as extend CC, which is about quite high when basefee is high. So it is not without any 'penalty'.

Given the the current longevity of many CC sector lifetimes,

Do we have any concrete data on this? Can we aggregate all ExtendSectorExpiration and make an estimation on how many CC can be retired?

As such, I've shared your idea with the CryptoEconLab so they can provide more guidance on the cryptoeconomic feasibility of this proposal.

When can one expect CryptoEconLab to offer their guidance on this?

[jennijuju]

or a CC sector that has already lived more than 180 days, reduce/cut/slash CC effectively "terminate" the CC sector without incurring penalties

I think the SPs that break any sort of commitment to the network should be penalized. i think like Kaitlin mentioned, if SP may retire sectors w/o penalty, it may cause sudden network power drop, circulating supply incease due to unlocked IP, market instability due to demand vs supply change and so on

[Fatman13]

I think the SPs that break any sort of commitment to the network should be penalized. i think like Kaitlin mentioned, if SP may retire sectors w/o penalty, it may cause sudden network power drop, circulating supply incease due to unlocked IP, market instability due to demand vs supply change and so on

The network is already expecting a ~1.5EiB power loss due to expiring V1 sector, which means network at this point implicitly tolerates EiBs of volatility. If network stability is of high concerns, maybe we should consider allowing V1 sector to extend another 540 days, as we see no interest in developing specialized hardwares for windowPost right now on the market?

For a more conservative design, a small penalty may be imposed but should be less than using terminate command.

In the original proposal it also mentioned a conservative design with penalty. But it all boils down to when CryptoEconLab could offer their guidance on this.

[neogeweb3]

SPs economically wouldn't reduce/cut/slash huge chulk of CC sectors instantaneously unless they have to, because keeping these sectors up and running is very profitable even with median operation cost. Sealing these CC sectors are fairly operational expensive, reduce/cut/slash them means SPs give up all the future profit of remaining lifetime on these CC sectors. This FIP is acting as the last line of defense for SPs when force majeure occurs like mentioned above in the Use Cases.

Frankly speaking, when the majeure occurs, volatility of Filecoin network power is inevitable, with or without this FIP...

[anorth]

@nicola

maybe we should consider allowing V1 sector to extend another 540 days

This is certainly worth considering.

[anorth]

@neogeweb3 @Fatman13 could you please provide more detail about situations when a shorter lifetime may be more favourable or the kinds of strategies that might benefit from this? I know you linked to some Slack threads, but I think it would make a big difference to sketch out some real or realistic scenarios for us to analyse.

Like most protocol stewards I would err towards the network enforcing commitments, and accept that sometimes a provider might make a commitment they can't keep due to either insufficient analysis or a strong exogenous shock, and they'll have to wear that cost. But I'm also open to the idea that we haven't thought about these operational scenarios as much as you and could be overlooking things.

You have to paint the full picture for us, though. Please convince me!

[jennijuju]

@nicola

maybe we should consider allowing V1 sector to extend another 540 days

This is certainly worth considering.

I think it might make more sense to consider enable an easy way to upgrade and reseal v1 sectors into v1.1 sectors instead as mentioned in this comment
#222 (comment)

[Fatman13]

I think it might make more sense to consider enable an easy way to upgrade and reseal v1 sectors into v1.1 sectors instead as mentioned in this comment

Wouldn't that still be a "threat to network stability"?

[Fatman13]

could you please provide more detail about situations when a shorter lifetime may be more favourable or the kinds of strategies that might benefit from this?

Sure thing. Say, SP seal CCs of 540 day lifespan with 9 FIL as collateral per 1TiB of sectors on day 1. As network grows, maybe on day 300, collateral for 1TiB of sectors goes down to 4 FIL. If reduce CC were to be implemented, SP could actively leverage the collaterals they pledged on day 1 to double the amount of storage power they commit to the network, meaning using 9 FIL to pledge 2TiB in this example. This is one way of optimizing SP's storage strategy.

For concerns on SP's commitments to the network, I propose one simple design (which potentially complicates the protocol further) could enforce commitments as following...

Have two flags for SP to use for either A) reduce CC to pledge more power or B) reduce CC due to force majeure.

• In case A, after reducing CC, the commitments (collaterals) are not returned to miner's available balance but to a locked account that can be used as funds for pledging more sectors.
• In case B, after reducing CC, the commitments (collaterals) are not returned to miner's available balance but to a new locked funds account until the original committed date is reached.

By this design, token economic would stay the same as before at the expense of increased implementation challenges.

[Fatman13]

4. Natural disaster.

Adding to the above. https://filecoinproject.slack.com/archives/CEGN061C5/p1639705658273400

[AxCortesCubero]

This issue relates to an ongoing project we have been considering at CryptoEconLab. (I post a write-up of the work in progress here, for the mathematically inclined. https://hackmd.io/@R02mDHrYQ3C4PFmNaxF5bw/r117DMU9Y )

We have been studying the theoretical question of how much percentage of the total FIL supply is expected to end up being locked up by collateral (in the above write-up, only consensus pledge is considered, but similar arguments apply to block reward collateral), in the case where, as mentioned by @Fatman13 above, the cost of collateral decreases over time, so it becomes a good idea for SPs when given the opportunity, to terminate their sectors and reseal them, paying a lower current-time collatera (Note that this is not always the case / this is only the case under a few specific conditions as specified in the write up)l.

Therefore there is an issue, which is that the percentage of FIL supply that is locked up as collateral, depends in a non-trivial way on the locking period. What we are studying in the above link is how this percentage of locked FIL decreases as the locking period is reduced. Generally the idea is that greater locking period means more Locked FIL.

Any proposal that intends to in some way reduce locking periods, leads to an increase in the circulating supply, which as mentioned by @jennijuju could cause some market instability.

One way to counter the effect of reducing locking periods, is to increase the price of collateral initially paid, the two may be balanced to keep total amount of Locked FIL unchanged.

[jennijuju]

@AxCortesCubero Thank you for the extensive insights!

[anorth]

Thanks for the further discussion.

With regard to the various possible events grouped under "force majeure", I am not very sympathetic. In my opinion, business failure, supplier or counterparty risk, regulatory risk, and simple disaster recovery (i.e. backups) are exactly the kind of risks that storage providers are paid to manage. Some of the recent stresses on providers, while understandably upsetting to those affected, may have been good for network in the long run by encouraging appropriate business analysis of these risks and promoting diversity, DR plans etc. I don't think it makes sense to allow a provider to reneg on a capacity commitment in these cases.

The other cause is a change in the pledge dynamics. We can and should evaluate this as a purely cryptoeconomic situation which we can address without terminating any sectors early. It amounts to an observation that the collateral locked for a sector depends highly upon the date at which it was committed, but that past should have little relevance to the future economics of maintaining the sector. At any present moment, all sectors CC are homogenous, yet they are treated as highly differentiated. I can certainly see we might be able to find better models. Anything that amounts to a simple reduction in the pledge amount is unlikely to be viewed positively, but I'd be interested to explore mechanisms that would support the commitment of more capacity for a fixed amount of pledge (though of course that could decrease the rate of increase of pledge).

[Fatman13]

Hello, @AxCortesCubero, thanks for reply!

Any proposal that intends to in some way reduce locking periods, leads to an increase in the circulating supply, which as mentioned by @jennijuju could cause some market instability.

That's why I proposed in the above to have a design to reduce CC but still keep locking period. (You only get collateral back as your original locking period ends) Would that fix the token economics?