PUP-17: The Phase Plan (a progressive plan for network security and optimizations)

UPDATED: Calculations have been updated. Target ProposerAllocation is now 21% instead of 27%. This change due to an over calculation I discovered when refining the numbers. Feel free to check out the formula here.

Attributes

  • Author(s): @shane
  • Parameter: ProposerAllocation, ServicerAllocation, MinimumStake
  • Current Value: ProposerAllocation = 1%, ServicerAllocation = 89%, MinimumStake = 15000
  • New Value: ProposerAllocation = 21%, ServicerAllocation = 69%, MinimumStake = 30000

Summary

Securing the network, reducing network infrastructure, and continuing to reduce inflation are currently top priories of the DAO.

GOOD VIBES seeks to address these challenges with a new economic framework that centralizes decision making and prioritizes validators. However I believe our challenges can be addresses while preserving our current ecosystem model with significantly less risk.

Core-devs saw ahead when designing pocket-core and knew the network needed parameters to account for ecosystem conditions. We already have all the parameters we need to address today’s challenges in a safe and effective way, so I propose we use them.

THE PHASE PLAN

I am proposing a 2 phase approach:

Security Phase:

  1. Block producer reward increase
  2. Minimum stake increase

Optimization Phase:

  1. Lite client
  2. Inflation adjustment (akin to WAGMI).

Motivation/Rationale

Phase 1: Security Phase

The Security Phase needs to happen now. We need to secure the network by increasing block production rewards. Any changes to the block producer rewards will create an unstaking event where large numbers of servicers need to unstake to consolidate POKT to create a validators. With there needing to be an unstaking event already, I suggest we also increase the minimum stake required for to run servicers as well.

Why change minimum stake? It will reduce the number of nodes on the network while the lite client is under development. By incentivizing node consolidation on both the validation level and servicer level, we can reduce the number of nodes on the network by 55% while securing the network from validation attacks.

PARAMETER CHANGES

Validation Rewards: 21% (Currently at 1%)
Servicer Rewards: 69% (Currently at 89%)
Minimum Stake: 30,000 (Currently at 15,000)

RESULTS

  • Network secured with 26% of POKT staked in validation
  • Node count and network wide infrastructure costs cut by more than 50%
  • If 90% of circulating POKT is staked into nodes, the most amount of nodes on the network would be less than 26k (we will never have 48k+ nodes on the network until potentially after v1)

TRANSITION EVENT

Similar to what GOOD VIBES proposed, we would likely need an unstake transition event to give nodes the ability to consolidate into validators and servicers without going through the 3 week unstaking period.

From GOOD VIBES :point_down:

Phase 2: Optimization Phase

Once the network is secured and network wide infrastructure costs have been dramatically reduced, we are in a good place to further introduce further optimizations.

LITE CLIENT

Thunderhead and POKTfund’s v0 contributions have kicked off the potential for a lite client which could even further reduce network wide infrastructure costs. They will be working with core-dev to finish the prototype, QA, and hopefully bring to market. The core-devs have already created their own code-complete prototype which has proven it’s initial viability.

Once the lite client feature is added to pocket-core, then we are in a solid place to optimize inflation without crushing node runners.

INFLATION ADJUSTMENT

With the network already being significantly optimized by reducing the number of node, and having a lite client feature, we can continue initiatives like WAGMI to find the sweet spot for inflation while the core-team is building app staking into the Portal. The inflaton goals outlined by @adam in GOOD VIBES could be optainable without fundamentally changing Pocket’s economics model.

The benefit of doing inflation adjustment at this point is we will have real data on how these new optimizations have effected the network. Adjustment can be made with real world data instead of using projections. Decisions can be made that consider and protect both validators and servicers.

GROWTH POTENTIAL

One of the benefits of this approach, is there is still room for healthy node growth. By reducing the number of nodes on the the network, and making them cheaper than ever to run with the lite client, there will be ample reasons why folks would still want to join the Pocket node ecosystem.

By increasing the minimum stake parameter to 30k POKT, the network will only have 4k more available nodes (when looking at the circulating supply).

This could be leveraged to generate excitement and encourage folks to purchase Pocket nodes.

“Right now Pocket has a max node count of 26k and there are only 4k spots left!”

Currently 78% of circulating POKT is staked into nodes and why not shoot for 90% (especially since POKT is designed for higher inflation)? That would put circulation supply in a good position for when app staking is released.

Dissenting Opinions

Increasing minimum stake would cut off those who only run 1 POKT node.

