I realize that there needs to be a bit more questions to be answered (see my updated attack vectors). I’ll be moving the technical discussions over to the Pocket Core Github once there is a draft ready so that Core contributors can address concerns more formally. In the mean time, this proposal won’t go into vote until those questions are answered and a more fleshed design spec is presented / mvp implementation. (Besides, there’s no rush to, as the vote can start async once development has started) I would say that this conversation - regardless was extremely valuable in gauging the community support for TransferStake and I’m glad we’re aligned. I am certain we can get a variation of TransferStake into the protocol that is safe for everyone- so stay tuned for that.
I have given this proposal a lot of thought over the last week. While some use cases it makes possible do not excite me (e.g., rapid switch of providers) it is a reasonable price to pay for the other use cases it does enable. And to be fair, many may argue that rapid switch of providers is a net positive feature for the system.
What started as a simple exercise in reducing the friction of competing for validator slots has grown to include other use cases, such as reducing the friction of those who have not yet consolidated according to the weighting allowance of PIP-22 (primarily those who have implemented some form of Lean Pocket) so that they may do so without the burden of the 21-day waiting period.
These use cases are only the tip of the iceberg. I predict that looking back a few years from now, TransferStake will be viewed as one of the most indispensable and transformational CLI Commands ever to be added to Pocket Network. The use cases are almost unlimited and all center on enabling the network of Pocket nodes to operate as a decentralized, autonomous and yet organized whole that is rapidly responsive to changing market conditions and system dynamics.
Here are just a few of the use cases that TransferStake enables beyond those mentioned elsewhere in the proposal.
Initial settings for PIP-22 specified linear weighting while stating that there may be desire to move to nonlinear weighting in the future. The mere possibility of specifying exp<1 in the future has led to suboptimal consolidation by many node runners; TransferStake allows node runners to optimize for current settings by removing the friction involved in future parameter changes
If the DAO decides that PIIP-22 exp<1 is superior to exp=1.0 for QoS or other reasons, the DAO may hesitate to make the change due to how disruptive the change will be to the network, thereby leaving the system as a whole with a suboptimal parameter setting. TransferStake removes that friction at the DAO governance level, leading to being able to optimize PIP-22 parameter settings.
Raising MinStake to achieve rapid system-wide node consolidation can be explored in earnest again since the disruption such a parameter change would have unleashes previously is all but removed.
Lowering MinStake to achieve rapid expansion of nodes is absolutely need in the future if Pocket Network is successful. A quick back-of-the envelope calculation shows that to service 1T relays, Pocket will need approximately 300k nodes. Projecting forward from FREN and other modest future inflation reduction measures, there will never be enough POKT in existence to stake more than about 150k nodes to 15k POKT. TransferStake will enable frictionless reduction of MinStake to 5k POKT or whatever number is needed to accommodate RPC growth
Suppose bizdev opens a new region (e.g., Japan) with large initial RPC count. Large node runners can quickly spin up nodes in the new region by transferring tokens from regions that are over-provisioned to servers in the new region.
During the current phase of development (all eyes on V1), all consensus-breaking proposals must be weighed, in part, on the risk/reward of current utility and survivability into v1 versus the amount of V0 dev time and energy that is required. Since the utility of TransferStake is high for remainder of v0 and remains high in V1, and since the dev work needed in order to implement is relatively modest, I strongly support this proposal and the attending commitment of coredev resources to implement it
This proposal is on halt due to validator security:
Our network security is weak, and this “enables” attacks to happen faster than expected. Please read Increasing Validator Security through Delegation and Other Ideas · Issue #1477 · pokt-network/pocket-core · GitHub to understand more. This will be revisited once our validator security is addressed. To be fully clear, I do not believe that TranferStake is the problem, but rather, we have other issues in the network which would exemplify if it was approved. First, we must tackle those problems before visiting this one. Thanks to @Jinx for the callout.
I’ve deemed TransferStake to be a pretty simple integration (and modification) of application logic intp pokts blockchain. The problem lies within the amount of sheer unprecedented staked amounts that can be transfered within one block without notice. This becomes a large concern due to the threshhhold of our validator pool currently.
The RFP - which addresses validator security concerns is what needs to be addressed before the original TransferStake can move forward. My RFP was discussed in last core contributor hours on Wednesday. TLDR (summary of the call) - delegation not likely to happen, perhaps raising PIP-22 bins is on their radar. They need to be focused on V1 so significant “lifts” are not being considered right now.
To be fully clear, I still believe that a 21 day unstaking period for anything in regards to “transfer” activites to be far too punishing, and would like too see a resolution before V1. Perhaps, we modify the conditions of TransferStake to be inclusive of servicers only and not validators. Or we simply just decrease the unstaking period to ~3-4 days for all use cases. I’m not too sure.
What if we restrict the scope of the TransferStake command to servicer addresses?
I think this proposal is interesting besides the validators race. It enables rapid changing of providers and reduces horizontal/vertical scaling. I think this is one of the main reasons why we see so many 15K POKT nodes.
Validator stake is also important but it needs more research. We can start by implementing StakeTransfer to less critical parts of the network and then move on to analyze the Validators case.
Right now the validator threshold (64.2K POKT) is marginally above the ServicerStakeWeightCeiling (60K POKT). This value has been increasing slowly, as it is expected since the logical staking strategy is to be at the edge of the threshold and try to float there. We could define a new (soft) floor for becoming a validator. Then we can limit TransferStake to only occur below this threshold, removing (or difficulting) many validator attack vectors on the network.
What I’m thinking is:
Define a ValidatorStakeFloor. This could be set to ValidatorStakeFloor = ServicerStakeWeightCeiling + StakeMinimum.
With current values this is 75 K POKT = 60 K POKT + 15 K POKT
Keep top 1000 staked nodes as Validators.
Assign an extra validator ticket to those validators above ValidatorStakeFloor. This will likely raise the validator threshold rapidly.
Restrict TransferStake to servicer accounts. Transfer will only be allowed from accounts below ValidatorStakeFloor.
Restrict the maximum value that a single account can receive from TransferStake to ServicerStakeWeightCeiling. This will avoid transferring to ValidatorStakeFloor limit and then become validator using a small amount of POKT.
I like the pragmatic approach here. Iterating and refining the process down the road until V1 is not a problem to me.
Yes, this is what I had in mind in the above post. Pretty much only allowing servicers to TranferStake. I overall agree with the idea.
I am iffy about changing the mechanisms we have in place for validator tickets. Something to note, but not necessarily a blocker, is the block proposer code for this lives in the tendermint fork, not the application layer.
As well, perhaps, raising the PIP-22 bin once more would just be cleaner solution. Why do we need to increase to 75k? Trying to get a better idea of why.
Instead of defining a new variable, I believe we can just retrieve the 1000th validator’s balance and define that as the ValidatorStakeFloor and as well retrieve the validator set. If the transfer amount + receiver staked amount >= ValidatorStakeFloor or the receiver is in the validator set, then we can make the TX fail. I believe this would meet your requirements, let me know if i misunderstood.
Overall, validators will just pay the price of not being flexible to transfer funds until they are outbiddded. Given that’s a small percentage of the network, I am fine with that (it’s not like they were going to be able to transfer funds before something like transferstake anyways).
I added the new variable to include a “buffer” between the validator threshold and the ServicerStakeWeightCeiling.
I wanted to be sure that you wont be able to trasfer the stake and place 666 nodes at the current validator threshold and then, staking only 666*100 = 66600 POKT claim, 666 validator spots.
I think that this will only rise the validator threshold again but we will end up in the same situation where the validator trshold is very near the ServicerStakeWeightCeiling.
This is also OK for me. I would only modify the hard cap, failing all transfers above the servicer bins: transfer amount + receiver staked amount >= ServicerStakeWeightCeiling
This way, as the difference between ServicerStakeWeightCeiling and validator threshold grows, the hypotetical attack that I descrived before becomes less and less likely.