PUP-25: Non-Linear Stake Weighting For PIP-22

Attributes

  • Author(s): @RawthiL

  • Parameter: [ServiserStakeFloorMultiplier, ServiserStakeWeightMultiplier, ServicerStakeWeightCeiling, ServiserStakeFloorMultiplierExponent]

  • Current Value: [15000000000, variable according to PUP-21, 60000000000, 1]

  • New Value: [15000000000, variable, 60000000000, variable (strictly lower than 1)]

Summary

This proposal intends to modify the current linear stake weight model of PIP-22 and enable a non-linear stake weight model. The mechanism for such change is already included in the PIP-22, therefore this proposal is only a parameter update proposal.

This modification is required to:

  • Address a fairness issue that reduces the rewards of base stake nodes.

  • Enable a stake compounding strategy that is beneficial for the quality of service of the network.

Abstract

We propose the following chnges:

  • Set the ServicerStakeFloorMultiplierExponent to a value lower than 1.0. We propose to change this parameter to a value of 0.7 (under current network conditions).

  • Set the ServiserStakeWeightMultiplier to new value wich is lower than the value obtained from PUP-21. The decrease in this value will be compensated by the decrease of the ServicerStakeFloorMultiplierExponent.

The need for these changes roots in the limitations of the linear model to keep inflation constant without reducing the gain of nodes with base stake (those who decided to not perform any compounding). This forces nodes to perform compounding of stake and this was not the spirit of the PIP-22, we want to correct this effect.

We have analyzed the main mechanisms of the PIP-22 and the effects of the linear stake weight modeling. Our main conclusions are:

  • The linear weighting model penalizes the nodes that do not perform compounding. We estimate that non-compounded nodes are loosing at least ~15% of their rewards.

  • With the linear staking model the only valid strategy is to compound at maximum stake. This creates a de-facto increase of the minimum viable stake.

  • Observing only the variations of the number of sessions by node does not gives enough information on how the number of relays is modified. Hence, the reduction of the rewards for the base stake nodes is not correctly justified in the linear stake weighting model.

  • If the performance of the nodes in each compounding bin is not similar, the calculation of the ServicerStakeFloorMultiplier does not result in constant inflation. Correcting this problem leads to further penalization of nodes in the base stake.

Motivation

By implementing a non-linear stake weighting model we expect to:

  • Repair a fairness issue where the base staked nodes are being pushed out of the system due to an unjustified reduction of their income.

  • Avoid reducing the minting of base stake nodes (and other intermidiate bins as well) due to inhomogeneities in the performance of the nodes at different stake levels.

  • Create a new stake weighting strategy where going for the highest bin is not allways the answer. This new strategy can result in higher QoS nodes compounding less than low QoS nodes, improving the overall network QoS.

Rationale

The justification of the shorcommings of the linear stake weighting model and the justification of the non-linear stake weighting model is long and technical. In order to keep this proposal legible we have created a document to justify the proposed values. Please reffer to the PUP-25_Proposal_Document in this repository.

We leave an index to point the justification of some points:

  • Reduction of base nodes rewards: Section 4.2

  • Observing the number of sessions by node is not sufficient to estimate the increase of relays by node (using a linear model): Section 4.3

  • Problems of linear stake due to inhomogeneities in the performance of the nodes at different stake levels: Section 4.4

  • Changes in staking strategy that can lead to better network QoS: Section 5.3

  • Guidance for setting the new parameters: Section 5

We also created an infographic to understand the core issue that this proposal seeks to solve. Thi infographic shows the problem of PUP-21 to keep rewards constant for all nodes when the QoS affects the capitalization of the increment of the number of expected sessions by node. We show that a small change in the capitalization can lead to big changes in the node gains.

Dissenting Opinions

The “unfairness” problem thats been risen here is only a second order problem.

We dont believe that this is a second order problem since the observed effects are clearly larger than a 5% variation.

The PIP-22 should be transparent to node runners that do not wish to compound. We propose isolate the effects of compounding stake in servicer nodes from the nodes that do not wish to take part in the compounding game. This is the same that happens with Validators, the validatores staking volumes do not affect the rewards of the servicer node runners, it only affects the rewards (selecting probability) of other validators.

The network is currently over provisioned, if the 15 nodes dissapear it will be good for the network. This is a non-issue.

Increasing the StakeMinimum of nodes (or removing base stake nodes from the network) was never part of the PIP-22. In fact, PIP-22 was an alternative to increasing the StakeMinimum. Now PIP-22 is resulting to be an obfuscated way of increasing the minimum stake, not through a hard parameter set, but throug rendering nodes at the StakeMinimum unprofitable.

If the community wishes to reduce the number of nodes or improve network security throug higher stakes, then rising the StakeMinimum shoud be discussed. Anyway, this discussion should be done outside the scope of the PIP-22.

The model is fair, for each 15 kPOKT invested the expected return (before costs) is the same.

We agree, the unfairness problem is not related to the current return per POKT. The problem comes from an unjustified reduction of the base node rewards due to an overcompensation for the increment of expected nodes by session. In other words, PIP-21 expects an increase in the worked relays that matches the increase in the expected number of sessions.

Analyst(s)

Ramiro RodrĂ­guez Colmeiro and several members of the POKTscan team.

Copyright

Copyright and related rights waived via CC0.

Curious why you think this was not the spirit of PIP-22, as it explicitly stated that it was intended to incentivize compounding.

2 Likes

You said it yourself, incetivize, not forcing.

We dont believe that this is a second order problem since the observed effects are clearly larger than a 5% variation

Have you aggregated the reward results within individual sessions? Because fundamentally that’s where any unfair advantages would be seen, not as a historic trend.When not accounting for that session by session variance, I struggle to see how it can be assumed how over time that rewards should gravitate to a clean 25%/75% split unless the nodes were in the same sessions historically.

1 Like

Just skimmed this as I’m out currently. But in your analysis is this on past data. Did you factor out all nodes which are currently offline and not responding? As there are currently ~1.7k on the network thw majority of which are in the first bin.

If you haven’t then this will most likely be the 15% difference you mentioned.

Hi @blockjoe , Maybe I do not understand correctly your question, but we are not saying that there is a problem with how rewards are being handed out.
Our concern gravitates on the assumption of a linear relationship between the expected number of sessions served by a node and the expected number of relays served by a node.

Specifically, I have an issue with the assumption you make in your writeup that:

$$
\bar{R_{c}} \approx L \bar{S_{c}}
$$

there’s an entire demand driven market variable that determines the relays per session. There’s no reason to assume that the Relays per Session function in this kind of model, are going to maintain this linear relationship you have mapped out over time.

1 Like

Hi @Andy-Liquify , Yes, the information gathered is only on active nodes. The number of nodes used for calculations is actually the number of “active” nodes. This means that if a node runner had a problem on day X and then Y nodes did not worked, then we did not count them for that day.

I’d encourage you to take a look at this breakdown of a model that can be used to describe expected rewards behavior, because there is not reason why expected rewards should have a linear relationship to expected session.

1 Like

That is true, but thats why we made our analysis over the most stable network (Polygon, currently). Also we did not analyzed directly the number of relays, but the portion of the total relays each day (worked relays by node divided by total relays in the network).

Finally, that assumption is not ours, is the one behind the PIP-22 linear stake weighting. Our document proves that it is not like that.

The assumption of PIP-22 is that the opportunity should not be impacted, but PIP-22 has no ability to control the other Random Variables that impact total rewards. A quick overview of what actually is going to influence rewards is here:

and important to note, that the relay rewards are directly dependent on the individual session that an application has been paired with, for each unique session.

All of those variables and functions are defined explicitly in the document. If there was a PIP-22 assumption that rewards are linearly proportional to number of sessions, that’s an incorrect assumption, however they are related.

And even still, this is an oversimplification, since it can’t be truly assumed that the number of relays coming for a chain ID are going to be evenly distributed throughout the sessions.