Yes, this is a fair critique and a concern. Currently there are around 80 single node operators. These users would likely need to top off their nodes to continue generating revenue with a single node. Fortunately POKT is the most affordable it’s ever been so topping off now could be within reach for many.

There are upwards of 1000 single node customers using node hosting services. These node owners are also in a predicament when increasing the minimum stake. However, fortunately Pocket is a robust ecosystem with services that offer node pooling. This means that these users have options to simply change from one service to another.

We are in the unfortunate position where any change to the network effects users in different ways. Whether it’s cutting servicer rewards (like GOOD VIBES suggested) or increasing minimum stake, changes will always hit folks differently. Please respond to this post with concerns on how any of these changes may effect you.

We should be targeting a max of 15k nodes on the network.

I haven’t agreed with the 15k figure since it was introduced. Pocket was created on the idea that we would eventually have hundreds of thousands of nodes, and while we have limitation with v0, I don’t think we should forcefully regulate node count to a set number.

15k is as arbitrary to the 20k I’m suggesting. With the strategy of increasing minimum stake we have a clear cap on the amount of nodes that can be staked with our current circulating supply. I feel it is much more elegant to have a natural node cap vs a regulated cap.

Mechanisms like GOOD VIBES make Pocket’s economics significantly more complex, especially for new users trying to enter into our economics. I think we need our economics to be approachable (which it has been) so I suggest we take advantage of the tools we were given for this exact situation and keep things moving forward.

We need to move faster on all these areas, and doing a phased approach is too slow.

With just the Security Phase we can address our most pressing needs in a very quick fashion. We don’t need to build anything other than plan a Grace Period which would need to be part of any solution we take.

To tackle every need of the network, I think we need a progressive plan that can be taken one step at a time. It has taken years to get us to where we are today, and making huge sweeping changes is a major security and economic risk.

We should focus on weighted staking for node consolidation instead of increasing the minimum stake.

I am all for weighted stake and I believe that concept would be the best solution. Unfortunately weighted stake is a very complex feature that will take notable time to develop, test, and deliver. Weighted stake would need to be a network fork.

Pocket CTO @luyzdeleon talked about the technical challenges that will need to be overcome before weighted stake will be a reality.

I believe most of the community is looking for a more immediate solutions than what weighted stake can supply. The Phase Plan still keeps the option for weighted stake possible since it isn’t changing Pocket’s economic model to be validator focused.

Requiring an unstaking event is risky.

So far, every solution in these discussions require unstaking. A coordinated consolidation event is going to be required regardless and since most nodes are controlled by 3rd party hosting services, coordinating the transition is very possible with PNI’s support.

Analyst(s)

Shane Burgett (@shane)

Copyright

Copyright and related rights waived via CC0.

4 Likes

Thank you for such a thoughtful and well-written proposal for the ecosystem. You make some strong arguments in here.

1 Like

Thank you for posting this, great to have choices. After the GOOD VIBES v1.1 update I’m on the fence, I need to chew on both for a while.

1 Like

Great write up Shane! is 27% not too high for validator rewards? I’m worried we will have a never ending race to the top if we over incentives it. If we keep at 1000 validators if you were on spot 1000 and got kicked back to 1001 you will have to stake more to be pushed back in the set (otherwise your excess tokens will be wasted, without a means to reduce stake) so it will be a never ending ladder.

I think we are over complicating weighted staking here. I pitched my solutions in comments about it here Weight session selection by staked amount - #15 by Andy-Liquify.

imo the easier and better solution would be too keep session chance completely random and just scale the rewards based on stake.

5 Likes

I agree that 27% is too much for validator rewards. Some node runners don’t seem to realise it yet, but in actual fact it’s already really profitable to stake a bit extra and become a validator as well as servicer. We’re talking about an extra 2-400 pokt/month for an additional ~1000 pokt staked. And with each subsequent WAGMI adjustment it becomes even more profitable, relatively speaking. The validator distribution problem should solve itself over time.

1 Like

Good feedback and questions @Andy-Liquify and @StephenRoss. Let me know if I’m able to answer your questions below.

The numbers can indeed be adjusted.

What is important with the validation is ensuring that enough POKT is staked to protect the network. Currently we have 17M staked in validation, which leaves us vulnerable to validation attacks, so what I’m proposing puts us for use over 200M. This is why I believe 27% makes sense.

I get what you mean about validators being bumped out. At the bottom of the validator pool it will be unpleasant for validators as they can easily fall out of rewards if a new one comes in. To address this changes will need to be made to the protocol, which I think we’ll want to look into.

