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.
As @adam pointed out in his proposal:
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.
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.
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.
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.
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.
This.
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?
Hi Adam,
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.
I will direct you to my thesis here: PEP-35: The v0 Optimization, LeanPocket - #20 by adam - pay attention to the charts about runaway node costs. You can see the effect here.
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.
So with this economic model… running servicers always comes at a loss compared to validators because the amount of infrastructure costs and time that servicers require. When you look at the chart, servicers never increase in rewards the lower they go, so they are pegged to an APY loss until the economic model changes entirely.
Validators though… they need servicers to generate their reward. They lose APY if servicers do not do their jobs at a loss.
So whales who are validators, will want to keep some of their POKT in servers at a loss (APY wise) so they can keep their validators generating all the real rewards.
The servicers are always meant to be generating a loss so that only those who have validators will have the capital to run servicers.
I don’t know what to call this economic model. Servicers are designed to run at a loss so only those with validators run them. Am I getting that right?
So if you look at the graph, at 15,000 node the APY lines cross. Once we go below 15,000 nodes, it becomes more profitable from an APY standpoint to be a servicer than a validator. Once you go over 15,000 nodes, it becomes more profitable to be a validator than a servicer. This is the mechanism that will balance the network around the 15,000 node target.
Servicers can run at a loss, but most likely they will either just run enough nodes to be profitable, or move to a pool. Whether we raise min stake to 150,000POKT, or tweak the economics so you have to run at least 10 nodes to be profitable, end result is the same. Weighted stake will have the same effect once implemented and should repeal PUP-15 once approved.
Loss or profit is a function of token price though. 10 POKT per day might put you well within profitability range with even a few nodes if token price increase by even just 10 cents. And a reduction in token supply and sell pressure coupled with a huge increase in demand - all of which this proposal will create - should have a very positive impact on token price.
I’m hearing a whole lot of “people will move to a pool” around this, but I don’t think it accounts for the fact that pools cannot build entirely around high stake validators for two reasons: it takes 21 days to unstake a node (including validators), and you’d potentially have to unstake a 150K validator to allow 1K pool participants to exit.
Stake weighting servicers works better for pools, because you can treat servicers like currency denomination: 10 100K stakes, 20 50K stakes, 50 15K stakes, etc., to provide the liquidity structure needed to let participants move in and out.
For example, in the last couple of tranches with poktpool, low returns have driven up our unstaking amount. When stakers request an unstake, we must honor that request. If we had all 150K staked validators, some stakers would be force unstaked against their will to cover the request of smaller stakers wishing to exit.
Pools themselves are a notable factor in the dramatic rise of node count, because they’re filling up servicers with small stakes. With Good Vibes, pools may choose to stake a handful of large validators, but the liquidity requirements prevent us from using megavalidators fully. Those largest validators would mostly be whales who do not have third party considerations around staking.
Certainly stake weighting is the ideal solution. This proposal only aims to act as a stop gap , since the dev team indicated it will be 6 months before stake weighting can be production-ready. Maybe we can get Thunderhead on it. Just kidding. But not entirely.
I certainly agree that pool operators will be faced with the task of making some decisions, as far as balancing reduced infra and administrative costs with the need for liquidity. It may end up being 80% in validators, 20% in 15k servicers, those are business decisions that only pool administrators can make based on their specific needs, market conditions etc.
Ultimately, this proposal only creates an incentive. Whether the network chooses to move in that direction or not, is entirely up to the network.
