Wasmd 0.27 Released
And packed with some long-awaited features!
Wasmd v0.27 is not just another in a series of releases … this is basically feature-complete for a 1.0 release. There is still some code cleanup to do and audits to run before then, but we have managed to tackle a number of user requests and feel closer than ever. Why should you be so excited by this release?
State Sync Support
State Sync allows a new node to join an existing network at warp speed. It doesn’t have to run from genesis, but given a recent header it trusted, it can copy the application state from 2 or more other nodes and verify it against the header. Quickly up and syncing from an on-demand snapshot taken a few minutes ago.
This has been a great relief for validators and infrastructure operators, but it didn’t work for apps that store any state outside the IAVL tree (like CosmWasm and Agoric), and we had been quietly waiting on the core SDK team since it was requested in late 2020. Today, it is available for use in any CosmWasm chain that upgrades to v0.27.
Bringing this to wasmd was a true multi-team collaboration. First, Yi Huang from crypto.org made a great contribution by implementing support in the SDK in February. Marko backported this to the 0.45 branch in late March, and finally, the stage was set for us to implement that support in wasmd. Assaf Morami from Secret Network gave the kickstart in late April by posting a PoC implementation, which was one of the most commented PRs we have had. Ethan Frey pulled those comments into a new PR, with some great feedback from Giancarlos Salas and a review from Yi Huang. And finally, many networks have tested state sync on the v0.27.0-rc0 tag in their testnets.
Many thanks to everyone who made this possible!
IBC V3
While wasmd has been on Cosmos SDK 0.45 since January, we had not yet updated to the latest ibc-go developments. With ibc-go v3 containing Interchain Accounts (ICA) support, the time was ripe to add this in. Along the way, we discovered there was no standard module shipped for the controller side (the side that controls the remote account) and got access to a super helpful demo implementation by the IG team.
Wasmd now ships with a full-featured host (allowing remote chains to control a host locally) as well as the demo controller (allowing any external account to create a remote account, one per connection). We highly recommend that blockchains integrating wasmd research the controller and configure it to their needs, but this provides a nice platform to test on.
While this release allows CosmWasm chains to support ICA, we cannot yet expose and API for CosmWasm contracts to call the ICA controller as there is no standard module we can assume every chain is running. But we did expose the new ibc v3 data types to contracts, so they can take advantage of the full capabilities of v3. And we plan to write an ICA-compatible contract in a month or two, allowing contracts to remotely control accounts on another chain.
Thanks to Jakub Gadikan for pushing things forward with a first integration.
Better Workflow for Permissioned CosmWasm
Since mid-2020, CosmWasm has shipped with an option for permissioned contracts. No one can upload code directly; it must be uploaded by a governance vote. And in that vote, you can set who can instantiate that code: everybody, one account, or only another governance vote. This code works as designed and is tested, but when they ran this in Stargaze, they discovered that not only are such upload proposals very expensive, voting on them takes over 1 million gas. And many voting apps cap the gas amount to far lower than that. This is a big usability problem.
After discussion with Stargaze devs and some reflection, we decided to make a two-tier system. You can either block on the upload (as we did until now), or you could make uploading permissionless and require a governance vote on instantiating a contract. This second vote would be much cheaper to execute than the code upload and would tightly control who could run the code.
Sometimes you do want to let everyone instantiate the code permissionlessly. In this case, governance can vote instead to update the configuration of this code such that everyone can instantiate it. Just one (cheap) gov can open permissions on any number of codes, so if someone uploads 5 DAO DAO contracts, they could all be permitted with one chain governance vote.
This new workflow not only provides much cheaper voting but it provides a number of new alternative configurations. And each chain can choose the model that works best for them. Thanks to Jorge Hernandez from Stargaze for raising issues about real-world usage of permissioned CosmWasm, and pushing PRs to fix some of them.
Get Involved
Like what you see? Let the world know on Twitter or join the discussion on Discord. And remember to follow us on medium to be informed about the upcoming CosmWasm Academy, where you can level up your skills.
And please check out our next Community call on May 17th at 10 am CEST (8:00 UTC) for more early insights and a space to ask questions.
