CosmWasm 1.4
The latest feature release of the CosmWasm stack strengthens stability, security, and performance but also brings some exciting new features for contract developers and node operators.
Highlights of this release
Wasmer 4 upgrade
Wasmer is the engine that executes WebAssembly inside of CosmWasm. For a long time we used Wasmer 2.x while working on an upgrade to Wasmer 3 and Wasmer 4. Since Wasmer is tightly integrated into the entire cosmwasm-vm codebase, the huge API refactoring was a big challenge. But we made it, leading to a better overall codebase. Keeping up with the latest Wasmer ensures we have access to the latest advances in terms of performance and bugfixes.
Part of the refactoring led to a ~50% decrease in the elements in in-memory caches. This means that twice as many contracts can now be cached, leading to faster startup times.
New db_next_key / db_next_values imports
Before 1.4, iterating the storage always required to load both the full key and value from the store and copy them into Wasm. In cases where you only need the keys or only need the values, this leads to unnecessary gas consumption. A typical use case is deleting all elements in a range, for which you only need the keys.
The new imports are available through the Storage::range_keys and Storage::range_values functions. Also, the skip function on storage iterators now utilizes db_next_key to be more efficient.
Customizable debug handler
The debug handler of the VM is a function that defines how calls to dep.api.debug("some msg") (Api::debug) are processed in the host. So far, those messages were just written to STDOUT. Now the host can change the behavior and get additional information like gas remaining. Some use cases now possible are:
This opens up the possibility to do full stack benchmarking of Wasm execution embedded in a chain. To use set_debug_handler, you need access to a cosmwasm_vm::Instance, which you get in integration tests and in libwasmvm. By default, libwasmvm now logs time and gas remaining to STDERR. For customizations, you currently need to fork libwasmvm.
Decimal256 -> Decimal conversion
By implementing TryFrom between Decimal256 and Decimal, we complete the conversion map for the unsigned numbers:
Iterating through Coins
The Coins container type was introduced in 1.3. It ensures the uniqueness of denoms and allows basic mathematical operations on the container, such as adding a Coin to a set of Coins.
Now you can efficiently iterate through Coins and get elements of type Coin without having to call to_vec first. Iteration is always ordered by denom.
StdAck
StdAck is a simple acknowledgment type that follows the ICS-20 and ICS-27 specs. It is either success or error and holds binary success data or an error string. At a lower level, it is JSON encoded. In https://github.com/noislabs/nois-contracts/pull/279/files you see how StdAck can be used in an IBC contract. If you don’t need a complex acknowledgment type, it is recommended to use StdAck as a layer around application-specific success data. Non-binary results or structured error types cannot be modeled with that and require a protocol-specific acknowledgment design.
Queries for the distribution module
The new query types DistributionQuery::{DelegationRewards, DelegationTotalRewards, DelegatorValidators} allow more powerful contracts that stake to validators.
Compatibility & migration
Contracts using cosmwasm-std 1.4.0 can be deployed to all CosmWasm 1.x chains. By enabling the cargo feature cosmwasm_1_4 you unlock features that are only available on 1.4 chains.
CosmWasm 1.4 will be available in wasmd 0.42 (Cosmos SDK 0.47 compatible). Please note that it won’t be backported to wasmd 0.3x (Cosmos SDK 0.45 compatible).
