[WIP] PIP-24: TransferStake

Build Research
30

Agreed.

No, I meant to ask, how pressing is it to add this to v0 as opposed to waiting for v1

31

I also like this proposal. It would be useful for noderunners like myself that wish to consolidate. Couldn’t we add a passphrase requirement to prevent unauthorized people from staking to your node? We already have passphrases for staking.

32

Unstake command already prompts the user for the <fromAddr> account passphrase. It would be a logical extension from this to prompts the user for the <receiver_output_address> account passphrase since this address becomes the new (I think?)

33

Per our offline conversation to prevent some pingponging:

  1. Enabling multi signature will not prevent two parties from transferstake since both parties can just sign it.
  2. MSA brings up a great point about the unknown factors of enabling such operational effiency and I propose two things to make this more seamless and giving the controls back to the DAO if we ever need to use them - which are disabling TransferStake (curious if we can just do this via feature flags) and providing a customizable MinTransferStake amount that the DAO can control set at MinStake.

I will need some more time to create the final spec (maybe next week instead of Sept 1-5)… but look forward to all the conversation in the mean time.

34

Thanks. Sounds good to me. I look forward to seeing final spec

35

I agree with the premise of the idea. I’ve also been thinking about how to solve these issues. I echo some of the security concerns of others.

I think we can agree on the outcomes of something like TransferStake:

  1. Enables greater competition (leading to lower prices) among large node runners by allowing for easy movement across nodes
  2. Pocket’s economics will continue to change in the near to medium term, and the ability to easily move POKT to other nodes allows for much relief in this landscape

Thinking about solving this from first principles I’d like to offer a thought experiment:

What if we had DAO treasury be the counter party for a loan to transfer anyone’s stake among node runners?

You would need a neutral facilitator and/or a safe, open market for this to work.

The DAO could do this for a nominal flat fee or a % of the yield generated during the unstaking period. This fee could either be earned by the DAO, burned, or kept by the facilitator.

The foundation would be a good neutral facilitator, but I hesitate to delegate more to the foundation. I wonder if there was a multisig managed by members of the community that was topped up monthly and whether that reduce some of the burden (this may be risky due to not having threshold signatures native to Pocket yet).

It makes sense for the DAO to be a counter party due to rates likely being being infeasible with others being the counter party (e.g. staking yield would exceed this lending yield). The DAO would be the ideal candidate to facilitate with minimal rent extraction for the benefit of the ecosystem.

Just some thoughts to try to solve this from a different angle. A lot of the concerns would be alleviated by some neutral committee or software with agreed upon checks related to some of the concerns raised. Not saying this shouldn’t be done on-chain via TransferStake, but looking to take things off-chain to keep the protocol’s risk and bloat minimal is worth exploring.

1 Like
36

It is an interesting thought experiment. I’m not sure I would want to see the DAO/DAO Treasury get in the middle of provider competition. Seems to open too many doors for possible - or at least perceived - bias, preferential treatment or favoritism. And also opens to at least the perception of diversion of DAO energy from its primary purpose which may cause a dent in investor faith in POKT;

Pushing this to various degrees of “arms length” from DAO via a “facilitator” may resolve the above concerns , but the more arms-length you make it the more risk of non-repayment or graft is opened up due to reliance on a “trusted” 3rd party. I’m not at all saying its not doable… just the risk needs to be managed.

That being said, your thought experiment does open up two broader areas for discussion: (1) there is nothing that says that the fee for all on-chain services must be 0.01 POKT. If on-chain "bloat"as you put it is allowed to give functionality to a certain group that another group will never have occasion to use, and especially is offered as a convenience, rather than a necessity, then it is fair that the users of the service pay a premium for its usage. What if you take whatever flat fee or % you had in mind and bake it into the onchain fee of TransferStake. (e.g., FEE = 0.2% or 10 $POKT , which ever is greater)?

Second, a broader discussion of capital management of the DAO treasury is needed. There may be various useful ways to put the funds to work to earn a return and/or facilitate a new burn sink. This bears exploring in the future.

1 Like
37

Thinking about it further… anyone (including DAO Treasury could set up an unstake-loan-as-a service if the mechanism were in place (which I’m not sure it is) to have the unstake amount sent to the service-providers address. No questions asked as to purpose of the unstaking. If it is to switch providers, that’s the owners private busiess) (Analaogy: tax refund loan by tax prep rpoviders)

Another thought that I had been floating around w some others is to do something similar on chain… differential fees for standard and expidited unstaking (Analogy: UPS or FexEx shipping rates). eg FEE (providing a new sink for the token):

  • standard 21 day delivery: 0.01 $POKT
  • 14 day delivery : greater of 1 $POKT or 0.1%
  • 7 day delivery : greater of 3 $POKT or 0.3%
  • 3 day delivery : greater of 10 $POKT or 1 %
  • 1 day delivery: greater of 50 $POKT or 5 %
38

Historically, fees have generally been for spam protection. I am not sure how I feel about changing the definition of this. It can result in arbitrary “POKT” sinks depending on our token economics and can result in a carrot and stick dynamic. Not sure if that is ideal. I’d like to see this built upon more, but perhaps in a future proposal.

39

Absolutely! I did not mean to imply to add it the scope of this proposal… I was just continuing the thought experiment that @o_rourke started, Items to explore in the future.

40

I like this proposal. It will be very useful, We won’t have to wait 21 days to unstake our nodes if we wanted to consolidate or break a higher stake node to smaller ones.

41

Hey everyone:

A quick update

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.

1 Like
42

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

2 Likes
43

This proposal is on halt due to validator security:

1 Like
44

Is there any news on this feature or the RPF that is (as I understand) blocking the advance of this feature?

45

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.

Thoughts?

2 Likes
46

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.

2 Likes
47

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).

1 Like
48

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.

2 Likes
49

We keep trying to lower inflation. Significant portion of inflation is actually node runner profits.

Anything that increases node runner competition, i.e. allows rapid transfer between them, should ultimately allow us to reduce inflation.

Maybe it would also stop centralisation in certain providers, by reducing the loss in switching from them.

I think this all applies to validators too, and important (and fair) they can transfer too. Just need to nail security concerns.