Reduce CC Sector Lifetime #255
Replies: 21 comments 5 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, @kaitlin-beegle,
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'.
Do we have any concrete data on this? Can we aggregate all ExtendSectorExpiration and make an estimation on how many CC can be retired?
When can one expect CryptoEconLab to offer their guidance on this? |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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?
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. |
Beta Was this translation helpful? Give feedback.
-
|
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... |
Beta Was this translation helpful? Give feedback.
-
This is certainly worth considering. |
Beta Was this translation helpful? Give feedback.
-
|
@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! |
Beta Was this translation helpful? Give feedback.
-
I think it might make more sense to consider |
Beta Was this translation helpful? Give feedback.
-
Wouldn't that still be a "threat to network stability"? |
Beta Was this translation helpful? Give feedback.
-
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.
By this design, token economic would stay the same as before at the expense of increased implementation challenges. |
Beta Was this translation helpful? Give feedback.
-
Adding to the above. https://filecoinproject.slack.com/archives/CEGN061C5/p1639705658273400 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@AxCortesCubero Thank you for the extensive insights! |
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
|
Hello, @AxCortesCubero, thanks for reply!
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? |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your insights! @anorth
Looking forward to the new pledge model design. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Here's an idea: Q: I want to have flexible network power 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 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 Disagree completely with this FIP and agree 100% with @f8-ptrk To counter the points given in the first post;
|
Beta Was this translation helpful? Give feedback.
-
|
@AxCortesCubero another potential use case for defi when beneficiary address and fvm are ready is that reduce CC could help SPs to get a better collateral coverage ratio than just having CC terminations (in case of when SP use their node as collateral for loans to build new nodes or expand existing ones). For example, assuming collateral coverage ratio is 130% and SP has a CC node with 130 FIL worth of collateral locked up in the node. If reduce CC were to be implemented, then SP could ideally borrow 100 FIL when it use its node as collateral for the loan (to either build a new node or expand existing operations, and maybe later use snapdeal to "dealfy" the node). Whereas with termination collateral coverage ratio will likely be much higher due to the potential risk of SP defaulting and lender not able to recover its lost from the node of the SP. |
Beta Was this translation helpful? Give feedback.
-
|
that can be done by replacing them with deals. honor your pledge. period |
Beta Was this translation helpful? Give feedback.
-
@f8-ptrk how is replacing them with deals gonna help the defi case? If SP defaults, less collateral would be collected from a termination. Plus the pledge is honored no matter what (even after reduce CC, by locking up the collateral till the original date when it is supposed to expire). |
Beta Was this translation helpful? Give feedback.
-
|
Sounds like the ask is to enable adding new commitments by intentionally to fail fulfilling the existing commitments first…🤷🏻♀️ |
Beta Was this translation helpful? Give feedback.
-
Could you please elaborate? |
Beta Was this translation helpful? Give feedback.
-
the pledge is not the locked FIL but storing the data as committed to the chain.... |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions