PIP-22: Stake-weighted Servicer Rewards

Hi @iaa12 your implementation looks correct but understanding is out here. Like I mentioned above weighting it from the top down using the above variables values will make it deflationary unless you have 75k staked to a node (weight = 1, therefore it is the same as before). The reason the numbers are different for B before and after is that you have gone from 9/16 relays (56.5% of all relays to B) to just 2/5 (40% of all relays to B) relay for relay in you example B will be the same before and after.

ValidatorStakeWeightMultiplier can be adjusted to even out these numbers. In your example setting it to 3.2 and having servicerStakeWeightCeiling of 75k will result in the same numbers before and after.

5 was selected to ensure it was deflationary from the beginning. Once we get an understanding of how nodes are weighted in the field it can be adjusted by a PUP

1 Like

Great, thank you for reviewing that, I figured I was missing something. A few follow-up questions then. How was this 3.2 determined, do we have a formula for this calculation? Am I correct in understanding that this value will be dependent on the state/configuration of the network at a point in time, and may drift in time as the network changes(nodes consolidate, stake, unstake etc.)? Will a monitoring and adjustment mechanism be implemented in order to maintain rewards over time?

So this comes from the average bin, in your case it is as follows

A(45K) B(75K) B (60K) C(15K) D(45K)

A = 3
B1 = 5
B2 = 4
C = 1
D = 3

Average = (16/5) = 3.2

You could automate this but it will add sufficient bloating as you have to keep track of the bin values for all nodes and update the average at each stake/edit of a validator. Hence why I suggested having the weighted controlled by DAO Params (reduces alot of the complexity) that can be adjusted based on the distribution.

Can you indicate whether this would impact rewards for those node runners who’ve spent considerable effort and cost to build optimised high speed nodes please.

For example, would a node runner staking 30k on one node that has very high latency recieve 2 tmes the reward of a node staking 15k that has very low latency?

i.e. are we throwing the concept of rewarding performant nodes out of the window in favour of well capitalised nodes?

Session selection would be unchanged, meaning nodes will enter the same amount of sessions as they did before regardless of stake size (actually it would be more since there’d be fewer nodes after consolidation happens).

Once nodes are in sessions, they’d still be selected proportionally based on latency per the cherrypicker algorithm, which is again independent of stake size.

What this change does is apply a multiple to the rewards that the nodes are earning. Performant nodes with less stake would be earning proportionally less tokens per relay, however, they’d also be doing proportionally more relays since with whales consolidating nodes there’ll be less nodes to compete with for session selection.

3 Likes

Thanks for answering so quickly. It is clear then, that staked balance aside, the optimum strategy would be increase the latency of my nodes if this means I can increase the number of chains I can connect to my pocket node.

I’ll get paid just as much, whether my latency is 1000ms or 10ms.

It appears that if this proposal is implemented:

  • Performance of the entire network is likely to degrade considerably and the pocket network will be known as a low speed service
  • Node runners who’ve invested in high powered, well optimised systems will have wasted that time and expense and would have been better to setup infra on the lowest spec possible

Your understanding is wrong here, like @JackALaing mentioned this proposal has no affect on the cherry picker or session selection!. So faster nodes will still be given more relays (nothing has changed there) just the reward for each relay scales depended on amount staked.

1 Like

I’ve little interest in counting how many relays my nodes are doing if I’m not being paid for it.

I’d be overjoyed to be told that my understanding is wrong, and my nodes will continue to be rewarded - but it appears that the only nodes being rewarded are those with the highest amount of staked pokt.

I’d suggest that additional thought is applied to ensure we continue to incentivise a high speed performant, decentralised network as considerable reputational risk is at stake if we pivot to a network that simply rewards well capitalised node runners.

I am not against stake weighting as a principle, as long as it is balanced with the need to incentivise performant and decentralised nodes.