3 Likes

I think we agree here. We are trying to prove this. I dont know how what you are saying collides with our document,

The document you shared is quite accurate, however it makes tha ssumption that the cherry picker already knows the nodes response time. The probability of being distributed relays in that session is not fixed, it evolves during a given session. The effect of this meassuring period is strong if the number of relays to serve is small.

We decided to use only hard historical data in our analysis because when we used a simulation we received negative feedback saying that it “was just a simulation”. We included all the sources of randomness that you talk about in our previous analysis.

I think what I might be looking for, is instead of breaking down Polygon by the day, break it down by the proportion by session. Overall, I think the basis of your analysis is sound, I just think you have to narrow in the bins to get rid of some of the other variance to really hone in if this variation is due to PIP-22.

Narrowing it down by session might not be the most straightforward, but I’d be happy to help tag team that effort.

1 Like

Does this proposal include compensation for everyone who gave up 75% of their rewards for 21 days in order to comply with the original goal of PIP 22?
Does this proposal include compensation for everyone who will need to loose 100% of rewards for 21 days in order to restake back at 15k in order to get equal treatment under the new exponent?

PIP 22 is not broken.
It does not favor the 60k bucket over others.
It works exactly as it was intended.

3 Likes

If PIP-24 (Transfer Stake) is approved this will not be an issue. We hope that it will be approved.

I never said that PIP-22 is the problem, PUP-21 is the problem.

We do not agree. We look forward to see evidence that supports these statements.

1 Like

The code is the evidence.

4 Likes

I’m out all this week. I’ll take a look more on Monday. I did a quick scan of the PUP and couldn’t find the actual value you are proposing to set the exponent to (which may be due to my trying to read this on a small cellphone screen). Im not exactly sure what to do with a parameter update proposal that doesnt propose a new value. Perhaps put a stake in the ground even if you havent settled yet on the final number and then new vs current can be evaluated. Later, the proposed new value can be modified based on the ensuing discussion?

Just a couple notes until i can look closer next week. One, re fairness, last week i posted on TG 48 hr data for 4 dif domains that showed that within their own span of 15, 30, 45 and 60k nodes there is no bias of relays roward or away from ine bin vs another. I know that doesnt quite hit the concern you raise, but i do think it is materially important to the discussion.

Second, movement to 4x consolidation over the summer was dominated by major token holders using the occasion of unstaking to move from underperforming providers directly to 60k nodes on better-performing providers. Any analysis of shifts of pie slice between june and now must take this into account.

1 Like

I personally don’t think the exponent should be used to counter inflation because better QoS nodes are in the top bin. The use of the exponent was to disincentive/incentives consolidation (if it is below 1 or above 1 respectively). Setting this to counter inflation is counter intuitive and is a never ending battle as nodes will continue to shift. IMO exponent should only be use to reduce/increase on chain node count.

If higher QoS nodes are in the top bin then this will be picked up in wagmi/fren by looking at the trailing average.

A like for like node (same QoS) will earn the same pokt for pokt stake regardless of the bin. I struggle to see where the 15% you claim comes from other than QoS differences between bins.

3 Likes

Exactly this. No one is “forced” to consolidate. The are incentivized to consolidate to be in a higher bin for the same hardware cost. The use of the exponent as outlined in the proposal was specifically for targeting key node counts on the network to support growth, not to offset the very incentive this proposal created.

1 Like

Hi Mark,

Well this is strange, as I copied the PUP-21 format, that you authored:

New Value: [15000000000, variable see below, 60000000000, 1]

PUP-21 did not defined a fixed value, it proposed a way to set the values (that was not clearly shown). We are proposing an algorithm to set the values in section 5 of our document.

The fairness issue is not due to relay bias accross different bins. The problem is the multiplier value of the first bin. The root of the problem is probably QoS related, but we have no conclussive proof of this, so we are not claming anything in that regard.

It is not important why or how the nodes performed compounding. The linear model is not accurate when it tries to compensate the increase in the number of relays by means of the increase of the number of sessions.