CosmWasm 2.1
It’s been a few months (around five) since our latest big release, so it’s high time we announced a new version with a lot of new goodies for developers and node operators.
This release has a bunch of changes relating to IBC integration into CosmWasm, but it also adds support for more on-chain cryptography and a bunch of requests by our gold subscribers!
We showed off some of the features at Nebular Summit, so if you want to hear Simon going over them (with a focus on IBC), you can watch the recording (once it’s available).
IBC Callbacks (ADR-8) arriving in CosmWasm!
With this release, we implemented the ADR-8 specification in CosmWasm. It is a generalization of an earlier spec called IBC Hooks.
This primarily allows two new use cases for contracts sending and receiving funds through ICS-20 transfers.
It also applies to other IBC modules, but this is the most common one.
1. Call a contract when the funds are received on the destination chain
This is useful if you want your contract to react to incoming funds, like a contract that burns tokens when it receives them.
2. Get a callback when the transfer was acknowledged on the destination chain or when it timed out
This allows the contract to react to the success or failure of the transfer.
For example, you could transfer tokens to a treasury on another chain and only perform some action if the transfer was successfully received.
Both require explicit opt-in for each message and a new entry point implementation in the contract.
Async Acknowledgements!
In CosmWasm 2.0, we introduced a way to receive a packet without acknowledging it.
While this already allows you to implement IBC protocols that don’t use acknowledgments, it is not that useful on its own.
With this release, we added the ability to send the acknowledgement for a packet at a later time, using the newly-introduced IbcMsg::WriteAcknowledgement.
This allows for more complex protocols that need to execute an action that spans multiple blocks before acknowledging the packet.
One example is the packet-forward-middleware. It forwards a packet to the destination chain, going through multiple hops.
To do that correctly, it needs to wait for the packet acknowledgment of the next hop before acknowledging the packet
to the previous hop.
Functionality like this can now also be implemented in CosmWasm contracts.
secp256r1 verification on chain
And with that the cryptography part of this announcement has begun. secp256r1 (more widely known as NIST P256) is used for signatures all over the place!
More recently, the standardization and widespread adoption of passkeys has increased its usage even further!
We saw that many people are building products that interact with passkeys and their signatures, which is why we added native secp256r1 support to CosmWasm with 2.1.
The goal of this is to hopefully aid with the development and adoption of smart accounts, which have already been discussed at great length in different talks:
Adding this has the benefit of lower gas costs for developers aiming to verify ECDSA signatures on-chain (as opposed to letting those verifications run in Wasm).
Efficient BLS12–381 operations
BLS12–381 is another elliptic curve for which we added support in CosmWasm 2.1.
These types of signatures are most commonly used by Ethereum block headers and the drand project.
So if you ever wanted to write the smart contract of your dreams interacting with either of those, then you’re in luck! You can now do so even more gas efficiently!
The BLS12–381 APIs offered by CosmWasm run natively on the nodes and run in parallel wherever possible, meaning you will get high performance (and therefore low gas prices) out of these functions.
Wasmer upgrade
With the new version we also upgraded the underlying WebAssembly runtime we use: Wasmer.
We upgraded our Wasmer version to 4.3 (4.3.3 to be specific), which fixes a number of bugs that different developers hit while using CosmWasm.
The issues resolved are:
1. Panics on ARM architectures due to ImpossibleReallocation errors
2. Crashes on Alpine 3.19 with a SIGABRT
Especially the second point would have become an issue for a bunch of nodes running CosmWasm if they upgrade their build images to Alpine 3.19+.
We worked with Wasmer to fix this issue upstream and upgraded CosmWasm accordingly, so this issue is fixed for every chain that upgrades to 2.1!
New migration versioning
This is something exciting if you ever needed to migrate a lot of contracts.
This feature was requested by one of our gold subscribers. If you want to see your own feature ideas in upcoming releases, check the end of the article!
With 2.1 we introduce an extension to migrate endpoints. Until now they were simple entrypoints without any other annotations. Well, this changes now!
With the newest version, the migrate endpoint can have an additional annotation indicating the version of the state stored by the contract.
#[entry_point]
#[migrate_version(1)] // This has to start with "1"
fn migrate(deps: DepsMut, env: Env, msg: MigrateMsg) -> Response {
// Logic here
todo!();
}This allows you to tell CosmWasm which version of the state your contract needs. If the number doesn’t change between contract migrations, we intend to simply not run the migrate function in the future.
This saves a bunch of gas if you have hundreds and thousands of contracts to migrate.
Note that what is shipped in 2.1 isn’t the final iteration of this functionality. In future versions, we plan on implementing function-arity and pass you the current version of the state, and other optimizations
Exposing metrics on pinned contracts
Now for a feature that is particularly useful if you operate a node!
This feature was requested by one of our gold subscribers. If you want to see your own feature ideas in upcoming releases, check the end of the article!
Contract pinning in CosmWasm works as a tiered system. Essentially the caching has three tiers:
1. On-disk
2. In-memory through an LRU cache
3. In-memory permanently (pinned)
This metrics improvement focusses on the third tier, which is incidentally the most expensive tier since it costs every node operator memory, which is a lot more expensive than storing things on disk.
Pinned contracts are usually used for contracts that are loaded a lot to improve instantiation times and to spend less time on disk I/O.
But how do we know which contracts we pinned are actually being hit a lot? Well.. until now it was rather hard. Analyzing all executions using a chain explorer or similar tools in fixed intervals and coordinating that with all other node operators.
With 2.1 CosmWasm exposes statistics about pinned contracts in form of Prometheus metrics (PR here). For each contract we expose the metrics of the contract size and the amount of contract cache hits since CosmWasm started up.
This will offer node operators better insights into which contracts should be pinned in memory and which just aren’t worth it.
Quality-of-life improvement for gRPC queries
Before this release you had to manually construct a query and use the rather low-level Querier::raw_query API which isn’t the best UX admittedly.
This release introduces the new QuerierWrapper::query_grpc API which does all this low-level churn for you. All the gRPC, none of the verbose headache.
As part of the Interchain Stack, the ongoing maintenance and some well-defined features are funded by the Interchain Foundation in 2024.
If you have specific needs that you want to see in upcoming CosmWasm releases, consider becoming a CosmWasm Subscriber and help us make the next release possible.
