Attributes:
-
Author(s): @msa6867
-
Parameter: ServicerStakeWeightCeiling
-
Current Value: 60000000000
-
New Value: 75000000000
Summary:
PUP-21 set ServicerStakeWeightCeiling to 60k POKT, allowing up to 4x stake-weighted servicer rewards. This value was chosen over a more aggressive setting of 90k-120k (6-8x) due to the unknowns associated with turning on stake-weighted service rewards from the pre-PIP-22 baseline configuration.
The network now has 2.5 months of operation at the current configuration. During this time, PIP-22 is operating as expected and QoS has improved across the board between the approval of PIP-22 in June and today, as illustrated in the following data taken from cherry-picker data on the Polygon chain.
Latency (ms) | Asia Pacific | Europe | N. America |
End of June | 579 | 268 | 397 |
2nd wk Sep | 413 | 211` | 295 |
Delta (ms) | -166 | -57 | -102 |
Delta (%) | -28.6% | -21.1% | -25.7% |
It is proposed, therefore, to raise ServicerStakeWeightCeiling to 75k POKT. This is a sufficiently small change from current configuration that there is low probability it would trigger any degradation to QoS. Any consideration of changing the ceiling to a value higher than 75k would be deferred until network operation and QoS is first observed for a period of time at the new level of 75k POKT and would necessitate a new parameter update proposal.
Abstract:
Three questions of unknown Quality of Service (QoS) impact were raised during the July time period in which PUP-21 was formulated that led to the decision to set ServicerStakeWeightCeiling to a conservative value of 60k POKT rather than a more aggressive value:
- Consolidation of nodes servicing lower-volume chains might decrease the number of nodes servicing those chains so much as to cause an inability to fill a session with 24 nodes, leading to potentially compromised QoS due to lack of competition / QoS differentiation within the cherry picker.
- Lack of node consolidation on lower-volume chains compared to high-volume chains might lead to reduced rewards per relay for those chains followed by node runner decision to stop supporting those chains, leading to QoS degradations on those chains.
- Consolidation of nodes with significantly less than, or greater than, network-average QoS may lead to diminished network-wide QoS and may cause enforcement of WAGMI/FREN inflation emission targets to negatively impact small node runners disproportionately.
The status of the above concerns, now that we have 2.5 months of operation completed at current parameter settings, are as follows:
- There have been no reports that sessions are not being filled with 24 nodes on low-volume chains. Further with LeanPocket being made publicly available to node runners during the summer months, less consolidation has taken place to date than anticipated. There is no reason to suspect, at this point, that further raising the ceiling to 75k or 90k POKT would cause the onset of such issue. Note that generating sufficient supply-side support for certain high-cost/low-reward chains and regions is an ongoing issue that is unrelated to PIP-22-driven consolidation and should not hinder a modest increase to ServicerStakeWeightCeiling.
- There is no evidence that levels of consolidation differ more than negligibly between low-volume and high-volume chains. Current data shows that chain-agnostic and chain-weighted levels of consolidation differ from each other by less than 1% (Currently, 1.90x vs 1.89x consolidation factor). Thus rewards per relay are comparable from one chain to the next and the expressed concern has not materialized.
- One node provider brought network metrics to the attention of the community in late September that they felt demonstrated that issues related to the third concern above were being realized in the system and needed to be remediated. (See PUP-25). The author of this present proposal has spent extensive time over the last two months examining the claim and the data behind it and is satisfied that there is no QoS or fairness issue that hinders moving forward with raising ServicerStakeWeightCeiling to 75k. Posting this current proposal was deferred until a thorough review and disposition of all the PUP-25 claims had been completed. That disposition is complete and can be found attached within the comments section of PUP-25.
The absence of QoS detriments in response to current levels of consolidation suggests that a further modest increase to ServicerStakeWeightCeiling is safe for the network. It is proposed, therefore, to raise ServicerStakeWeightCeiling to 75k POKT.
Motivation:
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.
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.
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.
End Worry that ServicerStakeWeightCeiling will be reduced to 30k or 45k POKT: There are several large stakeholders who have suboptimally 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.
Rationale:
Changing the ceiling to 75k rather than a larger value allows for observing system response for an adequate period at the new nigher level prior to considering any future proposal to change the ceiling even further.
Dissenting Opinions:
“PUP-25 raises questions of system fairness and quality of service related to the current PIP-22 configuration; therefore, ServicerStakeWeightCeiling should not be considered while PUP-25 is outstanding.”
PUP-25 has been posted on the Forum for almost two months. During that time, no other party in the ecosystem has introduced corroborative evidence for the claims being made. Further it has been almost one month since any person besides myself has interacted with or commented on that proposal. I have recently completed an extensive review of the PUP-25 claims and the data behind the claims, and have concluded, at least to my own satisfaction, that the concerns raised in PUP-25 are errors of interpretation and that there is no fairness or QoS issue that arises from current PUP-21 parameter settings that would stand in the way of raising ServicerStakeWeightCeiling modestly to 75k.
Furthermore, raising ServicerStakeWeightCeiling is orthogonal to any consideration to set the PIIP-22 weighting exponent to a value less than 1. If, in the future, bona fide reason to decrease the exponent is found, proposed and passed by the DAO, that new exponent value will operate just as will with a ceiling of 75k as it would with a ceiling of 60k.
“Current setting of ServicerStakeWeightCeiling is already optimal.”
I have outlined reasons why raising the ceiling to 75k provides marginally better optimization in the system than the current value.
“Proposal does not go far enough; ServicerStakeWeightCeiling should be raised to a value greater than 75k”
That is a question best left for the future. It is felt by the current author that the benefits of being safe in terms of QoS and network stability that come with increasing the ceiling by only one increment of 15k POKT outweigh arguments to make a large jump to some perceived “optimal” setting.
Copyright
Copyright and related rights waived via CC0. *