Intermediate
The “Huygen” upgrade guide (v0.6.* to v0.7.*)
This tutorial provides a step-by-step guide for upgrading from version 0.6.* to version 0.7.* of the Cronos blockchain. The upgrade is called the “Huygen” upgrade and is scheduled to occur at a specific block height, which users should not attempt to upgrade to before that time. The tutorial includes instructions for backing up data, downloading the new binary, verifying the installation, updating the app.toml file, and restarting the node with the new binary. Additionally, the tutorial covers a patch for a known issue in version 0.6, where transactions were included in a block even when the block gas limit had already been reached, causing some “unlucky” transactions and duplicate transactions. The tutorial provides two methods for obtaining a complete database with the patched transactions, including starting from the genesis block and performing the necessary steps at each block height or performing a one-off sync from a snapshot.
The Cronos v0.7.0 – Huygen upgrade is proposed to be scheduled at the block height of 2,693,800. Referencing estimated time can be found on
DO NOT UPGRADE to the binary v0.7.0 before that suggested upgrade schedule.
You might check the current block height by the Cronoscan explorer or using
curl -s https://rpc-cronos.crypto.org:443/commit | jq "{height: .result.signed_header.header.height}"
Step 0 – Don’t panic
At the point of the proposed upgrade, user will see the error message on the cronosd
similar to the below:
ERR UPGRADE "v0.7.0" NEEDED at height: 2693800: {\"binaries\":{...."}}
Don’t panic – The Chain will be paused to allow the majority of validators to upgrade. Validators and full node hosts will have to upgrade your Cronos nodes to the latest release binary.
Backups
Before the upgrade, node hosts are encouraged to take a complete data backup. backup depends heavily on infrastructure, but generally, we can do this by backing up the .cronos
directory.
It is critically important for validator operators to back-up the .cronos/data/priv_validator_state.json
file after stopping the cronosd
process. This file is updated every block as your validator participates in consensus rounds. It is a critical file needed to prevent double-signing if the upgrade fails and the previous chain needs to be restarted.
Step 1 – Get the v0.7.0
binary
To simplify the following step, we will be using Linux-x86 for illustration. Binary for Mac Windows with different DB and architecture are also available here.
-
Terminate the
cronosd
; afterwards, download the0.7.0
released binaries from github:$ curl -LOJ https://github.com/crypto-org-chain/cronos/releases/download/v0.7.0/cronos_0.7.0_Linux_x86_64.tar.gz $ tar -zxvf cronos_0.7.0_Linux_x86_64.tar.gz
Remarks: If you have stated cronosd
with systemd service, kindly stop it by
$ sudo systemctl stop cronosd
And replace the binary in the location where the ExecStart
states in Systemd Unit file.
Step 1.1 – Verify the version
You can verify the installation by checking the version of cronosd
, the latest version is 0.7.0
.
# check the version of cronosd $ ./cronosd version 0.7.0
Step 1.2 – Update app.toml
In this v0.7.0 upgrade, there are a few extra parameters that we would have to add to .cronos/config/app.toml
under
-
EVM Configuration –
[evm]
and; -
JSON RPC Configuration –
[json-rpc]
. they are:... ... ############################################################################### ### EVM Configuration ### ############################################################################### [evm] + max-tx-gas-wanted=500000 ... ... ############################################################################### ### JSON RPC Configuration ### ############################################################################### [json-rpc] + feehistory-cap = 100 + logs-cap = 10000 + block-range-cap = 10000 + http-timeout="30s" + http-idle-timeout="120s" ... ...
kindly insert the above parameters, save it and move on!
Step 2. – Run everything
We are ready to start the node join the network again with the new binary:
-
Start
cronosd
, e.g.:
$ ./cronosd start
Remark: Once the cronosd
is started we would see the message
applying upgrade "v0.7.0" at height: 2693800"
and there will be an iteration over the previous blockchain data. This process will take a while, which is depending on the size of the database and the hardware specs.
Afterwards, sit back and wait for the syncing process. You can query the node syncing status by
$ ./cronosd status 2>&1 | jq '.SyncInfo.catching_up'
If the above command returns false
, it means that your node is synced; otherwise, it returns true
and implies your node is still catching up.
At this step, you’ve successfully performed the Huygen upgrade!
Patching Unlucky & Duplicate Tx
In the first version of Cronos (v0.6
), there was a known issue where transactions were being included in a block even when the block gas limit at the EVM level had already been reached. This led to:
-
Some “unlucky” transactions (before block height
2693800
) are not reflected at the EVM level -
One would observe a few blocks that have >100% of the block gas limit at the EVM level.
-
Duplicate transactions
A node host has two ways to obtain a complete database with patched transactions:
- Start from genesis and perform the necessary steps at each block height
- Perform a one-off sync from a snapshot
Method 1: Start from Genesis
Step 1. Follow the Cronos Mainnet docs from step 1 to start syncing a node with binaryv0.6.11
Step 2. When you reach blockheight 2693800,
the binary should automatically halt. Now run the command fix-unlucky-tx
to patch unlucky transactions. This patch only works for blocks until blockheight 2693800.
./cronosd fix-unlucky-tx --start-block 1 --end-block 2693800
./cronosd fix-unlucky-tx --start-block 1 --end-block 2693800
More information on this command can be found in the release notes of 0.7.1-rc0
Release v0.7.1-rc0 · crypto-org-chain/cronos And in the patch unlucky tx wiki Patch Unlucky Tx
Step 3. Verify that the unlucky tx have been patched by checking the following example tx hash 0x435ef379b9ddf226d9fe098ae39d36aed2d03f3c46febd84c48919f1adf1b7fe
curl -X POST 'https://evm.cronos.org' \ -H 'Content-Type: application/json' \ -d '{ "jsonrpc": "2.0", "method": "eth_getTransactionByHash", "params": [ "0x435ef379b9ddf226d9fe098ae39d36aed2d03f3c46febd84c48919f1adf1b7fe" ], "id": 44 }' {"jsonrpc":"2.0","id":44,"result":{"blockHash":"0xf0843bf4f40edb41537ef08fe70e192da77fba26eaae31871c63b15a2b9bda81","blockNumber":"0x2925bc","from":"0x1bfcb6b1ee66fe339a9dc452359c4c111cc5ffc0","gas":"0x5d9b18","gasPrice":"0x48c27395000","maxFeePerGas":"0x48c27395000","maxPriorityFeePerGas":"0x48c27395000","hash":"0x435ef379b9ddf226d9fe098ae39d36aed2d03f3c46febd84c48919f1adf1b7fe","input":"0xd931ccbc000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000050000000000000000000000000000000000000000000000000000000000000bf50000000000000000000000000000000000000000000000000000000002faf0800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000012c00000000000000000000000000000000000000000000000000000000000026de00000000000000000000000000000000000000000000000000000000000005dc","nonce":"0x8b","to":"0xb212ce53ff067ce6e07e3adcd39a362e54c9e534","transactionIndex":"0x1e","value":"0x0","type":"0x2","accessList":[],"chainId":"0x19","v":"0x0","r":"0xf5268b439f80c5294465d70804fe2f731ef87bf54d726ead72772a0162081767","s":"0x292d753ad7e52839c974df0325bd41cb2766d4f1c0ecd5d561d14da05b257d8"}}
Step 4. Run the command reindex-duplicated-tx
to patch duplicated transactions. This command works for all blockheights.
./cronosd reindex-duplicated-tx --start-block 1 --end-block 2693800
Step 5. Verify that the duplicate tx have been patched by checking the following example tx hash 0x3941c8a1625163165fb185e934d463743258ee4b0924c5deb690fc836dab839d
curl -X POST 'https://evm.cronos.org' \ --header 'Content-Type: application/json' \ --data-raw '{ "jsonrpc": "2.0", "method": "eth_getTransactionByHash", "params": [ "0x3941c8a1625163165fb185e934d463743258ee4b0924c5deb690fc836dab839d" ], "id": 44 }' {"jsonrpc":"2.0","id":44,"result":{"blockHash":"0x6eca0e692f6cce612a5c52294db0f5c75127dc6feb310b2693bc697fe3797793","blockNumber":"0x28c3ed","from":"0xdb8befa2f810662316e298f387c943e57b377260","gas":"0x7a120","gasPrice":"0x4a36fb03800","hash":"0x3941c8a1625163165fb185e934d463743258ee4b0924c5deb690fc836dab839d","input":"0x54d2f242","nonce":"0x30","to":"0xc6494099716abe3d95db5a97e5a7fc5ae7e7caba","transactionIndex":"0x0","value":"0x0","type":"0x0","v":"0x55","r":"0xea07319d8a7666afd8ad4970d7f11e2135c9b71719fc34b69995c110beeb84f4","s":"0x2f4f5aa3a822121ee65aa879ff50a2a4504d2f7575d404f1d22685e06d86e07b"}}
Step 6. After the unlucky has been patched, follow the Upgrade notes on performing upgrades until the node is synced to the current block height.
You can print out which blocks will need re-indexing by adding the --print-txs
argument. Bear in mind that this won’t actually reindex the block, but rather just print.
Method 2: Start from a latest patched snapshot
Alternatively, you can do a one-off sync, if you start with the most recent snapshot, that already includes patched transactions (after November).
Get the latest snapshot with patched data on S3 here