I question whether a grace/transition period is needed to implement this, because:
We’re at a point where node-running profits are very low, so 21 day unstaking period may not hurt as much as it otherwise would. In addition, if there’s infrastructure commitments in place, a node runner would be incentivized by the unstaking period to keep the revenue stream going by unstaking in portions over a period of time as opposed to all at once.
There was some information in another thread indicating close to 40% of node runners are small, and they would have no reason to unstake. They would see increased earnings during the unstaking period, and would be incentivized to stick around and do servicing work, even if whales suddenly decide to mass unstake.
The network is over-provisioned, so it should be able to handle 1 billion relay traffic with a fraction of the 47,000 nodes it currently has.
The good citizens of the community would no doubt be ok with keeping a portion of servicing nodes active in order to ensure network stability - without which they would tank their own investment.
When Adam shared this draft with me I tabled my proposal to increase the minimum validator stake in favor of GOOD VIBES. This uses native market incentives to decrease the minimum validator count with minimum friction to the network.
This proposal included with the light client will solve most of the issues we have today. It will allow us to step down rewards as we become more efficient, allowing POKT purchases from applications to have more impact.
In a GOOD VIBES world I would also opt to increase the DAO allocation in a separate proposal as well.
I would love to see this proposal voted on ASAP.
There may not be a need for a grace period given where we are at with the cost model today. It is better for me to unstake and eat the 21 days than pay the monthly fee.
Agree, as we get more efficient, we can continue to lower this number.
This is standard for any proof of stake network. From the start, pocket has had an extremely favorable distribution across every token holder and is not at risk with 1k validator slots, given the distribution of POKT across all major holders.
If i’m running 2 servicers and I don’t receive validator rewards, I naturally earn more rewards for my 2 servicers as validators consolidate and earning on proposing blocks. The purpose of this proposal is that it balances out.
The important part of this proposal outside of the consolidation is that it provides a WAGMI-like step down in rewards as the network begins to consolidate. We should be aiming to have the network be as efficient as possible regardless.
We should be working towards upping the incentives to stake more POKT on validators. The network is extremely vulnerable otherwise. This is what provides the economic security for everyone.
We have already changed the security model once. The intention was that all nodes staked would be participating in block production. Due to the limitations of the protocol we had to limit this to 1k. This is increasing the security of the network while allowing for servicers to earn roughly the same amount as validators.
It would be designed to provide an even playing field for liquid or currently staked POKT.
At the moment, there are 1000 validators. That could change via a proposal.
I’m open to further deceases, but every time I’ve proposed something to this extent, it’s been HIGHLY unpopular. I’ll point to: PUP-12: Inflation Stop-Gap Proposal: Double Trouble as an example. I built in a mechanism for accelerating decreases to the mint rate above and beyond a proportionate decrease. That would look something like this @lex :
Inflation would be about 105M at the MVNC. If I hear others call for this, I’ll edit the proposal.
Looks like an oversight. I’ll get in there and correct things. Thanks @addison.
While I’m heavily in favor of the idea of the light client, I am thinking that there is a non-zero cost to the light client, as light as it may be. Meaning at the end of the day, more clients = more costs. According to Addison, these costs are very much non-zero At 50% of the cost, low long until we’re at 80K or even 160K nodes? What does that mean for network cost? It’s a little too early, in my opinion, to consider that the silver bullet until it plays out in reality. Further, why not do both? Operate at a more ideal node count, with very low costs? Seems like a win-win to me.
In an ideal scenario, this would be well coordinated and node runners would have a chance to get ahead of the changes meaning that changes wouldn’t take effect until everyone has had a chance to make their moves. It should be an even playing field. If someone does want to front-run, they’d be securing the network.
We’ve seen this continually with launching new service nodes; therefore, I’m not sure I follow the logic. Further, unstaking penalties make it costly to marginally decrease your stake.
At current costs, it definitely is. Post-light client, we will see. To your point, I think you can have the best of both. Liquid POKT is staked on validators (great) and we have low cost servicers with the light client (also great). I think where the rubber meets the road is with node running services which will offer validation services that put little strain on the market.
Let’s do both?
I’m convinced that incentives overcome the complexity that this introduces.
Given PUP-14: Increase MaxValidators to improve economic security - #29 by addison, it feels like we need this. The simple solution would be to just up the validator incentive arbitrarily, but I think you run the risk of migration back to servicing if not dynamically adjusted, jeopardizing network security.
Keep in mind that there is a 15 chain limit per servicer. It’s not like costs per servicer vary based on how many chains Pocket Network Supports.
I think this is a separate issue that GOOD VIBES does not intend to address. See below:
And while PUP-15 seems nicely thought out, It won’t help the price. The only solution is stake weighting. And it’s such an important solution that devs should not lose time with coding GOODVIBES and instead completely focus on stake weighting. And yes they should release staking preferably on a testnet in the next week at latest if they want this project to survive.
If price goes down a bit more, mass unstakings will happen.
This enables a form of stake weighting without needing to change one thing to Pocket Core. Stake weighting is a large change to the code base that will take time to implement.
With this proposal we’re incentivizing consolidation of stake by adjusting some of the parameters, allowing it to be implemented as quickly as possible.
To be clear, GOOVIBES is s a no-code, parameter-driven solution. Ideally, this would be a stop-gap until the servicer stake weighting can come into place.
Agreed, but this extreme measure to change rewards to this level introduces a very large imbalance which I’m can’t seem to justify.
Taking @adam’s suggestion of incentivizing the network to only have balanced rewards at 15k servicers, with the amount of POKT staked today the GOOD VIBES staking ration would look like this:
Validator Stake: 495M POKT Servicer Stake: 240M (assuming all 15k validators are staked at 16K POKT)
Yes, the network is secure with 495M staked on validation, but from my understanding this is extreme overkill for what is required to secure the network.
By having 2/3 of the network staked in valdiation and only 1/3 staked in servicers, this create many potential issues and inequalities.
ISSUE 1: Validation becomes top heavy and centralized
When this happens, the network is locked into a node class that controls 2/3 of staked POKT.
How do you role back 2/3 of the POKT staked once validations becomes too top heavy and centralized?
Changing mechanisms that lower validation or validation APR can put the network at risk if there is unstaking. The whales in this class of node will likely become uncontested with no meaningful ways to reverse course without endangering the validation of the network.
Validation incentives can always increase without issue on the Pocket Network, but they cannot be decreased/reversed or the network risks unstaking of validators. Once this level of valuation is in place, I don’t see how we can ever reverse course until v1.
ISSUE 2: POKT becomes primarily about the validator economy
With 2/3 of the staked POKT dedicated to validation, the focus of all economic decisions will primarily be driven by validator incentives. POKT can not role back validator economics to benefit servicers because 2/3 of POKT is committed to the validation economy.
It is likely that most whales will be entirely focused on the validation economy because GOOD VIBES is encouraging validation to be 2/3 of all staked POKT. Most whales have no reason to even run servicers since their entire stake can be inside of validation.
All future economic decisions will likely favor the validation class because the security of the network relies on them and they hold all the validator voting power.
ISSUE 3: Growth taxes servicers to the benefit of validators
If there are ever more than 15k servicers, then the servicer class is essentially taxed by lowering their reward to give to the validator class (which are exclusively whales). If independent node runners join the network, servicers are not only diluted but they also have to give a extra % to the validators.
This mechanism doesn’t make sense unless 2/3 of the network is required to be staked to secure the network… and from what I gather, this 2/3 is extreme overboard.
Servicers already have delusion when new nodes join, plus they have massive infrastructure costs from running chain nodes… so then adding this % tax to be given to validators makes no sense.
Issue 4: Lite client addresses over provisioning.
Why though?
If over provisioning is addressed with a lite-client, why do we need to adds an economic mechanism that favors whales over independent node runners?
If the lite client does what tests have currently shown, then the need to decrease the # of servicers by giving more rewards to validators isn’t needed for the good of the network.
PROPOSED REVISION: Adjust the block producer reward without adding the dynamic % to decrease servicers numbers.
If we were to increase the block producer reward enough so that 1/3 of all staked POKT is focused on validation, then the network is secure without penalizing servicers.
Right now 17M POKT is dedicated to validation… which as we know puts the network at risk.
If we instead looks to incentives 240M POKT to be dedicated to validation, we secure the network.
This leaves 2/3 of the staked POKT focused on servicers. There will be significantly less imbalance and it will decrease the current node count from 48k to around 33k because of servicers being moved to validations.
We then start with 33k and the lite client on the way. As you point out Adam, the network is still growing, but from the data from the lite client, over provisioning will likely be fully addressed in the immediate to mid future.
If we ever need to increase the validation reward to increase security or lower service number, we can always increase it validation rewards at the right time. I’m not saying to change it “arbitrarily”, I’m asking we simply adjust it to what is required for the network to be secure. But with the current GOOD VIBES in it’s current state, we cannot reverse anything without putting the network at risk.
The lite client does not address over-provisioning. It actually further enables it. As long as the cost to run a node is non-zero, over-provisioning is waste. A light client implemented in isolation will add fuel to the fire. Node growth is butting up against infrastructure costs , so once you remove that obstacle the node runner arms race re-starts, with a vengeance. This is so elegant because is solves multiple problems with one proposal:
It provides a mechanism for making the network self-balancing around the number of nodes it needs.
It provides a mechanism to taper inflation to sustainable levels.
It resolves the network security issue reported in another thread.
It incentivizes hodling by whales by creating an incentive to keep adding in order to stay in the top 1000.
The lite client does none of that. That’s doesn’t mean it’s not valuable, it’s very valuable. The light client resolves a technical issue, PUP-15 resolves a few economics issues and a security issue. Together they will put us way ahead in the right direction. There’s pros and cons to everything, but as a stop-gap until stake weighted selection is ready, this is about as good as it gets. It’s genius, actually.
I think we are defining “over-provisioning” in different ways.
Over-provisioning, from my perspective and the perspective of the lean pokt proposal, is that the infrastructure cost of to run the network is significantly over what it should be. Over-provisioning doesn’t have to do with the amount of nodes but the overall cost of nodes. It’s about the efficiency of nodes, not the numbers.
The lite client reduces the cost of infrastructure significantly, which is why it will likely solve the over-provisioning problem.
Node growth isn’t a bad thing. That means more POKT is being locked up and stake… leaving less on the open market. That is a massive plus for any crypto.
With the amount of resources required to run a POKT node being dramatically reduced, we can continue to allow node growth with only adding minimal infrastructure costs. This actually creates buy pressure on the market until the Portal releases app staking.
Regardless of if GOOD VIBES is released or not, with the cost of running nodes being dramatically decreased, it will likely create more node growth. The catch here, is that with that node growth, servicers start to have their rewards reduced and given to the validator whales via GOOD VIBES.
Whales will benefit the most the most in terms of rewards when the lite client is released. GOOD VIBES isn’t required to secure the network (I already shared that upping the block production reward secures the network), but it does create a mechanism that rewards whales disproportionately when there is node growth.
How is incentivizing the ecosystem to lock up 2/3 of all POKT into validators balanced? My argument is that this is not balanced and once 2/3 of the network is staked solely on validators, the network likely can’t reverse course to account for new network conditions until v1.
495M POKT is not required to secure the network today.
GOOD VIBES mostly nullifies the need for weighted stake. With 2/3 of the network staked into validation, adding weighted stake for servicers only effects 1/3 of the network. Sure it can help a little with not having to run the lite client, but the lite client is super efficient already and weighted stake would have little effect on infrastructure costs.
Even with weighted stake, many folks (like pools especially) will likely still use the lite client so that they can unstake portions of their holdings. If you put 75k POKT into one node, then if you ever want to unstake a node or two you have to unstake the entire amount. The lite client would allow you to unstake smaller portions, which will likely be preferable for many node runners.
GOOD VIBES reduces the servicer economics to a point that weighted stake will have likely no effect on meaningfully decreasing network resources. It does all compounding rewards, which I’m a fan of, but that is outside the scope of what we need to address now.
I think the fatal flaw in all this is assuming that everything stays the same in the future. Yes, the lite client allows you to keep stacking with minimal infrastructure costs. For now. Will that still be true in 3 months? 6 months? 1 year? Who knows. Blockchains grow, new needs arise, exponential growth has a habit of coming back to bite you when you least expect it. Putting all our eggs in the lite client basket means eventually finding ourselves in the exact same position, maybe not too far from now, but with an even worse problem. If there’s anything that can be guaranteed, it’s growth in computational complexity. And good luck with that when there’s 100k nodes for no reason, and no more lighter clients in sight.
Relying on the lite client alone means we’re just kicking the can down the road. And we might not be kicking it very far. The network has underlying structural and economic issues that need to be addressed. We can choose to sweep the dirt under the lite client rug, or address it head on.
Validator stake can always be raised when needed to incentive less servicers when needed. GOOD VIBES makes validator stake so extreme, right off the bat, and it’s not reversible without putting the network in jeopardy. GOOD VIBES is the definition of putting all your eggs in one basket since nothing can be reversed.
Do we want/need to reverse anything? Once weighted stake kicks in, I would expect node runners to consolidate their stakes anyway in order to reduce costs , which would naturally result in the top 1000 being fairly large stakes. The spreadsheet has the average validator stake at the target 15,000 nodes near 590,000 POKT. I can definitely see servicing nodes staked that high once weighted stake kicks in. You made the point that pool operators may want to keep their stakes low in order to unstake portions easily. I think in the end, in addition to infra costs, we also have to consider management/administrative costs. Would Jinx rather have 4,000x15,000POKT nodes on the books to manage, or 100x600,000. It might turn out to be a mix, but I think once consolidation becomes possible, it’s going to end up top heavy and less diverse regardless.
I’m convinced people will act in the best interests of the network and will agree to approve sensible proposals that reverse course when a better, code-driven methodology can be applied. Until then, we need to focus on controlling the costs of the network through proposals like this (and others).
I think where falls short for me is that we’re assuming people won’t act/vote in the best interest of the network. Although the community has taken some time to come around to reducing inflation and changing incentives for different parties the important point is that they have come around.
To that end, I think we’ve all learned a valuable lesson that we have to balance validator incentives with servicer incentives so that we do not end up in this position a second time.
I view this as a potential feature. We want a strong validation base. It’s an effective sink and leaves room for people to compete as servicers. The more people retreat into low-cost validation, the more inflation can be reduced, and the more we can focus on low-cost servicing.
This is an important point, as validators do act as a veto. With great power comes great responsibility - and we have to trust that validators will take that responsibility seriously. To take things a step further, this could be the case today as well, but we haven’t seen such things abused.
I wouldn’t consider this a tax as servicer returns remain stable and then increase as node count increases. An individual doesn’t make fewer rewards as node count increases, they remain stable and then increase according to the curve. The alternative is excessive inflation to maintain the current node base OR arbitrarily picking a validator % and hoping that achieves the right balance between validators and servicers.
From my perspective, this is the only reasonable tool we have at our disposal that we can leverage to control node count. While some may view it as a tax, it may be necessary until servicer stake weighting is released (if ever). Without this mechanism, things are too difficult to predict and will lead to supply-side churn.
There’s a fallacy for light client maxis that this solves all the network problems. It only temporarily solves the problems because it’s only effective at reducing the cost one time. Certainly, as we’ve seen in Pocket Network, if there is a reason to stake additional POKT on more nodes people will.
What happens when we cut costs by 50% and then double the node count?
This proposal optimizes for eliminating overprovisioning, which is where the focus needs to be.
I’m in favor of adopting a framework so there are not weeks of modeling and design plus weeks of debate every time we need to make a minor adjustment. GOOD VIBES can provide for these adjustments over time, given its flexibility. If the DAO decides it wants more or fewer servicers, this framework provides for that.
I think the importance of this proposal is that it provides stability to the network in terms of service rewards that are unpredictable otherwise. The natural incentives will grind down small node runners as they are outcompeted with better resources of the whales. Getting them to focus on low-cost validation might free up an opportunity for the little guys/gals.
To @iaa12, let’s stop kicking the can down the road and implement a solution that will get us to v1 with security. Further, let’s unroll it when facts on the ground change in a meaningful way where it no longer makes sense to spread the GOOD VIBES around.
Assuming the goal is to build a network that is the go-to infrastructure for all Web3 apps someday, wouldn’t more nodes always be preferable to fewer nodes? I understand wanting to cut the number of nodes now is because we want to lower the cost of running nodes (to make it more profitable/sustainable for node runner). Or, is it because we want fewer node runners (of any type) earning rewards?
It seems to me that if the cost of running nodes was reduced dramatically as it would be when the LeanPOKT / light Client is released. Node runners would be more profitable and more sustainable in down markets. If that were true, why would we want/need fewer nodes other than to consulate rewards to fewer participants? I’m not saying that’s necessarily bad, it might be necessary for the short-term health of the network. But, I’m still not understanding why, aside from the current high-cost of running a node, fewer nodes would be better in the long-run.
I believe this is the same point @Shane is making. But to restate… If node costs were lowered to the point that running nodes was profitable in almost any market condition, would we still want to cut the node count? If so, I’m just not understanding why.
In particular, the cost of the backend servers which provide Pocket’s actual product is not being factored in. Small scale node runners use third party services now because the cost of the backend servers is greater than the the cost of the nodes. Light Clients will only exacerbate this effect and mid-sized node runners will also capitulate to using 3rd parties.
I need more time to math up and consider the ramifications of this, but at this moment it seems like shutting down the node running business and just throwing everything into a single validator will be more profitable (and a whole lot less work) than constantly optimizing and adjusting just to fight for the scraps.
Giving 80% of the network’s income to stakers rather than producers is a HUGE redesign of Pocket’s economic incentive model. I ask that if you push this to proposal please slow down on the rate of change and allow the unintended consequences to show up slowly.
If we do this and increase the number of max validators to 2k, 3k, 4k, 5k, then we can have a pretty secure network without shifting the “proof of work” reward model from servicing to validating.
Also, @adam could you elaborate on the various unstaking scenarios you have in mind on how to do this transition gracefully? I didn’t quite understand how it would be done without creating large sell pressure.
Another question: Let’s say this gets passed and then later gets repealed - what is the game plan for validators who have a bunch of POKT staked, will they be expected to wait the 21 days to unstake so that they can convert to servicers?
While I am not yet a DAO voter, I hope to be in the coming days and weeks. As a member of the community, I wanted to voice my support for this proposal.
No proposal is perfect and no one can predict the future or the unintended consequences of a change. We can debate all day long about the merits and we can address details that might have been overlooked but we will never be able to predict the future.
I think Good Vibes takes into account the current climate and provides a solution to address some of the headwinds the network is facing and will face.
I support it and I appreciate the openness to be agile and modify as we traverse the future.
We are optimizing for total network costs, not profitability of nodes. Profitability is a function of rewards and the token. Whatsmore, even if nodes are “profitable” this leads to significant pressure on the market that needs elimination to promote a healthier ecosystem. Give this a read for insight into this problem in the Ethereum ecosystem.
Lowering costs one time through optimizations only kicks the can down the road rather than helping guide the ecosystem to sustainability. If we can lower node costs and control count, why not?
We can encourage node churn through economics (which has nasty consequences) or incentivize validation keeping the stakers in the ecoystem (and secures the network).
The only thing we control in this scenario are the curve (incentives). The players in the ecosystem will make their own decisions as to whether to validator or not. We cannot dictate how the unstaking happens. Attempting to coordinate could lead to a prisoner’s dillemma style event, where node runners are forced to trust in the actions of others for the optimal outcome.
Implementation wise, there is some discretion given to the Foundation to deliver an effective coordination plan that is well thought out. I will not commit to anything, but my thought was to select an effective date of the change with enough time so that people can unstake and prepare for the change. Each node runner would then decide what to do during this period and would either stay as a servicer or unstake in prepartion for validation.
For example, let us say that the announcement was made 30 days in advance of the change (assuming a 21 day unstaking period). This period would buy everyone enough time to make a change while giving the Foundation a good idea for what to expect. On day 30, the economics would take effect. In an accelerated process, the unstaking period could be reduced to 7 days, the process could be done in as little as 14 days. It is advisable that the devs make the decision on the unstaking period from a security perspective.
This is an open question. I would suggest the same unwinding period occur in the proposal that calls for GOOD VIBES’ repeal.
Have we realized that with 15k servicers, and these types of APY goals, servicers will be squeezed to only generating 10.57 POKT a day? This is only 25% of what a servicer currently receive daily.
This is pulled from the GOOD VIBES spreadsheet. This goal is set for servicers to generate 10.57 POKT and validators to generate 407.78 POKT a day.
What research has gone into what the servicer node landscape will look like if servicers are squeezed to only receive 10.57 POKT a day?
By paying servers 10.57 POKT a day, how many servicers will an individual have to own to at least break even with infrastructure costs with only $41 worth of reward a month?
What type of infrastructure environments will likely be needed for servicers to make the same APY as validators with only 10.57 POKT per day and high infrastructure costs?
How many individual node runners will not have enough POKT for a validator but won’t have enough servicers to break even with 10.57 POKT a day?
Yes sir. The goal is to reduce the number of nodes, so rewards have to be reduced to incentivize that. It’s the inflated rewards that allow 47,000 nodes to exist today, so rewards have to come down in order to address over-provisioning . The other option is to keep minting and wait for the token price to drop to a couple cents.
I would argue there is no break even, regardless. It’s false income. There’s no money coming in from anywhere at the moment. As a node runner, you can pay for infrastructure by diluting your stake with high inflation, or you can pay for some infrastructure out of pocket, stop diluting your staked assets, and watch the token price rise as supply gets reduced, and later again as monetization kicks in.
Many. That’s the point of the proposal, to drive down the number of nodes to the target of 15,000. Pools will become a very viable option for these folks where they can benefit from economies of scale. It will greatly increase the overall efficiency of the network.
It’s no different than increasing minimum stake. If we go to 45,000POKT min stake, everyone below that gets unstaked and moves to a pool. Except adjusting minimum stake comes with pitfalls. Instead, PUP-15 creates the economic incentives to run 5-6 nodes in order to be profitable, while allowing for minimum stake to remain the same for future flexibility.