A solution could be to measure the amount of relays supplied, and use this in the rewards mechanism so that 50% of the reward distribution is based on performance, and 50% is based on stake weighting. To move forward with a shift from the as is (100% based on performance and 0% consideration of staked balance) to a complete opposite of 0% consideration of work done and 100% consideration of stake is innapropriate and a knee jerk reaction in the extreme.

You will still get paid for them, not sure what is making you think otherwise.

Your understanding is still out here like I mentioned faster nodes will still be prioritized by the cherry picker nothing has changed there. A node which is faster will still get more relays the only thing different is that a weight is applied based on stake which will vary the reward for each relay served.

Thank you, I’d focussed on the detail of how to calculate the weighting based on stake, and completely missed the proposed algo

reward = NUM_RELAYS * RelaysToTokensMultiplier * ((FLOOR/ValidatorStakeFloorMultiplier)/( ValidatorStakeWeightMultiplier*ValidatorStakeFloorMultiplier))

Thank you for patiently explaining this. I was concerned that whilst the session would still be run by the fastest nodes that are pseudo selected, the rewards would in turn be completely agnostic of the relays performed and be based purely on the stake. But I can see they are not completely agnostic of that and continue to consider this in the rewards (albeit alongside stake).

I withdraw my concerns and support this proposal.

1 Like

First. I’m sure the implantation will be fine, but just pointing out that the math in the actual (updated) description is off in that it has a square of ValidatorStakeFloorMultiplier in the denominator whereas it should be inverse linear with that term: should be reward = NUM_RELAYS * RelaysToTokensMultiplier * ((FLOOR/ValidatorStakeFloorMultiplier)/( ValidatorStakeWeightMultiplier))

Second, I see the suggestion of DOA controlled parameter: ServicerStakeWeightCeiling but this value can be derived from other parameters and thus does not need to be separately controlled (or named), or am I missing something?

Third, just pointing out the obvious that this proposal in its modified form is almost indistinguishable, in terms of network and tokenomic effects, to simply raising the min staked to 75k. The vast, vast majority of node runners will consolidate to 75k nodes. The only added benefit to this proposal vs 75k min nodes is to “allow” for smaller players to run a node with les than 75k POKT while stripping almost all incentive to do so. Is that what people are wanting to vote to do???

[remainder deleted]…

3 Likes

I’m trying to work out the math before I say more. Bottom line: even though weighted rewards is a whole lot easier to implement than weighted validation, it is temporary and inadequate substitute and creates very unintended consequences. If you make it 1 at the top and 1/5 at the bottom then
- if most consolidate to 75k you get great operation OH benefits for those who consolidate but the ones who cant consolidate get priced out completely and thus you basically price out the smaller players and loose the diversity and decentralization that makes this project great.
-but if people hesitate to consolidate, the hesitation will be self-reinforcing since those in the minority who do consolidate get totally screwed as they will see their rewards per 15k POKT staked slashed by 80% (one node instead of 5 getting rewards while relays per node did not go up since other’s did not consolidate). Thus a node-runner’s fate’s tied to the percentage of people who consolidate. Seeing that the equation is linear, there will be no stable equilibrium point and thus the results of implementing this proposal are totally unpredictable.

Note that none of this plagues the harder-to-implement weighted servicing probability as in that model, a node-runners probability of servicing a relay is not at the mercy of whether other’s consolidated or not.

In the current form this proposal will not be good for POKT; if it must go to a vote, I recommend NO . However, I would prefer putting off the vote for a bit to see if a tweak in the payout scheme can be achieved that (1) is stable and whose outcome can be predicted and (2) maintains benefits for both those who can consolidate and those who cannot. Because of it’s simplicity it does hold potential as a good short term solution if the right nonlinear reward equation can be found. I will spend the next 24 to 48 hours to see if I can come up with anything

2 Likes

@msa6867 hopefully I can address some of your concerns below

It is two different things ValidatorStakeWeightMultiplier and ValidatorStakeFloorMultiplier

This can be derived if coupled to the other two parameters and if the max bin is 1 but having this configurable give greater control and allows you to increase the number of bins down the line if needed.

