Introducing a Sector Duration Multiplier for Longer Term Sector Commitment #386
Replies: 24 comments 81 replies
-
|
Curious what @ZenGround0 thinks about this FIP re ease of implementation in the new builtin actors? @nicola @irenegia @cryptonemo - would love your protocol security perspective on increasing the max initial sector duration to 5 years from 540 days? This would mean that if an issue or vuln were found that required sectors to upgrade (ex proofs v1 —> v1.1), we’d probably need to invest in a conversion tool to upgrade a sector from vulnerable to secure instead of just letting old vulnerable sectors expire off the network naturally after their current max 540 day lifespan. |
Beta Was this translation helpful? Give feedback.
-
This should be a simple code change on the order of a few days to implement and fully test. |
Beta Was this translation helpful? Give feedback.
-
|
"we’d probably need to invest in a conversion tool to upgrade a sector from vulnerable to secure" highly unlikely unless you are ok with re-sealing |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
How feasible & rational will it be for SPs to consider a full re-seal of all of their existing power? (IMHO a strategy needs to exist before the FIP can be accepted.) |
Beta Was this translation helpful? Give feedback.
-
|
This proposal does seem like a generally straightforward way to incentivise longer sector commitments and allow providers to earn greater rewards for doing so. It has some minor interactions with my proposal in #313 to decouple Filecoin Plus rewards from the built-in storage deal market, removing the "spread out" QA power calculations along the way. Something like this change will be required to support user-programmed actors brokering storage deals. The interaction is that a Filecoin Plus data cap allocation will have define an acceptable range for its term (duration), a minimum and maximum. An allocation can only be sealed into a sector with a committed lifespan that lies within the term. In particular, if a FIL+ allocation has a maximum term of N years, it can only be placed into a sector that expires before N years. So if clients want a short FIL+ term, they won't be able to get it into a long-expiring sector. This arises from a product requirement that FIL+ cannot be incentivised for ever, and some clients want assurance that their data will be removed from sealed storage at some point. This is probably ok, because I expect (a) most FIL+ clients will be happy with maximal-length terms, and (b) even for those that aren't, the incentive of the 10x FIL+ multiplier will be higher than the incentive to commit for 5 years. Which raises the obvious question here: what SectorDurationMultiplier function are you proposing? |
Beta Was this translation helpful? Give feedback.
-
|
Just wanted to clarify
Where does this requirement come from? What does "Fil+ cannot be incentivized forever" mean since it's a little ambiguous? Would Storage Providers stop serving files with an eventual date that files will be removed work for clients?
Is the following illustration what you mean? (# represents nothing) ######## |<------- Fil+ allocation ------->| ###### What happens to the allocation that is not covered by a sector? |
Beta Was this translation helpful? Give feedback.
-
This requirement comes to me via product research from @pooja (and IIRC echoed by @momack2). I was designing a change to FIL+ whereby all data cap allocations had no expiration, so a miner could store a piece of FIL+ data forever (moving it between sectors as they expire) and earn the boosted power/rewards indefinitely. This product requirement was a challenge to that: apparently at least some verified clients do not want their data incentivised forever, and would prefer it to be actually removed at some point. #313 is an iteration on that proposal that restores a maximum term limit to a FIL+ allocation (but allows that maximum term to eventually be arbitrarily long).
Please read the proposal. I'll quote
So: The sector must live longer than the minimum, and cannot live longer than the maximum. If miners are incentivised or forced to increase sector durations, short maximum allocations will be difficult or impossible. I.e. a client won't be able to get the incentivisation to stop when they want it to. As noted, I don't think it's a big problem. I would recommend we don't change the enforced minimum commitment though, only change the incentives to commit longer. |
Beta Was this translation helpful? Give feedback.
-
|
Don't see how this FIP help the ecosystem growth, nor attract new SPs/data clients, so is to follow the trajectory of like other zero sum, financial game projects maybe? |
Beta Was this translation helpful? Give feedback.
-
|
The FIP proposal increases the incentives for an SP storing useful client data for long-term (upping their rewards from 10x to 50x multiple for sealing a FIL+ deal sector for 5 years up front). This drives incentives for additional data onboarding , creates a better network experience for clients who want longer-term storage, and helps Filecoin achieve it's mission to "create a decentralized, efficient, and robust foundation for humanity’s information". |
Beta Was this translation helpful? Give feedback.
-
|
No offense but these are just big words, by implementation of this FIP, at the end of the day, SPs as a whole need to lock in more tokes to compete the same amount of the reward, how that’s not a zero sum game? And guess who will enjoy the price boost most? |
Beta Was this translation helpful? Give feedback.
-
The summary notes a proposal to increase the max sector duration to 5y. It's not explained, but I think it's talking about the maximum initial commitment/extension, and if that is raised then deals length can raise to match it. However it's not yet clear that we can raise it while retaining current safety. Separately, #313 and subsequent proposals will decouple deals from these sector commitment bounds. So one way or the other we're working towards supporting much longer deals. That said, I am sympathetic to your point that this proposal is lacking any detail or modelling about how it drives incentives for data onboarding or creates a better network experience. |
Beta Was this translation helpful? Give feedback.
-
I think we're looking at where things currently are today. SPs effectively have three rev streams today:
I do think this gets more interesting post-smart contracts, where you have other rev streams turning on for SPs as well (as more people are paying to use the network in different ways), and more ways to permissionlessly share costs (e.g acquiring collateral). I mention this just to tee up that increasing multipliers doesn't seem (on the surface) super at odds with long term goals for the network - so long as on permissionless markets there are good solutions for getting capital, this should be on balance substantially better for SPs who are long term aligned as well - per unit of effort, you'd get maximum value. My bigger concern is re: 50x, I didn't see that in the proposal but that seems... high. Would love to see the crypto econ and how it might affect things. Not every client wants to hold on to data for 5 years even (maybe you have a 1 year retention policy) - and I wonder if too heavily incentivizing long term archival we bias the incentives against other use cases (especially against ones that might be better served as new services emerge on the network e.g. retrieval / compute / smart contracts) |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
#313 aims to break this coupling so that that quality is always just the bytes of the FIL+ allocation for the full sector lifespan. |
Beta Was this translation helpful? Give feedback.
-
|
@anorth yes I understood - that’s assuming this might be finalized earlier or in the same upgrade with #313. Do have a q: do you think it will make more sense for the impl of this work to wait after the prototyping of #313 is somewhat done, or these two work may be executed in parallel? |
Beta Was this translation helpful? Give feedback.
-
|
They're pretty independent, I don't think they need to be coupled in any way. |
Beta Was this translation helpful? Give feedback.
-
|
Logically, taking more risk worth more reward, right。 Yet , this also means driving away those who can't take the risk, that is small sps. Think about the consequence of this FIP：The total amount of reward will not change, the large sps with lower cost、more tokens、more ways to borrow tokens、healther cash flow can seal longer time sectors and will earn more reward. Yet the small ones, what can they do? Nothing! They may only have 1-2PB, and can’t afford new SPs machines and tokens, they just get less reward and may leave this network after sectors expire and will not reinvest in this. From client view，flexible and low storing time is better than longer storing time, especially lots of client do not know about filecoin, flexible and low time will help client to onboard with lower risk, it will be easy for them to try. |
Beta Was this translation helpful? Give feedback.
-
@steven004 - exactly what led to my questions! all of things you described is supported in the network today, including the pledge recalculation - except for that we do not do refund. @vkalghatgi what's CE's take on refunding collateral? |
Beta Was this translation helpful? Give feedback.
-
|
most likely - do not refund collateral and keep funds as locked as possible as long as possible what we need is resnapping for parts of sectors. so we can dynamically replace single deals in long term committed sectors |
Beta Was this translation helpful? Give feedback.
-
what this doesn't take into account is that not all clients are doing LDN applications as the nature of the program discriminates against the data that can be applied for. we should take great care that the commitment multiplier isn't coupled to the deals inside the sectors and make sure we can refill sectors with new deals !!!! |
Beta Was this translation helpful? Give feedback.
-
|
@f8-ptrk can you clarify what you mean, re:
The proposal right now does describe that the multiplier applies to sectors, not specific deals. Just confirming that this is your preference? |
Beta Was this translation helpful? Give feedback.
-
I get your point. |
Beta Was this translation helpful? Give feedback.
-
|
I agreed that longer-term sector commitment SPs take more risk, therefore deserve more rewards. But, it is a double-edged sword. The major impact is that this may lead more initial pledge required for the same size of content comparing to the current implementation, which simply increases storage cost (specifically, capital cost), further more, to decrease the willing to add more storage (raw bytes) into the network. And, basically, the initial pledge is mainly designed for quality assurance, though it also play a role in the crypto-economics. we need to focus on the security first, at the same time, thinking more about how to provide secure and cheaper storage for web2/web3 users, i.e. thinking more about the services than the economics. We need to be very careful to introduce this into Filecoin network. If we really think it is required, carefully design the function, and keep the initial pledge at the reasonable level. |
Beta Was this translation helpful? Give feedback.
-
|
@steven004 can you explain a bit more what you mean about 'initial pledge required for the same size of content'? From what I understand, you're right, but the initial pledge requirement would still scale with sector length. So the size of the sector would be the same, but if sealed for longer, you would now be eligible for an additional multiplier on earned rewards. Is this correct? Also, in regards to the second half of your comment, do you have specific security or cost concerns that you think ought to be addressed instead? For the latter, you're welcome to DM me directly. CC: flagging @vkalghatgi for transparency |
Beta Was this translation helpful? Give feedback.
-
love the stewardship here; however, i'd like to propose and encourage folks who have concerns, especially security, to leave comments in public discussion(like this one) instead of DM, so that the broader community may track the conversation and share thoughts. |
Beta Was this translation helpful? Give feedback.
-
When I say |
Beta Was this translation helpful? Give feedback.
-
|
One question: |
Beta Was this translation helpful? Give feedback.
-
|
Per the above FIP draft, the new quality calculation would take effect during sector extension or upgrade. Any new sectors initiated after the implementation of this FIP would of course be subject to the updated quality calculation. See: Backwards Compatibility |
Beta Was this translation helpful? Give feedback.
-
50x multiplier seems to be extremely high. It would likely to shift the fundamental of the network from a hardware+collateral model to a mostly collateral only model, diverging the network from its actual utility which is storage & retrieval of data. Similar to many Defi projects, whales would dominate the lending infrastructure and siphon most of the rewards, and leave SPs strangled with the 5-year commitment. |
Beta Was this translation helpful? Give feedback.
-
|
Filecoin as you mention works on a hardware+collateral model. The duration multiplier would not necessarily alter this, in either direction, or it could, depending on the choice of curve for multiplier vs. time commitment. Committing a new sector adds value to the Filecoin network in two ways, first there is more data storage (either real data or CC), and second a collateral is locked. With increased quality multiplier, more collateral would be locked. If we wanted to switch towards a more collateral-based model, the curve should be such that quality multiplier increases very quickly, such that more reward is given for more collateral. Conversely a slower increasing curve gives less value to just collateral. So, this policy does not necessarily shift the network to a “mostly collateral” model since it is also accompanied by longer-hardware commitment to the network. To your point about “whales siphoning rewards”, we must keep in mind that large SP’s are also “whales”. This policy should actually encourage further collaboration between token holders and storage providers, while also creating a mechanism to express a long term view/support of the network. A final point to note, is this proposal, if anything, should benefit smaller SP’s (rather than whales) because they can still get rewards boost/multipliers without prohibitively expensive hardware costs, and termination risks associated with FIL+ data. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, @AxCortesCubero thanks for the reply! Watched your Econday recording, big fan!
Are you saying that the multiplier could be dynamic like how baseline is calculated?
Using ZX's filecoin island economy analogy, the "collaboration" is still much within the island with no value created from actors outside of the island economy. (Very much like a unsustainable defi project) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! Glad to see people are watching! I am not proposing to calculate the multiplier dynamically, just about the exact shape of the multiplier vs. time commitment curve. If we wanted to switch to a more collateral-based model, we could do this by having that curve quickly increase, give a lot of multiplier for little extra time commitment. Otherwise a slowly increasing curve places less value on collateral alone. There are many competing needs to balance to find the right curve (including simplicity, which is one reason to argue for a linearly increasing multiplier instead of some more complicated curve with more parameters). Still with a line, we have a slope parameter to think about, we can become more collateral-based by having a higher slope, or better, to agree on a good slope to balance all our different needs. |
Beta Was this translation helpful? Give feedback.
-
@Fatman13 I may not be interpreting this comment correctly, but two thoughts:
Gonna link to two of my own things here, just to touch on where Im optimistic the FVM can help here (both in bringing new user groups to our economy, solving some of the capital efficiency challenges especially smaller SPs have, as well as how value flows can be less linear post-FVM): imho figuring out if we're aligning the incentives properly for the longer term storage of things (or the appropriate term that meets users needs) / compensates appropriately between the increased risk SPs are taking on is the most important thing - especially if we can solve some the challenges youre flagging (i.e. only large SPs being able to acquire cheap collateral) in other ways. One of the nice features if we can permissionlessly set some of these features up is that the capital providers can be the clients themselves (i.e. folks aligned with outcomes other than pure monetary ones) - as an example data daos could be really interesting in being sources of capital for aligned SPs who directly are taking deals as well. |
Beta Was this translation helpful? Give feedback.
-
|
We will need to think more about if encouraging “keep data as long as possible” is the one size fits all solution, Another choice could be keep it as is, let the client and SP to negotiate how long the data should be kept instead of making a protocol change to encourage or discourage certain time conditions, and that decision might be made by varies considerations including data retention policies required by different jurisdictions (data remove could be required after the retention period) or other business decisions. Generally just thought we should be more inclusive for all data scenarios in protocol level and let the market decides the preference, not to the opposite direction. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @1475Notary thank you for the comment. The goal of the FIP is not necessarily to “keep data as long as possible”’; we want to enable SP’s/stakeholders to express a long-term view/support of the network, while also being compensated for the added risk they incur from doing so. There is still a 1-year floor which is only 180 days longer than the current iteration of the protocol, and, is also a minimal change from empirical activity observed on the network (clients/SP’s have organically demonstrated a preference for longer deals). |
Beta Was this translation helpful? Give feedback.
-
|
I don’t have problem to double the minimal sector lifecycle, although I don’t see any solid or quantify analysis to prove why 180 days makes more “short term behavior”, and this looks a bit contradict to what you said “is also a minimal change from empirical activity observed on the network (clients/SP’s have organically demonstrated a preference for longer deals)”, Occam’s razor tells us we shouldn’t bother to do it if this change brings minor impact. And talking about meet client long term demands, #313 looks a nature and more flexible solution, and SP will still get 10x block reward compensation when their sector is beyond the minimum commitment as long as maximum period specified by client is reached. You may have to be more specific and provide solid facts that this is still not enough to encourage people to “express a long-term view” when needed. |
Beta Was this translation helpful? Give feedback.
-
|
This proposal will interact with FIP-0034: Fix pre-commit deposit independent of sector content. FIP-0034 sets the pre-commit deposit (PCD) equal to the storage pledge for a fully-verified sector, regardless of whether the sector actually has verified deals. (Note the storage pledge is one part of a sector's total initial pledge – the consensus pledge is additional.) If the potential quality multiplier and hence storage pledge is larger, PCD will increase too. This mainly affects CC sectors, which must post the same PCD as verified sectors. With the current 10x multiplier, the CC PCD is still always less than the full initial pledge that will be required at prove-commit, so basically no issue. However with a higher multiple for a longer committed duration, the CC PCD will rise above the CC sector initial pledge, perhaps by some multiple. The PCD is still only a temporary pledge, with any surplus to initial pledge returned at pre-commit. But it will affect SP capital efficiency a little. A larger issue might be that the penalty for a failed pre-commit for a long-term CC sector would become overly punitive (the target is just 20 days' reward). SPs will factor in some non-zero operational failure rate to their economic models. |
Beta Was this translation helpful? Give feedback.
-
|
cc @nicola. Is the PCD target of 20 days reward calculated with the full 5y maximum sector life in mind, or the initial 540 day commitment, or some discounted model of reward over time? FIP-0034 fixes it to account for subsequent increase in power via Snap Deals. Does my reasoning above make sense to you? Any ideas to avoid the overly-punitive penalty for a CC sector (that wasn't going to be Snapped)? |
Beta Was this translation helpful? Give feedback.
-
|
@nicola is it worth considering whether the 20 day penalty calculation should be scaled in accordance with the length of time for which the sector is committed? Would this even be worth considering, given potential complexities around the question of calculating term length multipliers in the case of sector extension? Want to explore any follow-on questions ASAP, since FIP0034 is in Last Call |
Beta Was this translation helpful? Give feedback.
-
|
@kaitlin-beegle see here |
Beta Was this translation helpful? Give feedback.
-
|
A few thoughts on this proposal:
|
Beta Was this translation helpful? Give feedback.
-
|
Changing the gameplay and passive locking for a longer time are only internal factors, and ultimately driven by external factors, such as the ecological explosion based on FVM. Storage providers begin to charge for orders and commercialize them, more WEB2, WEB3 use cases, more capital invest,,,, |
Beta Was this translation helpful? Give feedback.
-
|
Some comments in this discussion is against higher initial pledge to be required in average after introducing a sector duration multiplier for longer term sector commitment. This is not explicitly mentioned, but it looks commenters assuming this. So, could we make it clear? will this result in higher initial pledge required for a fix-sized (say 32G) sector in average? It may or may not, depending on how we design this. @vkalghatgi , any idea? Given that pledge is for securing the network, if total pledge secures the consensus now, we should not expect total pledge to rise. If it does rise, what's the justification? |
Beta Was this translation helpful? Give feedback.
-
|
Another consideration for any proposal is how it will impact the value of Filecoin network, which is based on how much storage space committed to the network and how much valuable data stored in and retrieved from the network. Something like: We hope to have more spaces committed to the network, and of course, more useful data served by the network. The higher initial pledge requirement does help on locking more fil and may benefit some fil holders, however, under limited budget for a storage provider, less space can be committed, or less data can be served. |
Beta Was this translation helpful? Give feedback.
-
It may be slightly higher in the short term, but in general the Initial Pledge per GiB is expected to become lower under this change. This is illustrated in Figure 4C, which shows the time evolution of this quantity under different simulated scenarios. The logic why Initial Pledge per GiB decreases, is that longer durations increase the QAP denominator and suppress the circulating supply term in the numerator in the pledge calculation. Note, all simulated trajectories are conditional on the model assumptions detailed in appendix. |
Beta Was this translation helpful? Give feedback.
-
|
Not really think so. Firstly, in Figure 4C, you are using QAPed GiB, not the raw bytes, which clients are more caring about. If you calculate using raw bytes, Fil/GiB in average will be much higher. Secondly, you are assuming the power growing keeps a good pace, which may not be true. The higher cost for a storage provider to seal a sector is to block storage providers to add more devices/disks into the network, then, you may see less growing rate, and much higher initial pledge. Actually, you could see this in the current network. Back to the value of Filecoin network. I really think it is more backed by the investment from the real world, i.e. the computing power and also disks. The pledge collateral is for securing the network as a necessary mechanism. Once it secures the services, more pledge does not add more value to the network. However, more capacity of storage really means a lot. |
Beta Was this translation helpful? Give feedback.
-
|
To the first point, true clients care about raw bytes, but their interaction with the protocol is mediated by SPs, who have pledges and rewards based on QAPed GiB. If we looked at the Initial Pledge per raw GiB instead, this would give an overinflated sense of how much pledge is paid relative to rewards received for that storage. Secondly, for sure, power may grow slower, or it may grow faster. And this is accounted for by sampling trajectories with +/-50% variation about the current growth rate we see today. See the bands in the Initial Pledge figure. They indicate the decreasing Initial Pledge per GiB trend is broadly robust to this kind of variation in raw byte growth rate. Agree pledge is a necessary mechanism for security, but imho it must be recognized that the network having a stable rather than declining Percentage Value Locked is a relevant factor to support long-term and predictable SP returns and our wider goals. |
Beta Was this translation helpful? Give feedback.
-
|
In addition to the changes initially proposed (altered duration limits and a duration multiplier), the #386 topic authors would like to suggest reassessing the Initial Consensus Pledge target multiplier. This number is currently set to 30%. Suggested values to consider are 40-50%. This suggestion seems unrelated on the surface but there is a clear rationale. Sector durations are coupled to Initial Consensus Pledge target, through their effects on SP returns and supply dynamics, therefore these should be considered concurrently. Moreover, both are economic changes specifically designed to make the network more long-term aligned. The primary way a new target pledge multiplier can contribute to this is by improving the macro setting, aiming the network's trajectory towards a more stable rather than declining percentage locked supply. This supports more predictable SP returns which are essential for the overarching goal of long-term aligned data storage. |
Beta Was this translation helpful? Give feedback.
-
|
I note that the FIP draft at present explicitly excludes this, but thanks for pointing to it. It helps clarify some of the goals. |
Beta Was this translation helpful? Give feedback.
-
|
The current draft explicitly excludes it but this should change. I believe @vkalghatgi will be updating the FIP draft within the next 24hrs or so. |
Beta Was this translation helpful? Give feedback.
-
|
CEL has set out a summary of econ analysis points on this notion page. We hope people find it useful to add more detail to this FIP discussion. In short, out of the options introduced, we think a slope 2 linear duration multiplier function on 1-5 year sectors, with Initial Consensus Pledge target multiplier of 40 or 50%, is a good place to be in. Our current assessment is, this has properties likely to improve long-term storage outcomes for the network, and this is the key scenario the community should be considering. |
Beta Was this translation helpful? Give feedback.
-
|
@vkalghatgi we should talk about CEL's position on the Initial Consensus Pledge. Since ICP and sector multiplier do not necessarily depend on one another, two FIPs may be needed. |
Beta Was this translation helpful? Give feedback.
-
|
This proposal interacts somewhat with future plans for scaling the capacity of the Filecoin blockchain to account for committed storage by making sectors more heterogeneous. We put quite a lot of thought into this in mid 2021 when the capacity growth was going exponential. The growth rate has since levelled off at a level that pushed such problems far enough out into the future that we moved on. I've just copied out some of our design ideas from that time into the CryptoNet notebook for reference here: Fungible Committed Capacity and Project Neutron: Exponential Storage. However, the solutions to this eventual problem revolved around removing per-sector information from the chain. The sealed CID is about half of it, and metadata about weights, activation/expiration epochs etc the rest. To scale exponentially, we need to remove all that per-sector information, making sectors more homogeneous. Giving sectors radically different rewards based on their duration will be a bit difficult to reconcile with handling sectors in ever-larger aggregates. For Neturon, when merging [super]sectors we had to pick some policy on merging expiration epochs, and would probably take the max. This is straightforward when the merged supersectors have power linear in their weight only, but not obvious when the duration itself affects rewards. The takeaway here is that proposals that identify and distinguish individual sectors could be a severe limit on the design space for handling more growth or other complexity in the future. I would prefer the direction was toward aggregate per-miner accounting. |
Beta Was this translation helpful? Give feedback.
-
|
I wouldn’t worry about future scaling capacity tbh, because there won’t be much. Current hardwares in the Filecoin ecosystem is far more than enough to hold the additional collaterals brought by this FIP, so a logical move for most people will be to extend the existing sectors rather than seal new ones. |
Beta Was this translation helpful? Give feedback.
-
|
Sure, we're not worried near-term. But as technology improved and HDD become cheaper, we will need to scale. Not to mention eventual demand for storage from paying clients. See the Bitcoin hash rate history as a comparison. |
Beta Was this translation helpful? Give feedback.
-
|
If this proposal were considered - We’d like to propose decoupling:
into two fips, (which the later May bring security vulnerabilities to filecoin network and needs much more research and analysis from various teams) |
Beta Was this translation helpful? Give feedback.
-
|
We think they should go hand-in-hand and not be split because they're tightly coupled in their effects. For example, how big the multiplier should be (slope 1, slope 2 etc), depends on what the max duration gets set to. If it's 5 years, x2 slope looks good for the reasons set out in the Notion doc here. But if it ends up max 4 or 3 years, something else. So ideally we need to know max duration first. |
Beta Was this translation helpful? Give feedback.
-
to be accepted & finalized prior to/along with this FIP! |
Beta Was this translation helpful? Give feedback.
-
|
The main thing is just to say there's a lot of interaction and coupling between the changes being discussed, so whether ppl feel better about it as one FIP or multiple, ppl should decide. As long we're clear about the inter-relatedness and need to consider things in order. From a CEL perspective (any other CEL ppl pls feel free to disagree), the key points that have to be considered have the following ordering:
|
Beta Was this translation helpful? Give feedback.
-
|
Given scope and interrelatedness, I think it makes sense that 1) adding a new multiplier, and 2) adjusting max duration are considered together. Their individual use-cases don't make much sense in isolation, and it doesn't seem helpful for community members trying to navigate this issue. If CEL also believes that Initial Pledge Commitment should also be changed, that should be its own FIP, rather than rolled into this proposal. |
Beta Was this translation helpful? Give feedback.
-
|
@kaitlin-beegle happy to change multipler and max duration together. To me they're completely interrelated so makes most sense to package as such. But note, the same argument applies to Initial Pledge Commitment! One of the goals is to improve long-term SP business by supporting a steady level of %locked. The value that's locked depends on duration but also what the Initial Consensus Pledge multiplier is too. Slope 2 and 40% together satisfy good outcomes across %locked and ROI. Both have to be considered together imo. |
Beta Was this translation helpful? Give feedback.
-
|
Firstly, adjusting the power can greatly satisfy the needs of clients who wish to store over longer periods of time and motivate SPs to make a long term commitment to the Filecoin community. We are looking forward to the beneficial impact which this will bring to the community. But one thing we must consider is that the data stored in the CC sector is not really dedicated to the advancement of the community. Rather, because of the application of the incentive system, it is not difficult to foresee a reduction in the data selection criteria of SPs. And this will eventually lead to a large amount of useless data being stored. Moreover, this is incompatible with the idea of storing the humanity’s most important information that web 3.0 has held since the beginning. There is no positive impact on either the reputational impact with the Filecoin network nor Fil. In short, I think it would be the most appropriate to suspend the sealing of the CC sector and apply the power adjustment to the DC sector only. |
Beta Was this translation helpful? Give feedback.
-
thats partly true - the data in a CC sector has no "value". but the possibility to store data with value into these sectors needs to be taken into account. a CC sector itself has value - we shouldn't make assumptions about what a SP will do in the future with his committed capacity. we should give incentives committing capacity as long as reasonable from a networks perspective |
Beta Was this translation helpful? Give feedback.
-
|
Notably, this proposal suggests calculating quality scores according to sector terms, irrespective of sector content. If you believe that CC sectors should be deprecated, or that this proposal should address deals (i.e., sector content) instead, you are welcome to open that as a separate FIP discussion! |
Beta Was this translation helpful? Give feedback.
-
I would like to add that unlimited CC sector growth will only have negative impact on filecoin's reputation. The previous large abnormal fluctuations in network-wide power are indirectly related to this, so we have to carefully consider our approach towards CC sector growth, thereby enhancing the reputation and evaluation of filecoin by the government and society. |
Beta Was this translation helpful? Give feedback.
-
|
I think this proposal in fact ends up strongly preferring stability over maximum growth. It increases costs while dramatically skewing rewards toward long-term commitments (and even disallowing <1y commitments). |
Beta Was this translation helpful? Give feedback.
-
|
i see the danger of people leveraging the fact that rewards now are higher than in the future --> getting a lot of power now might get returns high enough to take the 90 days termination penalty mid way through the commitment cheaper than for x1, x10 sectors we might want to consider changing the termination fee calculations to something that is based on the remaining sector lifetime. |
Beta Was this translation helpful? Give feedback.
-
|
Agreed, termination fee needs to be reassessed. Our view is that this should happen in a subsequent FIP, so time can be taken to carefully determine what a new optimal value looks like here, without blocking other components of the changes. |
Beta Was this translation helpful? Give feedback.
-
|
A question for Econ team, when you say sector duration, what’s the definition of it? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @lyswifter. I'm not on the CryptoEcon team, but you can find answers to these questions in the Filecoin spec! |
Beta Was this translation helpful? Give feedback.
-
|
Please note that @vkalghatgi recently presented this FIP to Core Devs. For a detailed technical breakdown of the proposal, as well as a Q&A session, you can review meeting notes or watch the recording of Meeting 1 and/or Meeting 2. I also have a few questions to ask:
|
Beta Was this translation helpful? Give feedback.
-
|
Apologize if my previous reply seems aggressive. It’s just weird that we are trying hart to fix an error that didn’t occur yet and will not occur in the foreseeable future, it feels like to do a cecum surgery when it’s totally fine. |
Beta Was this translation helpful? Give feedback.
-
|
maybe ask some sps.... |
Beta Was this translation helpful? Give feedback.
-
|
@f8-ptrk I believe this proposal has been shared with and discussed among the SPWGs multiple times. Perhaps you can help encourage them to participate? |
Beta Was this translation helpful? Give feedback.
-
|
can we condense this to a more user friendly form? a list of:
most miners have no time to dig into this and you will get the same miners on most of the fips providing input. i think if we have a "this is what this allows you to do" snippet there might be more interest in providing input establishing something like that will benefit all FIPs. |
Beta Was this translation helpful? Give feedback.
-
|
@SparkHao not agressive at all. My perspective is, rather than cecum surgery, this is lazer eye surgery to improve the focus of the network. Is it 100% necessary? Not 100% critical, but it does seem like a good opportunity for a low-risk self-improvement. |
Beta Was this translation helpful? Give feedback.
-
|
Is there a plan to set a new baseline storage power for the network with this FIP? Without one, SPs that seal or extend long duration sectors early after the upgrade will be at a significant disadvantage. Ex: Let's consider the current proposal with sector duration multiplier slope of 2 where 5-year sectors get an additional 10x storage power. Let's also say (for argument's sake) the entire network extends their sectors all to 5 years (or close to it).
We can avoid the situation above by setting a new network baseline for this upgrade by making an educated guess at what the inflation of network power is going to be by estimating the new average sector lifetime on the network. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, this is interesting -- I'm not sufficiently familiar with how the baseline affects these factors, but the concern seems quite valid. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for raising this. There are a few points I'd make. The first is that the storage and consensus pledge should be considered together, and out of the two components, consensus pledge is the one that’s much larger. Considering both collateral parts together, for SP A and SP B, we do not expect SP A, the early sealing one, to be at any disadvantage. There’s a few reasons for this including:
We are monitoring the network QAP and baseline and may recommend adjustment in the future. |
Beta Was this translation helpful? Give feedback.
-
I think the OP was wrong to point to Depending on the rate of adoption, missing a short period of multiplied rewards, and the exponential decrease could account for a very small portion of the total 5-year reward, while suffering a high multiple of pledge. I think there really is a game of chicken that's introduced here (SPs incentivised to upgrade last), which is opposite to the incentive that the baseline mechanism created in the early network. Possibly it's self-limiting. If SPs do delay in order to reduce pledge, then they will cause the shift to take a long time, which reduces the disadvantage to going first (how much? dunno, needs modelling). But incentives to delay making long commitments don't seem to be aligned with what the proposal is aiming for. |
Beta Was this translation helpful? Give feedback.
-
|
Chicken for me is not the right analogy. There is a dynamical and collective element but I wouldn’t say it’s a game of waiting until the last minute. Consider an SP who commits a 3 year sector and everyone else opts for 1 year. For their ROI vs time, increasing the slope of the duration multiplier would make the ROI flatter at the start. In the long-term limit, it doesn’t make much difference --- minting rewards will decrease with time, and incentives must transition more to deals within the coming decade. But at the start, the slope does control how quickly ROI from minting is decreasing vs time. If slope 1, it’s always decreasing. If slope 2, it’s quite flat at the start (~first year) then gradually starts declining. If slope 3 of greater, there may be strong benefits from high TVL, but the ROI trajectory can be increasing initially, which is a behavior that you’ve alluded to that I agree is not optimal. This is part of the reason why slope 3 or greater is not chosen. An imporatnt dimension to the problem is average duration. In reality SPs are traversing a surface in ROI which depends on chronological time and average duration which is a function of collective adoption. Again, long-time limit, average duration doesn’t massively affect where minting ROI is going. Short-term there can be an effect which is bigger the faster adoption occurs. Example, if average duration increases from 1 year to 3 years over the course of a few (~6) months, then minting %ROI would increase a little (likely single digits) with time over a few (~6) months before resuming its decline. The increase for delaying is likely marginal in the context of the cost of waiting and the time value of money, so any incentive towards this behavior is weak imo. And there is a self-regulating aspect. If no-one at all chooses long sectors, they’re be maximally profitable for whoever did, which ensures there will be an increase in sector durations so I would class the proposal's mechanism as aligned with its long-termist goals. |
Beta Was this translation helpful? Give feedback.
-
|
Alternatively, would it be possible to incentivize long-term storage by tieing rewards to the renewal of a storage deal instead of extending sector lifetimes? |
Beta Was this translation helpful? Give feedback.
-
|
you cannot renew storage deals |
Beta Was this translation helpful? Give feedback.
-
|
The complexity of this FIP has led to a very long community discussion. As a result of this discussion, the FIP authors have retracted their original PR and pushed an updated draft for consideration. The original draft is available HERE. Please note that this FIP is still very much a draft; community review and feedback is still very much welcome. For ease, this discussion thread will be locked. A new discussion thread, corresponding to the new FIP draft, can be found HERE. |
Beta Was this translation helpful? Give feedback.
and others
-
Authors: @AxCortesCubero, @jbenet, @misilva73, @momack2, @tmellan, @vkalghatgi, @zixuanzh
Simple Summary
Problem Motivation
Currently, storage providers do not receive any additional compensation or incentive for committing longer term sectors (whether that be CC or storage deals) to the network. The protocol places equal value on 180 to 540 day sectors in terms of storage mining rewards. However, in making an upfront commitment to longer term sectors, storage providers take on additional operational risks (more can go wrong in a longer time period), and lock rewards for longer. Furthermore, in committing longer term sectors/deals, storage providers demonstrate their long-term commitment to the mission and growth of the Filecoin Network, and are more aligned with client preference for persistent storage. Therefore, the added value of longer-term sector commitments, coupled with the compounded operational/liquidity risks storage providers incur for longer term sectors should be compensated for in the form of increased rewards.
Specification
Current Protocol Configuration:
The current sector quality multiplier follows from the spec here. The notion of Sector Quality distinguishes between sectors with heuristics indicating the presence of valuable data.
Sector Quality Adjusted Power is a weighted average of the quality of its space and it is based on the size, duration and quality of its deals.
The formula for calculating Sector Quality Adjusted Power (or QAP, often referred to as power) makes use of the following factors:
dealSpaceTime: sum of theduration*sizeof each dealverifiedSpaceTime: sum of theduration*sizeof each verified dealbaseSpaceTime(spacetime without deals):sectorSize*sectorDuration - dealSpaceTime - verifiedSpaceTimeBased on these the average quality of a sector is:
The Sector Quality Adjusted Power is:
Proposed Protocol Change:
Introduce a multiplier based on sector duration
This SectorDurationMultiplier would be a monotonically increasing function of sector duration. (TBD and further discussion on this function/multiplier necessary). Therefore, the new suggested Sector Quality Adjusted Power is:
Design Rationale
The rationale for the specification is to achieve the goals and desired behavior with minimal code changes. Introducing a duration multiplier should flow into collateral requirements, consensus power etc with minimal change.
Backwards Compatibility
This policy would apply at Sector Extension and Upgrade for existing sectors.
Test Cases
N/A
Security Considerations
There is a potential added risk to introducing a strong economic preference for longer term sectors. Sectors that are locked for extended periods of time may be able to exploit emergent security vulnerabilities and expire off the network much later once these vulnerabilities are addressed.
Incentive Considerations
As discussed in the problem motivation section, this FIP introduces incentives to further align the cryptoeconomic schema of the Filecoin Network with intended goals of the network to provide useful and reliable storage. We introduce the idea that longer term sectors represent a long-term investment and commitment to the Filecoin ecosystem, and therefore should be rewarded proportionally with greater block reward shares.
Note, we also introduce the possibility for storage providers to receive additional multipliers from committing CC for longer. Even this has added value insofar as it represents a commitment to the ecosystem long term that should be rewarded.
Implementation
TBD
Beta Was this translation helpful? Give feedback.
All reactions