Back in 2019 PNI joined the ICON network as one of their validators. They had a 21 validator limit and if you were not in that top 21 then you received no rewards. This was hard on their community so they eventually made it was more of a smear (instead of a hard 21 cap), and those under 21 still got some rewards. I suspect it would be in the best interest of the network to do something like that at some point, depending on how much gaming is happening in the validation space, but I don’t believe it’s wise to wait when we have current needs.

Unfortunately, we need to act now and we can’t wait for a more ideal technical solution which will take significantly more time. I do love the idea of weighted stake as you describe but that will take serious development. Here’s what I wrote about it, but I’d love your take on Luis’ comments :point_down:

Open to any more thoughts on this :slightly_smiling_face:

2 Likes

Ok I like the long term idea of “tiering” it!. I am worried short term there will be a lot of excess staked doing nothing without any means to reduce stake (without pulling a node)

The way I mentioned doing it mitigates the issues Luis mentioned on his call scaling rewards and not chance to service won’t impact end user experience or have increased bloating since nothing will change to the low level as far as I can see, you lose a lot of the complexity. Should just be a couple of lines of code changed in RewardForRelays() function.

3 Likes

@Andy-Liquify and @StephenRoss, after looking into your feedback, I ended up updating the formula.

I believe I was over calculating the amount of rewards required to get over 200M staked. I’ve edited the proposal to reflect and have shared a spreadsheet with the formula.

Instead of 27%, I’ve adjusted to 21%.

3 Likes

I’ve pinged @luyzdeleon about this. I’m interested in his take on this different method to approach weighted stake.

2 Likes

Is this so? If this is the case, do you think PUP-17 : The Phase Plan or PUP-15: Good Vibes is even necessary?

To protect against a validator attack we need significant POKT locked into validators… so the block production reward does have to be dramatically increased.

Today we are around 17M locked in validation and we need to at least 10x that to protect the network. It’s not so much about validator rewards… it’s about the amount of POKT locked in validators.

1 Like

Agree. That is a key objective. Hence the value of this proposal and why it is compelling.

Given @StephenRoss 's observation - is it so profitable to be shifting to Validator nodes in natural statethat it would 10x shift to protect the network if unabated by any DAO proposals?

POKT nodes generate 40ish rewards a day, which is 1,200 POKT a month. Even at the max, an extra 400 POKT (which it doesn’t consistently play out as that) could likely increase to 20M staked in validation vs the current 17M. We are talking about a thousand nodes only locking up a few thousand each to become a validator to maximize on today’s rewards.

After 20k stake per validator, you would likely receive a better APR by deploying another servicer, over continuing to increase your validator stake. This is why we need to increase the reward dramatically so we can reach closer to 200M staked in validation.

2 Likes

Agree with @shane it’s not going to get us to 200M staked in validation. Maybe 20M, maybe a little higher but definitely not 200M. The distribution of validators should improve over time though.

Just asking the question though purely as a layman, why do we need 200M staked in validation? That’s over 50% of all the unstaked pocket in existence. Seems a lot? :man_shrugging:

1 Like

200M is what I’ve heard talked about and it makes sense to me. It’s not just about being over the unstaked amount, but also the amount of validation power anyone participating in the network already can amass. Currently our validation is not spread out. To be decentralized we need to make sure that no one entity can accrue enough POKT to control validation.

Open to other ideas on amounts… but from what I’ve gathered, 200M has been understood to be safe.

(This relates to Shane’s current proposal.) So said Addison under PUP-14 in regards to network security and his proposal to 5x the number of validators. No one responded to Addison’s comment. Is his concern valid? It certainly needs addressing.

If it is valid, perhaps the number of validators should be upped somewhat as a tweak to PUP-17? I did not see any core devs weigh in on this issue or on the related network bloat aspect.

But I do note Jack’s comment on PUP-14:

In another vein, I suggest that before voting on the current economic proposals (Good Vibes etc), a presentation (with a debate component?) be held on Discord by the proponents of the competing visions and that a core dev also participate to ensure that important technical aspects are not overlooked. The written contributions have been extensive and a debate would bring some focus and help the voting public and wider community to better understand the pros and cons. There could be a moderator (Jinx?) and presenters could field audience questions.

1 Like

Thanks for your proposal @shane. I’d like to address the proposal to raise minimum stake.

Based on my research, there are 306 unique Pocket node service domains as of block 61834. Working on the hypothesis that each unique Pocket node service domain represents an individual node running entity, we can estimate there are 306 entities running Pocket nodes. Of those, 86 entities are running a single node. Under the proposal to raise the minimum stake to 30k, these entities (comprising 28% of all node runners) will be forced out. There are also those currently running 3 nodes who will be affected, as they will have to drop down to 1 x node. This will affect 18 entities or 5% of all node runners.

