FIP-0081 Fix initial pledge baseline design error #847
Replies: 24 comments 53 replies
-
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. |
Beta Was this translation helpful? Give feedback.
-
This looks like a reasonable proposal, minimally disruptive and aligned with the original intent. Interested in hearing the perspectives of the different stakeholders. |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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! |
Beta Was this translation helpful? Give feedback.
-
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. We are a small SP from Singapore and currently have 550PiB of QAP. |
Beta Was this translation helpful? Give feedback.
-
Why not use the voting tool? |
Beta Was this translation helpful? Give feedback.
-
@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. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
This fix is pointless, it only makes the situation worse and destroys the consensus. |
Beta Was this translation helpful? Give feedback.
-
Timing Considerations for Baseline Pledge AdjustmentThanks 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 MotivationThe 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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Strongly object to this FIP to be included in the next upgrade. No justifications have been given after this comment. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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: 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. |
Beta Was this translation helpful? Give feedback.
-
I will restate some points from the origin of this proposal, which are still true today.
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. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
this discussion is almost a year already, and it's only 18 participants here |
Beta Was this translation helpful? Give feedback.
-
In the Lotus integration part of this, I'm proposing that we apply the ramp for calibration net as 7 days, so 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. |
Beta Was this translation helpful? Give feedback.
-
Background
The per-sector initial pledge requirement is specified as
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 aswhere
CirculatingSupply
is the minted+vested token supply less the amount locked in initial pledge, vesting rewards etc, andNetworkBaseline
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.
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.
Beta Was this translation helpful? Give feedback.
All reactions