Governance-backed Runtime Software Upgrade on Fuxi-4000

Attention!

Highlights:

Fuxi-4000 upgrade schedule:

  • Dev team will submit software upgrade proposal at Nov. 21
  • If this proposal was passed, Validators of Fuxi-4000 have to upgrade to v0.6.2 and then send a submit-switch transaction
  • Wait for 95% threshold
  • New iService functions in v0.6.2 will be activated

IRIShub Architecture

At Nov 1, IRIShub dev team published a new release v0.6.0 and launched the latest testnet: Fuxi-4000. Learn how to join the testnet here: https://medium.com/irisnet-blog/how-to-join-irisnet-testnet-fuxi-4000-8ff569e029fa. IRIShub v0.6.0 contains many breaking changes.

IRIShub Architecture

As shown in the diagram above, IRIShub is built upon Cosmos-SDK, which is a blockchain development framework. It’s designed as a developer-friendly toolkit for building application-sepcific blockchain on top of PoS BFT consensus engine: Tendermint. The key features of Cosmos-SDK is its modularity. Anyone can create a module for the Cosmos-SDK and integrating the already-built modules is as simple as importing them into your blockchain application.

IRIShub inherits some existing modules in Cosmos-SDK, namely Auth, Bank, Staking, Slasing & Distribution. The team modified Gov and Param modules to support specific functionalities. Meanwhile, the team developed two brand new modules: Record and iServiceto build a framework for next-gen distributed business applications.

One of the vital purposes of Fuxi-4000 is to test the in-protocol software upgrade process. The dev team looks forward to a successful upgrade to v0.6.2 with the help of IRISnet validator community. But first, let’s talk about the meaning of upgrading blockchain software.

Power of Upgrade

IRISnet believes in the power of evolution of blockchains. Any codebase will always contain certain level of bugs and meanwhile, developers will introduce new features someday. On-chain governance gives all stakeholders a chance to implementing changes to protocols. Since v0.6.0, IRIShub supports major upgrades or patches in the source code.

  • Transparent Process:making decisions about how to upgrade them is increasingly important. These are decisions that may affect millions of people and should have high standards of clarity and accountability .With on-chain voting governance module, this can be provided.
  • Backward Compatibility: The Upgrade module provides backward compatibility. All historical data on the blockchain will still be queried and verified afterwards. This mechanism provides more flexibility.

Upgrade Workflow In IRIShub

Upgrade Workflow
  • First, the dev team will submit a software upgrade proposal about upgrading from v0.6.0 to v0.6.2 at Nov. 21.
  • After getting this proposal passed, we expect every validator to install IRISHub v0.6.2 and run the new version. Please note you should use the new version of iris & iriscli
$ iris version
v0.6.2
$ iriscli version
v0.6.2
  • Then, the validators will submit a submit-switch transaction to demonstrate they finished upgrading. The community will have 57600 blocks ~ three days to do this.
iriscli upgrade submit-switch --from=$VADDR --proposalID=N --chain-id=fuxi-4000 --fee=0.05iris --gas=20000
  • After 57600 block, if more than 95% voting power have submitted a submit-switch transaction , this upgrade will be successful and new modules from v0.6.2 will be activated.
  • Verify that upgrade process is successful by running the following command to query upgrade information:
iriscli upgrade info

The example output should be like:

{
  "current_proposal_id": "-1",
  "current_proposal_accept_height": "84571",
  "version": {
    "Id": "1",
    "ProposalID": "16",
    "Start": "10000",
    "ModuleList": [
      {
        "Start": "0",
        "End": "9223372036854775807",
        "Handler": "bank",
        "Store": [
          "acc"
        ]
      },
      {
     ........

You should see that Id is 1 and ProposalID is that of Upgrade proposal.

  • If you forgot to upgrade to a new version, but other nodes has successfully upgrade to new version, then your node will exit for appHash conflict. But don’t worry, you could still download IRIShubv0.6.2 and run the following command to activate switching logic:
iris start --replay --home=<IRIS-HOME>

New Function in v0.6.2

IRIS Service Definition & Binding

In v0.6.0, IRIS service definition is implemented. A service provider could define its own service and publish the definition on IRIShub.

IRIS Service Definition & Binding

The Interface description language (IDL) we used is a service standardized definitions to make service invocations across different programming languages possible. Tags and descriptions will be defined to services. For example:

iriscli service define --chain-id=service-test  --from=x --fee=0.004iris --service-name=test-service --service-description=service-description --author-description=author-description --tags=tag1,tag2 --file=test.proto

The currently supported IDL language is protobuf.Then, users could query all existing services:

# service query
$ iriscli service definition --def-chain-id=fuxi-4000 --service-name=test-service

Service Binding

In v0.6.2. it’s possible to bind a service to a defined IRIS service. Service binding will hook some resources and point it to one existing service. There are some important metrics like: Type, Deposit, Prices, and Response Time.

For example:

iriscli service bind --chain-id=service-test  --from=x --fee=0.004iris --service-name=test-service --def-chain-id=service-test --bind-type=Local  --deposit=1iris --prices=1iris --avg-rsp-time=10000 --usable-time=100

After some time, more fund could be deposited on this service. The operator could also disable the service.

More info here: https://github.com/irisnet/irishub/blob/master/docs/features/service.md


1

1 clap
Sophie Huang

Written by

Blockchain | Data Science | Cosmonaut https://www.flyovercrypto.space