FIP Discussion: Reduce CC Sector Lifetime
neogeweb3 opened this issue · 20 comments
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
-
As network parameters changes, storage providers may find shorter CC lifespan to be more favorable, adapting their storage strategies.
-
Storage providers may be out of cash flow, have trouble sustaining its business or simply go bankrupt.
-
IDC hosting storage provider's hardware may go out of business or evict storage provider for some reason.
-
Natural disaster.
-
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.
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.
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?
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
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.
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...
maybe we should consider allowing V1 sector to extend another 540 days
This is certainly worth considering.
@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!
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)
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"?
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.
- Natural disaster.
Adding to the above. https://filecoinproject.slack.com/archives/CEGN061C5/p1639705658273400
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.
@AxCortesCubero Thank you for the extensive insights!
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).
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?
Thank you for your insights! @anorth
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)
Looking forward to the new pledge model design.
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).
There are different possible ways parameters could be balanced, depending on what we want to keep constant or optimized (for instance total percentage of circulating supply that is locked at any time by collateral, in my comments). With every change comes compromise, and no protocol-level change should be taken lightly and without sufficient motivation (as @anorth mentions, it can be questioned whether sufficient motivation is presented here, given that it is possible to account for these risks in other ways). Increasing the pledge amount to deal with shortening of locking period will surely be met with other resistance too.
@Fatman13 Your suggestion, as I understand, to allow the release of collateral, but only under the condition that it be used to seal new sectors, encouraging growth, is interesting, and not something I have considered in my previous notes. It is not the simplest solution though, as it would require some engineering effort and quite a few new variables to understand. I would consider it a longer term possible goal.
@Fatman13 Your suggestion, as I understand, to allow the release of collateral, but only under the condition that it be used to seal new sectors, encouraging growth, is interesting, and not something I have considered in my previous notes. It is not the simplest solution though, as it would require some engineering effort and quite a few new variables to understand. I would consider it a longer term possible goal.
Yes! And if SPs couldn't manage to seal new sectors before the original CC lifetime (say 540 days), only by then collateral would be returned to miner available balance. Thus preserving the token economics. Protocol revenue may lose some windowPost income due to this change but should be minor.
storage providers can replace CC sectors with deals. the possibility to pledge CC sectors for only 180 days was always there. i see no reason for allowing storage providers to not honor their pledge "for free". this is the 4th? 5th? FIP regarding not honoring your pledge/prove your storage without the need to pay the fees that come with that break of the pledge.
Here's an idea:
Q: I want to have flexible network power
A: Pledge for a shorter duration
Q: I want all the money I put in collateral back so I can sell because I think the coin is about to drop in value
A: Your (our) initial promise is what made the coin's price in the first place
Q: There's a big fire near our DC and our data is at rist of being destroyed so we need to quickly remove the CC without paying a penalty
A: Move away from the fire.
A: Make sure you have backups (you're a storage provider)
A: Don't commit to storing X for Y amount of time if you're not sure you can store X for Y amount of time
Disagree completely with this FIP and agree 100% with @f8-ptrk
To counter the points given in the first post;
-
As network parameters changes, storage providers may find shorter CC lifespan to be more favorable, adapting their storage strategies.
If they change (due to FIPS for example), there should be good reasoning behind it and those things will be taken into account appropriately, such as giving users a choice or keeping things backwards compatible. -
Storage providers may be out of cash flow, have trouble sustaining its business or simply go bankrupt.
Then you failed as a storage provider. Can't do simple math regarding cashflow? Don't open up a PiB/EiB scale cloud storage solution business. -
IDC hosting storage provider's hardware may go out of business or evict storage provider for some reason.
You chose the wrong IDC. I refer back to 2. You made a bad decision. -
Natural disaster.
You chose the wrong location and bad backup strategies. I refer back to 2: You made a bad decision. -
Local regulation/law forcing closure of storage providing business.
You chose the wrong location and to provide this service. I refer back ot 2: You made a bad decision.