Revisiting a Sector Duration Multiplier (FIP-0056) #554
Replies: 72 comments 196 replies
-
I think this is a good point worth highlighting:
It's also worth highlighting that this does not include any proposed changes to the collateral target locking parameter. |
Beta Was this translation helpful? Give feedback.
-
I would like to argue for scenario 4 (5 year sector max lifetime, applied to all sectors) - because I think its parameter set is most aligned with long term network value and capability. To break down those two tradeoffs:
Re 2 - I think there's a potential compromise that mitigates concerns for deal-making SPs.
The solution: There is significant work in flight towards "Re-snapping" sectors with existing deals, to replace an expired deal with new data and apply the new deal multiplier for the remaining length of the 5-year sector. Core Devs could prioritize this FIP to land it in ~ex a network upgrade shortly after SDM takes effect, in order to bring long-term usage of extended sectors to deal-making SPs that need/want to use their data storage resources fully.
Curious to hear from folks if they agree that Scenario 4 seems most aligned with the network's long-term value/capability, and whether this mitigation assuages deal-making SP concerns with choosing that option. 🙏 |
Beta Was this translation helpful? Give feedback.
-
I would like to open discussion about the possible incentives to terminate sectors if the SDM did not apply to extensions of existing sectors.
I am not convinced this is as bad as this claim (which I know is held more widely). Regarding incentive to terminate existing sectors, I would like to see it quantified. I think it would have to be based on some kind of scarcity argument, e.g. the SP doesn't have the storage capacity or pledge funds to make a new SDM commitment, so they have to terminate an existing non-SDM sector to free it up.
If an SP were not previously incentivised to terminate and exit, I don't see how the introduction of an SDM option would increase it significantly. The only way could be through wide adoption of the SDM reducing their share of rewards, but wide adoption is a success case and means much more storage and pledge were committed by others! Regarding re-sealing, I agree that the energy cost is probably a net social loss. However, I don't think sealing time that could be dedicated to network growth is a valid concern. Almost by assumptions behind this proposal, SPs are not limited by sealing capacity. We've observe much higher network sealing throughput, growth is low now for other reasons. That sealing hardware is probably not otherwise being used toward network growth under the conditions that motivate this proposal. This could be really good. If, in fact, we can determine that incentives to terminate existing sectors are actually weak or zero, that gives us a wider range of options. There would still be reasons to prefer applying to existing sectors, but we can evaluate them for the potential up-side. It would be a shame to have chosen this only in response to a worry that wouldn't have materialised. |
Beta Was this translation helpful? Give feedback.
-
there should be an option to opt out of the multiplier when doing long term sector pledging. |
Beta Was this translation helpful? Give feedback.
-
Thanks @vkalghatgi and your team for restarting this discussion and presenting a wider space of tradeoffs for us to explore together. I'm glad these ideas are back in active discussion and look forward to us landing something into the network soon. I hope and expect that the restricted scope and presentation here are much more widely acceptable. I think the general thrust here is positive for the network and almost all stakeholders, especially in the long term. I have some concerns about further shifting the security base of the network towards tokens rather than hardware, and that we might be over-paying in terms of power/reward to secure longer commitments, but they could be seen as letting the perfect be the enemy of the good. Everyone's idea of perfect here will differ, and it's valuable for us to quickly settle on something good so we can learn and iterate if warranted. These proposals are close enough for me. I am fairly confident in supporting this proposal in scenarios 1 or 3, i.e. new sectors only. Scenarios 2 and 4 (applying to extensions of existing sectors too) present tradeoffs that are more balanced. In addition to the fairness issue (which can't be resolved simply by fast-tracking re-snapping), these scenarios bring somewhat more risk of volatile dynamic behaviour, the potential for a race etc. Some prior proposals suggested a ramp on the multiplier to mitigate this, but I am hesitant to introduce complexity here. I would really love to just see some "what if" modelling demonstrating stability if uptake is higher than expected. I think there is potential to design around the fairness issue with a combination of re-snapping and an opt-in migration for pre-FIP-0045 sectors that has re-snapping in mind, but that would take this squarely out of the realm of a quick and easy implementation, and sooner + simpler is probably better. Doing that work would have opportunity cost pulling experienced Filecoin engineers from other long-term utility-oriented projects. I am not sure the fairness issue should necessarily block applying this to existing sectors, but the tradeoff definitely has a downside. |
Beta Was this translation helpful? Give feedback.
-
Is it possible to set SPs into different classes with storage capacity as a variable condition? |
Beta Was this translation helpful? Give feedback.
-
It is inspiring to see that the ratio of real data stored on network is growing relative to the CC stored. How does this proposal prevent that relative growth from being reversed? A reversal would be harmful to the value of Filecoin to the world, especially in light of the FTX debacle where policy makers question the value of crypto systems. I, too, question the concept of "incentive to terminate existing sectors" when trying to justify additional incentive to maintain or grow CC sectors. I believe the opposite is true, with additional incentives for real data, CC Filecoin miners will actually be incentivized to snap real data into existing CC sectors. Storing real data that benefits humanity is the motivation behind Filecoin, not simply mining tokens. |
Beta Was this translation helpful? Give feedback.
-
Clients want 5-year storage deals, we need to facilitate what they want, not what we think... |
Beta Was this translation helpful? Give feedback.
-
I would choose option 3, regarding if the DM should be subject for SP to choose, I don't think we need to worry too much about it, since SP can still distribute their sectors among regular/FIL+ to control the overall cost. And from another perspective, if the token price raise 5 times, would've less storage been committed to the Filecoin? |
Beta Was this translation helpful? Give feedback.
-
Scenario 3 will be great for flexibility. Also, I agree with f8-ptrk, there should be an option to opt-out. |
Beta Was this translation helpful? Give feedback.
-
We'd like to choose Scenario 3. |
Beta Was this translation helpful? Give feedback.
-
Scenario 3 with an option to opt-out of the multiplier makes most sense to me. But as F8 already stated, I don't fully see the reason for having the multiplier so high. It makes it very difficult for everyone to deal with. Personally I would do a x2 as a multiplier on 5 years. At maximum. One thing we do love, the option for 5 years. This should be implemented asap. |
Beta Was this translation helpful? Give feedback.
-
In general terms the concept of a sliding multiplier for length of duration sounds reasonable and I agree that scenario 3 is best. However, in alignment with @jhookersyd we should be considering this from the perspective of the "customer" not the SP. Flexibility is key: If the goal is ultimately to enable real customers (public data or enterprise) to store data on Filecoin, retrieve it, and over time do much more with it (move from cold to warm to perhaps one day hot storage), then what we should be providing is flexibility of length of contract able to be adjusted to the needs of the client and not fixed centrally. With that, incentivising the client to sign up for longer term deals is in everyones benefit (including getting a better multiplier). In the enterprise world, we would sell contracts based on 1, 2, 3, 5, 7, 10 years. We should be incentivising the positive actions for network growth, as per @stuberman - we absolutely should be incentivising the storage of real customer data (public and enterprise) over all else. The elephant in the room alongside all this remains availability of FIL (and the fact the when it is available for borrowing, it comes with a 20% interest rate that almost kills the breakeven). This is for another thread/FIP but am sure this can be solved for elegantly... |
Beta Was this translation helpful? Give feedback.
-
I would go for scenario 3, primarily because I think this has the least potential impact on destabilization and centralization of the network. 3.5 years is not long enough, allowing existing sectors to upgrade without resealing is too dangerous - scenario 3 is the only option. |
Beta Was this translation helpful? Give feedback.
-
So...
Next stop 2 dollar FIL. Let's get this done people! Many enterprise SPs will disappear if we don't get this done asap! (Holon is fine FYI) Agree with @DecentCr8, FIL+ should be moved to the FVM at some point. This will make it easier to program flexibility into future models. "Genomics/Healthcare FIL+" feels like the natural first step for a dedicated incentivisation program. If we nailed this one vertical well, it would lead to exponential growth for the network. |
Beta Was this translation helpful? Give feedback.
-
It is normal for the client to have a storage requirement of more than 1.5 years. In my opinion, PL should provide a more convenient renewal plan for this, instead of increasing the output multiplier based on the length of time. In addition, from the perspective of SP, in the absence of pledged FILs, the longest period of 5 years corresponds to at least 10 times the number of pledged FILs, and no funder will agree to their loan needs. So I refuse this proposal absolutely. |
Beta Was this translation helpful? Give feedback.
-
@Aaron01230 this is a good point. The network should aim to be as frictionless as possible given its broader goals. My 2 cents on the above and the broader discussion: -
Debate is welcome, but it needs to develop to effective and rapid action. My understanding is that this debate has been too long, and without appropriate response and this is the problem that should be addressed urgently. Otherwise, how can the network hope to adapt to the ever-changing environment in the future (and thus help ensure sustainable network growth)?? |
Beta Was this translation helpful? Give feedback.
-
As a member of Singapore SPWG, I agree SDM should not go ahead, CDM has to be discussed. "Widened belts are hard to shrink back to their original shape" The same applies to Filecoin Network. |
Beta Was this translation helpful? Give feedback.
-
Dear Filecoin Community Members, Following in-depth discussions within the Global Storage Provider Working Group (SPWG), DCENT has determined its position against the implementation of the Sector Duration Multiplier (SDM) as proposed in FIP-56. We believe that this stance not only represents our view but also accurately reflects the majority of Storage Providers' perspectives. The SPWG's core values encompass increasing network value, promoting permissionless access, and ensuring profitability for Storage Providers. We contend that FIP-56, which proposes the introduction of SDM, directly contradicts these principles and does not serve the best interests of the network. Instead, we believe that the Capped Duration Multiplier (CDM) is a more appropriate proposal to support the network's long-term growth and sustainability. This stance aligns more closely with our core values and has recently gained significant support from the active Filecoin and Storage Provider community. Sincerely, The DCENT Team |
Beta Was this translation helpful? Give feedback.
-
FilSwan did a community research and discussion inside webchat group (378 user) in Asia. the majority opinion is against this proposal. |
Beta Was this translation helpful? Give feedback.
-
Reminder: Last Call for comments regarding FIP56 is EOD March 24th. Please make sure you add your opinion to the discussion before then. After Last Call, the next step is the Community Governance call scheduled for March 27th 3-4pm ET. Register here: https://fil-org.zoom.us/meeting/register/tZMkf-2qpjIqEt3nkeKh_7f7_F6wPm76zbTw |
Beta Was this translation helpful? Give feedback.
-
Thanks again for the continued engagement and productive discussion on this FIP0056 proposal. As it moves to final call this week, on behalf of the Filecoin Plus governance team, @galen-mcandrew and I are sharing the following statement. We hope to address the challenges raised by the community and share more details on the actions that we are taking. In light of all the current conversations and pros & cons to this FIP, the Fil+ governance team is confident that the community will continue to grow and thrive and therefore is not taking an explicit stance for or against this proposal. Nonetheless, we hear and appreciate a lot of the feedback and requests that have been voiced as result of the FIP discussion. We are working on a broader Fil+ community-wide statement which includes position for more specific points (i.e., what % of the community supports position X on issue A), and we expect to post another update by end of week from Galen on what the community aligns on as a broader group. Please reach out to Galen or me directly if you have any questions. This FIP0056/SDM discussion, as well as that in the parallel CDM proposal, have continued to highlight the importance of Fil+ in enabling Filecoin to achieve its goal - building a data store for humanity’s information. Over the last year, we have seen a tremendous amount of growth in the Fil+ pipelines, enabling storage of 99%+ of all active deals in the network today representing a growth of about 50x in total data stored on the network. Our main focus during this time was to scale up the program - evolving the LDN process to its current v3.1 implementation which has drastically reduced time to DataCap, increasing the number of active notaries in the system, and supporting a wider range of use cases through E-Fil+ and other pilots. This has also shown us that ultimately, there are several participants in the program today that are abusing the system and looking at ways to maximize their earnings to the detriment of others doing the hard work of “correctly” onboarding data - winning business, preparing data correctly, storing with reputable SPs, and ensuring the data can be retrieved by the data owner/client/users. In the last few months of 2022, we made an explicit pivot towards working towards minimizing abuse in the system. This resulted in releasing the CID checker, working with individual notaries and data owners to improve dispute handling, and empowering the T&T WG to scale up. We see the mission of this program as “The Fil+ program supports use-cases for data onboarding and utilization of Filecoin’s decentralized storage network through community-governed trust mechanisms.” Based on this, we plan to continue down the path of prioritizing supporting quality data onboarding to the Filecoin network. This means that independently of how this proposal progresses, the Fil+ team is committed to the following:
In line with the above, here are a few current priorities that we’d like to highlight:
There are several other things in flight as well, please check out our roadmap! Restating that we are committed to ongoing evolution and improvements to the Fil+ program and processes as the state of the network continues to change. Our top priority is and remains to support onboarding from trustworthy clients. We’d love to hear your feedback and suggestions on the above in relevant GitHub discussions, an upcoming Fil+ governance call, or in Slack. |
Beta Was this translation helpful? Give feedback.
-
As @dkkapur mentioned above, the teams are committed to increasing the users and data quality of the network by implementing new tooling and automated processes. In the last couple of months, there have been questions about our overall strategies as an ecosystem to drive and accommodate the growth of the network. As we are in the second phase of our master plan, we continue to prioritize our efforts on demonstrating utility and onboarding data to the network. Here are some of the other major initiatives, but not all, that are in progress as of March 2023. We will continue to update these as more details roll out. 1. Building tooling to support data onrampsWeb2 apps and data owners manage the largest datasets today. To increase the adoption of the Filecoin network, we need to help bridge those Web2 applications and make it easier to store and retrieve data from our decentralized storage network. To accelerate adoption of the network, we need to reduce the onboarding friction customers face when storing and retrieving data onto the network. Since mainnet went live, we have seen plenty of successful onramps built and deployed. However, the proprietary implementation makes it unavailable to the rest of the community that doesn't have the capital to hire engineering resources. As our network is a decentralized storage platform, it requires the rails to store, track and retrieve data onto the platform. To be successful, we need to build a series of tools that can form the foundation to build the decentralized onboarding services and make those scalable, publicly available, and vetted by the community. In this way, we aim to create better customer experiences and help build standards on how data gets onboarded, indexed, and retrieved. The Outercore engineering team, a division of Protocol Labs, has been building onboarding tools to enable onramps and SPs and made them available publicly here. We continue to collaborate with the ecosystem to improve these and vet those out further. Check out this landing page to learn more about these upcoming tools. 2. Driving more top-of-the-funnel demandIn the last year, the network has made a ton of progress in getting Web2 datasets on the Filecoin network. Today, Filecoin hosts datasets of some prominent Web2 businesses and many more copies of public datasets originally stored on web2 clouds. Our main Web2 user interests today come from early adopters in research, academia, media, and entertainment. Though we have a long way to go to make Filecoin a household name in the Web2 space, we are seeing increased organic interest from Web2 decision-makers coming to our ecosystem. We need to build on these successes and continue to create awareness and drive demand for our Storage Provider ecosystem by educating the market on the benefits of Filecoin through paid campaigns. We will start these campaigns next month. 3. Reducing the cost of sealing for Storage ProvidersOne of our key initiatives has been and continues to be focused on reducing the cost of processing the data before storing the cryptographic hashes on-chain. Two immediate improvements are being released: 3.1 Reduce Sealing CapEx by up to 80% with new software and hardware configurations. These new recommendations and software enhancements are built for existing sealing deployments and can achieve up to 80% lower cost versus most current deployments. This improvement results from collaborating with key industry leaders participating in the Decentralized Storage Alliance (dsalliance.io). These enhancements will be released and made available publicly in the next quarter. Keep up to date with the latest release timelines here. 3.2 Move to an OPEX model and leverage on-demand sealing services. We are introducing sealing-as-a-service software that allows for a new ecosystem of Sealing Providers to join our ecosystem. These could be existing providers with excess compute capacity or new providers (e.g., Aligned) with optimized hardware architectures to offer sealing services to the Storage Provider community. Storage providers needing extra sealing will be able to consume these services on demand instead of using CAPEX to purchase compute resources. Keep up to date with the latest release timelines here. 4. Support and enable new DeFi staking programs to support SP growthWith Storage Providers increasingly storing more data onto the network and needing access to FIL collateral for pledging, we must ensure FIL liquidity moves easily through the network. In the last few months, we have worked closely with entrepreneurs to build liquid staking solutions on our FVM stack. We are committed to continuing to help and support these new offerings to develop and scale their stack on FVM successfully. We still have a lot of work to do, but expect that this new DeFi economy will provide access to millions of FIL liquidity to our provider ecosystem in the next few months. Check out the blog here by Ashwanth and monitor all ongoing staking solutions listed here. 5. NEW Upcoming Economic FIPsDuring this FIP discussion we received requests to look at solutions to alleviate the collateral requirements and prepare for uncertain dynamics in the gas economy. So the teams started a few new FIP proposals specifically to address these: 5.1 _Reducing Upfront Collateral (Project Network Shortfall)
The storage capacity has been dropping in the last year as storage providers were redirecting their pledge to FIL+ Datacap or other regulatory requirements.
The Network Shortfall proposal would allow providers onboarding new storage capacity (or extending, snapping) at a fraction of the initial pledge requirement – a pledge shortfall. This shortfall is accounted for at the miner actor rather than the sector level. 5.2 Optimizing Gas impact through a Multi-dimensional Gas Lane
With the launch of the FVM and upcoming IPC applications, there is uncertainty around the relative supply and demand of block space and different types of messages. BatchBalancer was a previous attempt to address a similar issue. Exploring a more general solution that works with varying levels of supply and demand is desirable.
Read up on the details from AX's blog here on how new gas lanes will help the network against a gas sprawl and help maximize the network revenue by optimizing the blockspace allocated for FVM messages. |
Beta Was this translation helpful? Give feedback.
-
@dkkapur @Stefaan-V All the SPs that are voicing their concern against FIP56 don't want human based governance in a blockchain system. Bitcoin has endured time due to its clear protocol-based incentives. CDM gives the Filecoin community this long lasting clarity to build a real business, selling real data, to real clients. It is clear to see that PL just wants to push this FIP through which has NEAR ZERO community support. Mark has made some great points on how FIL+ should change from where it is today. = filecoin-project/notary-governance#841 (comment) TLDR You can’t have ‘trustworthy client’ or ‘datacap allocation commensurate with earned trust’ at the same time as Decentralization. Great Notaries will be bias, bad notaries will be malicious. Adding more Notaries to FIL+ just creates a larger attack vector, again I think we are seeing this play out in real time. Filecoin+ should be centralized and bias because it inherently will be, the program should be treated somewhat like and R&D grant whereby ANYONE can apply for datacap but the approval is based on the decision on a smaller notary group that represents stakeholders regionally. The focus of FIL+ should be on driving REAL adoption and Development and thus value to the network. Datacaps should not automatically be 10x but much more nuanced, a function of the value being driven by the data being onboarded. The ‘budget’ of such a program should be reviewed annually and scaled up and down based on the community’s view of whether it is successful (driving value to Filecoin) or not. |
Beta Was this translation helpful? Give feedback.
-
while your input is valuable - this discussion is in the end not the right place. FIP56 will be implemented regardless of developments in FIL+ governance or off chain tooling available in/to the community. if there are concrete FIP'able steps resulting from the actions your teams take, please start new FIP discussions to give the community the chance to provide input on/for these proposals. FIP56 is in the eyes of a lot of people a threat to the core of the network, its mechanics, its future and ideals - its impact going way beyond what off chain tooling and governance could potentially fix we need to be very careful to not justify implementing something with the destructive power of FIP56 on the premise of what might or might not be happening off chain. |
Beta Was this translation helpful? Give feedback.
-
Hello, all, I am the coordinator of CN SPWG group and we just held a meeting in light of Porter and Jennifer’s calling for FIP governace engagement. Here are some highlights of what we have discussed… (Note that things may get lost in translation) TLDRAs there are still arguments on if SDM and CDM is exclusive to one and the other. The “vote” was collected on two front. SDM
With respect to CDM
Discussion
Off-topic
|
Beta Was this translation helpful? Give feedback.
-
Hey'all. BlockScience has worked to perform a first-principles-based review and compare the FIP-0056 (i.e., SDM) and CDM proposals. It has been instigated and funded by the Filecoin Foundation due to the controversy generated by recent proposals and the consequent need for an independent technical group to read through the arguments, check them, and evaluate their implications. The full article can be found at Medium. Our Executive Summary, Diagnosis and Recommendations on the whole FIP-0056 / CDM discussions are as follows: Executive Summary
Diagnosis
Recommendations
|
Beta Was this translation helpful? Give feedback.
-
@dkkapur
|
Beta Was this translation helpful? Give feedback.
-
I would like to point out that we are starting to see a fairly significant decline in block rewards, even with FIL+ today. As it was explained to me by @flyworker, this is because the baseline is predominantly based on CC; if raw power lower is lower than the baseline, block rewards decrease. I'm a bit outside my depth here, so would love to hear opinions on this from @SBudo, @momack2, @tmellan and others on how FIL-56 or the CDM alternative proposed may have an impact to block rewards going forward. |
Beta Was this translation helpful? Give feedback.
-
The current termination fee cap modification can be easily circumvented by either:
|
Beta Was this translation helpful? Give feedback.
-
Author: CryptoEconLab
Problem Motivation
Earlier this week, @Stefaan-V started a discussion on current challenges and economic headwinds the Filecoin network faces. Some key issues include:
The following proposal is by no means an exhaustive solution to the above list of issues/challenges facing the Filecoin Network, but could help better align the economic incentives of the network with longer-term storage commitments, attract capital interest to the ecosystem, and improve the network’s stability while providing Storage Provider’s with further optionality and reward potential.
The proposed mechanism draws on elements of FIP-0036, and the discussions and analyses that followed. They are our take on a maximally agreeable subset, selected to bias towards achieving community consensus and minimizing delays, while still being net positive for the network and individual stakeholders.
Proposed Mechanism
We present some scenarios for implementation of the SDM policy, followed by a discussion of the tradeoffs relevant to these parameter decisions.
Parameter Spaces and Tradeoffs
Two main parameters for the community to consider are (1), if the maximum sector commitment should be increased to 3.5 or 5 years, and (2), whether the SDM policy only applies to sectors onboarded after the policy's implementation or if the multiplier also applies to already existing sectors at upgrade and extension. These options each have respective benefits and risks which are discussed below.
1. Increase the maximum sector commitment from 3.5 years or to 5 years.
2. Whether the SDM policy should only apply to sectors onboarded after the policy’s implementation or if the multiplier applies for existing sectors upon upgrade and extension
Next Steps
Following community discussion on these policy changes, CryptoEconLab will look to introduce a FIP ideally for inclusion in the upcoming Network v18 upgrade with guidance from the governance team at the Filecoin Foundation as well as Filecoin core-devs.
Beta Was this translation helpful? Give feedback.
All reactions