I’m the author of this proposal, Billy Rennekamp. I’m the Cosmos Hub Product Lead at Interchain GmbH. My job is to help coordinate and integrate the various contributions to the gaia binary that runs the Cosmos Hub so that it is ready for Upgrade Proposals. This is done with an engineering team at Interchain GmbH as well as support from various Core Contributor organizations like Informal Systems, Iqlusion, Strangelove, Regen, Confio and others. It would be a waste of my time (and others) if significant work is performed preparing an upgrade that includes CosmWasm if the community ends up rejecting the Upgrade Proposal because of its inclusion. To ensure that developer resources are well allocated I’m requesting a signal proposal to determine whether CosmWasm be included in v8-Rho.
Please note: I am not including a signaling proposal for other items on the Cosmos Hub Roadmap at this time because I have not detected as much need for discussion around the inclusion of those features. All features are voted on with the actual upgrade proposal. However, in order to not overload the Cosmos governance system with votes on every decision, I am approaching proposals with an optimistic point of view—meaning I won’t ask for input on items where no large discrepancy of opinion is detected. That said, please review the roadmap regularly and feel free to open signaling proposals or discussion around any item that might deserve to be officially recognized before a final upgrade proposal.
Historical context to this proposal includes a document produced by Cosmos co-founder Jae Kwon called “The Shape of Cosmos” that included a section about CosmWasm and the need for “Hub Minimalism”. The primary point is that CosmWasm introduces complexity risks that should be avoided due to the importance of the Cosmos Hub stay online producing blocks. I believe these risks are adequately addressed by governance gating CosmWasm.
More recently I hosted a Fireside Chat where the topic of CosmWasm on the Hub was discussed at length with CosmWasm creator Ethay Frey, IBC protocol architect Chris Goes, long-time Cosmos core contributor Zaki Manian, Lido representatives Andrei and Kay, and Interchain Funding Manager Sam Hart. A recording of that session is unfortunately no longer available as twitter takes down spaces 30 days after publication.
A summary from my memory of the session (which I encourage others who attended to further add detail) is:
- Ethan Frey, Confio
- His point was that the team had not really added the capacity to own cosmwasm (especially since they seem to want to fork/be independent of our releases).
- And there was no clear plan on how to use cosmwasm besides Lido contracts and maybe copying over daodao from Juno
- I suggested that if a serious chain wants cosmwasm, they should have capacity internally that knows how to integrate/debug it. And they should have a plan that involved of deploying multiple contracts to utilize it
- Osmosis is working with multiple teams to add features. Stargaze as well. Nym has built out many contracts there (using vanilla wasmd and doing all app dev in Rust). Juno obviously built a large community like Archway plans.
- Adding cosmwasm should go along with an in house team dedicated to build contracts, or agreements with multiple external projects to deploy on your chain.
- I heard no other use case on the roadmap besides Lido.
- Basically, build up a bit more plan/capacity first
- Chris Goes, Anoma
- Clarified that the proposal it is not necessary to use CosmWasm to facilitate IBC client updates although there may be some overlap in use of lower level WASM components.
- Generally encouraged the Hub to be less risk averse in adopting new technology and features
- Zaki Manian, Iqlusion
- Pro-CosmWasm for enabling easier deployment of functionality on the Hub.
- He views cosmwasm as key to establish ATOM at the center of the Cosmos liquid staking world and it would block deployment of the iqlusion liquid staking module if cosmwasm wasn’t available
- Andrei and Kai, Lido / P2P
- Strongly in favor as Lido has hopes of deploying Liquid Staking contracts to the Cosmos Hub and making the Cosmos Hub the center of activity for Liquid Staking of ATOM as well as other IBC staking assets
- Sam Hart, Interchain GmbH
- potential to decouple aspects of hub dev from integration team
- new IBC app dev is increasingly going to happen there, which we will likely want exposure to
- I want to centralize stack dev on the hub and cosmwasm is now part of the typical stack
I am also in favor of having CosmWasm on the hub but it’s worth outlining the benefits and the drawbacks. It is ultimately up to the ATOM holders to decide which Gaia binaries are used to operate the network—and by extension what code is included in those binaries. What follows is my summary of the benefits and drawbacks.
- Lowering the Burden on Validators and Maintainers for New Cosmos Hub Features
The most important reason to include CosmWasm on the hub, in my opinion, is that it lowers the barrier to contributing code and features to the Cosmos Hub. Currently, new features come in the form of Cosmos SDK modules and most of these modules are created and maintained by Cosmos SDK contributors at Regen network and other Core Contributor organizations. Other modules are created and maintained by other Cosmos Core Contributors like the IBC router middleware by Strangelove Ventures, IBC and Interchain Accounts by the IBC team at Interchain GmbH, the Liquidity Module by B-Harvest and the upcoming Liquid Staking modules by Iqlusion Inc. Today it is the job of the Cosmos Hub team at Interchain GmbH to review, test, and integrate these modules before releasing a new version of Gaia and then coordinating the network upgrade via validator communication with assistance from Cosmos Core Contributor team https://hypha.coop.
A software release and upgrade includes launching and running a public testnet to simulate the upgrade proposal with a validator set from the Cosmos Hub and chain state that mimics the live Cosmos Hub. Finally, all validators of the Cosmos Hub need to prepare for the upgrade and take measures to update their nodes at the right height or configure Cosmovisor to run the upgrade process automatically. Improvements to the release process of the Cosmos Hub executed by the Cosmos Hub team at Interchain GmbH, Cosmovisor, other Cosmos Hub Core contributors, and validators has greatly reduced the work involved in this process, however it is still a significant amount of work for all parties involved.
With CosmWasm on the hub, it’s possible for anyone who writes a smart contract to add functionality to the Cosmos Hub. CosmWasm on the Hub should be governance gated, as previously mentioned, and means that no code will make its way onto the hub that doesn’t go through a governance proposal. This means that it won’t be possible for malicious or spammy code to be uploaded to the Cosmos Hub without the approval of ATOM holders. But it also means the elimination of large coordination tasks between Cosmos Core Contributor organizations and all validator and node operators aside from the time it takes to vote.
- Lowering the Barrier for Contributions
With CosmWasm expanding as a popular format for designing and creating decentralized applications we’ve seen standards emerge like CW20 (fungible tokens), CW721 (non-fungible tokens), and standard deployments of DAOs like DAODAO. All of these contracts, as well as the growing number of functionalities, would become possible to deploy to the hub. Of course, community discussion about what actually belongs on the hub should still take place, however, the question of inclusion is about Cosmos Hub as a product and not an engineering one.
It will also make it possible for smaller features that may not deserve an entire upgrade to make their way onto the hub. For instance a convenience app, like profit splitting, could be simply created and deployed to the hub. Or, a simple OTC app that holds some tokens and exchanges them for exactly some other amount of tokens. These could be created as Cosmos SDK golang modules but having more than one way to deploy functionality will lower the barrier to the types of functionalities that can make their way to the hub (again these will nonetheless be rigorously considered via governance before being deployed).
- Burden of upkeep
As CosmWasm creator Ethan Frey pointed out in the Twitter spaces, it is a not-insignificant amount of work to maintain compatibility with CosmWasm. While Confio, funded by the Interchain Foundation, maintains and improves CosmWasm as a public good, they take a conservative approach to following the Cosmos SDK release cycle. The Cosmos Hub could eventually rely solely on version maintained by Confio, but in order to use Cosmos SDK v0.46 in the Rho upgrade (with the Groups Module, updates to Gov, and other fixes and improvements), a fork of CosmWasm must be made compatible with v0.46. Notional labs has already created one and Lido has been using it as a starting point to begin testing CosmWasm with Liquid Staking. Lido, and the P2P team (long time Cosmos validators and contributors) have agreed to update and maintain CosmWasm for v0.46 compatibility in light of their desire to see CosmWasm on the hub. Thanks to this commitment and the longer term ability to use the Confio maintained version, I don’t think it’s an insurmountable burden and on behalf of the Cosmos Hub team at Interchain GmbH, I think it is technically feasible to include CosmWasm in the Rho upgrade.
- Short term compatibility concerns
CosmWasm does not run on Windows machines and has only experimental support with ARM architecture. There are much fewer downloads of the gaia binary for Windows and ARM architecture than for AMD linux and darwin as seen in this analysis. However it’s not yet confirmed how large of an impact or overhead this would have on current validators or node operators at wallets, exchanges, block explorers, data providers or other integrators. I’ve posted in the validator verified discord and in separate chats with validators and node operators and have not yet found any that would be significantly impacted by this. I’ll continue to update this post with results as they come in.