f(x)Core v3.1.0 Manual Upgrade Instructions
f(x)Core Network Upgrades
WARNING
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
Ensure you have stopped the node❗
2. Get the latest fxcored
binary
1. Pulling the latest fx-core code base (ensure that you are in the fx-core folder):
2. Checkout the branch of the upgrade version:
for example:
Check log whether is the latest commit
commit 49d991f692d6662660c2c2dd9e009238f595c438 if you checked out the branch without specifying the tags
3. Update fxcored (ensure that you are in the fx-core folder):
3. Cross reference the latest commit hash to the commit in our official github page:
4. Download genesis (copy and run each line, line by line)
5. Restart the node:
6. Check whether the node is participating in consensus:
It should return something similar to the following:
You can cross reference the block "height" field with that of the FunctionX Explorer
⭐⭐⭐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.
key | default | Optional value | description |
---|---|---|---|
|
| 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):
Last updated