Proposal for simple increase to max sector commitment duration #475
Replies: 7 comments 20 replies
-
|
Why 5 years? |
Beta Was this translation helpful? Give feedback.
-
|
I think extending deals is a complex situation as the client has to be involved (lock in additional FILs to the market in case of non-verfied, or lock-in additional data cap). So there has to be some sort of back and forth automated process where the SP or the Client requests a deal extension. In regards to this FIP compared to FIP-0036, I don't mind it so much as there is no multiplier, which means that our QAP is not going to melt like snow in the sun overnight. If the existing "CC providers" want to continue to use their existing sectors by extending them, there is little to no impact on our operations. I think limiting sector life in the first place was a mistake. Filecoin is clearly positioned as an "archive" storage in the market, which to me means long-term... 18 months is not long-term, so to sell the solution to customers, we need longer deal terms |
Beta Was this translation helpful? Give feedback.
-
|
we have a chance here to uncouple sector duration/lifetime and deal duration once and for all. by allowing snapping into deal sectors and deal extensions. from a strategic view allowing us to not only be only "archive storage" but a way to be more than that. imagine you could resnap a sector that got DMCA'ed and even deliver a proof of having done so - on chain! (to just name a random example of all the possibilities) For sure this proposal is better than fip36 but it has some of the same problems fip36 brought up. they will come up again and again and again when duration/lifetime and multipliers are proposed. why rush it? why not implement a clean solution to allow this to be uncoupled from deals? |
Beta Was this translation helpful? Give feedback.
-
|
@f8-ptrk actually this is exactly what is being done, it just takes a lot of work. Read the motivation (and pre-announcement) of this FIP here: #313 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
@f8-ptrk resnap and deal renewal are different problems in parallel of such proposals. Deal renewal doesn’t have to be built on protocol level and it might be a use case enabled by FVM m2 with smart contract. There are other ideas like be able to move deals to new sectors and such. |
Beta Was this translation helpful? Give feedback.
-
There is no multiplier here. The reason extension with multipliers causes a problem for existing deal sectors is due to comparative competitive disadvantage in ability to multiply power. The proposal points out there is very little incentive to commit long-duration CC sectors. They can be extended incrementally all the way to 5 years today. You can do the same with a deal-sector (but its power will drop toward the CC-equivalent rate for the extended period).
These are impossible until FIP-0045 lands. After that, we can work towards those, but they're still complex. This proposal is simple and brings the immediate client benefit for new sectors, and any FIL+ allocation created after nv17 will be extendible too. But please take this conversation to a new discussion – it's not a helpful critique of this proposal but a welcome discussion generally. You might consider #298 first, where you will see I have been working towards these features since February. |
Beta Was this translation helpful? Give feedback.
-
|
I think this is a no-brainer (dependent on FIP-0047) positive upgrade for the network when decoupled from any changed incentive scheme. It would be very simple to implement and would allow for long-term deals immediately! |
Beta Was this translation helpful? Give feedback.
-
|
Is this proposal moving forward? Hoping this can get implemented soon. |
Beta Was this translation helpful? Give feedback.
-
|
@NSC-FIL, very likely. I believe we will discuss tomorrow at the core-devs call whether this will be included in the next network upgrade. |
Beta Was this translation helpful? Give feedback.
-
|
I have drafted a FIP here: #558 In this draft, I have reduced the maximum commitment duration to 3.5 years. This is so as to reduce any potential conflict with #554 and because it's safe and easy to increase later. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for minimising potential for conflict with #554. Can we expand on why it's safer? For example, here's a scenario where it's not:
The tradeoffs around 3.5 vs 5y are also relevant to #554 |
Beta Was this translation helpful? Give feedback.
-
|
I didn't say safe_r_. The safety I'm appealing to here is just the general sense of making a smaller change so we can observe the impacts, and then lean into it later. I don't think your scenario is valid. The commitment duration does not affect a sector's profit horizon. Any sector can still live for 5 years, as today, but if the max commitment is 3.5y it will require extending once to get there. Secondly, assuming "re-sealing" does involve an actual PoRep, any newly proved sector would have a new 5-year term, regardless of the age of the sector it's replacing. |
Beta Was this translation helpful? Give feedback.
-
|
I don't have any strong objection to 5y by the way. I had to nominate a concrete value and I chose a conservative one. I'd happy for us to decide in this FIP to increase it, or for #554 to do so instead. |
Beta Was this translation helpful? Give feedback.
-
|
Great proposal! Simple, yet elegant. Bumping it to page 1 of discussion for more visibility. 😊 |
Beta Was this translation helpful? Give feedback.
-
|
Added deal duration without changing any incentive or multiplier? YES! |
Beta Was this translation helpful? Give feedback.
-
|
Sounds good to me. |
Beta Was this translation helpful? Give feedback.
-
|
Does this mean if the network want to get rid of cheating/malicious sectors, it will take 3.5 years for longest. Did we put it into the Security Considerations? |
Beta Was this translation helpful? Give feedback.
-
|
if you looked up the FIP itself - you will find https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0052.md#security-considerations |
Beta Was this translation helpful? Give feedback.
-
|
I just checked the FIP, it did not mention the change to a longer sector commit for max 3.5y will also allow malicious sectors stay longer in network thus weaken the security of the network. |
Beta Was this translation helpful? Give feedback.
-
|
That's because it doesn't change it. If you are referring to FIL+ verified data of dubious "quality", allocations can already be made for 5 years, and sectors can already be extended repeatedly to fulfil that 5 year term. This proposal doesn't change what's possible (but does make it a bit cheaper and more convenient for everyone). It wouldn't affect network security even if it change the max duration of dubious quality data, though one could make an argument that it decreases utility in some way. |
Beta Was this translation helpful? Give feedback.
-
|
OK I get it this FIP itself is not affecting the network security but it has a side effect. My concern is that many still believe dubious “quality” of Fil+ and the multiplier weaken the network security since it affect the block-producing rights. Allowing 3.5 years sectors will make the Option1 (Stop new Datacap allocations immediately. Eliminate 10X multiplier upon FIP finalization in an upgrade) we provided in discussion #774 much less effective because these 10x sectors will stay longest for 3.5 years rather than 540 days. |
Beta Was this translation helpful? Give feedback.
-
Background
FIP-0047 introduces a mechanism to decouple a sector’s PoRep validity from its commitment duration. After this, we are free to increase the maximum sector commitment duration from the current 1.5 years up to 5 years (the maximum sector total lifetime).
FIP-0036 proposed increasing the maximum sector commitment duration along with a “duration multiplier” that multiplies the QAP attributable to a sector by that commitment duration, and an increase to the consensus pledge supply target. This proposal was controversial and has complex ramifications on different groups (see discussion 1, 2, 3).
This is a proposal to simply increase the maximum commitment duration, motivated primarily by the product benefits.
Motivation
At present, storage providers can commit sectors only for 1.5 years at a time. This (coupled with current limitations of sector storage) in turn prevents committing to a deal any longer than 1.5 years. There is significant client demand for longer deal terms.
Longer commitments will also contribute to both the stability of the storage-powered consensus base, and decrease the velocity of tokens that are pledged to those sectors.
This proposal is intended to be the simplest change possible to enable these benefits, with the product utility benefits being the primary motivation.
Proposal
Set the maximum sector commitment duration to 5 years. Set the maximum deal duration in the built-in storage market to match. There is no change to pledge amounts.
This proposal depends on FIP-0047.
Discussion
Impact on storage clients and providers
The primary impact of this proposal is on deal clients and the storage providers serving them. Supporting a 5-year deal minimum-term allows clients with long-term archival data to secure storage for their data for that term. Specifying this term up front will avoid numerous costs and overheads of making replacement deals every 1.5 years, amortizing fixed costs over longer terms. It will also allow clients to lock in the negligible price of storage given the current incentives and supply surplus. This general improvement in capability of storage would make it cheaper and better for clients, and thus might encourage additional marginal net demand (especially through not having deals expire every 1.5y).
Providers serving these deals will be required to make a long sector commitment in order to accept them, but can lock in the payment (including the FIL+ verified data subsidy) for the entire duration. While there is no additional multiplier for the longer term, locking in the full 10x benefit for many years is expected to be attractive to these providers. When the protocol supports long commitments, a market for them will become possible.
There are only weak direct incentives to make longer commitments on CC sectors, vs the status quo of rolling 1.5-year extensions. When the per-sector initial pledge amount is increasing (as is the case when net onboarding falls behind net token emissions), CC providers can lock-in the current, lower, pledge amount for a longer term rather than face a decision between re-pledge a higher amount when extending their incremental commitment, or letting the sector expire. A longer commitment has the small beneficial effect on the network of locking that pledge for longer, delaying future emissions.
Constraints on future design
This proposal has no intention to prevent the introduction of incentives attached to sector duration in the future. However, such a proposal that calculates those incentives at the time of sector commitment would need to address those sectors already committed with long terms. One possible mechanism might be for sector extension methods to support a no-op, that merely recalculates weight/power according to the remaining commitment duration.
Beta Was this translation helpful? Give feedback.
All reactions