github pokt-network/pocket-core RC-0.6.3
on GitHub

latest releases: proofofconcept, RC-0.11.3, RC-0.11.2...
pre-release2 years ago

NOTE: This release requires using a backup datadir (provided below) or syncing from scratch due to the new custom transaction indexer

RC-0.6.3

  • UpdateStake Transaction
  • MaxApplications Bug Fix

NOTE: The above features are only enabled after the DAO 0.6.X upgrade height

Upgrade:

  1. Shutdown Pocket Core (NOTE: Validators will not be jailed until they have been offline for 6 blocks. You have more than one hour to complete this upgrade. 15 to 30 minutes should be sufficient.)

  2. !!! Ensure golang version 1.16 !!! or > golang upgrade NOTE: This version is new so please ensure you are on 1.16 or later 

    # Startup script linux users might find this useful (BenVan's Validator Script Only)
sudo apt-get update
g install 1.16

  3. Build from source, Homebrew or Docker:

    To build the latest binary from source, follow these steps:

    Navigate into your pocket-core directory:
    Example: cd ~/go/src/github.com/pokt-network/pocket-core

    Enter: pocket version
    You should see: RC-0.6.2 (or older)

    To grab the latest packages and tags we are going to swap branches to the latest tag using:

    git pull
    git checkout tags/RC-0.6.3
    Once you checked out the latest tag and branch, we are going to rebuild the binary by entering in:
    go build -o $GOPATH/bin/pocket ./app/cmd/pocket_core/main.go

    After it builds, make sure you are on the latest release version by entering in:
    pocket version

    Output will be RC-0.6.3

    If you built your binary using Homebrew, follow these steps to upgrade your binary:

    In a terminal window, we are going to pull the latest tap by entering:
    $ brew upgrade pokt-network/pocket-core/pocket

    After it builds, make sure you are on the latest version by entering in:
    pocket version

    Output will be RC-0.6.3

    For individuals using Docker, all you will need to do to get the new container image is run:

    docker pull poktnetwork/pocket-core:RC-0.6.3

    or

    docker pull poktnetwork/pocket:RC-0.6.3

    Depending on which of the 2 Docker images you want to use.

  4. Upgrade your config.json
    Use the default config for all options (except unique configurations like moniker, external addr, etc).

    You have two options:
    OPTION 1 (RECOMENDED)

    Run pocket util update-configs command (creates a new config file and backs up old config file)

    In order to use the most performant values, you will need to upgrade your config.json file in within your /config directory
    Run the pocket util update-configs command to backup your old config and generate a new default one.
    Manually go over your DATADIR/config/config.json.bk file and update your new DATADIR/config/config.json with any custom changes that you use.

    OPTION 2

    Backup and remove your existing config.json file (mv DATADIR/config/config.json DATADIR/config/config.json.bk)

    Execute a CLI command, (this will cause a default config.json to be created), then update the custom configurations.
    Manually go over your datadir/config/config.json.bk file and update your new datadir/config/config.json with any pertinent values such as moniker, external addr, etc.

  5. NOTE: **Step 5 and 6 IS ONLY NEEDED IF RUNNING VERSION EARLIER THAN RC-0.6.0:
    Delete Session.DB before upgrading

    • rm -rf <datadir>/session.db

  6. Convert pocket_evidence.DB before upgrading

    • pocket util convert-pocket-evidence-db

    Successfully Converted Pocket Evidence DB

    If the command Failed and success message not shown, delete pocket_evidence.DB

  7. NOTE: Step 7 IS NEEDED FOR ANY VERSION BEFORE RC-0.6.2 DUE TO THE NEW TRANSACTION INDEXER

    • PNI temporarily will provide a backup datadir to download to avoid syncing from scratch (MAINNET ONLY):
      27K .tar.gz

    After uncompressing the file, replace the DATADIR/data folder with the new data folder.

Release Details:

MaxApplications Param:

  • Applications cannot stake (no matter what amount) if this parameter is enabled and MaxApplications threshold is reached.
  • If an Application unstakes a slot will open up.

UpdateStake

  • Apps
    • Applications can up their stake amount (but cannot lessen stake amount)
    • Applications can updated their RelayChains 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 their RelayChains
      Rules:
      1) Must be after upgrade height
      2) You should ONLY be able to execute this transaction while status = staked
      3) You should be able to execute this transaction while in jail
      4) Only can modify certain parts of the structure 

                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
          }

How?
Simply execute the stake transaction again with updated values:
pocket node stake <fromAddr> <amount> <relayChainIDs> <serviceURI> <chainID> <fee> <legacyCodec=(true | false)>
pocket app stake <fromAddr> <amount> <relayChainIDs> <chainID> <fee> <legacyCodec=(true | false)>
As long as the new parameters adhere to the rules described above, the transaction will successfully update staked values.
Details in the CLI Spec and the Architecture guide.

Testing and QA considerations:

  • Stake should be working as normal.
  • Unstake should be working as normal.
  • Update stake should only work after upgradeHeight (validate that it’s not possible before)
  • Update stake should only work for staked entities.
  • Update stake should still match original rulings. 
- If executed a change 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 - PASSED
    B) the v1/dispatch sequence should not show the node anymore - PASSED (it’s removed after the session ends tho)
    C) if an app removes the chain from the list, a node should stop servicing the app // this might not be true
    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 // this might not be true
    F) if a node changes service url the change should happen right away in the v1/dispatch sequence - Happened in the next block (different than with chain IDs)
  • Tendermint’s behavour:
    • Depending on the stake updated, node/Apps should be removed/added under the same rules, correct?
  • Document tests in the testing documentation framework

If UpdateStake 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

MaxApplications - make sure is enabled after upgradeHeight.
MaxApplications - make sure N quantity of APPs can be staked before the upgradeHeight.
MaxApplications - Enabled - Block new exceeding APPs to stake.
MaxApplications - Enabled and Reached - Unstaking APPs allow new staking APP to be staked.
MaxApplications - Enabled and Decreased - Existing staked APPs remain staked.
MaxApplications - Enabled and Decreased - Existing staked APPs remain staked (if they are greater than maxAPP)
MaxApplications - UpgradeHeight occurs - Existing staked APPs remain staked (if they are greater than maxAPP)

For more information on test results/details, this spreadsheet stated them:
https://docs.google.com/spreadsheets/d/1OPzsIxMs6FdxocYujgh_WHs3ohbjNKIHzH0xy8w57Y8/edit#gid=285455087

For steps by steps and procedural details on each scenario, please refer to the following repo (in which latest scenarios are still being updated):
https://github.com/pokt-network/pocket-core-func-tests

Attached, please find the setups used for this functional tests execution, plus some test data/evidence on the updateStake scenarios from both, APPs and Nodes, procedures:

RC-0.6.0.zip
NodeUpdatingResults.txt
APPsEvidence.txt

Check out latest releases or
releases around pokt-network/pocket-core RC-0.6.3

Don't miss a new pocket-core release

NewReleases is sending notifications on new releases.

Get notifications