Node Provider Inflation Spiral

Governance
43

Very good topic indeed.

So far, I haven’t read anything about cycles burn (and ICP burned to mint those cycles).

My impression was that we were “safe” in the NP rewards, because it would always be a % of the usage (adjusted in the medium term).

Its important to remember that Cycles are also priced at SDR, currently 1 ICP = 2.2 T Cycles, and I have the impression that a year ago it was about 1 ICP = 4 T Cycles, so the cheaper the ICP, the more burn will exist as well.

So I would only be worried about NP rewards if there isn’t a match on the amount of burning.

Have checked the Dashboard and am struggling in comparing the burning with the rewards. Someone would even get scared by these differences:

Screenshot_20230913_005337_Chrome
Screenshot_20230913_005337_Chrome1080×2340 118 KB

In the information it mentions Cycles burn, but on the graph it only shows the transactions + fees. Hopefully someone can ping a Dashboard dev team member and hopefully clarify if it’s included or not that information.

I tried to make the math from the average of cycles burned per second (which is 5.3 B (not T)). And at a conversion rate of 2.2T per icp, this would give a burn rate of only 6.3k ICP (when we are rewarding +500k ICP of NP rewards). :thinking:

Please, someone confirm my math, but are we having a slippage of 98%? I can understand some subsidizing to attract more developers, but only charging 2% of the real cost, seems worrisome.

If I am correct, then the problem needs to be more fixed on charging higher cycles cost in canisters (at double or triple order of magnitude). Also it needs to be deeper researched, how can costs be much higher than usage? Does it confirm that we are approving more node providers than we should?

Hopefully someone can confirm / answer some of these claims. I hope I’m mistaken :sweat_smile:

7 Likes
44

Do something,please! ICP is running to zero!

45

we can learn from the Federal Reserve System, if inflation exceeds the limited value, NNS starts the nhibition plan，such as taxation of all links that generate ICP,the higher the inflation, the higher the taxation,until the inflation fell below the limited value.Reducing rewards is certainly annoying，but inflation will destroy everything。I would rather reward less, and I didn’t want to run to zero.

1 Like
46

Addressing hyperinflation from the supply side, such as by adjusting expenses or minting rewards for NP and Voter rewards, is crucial, however, it has limitations as these changes may impact the quality performance of the infrastructure.

In my view, the primary challenge that IC faces is low demand and usage, which is evident from the cycles being burned. I believe that by addressing this issue, along with implementing more responsible tokenomic, we can swiftly resolve the hyperinflation problem.

During the prolonged crypto and blockchain market downturn, while other projects may be in a more dire situation due to their specific focus on crypto and blockchain, IC has a distinct advantage due to its diverse range of use cases, especially in cloud services. To overcome current challenges, IC should prioritize expanding its marketing efforts beyond the crypto and blockchain industry to increase its network usage demand

3 Likes
47

This seems like a reasonable idea to consider. It would also give NNS participants more skin in the game to study the need for new node providers and contribute more actively in the decision making process for their approval. More node providers implies more decentralization, which resonates with most people in the ICP ecosystem. However, subtracting their rewards from overall governance reward allocations would provide a stronger incentive to critically evaluate the need for more node providers. It seems like an idea worth considering further. I especially like it because it means the max total ICP supply inflation rate would always be known.

5 Likes
48

Hey @Kyle_Langham and @bjoernek it seems like @tiago89 brings up some great question as they relate to this forum topic. I would love to see you guys add more clarity to these considerations. Perhaps we should be looking into increasing cycle costs. Also, why not consider increasing transaction fees? Cycles and transaction fees are very inexpensive on ICP and it seem valid to question if that is really healthy. It’s certainly a knob that can be turned to throttle the inflation concern if needed. Perhaps we should consider higher cycle costs and transaction fees during the bear market while more development is happening and then dial back the cycle costs and transaction fees as the ecosystem enters a bull market where there is more consumption. I’d be very interested in knowing if anyone at Dfinity has any insight along these lines.

6 Likes
49

Yes,

