FIP-0036 Followup proposal #478
Replies: 8 comments 25 replies
-
|
Posted this while a bit tired and forgot one really important bit: Parameter selection. Specifically on the sector length QAP multiplier, the original proposal of 1x multiplier per year is too onerous, especially for deal providing miners, as they are not in charge of the durations at the end of the day. Storing a longer deal for a client isnt making a conscious choice to 'go long' on the network so much as it is responding to simply supply and demand dynamics. I still think the mechanism is good in general, but the multiplier should be scaled back.
|
Beta Was this translation helpful? Give feedback.
-
|
@geoff-vball what I’m trying to articulate (poorly, admittedly) with ‘risk of exit’ is how commitment scales with duration. I see massive value to the network from the longer durations, and that SPs stand to benefit both individually and in mutualistic terms, but we should be under no illusions many in web3 will see 5y as an enormous commitment. If I run any business it can fail because of currency fluctuations, force majeure, and x other reasons. My expected cumulative revenue increases with time but so does the probability of experiencing an adverse event that causes me to withdraw from the ecosystem. I’d hypothesize the n-year relative risk scales approximately as p(1)^-(n-1) where p(1) is the 1year survival probability. It’d be useful to know SP inflow and outflow here, but for a range of plausible values, say 5% to 33%, a 5y linear sector duration multiplier that compensates relative risk proportionately is between approximately 0.25 and 1.05. To be clear, I think this perspective is just one extremely limited way of looking at things, and compensating relative risk is not an immutable principle. Value to the network is a wider perspective (cc @axel). And ultimately the perception/prospect of risk and willingness to participate in longer durations is also central. |
Beta Was this translation helpful? Give feedback.
-
|
The key point that worries me is the principle above that smaller is safer. Maybe it’s useful to ask what are the advantages and disadvantages of 1x vs 0.25x slope? On a potential advantage of 0.25x being
I mean maybe or maybe not. It’s hard to make any changes that affect rewards distributions, but if the case were sufficiently strong I’m not sure I follow why direction is a special factor. An advantage of 0.25x is that there's zero data on sensitivity of the network to duration incentives, and opting for 0.25x we at least acquire this data on responsiveness. I agree this is valuable but this strategy is not risk free. We’re absolutely in a position where we need to be making decisive choices quickly to steer the network. As with earlier changes to FIL+. In the context of flatlining and actually declining rawbyte power (this is the current state), the compound opportunity costs lost through acting overly slowly are not small imo. Opting for 1x will produce longer sector durations and stabilize supply more quickly than 0.25x, but what are the concrete reasons against it? Given some SPs have indicated that 1x is not strong enough to see substantially longer durations, it seems unlikely 0.25x is sufficient incentive for 9/10ths of the network to adopt substantially longer durations? |
Beta Was this translation helpful? Give feedback.
-
|
all the slope does is reducing the time it needs to come to a point where sector termination makes sense financially. the best option most likely is to always go max duration with max QAP and if it becomes unprofitable just terminate. |
Beta Was this translation helpful? Give feedback.
-
Let's assume this is not the case because the termination fee would be reassessed. |
Beta Was this translation helpful? Give feedback.
-
Is the the benchmark we're aiming for? I don't think we've mentioned a target before, and I think a discussion around it would help the overall FIP discussion.
This describes the probability of a company not experiencing an adverse event, but doesn't accurately describe the survival chances of a business. Businesses because more resilient to these events over time. If this relation held, we would see no old businesses. A business that choses 5-year sector durations does not have to think it will last for 5 years to make the decision for pledge for 5 years. With a SDM of x, their hardware costs will be reduced to 1/x. If this reduction over some time T is greater than the termination cost for a sector, then it's a rational choice to pledge the longer sector if you think your business can survive until T.
I don't think this is a good argument for shooting high. As we saw with FIP-0036, something too ambitious will not be accepted by the community. I think the purpose of the proposal here is to strike a balance between the concerns of the current network participants and helping the long-term view of the network to come up with something that will pass without controversy.
The biggest concern I saw raised was by deal-making SPs. If long-term sectors are heavily incentivized, then deal-making SPs can either only take long deals, or will end up with empty unusable sectors when the deals expire. We can alleviate this problem by implementing re-snapping. For that reason I think landing a small multiplier ASAP, and then pursuing a larger long-term incentive later (if needed) when re-snapping is available would strike the right balance between the different stakeholders in the community. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @whyrusleeping. I appreciate the relevance of timeliness here, but suggest we separate the discussion of what change to make from how to schedule it in network upgrades. I fear that a constraint of must go in the next upgrade, which must wait for it, will make it harder to reach agreement on what changes to make. I share your impression that the modified subset you proposed is much more likely to be accepted, and that sooner is much better than later, but tying it specifically to nv17 isn't the only option. |
Beta Was this translation helpful? Give feedback.
-
|
isnt this just FIP 36 with a different slope and 30% lock up target? |
Beta Was this translation helpful? Give feedback.
-
|
And no change to the target lock parameter, so much less impact on SP costs. |
Beta Was this translation helpful? Give feedback.
-
|
tbh. that was never the problem as the pledge amount for extended sectors wouldn't have been affected by it. |
Beta Was this translation helpful? Give feedback.
-
|
FIP 36 ignored a lot of chain mechanics it would have influenced
it was and is badly designed. thats the reason it failed, not the numbers it uses. sure the "we need it ASAP" was and still is a mistake. if we vote this with new numbers the outcome will be the same! the fact that we are now throwing numbers around - seemingly without any reason besides "this might be accepted" - discredits the original fip and makes this proposal here strange, at best. was there a reason for those numbers, macro economics maybe ?!?, or not? why is this new "idea" acceptable - we are told the old numbers are well thought out and needed?!? isn't it really about getting the "lock up more FILs for longer" mechanic onto the chain asap? |
Beta Was this translation helpful? Give feedback.
-
|
Have you considered a multiplier that only apply to new sectors? Whats the "must have" motivation to have existing sector migration as well? |
Beta Was this translation helpful? Give feedback.
-
|
I don't think a 2x multiplier would be high enough incentive for SPs to terminate sectors, but I do think not allowing extension would incentivize SPs to let sectors expire without extending them, and seal new ones instead. |
Beta Was this translation helpful? Give feedback.
-
|
@jennijuju What if we made resnapping a priority? SPs would then be able to pledge a sector for whatever duration they want, and replace their deals with new deals when they expire. |
Beta Was this translation helpful? Give feedback.
-
|
I would love that to happen yes, but that needs work 😜! Wanna start a fip discussion? |
Beta Was this translation helpful? Give feedback.
-
|
a fip i would celebrate! :) |
Beta Was this translation helpful? Give feedback.
-
|
I have re-snapping (repeated SnapDeals) already planned. |
Beta Was this translation helpful? Give feedback.
-
|
A realisation I have just had here (thanks to @Kubuxu for helping me see it) is that the non-fungibility of sectors with multipliers can create unexpected effects when it comes to deal accepting and packing. This applied to FIP-0036 too, but afaik no-one realised or at least communicated it. Consider a single SP who has many CC sectors of varying commitment lengths, and hence multipliers. When accepting a FIL+ deal, say for 2y minimum term, they will earn far more by putting that deal into a 5y commitment sector with 2 years remaining than a 2y one, even over the initial 2y term (i.e ignoring that they would also keep the deal in the 5y sector longer, if max term allowed). The per-epoch reward for hosting the deal could vary by multiples (2.5x in FIP-36, ~2x with Why's params) for doing the same useful work. Both sectors are equally capable of satisfying the deal terms, yet the SP faces quite different outcomes depending which one they chose. This is an odd outcome, I would guess surprising to many. It will add constraints to SP operations and subtract from the "fungible container for data" ideal that we'd like sectors to become. One consolation may be that if the SP does use a 5y sector, they will commit to storing that deal for 5y (even tho the client only required 2y). This then applies between SPs too. A provider with longer duration sectors is not only earning a higher share of reward for the storage commitment, but also enjoys significantly better returns for taking the same deals into those sectors. Perhaps one could say that's just part of the network incentivising longer commitments, but it strikes me more as an unexpected effect than a design goal. It might be mitigated by a claim that, in a competitive market, clients should negotiate to extract much of that extra profit (via reduced or negative price) from the long-duration SP anyway. This arises from the multiplicative nature of the multipliers. If the FIL+ and duration multipliers added instead (before the multiplying the byte power), SPs would get the same returns regardless of which sector they chose. However this would have the aggregate effect of reducing the share of power attributed to FIL+ deals, when compared to the original proposals. I would love to find a way where we could attach such incentives to an SPs aggregate storage and deal commitment, rather than to each sector or piece of data individually. It may not be the right place to open that discussion here, given that we want to find something simple and fast to launch, but 🤞 that such mechanism can be migrated into an aggregate when we need to do that for scale. |
Beta Was this translation helpful? Give feedback.
-
|
that's what people mean that these "FIPs" incentivize storing a lot of "dead" data - deals that aren't active but still stored for rewards. right now it makes hardly sense to extend a 18 month sector with a 18 month FIL+ deal for another 18 month - the QAP loss is to big. with the changes it'll possibly make sense |
Beta Was this translation helpful? Give feedback.
-
|
The core problem of the duration multiplier is that the said multiple reward is due to multiple pledge, and multiple pledge is a clear expenditure cost, but whether the multiple reward can be obtained is still a question mark. My understanding is that this has created vicious competition. I need to spend more costs to pledge to maintain my existing income, but now the economy is not good and I cannot afford to pay more costs. If I borrow money to solve the funding problem, the return is not optimistic, the existence of debt will be more difficult. It can only be said that opportunities are reserved for powerful people. Miners without strength like us can only quit. |
Beta Was this translation helpful? Give feedback.
-
|
Picking this convo back up as I am of the view that things should change in regards to the tokenomics and that is likely important to do this ASAP.If there is not already people on this, I would suggest a small working group with people representing various stakeholders. I realise that a large amount of work was put into FIP-36 but it has failed and I think to a certain extent we could move quicker on such a proposal by having a smaller group iterating the design and getting stakeholder buy-in along the way. Rather than a lot of upfront work for a non-result. Aside from above, here are some of my views that I have been thinking about lately and would love to some feedback on whether concerns are valid or not and whether we should move in this direction or not. Not all of this relates to this specific FIP but I think we may have missed some of the point with the FIP design. The incentive design has done an amazing job of scaling to such a large size in such a short period. Incentives do work. But given the current utilization (1%?) and price of FIL it's clear to me that many of the CC's have no intention of storing client data. Which begs the question of whether the outcome was correct. There is a view that Filecoin consensus algorithm is useful and thus less wasteful, but given almost 15 EiB of storage capacity has been orientated to this network without servicing clients needs is hugely wasteful in my opinion. I agree with the concept of extending sectors, it makes it easier for both SP's and clients but I don't think this should be done for the sake of getting 'blank CC' to commit to the network. (What is the point?). I also agree that people holding and locking FIL provide value to the network. So a separate idea is not incentivize these blank CC's but incentivize a staking pool or similar on FVM. This would satisfy those who currently are using storage just for the access to the yield and would increase their returns. It would also allow us to look at the network in a much more realistic view. Ultimately CC sectors that have no intention of providing services on the network aren't adding value besides being 'locked' - that can be achieved more efficiently somewhere else. I recently saw https://tldr.filecoin.io/staking-your-fil/ can staked FIL be included in reducing circulating supply. Likely, a separate FIP but worth adding here. The FIL+ program needs a revamp. We are working on E-FIL+ which I think is a great start because we need to scale the network utilization. But tiers. Can we have a FIL+ program for private data that earns 2x QAP and leave the 10x for Proof-of concepts/Research & Development that will significantly benefit the overall network through it's implementation and thus the 10x rewards are reserved to pay for that R&D. (I do believe this is largely happening now given the early stage of the network but something to consider as we advance.... there is a lot of data out there we subsidize that which drives the most value back to Filecoin. The point of this ramble is to say that there are multiple issues with the incentives and I think it largely stems from actors not adding enough value to the network being rewarded. We do need to somehow cull those not adding value so that those that do are proportionally rewarded. We are likely going to face a 'macro issue' given the price and scale of the network, I'm not sure this FIP solves the core issue. we should be solving for SP's adding value. In summary:
|
Beta Was this translation helpful? Give feedback.
-
|
you will not get anything on chain that changes the current incentives without a waiting period of 18 month to allow people to opt out. thats the lesson from fip 36 instead of panicking and looking at ASAP - design something that is solid for the next decade people can agree on, can be implemented on a reasonable time line to give stakeholders a valid chance to opt out. |
Beta Was this translation helpful? Give feedback.
-
|
I agree. I’m not suggesting rushing it I’m suggesting we start working on this ASAP because the longer this goes on the more it effects the network.
@f8-ptrk have you suggested any changes on this front that we can look at?
|
Beta Was this translation helpful? Give feedback.
-
|
yes. feel free to crawl the fip36 discussions. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Despite it not looking like FIP-0036 is going to pass, I still think that something should be done to address the problems presented by the FIP authors. As discussed elsewhere with @zixuanzh, I think shipping a portion of the FIP-0036 proposal should be done as soon as we can (time is of the essence).
Concretely, the following things should make it into a network upgrade (taken from the summary in discussion 421):
Additionally, I think that the duration multiplier should be equal to '1' at the current maximum sector lifetime, so that the QAP of a 1.5yr (current max duration) sector does not change. This is only a slight amendment to the FIP-36 mechanic that I think introduces a bit more fairness, but its probably not a huge deal.
This proposal is the least contentious portion of the FIP, and I am quite confident that it would have passed the poll very easily if it were the proposal. Given the general level of agreement I've already seen that these points are good (and the only stated downside of just doing these being that it would make it harder to do the rest later) I propose we try to get these changes into the next network upgrade (I realize this would very likely mean delaying the upgrade until the changes can be made).
Beta Was this translation helpful? Give feedback.
All reactions