PIP-22: Stake-weighted Servicer Rewards

Proposals Improvements
61

I have not joined the POKT discord room or TG group yet but need to… fairly new to POKT and got wind from discord poktpool that PIP-22 looked to be coming to a vote, so I made my way here to take a look.

Umm, mixing up parameters here I think?. Remember the discussions from earlier… with linear weighting (which I think we should go with on day 1 until we study the behavior of nonlinear weighting better), I am incentivized to consolidate to the maximum amount I can, limited only by my individual resources and MaxValidatorStakeFloorMultiplier; In this scenario ValidatorStakeWeightMultiplier, does not influence validator behavior. Whether set to 1 or 1.25 or 2 or 4 or 5, I am most profitable if I immediately consolidate to 5x or 8x or whatever max I am allowed. Setting it to 1 means the ones who can’t consolidate wont see a drop in rewards while those who can consolidate will see a boost of rewards. Setting it higher will proportionally dial down rewards for everyone - both big and small - to keep the transition period from being too inflationary.

Agreed. I’m not recommending it. Just saying it’s possible if somehow there was big concern over immediately setting max to a value like 5 or 8

Think for example of the debate going on in the ETH community on the same subject regarding the shift to POS. By tying probability of being selected as validator to the amount staked you risk concentrating validator decision making into the hands of too few big players which opens up a network to security issues related to the big validators colluding with each other to self-aggrandize at the expense of others. That is why I call it a fundamental philosophy/policy shift from pure-random selection.

1 Like
62

Luis and I have pushed edits to the proposal that integrate most of @msa6867 's feedback and acknowledge @addison 's dissenting opinions.

Given that we’ve incorporated the feedback pertinent to refining the details of the proposed mechanism (stake-weighted rewards) and would be unable to incorporate the feedback that advocates instead for an alternate mechanism (stake-weighted session selection), we feel comfortable that this proposal is ready to go to voting.

I plan to put this proposal up for voting tomorrow. Note that voting will last 7 days (unless a 50% majority approves before the time is up) and discussions about the details of the proposal can still continue.

5 Likes
63

Thanks @JackALaing . Assuming PIP-22 gets the votes to pass I would very much like to be able to see proposed code changes before commit , There’s been so many different parameters proposed, removed, re-added, repurposed etc, that I would love to just check for consistency between proposed implementation and intention. Along that line, just to help future developers, auditors, etc it is probably prudent to choose variable names in keeping with their final role in the code. Eg., ValidatorStakeFloorMultiplier ought rather be called ValidatorStakeFloorMinimum or ValidatorStakeFloorBinSize, and ValidatorStakeWeightMultiplier might more aptly be called ValidatorStakeWeightDivisor, etc

Re “Validate Edit Stake” I assume intention is to always run with VEDIT =FALSE and only set TRUE under true emergency? Even so, when set to TRUE there is still a disconnect between the pseudocode and the intention.
(1) in the current pseudocode no one would be able to add tokens to replenish following a burn events as long as VEDIT=TRUE . Is this the intention? If not it is easily fixed
(2) the line

in “Proof lifecycle validation” sort of implies that ServicerStakeWeightCeiling is chosen to be a whole multiple of ValidatorStakeFloorMultiplier; whereas the line

in “Validate Edit Stake”
implies that this same parameter is set to some sufficiently large value greater than a whole multiple of ValidatorStakeFloorMultiplier in order to accommodate the need for a prudent reserve. Again, this is easily fixed such as by changing the line in Validate Edit Stake to:

flooredStake = MIN(nodeStake, ServicerStakeWeightCeiling) - (MIN(nodeStake, ServicerStakeWeightCeiling) % ValidatorStakeFloorMultiplier).

Then again, is it really necessary to calculate FlooredStake twice (and that using two different methodologies)? Perhaps just pass the value obtained in “validate edit state” to “proof lifecycle validation”?

These are simply implementation-level details and have no bearing on the vote at hand - the jist of which I think is well understood.

1 Like
64

The math is spot on up to this point, excepting that it places ServicesStakeWeightCeiling as the divisor rather than “ValidatorStakeWeightMultiplier” which is the correct parameter to use in the equations. My whole point in the above parameter-setting discussions is to set this parater to 1 on day one and adjust it over the first month to be on par with what you call “AverageStakeFloor” in order to keep total minted from getting out of whack during the transition. As long as total minted is more-or-less kept even, then to first order the small validators who cannot consolidate to larger bin increments should not see a reduction in rewards due to others consolidating.

