FIP-0081 Fix initial pledge baseline design error

[anorth]

Background

The per-sector initial pledge requirement is specified as

SectorInitialPledge = SectorInitialStoragePledge + SectorInitialConsensusPledge

This pledge is intended to “incentivize the fulfillment of a sectorʼs promised lifetime and provide sufficient consensus security”.

The SectorInitialStoragePledge part provides collateral for potential fees and penalties. It’s calculated as 20 days’ estimated rewards for the sector’s share of power at onboarding. This value decreases over time as block rewards decay and network power increases. It’s only 5% of the total pledge requirement today, the rest being consensus pledge.

The SectorInitialConsensusPledge part provides incentive alignment and consensus security, ensuring that SPs (or their financiers) have tokens at risk, and increasing the cost of attacking the network by acquiring consensus power. The network target is for approximately 30% of the circulating token supply to be locked in sector initial pledge, apportioned by share of network QAP. The per-sector value is calculated as

SectorInitialConsensusPledge = 0.3 * CirculatingSupply * SectorQAP / max(NetworkBaseline, NetworkQAP)

where CirculatingSupply is the minted+vested token supply less the amount locked in initial pledge, vesting rewards etc, and NetworkBaseline is the baseline function that is an exponential, doubling every year.

Problem

The built-in actor code faithfully implements this spec. Unfortunately the spec has a design flaw. Because the network baseline function is an exponential, it will dominate any calculation of sub-exponential terms. In the denominator of the consensus pledge calculation, it means that consensus pledge goes to zero, unless network QAP follows a similar or faster exponential. Zero pledge collateral is clearly not what was intended nor a property that is compatible with a secure network or stable token supply.

Why is the network baseline in the denominator of consensus pledge at all? This is intended to reduce the costs of pledge when the network QAP falls behind the baseline function, to encourage more onboarding. As network growth lags, pledge cost decreases. This is a desirable feature, the only problem is that it currently decreases to an asymptote of zero.

The baseline denominator only has any effect when the baseline function overtakes network QAP. This hasn’t happened yet, but on current trends may happen in the first half of 2024 (e.g. see Starboard). Pledge won’t immediately go to zero, but will start decaying fast. Reducing pledge costs is a design goal, but it is a problem if the reduction goes all the way to zero.

Proposal

The baseline function primarily exists to mediate the minting of rewards. It sets a target for network power, and mints more block rewards as the target is approached. If the baseline function exceeds the raw byte power, those rewards are deferred into the future to incentivize future growth. The minting function splits the total block reward allocation 30/70 into simple and “baseline” minting, where baseline minting is that part that depends on network growth.

This 30/70 split seems to have been forgotten in the pledge calculation. It would be unreasonable for block rewards to drop to zero based on an exponential doubling, so the 30% simple minting provides a floor. Similarly, it is unreasonable for sector initial pledge to drop to zero, but a 30% floor would match with the guaranteed emission of block rewards.

Thus, a simple solution to calculate per-sector initial pledge following a similar 30/70 simple/baseline split.

SectorInitialConsensusPledge = (0.3 * SectorSimpleShare + 0.7 * SectorBaselineShare) * PledgeLockTarget

SectorSimpleShare = SectorQAP / NetworkQAP
SectorBaselineShare = SectorQAP / max(NetworkBaseline, NetworkQAP)
PledgeLockTarget = 0.3 * CirculatingSupply

The practical effect of this is that the sector initial pledge calculation has a floor at 30% of the current calculation if the baseline function were ignored. When/if the baseline function exceeds network QAP, the per-sector initial pledge value will still decrease exponentially, but to this floor rather than to zero.

This reformulation will have zero effect on sectors pledged today, while network QAP exceeds the baseline. It will only change future pledges, preventing them from decreasing quite as far as they might have otherwise.

In summary: the sector initial pledge construction has a desirable property of exponentially decreasing as Network QAP lags behind the baseline function, but an undesirable property of tending network collateral to zero as the baseline function grows. A blended consensus pledge requirement, following the blended minting model, maintains the desirable property of exponential pledge decrease but introduces a reasonable non-zero floor on network collateral.

Discussion

Ratio of simple/baseline share

The 30/70 split is a parameter. We could contemplate a different split that would increase or decrease the floor value to which sector consensus pledge can fall. Aligning it with the minting split seems like a natural value which would roughly maintain the ratio of tokens minted to the initial pledge target as the baseline function grows. Any other value would need some additional justification.

Credits: This proposal was formed in discussions among protocol designers and developers at Fil Dev Singapore, the problem having been identified earlier. The simple solution of a 30/70 split for pledge, following the minting model, is due to @vkalghatgi and @tmellan.

[rvagg]

Would it be very difficult to work up some graphs illustrating various scenarios that illustrate the rapidity of the decay under current calculation vs the impact of the 30/70 mitigation? Being able to visualise any urgency (or not) may be helpful in forwarding this discussion.

[vkalghatgi]

Thanks for the question: Below is a look at the rate of pledge decline simulated across a couple different onboarding scenarios for both the current calculation and the 30/70 mitigation.

