RFP-6: Enable Update Stake Before Onboarding New Chains

Ideas
1

With the onboarding of new blockchains into the Pocket ecosystem imminent, we should consider how they will be supported by existing node operators and what affect new blockchains will have on the network.

Defining the Problem

Unstaking a node to update its supported chains is a 21-day process that renders a node and its stake unusable. Previously it was thought that the unstaking time would be reduced after decentralization day, but that does not seem to be the case based on the PIP here.

In the near future, new networks will become whitelisted and available through Pocket. The DAO obviously wants these networks to be well supported on the node runner side. Without a method to update a node’s stake, there are two ways node runners can support a new chain:

  • Launch a new node using more POKT
  • Unstake their existing nodes to re-stake in 21 days

Either choice could have disastrous affects on the network stability.

If node runners choose to launch new nodes, it will exacerbate the issue raised by PUP-4 – increasing validator count. In the case of a valuable network like Ethereum Archival coming online, you can imagine that dozens, if not hundreds of new nodes will come online to support it.

If node runners choose to unstake their existing nodes to re-stake, it is possible that large groups of nodes will go offline all at once. If multiple major operators choose to unstake to support the new networks, the number of active nodes serving the current chains might drop under the necessary threshold for quality service.

It is also worth mentioning, that unstaking a node for 21 days is very unappealing to node operators as all of the node’s income is lost. This downside could affect support of new networks.

Now it is true that the two approaches above may offset each other – enough nodes go offline to re-stake that the new nodes coming online don’t upset the validator count. But that is a risk that is difficult to quantify. And as the network grows, node operators should be thought of more as independent entities that may choose whatever option best suits them and not what is best for the network as a whole.

Proposed Solution

Implement an UPDATE STAKE function so that node operators can update their staked chains without requiring a 21-day thaw.

Open Questions

  • How difficult is this to implement?
  • Does the ability to modify staked chains affect QoS?
5 Likes
2

I’m definitely onboard with this proposal, however we have to consider all angles that are impacted by it. A few thoughts are:

  • I believe not only chains supported should be updatable for both Nodes and Apps, but also Service URL for Nodes as well.
  • We have to understand that the way this needs to be implemented is that these changes get applied between sessions and not immediately as it could be error prone and cause state issues if nodes and apps modify their stakes mid-way.
  • We need an anti-spam mechanism, such as a cooldown of some sort, as this is a transaction that potentially could be spammed continuously by Nodes and Apps alike and we need as much space as possible for claims and proofs in the blocks.

In general I believe this is going to overall positively impact the network and make it more flexible for both Nodes and Apps to participate.

2 Likes
3

I’d like to voice my support for this proposal, it would be great to see implemented before updating the chain support. I’ve got a single pokt validator, yet numerous (potential) back-end nodes. It seems rather silly being fully out of commission for 21 days, to be able to sever the pokt network better.

As Luis mentioned, it would be good to consider other parameters that could / should be updatable without unstake and waiting period. IMHO anything that isn’t decommissioning. In particular i’m thinking of increasing / decreasing the staked amount, to dynamically adjust to needs.

2 Likes
4

I agree. This is much needed and removes an unnecessary operational hurdle.

It also would greatly speed up the adoption of new chains and thereby reduce the danger window of chains with small node count.

Edit to add: I’m not sure that we should allow changes to amount of stake, either up or down. Might introduce some undesirable incentives to keep adding small stake bumps to avoid a force unstake.

3 Likes
5

I would love to see this happen, I firmly believe this will help adoption of new non-native chains by node providers.

2 Likes
6

Considering the timing (first chain onboarded in June), if there’s much support for this I’d recommend delaying the RC-0.6.1 upgrade and fitting this in for RC-0.6.3 (or greater) and and setting that as the DAO upgrade rather than doing two consensus rule change upgrades.

1 Like
7

Hi all,
I’m also pro for implementing an “update stake” mechanism. But as already was brought up, we need to avoid the implications on the network which such a dynamic “update stake” may cause. So was thinking about something like:
→ update stake (with freshly added relay chains),
→ update stake isn’t taken in effect straight away, but rather with an increment period of 3 - 7 days,
→ The freshly added relay chains are in effect and payout rewards after the increment period has been reached.

If above is flawed in regards to the current pocket infrastructure and architecture, please do correct me.

8

Pocket Architecture actually always looks at the last session block for the latest state, so theoretically changes wouldn’t take effect until the session completes and a new one starts. If there is a conflict, the node operator would just lose the relays for that session and an application would receive a new service node in place (similar to if a service node gets jailed mid-session)

Here’s a proposal

Rules:
1) Must be after 6.X upgrade height
2) You should ONLY be able to execute this transaction while status = staked
3) You can also execute this transaction while in jail
4) Only can modify certain parts of the structure (see below)

type Application struct {
    Address                 sdk.Address      // SHOULD NOT CHANGE
    PublicKey               crypto.PublicKey // SHOULD NOT CHANGE
    Jailed                  bool             // SHOULD NOT CHANGE
    Status                  sdk.StakeStatus  // SHOULD NOT CHANGE
    Chains                  []string         // CAN CHANGE
    StakedTokens            sdk.BigInt       // CAN GO UP ONLY
    MaxRelays               sdk.BigInt       // CAN GO UP ONLY
    UnstakingCompletionTime time.Time        // SHOULD NOT CHANGE
}


type Validator struct {
    Address                 sdk.Address      // SHOULD NOT CHANGE
    PublicKey               crypto.PublicKey // SHOULD NOT CHANGE
    Jailed                  bool             // SHOULD NOT CHANGE
    Status                  sdk.StakeStatus  // SHOULD NOT CHANGE
    Chains                  []string         // CAN CHANGE
    ServiceURL              string           // CAN CHANGE
    StakedTokens            sdk.BigInt       // CAN GO UP ONLY
    UnstakingCompletionTime time.Time        // SHOULD NOT CHANGE
}
1 Like
9

I absolutely support getting “update/modify” stake before enabling the new chains. In fact, I consider it is a prerequisite.

  • It simplifies onboarding the new chains significantly. No need to worry about incentives, cost-of-opportunity compensations.
  • All my customers start asking about unstaking / restaking. This is a serious business continuity concern, but also, very worrisome for the network health. No one wants to miss out rewards, and I worry that thousands of nodes may go offline, jeopordizing network stability / app experience.
  • Since unstake / stake takes 21 days, people will want to minimize this, and they will simply stake for all the upcoming chains, whether they are ready or not. We will have hundreds of nodes on a chain but not ready to serve any successful relays.
2 Likes
10

Just an update on RFP-6:
Given the amount of support and lack of opposition in the community for Edit Stake in the 6.X release. PNI is actively developing Edit Stake feature for RC-0.6.3 release and hope to have it complete shortly to maintain the original RelayChains whitelisting schedule

2 Likes
11

Update Stake is here!

2 Likes