There is a very real second-order effect that my come into play and ought to be a concern for everyone, namely that as soon as staking at max levels shows high profitability, then not only will those who can consolidate do so, but all sorts of new max-staked nodes are likely to flood into the space again, putting the squeeze on the small player until they are completely sqeazed out, causing another round of overprovisioned network and eroded profits for all until the reduced profitability once again causes new node staking to slow down. This is just simple economics 101. Setting the exponent parameter significantly less than 1 (e.g., to 0.5) will take care of that by making sure it is not overly-profitable to run max-staked nodes

1 Like
65

I have not had a chance to look into light-client yet, but will do so. I have a feeling introducing light client my be even more important than PIP-22 in the long run. I’m not seeing incompatibility though, especially if we set the parameters right, adjusting ValidatorStakeWeightMultiplier to keep on par with AverageStakeFloor and dialing the exponent parameter to incentivize toward deploying a greater ratio of lite to regular clients or vice versa as the system needs

1 Like
66

All commits, PRs and releases are open-source.

The pseudocode in the proposal is intended as illustrative of the mechanism not a full spec; details such as variable names are liable to change.

We appreciate the feedback and will take it into account when building out the feature, if this proposal passes.

2 Likes
67

I appreciate all the work that has gone into figuring out PIP-22, but after having spent hours playing with the economics of this version of weighted stake, I will be voting no.

To have a successful economic model, you have to be able to keep a balance while addressing:

  • Number of nodes
  • Validation Security
  • Price changes
  • Inflation goals

The new parameters being introduced in PIP-22 are much too complex and sensitive to be effectively used to create a balanced economy. I’ve discussed the economics with others and so far I haven’t seen or heard of a working approach to mapping out how the economics would balance out. I feel the theory of PIP-22 is interesting, but I don’t see the real economics of it playing out in a balanced, predictable way.

I believe investing core-dev resources into PIP-22 would be an inefficient use of resources when we can easily increase the minimum stake to have the same impact outcome. Why invest time into a v0 feature that will have major economic issues, when we already have the params we need to address our needs?

Now that I’ve given PIP-22 a fair shake with seeing how the economics will play out, I will return my attention to PUP-17 and will be updating it will a more in-depth economic model.

1 Like
69

I’ve done the same pondering and now tend to agree. The complexity this will introduce into the economy will make it very hard to keep the results predictable and will require constant tweaking as the network evolves. Imagine having to explain all this to someone looking to enter the network. I also don’t like the idea of paying more per relay based on stake amount, yes the end result is the same but the optics are bad.

I have always disliked the idea of raising min stake just because it would cut off small node runners and raise the entry barrier should token price increase significantly in the future. But, looking at the macro environment, not sure how much of a concern that is at this point. And people were buying in at $45k per node in January. It’s also a lot easier to decrease min stake in the future should the need arise. I think a min stake increase - along with a strong financial incentive to go above and beyond for validators - would be cleaner and easier to understand and implement at this point. And folks that fall below can beef up their stake or join a pool where they can benefit from economies of scale.

70

In case you missed it in Discord, this proposal is up for voting Snapshot

71

I think people have lost sight or maybe gotten lost in @msa6867 amazing but complicated maths. There is no reason it can’t be a balanced system once the consolidation point is found (like I mentioned on today’s call), the parameters give the DOA control over consolidation rates and this balance point (the balance point can be set in a similar way to WAGMI is currently). Once we know how consolidation is applied in the field the weight can be moved to the average point and there will only be a small steady state around this point (since it will be a fairly “true” average given a sample size of over 10k plus nodes)

Also I spoke with Luis the other day I’m happy to take on the development, reducing input from core team. I have already written/planned most of the code changes.

1 Like
72

Undoubtedly there is complexity of modelling out the exact outcomes of this proposal with 100% of uncertainty removed.

However if that’s the barrier we’re setting for success then as far as I see it none of the proposals can pass. Be it GOODVIBES, PUP-19, PUP-17, doubling the minimum stake, the Phase Plan, SWANS, stake weighted session selection, you name it… None of them have economic outcomes that are 100% understood, with no ambiguity. You can tear holes in any of them.