Some findings of note:

• Under all onboarding scenarios and pledge designs, once Network QAP and the baseline function cross, pledge declines . (Note for context: the all time historical low for pledge is 0.15 Fil/32 GiB of Power, In all scenarios we go below this).
• Under more pessimistic assumptions for onboarding, the baseline crossing date happens earlier, causing pledge to start declining earlier, while the "Mixed Consensus Pledge" and "No Protocol Change" designs start to diverge sooner
• More optimistic assumptions for onboarding will delay baseline crossing, delaying the divergence between the "Mixed Consensus Pledge" and "No Protocol Change". However, pledge will still decline faster, because more QAP onboarding generally means lower network circulating supply and higher network QAP, both of which will cause pledges to be lower.

Some additional context to help interpret the simulations inputs/assumptions:

• Onboarding Scenarios over the simulation duration (5 years) are informed by historical daily onboarding over the past 60 days.
  • Status Quo onboarding assumes 5.2 PiB/day of raw byte power onboarded per day (median onboarding), and 97% of that raw byte onboarding with sectors allotted data cap (Fil+)
  • Pessimistic onboarding assumes 3.5 PiB/day of raw byte power onboarding (10th percentile onboarding), and 97% of that raw byte onboarded with sectors allotted data cap (Fil+) .
  • Optimistic onboarding assumes a linear increase in daily onboarding starting at 6.5 PiBs/day (95th percentile onboarding) and increasing to 19.5 PiBs/day by end of the simulation duration. See the chart below for a visual representation of daily onboarding for the simulation runs

[anorth]

@vkalghatgi can you show a similar chart for the network total locked, or locked fraction of supply? The per-sector chart doesn't show the aggregate effect of the rapid fall in pledge requirements.

[vkalghatgi]

@vkalghatgi can you show a similar chart for the network total locked, or locked fraction of supply? The per-sector chart doesn't show the aggregate effect of the rapid fall in pledge requirements.

@anorth certainly. Below shows some key macroeconomic metrics under both pledge designs, given the onboarding assumptions detailed above.

Some notes:

• Network locked and L/CS (Locked over Circulating Supply) tends to 0 when network QAP crosses the baseline function from above under the current protocol pledge design (as is expected since initial pledges tend to 0). Network Locked will still decrease under the mixed design given that pledges also decrease under this design, but towards a nonzero floor.
• Simple Minting will provide a "floor" on the amount of FIL minted / day regardless of onboarding scenario, with more optimistic raw byte onboarding scenarios yielding higher contributions to daily minted FIL from the Baseline Minting component.
  

[jsoares]

This looks like a reasonable proposal, minimally disruptive and aligned with the original intent. Interested in hearing the perspectives of the different stakeholders.

[mjroddy]

Nice proposal @anorth. This was something I recognised but was under the impression it was the intention, as to incentivise more RB onboarding given the lower pledge amount. I do not understand the security trade-offs here but can appreciate the alignment to the simple and baseline minting.

This would lower the effective ROI on sectors, given there is no change in minting. is the bigger issue here the growth rate of baseline is too fast and not practical?

[anorth]

I would say it will limit the raise in effective ROI of sectors in that situation compared with not fixing it, rather than lower the ROI. The ROI will still improve rapidly after crossing.

I think practicality of the baseline function is a less well defined debate. Even if the network could never catch up to it, its effect on minting of deferring some rewards into the future, unlocked by growth, still works as intended. I'm not convinced it's necessary for the function to be practically reachable. The tech and environment can and will change rapidly, and we wouldn't want to be trying to change the function definition every couple of years to match reality. I think we have to accept the function being "too high" or "too low" in the long run, rather than attempt a goldilocks value. And "too high" seems more useful (after resolving this pledge issue); if "too low" it would be simpler just to not have it.

But I think this is out of scope for the current proposal - please take to a new discussion or Slack #fil-protocol.

[mjroddy]

Also how has the first of 2024 been estimated. My estimates (which admittedly are fairly basic) see's the crossover happening in December given current trends?

[anorth]

Very roughly, and I may have used a longer term average onboarding than you. There's a big window of potential crossing that depends mostly on QAP onboarding. A very recent drop in that brings the window forward. Don't take my value as a sophisticated estimate.

[Fatman13]

Unless there is a solid redesign, half way fix / patch of tokenomics would shed bad outlook of the chain in general. No serious money would consider Filecoin for long term given the constant stream of situational tokenomics FIPs.

[Fatman13]

I‘d suggest that the title of the discussion to be changed to either of the following to reflect the nature of the "fix". @anorth

• Temporary fix initial pledge baseline design error
• Band-aid fix initial pledge baseline design error
• Ad Hoc fix initial pledge baseline design error
• Interim fix initial pledge baseline design error

[EVS2024]

The root cause of potential abnormal Sector Initial Consensus Pledge is that BASELINE itself, and the unreasonable baseline has led to many problems with the network besides the pledge rule.

