Software Upgrade on Fuxi-8000 Testnet

Sophie Huang

Published in

IRISnet Blog

5 min readJan 19, 2019

Editor’s Note: Fuxi-8000 has smoothly upgraded to v0.10.2 at height 50000.

Highlights:

Fuxi-8000 Testnet upgrade schedule:

Phase One (Jan.16~Jan. 18): we bootstrap the network with iris v0.10.0 in a decentralized way. After that, we expect the network to be running for two days.
Phase Two(Jan.18~Jan.21): After Fuxi-8000 goes steady, dev team submitted a runtime Smooth Software Upgrade proposal to v0.10.2. More than 70% voting power switched to v0.10.2 before #50000, new functions in v0.10.2 is now activated.
Phase Three(Jan.21~Jan.25): Team will test the software upgrade workflow to recover from consensus failure: Patch Upgrade. The team will trigger a consensus failure deliberately placed in v0.10.2. This bug will cause the network to halt and you need to switch to v0.10.2-patch to make network come back.
Phase Four(Jan.25~Jan.29): In this phase we will try to export a snapshop of blockchain and use it as genesis file for a new chain. This is another type of software upgarade: Restart Upgrade. In this phase, we will first submit a system-halt proposal. If this proposal is passed, Tendermint will stop at certain height. Then, you can export the snapshot or download the new genesis file provided by IRIS team and restart with new version v0.11.0.
Load Test(Jan.29~Feb.3) : we expect to deploy a transaction bot which will push system tps to certain level. We expect TPS to increase from 100 to 500 in following days.

Evolution of Upgrade

The first experiment of runtime upgrade of Fuxi-4000 was very inspiring,but software upgrade in Fuxi-7000 cased the chain to halt. Dev team put many thoughts into creating a more robust upgrade workflow afterwards. IRIShub v0.10.0 contains many breaking changes. Besides the architecture modifications that we have already talked about, the most exciting feature is to redefine software upgrade workflow.

Types of Software Upgrade

Voluntary: When there is a non-breaking path release of IRIShub software, validator could upgrade to newer version and restart their nodes. IRIShub v0.10.1 is good for voluntary upgrade.

Smooth: Runtime software upgrade where Tendermint will collect version signals from block headers and tell if the pre-defined threshold is passed. When the target is met, new logic will be activated.

Patch: When there is a consensus failure, like apphash conflicts, then a patch could be deployed with class III upgrade. Tendermint will replay last block to recover application state.

Restart: When the changes in iris is no longer backward compatible, this type of upgrade is needed. We export a snapshop of blockchain and use it as genesis file for a new chain.

Software Upgrade in Phase II

First, one profiler address held by dev team will submit a software upgrade proposal about upgrading from v0.10.0 to v0.10.2 at Jan 18, 2019.
To get this proposal passed, we need to reach participation of more than 85.72% and more than 83.4% of them vote yes. Then it’s expected that validators begin to install IRISHub v0.10.2 and restart with this new version.

$ iris version
v0.10.2
$ iriscli version
v0.10.2

Your node status will be different:

{"node_info":{"protocol_version":{"p2p":"5","block":"8","app":"1"},"id":"57019a13c2469260eb9033d7b714cc6e664643bb","listen_addr":"tcp://0.0.0.0:26656","network":"fuxi-8000","version":"0.27.3","channels":"4020212223303800","moniker":"test","other":{"tx_index":"on","rpc_address":"tcp://0.0.0.0:26657"}},"sync_info":{"latest_block_hash":"859AD1BD65608AB3E13E1BDF68F03B6D08E2656441CD069FBA171AAAF9DC178D","latest_app_hash":"99024C01117EBA268DAF3BA4638EA2FD34571A6E4F3A24ADD5A4BE903DF8F548","latest_block_height":"32063","latest_block_time":"2019-01-19T06:28:04.668226481Z","catching_up":false},"validator_info":{"address":"","pub_key":{"type":"tendermint/PubKeyEd25519","value":""},"voting_power":"100"}}

As you can see, the app field is bumped from 0 to 1.

The validators will have three days, until block 5000, to do this as indicated asswitch-height in proposal, while Tendermint will collect version signals from block headers afterwards .
At the end of upgrade period, aka. switch-height, if Tendermint tells that more than 70% voting power is using v0.10.2, then this upgrade proposal will be passed and new functions from v0.10.2will be activated.

Verify that this runtime upgrade process is successful by executing the following command to query upgrade information:

iriscli upgrade info

The example output should be like:

iriscli upgrade info --node=localhost:26657
{
  "current_version": {
    "UpgradeInfo": {
      "ProposalID": "0",
      "Protocol": {
        "version": "0",
        "software": "https://github.com/irisnet/irishub/releases/tag/v0.10.0",
        "height": "1"
      }
    },
    "Success": true
  },
  "last_failed_version": "0",
  "upgrade_in_progress": {
    "ProposalID": "1",
    "Protocol": {
      "version": "1",
      "software": "https://github.com/irisnet/irishub/releases/tag/v0.10.2",
      "height": "50000"
    }
  }
}

You should see that in upgrade_config, the version is 1 and ProposalID is that of Upgrade proposal.

To query how many validators have switched to new version, run this command:

iriscli upgrade query-signals
[
  "fca13yrfhk4z5kzs9kqunamtfxrtpver5zvese2udl",
  "fca1wqpkyd68ludlruqtdryzs0ss5dya47m25vawzh"
]

If you forgot to upgrade to a new version, but other nodes has successfully upgrade to new version, then your node will show panic error messages in output logs. But don’t worry, you could still download IRIShubv0.10.2 and start again. Then , you will see the panic messages no more

iris start --home=<IRIS-HOME>

New Function in v0.10.2

The proposer must deposit 30% of the minimum deposit when submitting the proposal

Software Upgrade in Phase III

We will test the software upgrade workflow to recover from consensus failure . In v0.10.2, there is an easter egg🥚: team will trigger a consensus failure deliberately. This 🐞 will cause the network to halt
This bug will stop the system from making new blocks, while patched version of iris will fix the problem and reload the application states. As a validator, you need to switch to v0.10.1-patch to come back live

iris start --home --replay-last-block

If more than 2/3 voting power has switched to the patched version, the network will resume making blocks.

Software Upgrade in Phase IV

First, one profiler address held by dev team will submit a System-Halt proposal about stop the chain at about height #160,000
To get this proposal passed, we need to reach participation of more than 85.72% and more than 83.4% of them vote yes. Then it’s expected that the chain will stop after 20,000 blocks.
After the chain is stoped, dev team export a snapshop of blockchain and use it as genesis file to restart the chain,still named Fuxi-8000. This is another type of software upgrade: Restart Upgrade. All the validators are expected to download. the new genesis and start with new version v0.11.0. If +2/3 validators come online, the new chain will begin making blocks.