What I’d say about this proposal though, is that it’s among the most simple, doesn’t completely screw any size of node-runner, and actually does include an adjustment mechanism built in (the RelaysToTokensMultiplier), so it’s not a complete 1 way ticket. You could implement the proposal, find it’s not working quite as planned and easily adjust it down the line. In fact if you use a completely linear reward model with no exponent, then set the relaytotokensmultiplier to 1 and the mechanism can actually be switched off completely if need be. Many of the other proposals do not have this failsafe.

Adjustment is also fairly simple for a linear model, and we already do perform regular adjustments for inflation control so I don’t see why this is a big concern here. You can just perform this relatively simple adjustment twice weekly to start and then eventually monthly, as we already do for WAGMI, and all is well.

It’s also true that all of the proposals are also built, to some extent or another, on questionable premises. The $100 per-node cost for example is pulled from thin air. Or the idea we need at least 200M pokt staked in validation or the network is at risk of attack. These are actually completely arbitrary numbers. Where is the model that says we need around 200M, not 300M or even 50M pokt staked in validation? Where is the properly conducted anonymised survey of the entire node-running community to determine what the cost to run a node ACTUALLY is, and how much profit it’s possible to actually make in today’s environment? How quantifiably necessary are ANY of these proposals?

It’s also worth nothing that we cannot even model how the economics of pocket will change into the future right now, even before we change anything! We cannot say for certain what will happen if the pokt price halves again, or triples, what will happen when the lite client gets released or how WAGMI will continue to effect the economics over time.

To reiterate: My overall point of this rant is that if we’re going to exclude this proposal because it’s possible to pick holes or point out complexities, then we can’t realistically pass anything IMHO.

5 Likes
73

I’ve had a little play around with @iaa12 fiddle to try and get my point across that with the weight scaling ( ValidatorStakeWeightMultiplier) to the average point the net inflation is no different from where we are now because people seem to be getting confused around this point.

Note: I am no JS developer (I’m an old school c/c++ engineer) so this was literally thrown together. I have added a new function calBalancePoint() this basically calculates the optimum bin position as:

image_2022-06-23_17-05-08
image_2022-06-23_17-05-08813×81 5.07 KB

Feel free to play around with the number of nodes in of the unconsolidated nodes section the outputs before and after will be more or less the same (baring some very small rounding/precision errors)

I have also increased the ceiling as an example because I didn’t have time to code this logic into the consolidation code.

1 Like
74

I’d like to raise the possibility of this proposal being unconstitutional.

4.25. As the actors responsible for transaction finalization in Pocket Core, Validator Nodes have the power to overthrow the government apparatus of Pocket Network (outlined as the above Legislature, Executive, and Judiciary functions). They are trusted to represent the citizenry (Users) of Pocket Network because their Block Reward is tied directly to the number of relays being processed for developers (i.e. User usage). The Council must never approve Protocol Upgrades that would decouple this incentive alignment.

I think a strong argument could be made that this proposal ties Block Rewards to stake amount much more directly than to the number of relays being processed. Validator earnings would depend primarily on how much a node has staked, not on relays, since a node staked at 75k would earn 5 times more than a node staked at 15k for the same relay. Thus skewing the representation validator nodes are entrusted with via Block Rewards.

As such, I believe the Council should not approve this proposal. Should the Council approve the proposal, the directors and supervisors of the Foundation should refuse to implement the Council’s decision per Statute 4.9:

4.9. The Directors and Supervisors of the Foundation can refuse the Council’s decisions subject to the limitations imposed on them by the law and their duty to steward Pocket Network.

Pocket Constitution

2 Likes
75

Interesting. I don’t believe constitutionality has been discussed. It didn’t even cross my mind though I worried about this same issue of incentivizing based on stake size rather than relays. We are trying to build something that has a lot of servicers in the end, so this seems pertinent. I am interested in the security if the network convo taking place but this may remind us of how we said we wanted to get to our goal of balance. Thanks for bringing to the conversation.

76

I generally speaking like this proposal overall, but I have to agree with @iaa12 , this directly ties Block Reward to amount staked, not to relays creating a misalignment of incentives according to the Constitution.

I can not stand by the proposal as such.

I want to thank @iaa12 for calling this out.

77

Thank you *iaa12 for bringing this up as a possibility. However, there is nothing at all in this proposal (or in PIP-23) that causes a decoupling of the incentive alignment between validator’s blockchain rewards and number of relays being processed for developers. Consider the following:

(1) The constitution never said that validators could not also wear a “servicers” hat and/or could not earn rewards for work they do while wearing a “servicer” hat in addition to the work they do as a validator. Personally I wish they had; I think it is better for the long-term health and security of the network to force a choice and not let a node wear two hats. Heck, I might even propose that as a PIP. But that is not our current constitution. Need I remind everyone that in the pre-March time frame that vast majority (upward of 80 to 90% ) of a validator-nodes total reward was as a result of earning servicer rewards not proposer rewards.

(2)In all scenarios - meaning current situation, post PIP-22 or post PIP-23 - no matter how much a validator node chooses to stake, his rewards both on the validator side and on the servicer side (and ergo in the aggregate )- are 100% directly proportional to the number of relays being processed for developers. If the total number of relays doubles, their reward doubles. That is what you call a complete and total keeping with both the wording and the spirit of the constitution.

An example of validator reward mechanism that would be found in violation of the constitution and what the foundation is trying to prevent is if we were to start rewarding validators based on number of POKT transactions (adding to POKT stake, removing POKT stake etc) as that could incentivize validators to create a lot of POKT transaction churn in order to self-aggrandize. Such a reward structure would be in violation of the phrase “being processed for developers.”

A second example of a reward mechanism that would be in violation of the constitution is to reward validators via a fixed monthly stipend, since in that case the validators would be perfectly happy if the relays dwindled to nothing as long as they collected their monthly check. Such a reward structure would be in violation of the phrase " tied directly to the number of relays."

1 Like
78

Firstly, I’d like to say thank you for being one of the first people to challenge a proposal on constitutional grounds. This is very exciting for me :slight_smile:

In this case, I believe that PIP-22 is not unconstitutional. Let me illustrate why.

Firstly, it’s important that we don’t conflate servicers and validators here. Decoupling servicer rewards from relays in isolation (assuming no second order impact on validator rewards) would not be unconstitutional according to 4.25, since servicers outside of the MaxValidators validator set do not participate in “transaction finalization” and therefore have no “power to overthrow the government". It is the validator set whose incentive alignment we care about here.

So what does PIP-22 do to validator rewards? Validators earn a ProposerAllocation % of the total block reward, which is a summation of the coins formula for every servicer in the block. PIP-22 adds a parameter-based modifier to the coins formula that multiplies Relays*RelaysToTokensMultiplier by a “weight” value < 1. The validator’s own stake size does not factor into the new weight value, only servicer stake size, therefore the validator’s own stake size does not influence the block reward in PIP-22.

Fun and illustrative fact: since the genesis of the network, the consensus rules have deemed that a validator’s stake size influences their individual block rewards by increasing their odds of being selected to propose a block. This founding principle of the consensus rules violates the letter of 4.25 according to your argument (I disagree, more below), however even if it does it is overruled by 1.1.

1.1. This Constitution does not take precedence over the consensus rules defined by Pocket Core. If there is any conflict or inconsistency between this Constitution and the consensus rules, the consensus rules shall prevail.

So what do we do if we feel that there is a contradiction in our constitution, composed of an off-chain social constitution (which you’re referencing) and an on-chain constitution (the consensus rules of Pocket Core)? Like any good constitutional test, let’s try looking at precedent: WAGMI. WAGMI targets a network-wide annual inflation by adjusting RelaysToTokensMultiplier to cancel out fluctuations in the relay count. In other words, even if relays grow, validator rewards don’t grow. Why is this not unconstitutional? Because regardless of the coefficients in the coins formula, income is still directly proportional to relays. If relays fall to zero, validator rewards fall to zero.

PIP-22’s new weight modifier is bounded at 1, which means it rations the block reward but cannot generate extra rewards per relay, so servicers cannot increase their stake to counteract a meaningful drop in relays. With this fact in mind, I believe it’s misleading to say that in PIP-22 “Validator earnings would depend primarily on how much a node has staked”.

With this illustration I believe we can extract the spirit of 4.25 – that validators should act in the best interests of the users of the network’s relays, ensuring decisions are made to further the app experience so that they don’t eliminate the source of the network’s income. 4.25 is all about keeping validator rewards proportional to total relay count; it is agnostic as to what the coefficient of proportionality should be or whether or not different validator nodes have different coefficients.

And where PIPs are concerned, it is the spirit of the constitution that matters…

1.2. This constitution shall be enforced according to de jure interpretations of the Statutes (the letter of the constitution), except in the case of amendments to the Constitution or Pocket Core’s consensus rules, in which case they shall be enforced according to de facto interpretations of the Principles (the spirit of the constitution).