It’s no small feat setting up to be an indie node runner as these entities have been dubbed. It involves tens, if not hundreds, of hours of work to configure a Pocket node and the supporting blockchain RPC nodes. Upping the minimum stake to 30k will effectively knock these folks out of the game, and I feel this is a rather drastic way in which to treat a sizeable number of the node running community. I also feel it sends the wrong message about how small node runners are viewed and the role they play in the ecosystem. The knowledge that one could get knocked out the game as MinimumStake is modified is a disincentive to start running a node.

Is it worth “sacrificing” a few (or not so few in this case) to save the many?

Implicit in this proposal is the understanding that increasing MinimumStake would force-unstake nodes beneath the minimum stake amount, regardless of when that node initially staked. I would be far more comfortable with this proposal if the MinimumStake parameter update only affected future stakes, not existing ones. Its also been stated that that is probably not possible without (significant) Tendermint modifications. I wonder if anyone from the Core Dev team could confirm this?

I can only imagine that implementing this change would be highly disruptive. We also suspect/know the POKT token is very underpriced at the moment. In the event that the token recovers in value, the 30k stake amount is deemed too much of a financial hurdle for smaller entities to enter the ecosystem, and a reduction is proposed; that would incur another risky and disruptive mass (albeit unforced) un-staking event as node runners optimise for servicer rewards.

I am a small node runner. I won’t be affected if the MinimumStake is raised to 30k. I have invested countless hours into setting up my node infra, and I hope to become a DAO voter soon. I love what Pocket does, and the utility it has. I know I’d be pretty destroyed if I got knocked out of the game. Putting POKT into a pool or 3rd party provider as an investment is one thing, but running a node is another thing altogether.

In summary, I’m not sure if I could support the proposal to raise MinimumStake based on how it would affect small node runners, except in one of two scenarios. a) that it only affect future stakes, or b) is is a measure of absolute last resort.

3 Likes

I greatly appreciate your comment. The 86 node runners is the major issue with this proposal and one it should be flushed out. Thanks for laying it all out.

I agree that this should only be a measure of last resort, which is why I’m posting it now. There are very few options to address today’s economic situation.

The most notable that has gained attentions is GOOD VIBES which seeks to put economic control of Pocket behind centralized levers that primarily focuses on locking the majority of POKT into validation. While I appreciate the goals it’s trying to achieve, it makes POKT a validator focused economy and sacrifices Pocket’s decentralized economics to a centralized committee, who decides which nodes are more profitable when. I don’t believe that is a good idea.

The lite client is still a ways away as it needs to be finished and QAed.

Weighted stake also needs development and testing, so it is likely not a short term fix either.

So when it come to short term options, it looks like we have two options:

  1. Raise min stake (The Phase Plan)
  2. Relinquish economic control to a centralized committee (GOOD VIBES)

I’m open to ideas that would not effect single POKT node runners but they haven’t been presented yet. There is a natural evolution that has been a part of all major blockchains, where growth requires changes that require folks to upgrade. Bitcoin mining is a good example where miner do need to keep upgrading their hash power as more folks join Bitcoin mining. Pocket may need to be similar in that way.

Fortunately tipping of one’s POKT is very reachable right now with today’s market condition. Most of the single node runners staked their node before May, which means POKT is magnitudes cheaper than their initial purchase.

If upping the minimum stake can significantly reduce sell pressure, add a buy pressure incentive, and set POKT up for a scalable future, it may be in the best interest of those node runners to be behind this initiative. Open to feedback.

If there are other ideas, I’m all ears, but from what I’ve seen, this has the least amount of risk with the most quantifiable upsides.

P.S. There have been some that have suggest a good faith loan program for small node runner to ensure they can still keep generating rewards. There could be options to help the independent node runners, which I am ALL FOR. Open to more idea as well here :+1:

1 Like

I completely agree that the network needs to be secure, and I think this is a viable solution for doing so

My only concern is that by the time this proposal is voted upon, the minimum stake is increased, and a mass unstaking/restaking is coordinated, the lite client will be very near or already completed which will negate the need for increasing the minimum stake and will avoid losing 28% of our small node runners.

1 Like

Mass unstaking will always have to happen because of dramatically changing block producer rewards, so having minimum stake happen then isn’t much different IMO.

I’m all for mitigating the need for changing the minimum stake… but we haven’t received an official timeline on the lite client, so everything is guess work at this point. It feels like folks want action now, so this is the closest solution I can come up with while the lite client timeline is being worked out.