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.
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:
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.
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.
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.
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.
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:
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.
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.
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.
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.
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."
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 
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
- 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.
If this proposal fails, we should re-post a variation of the proposal with the set parameters as suggested by @msa6867 :
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:
TLDR: With the correct parameters, this changes nothing but provides the DAO with more flexibility
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.
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]
I’m sure people voting against this proposal have given it ample thought, understand it thoroughly, and have more fundamental issues with this approach to stake-weighted rewards beyond parameter settings.
A lot of the concerns circle around the fact rewards will be dependent upon the entire network’s staking status, which will continuously change in time, which makes the whole thing unpredictable and complex. It’s a recursive loop of parameter changes, that stimulate changes to the network, that trigger more changes to parameters to keep rewards in line, which stimulate more changes to the network - it feels wrong.
To me though, what feels the most wrong about this approach, is the fact that node runners will be paid different amounts for the same work, based on their stake amount. In a true stake-weighted scenario where nodes are assigned to sessions proportional to their stake amount, a node staking 5 times more earns 5 times more, but also does 5 times the work. Fair. In the case of PIP-22, a node staking 15K does the exact same work as a node staking 75K, but earns 5 times less. It’s poor optics, unfair, and not the direction the network should go in.
I think with LeanPocket on the horizon it would be best to hang tight, increase validator block rewards to see what happens, maybe re-examine PUP-17, and wait it out until v1. LeanPocket will be a better surrogate stake-weighted solution than PIP-22.
Though this is a bit late, in addition to the JSFiddle @Andy-Liquify provided, I also wanted to share a simple colab I used to verify the updated proposal for those who prefer Python.
reposting from Telegram:
We’ve been evaluating weighted sessions vs rewards through the lens of nodes (the supply-side) but I’d encourage thinking about the implications for the apps (the demand-side). Currently the Portal’s cherrypicker relies on consistently having a pseudorandom set of 24 nodes to choose from - ensuring that even if some nodes are highly latent or out of sync, there are plenty of others to choose from, ensuring quality service for apps. Now imagine instead that a new set of whale servicers get selected for 80% of sessions, but they’re misconfigured, now the Portal is going to have a much harder time ensuring quality service because it has a much smaller pool of alternate servicers to choose from.
PIP-22 is superior on the basis of not disrupting quality assurance on the demand-side. Folks like msa6867 have acknowledged that PIP-22 is less set-and-forget from a governance perspective than PIP-23, when it comes to supply-side parameters, but PIP-22 leaves the demand-side untouched whereas PIP-23 will require Portal enhancements and most likely an increase in the SessionNodeCount to compensate for a reduction in diversity of available servicers.
Regardless of which way this proposal goes, the way in which this was thoroughly discussed, amended via community contributions, criticized for its flaws and praised for its merits, it’s a huge win for the Pocket community. It’s probably going to be close , but I think everyone can be satisfied that every facet of its pros and cons was thoroughly debated(I certainly threw the kitchen sink at it), every vote was cast in full knowledge, and everyone can feel good about moving forward and coalescing around the end result, whether they agree with it or not. There’s tremendous value in that.
This proposal has been approved with 27 yes votes and 6 no votes. Snapshot
The next steps are for the code to be shipped and bundled with the next release (RC-0.9.0) and, in parallel, for the DAO to agree to the initial parameter values, which @msa6867 and @Andy-Liquify have proposed here PUP-21 Setting parameter values for the PIP-22 new parameter set