…where the Principles attempt to enshrine the spirit. For the issue that PIP-22 seeks to resolve, the 2nd most important principle is relevant

  1. Sustainable Decentralization: Pocket Network should optimize for as many sovereign Nodes as possible, because this reinforces the resilience and censorship-resistance of the service, but this should not be rushed at the cost of the sustainable growth of Pocket Network.
7 Likes
79

If this proposal fails, we should re-post a variation of the proposal with the set parameters as suggested by @msa6867 :

  • Set ValidatorStakeWeightMultiplier to 1

From my understanding, the set parameter at 1 will not incentize any node consolidation or affect rewards distribution. BUT what it does do is effectively gives the Core Team/@andy the green light for development. Essentially, if the DAO ever needs to trigger this mechanism then we can, and we should at least support giving the engineers the “go” to finish the development work and let the DAO have that level of flexibility. Once finished (which can take at least a month from now), we will have more clarity and a lot of news can come into fruition in a month.

I suggest that the DAO does not change/vote on a new set of parameters for consolidating until development is fully completed and the network is upgraded with this consensus change. This will also give more time for this proposal to marinate in people’s mind (perhaps some more dissenting opinions/implications may show up for this proposal) & to observe the effects of the economy, other PUP’s and PIP’s, and LeanPOKT

Pros:

  • Hopium/Sentiment, the DAO passes a PIP with clear set parameters
  • Small steps at a time
  • Development on this occurs asap
  • Sets up the DAO with a mechanism to pull the the trigger immediately if necessary after observing the economy, other proposals, and LeanPOKT

TLDR: With the correct parameters, this changes nothing but provides the DAO with more flexibility

80

Setting the ValidatorStakeWeightMultiplier to 1 was to allow for future growth of the network if/when needed (per msa). I have posted several of his comments (which are apropos to this discussion). He had other suggestions which I think should be considered in context. Here is what he wrote (over several days and messages):

I hardly think that not recommending parameter settings is a valid reason to vote against PIP-22.

I know that adding ValidatorStakeFloorMultiplierExponent to PIP-22 (and perhaps more importantly the whole discussion of why it is beneficial to include) made PIP-22 feel “too complex” to some people . No worries. Just set it to 1.0 on day 1 so that it has no effect and worry about changing it in the future if and when it is needed. It was added because it is the only parameter that can incentivize to diversify to more nodes if that is needed for network stability and security in the future as the network grows.

My recommended Day-1 settings that would get written up and voted on in a PUP (ie turning on the incentive to consolidate) would be (15k, ==averagestakefloor , 75k, 1) . Very conservative. Allow 5x consolidation to start and defer any nonlinearity in the weighting until the future. Per discussion above, DAO would adjust the second parameter over the transition to keep up with average consolidation that takes place in response to the consolidation incentive being turned on.

To me it seems that the ones voting against PIP-22 have lost sight that by itself the proposal adds the parameters and the few lines of code that provide the knobs needed to enable varying degrees of weighed rewards while deferring to an accompanying PUP the actual setting of the parameters (i.e., whether or not to turn on the weighted staking and if so by how much). I urge remaining voters to vote to approve PIP-22 as it is rather a minimal dev effort and save the debate/objections on the right value for the parameters for the related PUP (to be posted immediately if and when PIP-22 passes)

Bottom line: passing PUP-14, PUP-19 and PIP-22 together and as is is gives two very distinct and decoupled system behaviors (one focused on validator count and the other focused on servicer count). Once this new state is absorbed, further action can be introduced to further incentivize bidding up POKT to achieve validator status.

81

Thanks @poktblade. If people voted against the proposal based on parameter values not being suggested, then we need to understand why that was a defining motive. I have seen some sentiment expressed that a reason to vote no was to not use up dev energy coding up and testing a feature that the community has no desire to ever use. In which case we might as well repost with suggested parameter values the accomplish a helpful yet conservative, easy to understand consolidation incentive - like 4x or 5x . The built-in state, RSCAL, that the dev team indicated they would build into the implementation is probably sufficient to achieve no change in system behavior until ready to migrate to the suggested incentive structure on a set date.

That being said, if you want to set the parameters to accomplish no change to system behavior it would be as follows:
ValidatorStakeWeightMultiplier = 1
-PLUS- at least one of the following:
[ServicerStakeWeightCeiling=15,000
-AND/OR -
ValidatorStakeFloorMultiplierExponent = 0]

3 Likes