Attributes
-
Author(s): @msa6867
-
Recipient(s): Terracelum, Inc.
-
Asking Amount: 300000 POKT
Summary / Abstract
The goal of this proposal is to fairly compensate @msa6867 for research and development, modeling, and pre- and post-implementation analysis that went into defining and implementing PIP-22 and PUP-21. PIP-22/PUP-21 was vital for network security and scalability. The scaled weighting scheme that was developed allowed for both fast deployment and significant cost savings for the community.
Abstract
The Liquify team worked hand-in-hand with @msa6867 to make the vision for stake-weighted rewards a reality. To date approximately 15,000 nodes have unstaked from the network to participate in and take advantage of the new reward structure introduced by PIP-22 and PUP-21. Using an estimate of $100 per month per node in costs to run a node, PIP-22 saves $1.5M PER MONTH in infrastructure cost. Not only is this a direct tangible benefit to node runners who consolidate, but it also gives a huge boost even to those who do not or cannot consolidate by helping stabilize POKT price by greatly reducing the POKT being liquidate each month in market sell orders to cover infrastructure costs.
Liquify cast the original vision for stake-weighted servicer rewards, authored the first draft of PIP-22 and provided the heavy lifting on the development side. @msa6867, on the other hand, added key improvements to PIP-22 needed to ensure PUIP-22 was tenable, authored the first draft of PUP-21 and provided the heavy lifting of analysis and modeling need to make the PIP-22 vision a reality.
The Liquify team proposed and was approved for reimbursement for their development effort for implementing PIP-22/PUP-21. I declined the invitation to forge a joint funding proposal as my intention had been to forego reimbursement for prior contributions should PEP-39 have passed. The Liquify team nonetheless graciously carved out 62k POKT to stake on my behalf as a gift/donation/âthank youâ. Regarding PEP-39, the community has indicated that PEP-39 was the wrong vehicle for @msa6867 to seek DAO funding and advised instead to utilize the standard reimbursement mechanism that defines most other PEP funding initiatives. Hence the current proposal which seeks reimbursement, after accounting for and subtracting the 62k already pledged by the Liquify team, for my contribution to make Stake-weighted Servicer Rewards a reality.
The process of analyzing and modeling expected system behavior in response to PIP-22, adding improvements to PIP-22 as discussed below, defining the initial parameter set so as to achieve the simultaneous objectives of maximizing consolidation while maintain high QoS for DApps and fairness to node runners, writing PUP-21, and conducting post-activation system analysis has taken around 300 hours since the middle of June 2022. I am only seeking reimbursement for 160 hours of those hours.
Motivation
My main motivation, with respect to my involvement in Stake-Weighted Servicer Rewards, was to ensure that in the process of reducing overall network costs the network would remain orderly and fair, be neither inflationary nor deflationary, ensure high QoS for DApps and have the ability to incentivize less consolidation in the future as new nodes are needed to accommodate RPC growth. System observations during the two weeks following turn on of PUP-21 parameters indicate these objectives are being met.
PIP-22, as originally proposed, fell short of these objectives in several regards. Chief among them was the lack of a mechanism to incentivize movement to smaller-staked nodes in the future and the lack of a defined mechanism to keep PIP-22 from being unfair to small node runners who canât consolidate without resorting to creating a massive inflation spike.
@msa6867 added two innovations to PIP-22 to correct these limitations. First, a knob was added to allow varying degrees of nonlinearity to stake-weighted reward. This introduces a principle of diminishing returns and can be adjusted to incentive maximum consolidation, minimum consolidation or anything in-between. (Currently it is set to incentive maximum consolidation.) In the beginning the addition of this knob seemed, to many, to make PIP-22 âtoo complicated.â Now it is seen by many node runners/providers as an indispensable knob to optimize the system balance between small and large node runners; there has been considerable interest expressed recently in exploring options for exponent<1. Looking to the future, the innovation of adding a non-linear weighting knob survives into V1 even as the rest of PIP-22 is retired, since this knob can easily be added to the V1 version of stake-weighted rewards.
Second, a dynamically responsive approach to setting ServicerStakeWeightMultiplier was developed to prevent either massive inflation (leading to a flood of new nodes at a time when additional nodes are not needed), or massive deflation (leading to small nodes being starved out of the network). This innovation removes, to first order, the dependency of one nodeâs rewards on the consolidation choice made by other node runners.
Proposal Objectives
The goal of this proposal is to receive a reimbursement for the time spent refining, optimizing, analyzing and modeling the PIP-22 implementation and PUP-21 parameters.
PIP-22 and PUP-21 Objectives
Node consolidation objectives that are enabled by PIP-22/PUP-21:
- Lower costs for node runners.
- Increased network security with the increase in validator threshold caused by the stepping of PIP22.
- Reducing node count at a protocol level allows for a faster healthy network with reduced bloating.
PIP-22/PUP-21 objectives while enabling node consolidation:
- Prevent starving small node runners of rewards or forcing them off the network
- Maintain WAGMI/FREN emission objectives
- Preserve DApp QoS even on chains with less volume
- Isolate node rewards from the consolidation choice made by other node runners
- Avoid the draconian alternative of forced consolidation or add stake
- Is implementable on a one-to-two month time scale
Dissenting Opinions
âThis, in combination with PEP-40, seems like a lot to pay for a PIPâ
The amount of compensation was calculated using the Proposal Value Model. Further, the hours input to this model were truncated at 160 hours even though many more hours than that were actually dedicated to the task. The combined spend between PEP-40 and this proposal would be 870k POKT (570k PEP40 + 300k for this proposal). This is a roughly $87k spend for a feature that demonstrably is saving $1.7M per month in infra costs and helping to stabilize POKT price for everyone.
âYou were already compensated for your PIP-22/PUP-21 contribution via PEP-40. No other reimbursement should be expected.â
As was acknowledged in the comments section of PEP-40, PEP-40 focused mainly on the dev work, and the 10% carveout was in no way meant to indicate that I provided only 10% of the work to make PIP-22 a reality. The ask of this proposal in combination with the 62k gift from Liquify from PEP-40 would result in a roughly 60/40 split of total reimbursement for PIP-22/PUP-21 between Liquify and @msa6867. I believe that anyone involved in the movement of PIP-22 from inception to reality would see a 60/40 split as being reasonable.
âWith Lean Pocket is this needed?â
Yes. PIP22 goes hand in hand with Lean Pocket. PIP22 has advantages over âoff chainâ consolidation mechanisms. PIP22 reduces the node count at a protocol level this helps make the network more efficient. PIP22 also helps improve network security by vastly raising the validator threshold. PIP22 is also fully governed by the DAO allowing them to adjust consolidation parameters as they see fit.
Further, some simple math reveals the following: even if the ENTIRE system implemented some form of Lean Pocket such that it drove average ânodeâ cost down to $15 per node per month⌠by PIP-22 eliminating 20k nodes from the network that are not currently needed, it would STILL save $300k per month in costs! A $87k one time spends to accomplish this level of MONTHLY savings is a tremendous value for the DAO.
That being said, @addison, @poktblade and all the rest of the team that developed and open-sourced Lean Pocket ought also to be generously reimbursed for their contribution to the ecosystem as well. When multiple solutions all contribute to the improvement of the network, all can be rewarded. It is not âeither/or;â it is âboth/andâ. For that matter, Henry et al at NodeForAll ought to receive fair compensation for PUP-19 to reward them for the way they and their proposal cut through what seemed to be DAO gridlock and prompted the community to take a decisive first step toward mechanisms that could bring infrastructure cost relief.
Deliverables (Completed))
- Provided detailed analysis of original PIP-22 draft
- Incorporated non-linear weighting into PIP-22 draft and defined a dynamic-response mechanism for setting ServicerStakeWeightMultiplier
- Provided analysis and modeling of system behavior in response to final PIP-22 version
- Investigated and addressed to CoreDev satisfaction all QoS and fairness challenges to PIP-22 implementation (QoS consideration for low-volume chains brought by @luyzdeleon, fairness consideration for high-QoS 15k nodes brought by @RawthiL and PoktScan team, fairness consideration for servicers of low-volume chains brought by myself).
- Defined a construct for setting PIP-22 parameters; proposed and passed PUP-21
- Provided post-activation analysis of system response to PIP-22 to ascertain and ensure that QoS, fairness and inflation objectives are being met within tolerable bounds.
Budget
The total reimbursement requested for this proposal is 300000 POKT. This is the amount that was calculated after capping hours at 160 and inputting this into the Proposal Value Model using premium settings similar to those defined by Liquify in PEP-40 (but slightly less due to the inapplicability of a couple line items).
Contributor(s)
@msa6867 (Mark Abinante) is the sole contributor covered by this proposal since the Liquify team has already been reimbursed via a separate PEP.
I would like to thank @Andy-Liquify for proposing a mechanism to incentivize, rather than force, node consolidation in a way that could be implemented in a one-to-two-month time scale.
I want to acknowledge the following persons or groups for their contributions to the PIP-22 process: @addison for digging into the math details in response to my initial PIP-22 analysis; @adam for his independent modeling of post-PIP-22 system behavior; @Luyzdeleon for bringing awareness to the unique QoS challenges faced by low-volume chains; @RawthiL and the PoktScan team for bringing awareness to the unique challenges faced by small, high-QoS nodes and for defining a new potential use case for enabling nonlinear weighting in a future PUP.
Copyright
Copyright and related rights waived via [CC0](http