First, I have posted an answer to your claims that there is no fairness issue with the linear model used for PUP-21 (and this proposal also). There I also comment on why that proposal was not moved forward.
Now, regarding this new proposal and ignoring the total absence of proof behind the linear model, I have some other comments.
TL-DR:
I see no reason for moving forward with this proposal , based on the following reasons (please read below for justification):
- No real cost reduction for the large majority of the node runners.
- No cost reduction for node runner clients.
- No expected increase in the QoS (actually I expect the opposite).
- The PIP-22 is not the right tool to increase the validators threshold. Using PIP-22 as the jack-of-all-trades is irresponsible.
Since the creation and approval of PIP-22 (June 2022) the Pocket Network changed a lot. At the time of the creation of the PIP-22 the cost of running a Pocket Node was high (too much sell pressure), the LeanPocket was not ready yet and the number of nodes (~56k) was creating too much bloat in the block size (and processing times). In this context the PIP-22 was able to rapidly reduce the number of nodes in the system and solve some of the mentioned problems.
The PIP-22 was chosen over simply rising the minimum stake since it was easier to accept, as it promised unchanged rewards for those that did not up-stake. I do not think that this was the best choice in the long term but it surely did its job quick enough.
Today we have LeanPocket and GeoMesh, these tools changed the paradigm of running nodes in the Pocket Network. With LeanPocket the cost of running one node, 50 or 100 is exactly the same in terms of hardware costs. Then, with GeoMesh, the cost of globally distributing a node running operation decreased dramatically, as no new Pocket Nodes were required, only the blockchains.
So, the first issue that I found is that this claim is incorrect:
Reduce infrastructure costs: Medium to large stakeholders can reduce their node count by ~20%, over time, by moving stake-weighted rewards from 60k to 75k. While this may not seem like a large percentage compared to the initial savings of consolidating to 4x, every source of savings is important in the current market environment.
As it is publicly known, the cost of running a Pocket Node or 100 or 400 is the same (using LeanPocket). Any large and medium node runner has LeanPocket (or some version of this) running in their system. This 20% reduction in cost exists only when the 20% of the total nodes of the node runner is exactly one server, this is only valid if you have 2000 nodes (only two node runners above this threshold as of block 76701, not sure if all their nodes are at 60K). No medium-size node runner will benefit from this. I see very little reduction in sell pressure coming from medium or large node runners operations.
Now, from the point of view of a client, who will sell tokens to pay the node runner provider, I see even less reduction of the cost. Most providers are charging by stake (even by unit of POKT staked) or have a reward sharing mechanism. As the cost of the node is no longer important. There is little to no impact on the sell pressure coming from node runner clients. Their sell pressure do not relates to the number of Pocket Nodes that the client owns.
Finally and most important, the author seems to be overlooking a very important factor of node running, the real cost comes from the associated blockchains not the node itself. Running a single Pocket Node requires to have one or more blockchains associated to it. Having one Pocket Node or hundreds of them make no difference, as the traffic that a well configured blockchain can handle is normally much higher than the expected traffic coming from a Pocket Node. While this highly depends on the blockchains that are being staked, the rule of thumb is that you can easily handle hundreds of Pocket Nodes per blockchain. Also, the reduction of the Pocket Nodes makes no difference in the expected number of blockchains that must be deployed. No cost reduction whatsoever.
Second, the author hints that there is an increase of QoS to be expected:
Optimize stake-weighted rewards: Setting consolidation level of 4x in PUP-21 was not an endorsement of 4x being the optimal configuration point but was rather an act of cautiousness to allow observation of the system at that level before making any decision to ratchet higher. Now that the system has been observed, stake-weighted rewards is operating as expected, and Quality of Service is consistently higher than pre-PIP-22, higher levels of consolidation than 4x can be considered.
While there was an increase in the QoS due to PIP-22, this was in a completely different network landscape. The increase in QoS (before GeoMesh) was achieved by a reduction of the number of nodes. This reduction lead to a change in how low-QoS and high-QoS nodes performed compounding and resulted in an increase QoS. Back then there was an economical incentive for the node runner client to un-stake and perform compounding, since the node runner charged them by node. This is no longer true in most cases. Also the cost of the Pocket Node itself was important, and small and medium node runners were also motivated to perform compounding. Today the cost of the Pocket Node is almost irrelevant.
Also, we are seeing that the network has divided in two kind of node runners, those with 15K stake and those with 60K stake. The node runners in 15K have lower QoS than those in the 60K group. This can be seen by looking at the average minted of each group. Probably the 60K group will be more inclined to perform compounding to 75K since it has already done it once.
The problem I see is:
- No economic incentive for compounding, I expect the 15K group to remain the same.
- The 60K group demonstrated that it is interested in perform compounding. I expect them to do it again.
- The 60 K group has higher QoS than the 15K group.
- This proposal will reduce the number of nodes in the staked in the 60K group (by a 20%) and keep the nodes in the 15K group constant.
- I expect the new network to have more low-QoS nodes than high-QoS nodes. Thus, the average network QoS will drop.
This motivation is difficult to prove:
End Worry that ServicerStakeWeightCeiling will be reduced to 30k or 45k POKT: There are several large stakeholders who have sub-optimally allocated POKT to 30k and 45k nodes to hedge against ServicerStakeWeightCeiling being reduced to 30k or 45k and/or another mechanism being enacted that effectively eliminates highly-consolidated nodes from the network. Setting ServicerStakeWeightCeiling to 75k POKT helps ease concern that the Ceiling will be reduced in the present time frame in which the network is still over-provisioned from a node-count perspective.
I think that many node runners are seeing that there is no point in staking in the higher bin (besides fairness issues):
- Rewards are the same in any bin.
- Pocket Node cost is negligible.
- Having less nodes increase your Time Between Sessions.
- Inflation control mechanisms (FREN, PUP-21 corrections) are being applied more frequently.
I don’t know if staking to the max bin and hope for being lucky and enter a big session is a better strategy than having lots of nodes and trying to get all the tokens I can before the next parameter change hits (inflation controls). Just a thought…
Also the author claims that: the network is over-provisioned from a node-count perspective. I would like to see where is the fundament of this claim. Right now (block 76704) we have 26140 nodes, blocks are being processed in time and block size seems controlled. As I said before, Pocket Node count has no large effect on the network cost anymore. Why are we still over provisioned?
Finally this is the only real effect this proposal will have:
Increase Network Security: It is expected that as a result of raising ServicerStakeWeightCeiling to 75k, the amount of POKT staked to validators will increase by approximately 15%. While that may not seem much, any increase of validation-related network security is welcome, and it is low-hanging fruit involving no distraction to the development team. If the number of validators is increased to 2k via a separate proposal then the increased average staked POKT from this proposal will have a multiplicative effect when combined with raising number of validators.
While increasing the validator threshold is always nice, since it secures the network, I think that PIP-22 is not the right tool for the job.
Using PIP-22 for this end brings many other “second order” effects that add complexity to the Pocket Network. We should discuss a cleaner way to increase the validators threshold (for example, assign an extra ticket to anyone with more than X POKT staked).
(I will later analyze the other proposal PUP-28)