Binaries - Upgrading Your Node

f(x)Core Network Upgrades

There are 2 types of network upgrades with similar steps but it is IMPORTANT to differentiate and identify which type of upgrade is required and which to perform before the upgrade height is reached. Hard fork requires validators to upgrade their nodes before the upgrade height and software upgrade requires validators to do so after the upgrade height.

Hard fork upgrade:

The code after the upgrade is backward compatible, so the node can (and needs to) be updated before the upgrade height, and when the upgrade height is reached, the node will automatically switch to the new logic.
Software upgrade:
When the upgrade proposal is passed, we need to wait for the block height to reach the upgrade height set in the proposal. We cannot use the new program to update the node in advance, because the code after the upgrade is backward incompatible. When the block height reaches the upgrade height, the node will automatically stop producing blocks and print the log: "ERR UPGRADE" upgrade proposal plan name "NEEDED at height: upgrade proposal set height...", and then we can use the latest program to update the node
For more information on past upgrades and instructions, refer to Upgrade Versions.
You may refer to this Countdown Timer which will countdown the time till the upgrade height.

Upgrade steps

  1. 1.
    Ensure you have stopped the node❗
With Daemon
With PID
sudo systemctl stop fxcored
ps -ef | grep fxcored
kill -9 <PID>
2. Pulling the latest fx-core code base (ensure that you are in the fx-core folder):
git pull
3. Checkout the branch of the upgrade version:
git checkout <upgradeable version branch>
for example:
git checkout release/v2.2.x
git checkout tags/v2.2.1 -b release/v2.2.x
Check log whether is the latest commit
git log
commit d5d54614f3227bb070e4a930c0ca95f0e31006a5 if you checked out the branch without specifying the tags
commit 5eef07630e89ad0bd786fb08fa0fb937e5c84d67 (HEAD -> release/v2.2.x, tag: v2.2.1) if you checked out the tags
4. Update fxcored (ensure that you are in the fx-core folder):
make go.sum
make install
5. Cross reference the latest commit hash to the commit in our official github page:
fxcored version
6. Download genesis (copy and run each line, line by line)
wget -O ~/.fxcore/config/genesis.json
wget -O ~/.fxcore/config/config.toml
wget -O ~/.fxcore/config/app.toml
wget -O ~/.fxcore/config/genesis.json
wget -O ~/.fxcore/config/config.toml
wget -O ~/.fxcore/config/app.toml
7. Restart the node:
sudo systemctl restart fxcored
8. Check whether the node is participating in consensus:
cat $HOME/.fxcore/data/priv_validator_state.json
It should return something similar to the following:
You can cross reference the block "height" field with that of the FunctionX Explorer
"height": "347450",
"round": 0,
"step": 3,
Additional features of client.toml
Users can specify the configuration of certain commands in the configuration file client.toml
Configure priority --flag> client.toml(default)
A point to note is that client.toml configuration are for fxcored CLI, while app.toml and config.toml are configurations for the node.
Optional value
Chain ID-used when signing transactions
Keys storage method os: stored in the system password, file: file, specified password encryption, test: file, no encryption
Output format when querying
Node address to be called
Broadcast transaction mode
Modify client.toml command fxcored config $key $value (example):
fxcored config chain-id fxcore
fxcored config keyring-backend test
fxcored config output json
fxcored config node "tcp://"
fxcored config broadcast-mode block