Need to hear from @luyzdeleon if he sees a red flag in going forward w turning on a 60k cap
Can the foundation clarify on exactly how it will decide when to notch it up this parameter? Which metrics will we be using? i.e the average, p99 or p90, etc of all nodes staked before notching it up to 2, 3, and finally 4? I would like to see a defined criteria for this to set a level of predictability.
I canāt answer on behalf of the foundation, but let me add what clarity I can while waiting for a reply from a foundation member. First, I want to make sure we are not confusing parameters. ServicerStakeWeightCeiling is the parameter that can be set to accomplish 2, 3, 4x weighting etc. That is fixed by PUP-21 to 4x immediately without notiching up in increments. Foundation would have no hand in this parameter. ValidatorStakeWeightMultiplier is that parameter that foundation would adjust in response to consolidation. It is a decimal number and doesnāt notch up in whole-number incremets ie 2, 3, then 4. Per PUP-21 proposal, it will be set to the AVERAGE (not p90, p99 etc) of all staked, non-jailed nodes at the time the adjustment is made.
For example if there were four nodes in the system staked with 16k, 31k, 62k and 100k, respectively, then their expected multipliers would be 1, 2, 4 and 4. The average of this is 2.75. So ValidatorStakeWeightMultiplie would be set to 2.75
Which brings us to the question that needs to be answered by a representative from the foundation prior to being able to put this to a vote: If PUP-21 passes then is the foundation committed to adjusting ValidatorStakeWeightMultiplie at minimum according to the timeline in this proposal assertion 3 (eg, once a day for the first couple days, once a week for the first few weeks and perhaps spot checks and adjustment if necessary once a month for a few months). If not, then what will it commit to?
2 Likes
Hi All,
Without getting too much into recommendations, Iāve put together this model to help me wrap my mind around the options voters have for this particular proposal:
Please take a look. Please make a copy using File > Make a Copy. Play around with it and let us know what you learn.
Iāve had a few people take a pass at it and I believe this to be correct and without errors, but please let me know if you find any bugs.
Thanks. Will take a look and compare with the model Iāve been building.
Having a hard time tracing how ValidatorStakeWeightMultiplier is implementedā¦ changing this value seems to be having the opposite effect of what I expected.
Remember that validator weight selection is quantized.
Please do 75k max to get maximum benefit of node consolidation
1 Like
75k is off the table for now. Anything beyond 60k would be a future proposal. Even at 60k, that sticks only if we can adequately work through the various QoS issues that have been raised. Stay tuned in the coming days for updates,
1 Like
I have 3 nodes staked to 100K. Post-implementation, they will be earning both the 4x servicer bin + the validator rewards. Why do you think this results in a lack of incentive for validation? Post PUP-19, the premium for validation is plenty of incentive to jump up several servicer stakeās worth of POKT.
1 Like
Hi @jinx, Iām not sure what section or previous comment you are commenting on. It will almost always make sense to vie for a 1-ticket validator slot as long as it can be had for a reasonable premium (~50% or less over minimum needed to max out 4x stake-weighting). . With 4x weighting 5% proposer allocation may not be enough to spur much demand for multi-ticket validator status as the extra pocket needed to do so may be more profitably put to work in staking new nodes. Ditto If bidding for lower-end validator slot reaches too high. In your example, deploying 300k pokt in three nodes at average performance might expect to bring in on average 585 pokt per day (120 servicer + 75 validator per node). Deploying that same 300k as 5 nodes could be expected to bring in on average 600 pokt per day (120 per node). OF course service fees per node play a factor as well and may be enough to tip the scales in favor of the 3-node configuration. In this case, to spur greater demand for validator slots, it may be prudent to raise proposer allocation.
On the other hand, if cap is 30k rather than 60k, the economics favors stacking pokt to highly-staked multi-ticket validators over spreading pokt over lots of 30k nodes.
A cap at 45k sits in between and is more-or-less a wash
1 Like
Sorry if it wasnāt clear, I was referring to the 100K examples re: incentive, since thatās the setup I have.
While my data is fairly thin right now, there does seem to be a noticeable benefit to multiple tickets in the validation pool, and with a 4x base servicer reward, the leap from 60K to 100K feels like less of a risk than my initial leap of 15K to 25K. The risk analysis isnāt quite the same with servicers; that pool keeps growing, and trafficās regionality means there can be quite a high variance for relay locations, while the validator pool is fixed, and not subject to the same QoS considerations to produce a block.
When the validator rewards were 1%, the overage on winning the bet wasnāt enough to really justify it, but with an average validator block now earning between 800-1000 pokt depending on relays served by the block, I am very much incentivized to track ticket cost, and adjust upwards. My 100K staked nodes are significantly outperforming my single servicers before the 4x service rewards multiplier even kicks in (average 500pokt per day over the last 7 days, although this is the data that is thin, since theyāve only been in this configuration for a week).
Pure averages may not accurately reflect the emotional incentives around gambling on the big block action, and 1x validators arenāt going to have the same pop as 3x-4x validators.
when you started, 100k got you 4 tickets. It is now down to 3 and within a couple more days will be down to 2, even without PIP-22/PUP-21 turning on. If PUP-21 turns on at 4x, that will drop to 1 ticket for sure. I expect that post consoidation, new valiator average will sit around 80k, which means it will take 160k to get two tickets, 240 to get 3 tickets, etc.
1 Like
Sure, but your expectation as outlined in your previous comment is for the vast majority of nodes competing for validation to tap out at ~50% above the max stake. In the current validator pool, nearly half the validators are double or more that threshold, a third are quadruple or more, and 12% are 8x that or better, with 16 over 100K and max validator stake over 300K.
Thereās a demonstrated willingness to go far above and beyond the base servicer awards in competing for multi ticket validation which has increased with the validation rewards increasing to 5%. If the current ratios held true, with a 60K max stake we could expect nearly half of validators to shoot for the 160K range, and perhaps a third to shoot for the three ticket range.
Admittedly, the light clientās impact on price is likely to shift this formula more in favor of horizontal servicer nodes, depending on performance at scale. But thatās also why I think having a higher (4x) max stake for servicing is so important; the light client is going to encourage node count bloat once again.
This should be shelved for now, in my opinion. We should wait for the light client, turn down inflation to 20% or less to control node count bloat, and see how things shake out between that and PUP-19 for a few months. At 200 million yearly inflation the most the node count can go up is 13k, which is not the end of the world. And according to the schedule released by the dev team, V1 is not that far off, and weighted stake can be revisited at that time.
I request that we move this to a vote ASAP, please. A significant number of network moves are reliant on the outcome.
1 Like
I understand the sentiment and appreciate that a significant number of network moves are reliant on the outcome. However, it is simply not ready to move to vote yet as it is awaiting adequately addressing some concerns that have been raised regarding chains with only a small number of nodes. That work is going on in the background, and as soon as it is done there will be an update to the proposal followed by the ability to move it to a vote. I am hopeful the timeline for that will be within the next several days. It should certainly be in time for being ready to turn on as soon as PIP-22 is ready for production release
I believe the community sentiment in passing PIP-22 was implicit approval to utilize the knobs to offer some consolidation ability. To that end I view PUP-21 as a measure of more where to set the knobs rather than revisiting whether to use the knobs at all. We cannot wait for light client to āsaveā pocket. While light client may have some benefit to pocket, it comes at a huge cost, namely loss of control. Controllable mechanisms that duplicate some of the benefits that LC provides is part of the answer to keep LC from becoming a tool in the wrong hands to harm the system. To that end I strongly urge you to continue the work to get PIP-23 ready to put to a vote and passed
1 Like
Iād have to disagree with that based on some of the comments in that thread. I think PIP-22 was green light to develop the feature in case it was needed, with no implicit approval to turn any knobs. At least not right now.
I have finished edits on this proposal, adding clarification for how the Foundation will set the ValidatorStakeWeight Multiplier and adding a Dissenting Opinion section.
The proposal is ready to move to a vote.
1 Like
Hello from the Poktscan team! The implementation of PIP-22 triggered our data science team to run Monte Carlo simulations on the Pocket network with the intent to use the results for advising our customers on compounding options.
Key findings point out two issues not documented in PUP-21 or PIP-22:
- Increasing the ValidatorStakeWeightMultiplier parameter will trigger a reduction in rewards for those maintaining 15K validators, even if they are good performers. If the intention of these proposals is to discourage 15K node runners, it should be documented as such.
- Compounding node runners with poor performance will be rewarded equally as those with good performance. We understand that once the network reaches an equilibrium we will reach a status quo, those that perform well and those that do not. Understanding that the impact of node consolidation is positive, there is also an opportunity to encourage node performers to get better.
We are publishing our findings, the simulated data, and ways to test the PIP-22 parameters on the simulated scenario. We welcome any comments and challenges to the simulation and approach.
The public report and the code can be found here:
2 Likes