+1. It’s important because it penalizes the excessive “rewarding”. But we should be careful not to go the opposite direction, where voters would always reject and we ended up having a badly performant / risky network.

Also it’s important to understand that in 5 or 10 years from now, the Voting Rewards will be less than the NP rewards (due to voting being lower and lower, while NP / Cycle burn will grow with usage). So we can’t use absolute values.

Was thinking that maybe a good implementation would be measuring the difference between NP rewards and ICP burned (cycles+transactions), and the % difference is the penalty that Voting Rewards get.

So, in theory, if we are minting 500k, and we are only burning 50k (cycles + transactions), then Voting Rewards would be slashed 90%. This could be a 90 days rolling average.

There could be a “healthy threshold” where no penalty would come, like <20% or <10% diff.

For sure voters would quickly react on increasing transaction costs and cycle costs (and reduce NP rewards). The focus is on equilibrium, making sure that both sides are balanced. Which is a main responsibility of the NNS (and its voters).

Of course, such a transition would need to be gradual, phased out across 6 or 12 months.

3 Likes
50

Great response! You raise some legitimate concerns. Do you think it would work better if the donation was optional? At a pervious job, the company had a “hardship pool” where every employee could voluntarily donate a small amount of their check (the amount decided by them) to the pool. Then if someone faced a hardship, like their house burning down, the pool would help them out while they get back on their feet. Most people were willing to donate an amount that is inconsequential to them, but over the whole company, the total amount was significant enough to be useful. I, for one, would be willing to donate say 1% of my rewards to the pool in order to bring down the total inflation and contribute to the stability of the network.

Remember, the goal of this design is not to eliminate ICP minting entirely, but to reduce the amount that’s minted specifically for node providers by establishing additional layers of funding, thus moving the threshold for a cascading failure to a position that’s less likely to manifest in reality.

1 Like
51

I have always supported ICP and opposed FUD, but why does dfinity have no solution to this huge impact? Is ICP really going to die from now on? I have all my life savings locked up for 8 years and I feel hopeless now!

2 Likes
52

Agreed. The issue of more ICP being minted, transferred to exchanges and then sold as the price of ICP drops still persists, albeit at a slightly slower rate, since less rewards would be minted for stakers.

The issue of run-away inflation wouldn’t come as a result of staker rewards as they are denominated in ICP. Any proposed solution in which staker rewards are cut in order to pay node operators does not resolve the issue. It merely kicks the can further down the road. I’m not saying such proposals shouldn’t be considered, since this issue resolves itself as the price of ICP increases. In the short term we just need to buy enough time to allow the price of ICP to increase, thereby avoiding catastrophe. It’s very possible that reducing rewards to stakers to cover node provider rewards could be sufficient for buying us that time. But we need to keep brainstorming.

As long as node provider rewards are denominated in USD, dispersed in ICP, the price of ICP is low and node providers are dumping their ICP on the markets, this issue yields the risk of runaway inflation.

The only real solution that follows sustainable economic principles is for the amount of node provider rewards to be less than or equal to the amount of ICP burned. Short term, this could be achieved by reducing the number of node providers. Mid/long term, this is to be achieved by increasing the amount of network activity on the IC.

I do have a solution that could be enacted in the mid term (6-9 months). I’ve been working on an application that is meant to be deployed to the IC with many replicas so that each person within the ecosystem may have their own respective replica. Each replica burns anywhere from 0.2 T cycles to 1.2 T cycles per day depending on activity. It also offers neuron staking as a way for subsidizing cycles consumption. The cycles burned, as well as the neurons staked to subsidize the cycles burned add deflationary pressure to the ecosystem. If each person in the ecosystem were to receive their own replica of the application, I believe it would add enough deflationary pressure to the ecosystem in order to resolve this issue. The product also provides an economic incentive for anyone with a replica to onboard more users to their replica, thus growing the ecosystem.

I’ve already built the substantial amount of infrastructure needed for delivering updates to the replicas.

The challenge is, the product is still a few months from its alpha launch. Also fostering awareness of the product to every member within the ecosystem would require support from dfinity. @bjoernek, @Jan , @diegop, I would love to be able to meet with dfinity about receiving support and fast tracking the release and rollout of this product.