With the suggested parameters yes. I talked about this before but you have hit the nail on the head here, if the vast majority of runners consolidate to 75k this in turn lowers the number of nodes up to 5x thus increasing the number of relays served by each node. So should average out the tiers. I suggested a multiplier of 5 because it is the worse case (always be deflationary from where we are now). The plan as I see it is too observe how runners consolidate nodes post this proposal and then this can be adjusted to the average point, at the minute this is an unknown hence why I suggested 5.

To keep the same spread as where we are now you need ValidatorStakeWeightMultiplier to be the average bin position.

feeding back to what I mentioned above the more consolidation the more you feed each node with relays.

Maybe 5 multiple is a bad starting point but this is all subject to change anyway (just like I mentioned 5 is the worst case to insure no inflation)

It is in their best interest too so I do not see this happening. And if this is the case the weight will be adjusted to counter it anyway.

1 Like

Thanks @Andy-Liquify , this seems to be a very elegant solution! If I’m understanding correctly, node runners will be incentivised to consolidate stake up to 75k (configurable via vote) to lower operating cost. Minimum stake is not changing, so smaller node runners are not negatively affected other than being at an operating cost disadvantage due to being rewarded a lower reward rate. I think everyone understands there are economies of scale, and I think the benefits far, far outweigh any disadvantages.

1 Like

As a follow up to potentially address the cost disadvantage smaller node runners could face, the ValidatorStakeWeightMultiplier value could be set at a value lower than 5. It could be set between 4 and 4.6 as an example. This would make rewards not scale linearly with stake amount and account in some fashion for the fact that nodes consolidated to less than ServicerStakeWeightCeiling are at a cost disadvantage by making rewards not scale linearly with stake amount. It would level the playing field somewhat.

Market conditions vary a lot, so selecting the ValidatorStakeWeightMultiplier value could be more arbitrary than based on cost/profit ratios.

2 Likes

Thanks @ Andy-Liquify for your responses. I spent the night working out the math. Bottom line: linear weighting drives the whole system to the cap which may be a great short-term Band-Aid, but what about when price improves and we have a need to add nodes fast to handle growing relay count? The disincentive to small-staked nodes persists under all price and growth scenarios and is not sensitive to parameter setting. A simple fix would be to go to nonlinear weighting, For example weighting according to sqrt of FLOOR rather than linear with FLOOR is a very simple and elegant tweak that solves most of the issues. (1) weighting by sqrt of FLOOR (or perhaps a variable exponent less than 1) is naturally deflationary and (2) most importantly creates a natural balance between small and large staked nodes that skews toward large-staked nodes during challenging times like we are in where fewer nodes are needed and deftly shifts to favor smaller-staked nodes in economic environments in which node expansion is needed. Is it better to show the math here (i.e., you are open to the suggestion of tweaking this PIP to incorporate a parameter allowing nonlinear weighting if the math proves it is needed) or is it better for me to open a new PIP advocating nonlinear-weighted staking?

4 Likes

Fascinating idea! Yes, do share the math here if you can. I’d like to look into modeling out the economic implications.

