Comsmwasm v.1.1.0 Upgrade

The following is a summary of the technical detail involved in the Cosmwasm upgrade to v1.1.0, utilizing ‘scenario #4’ which was previously communicated as the recommended upgrade path. Thank you to Frag for the excellent summary.

After the successful chain upgrade to Cosmos SDK v0.45 the L1 team is now continuing work on the upgrade of the smart contracting platform for the chain — the WASM module. We have been working on this item since the first quarter, and are now gearing up for deployment. If we were to start a new chain from scratch (i.e. from Genesis) we would have completed this upgrade months ago, within a very short timeframe. The difficult and complex part of this upgrade is to migrate the state and the data that is currently inside the WASM module to the version of the future WASM module. The following is a summary outlining the migration path that the L1 team is suggesting.

First, let’s clarify what the WASM module actually is so we can read from the same page: The WASM module is a Cosmos blockchain module that implements an interface so users of the blockchain can talk to the WASMVM. The WASMVM is the core piece of software that executes code for smart contracts and stores their execution state. Both the WASM interface and the WASMVM come bundled as a package. The WASM module is responsible for handling/managing the following data:

1. The CodeInfo store that stores a CodeInfo Data structure
2. The ContractInfo store that stores Elements of the ContractInfo structure

The CodeInfo structure stores metadata about each individual code that has been submitted to the WASMVM. The ContractInfo structure stores metadata about each contract — i.e. which code the contract references, the contract address, admin address and so on. From the L1 perspective we can handle the WASMVM pretty much as a black box which is responsible for executing code as well as storing code and execution state of contracts.

When TFL originally implemented the Terra blockchain, they laid out a custom WASM module (a.k.a x/wasm) to enable the chain with a smart contracting platform. Most Cosmos blockchains however do not use a custom implementation for x/wasm. They make use of a production ready reference implementation called wasmd (GitHub — CosmWasm/wasmd: Basic cosmos-sdk app with web assembly smart contracts). Why did TFL use a custom implementation in the first place? Really, we don’t know. We suspect the wasmd implementation was not ready at that point in time when x/wasm was needed.

From a maintenance perspective the L1 team recommends that it’s beneficial NOT to maintain own custom smart contract platform. Instead we would like to use the reference implementation wasmd. Because it saves time, greatly simplifies future upgrades, and should allow for the blockchain to focus on innovation and utility.

X/wasm is somewhat outdated and does only have superficial similarity with wasmd. When you look under the hood and how the ContracInfo store and CodeInfo store are laid out in x/wasm versus wasmd, then you find some major differences:

1. The store keys are different and not compatible
2. wasmd has more complex CodeInfo and ContractInfo data structures some fields introduce indexing redundancy
3. The fields in the data structures have different sequences

We are recommending the following upgrade strategy:

1. Fork wasmd and prune unnecessary data fields from it’s data structures
2. Remove the old x/wasm module
3. Reintroduce the forked wasmd as a replacement
4. Migrate the contents of the x/wasm store to the database schema of wasmd

After successful migragtion the Terra Classic blockchain will have a wasm blockchain module that is compatible with v0.30.0 of the upstream wasmd and that comes bundled with WASMVM v1.1.0.

The following outlines impacts for smartcontract providers, including what is going to work and what is not:

The migration will preserve each contracts

1. addresses, native token balances and admin addresses
2. execution state (i.e. key value store)
3. code

What will not work (without dApp owners updating their smart contracts)

1. The code referenced by the smart contract will (most likely) not be executable anymore within the new version of the WASMVM.

For smart contract providers this means that they will need to upgrade their projects codebase to CosmWasm v1.1.0, upload it and then migrate code and data (this can be done at anytime, and once completed, the smart contracts should function normally). Note that this will NOT be possible, when the contract is SEALED. In this case the smart contract provider will have to manually extract the internal state of the contract and redeploy it on instantiation of a completely new contract. However, this will not preserve native token balances and contract addresses. It should be noted that sealed contracts would be impacted by any and all upgrades, and for those contracts only their owners are capable of updating them.

However, to address the issue of ‘sealed’ contracts, during the migration, and to allow for contract migration post-upgrade, we will set admin=creator if admin==“” — which should result in no “unmigratable” contracts on the chain after migration.

It should be noted that the upgrade of smart contracts to be fully compatible with current versions of cosmwasm is the responsibility of the contract owners. We will aim to provide any assistance we can to existing smart contract owners prior to, and post upgrade/migration to ensure that they are able to update their contracts to be compatible with cosmwasm v1.1.0.

Key Dates

• Complete v1.2.0 upgrade and smart contract unit testing Completed
• v1.2.0 upgrade testing on Bajor testnet May 22nd to May 25th
• v1.2.0 ‘dress rehearsal’ upgrade on rebel-2 testnet May 31st
• Updated agora upgrade proposal posted with test results included May 31st or June 1st
• Post software governance proposal June 7th
• Upgrade to v1.2.0 (parity) June 14th

We are excited to deploy this upgrade to production, and would like to see it run as smoothly as possible. While we felt would could have pushed to reach the May 31st target for ourselves, the timing would have been tight, and we would not have been able to test as much as we would like in order to ensure a smooth upgrade. We feel that the upgrade to v2.0.1 went very well, and would like to ensure that all future upgrades — especially the one to parity are run to the same standard. Again, May 31st was a target date, now June 14th (pending any unforeseen issues discovered in testing) can be considered firm.