Mainnet Upgrade – 0.6.3 Bonus Feature – Update Stake

0.6.3 Release

Our upgrade process has been designed to allow for changes before a consensus rule change is activated. For activation to happen, ≥67% of validator power must update to the new version (which contains the yet-to-be-activated rules), the DAO must approve a PIP, and then this approval must be executed through a pocket gov upgrade transaction submitted by the DAOowner account (currently a Pocket Network Foundation multi-sig).

While we were coordinating node updates on the road to 67%, the node community rallied around an RFP to add “Update Stake” functionality, in particular before we start onboarding new chains.

Well you asked and we answered, with 0.6.3.

Since Update Stake would itself be a new consensus rule change, and we haven’t completed the existing consensus upgrade yet, it is our view that we should make 0.6.3 the new consensus upgrade version, to simplify the upgrade process and incorporate Update Stake sooner rather than later.

The Bonus Feature: Update Stake

Update Stake is new functionality that enables apps/nodes to edit certain parameters of their stake without needing to unstake first. Since unstaking takes 21 days for economic security, this feature will save apps/nodes 21 days every time they want to change something.

To update your stake, simply submit the pocket node/app stake transaction. When you are already staked, this transaction acts as an update transaction. Some extra details for this transaction:

  • You do not need to be unjailed to edit your stake.
  • If the node/app is currently staked at X and you submit an update with new stake Y, only Y-X will be subtracted from an account.
  • If no changes are desired for a parameter, just enter the current parameter value just as before.

In particular this will help nodes with 2 key challenges:

  • Adding support for new chains on already staked nodes
  • Topping up their stake to prevent falling below the 15,000 POKT minimum stake

Apps

  • Applications can up their stake amount (but cannot lessen stake amount)
  • Applications can updated the RelayChainIDs they are staked for

Nodes

  • Nodes can up their stake amount (but cannot lessen stake amount)
  • Nodes can update their service url
  • Nodes can update the RelayChainIDs they are staked for
          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
          }

Executing Update Stake Mid-session

If Update Stake is executed mid session (while servicing), there are some other behaviors that are expected:

A) If a node removes that chain from their list they will not get paid for that claim/proof
B) The v1/dispatch sequence should not show the node anymore
C) If an app removes the chain from the list, a node should stop servicing the app
D) A node should get paid for an app that changed mid session
E) If an app updates stake and Max relays the node cannot do more than previous max relays
F) If a node changes service url the change should happen right away in the v1/dispatch sequence

Other Changelog Items

0.6.3 also ships with a few other improvements:

  • MaxApplications threshold activated (if all slots are taken, no additional apps can stake regardless of the stake amount)
  • Return AllClaims if no address is passed to nodeClaims query
  • No ABCI query during newTx() function in pocket core module
  • Change StdSignature from Base64 to Hex in RPC

The New Upgrade Process

The upgrade process will proceed as normal, with 0.6.3 as the new version.

We’ll now proceed with the process from Step 4:

  • 0.6.3 has been released and is available to upgrade now here.
  • PIP-4 has been amended to specify 0.6.3 as the new version being upgraded to.
  • All node runners, including those who already upgraded to 0.6.0, must upgrade to 0.6.3.
  • If/when ≥67% of nodes have upgraded, reaching consensus for the new protocol version, PIP-4 will be amended again to include an upgrade height (the height at which the new consensus rules will be activated and non-updated nodes will be left behind). PIP-4 will then be put to a vote. This gives the DAO the chance to veto the consensus rule change before it is executed.
  • Voting on PIP-4 will last 7 days and pass with a 50% majority. If the vote passes, the Foundation will activate the upgrade at the specified height using the pocket gov upgrade transaction.

All node runners, including those who already upgraded to 0.6.0 and 0.6.1, must upgrade to 0.6.3.

FAQ

For general upgrade FAQs, refer to the original 0.6.0 announcement post here.

Are the details in the original announcement doc and community call still relevant?

Yes, the upgrade details outlined in the 0.6.0 announcement doc and discussed in the community call are still reflected in 0.6.3. It is still the same upgrade in essence, with the addition of this bonus feature and a few smaller improvements.

2 Likes