Instead of amending the pledge rule, the definition of BASELINE needs to be redesigned. This may be less disruptive to the consensus and the network than modifying the pledge rules.

We need to get to the source of the problem, not keep patching it up. Otherwise it will only make us more and more passive.

[Destore2023]

If we all feel that QAP growth in the future, even if driven by rapidly declining pledge rates, will never catch up with the baseline, then it does show that the baseline is set very unreasonably.

We support adjusting the baseline first

[anorth]

Please open a new discussion topic for this. It's a good thing to discuss, but is a much more significant change than this proposed fix, requiring much more thought and analysis. It's not clear that catching up is a necessary feature.

[EVS2024]

@anorth We have a different view on this.

If your proposal is based on an inappropriate baseline parameter, we think it will probably have a very limited time to play a positive role.

As some community members mentioned as above, we may need to patch things over and over again.

[nai2283]

If every term involves baseline parameter as denominator is diminishing, then the design of baseline must be a mistake, thought that's a common sense.

[anorth]

Being permanently below baseline is a reasonable state. It still has the effect of deferring and releasing additional block rewards for incremental growth in storage. As I noted above, a goldilocks "just right" value is impractical, and we don't want to be adjusting the parameters frequently in an attempt to balance the parameter with real world technological progress and economic conditions. I think we have to accept either "always below" or "always above" as the practical sustainable states.

If the network were always above baseline, then it wouldn't be doing anything and may as well be abolished. So The only design approach I see as alternative to the current state (always below) is removing it entirely. This is a reasonable thing to discuss! But larger in scope than this patch to the current design.

[nai2283]

CEL is trying to find every excuse to squeeze SP's ROI aren't they. While RBP crossing they said everything is fine then block reward drop like a rock, and now when QAP crossing is approaching, guess what, they found a protocol error three years after mainnet went live!

[anorth]

Block rewards dropped like a rock towards a 30% floor. Initial pledge requirements should still drop like a rock too, but also towards a 30% floor. Zero pledge is incompatible with a secure and functioning network just as zero rewards would be.

(Please note I am not part of CEL)

[nai2283]

Ser I am fully aware you are not part of CEL. I guess my problem here is if we don't correct this "error", the SPs' ROI could be maintained to close to 20% long term and it's a doable business, but once we increase initial pledge, then we will see heading to 10% ROI within 2 to 3 years. If we've all seen visions and roadmaps from Mr Benet(where is he btw, seems he ignoring the community for long time) that we would be able to have alternative income from clients other than block reward than I guess we are all fine with this ROI downward, but sadly the truth is both clients and so called "DPs" are taking cuts from SPs instead and that won't be changed any time soon. So after all you don't want to build the most secure and sound protocol but on a ghost chain,simply because SPs are all bleeding and leave.

[anorth]

Thanks for your more detailed response. A sustainable SP ROI is a real and important concern. Let me make a few notes in case some implications weren't clear:

