I don’t see an active topic for POKT’s coin economics discussion, the effects of the passed proposals to the POKT tokenomics, the final impact it had on POKT compared to the expected / wanted outcome. If there is no other place to discuss this topic publicly in one place, please leave this topic opened and feel free to add the comments, suggestions, arguments and counter-arguments below. I’ll add the first one.
2 Likes
Now that PIP-22 has passed, PUP-22 (FREN) as well (inflation was reduced to 26.8% as of right now) and LeanPOKT coming out even this month possibly, I’d like to discuss the current POKT coin economics.
According to poktscan.com as of right now (block 70514), there are:
- 22,294 15k POKT nodes
- 481 30k POKT nodes
- 663 45k POKT nodes
- 3,908 60k+ POKT nodes
Total node count: 27,346
So, the question is: Did the PIP-22 have satisfying effect? Was the outcome expected? Is the POKT node network (infrastructure) still overly expensive for the current demand (number of relays)?
In my opinion, the outcome proves that overly extensive economic research is kind of useless here, because theory is significantly different to reality. Not all variables are always taken into calculation, and ultimately, it’s close to impossible to predict the human psychology and put that factor as a variable into equation. All the proposals had the best intention of achieving outcome X, but ended up with outcome Y.
Let’s get straight to the point. Although I like LeanPOKT very much, I believe it will negatively effect the targeted / expected outcomes of PIP-22 and PIP-22 (FREN). It will result with even cheaper node running of 15k servicer nodes, instead of motivating people to consolidate nodes even further. In other words, it will give more space to those 15k service node runners that are indeed “hurting” the POKT by running at the highest possible cost and mostly dumping their rewards on the market to cover the monthly infra costs. That is how I see it.
There is still way too much nodes in the network for the current demand (relay count). Do we want to reduce the node count further? I would say yes. If so, I would suggest cutting down the inflation rate to like 10% in the short run to ensure that the lowest quality 15k servicer nodes become non-profitable and kind of force them to stop running their nodes or consolidate for the benefit of everyone.
That would be the first step. I see the inflation rate reduction as the most efficient way of reducing the node count immediately and cutting down the costs of the overly expensive network. In case that the relay count goes up significantly and there isn’t enough nodes in the short term (highly unlikely to happen), the inflation rate can be quickly increased even 2-3x and people would be motivated to setup new nodes. That’s my quick brain dump to heat up the much needed discussion I’d say. Comments and feedback are more than welcome. Thanks everyone and have a great day!
Hi @TheDoc , we are also unhappy about the outcomes of the PIP-22 and we are analizing the effects in terms of fairness and quality of service. However we are thinking in a different solution. As soon as we have some solid number we will share our results.
Anyway, I wanted to make some comments:
Let’s get straight to the point. Although I like LeanPOKT very much, I believe it will negatively effect the targeted / expected outcomes of PIP-22 and PIP-22 (FREN). It will result with even cheaper node running of 15k servicer nodes, instead of motivating people to consolidate nodes even further. In other words, it will give more space to those 15k service node runners that are indeed “hurting” the POKT by running at the highest possible cost and mostly dumping their rewards on the market to cover the monthly infra costs. That is how I see it.
PIP-22 has nothing to do with base stake (15k). If the base stake is the problem it should be discussed outside the scope of PIP-22, since the PIP-22 tries to encourage increasing the stake and a base stake modification forces it.
Also saying that 15K node runners “hurt” the network is not fair. A 15K node can be much much better than a 60k node in terms of Quality of Service (QoS). Stake amount does not relates to QoS. Which kind of network do we want? I think that a network with poor QoS and low node costs is not what Pocket Network wants to be.
Finally, I think that LeanPOKT will work fine with PIP-22, it will reduce the node costs without affecting QoS. PIP-22 only encourages further staking, no problem here. Also, if nodes with LeanPOKT are cheaper, how could they create more sell preasure than the current nodes?
There is still way too much nodes in the network for the current demand (relay count). Do we want to reduce the node count further? I would say yes. If so, I would suggest cutting down the inflation rate to like 10% in the short run to ensure that the lowest quality 15k servicer nodes become non-profitable and kind of force them to stop running their nodes or consolidate for the benefit of everyone.
Supose that we do this and all nodes go to 60k stake (we dont know how, some will unstake and consolidate others will just add more POKT). In that scenario the ServicerStakeWeightMultiplier will be 4 and the rewards multiplier with 60K stake will be 1.0. In this scenario the only effect of PIP-22 is increasing the base stake. Once again, if we want this we should discuse it outside the scope of PIP-22 and make it clear to the comunity.
Finally, low quality nodes will be naturally forced out only by reducing inflation and keep rewarding QoS and not stake.
Hi @RawthiL , thanks for joining the discussion.
I agree that POKT shouldn’t strive towards lowering the Quality of Service (QoS), especially not in the long run where it should be the most important factor. However, in the short term, while POKT still didn’t launch v1, while there isn’t any support on the demand side, infrastructure cost should be more important factor I’d say (sadly, I know, but compromise should be done somewhere until POKT mature a bit more). Because if you take a look at the wider picture, POKT is within top 5 worst performers price-wise in 2022. From ~3.11 USD down to ~0.06 USD within couple months is not far from LUNA crash situation let’s be honest.
I would suggest stronger incentive for running 60k nodes than it is right now compared to 15k nodes.
As I said above, I agree absolutely. I’m just trying to think about compromises in the short run, while POKT is not mature enough yet, while there isn’t monetization in place or simply until POKT isn’t truly decentralized (until v1 activation).
Because running 15k POKT nodes will become even cheaper, so people are less likely to consider consolidating multiple nodes toward 30-45-60k nodes. So, although it will become cheaper, infra cost of 4x 15k nodes is still unnecessarily 4x higher than single 60k node. The only difference is that each node won’t cost $250 per month, but $100 or so. IMO still way too much unnecessary sell pressure.
In a word, no.
I just staked 3 60K nodes. Per the discussion on PIP-22, including the table provided showing outcome, one would expect them to have a stake weight of 4:
Checking poktscan right now, they have a stake weight of 2.7, meaning that they are earning ~65%of what would be expected based on the proposals.
I noted in those threads that the formulas for deriving the expected values had become exceedingly complex, but I was trusting the language of the proposal in regard to the outcome. That seems to have been a mistake.
1 Like
I beleive that this is the general feeling of the community. We have received many questions regarding this topic in our discord (POKTscan). Indeed PIP-22 was not clear enough. We tried to explain that this could happen but we arrived too late to the discussion. The extreme cases and fairness issues were not correctly addressed (IMHO). Nevertheless the numbers that you are seeing are correct.
Sadly there is no easy explanation for why these numbers are like this. The problem resides in the infation contraint of PIP-22. The PIP-22 should not affect inflation and in order to do so a complex calculation of its parameters is requiered.
We are working on a new repport and we will try to shed some ligh over all this issues soon, but there will be a lot of math that cannot be spared, otherwise its all just words and no proofs…
2 Likes
I think I can clear up a misunderstanding here.
First, PoktScan has made certain ux decisions on how to group and report data that has contributed to confusion. Several have suggested an alternate method to report the data in their dashboard so as to not lend to this confusion, but that is an internal PoktScan design choice. In actuality, this aspect of PIP-22 is working just as indicated. If you have access to 15k, 30k, 45k and 60k nodes you can easily verify that the 30k, 45k and 60k nodes receive 2x, 3x and 4x the rewards per relay as the 15k node (the “base amount”). You can also verify that the base amount is equal to RTTM/SWWM*relays, just as stated in the proposal (after discounting of course for the servicers only getting 85% of the allocation).
Second, to first order the base rewards are the same now as they were in June after adjusting for WAGMI, FREN and PUP-19. (If anything rewards are running on average about 10% higher than June, and @Andy-Liquify , @KaydeauxPokt and I, in conjunction with data being provided by PoktScan, have been working to understand this effect).
The misunderstanding is the result of what I might call “overtime amnesia”. This is like the hourly worker who earns $5k per month and then is asked to start working overtime. which boosts his pay to $8k per month. At first he knows this is just a temporary boost, but as days become weeks become months he starts to forget that it is temporary and he begins to think of the $8k/mo as the new normal. On the day the overtime ends and his pay returns to normal, he gets up in arms over his $3k “paycut” from $8k to $5k.
This is exactly what happened over the summer. Throughout July and August, as nodes unstaked in order to consolidate, the remaining nodes received an overtime pay boost (as their average sessions per day increased due to fewer competing nodes). But after 2 months time, they forgot that the pay boost was only temporary and that the gravy boat would be turned off the moment PIP-22 was put into effect and returned base pay to pre-consolidation levels. Forgetting what normal was in June before consolidation, and presuming the overtime pay was the new “normal” they get up in arms over the 35% “paycut” when in fact it is just a turning off of the 35% “overtime pay boost” they enjoyed over the summer.
Stating the same thing as above in math terms that I really don’t think is too complicated:
Base rewards before PIP-22: base relays * RTTM
Overtime rewards during July/August: boosted relays * RTTM
Base rewards after PIP-22: boosted relays * RTTM / SWWM
where consolidation boosted relays is running , on average, about35 to 45% higher than June base levels, and where SSWM is designed to approximately cancel out this boost.
All of the above was spelled out in the June time frame. Nor was communication lacking later on. In the days leading up to PUP-21 I tried to remind the community that the overtime pay boost they enjoyed over the summer was about to be turned off. I did this in the Den in word form
By posting the spreadsheet image
and by posting a tl’dr mockup.
I’m rather at a loss of how else I could have communicated so as to avoid node runner surprises at PUP-21 turn on. Please let me know if this clears up the misunderstanding or if there is something that remains.
Note that I am only addressing here the big picture sentiment floating around of “I’m only receiving 65% of what I expected”. I am not addressing the more nuanced concerns that @RawthiL has raised both in July and now. That will require more detailed examination, will require more data, and will be discussion, I expect, involving variations of no more than about 5 to 10% around system averages.
2 Likes
Thank you @TheDoc . What an excellent discussion thread!
Shortly before the onset of PIP-22 voting, the network had about 44k staked nodes. Within a day of it becoming clear that PIP-22 would pass, between 5k and 7k nodes unstaked leaving 37k staked nodes. Then @JackALaing issued guidance to node runners to not unstake all at once but to measure out unstaking over two months. Unstaking continued in an orderly fashion between July and August to the 27k staked nodes we have today with evidence that some consolidation will continue to take place throughout the next month. Therefore even in the presence of LeanPOKT as an additional source of cost-savings for the network, 17k excess nodes have been shed from the network conservatively saving saving over $1.7M per month in infra costs assuming $100 per node per month. This is satisfying. This is the big picture.
Would it have been more satisfying to see another 10k of excess nodes shed from the network bringing staked nodes to 17k rather than 27k… and been able to “claim” $2.7M+ in cost savings per month instead of $1.7M+? Of course! Without LeanPocket I think we would have gotten there. In any case, 17-20k was my internal target. (4x consolidation down to 11k nodes could not have served as a realistic target since accommodation must be made for all the small node runners who don’t have enough tokens to participate in either PIP-22 consolidation or in LeanPocket).
Does that mean that LeanPocket “robbed” the system of an extra $1M in cost savings that PIP-22 might have otherwise produced? Of course not! That’s missing the whole point . Those ~13.3k nodes that chose the LeanPocket path to cost savings over the PIP-22 path to cost savings are saving the network the exact same $1M+ per month just via a different mechanism ($75 cost savings per LC node x 13.3k LC nodes vs $100 cost savings per shed node x 10k shed nodes).
From the get go I have made it clear that from a systems perspective, stake-weighted servicer selection is a superior solution to both LeanPocket and stake-weighted servicer rewards. LeanPocket and PIP-22 both exist because of the inability to implement the “ideal” solution in a timely manner (coredev insisted that it would be a 6+ month dev and the proposal was abandoned).
LeanPocket and PIP-22 were innovative solutions by @addison et all and @Andy-Liquify et al that could achieve infra cost relief ASAP, not 6 to 8 months from now when half the node runners were already bankrupt. There is room for both solutions to coexist during this interim period until V1 turns on in about a year. In v1 both LeanPocket and the PIp-22 version of stake-weighted servicer rewards go away in favor of the V1 version to stake-weighted rewards.
Before moving on, one last thing I want to mention with respect to: “Did the PIP-22 have satisfying effect?” one thing that I want to note is that from a design and engineering perspective I am very satisfied that the dynamically-responsive approach to setting the PIP-22 adjustment factor (SSWM) is working exactly as intended and is causing PIP-22 to operate, to first order, completely agnostic to the fact that many node runners who otherwise would have consolidated opted instead to implement LeanPocket prior to the completion of QA thus shifting consolidation pattern drastically from initial projections. In the first version of PIP-22 where SSWM was fixed, the LeanPOKT curveball would have caused PIP-22 to behave horribly at onset leading to a reward drop of about 50% until corrected via some emergency DAO intervention. With the innovation of dynamically-responsive SSWM, the system behaves in an orderly fashion whether everyone consolidates, no one consolidates or any end state in between.
IMO: Yes! I would like to see, by the end of 2022, node runners having to pay out no more than 20% of their rewards each month to pay for infra costs/ provider rev share. This is a tall order. I do not know if we will get there. But it is my goal.
The greatest challenge facing PIP-22 with regard to hitting maximum-achievable cost savings is bumping up against second-order effects of interplay between session selection and the cherry picker that will prevent it from ever being a vehicle for 100x consolidation. Where that limit lies we do not yet know. It could be that 4x is the limit. Perhaps 6x, or 8x or 10x. I do not think we are bumping up against that limit yet unless @RawthiL et al really produce data that I have not seen yet with clear signatures to the contrary, not just conjectures.
The greatest challenge facing LeanPOKT with regard to hitting maximum-achievable cost savings is obfuscation. Node providers can hide behind the separate node address to justify a certain price point without every revealing to a node runner that what they are actually paying for is just a virtual address on a shared node. At some point there has to be a mechanism introduced to allow distinguishing between the full node address and all the alias node addresses in order to eliminate such obfuscation.
Of course you are entitled to your opinion, but to me this is a rather bizarre statement. It is not about predicting the future, it is about charting a course to step into the future. If, in implementing PIP-22, we forecast that the result of PIP-22 could be consolidation from 44k nodes down to 17k nodes and we “only” reduced to 27k nodes because an alternative cost-savings mechanism ended up being simultaneously introduced, would that mean the the modeling was a failure? Of course not. Either way the projected $2.7M in cost savings is still being achieved… its just being achieved via two complimentary mechanism instead of one.
The only way LeanPOKT and PIIP-22 can simultaneously exist for more than a few months is if they offer similar cost savings to node runners. If LC far exceeded PIP-22 in savings then any attempt at consolidation would be abandoned and nodes would all return to 15k. If PIP-22 far exceeded LC in savings then LC would be abandoned and the system would resort to max consolidation.
I’ll try to add thoughts on the rest of your post tomorrow
… but one last thing before I head off to get some sleep :
Are we really that quick to forget that in June the token price seemed locked in a death spiral and that over the summer POKT price has stabilized, a new trading pattern has emerged, investor interest is returning (as evidenced by trading volume) and current price sits at about double ATL? Did all that happen all by itself? Is it all just a macro affect? Is that what plotting POKT/BTC would show? While no single factor can “claim credit” for this - market dynamics are hugely complex and impossible to parse out in that way - does it not stand to reason that the almost $3M reduction in POKT needing to be liquidated each month to pay for infra costs (through the combined effects of LeanPokt and PIP-22) have a significant positive bearing on this turnaround?
1 Like
Yeah, very happy that such discussion started! I think it is very important and beneficial for everyone involved. DAO should work that way imo.
That’s correct, although the decrease of staked nodes count dropped not only because of PIP-22 announcement, but because inflation rate was reduced significantly through WAGMI proposal(s). It simply wasn’t profitable enough with so many nodes, price falling quickly, and rewards being cut down monthly.
But still, with all the inflation reductions and PIP-22 being live now, we still have 27k nodes compared to approx. 47k nodes at the peak. POKT had an average of 1-1.2B daily relays few weeks back, now the average is around 800 million daily. So, my point is that there is still way too many nodes running. It should be well under 20k nodes for current demand. Will it continue to go down that much without short term interventions? Not sure to be honest.
That is all good, but there should be even more savings. People are forgetting that sell pressure of $1.7 million is much HEAVIER right now at current market cap than it was back in March at $1B+ market cap. So, the longer the we wait, the harder it gets. Pressure is proportionally much bigger now than few months ago.
My point is: why not cut it down further with or without LeanPOKT? If it can be reduced, why not? If the entire current infrastructure is way too much of an overkill for the current demand…
Especially since the node count can be quickly increased (within a matter of days literally) if the need arises. Significant inflation rate increase (much more rewards) would be a strong incentive to build new necessary nodes with coins sitting on exchanges.
You missed my point here. Point is that LeanPOKT makes costly-inefficient nodes not to go away, and reduces the effects that PIP-22 tried to have / achieve in the first place.
That is not possible unless price goes up radically. How can we know that the price will go up? No one can know that.
Point here is that the entire set of changes on the coin economics side is a hit and miss with projected outcomes (which are again subjective as not everyone is using the same variables in equation), where are more misses than hits down the road. But by tracking the outcome of each change / proposal and doing the parameter changes accordingly, we will be much closer to the targeted outcome.
I don’t think people are forgetting that, that’s even a reason why I’m all for reducing the excessive infra cost to get more relief from the excessive sell pressure, which is, as I already said, even bigger now at lower market cap than it was back when the market cap was higher (less coins had to be sold on the market for the same amount of USD).
This is a long topic for sure, so I’m happy that the discussion will be public and that the arguments can be presented publicly like this, so once any voting happens, anyone can form their own opinion based on the facts and arguments presented here.
1 Like
Hi, I just wanted to clarify a few things.
First, the 46k nodes peak was long before PIP-22 approval, as @TheDoc said, the reduction the reduction was due to non-profitability. At PIP-22 approval the number of nodes was 36K.
Second, it will be much clearer for the community if the PIP-22 or other simmilar proposals are sepparated from pure economic objectives:
- If we want to add staking weight to the mix of node rewards, QoS must be taken into account and this will not be solved by simple math.
- If we want to simply reduce the number of nodes, propose to upgrade the minimum stake or keep reducing inflation. This is much more honest to the comunity. It will also keep discussion purelly on economics terms and will avoid taking an obfuscated and long road to reach the same goals.
If there is a need to change the node running rules due to economic constrains, go on, I have no problem with that. I only want these rules to be clear and fair.
Understood. I didn’t quote 46k or 47k peak, I approximated 44k as a reasonable stasis that was developing between attrition and addition in the absence of DAO governance action. Reviewing the data I would have been more accurate to approxiamte 42k since that seemed to be a reasonable asymptote. So… what’s the point… that my estimate was off by less than 5% (42 vs 44)…
That’s what you want to split hairs about?? I’d say my ballpark estimate is close enough and doesn’t affect my argument. But come on!! Let’s not rewrite history and construct a completely false narrative! Good discussion and healthy debate help make the project great. And you bring so many good points to the table for consideration that there is no need to resort to inserting lies into building your case .
Here are the facts after review the PoktScan block data:
- From the middle of June and though the start and completion of PIP-22 voting, active (and indeed for another 24 to 48 hours post approval), staked node count stood at 42k each and every day in that period.
- PIP-22 passed June 28; staked node count still at 42k
- Coincidentally or not, on the very day that PIP-22 passed a major provider announced their intention to unstake most of their nodes - not due to attrition with intention to leave the ecosystem but with the intention of optimizing their configuration in light of recent changes (hint: consolidate to take advantage of to the imminent passing of PIP-22) - with said unstaking taking place starting June 30.
- Starting June 30 and continuing July 1 said provider unstaked some 5 to 6k nodes dropping node count within 48 hours from 42k to 36-37k
Clearly your arrow is in the wrong place… it needs to be moved back one week - back to the correct date and back to 42k. Or better yet post the daily chart instead of the weekly chart for the month of june plus first week of July and everything I’m saying will be manifestly obvious.
This portion of your otherwise excellent comment is not a flattering look for PoktScan. You may wish to edit out this portion of the comment all together. If you do, I will edit out this portion of my response as well .
This is good food for thought but at least the context of PIP-22 and all the other consolidation-focused proposals during the month of June, it is a rewriting of history to insinuate that this is what motivated PIP-22.
By June the community had all but decided that it was for the common good to consolidate the network into fewer nodes. The reasons were three-fold :
- network security (substantially increase POKT staked in validators)
- reduce block bloat / peer messaging bloat
- slash aggregate infra costs
@Andy-Liquify did not invent any of these objectives; rather he invented an elegant solution to accomplish the community’s consolidation objective on a timeline that PIP-23 could not meet and using an incentive-based approach rather than using a forced approach,
I challenge you to go back and reread the Background/Motivation section of PIP-22. You will not find a single sentence about economic objectives. It is all about achieving the technical challenges listed above in the quest to bring to reality the community’s previously-stated desire for consolidation.
Once PIP-23 was “blacklisted” as nonviable, (and setting aside for now the various proposals to increase proposer rewards), two options were put forward to the community as viable mechanisms to accomplish consolidation:
- force consolidation by raising MinStake with the known downside that small node runners who couldn’t consolidate would be forced out of the network.
- incentivize consoidation via stake-weighted rewards allowing small node runners to decide for themselves whether to quit the network of their own accord, stay in the network at 15k,and have a choice to consolidate to intermediate levels if those intermediate levels were not out of reach.
In June, the community chose the latter path over the former path . This does not imply that raising MinStake can’t be put up for reconsideration in the future.
First, never once did anyone ,whether @Andy-Liquify ,@iaa12, myself or any other community member suggest that adding staking weight - whether via PIP-22 or via PIP-23 - was a V0 objective in and of itself. Both PIP-22 and PIP-23 were technical incentive-based means unto the node-reduction objective as stated above.
Second, agree 100% with both statements that “Qos must be taken into account” and “this will not be solved by simple math” What I cannot agree with is the subtle ad hominin attack that insinuates that QoS was not taken into account. History will show that in the case of PIP-22 and PUP-21, QoS was indeed taken into account and was taken into account in a way that acknowledges that it cannot be solved by simple math:
- the vast majority of the time and energy that was put into defining PUP-21 parameters was spent chasing down and resolving, to the coredev team’s satisfaction, the various QoS concerns raised by @luyzdeleon (consolidation leading to too few nodes to support low-volume chains), by myself (unfair reward shifts to servicers of low-volume chains dis-incentivizing node support for these chains) and by your team (unfair reward shifts to 15k nodes leading to degraded aggregate QoS)
- when grumbling emerged in the community over the length of time it was taking to define the parameters - or at least the ceiling value - we pushed back and made it clear that nothing could defined until the QoS concerns were addressed
- While many in the community expressed desire for 8x, 10x or more consolidation, we stuck to principles of putting QoS first and defined the more conservative 4x ceiling so that system behavior could be adequately studied before venturing to higher values.
I believe this conservative approach is paying off in that I have not yet heard any credible report of degraded QoS.
Once again you are resorting to an ad hominim attack of @Andy-Liquify (and myself I suppose), insinuating that he (and I) were acting in a dishonest manner toward the community, were obfuscating and were taking the long road. etc. To repeat: the stated objective of PIP-22 was to offer to the community an implementable path to incentivize consolidation without resorting to the harsher approach of forced consolidation. Both choices were put to the community. The community decided on the incentivized rather than the forced approach
From a pure systems perspective, forced consolidation has a lot going for it. It may be simpler; it may be cleaner; it may be easier to analyze, But what about the little node runner who at the end of the day is the bread-and-butter of making Pocket a truly diverse, decentralized network?!
There are alternatives facing the small, high-QoS node that you care so much about:
- Choice A: “Congrats for your high QoS and high rewards that lets you stay profitable… By the way, everyone must consolidate to 60k or get the boot… So you don’t have the cash to buy more tokens to consolidate? You’re Fired!”
- Choice B: "Congrats for your high QoS and high rewards that lets you stay profitable… By the way, you’re being given the opportunity to consolidate to various levels that let you 2x, 3x or 4x your already high rewards… So you don’t have the cash to buy more tokens to consolidate? No worries, we’re working hard to keep your rewards more or less the same as before, but there may be unknown secondary effects that can cause a +=10% variation in rewards from what you’re used to.
In what universe is choice A more fair to the small, high-QoS node runner than choice B. This, at the end of the day, was why the community chose PIP-22 over PUP 17 or 20.
Forgive for not knowing the internals of the unstaking happening that day, my intention was not to be misleading, the hard number indicated otherwise and I have always used 35K nodes as the base node number before PIP-22 . Also there is no way for me know the reasons behind the unstaking, since the downward trend started before PIP-22.
Please do not accuse me of trying to create a false narrative or plainly lie. I think we all deserve to keep discussions polite.
This is exactly what I say, maybe I was not clear enough.
PIP-22 was created for other puposes but everyone is talking about forcing consolidation due to sell preassure. As I recall the PIP-22 was not created to add preassure to 15K node runners. Force consolidation was not the objective of PIP-22 back then, and it should not be used as a tool to that end today.
2 Likes
Thanks for clarifying re June. Sorry it got a little heated for the moment. But i totally understand there was no purposeful misleading or whatever…
can you clarify: by “everyone is talking about forcing consolidation” are you talking about today or in June? Talk among node runners or @Andy-Liquify et al?
Forced consolidation was not the objective of PIP-22 back then and is certainly not Andy or my objective today wrt PIP-22, but I understand that there may be a sizeable contingency who would like to force consolidation by whatever means possible. Using PIP-22 as a vehicle would be a pretty odd choice to force anything when raising MinStake would suffice. I’ve given a bit of “what if” thought to a drastic jump in minstake - say to 150k POKT, but it’s not like I’m advocating it… just giving it some thought. Talks of modifying MinStake get a whole lot more practical if TransferStake gets passed and implemented as that would remove one of the primary friction points that currently makes changing minstake unattractive.
One of the PUP-21’s explicit, stated motivations was to maintain enough pressure on node runners/providers to innovate in other areas without becoming lazy in implementing best practices, and this objective was achieved by setting a conservative rather than liberal ceiling. But this aim was geared toward large, low-QoS node runners not small high-QoS nodes, since the ceiling value is completely inapplicable to small nodes who aren’t going to consolidate anyway.
I’ll circle back to TheDoc’s comments next in a little bit.
1 Like
Ok @TheDoc , I’m finally ready to interact on your points. But first, top level, I agree with most of your system of thought. So a lot of what follows is starting to define the details.
The three goals of consolidation were infra/cost reduction, security (increase tokens staked to validators) and bloat. LeanPOKT (LC in the rest of my comment, since many have used the term “Light Client”) is aligned with the first goal, agnostic as to the second, and antithetical to the third .
Let’s assume, for the sake of argument, that the goals are listed in priority order. Then LC “scorecard” can’t lag much behand PIP-22 in overall network benefit despite being antithetical to the last goal, and indeed may even exceed consolidation in benefit, if it substantially outperforms PIP-22r in the first category. And there is reason to believe it does. For example a noderunner with 100 nodes at $100/mo per node would save $7.5k/mo (75 nodes x $100) by going to max consolidating, and would save approx $8.4k /mo (99 nodes x $85) by unstaking 99 nodes and restaking them as alias node addresses(that is what LC is) attached to the one full node.
The cost savings is close between the two approaches with a slight nod to LC… but the scores on the lesser priorites tips the scale back down, leaving LC and PIP-22 at almost parity in terms of benefit - hence both solutions coexisting in the system, as stated above.
Setting exp=1, as it is today, creates an incessant drive toward consolidation so long as even the tiniest cost remains in node running. Hence a brand new node runner starting from scratch with 6M POKT would natural maximize returns by staking 99 LCs to 60k attached to 1 full node staked to 60k. Existing node runners would naturally be inclined to do the same, and would do so except for the friction of the 21-day unstaking period. Even so, there may be indication that some LC providers are already starting to consolidate their LC nodes to 60k. If TransferStake passes, then you can expect that as soon as TransferStake is implemented, the rest of the large LC node runners will follow suite and no large node runner (~more than 2M POKT under mgnt) will have any nodes left at 15k.
Everything changes once you set exp<1. Even setting exp=0.9 will drastically alter the balance between LC and regular nodes and dis-incentivize LC consolidation. Setting it to 0.8 will all but kill consolidation, and consolidated nodes would be motivated to unstake to implement LC instead. In the absence of LC, there was great leeway in setting the exponent, as anything in the 0.6 to 1.0 range would have had more or less the same system effect of incentivizing toward 4x consolidation. So long as LC and PIP-22 coexist, we must be very, very careful regarding any attempt to move exponent even slightly away from 1. I can share some graphs later to illustrate.
There is another reason that LC coexists with PIP-22. At the moment, the DAOs hand’s are tied even if they desired to phase out LC; the hooks needed to distinguish between a “full node” and an LC simply do not exist. They would need to be invented and implemented. This would be a fairly substantial undertaking, and there is not much appetite for diverting that much coredev energy away from v1 in order to create the needed hooks. And why should they, given that LC is net benefitting the system not hurting it?
I’ll address some specific points raised a little later.
1 Like
For starters, thank you @TheDoc for kicking-off this discussion.
I have so many thoughts and opinions that I’m not sure where to start. But, here goes…
First, a question for @TheDoc. From your perspective, is the primary goal of proposals like PIP-22 to increase the token price? Or, should the network goals (i.e. network performance, security, scalability, decentralization, etc) be the priority?
I personally think the focus needs to be on making economic decisions that drive the true value and long-term viability of the network which may or may not be directly reflected in the token price. IMO, Pocket Network could be wildly successful even if the token price never sees $1 again. As long as it provides enough value to enough apps in a profitable way. Of course, hopefully when that happens the price will go up. But again, the token price is not a good measure of true progress - or lack of.
The second thing I noted (based comments like the ones above) is that you and @msa6867 don’t really understand how LeanPOKT (or running nodes in general) actually works. This concerns me - espicially when so many people are relying on @msa6867’s models / assumptions / opinions. But I’ll address that more later.
A “node” is simply a POKT address/wallet that is staked. A node is not equal to a single computer/server. You can run multiple nodes on a single machine, regardless of how much is staked in each node. Further, you can do this using various technologies - not just LeanPOKT. For example, many node runners have multiple nodes running on a single server using Docker.
The point is, it does not cost more to run 4X 15K nodes, or even 400X 15K nodes because each node does not require its own server (aka: infra). Meaning, PIP-22 and LeanPOKT are not mutually exclusive.
Also, again, being able to run multiple nodes on a single machine is not new with LeanPOKT - what LeanPOKT does is essentially allow multiple nodes (read: POKT accounts) to share the same blockchain data on the same machine. This allows nodes running on the same physical (or virtual machine) to use less disk space. This is the part that’s new, and yes, it provides a big cost savings. But to emphasize the point, LeanPOKT brings down the costs for any nodes - it doesn’t matter if they are staked with 15K, 30K, 45K, 60K, or if they are a validator or service node - they are all the same from a node running / infra costs perspective.
My concerns about PIP-22 or more specifically, the modeling that was used to promote it to the community.
I’ve shared one-on-one with @msa6867 that I question his depth of understanding of the details related to how pocket works and the business of running nodes. There have been numerous statements that he’s made over the past months (some I’ve highlighted in this post) that are objectively incorrect yet said with confidence and conviction. This feels reckless to me and is the root of my concerns about PIP-22 - or at least the models / assumptions made by @msa6867 that I believe largely influenced the adoption of PIP-22.
@msa6867 is clearly an intelligent individual and a quick study. He seems to have grasped a lot of this stuff in a matter of just weeks - a lot faster than I was able to for sure. But personally, I have a hard time trusting his models because of the number of inaccurate statements he’s made. In addition, I think, as a results of his knowledge gaps, he’s further confusing other community members - just reading this discussion provides plenty of evidence of that.
So, was PIP-22 a good thing? I’m not sure myself. It could be but it’s made understanding the best way to run profitable nodes A LOT more challenging. I’m running over 500 nodes (myself, not through a provider) and before PIP-22 I knew exactly what the nodes were able to produce in terms of rewards and the costs associated with generating those rewards. Now I really can’t say what the best way to configure a nodes is. But @msa6867 who I don’t believe is running any nodes himself, seems to know. I must be an idiot - I’ve been trying to understand the node running business for years and I’m still trying to wrap my head around the economics. But @msa6867 has it all figured out in a matter of weeks - without running any nodes himself? Yes, I’m a skeptic.
The previous statement is an example that illustrates my concerns. It seems to me that the question we need to answer is NOT will one 60K node produce 4x the rewards that one 15K node produces. But rather, will a 60K stake produce more if staked on a single node or on four 15K nodes. If PIP-22 works the way it’s been promoted, a 60K stake on a single node should net the same rewards as 15K stakes on four other nodes (the same total stake - 60K).
Anecdotally, what I seem to be seeing on my nodes, over the past few weeks is that four 15K nodes outperform one 60K node by ~22%. I suspect it’s because, assuming the nodes all configured the same, they will get rewards in a sudo-random manner. If that’s the case, than 4 nodes would increase the likelyhood of being selected - increasing the rewards generated by the same stake amount. It could also be that I just need more time to see things even out. But again, I’ll admit, I’m more confused about how this all works than I’ve ever been.
So, at this point I just want hard data because I don’t know anymore and I don’t believe anyone else does either. To that end, I’m running the following test for the next 60-days. I have 250 nodes all running on a single server (a very large one that is more than enough to handle the load). So, all of the nodes have the exact same hardware configuration (thanks to LeanPOKT, BTW) and they are all servicing the same relay chains. The only difference is that they have different stakes based on PIP-22. There are four cohorts each representing equal stakes of 1.8M POKT (the 15K cohort is bit higher to provide room for slashing if there are issues) which I hope is enough to create a controlled test that is large enough to show reliable results with minimal variability. The following is a breakdown of the cohorts and I’ll share the details when the test is complete.
For me, the results of the test (real data vs hypothesis) will determine my final viewpoint on PIP-22. But regardless, it won’t change my opinion about what I consider the reckless way PIP-22 was promoted and the incorrect and misleading statements that have hindered the progress/adoption of LeanPOKT. For example the following:
I believe what @msa6867 is saying is that investors (not people actually running their own nodes) might be charged more than they’d like to pay when providers start using LeanPOKT. But that has nothing to do with the cost of actually running nodes and is totally incorrect and irrelevant in terms of the actual network costs. Again, another example of a statement made with confidence and conviction yet a lack of understanding that serves only to further confuse people .
4 Likes
I’m glad this is ongoing discussion now.
Not an increase of the token price, but cutting the infra costs to suppress the excessive sell pressure. Because POKT has no demand side currently and if infra costs are way too high, especially for the current demand, of course that price will be crashing even harder and harder because infra costs are the same in USD terms. While POKT market cap is going down like it is right now, infra costs (which are the same in USD terms) are creating even bigger sell pressure itself, larger burden and it will be getting harder and harder to reach the price point where POKT was back in January 2022. Many of you are aware I guess how the “spiral of death” look like.
So yeah, infra costs are to me #1 ranked by importance at this point, but it will change once v1 launches because infra costs will not be as important as decentralization network performance and Quality of Service overall. I think there should always be a (economic / incentive) mechanism in place which would quickly suppress the node count if demand is going down, or the other way around, if demand is growing like 50% in a week, inflation rate increase (or some other method used) should be incorporated to incentive people to build the new necessary nodes to meet the demand.
Previous model (pre-PIP22) required either 4 different single computers/servers or a single machine with much more CPU, RAM, storage space, etc. to run these 4x 15k POKT nodes, which of course costs much more, which again causes higher server costs which will be dumped on the market to cover these costs. With the 1x 60k POKT node on a single node, there is 4x less infra costs. Or maybe I have a completely wrong understanding here, it’s quite late here, I’m writing this after a long 10-hour working day.
But LeanPOKT works in a different way, right? It allows to share the same blockchain data on the same machine for 10 or 1000 nodes. With PIP22, that is not possible, right? Each node requires its own blockchain data, which increases costs a lot, and that causes higher price and higher sell pressure on the market. Am I right or wrong here?
I’ll say again that I believe no one can “predict” the outcomes. It’s the hit and miss strategy to large extent until the targeted outcome is achieved. That’s why I would like to see such economic discussions publicly, where we share our thoughts publicly and where there is no 1 person that does the “economic R&D” which is both expensive and cannot guarantee results. It should be the community decision based on the facts and discussions.
I have to disagree here. Because to me, network costs = total USD infra costs, doesn’t matter if providers are charging $10 or $100 per node. People that are using these providers will have to pay the providers, and they will do it in a way of dumping their POKT to cover the fees. So I honestly see that as a kind of indirect network costs.
Thanks for the comments and feedback @steve , highly appreciated! 
All my expressions might sound “strong” or “harsh”, but I’m truly appreciative for this discussion and have no bad intentions whatsoever. Just trying to make sure all the different viewpoints are covered fairly and properly.
This narrative I keep hearing that infra costs are creating sell pressure is a theory - at best. How do you know this is actually what’s driving the costs down? What percent of node runners are selling their rewards to pay for infra? What percent of their rewards are they selling on average? Which types of nodes runners are selling the most rewards? Are they people using hosting services or people running their own nodes? Are some node runners accumulating rewards to compound and keep up with inflation or saving their rewards - betting the price will go up? If so, what percent of node runners are doing that?
These are obviously rhetorical questions that I know you don’t have answers for because nobody does. So, I’m not clear on why you seem so convinced that high infra costs are creating “sell pressure” and that’s the main reason the price is so low. Could it also be that the hype drove the price way to high initially? Or that because there currently isn’t demand from apps the price keeps falling? Or could it be that too many people who don’t really understand how to run nodes are paying way to much (or being charged way to much) and are selling as a result? Which has nothing to do with the actual infra costs.
Respectfully, your above statement is incorrect. The requirements to run a single node with any size stake is the same and has not really changed much since POKT launched. I think what you mean is that prior to LeanPOKT (not pre-PIP22), running 4 nodes on a single computer would cost more than running a single node on a single computer. Of course, but it would be way cheaper than running 4 nodes on 4 individual computers. But that’s kind of a moot point becaue that isn’t how most nodes are run (one node per computer) and that’s been true since way before PIP22 or LeanPOKT.
Another question for you. What do you think a node costs someone who knows how to run their own nodes? I suspect you might not know the answer so I’ll tell you what my costs are. Before LeanPOKT my costs per POKT nodes was about $17/month per node (not including my time). With LeanPOKT my costs are less than 1/2 that and I know of node runners that are doing better than me. So, let’s do some math. Say you’re using LeanPOKT and your cost per node is $10 / month. Let’s also say it only generates 15 POKT on average, per day. In 30-days that’s 450 POKT for $10, or $0.022 per POKT. Please explain to me again why you think the costs are too high? The costs are not too high - a lack of understanding is too high, and that’s costing retail node stakers/investors. But that is not a problem at all for people running their own nodes or companies providing hosting services.
Your previous statement highlights an example of the confusion that PIP22 has created. Again, LeanPOKT and PIP22 are not mutually exclusive. You can have a machine running LeanPOKT that is supporting multiple nodes with any combination of the PIP22 stake levels. Remember, a node is just a POKT account - PIP22 and LeanPOKT have not changed that. PIP22 just changes how much a node gets rewarded based on the stake and LeanPOKT lets node accounts share the same blockchain database which mostly just cuts the cost of storage on the machine doing the work the nodes are rewarded for.
There are some similar benefits when you look at LeanPOKT and PIP22 individually but they can also be used together. While this might be a good thing (again, I don’t know yet) it’s way more confusing - which is not good IMO. The LeanPOKT initiative was started before PIP22 but some felt that LeanPOKT would take too long, or really just didn’t understand how it worked and became convinced that PIP22 could be implemented faster. That wasn’t the case. An early open-source version of LeanPOKT was available before PIP22. So some node runners (myself included) got an opportunity to evaluate LeanPOKT even before PIP22. I’m going on a bit of a tangent here and it is-what-it-is now but again, PIP22 makes things much more complex from my perspective. Hopefully, after navigating the complexity and completing controled tests, the value (or lack of) will be clear. But I’m not to that point yet.
Actual costs and what people are charged are not the same. Costs represent the financial resources required to run the nework. Those costs are far less than what is being paid. If people are getting charged too much that has nothing to do with the ability to provide a cost-effective decentralized network. In due time, as buyers become more educated and hosting becomes more competitive (and it will), the market will fix the over pricing issue. However, the market can’t fix a scenario where the actual costs to run the network are too high to attract profitable usage. Thankfully, and why I’m bullish on POKT despite the current price, this isn’t close to being true.
I also appreciate you starting and engaging in this dialog. I will never take offense to “strong” or even “harsh” opinions so never hold back on my account. Thanks again!
4 Likes
Inflation on the basis of no demand side will eventually lead to unprofitable infrastructure into a death spiral. Only by ensuring the profit of infrastructure can more people be attracted to participate in network construction.
At present, POKT needs to be sold when the demand increases in the future. Finally, it will start to burn when the supply and demand balance between nodal vendors and the demand side.
3 Likes
I agree 100%. In the long-run, if there isn’t demand that makes running nodes profitable at the network-level, it won’t matter.
But I believe the current relay volume is evidence that there is demand. Now we just need to answer the following questions:
- Will apps pay for the relays and if so how much?
- Can we run nodes profitably given what apps are willing to pay for the relays?
I don’t know the answers. But there is a lot market evidence suggesting that we’re heading in the right direction.
Thanks for the comment @ZZX !
3 Likes