Also, feel free to reach out to me in Discord (shane#0809) if there is more you’d like to share that could help with modeling out the economics :+1:

1 Like

ok, I will post it here then. It will take me bout an hour to finish it up and then I will post

2 Likes

Here is the math I promised on why nonlinear weighting (exponent less than 1) works quite well while linear weighting does not

Current state of affairs:

Let R0 be node rewards under current implementation. For the sake of argument lets assume an average value that happens to be around 40 POKT in today’s environment

Let C be the average daily operating cost of a node priced in POKT; in today’s environment this is very close to R0; i.e., around 40 POKT. Since C is more or less a fixed fiat price, the main sensitivity of C is to the price of POKT. When POKT is $1 C is approx. 5; if POKT were to drop to 5 cents, C may be closer to 100

Let k be the number of nodes a node runner (pool/DAO/whale etc) runs. Let’s assume k large compared to 5 (so that he can consolidate to larger nodes if that were made possible) (i.e., k=100 would be someone with 1.5M POKT running 100 nodes)

Let P be the total payout to the node runner:
P = k*(R0 – C)
which clearly is untenable when C>=R0 as in today’s environment


State of affairs if PIP-22 gets passed as-is (stated in simplified terms):

R = R0 * A * B *min(n,m)
where A is a DOA-controlled parameter (currently suggested to be set to 1/5 or slightly larger),
B is an unknown network multiplier that depends on how effective PIP-22 is in reducing node count,
n is the quantized multiple of 15k POKT that an operator wishes to stake to a node,
and m is a DAO-controlled parameter (currently suggested to be set to 5)

total payout to node runner becomes:

P = k/n * (R-C) = k/n * (R0 * A * B * min (n,m) – C)

The continuation of the math will be easier to show if we take the cap out of the equation and just remember that the cap exists and apply it in the end. Thus, for n<=m:

P = k/n * (R0 * A * B * n – C)
= k * R0 * A * B - k * C/n

A node runner is motivated to maximize their payout and will adjust n accordingly. To find the max payout as a function of n, take the first derivative of P(n) and find where this crosses 0 (if at all)

dP/dn = k*C / (n^2) == 0 which implies n = infinity (but capped of course at m)

Or to show this visually instead of mathematically, this is payout as a function of n for challenging times like now where node reduction is needed compared to times where POKT is flying high and node growth is needed

(See graphic at the end)

Meaning that no matter the attempt by the DAO to tweak parameters, no matter the network effect caused by consolidation and no matter the economic environment or the need to add nodes, node runners will never be able to be incentive to run a node at anything less than the max POKT allowed. Great for times like now where node reductions is warranted – horrible in the long term when node growth is needed


Now compare this to what happens if we weight by the sqrt of n rather than linear with n (ignoring for the moment the possible setting of a cap).

R = R0 * A * B *sqrt(n)
where A,B and n have the same meaning as in the above discussion

P = k/n * (R – C)
= k/n * (R0 * A * B * sqrt(n) – C)
= k * R0 * A * B/sqrt(n) – k * C/n

Again, a node runner is motivated to maximize their payout and will adjust n accordingly. To find the max payout as a function of n, take the first derivative of P(n) and find where this crosses 0 (if at all)

dP/dn = k/(n^2) (C – R0ABsqrt(n)/2) ==0  n for max payout is at n = 4 (C/(R0A*B)^2

For given averages for R0, C and B, the DAO can now easily skew node-runner behavior toward running max-sized nodes, min-sized nodes or anything in between. 0.25 is a suggested initial value for A. This should cause most operators who can, to consolidate toward n=4 (60k POKT staked per node)

The system is self-correcting with respect to the network affects of consolidation (unknown variable B). At the start when few nodes are consolidated node runners are incentivized to consolidate. IF node runners consolidate too strongly (say they start staking 200k POKT per node) B shoots past target and the yield curve adjust to strongly incentivize destaking back down to about 60k POKT per node) and open back up more nodes

This also exhibits correct behavior with respect to economic conditions. Suppose POKT price drops to $0.05 to $0.1, (C>R0) then this incentivizes node runners to consolidate to even greater levels (max payout t around n=7 ~105k POKT staked per node). At a POKT price of $.4 (C<R0) sweet spot drops from n=4 to between 2 and 3). If POKT price jumps up to $2 (C<<R0) because relays are shooting through the roof, sweet spot drops to the n=1 to 2 range.)

Note this example only shows the effect of weighting by sqrt(n). It is better probably to weight by n^p where p is a DAO controlled parameter between 0 and 1 I have to model further, but I think p closer to 2/3 may give more desireable results (in terms of curve steepness etc) than p=1/2, but I will not know until I have a chance to model it.

6 Likes

Thank-you for the details! I think I’m following most of it.

Would you happen to have this in a spreadsheet format where folks like myself can poke around to fully understand it?

1 Like