2 Likes
53

I completely agree that this is something that should be explored further. I had planned on writing a discussion-piece on it, as @mechaquan has been rather persistent on the topic, although if someone else wants to start this conversation within another thread that would be great.

—

I believe this is where the issue comes into play - when times are tough are when people will be least incentivized to contribute, when they’re most inclined to leave.

I agree with you, I would also donate 1% of my rewards to the pool in order to contribute to reducing Node Provider Inflation. However if we assume everyone contributed 1% of the 3.5M potential rewards from last month - that’s only 35k ICP, or enough to pay one larger scale node provider.

With that being said, it is an interesting concept that should be explored further to determine how effective it’d truly be - it can’t hurt to make it optional.

—

I also agree that this makes complete sense - Node Providers should be rewarded in correlation to the amount of ICP/Cycles burnt on their subnet. To make this feasible though, the amount of cycles burnt needs to exponentially increase.

However, it is not possible to simply remove Nodes from the network. Each subnet consists of 13 Nodes, and if they begin to disappear from subnets, canister data will alongside them. Scaling down the Internet Computer is not a risk-less task.

1 Like
54

Correct. If we can buy enough time in the short term to avoid catastrophe, the product that I’ve mentioned would be a viable solution for increasing cycles burnt to a level that’s sustainable for the ecosystem. 30,000 replicas, burning ~0.85T cycles per day would result in ~765,000 T cycles burned per month or ~357,696 ICP burned per month at $ICP’s current price. With more being staked to cover cycles consumption. The issue of run-away inflation has been on my radar from the moment i saw how node provider rewards are covered. I’ve been building this product with the health of the network in mind.

Again, it is still months away from an alpha launch and would require support from Dfinity if I am to be able to fast track the roll out. @bjoernek @Jan @diegop

I do have a White Paper (Version 1) written up for this product. This forum doesn’t permit me to upload PDF files. The following is a link to the #white-paper channel of my discord server. There, you’ll find a single post with the pdf of the white paper attached to it: Discord

2 Likes
55

ICP’s handling fees are unhealthy, it’s like telling people I have a bigger, safer and more luxurious business center and our rent is free. I hope the DFINITY team will rethink whether it should increase fee income, and the corresponding burn rate should increase by a considerable percentage!

2 Likes
56

Just wanted to point out that there are already plans for devs to face increased cycles costs in the form of query charging and increased cross-subnet call fees.

I personally do not like the idea of increasing dev costs; that sounds a bit like cutting ourselves at knees.

6 Likes
57

I agree. Increasing cycles fees could very well have the effect that it destroys the business models for the projects that are currently on the IC. This is not a topic that should be discussed/implemented haphazardly.

3 Likes
58

Yes, I think increasing cycle cost for computation and storage is one important part of a multi-pronged approach as this will bring actual burn closer to node provider rewards.

However, I think we should consider other changes in parallel like tx costs (this is an easy low hanging fruit), lower gov rewards inflation, ensuring node providers are paid for PoUW, paying rewards over time (ie in locked neurons), etc.

There’s no silver bullet but all the potential levers should be defined with proper calculations and analysis of each followed by community/DAO votes.

4 Likes
59

Has anyone considered making the ICP token more expensive to transact? That would prob generate a big chunk

3 Likes
60

This point is not lost on me… make devs pay more = no more devs… not paying node providers = no more network…

Currently dev costs are being subsidised by the entire network… I’m happy to fund/subsidise dev work but shouldn’t this be voluntary ie based on fundraising and not blanket subsidisation?

2 Likes
61

In my personal experience, cycles costs aren’t exorbitantly cheap. I feel that the current pricing for applications where updates calls are made often is reasonable. OpenChat, Distrkt and DSVR, among other apps with large amounts of user generated content, would possibly be put out of business if cycles costs are altered.

7 Likes
62

You make good points and I don’t think your proposal is less valid than any other. It’s just not something I would support if the goal is to keep the ecosystem alive.

6 Likes