There is prior art to this discussion with a previous proposal with lots of thoughtful comments here. This proposal passed in Summer of 2020. It’s interesting because it is for specific development work but also implies that the hub would adopt this work eventually. One comment that I think is relevant to the discussion I’d like to use this post for comes from Ethan Frey. In response to the cost of his original proposal to support CosmWasm on the hub he had updated information:
That means, that after this proposal, and completion of that grant, the hub should have all the foundations they need and have no requirement to offer more payment to CosmWasm. That said, the two clear proposals I could see in the future are developing particular contracts to run on the hub, and adding support for another language for smart contracts.
We’re at a point where CosmWasm is again being considered for the hub based on 3 factors.
Liquid Staking
Zaki has recently completed work on a native Cosmos SDK liquid staking module. This design makes it possible to convert an ATOM delegation to a voucher for that specific ATOM delegation. These vouchers are not fungible between each other. However they are transferrable, which means that there can be application abstractions above these primitives which allow for the creation of a new fungible asset in exchange for these vouchers. This is how Lido approached liquid staking on Terra. Lido is one possible user of these liquid staked assets, and would create CosmWasm smart contracts that accept these vouchers and create the new fungible derivative. These smart contracts ideally have access to the native staking module of the Cosmos Hub in order to assess the reliability of the underlying delegations (they could for instance be slashed and no longer worth 1:1 with the voucher). As such in order to launch this staking derivative project, the Cosmos Hub would need to have CosmWasm smart contracts, that could be governance controlled in order to avoid rampant application development on the hub that would cause state bloat and a possible conflict between the various applications deployed as a result (goes against the benefits of being application specific and hub minimalism).
DAO Interfaces
There’s recent discussion about launching an IBC DAO to improve the business viability of IBC relayers as well as diversify the sources of funding for IBC development beyond the ICF. Initial proposals for how this DAO would work is that it would be funded by various community pools and foundations of networks beyond the Cosmos Hub that depend on IBC. One of the product pillars of the Cosmos Hub is Public Goods. As such it would be a good candidate for the host of the IBC DAO to coordinate its public goods activities. In order to do so, proper DAO interface needs to be available for the IBC DAO on the Cosmos Hub. The current options are Groups Module (scheduled in late Q1 or early Q2 in the Cosmos SDK v0.46 release) or using the DAO DAO CosmWasm implementation. If the Hub Adopted CosmWasm in an accelerated timeline, it may make it possible to support the IBC DAO in a faster timeline than waiting for Groups module to ship.
IBC Light Client Upgrades
Early design and roadmaps for IBC include the ability to upgrade light clients as breaking changes in consensus are created. For instance, Tendermint v0.35 will be included in Cosmos SDK v0.46 in late Q1 or early Q2. However Tendermint v0.37 will have consensus breaking changes, which means there will be a new light client for blocks produced using Tendermint v0.37. All IBC connections that use clients of the prior version of Tendermint will need to be updated to the new version in order to continue moving packets. This can be done via governance (there’s a proposal type to set a new client per connection). This could also be done automatically if the light clients in question were both implemented as WASM blobs. It will be a very large and complicated coordination problem to update the entire IBC Interchain to new clients, while maintaining backwards compatibility. The problem will be made easier if WASM clients are widespread.
PLEASE NOTE: IBC does not use CosmWasm in this scenario. It’s more of an orthagonal conversation that IBC will include WASM as a dependency and have it’s own system for deploying WASM blobs that doesn’t use CosmWasm virtual machine or the
wasmdModule of the SDK. This item is listed here mostly because CosmWasm is often erroneously identified as the IBC light client upgrade solution.
To kick off this conversation I’ve arranged a Twitter Spaces, part of the new Cosmos Hub Weekly Fireside Chat on the https://twitter.com/cosmoshub twitter handle. It’s scheduled for:
Feb 16, 2022 at 6pm CET (5pm UTC)
Invited participants are:
- Billy Rennekamp / Cosmos Hub Lead / Interchain Foundation
- Zaki Manian / Cosmos Contributor / Iqlusion and Sommelier Founder
- Ethan Frey / Cosmos Contributor and Creator of CosmWasm / Confio and TGrade
- Chris Goes / Cosmos Contributor and Author of IBC Spec / Heliax and Anoma
- Sam Hart / Funding Manager / Interchain Foundation
- Kai Tiurin / Cosmos Contributor / Lido and P2P
The call will end with a call to action to bring the discussion here. Hopefully we can also get a synopsis posted here after the call and a link to the recording.
Questions to be answered in the discussion or in this thread
- What are the benefits and drawbacks of CosmWasm on the Hub?
- How does this change the product offering of the Cosmos Hub?
- How does this change the development requirements of the Cosmos Hub?
- Will this enable short term gains that have long term negative impacts on the Cosmos Hub?
- How does this feature compare to other features and their priorities?
- How does this impact the ability for Cosmos Hub contributors to deliver on other Cosmos Hub products?
(I encourage others to post questions here that can be discussed on the call tomorrow, and furthermore in this thread)