• Nothing in this proposal will increase initial pledge beyond the current levels, because the baseline denominator doesn't have any effect while QAP is above baseline. In theory we could completely drop the baseline from the formula and today's pledge wouldn't change.
• After the baseline function exceeds QAP, initial pledge requirements will still decrease quickly, resulting in increased ROI for new sectors. The proposal is just to limit the amount that initial pledge requirements could fall from today's levels. If an SP has a 20% FIL ROI today, that would still increase quite significantly when the baseline function exceeds QAP. Which is by-design. There is no increase from today's pledge levels, and no decrease in ROI (in fact, still a large increase).
• If we don't resolve this issue, FIL-on-FIL SP ROI would increase towards "infinity" as pledge approaches zero. But this would become an increasingly irrelevant point in an SP's business. The impact of rapid inflation due to pledge unlocking could greatly destabilise the token price and ruin the true fiat returns. SP business returns depend on everyone else locking tokens to maintain the fiat exchange rate (well pointed out in Reasons and Suggestions for Increasing the Quality Multiplier of Filecoin Networks #833). And the loss of network security could similarly destroy returns in case that weakness is attacked.

[nai2283]

I don't understand why ROI will go to infinity. Initial pledge has two terms combined, storage pledge and consensus pledge. While consensus pledge proportionally decreasing, SPs will try to commit more QAP and make the ROI stable.
Let's just consider the storage pledge, as ROI of this part is only depending on QAP, this term already provides enough resilience to the whole system.
Then second term.if somehow overall QAP decreasing for some reason, the numerate is increasing due to the circulation releasing, the denominator is decreasing due to the QAP reducing, so it's a somehow loosely quadratic function of QAP velocity, so individual SP's block reward increasing for higher QAP proportion can't compete with pledge increasing, SPs would still leave due to lower ROI and itself drive down the ROI further, aka, death spiral??? Btw here we don't even consider circulation is constantly increasing with block rewards and PL&FF vesting, which already is drugging the ROI to lower level everyday.

[anorth]

Thanks it's fair to point out that the storage pledge part will remain, and become a little more relevant if the consensus pledge falls a lot. The storage pledge is today only 5% of pledge requirements. It depends only block rewards, so it is also decreasing towards zero along with minting (also exponentially, but with a much slower half-life of 6y instead of 1y). I think that network pledge falling to
(very roughly) 5% * 30% = 0.015% of circulating supply is close enough to zero that all of the negative impacts of high inflation price destabilisation and loss of network security are basically the same. But true, the practical asymptote is not zero.

I think your analysis of the second term is off. Yes, circulating supply numerator is increasing, but at a decreasing (log) rate. But the baseline denominator will increase exponentially (ever faster). The numerator rate of increase is insignificant here, the exponential denominator will dominate and give exponential decay of the consensus pledge requirement. Pledge requirements will definitely fall, so ROI will increase and induce more participation. Which, again, is good! Just not when it gets to the extreme of ~no pledge. See the projection charts above.

(Note: even if SPs did leave, this generally raises the ROI for other participants as they gain a greater share of power, and increases the lag of QAP behind the baseline, reducing pledge requirements. See https://medium.com/cryptoeconlab/resilience-of-the-filecoin-network-d7861ee9986a).

[BowenKate]

In the denominator of the consensus pledge calculation, it means that consensus pledge goes to zero, unless network QAP follows a similar or faster exponential.

Why do you think the QAP can't follow a similar or faster exponential when the SPs realize that ROI has recovered significantly? I can't agree that a zeroing trend is bound to happen in the next 6 years.
Is it because you don't have enough confidence in SPs? Can you share why you have this misperception?

We are a small SP from Singapore and currently have 550PiB of QAP.
We are opposed to passing such a hasty proposal without sufficient community input. That would really discourage us from supporting you.

[mjroddy]

ok I understand what you are saying.

I don't think Alex is suggesting that it 'immediately returns to 0', rather what he is saying is that the way the design works is that unless QAP keeps paces with the baseline it will converge to 0 and whether this is the right design?

You are right the lower pledge help self adjust the system, or incentivise people to add capacity as the Sector ROI will be higher.

Because the impact of this is zero to date, It's more about what we think should occur with the pledge. It seems with this proposal that this property (the self-adjustment) would still remain (maybe to a slightly less amount) and it would more closely align to the minting schedule, which in my view makes sense.

Happy to hear other views.

[anorth]

We are opposed to passing such a hasty proposal without sufficient community input. That would really discourage us from supporting you.

I am sorry you perceive this as hasty! This discussion is the call for community input, and thanks for providing some. Let's keep discussing it.

Why do you think the QAP can't follow a similar or faster exponential when the SPs realize that ROI has recovered significantly? [...]
Is it because you don't have enough confidence in SPs? Can you share why you have this misperception?

Possibly it can! There are many barriers though. It is far from merely a question of confidence in SPs.

Exponential is eventually really fast. There are many limits to exponential growth of storage capacity to overcome, and many of them are outside SP control. A few that come immediately to mind:

• The blockchain gas limit supports a maximum onboarding rate due to processing cost, which today is i fact not much higher than recent high rates. I and others will continue to work to optimise and improve capacity, but exponential growth depends on our unlimited ability to do so.
• Blockchain state size is a similar hard limit. At some point we won't be able to account for all the sectors on reasonable validator hardware.
• Obtaining datacap for FIL+ onboarding is a limit on QAP growth outside both SP and my direct influence. Changes in FIL+ governance could greatly constrain economically-viable onboarding (I think that may be behind current slowdowns).
• External and macroeconomic changes could dramatically change business prospects for SPs, like cost of capital or opex, regulatory changes (e.g. bans), and such effects could persist for years.

Yes, I and others have plans to break through the current physical/protocol limits before they become serious restrictions, but that will only reveal new, higher limits. Exponential growth requires never-ending exponential technological improvements, and I think most SPs reasonably think this is not their job.

Regardless of confidence in SPs' desire to see the network thrive, I don't think it's reasonable to expect them to onboard exponentially increasing hardware if the economic conditions don't support a profitable business. I'm not saying that's the case today, but it's quite imaginable.

I can't agree that a zeroing trend is bound to happen in the next 6 years.
There is no evidence that this will happen faster than we can accept, because we don't know and haven't researched whether most SPs react positively to this. If we try to disrupt it artificially early, it may backfire.

I agree we can't know the SP response, and at what pledge level SP's might keep up with an exponential (but possibly limited by factors mentioned above). Consider it this way:

• If SP's do respond strongly when pledge drops a bit, and match the exponential growth, then the proposed change to the function will have very little effect. The difference to the initial rate of decrease is very small. The initial reductions in pledge requirements will happen almost as fast with or without this change.
• If SP's don't respond strongly as pledge drops a lot, then the premise that they might is proven false and we need something to arrest the decline to zero, else inflation shock and network security both undermine the returns.

I think a key thing to note is that the proposed change only has any real effect if growth lags the baseline very significantly (I know charts would help illustrate this - @vkalghatgi?). I don't think it's an artificial disruption that will prevent a good SP response. If QAP is only a little below baseline but then starts keeping up with it, this adjustment will make almost no difference. It only makes a difference if that doesn't happen. It's insurance.

[BowenKate]

If SP's do respond strongly when pledge drops a bit, and match the exponential growth, then the proposed change to the function will have very little effect. The difference to the initial rate of decrease is very small. The initial reductions in pledge requirements will happen almost as fast with or without this change.

It's better not to think like that.

Any modification to the ECONOMIC MODEL is a re-challenge to the consensus, which is an entirely different concept from optimization at the technical level. Who can guarantee that such modifications will not face new problems? Not to mention that I've seen little in the way of a rigorous mathematical argumentation process, just some general extrapolations.

It's a risky move to modify an economic model without the agreement of more than a certain percentage of important community players.

[vkalghatgi]

I think a key thing to note is that the proposed change only has any real effect if growth lags the baseline very significantly (I know charts would help illustrate this - @vkalghatgi?

Yes this is correct, and is illustrated in this comment here

[anorth]

It's a risky move to modify an economic model without the agreement of more than a certain percentage of important community players.

I agree! That's what this forum is for!

[Chris00618]

Why not use the voting tool?
Any small change in the economic model should be taken seriously.

[jsoares]

The new voting guidelines are still being discussed, but it seems possible, even likely, that this FIP will go through that new process when submitted (if the timelines align).

[Chris00618]

@jsoares That's great, I think most people are tired of lots of inefficient and pointless arguments.

[mjroddy]

@anorth overall supportive of this change. I think it aligns to the minting which makes sense. I can understand the baseline argument here but appreciate that is a different discussion.

My estimate still has this occurring in December (although price movements up would delay) so I would support this change going in prior to that cross over.

[anorth]

Indeed it could come sooner. The practicalities of network upgrades make it unlikely we could actually activate this change in December, but if we can have the governance process complete by then, SPs can have certainty over the future. This would in practise result in a small jump in pledge (retracing a small fraction of the reduction since whenever the crossing was) at the epoch the change was activated (estimate Feb/March).

[anorth]

A first draft of a FIP is at #860.

This doesn't say anything that's not already contained in the discussion to date, but I hope that a concrete spec and laying out of the motivation and impacts is further help to community understanding and evaluating the proposal. I welcome anyone who wants to chat about it to reach out to me on Filecoin Slack, where I am also @anorth.

[anorth]

First draft now merged as FIP-0081 https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0081.md

[MarshLin88]

This fix is pointless, it only makes the situation worse and destroys the consensus.

[anorth]

Could you expand on what the situation is that you see this worsening, and how? And how does it negatively impact consensus?

[MarshLin88]

The next change in pledge rates is what many investors have used as the basis for their investment modeling over time. What you perceive as a "fix" may well cause some of the subtle and sensitive investment strategies of the past to become invalid or poor, and more participants will think this fix will continue. This is the mechanism that destroys consensus.

The current ROI in filecoin has become so strained that modifying one part of the modeling involves a lot of other parts that you can't imagin. This is especially true when pledge rate and ROI are core parameters.

[vkalghatgi]

Timing Considerations for Baseline Pledge Adjustment

Thanks all for the engagement on the thread - posting some additional thoughts and analysis following the discussion so far.

Top-Line Summary: The change outlined in the discussion addresses longer term problems present in the network's initial pledge construction. However, in the shorter-term immediate time horizon, given the current macroeconomic climate, and, in the interest of maintaining stable expectations, it may be prudent to defer implementation of the pledge adjustment. (Note: there is no obligation for a FIP that is passed to immediately enter the network in the subsequent available upgrade. cc @kaitlin-beegle)

Summary of Motivation

The change outlined in the discussion post protects against the long-run problems present in the current pledge design, in which consensus pledge, and, subsequently, locked FIL on the protocol tend towards 0, irrespective of hardware commitment securing the network. In the current pledge design, if QAP commitment increases exponentially in line with the baseline function, then consensus pledge will still tend towards 0 for a marginal unit of QAP commitment (of which the smallest discrete unit is 32 GiB), but network-wide FIL locked (i.e the sum of pledge commitments for all sectors) will be substantial (and roughly stabilize around the ~30% lock target). Furthermore, the amount of hardware commitment securing the network will be commensurately robust in size. The issue is when QAP commitment does not grow exponentially, or decreases, resulting in a network secured neither by robust hardware commitments nor pledge. This result is validated across economic simulations of the Filecoin network.

Macroeconomic Climate and Impact on Fil-on-Fil Return (FoFR)

In the short-term, the adjustment to the current pledge design will not have a large effect on FIL locked on the protocol and consensus, but, will immediately have an effect on SP business operations via comparatively reduced FoFR. The impact is summarized here and below:

In the long-run this tradeoff between FoFR locked supply/consensus is one that we should be prepared for as a network. However, we are in a tough macroeconomic climate, and this pledge adjustment will depress FIL returns amidst exchange rate risk and a high interest rate environment. It may ultimately be better for the network to accept FIP, but for, the sake of setting stable expectations, provide sufficient buffer prior to implementation to allow both for the economic climate to improve and for businesses to have adequate time to prepare and adjust their operations.

[mjroddy]

Thanka @vkalghatgi

An alternative could be to fix the pledge error and lower baseline to something at least feasible?

[mjroddy]

@vkalghatgi help me understand why the mixed consensus pledge does not rise more here. it basically trends down in all scenario's I would have thought that it would at least rise some given 70% remains the same here?

[lamborghiniandy]

It is not urgent at this time. Since miner irr is still quite low now and many are leaving. We can change it later maybe one year later.

[1475Notary]

Agree with @vkalghatgi and @lamborghiniandy. We suggest postponing this discussion#847 when an increasing number of SPs are preparing to leave filecoin . IMO, we don't need to consider this issue for the next two years.

[momack2]

Disagree. Delaying this fix kicks an important security issue down the road to be an even more challenging and contentious conversation later. This issue and fix was debated, reviewed, and intended to be implemented before the baseline crossing back in 2023 - but was delayed due to technical implementation issues. There is no further reason to delay except for trying to steal consensus and storage security from the Filecoin network while still paying SPs for security (via block rewards) that is not actually being provided to the network. That is not good for Filecoin.

[Fatman13]

Strongly object to this FIP to be included in the next upgrade. No justifications have been given after this comment.

[momack2]

AFAIK the fip has now down both of these things - 1) given SPs and the Filecoin economy lots of advance notice that this bug would be fixed, and 2) implemented a gradual ramp for it to actually take effect in the network, thereby smoothing its impact. Given that, I think those comments are already addressed.

[15012700225]

No, This is not true.

[kkarrancsu]

In Nov 2023, an option was discussed for FIP0081 to consider delaying immediate intervention by not implementing the FIP straightaway. This was based on an optimistic expectation that the general macroeconomic environment could experience an uptick - creating good business opportunities for Storage Providers to increase their storage capacity on the Filecoin network, such that immediate implementation to preserve collateral-backed security would not be necessary. The optimistic scenario has not played out and there has been a decrease in the network storage capacity. This is shown in Fig 1a, where we observe steady decrease of Network RBP.

We are now +9 months, and the baseline crossed QAP on Dec 15, 2023. Because of this, the pledge to onboard new data is on a trajectory to decrease exponentially, creating a threat to network consensus security. Therefore, there is no longer an option to optimistically delay the implementation. Forecasts of network locked are shown in Fig 1c, assuming that the current onboarding rate is sustained, while renewals are reduced from their current levels by 20%. If the FIP is not implemented, the network could reach $100M USD TVL at current FIL prices by the end of 2026.

Considering this, CEL recommends that the bug fix be implemented immediately. To minimize disruptions to business operations, CEL has updated the FIP to gradually ramp the new policy. This is shown in Fig 2a, where the sharp transition of the pledge is mitigated with the updated gradual activation.

[EVS2024]

Raising the price of movie tickets will not increase revenue generation if movie theaters find that audiences are dwindling. This kind of projection and analysis under the faulty logic will only cause theaters to go out of business faster.

[15012700225]

Now that FIL+ can be implemented, creating FIL++ and increasing the multiplier to 20~100 can also increase the onboarding rate.

[EVS2024]

That's one side of this proposal that's good for the security of network, so what's the downside?

More and more SPs are leaving filecoin because of the slippery slope of incentive value will only get worse when this proposal is implemented, this is a point that must be considered.

[momack2]

SPs will actually benefit more from this change long term too. Ensuring there is robust pledge security avoids good SPs having to share their block rewards with short-termist network participants only trying to suck security and value out of the network. A secure network with real collateral allows Filecoin to build a better long-term aligned storage service offering that is onboarding paying customers to the network (driving more value into Filecoin). Even with this change, pledge collateral for SPs will continue to decrease - it will just avoid an insecure “base pledge” that harms network security and value.

[kkarrancsu]

I'll invite other core-dev's to chime in here and speak directly, but due to security considerations, this is a critical patch that needs to be applied to Filecoin as soon as possible.

To reiterate on those:
In Fig 1 above, the forecasts show that if current onboarding levels remain and the renewal rate is reduced by 20% from its current value, then the network will reach $100M USD by the end of 2026 at the current FIL price of ~$3/FIL. If the FIL price increases, this date will be extended, but not by more than 6 months.

By passing this FIP, under these somewhat pessimistic onboarding scenarios (which model the scenario you envision), we stay well above the concerning levels of TVL throughout mid-2027.

[Fatman13]

due to security considerations

imho, i am not convinced that intrusively tweaking tokenomics of a network in exchange for a slight chance to keep TVL at some dollar amount in the far future is the right way to tackle the issues that network is facing now. At the heart, ie the mother of all issues, is the death spiral of steady declining of RBP for the past 2 years. FIP0081 seems to only be an ad-hoc-ish patch to delay the inevitable at the cost of setting an unnecessary precedent for changing tokenomics for no true benefit, rather than to genuinely create / inspire a network environment for growth.

imho, i would suggest considering the following two FIPs to positively address the issue with long term strategic merits...

• FIP0078 Removing Restriction to Access to Multiplier and Allowing Unrestricted Minting of Datacap
• FIP0093 Burning the Mining Reserve

[momack2]

Fip81 has been discussed and agreed on with the community for over a year (originally presented at FDS-1 in Singapore) - it is not ad-hoc, and it is not about RBP or TVL levels - it is ensuring that even if the baseline and RBP continue to diverge, the security of the Filecoin network and its cryptoeconomics are maintained. That is a core security issue for Filecoin to maintain, and implementing it has nothing to do with any of the other FIPs you suggested (those have nothing to do with Filecoin cryptoeconomic security).

For historical context, the original proposal and community intent was to fix this bug prior to the baseline crossing last year, however due to concerns about the overhead of extra network upgrades and required dev time to build a softer ramp for SPs to model this correction, that timeline was extended. The community has now done that dev-work and should deploy it to the network ASAP as the security mitigation it is.

[Fatman13]

it is ensuring that even if the baseline and RBP continue to diverge, the security of the Filecoin network and its cryptoeconomics are maintained

due to security considerations... the network will reach $100M USD by the end of 2026 at the current FIL price of ~$3/FIL... By passing this FIP... we stay well above the concerning levels of TVL throughout mid-2027.

From what author suggests, security is the $ cost to attack the network and thus is pegged to the hardware assets and TVL. By the trend of network's declining for 2 years, the network would always go below some "security threshold" by definition. Not going down on the consensus of this "security threshold", the way to genuinely solving this issue, imho, is to create a network environment that encourages growth and therefore maintain security, which circles back to the two FIPs I brought up in the previous comment.

the original proposal and community intent was to fix this bug

A bug or a feature, imho, it all depends on the perspective. In the context of Web3 and especially things related to tokenomics, it is a feature which network security contributors have all agreed upon when joining the network. Again, imho, such breach of originally acknowledged contract to delay the inevitable (shrinking of network, ie security) at the cost of setting an unnecessary precedent for changing tokenomics for no true benefit is not a good proposal.

[15012700225]

I agree with you @Fatman13 . When the problem of network shrinkage occurs, FF will either do nothing or implement a stupid solution like FIL+. When the community opposed FIL+, FF vigorously defended FIL+. Now it is worried that QAP is lower than the computing power baseline and affects sector staking. What is the significance of FIL+? We need to fundamentally summarize the problem and solve it, instead of ignoring the economic commitments and agreements with SP and doing whatever FF wants to do. Should SP bear all the costs? As the decision-maker of centralized governance, FF No need to bear any cost?

[anorth]

I will restate some points from the origin of this proposal, which are still true today.

• [A trend towards] zero[1] pledge collateral is clearly not what was intended [by the spec] nor a property that is compatible with a secure network or stable token supply.
• Reducing pledge costs is a design goal, but it is a problem if the reduction goes all the way to zero.
• The practical effect of [the proposal] is that ... when/if the baseline function exceeds network QAP, the per-sector initial pledge value will still decrease exponentially, but to this floor [of 30% of the no-baseline value] rather than to zero.

If consensus pledge trends toward zero in this way, it will cause huge inflation from unlocking, and undermine the economic basis of network security (it will become cheap to attack the network). Both of these would destroy any business that SPs hope to maintain into the future. Yes, FIL-on-FIL ROIs would increase, but this would become increasingly irrelevant as the inflation and security effects would likely destabilise the token price even further and ruin fiat returns from block rewards.

SP returns in the short term depend on everyone else locking tokens to maintain the fiat exchange rate. In the medium and long term, they depend on earning service revenue externally, as competition inevitably erodes any margins from pure "mining". Inflation and a loss of network security could similarly destroy such service-based earnings if the network is not trusted.

[1] As was pointed out in discussion, the immediate trend of total pledge is not quite to zero, but toward roughly 0.015% of circulating supply (the storage pledge). This has the same practical effects of huge inflation and eroding the economic basis of network security.

In summary, this proposal is necessary for both SP business prospects, token price stability, and network security. Some parties with short-term view may object because it limits future FIL-on-FIL ROI vs the status quo, but to do so is to choose short-term value extraction over the network's future.

[lyjmry]

If you think that a low pledge will make cyberattacks easier, you are wrong, even if the pledge is lower, it still requires a lot of hardware to attack the entire network.

[Fatman13]

[A trend towards] zero[1] pledge collateral is clearly not what was intended [by the spec] nor a property that is compatible with a secure network or stable token supply.

By the projection of the authors, "zero[1] pledge collateral" is not true.

And by spec, fund raising remainder should be converted to keyless account.

Reducing pledge costs is a design goal, but it is a problem if the reduction goes all the way to zero

Again, its not going to zero by author's projection. And we have plenty of time, years in fact, to address the real issue of the network which, again, is the decline of RBP over the past 2 years.

The practical effect of [the proposal] is that...

I don't doubt you have good intention but again within context of Web3 tokenomics in principle setting an unnecessary precedent of changing tokenomics for no true benefit is not a good way to address the core issue, which is that the current network environment is not encouraging growth nor innovation.

Some parties with short-term view may object because it limits future FIL-on-FIL ROI vs the status quo, but to do so is to choose short-term value extraction over the network's future.

Some parties with "long-term view" may be in favor of the proposal as they have always shifted network risks onto the backs of others, exploiting them, while they themselves take zero risks and loss.

[anorth]

If you think that a low pledge will make cyberattacks easier, you are wrong, even if the pledge is lower, it still requires a lot of hardware to attack the entire network.

Unfortunately, renting hardware is massively cheaper than risking pledge. Even at low token prices, the pledge dominates network security. Renting hardware to seal or just buying sealed sectors from others is 10-20x cheaper than the pledge. It's loss-of-pledge that protects the network from attack. The hardware cost is "only" <$10m. This was discussed at Fil Dev Summit in Singapore 2023 and detailed working is available here.

[anorth]

@Fatman13 I'm not sure if there's some misinterpretation of the graph, but to me it clearly shows the lower three lines ("no change") trending toward zero. I understand they approach an asymptote (that's slightly above zero), but that doesn't diminish the point. It's basically a chart of network economic security, and it is all but demolished. An attacker doesn't need to wait for it to reach actual zero, just for it to become cheap enough.

FWIW I agree that the spending of the fundraising remainder is shocking and counter to the spec, but there's nothing to be done about it now.

[mjroddy]

I think it's worth considering that if we do not implement this FIP the role of stakers in Filecoin will diminish alongside the pledge.

IMO this will have pretty large negative consequences for Defi and the value of FIL.

Very much supporting this FIP

[lyjmry]

I think it's important to eventually get back to an ecosystem where the underlying hardware serves, rather than just chasing after miners to lock up a lot of FIL

[lyjmry]

FIL+ is enough to destroy the economic consensus; it is the first cheating protocol.

[FILDCKabat]

this discussion is almost a year already, and it's only 18 participants here
time to finish it

[rvagg]

In the Lotus integration part of this, I'm proposing that we apply the ramp for calibration net as 7 days, so ramp_start_epoch would be the calibration net nv24 upgrade epoch (TBD I think, but it's on the 23rd of October) and ramp_duration_epochs would be 20160. Whereas mainnet would have the mainnet upgrade epoch for ramp_start_epoch and a ramp_duration_epochs of 1 year's worth of epochs, 1051200 as per the FIP.

Any objections to this? Participating implementers would need to agree of course because these parameters are set outside of builtin actors and are set during migration.

[lemmih]

No objections from Forest.

[jennijuju]

whata the downside of shorten it to within 3 days so to make sure we can patch any bug if necessary before all the travelling both lotus and forest will be taking in the last week of October?

[rvagg]

That would probably be ok too. I think I'd just want to run similar measurements as I ran for the graphs I put in filecoin-project/lotus#12526 to observe before, during and after ramp and make sure the ramp is distinct but doesn't have weird sharp edges. So the catch with 3 days is to be prepared to capture that information as it happens.

[rvagg]

Merged 0081 support into Lotus with a calibnet ramp of 3 days of epochs: https://github.com/filecoin-project/lotus/blob/49d6c8a0b893d2750efb48f1c7472def79a2815c/build/buildconstants/params_calibnet.go#L105-L112, I hope that's OK with you @lemmih, holler if you see problems with that.

[ipfsforcezuofu]

It's OK for Venus.

[rvagg]

This is live now on mainnet and is starting to be measurable:

Due to a quirk in the implementation whereby the "skew" value which determines the contribution during the ramp period (1 year) is calculated using integer operations, it will ramp up stepwise in 300 increments during the 1 year ramp. So the first tick was just now, at epoch 4464744 (there was no difference prior to this epoch).

[rvagg]

Not quite the same but very close to it. You can run the audits command with an epoch argument by the way, if you give it 4724725 you'll get:

 32GiB       |  100%      | 1.00 year(s) | 1.364732603850914344 FIL | 1.230511154318443211 FIL | 0.134221449532471133 FIL

Which is also not what you're observing in the onboarded sector. Delta of 0.01015485. Deal weight checks out, 20858319694462976/1024/1024/1024/(5331782-4724725) = 32.

The main catch with this audit tool is that it doesn't use the same calculation path as builtin-actors because we have no way to reach in and pull out that calculation by itself, so it's a re-implementation of the same code in Go, which obviously has drawbacks! It's not a super-complex algorithm and we put a bit of work into aligning the two so this is pretty surprising and definitely worth investigation.

[beck-8]

Thank you so much. I realized what caused it.
Because these methods of golang add a coefficient *100/110, as long as this coefficient is removed, it will be completely consistent with the on-chain sector pledge situation.

[beck-8]

[rvagg]

ah of course, upscaling by 10% 👍

[rvagg]

filecoin-project/lotus#12913