Swiss booklet: Proposal 69 (Include CosmWasm in Rho Upgrade)

Thanks to Sam Hart for the extensive discussions and for encouraging me to write this up.

Motivation

Amidst all the drama and confusion around Proposal 69 it has become apparent to me that the Hub needs an equivalent to the Swiss direct democracy handbook if it is to flourish.

The challenge here is to provide clear and succinct answers to every question that a reasonable Cosmonaut might have regarding a proposal, regardless of their level of education or knowledge.

If Cosmos is to succeed as a democracy we need every citizen to be able to understand the question they are voting on, even if they are not familiar with the subject.

While the forum is an essential part of the puzzle, it doesn't simplify things enough for those who aren't already in the know (too much background knowledge is assumed). And while twitter is great for spirited debate, it's a mess for synthesising information.

This is an attempt at an MVP of a Swiss booklet for prop 69 (I will continue to improve it throughout the week). My hope is that we move towards a Cosmos in which we publish such a booklet for every upgrade proposal well in advance of the vote (as well as perhaps a shortened version for param change proposals). If you have any thoughts and/or recommendations please reach out to me on twitter (@ssaintleger) – my DM's are open.

The question

Should CosmWasm be included in the Rho Upgrade?

FAQ

What is CosmWasm?

CosmWasm is a project which enables WebAssembly (WASM) virtual machines (VMs) in the Cosmos SDK.

It's written as a module that can plug into the Cosmos SDK. This means that anyone currently building a blockchain using the SDK can quickly and easily add CosmWasm smart contracting support, without needing to add any extra logic.

Why WebAssembly (WASM)?

Adding WebAssembly to the Cosmos SDK allows software written in many languages to run securely on a blockchain. WASM serves as an intermediate language that compiles the developer’s language of choice into a portable virtual machine.

At a more technical level, WASM is a near-machine-level virtual machine designed for restricted memory allocation and isolation. It doesn't prescribe how the higher-lever programming language on top of it should work, because it's designed to accommodate any language.

The tradeoff here is that work needs to be done to make this WASM machine accessible to the developer. CosmWasm provides this glue by initially making it possible to program in Rust, but more languages with support for the WASM build target are expected to gradually become available.

What is the Rho Upgrade?

The Cosmos ecosystem is growing rapidly and the Cosmos Hub is making steady progress on its journey to become a service provider for the Interchain. Part of that journey includes regular upgrades with new features that lay the groundwork to fulfill the port city vision.

If you look at the official Hub roadmap, you'll see that the current upgrade cadence is about one upgrade every quarter (four per year). The last upgrade was Theta – which represented the first big step toward Interchain Accounts. Rho is the name given to the next upgrade (expected end of May / early June).

Rho completes the Interchain account story, and includes other features such as Groups, which together with Interchain Accounts allows DAOs to natively interact with other Interchain Accounts enabled chains. With Groups, DAOs will be able to manage funds across multiple blockchains while only having to interface with the Cosmos Hub.

Depending on the answer to Proposal 69, Rho may also include permissioned CosmWasm.

What is permissioned CosmWasm?

In contrast to permissionless CosmWasm which allows anyone to push code to the blockchain without review, permissioned CosmWasm requires each contract added to the Hub to be voted on by governance. The amount of eyes present on each proposal adds a strong level of security compared to the permissionless approach.

Why is a governance vote needed for CosmWasm but not the Groups module?

While all features are voted on during the actual upgrade proposal, CosmWasm is a particularly divisive topic. As such, it merits its own separate discussion. In Cosmos Hub lead Billy Rennekamp's words:

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.

What are the main benefits of having CosmWasm on the Hub?

Permissioned CosmWasm would allow for new functionality to be added to the Hub without changing the codebase of the blockchain itself.

Currently, changing the Cosmos Hub application involves changing the codebase and having all the validators switch to this code. This requires a complicated software upgrade process, co-ordinated by the Hub team, to ensure all validators move to the new code at the same time.

CosmWasm on the Hub would allow anyone to submit a piece of code to the chain and ask for a governance vote to execute the code. If governance approves, the code goes on the chain and just runs. No need to ask validators to change their software.

This means that anyone (not just the Gaia repo maintainers) can change the functionality of the Cosmos Hub at any time so long as they have governance approval. Put another way, it introduces a new path for adding features to the Hub that isn’t dependent on the Hub team’s development cycle. This in turn frees up the team to think more creatively about what the Hub needs to flourish over the long-term and help prioritise and ship those features.

What are the main drawbacks of including CosmWasm on the Hub?

Since CosmWasm makes it easier for developers to add features to the Hub it requires governance participants to play a greater role in checking the security and purpose of the proposed code/contracts. If governance participants are not well-equipped to do so, malicious and/or exploitable code could make its may onto the Hub.

Even though CosmWasm is currently being battle-tested on Terra, as well as several other chains, one cannot escape the fact that more features = more complexity = more risk. The CosmWasm audit reports are still not public, and while no funds have been lost on any major chain so far, it's important to keep in mind that CosmWasm is still a relatively nascent technology.

In the words of Simon Warta (CosmWasm's maintainer in chief):

The most risk is in edge cases. An attacker needs to understand the inner workings of a bug and craft a contract specifically to execute a very specific code path with very specific data.

A counterpoint to this is that anything running in CosmWasm is running in a sandbox, which keeps CW in its own area, and away from the core logic of the chain. The same cannot be said for the Cosmos SDK. This means that pushing the same feature through the SDK rather than CW is arguably riskier.

Who maintains CosmWasm?

Confio is the company behind CosmWasm. They were one one of a number of projects to receive a grant from the Interchain Foundation to build a virtual machine on top of Tendermint. As such the Interchain Foundation has funded most of the development work to bring CosmWasm to production (Terra, Juno and others have also supported CW development financially).

Who is already using CosmWasm in production?

There are 8 IBC chains currently using CosmWasm on mainnet (including Terra, Osmosis, and Juno). CW is being collectively used on chains that have $40-50bn of value and has been production ready for more than two years.

Has CosmWasm been audited?

Yes. The Interchain Foundation have audited and tested several pieces of CosmWasm. However audits are arguably of limited value compared to code walkthroughs with knowledgeable core teams.

Perhaps better evidence of CosmWasm's safety is the fact that Terra, which has been running CosmWasm for over a year with billions of dollars on the line, has yet to suffer a serious exploit.

Will CosmWasm increase the Hub's complexity?

Complexity is created by features. Avoiding it means saying no to new features. This is a reasonable position to take.

If you do care about features on the Hub, implementing them in CosmWasm is already more convenient and safer than in SDK code. The reasons are better APIs, the sandbox, and Go's lack of type safety.

However, it's probable that CosmWasm will indirectly increase the Hub's complexity since making it easier to push features means more features will probably end up being shipped.

Have there been any CosmWasm bugs in the past, and how would they have affected the Hub?

It's important to emphasise that under this proposal CosmWasm won't run in a permissionless manner on the Hub, which means that it would not have been affected by the majority of security vulnerabilities found so far.

However this doesn't mean that permissioned CosmWam is completely immune from bugs. As with any piece of software, zero-day vulnerabilities are always possible. One important advantage with permissioned contracts is that you have a complete list of contracts that can quickly be checked should a vulnerability be found. Knowing what is running is extremely valuable in that it allows you to quickly analyse the severity of the bug and take the appropriate response.

It's hard to say how a past exploit would have affected the Hub, without specifying exactly which contracts would have been running on the Hub at the time of the exploit. If the recent Juno incident has taught us anything though it's that reacting quickly to published issues is of paramount importance – the issue that caused Juno to halt on April 5th was first found, and quickly patched, 6 weeks earlier on Terra; with a formal fix released as part of wasmd 0.24.0 on Marth 9th. If the Juno team had moved quicker to patch this known issue they would have avoided a chain halt. The lesson from this is that it pays to react quickly. Perhaps the most important step the Hub team can take is to increase their in-house CosmWasm expertise in order to ensure they can respond quickly and effectively to any issue which may arise.

Note: The CosmWasm security policy is documented here and the issues are tracked here.

What's the first feature CosmWasm is likely to unlock for the Hub?

If Proposal 69 passes, the first feature added to the Hub will in all likelihood be liquid staking. Lido is expected to be the first to offer such a feature.

What is liquid staking?

The main idea behind liquid staking is to enable cosmonauts to stake without losing access to the liquidity of their tokens.

This is done through the issuance of a tokenized version of the staked funds — a derivative of sorts — which can be transferred, stored, spent or traded as one would a regular token.

For example, If Proposal 69 passes, and Lido were to launch their liquid staking offering on the Hub, cosmonauts would be able to stake any amount of ATOM, receive stATOM in return, and then use that stATOM for lending, collateral and more, all the while still earning daily staking rewards.

What are the potential upsides to liquid staking?

The main potential upsides are:

• Lower opportunity cost: With a fully liquid derivative token, cosmonauts can freely participate in DeFi and generate another layer of rewards on top of staking yields. You don’t have to choose between staking or depositing their liquidity into an AMM, lending protocol, etc. You can do both!

• Higher economic security: Without staking derivatives, we might expect 60-70% of ATOM to be staked. However, with staking derivatives, this number could be as high as 80-100%, because there is no additional cost to staking compared to non-staking.

• Takes power away from large exchanges: Exchanges represent some of the largest ATOM holders, and exchange staking is likely to make their ATOM holdings even larger.

• No unbonding period: Since derivative tokens can be immediately swapped for their underlying staked assets, users don’t have to wait for the regular unbonding period to unstake their tokens.

• Automatic diversification across multiple validators: diversification minimizes exposure and serves as slashing insurance against the misbehaviour of any one validator.

What are the potential downsides to liquid staking?

Liquid staking has the potential to undermine the ability of a blockchain to slash bad actors, and create new centralised points of failure.

There are smart people who believe the game theory around liquid staking leads to a winner-takes-all outcome. Lido's dominance on Ethereum adds weight to this hypothesis so far. If a single liquid staking token were to dominate the market on Cosmos this would have less than desirable consequences.

For example, in a winner-takes-all scenario in which Lido's contract ends up with a majority of ATOM under management, the Lido DAO would be the largest ATOM shareholder; if this happens LDO holders could be able to effectively determine the Hub validator set.

If a single liquid staking project were to dominate the market and abuse its position, what backstops do ATOM holders have?

The backstops are as follows:

• The holders of the derivative token could choose to exit into native ATOM

• Cosmonauts could make a concerted effort to buy up ATOM and stake outside of the said project

• Cosmonauts could co-ordinate to replace the staked ATOM in the liquid staking contract through a hard fork

Is liquid staking inevitable?

Staking derivatives are probably subject to similar market realities as MEV extraction, in the sense that their existence is likely inevitable. As long as there is a private benefit to creating and using them, they will exist and flourish. However, if the right solutions win and are sufficiently adopted, it could lead to systemic benefits for Cosmos too.

We probably can't escape the fact that someone will create a much less secure solution if we don't make it easy to use the ones that are secure. Cosmonauts want capital efficiency, good UX, and optionality with their tokens. There's no escaping the need for someone to meet this demand.

As a thought experiment, in the extreme scenario in which Lido controls 100% of the staking market and the validator set depends on Lido, is this necessarily a worse thing than Binance and Coinbase being the majority controllers? Exchanges already offer pseudo-staking derivatives, which pass yield to their customers. They have a lot of flexibility in their offerings. In comparison, Lido is already non-custodial and permissionless and has publicly committed to decentralising themselves.

Does it have to be a winner-take-all market? What makes Cosmos different to Ethereum?

In an ideal interchain we have multiple liquid staking providers that compete and keep each other in check. This, however, requires sufficiently differentiated solutions.

While the winner in staking derivatives seems to be following a power law on Ethereum, it's possible that Cosmos' multi-chain + on-chain governance environment changes the dynamics somewhat. In particular, there may be more room for differentiation in an ecosystem in which sovereign communities have control over consensus.

Without going into too much detail Lido, Quicksilver, and Osmosis (through Interfluid staking) are all expected to offer sufficiently different product offerings in the coming months.

For example, in contrast to Lido which is expected to use a whitelist of validators for delegation, Quicksilver will operate with an unrestricted validator set. While we won't get into the nitty-gritty here, these approaches make different tradeoffs which have the potential to satisfy different types of Cosmonauts.

Osmosis' Interfluid staking can be thought of as reverse liquid staking, and offers an interesting alternative to both Quicksilver and Lido. Instead of creating synthetic representations of staked assets (as with regular liquid staking), Interfluid staking allows staking tokens already being used in DeFi to be staked. If you're familiar with Superfluid staking, Interfluid staking is essentially Superfluid staking for the other side of your LP position (for example, the ATOM side of ATOM/OSMO). Osmosis is currently working on a module that enables other chains to determine how much of their asset is kept in the relevant liquidity pool over time. They can then use that pool to secure their own chain, subject to slashing if the validator misbehaves.

Is CosmWasm on the Hub needed for liquid staking?

No. We don't need CosmWasm on the Hub to enable Interchain liquid staking functionality across the Cosmos ecosystem. But we do need at least one of either CosmWasm or Interchain Security (IS) to do it safely. While the core liquid staking module provides a simple primitive that anyone can use to build staking derivative products, without IS or CW on the Hub, such products will have to be built on external chains. This introduces important security concerns.

Quicksilver, for example, is not expected to deploy on the Hub, but as a shared-security zone that will initially be secured by the Hub's validators – this means it has a dependency on Interchain Security.

This semi-sovereign approach may have subtle tradeoffs however. On the plus side it allows for experimenting with more complex modules without burdening the Hub. On the minus side, it may be slightly harder for ATOM holders to ensure that a shared-security zone remains fully accountable to the Hub over the long-term (since the validator sets may diverge over time).

What is Interchain Security?

Interchain Security is the Cosmos solution to shared security. At a more technical level, if you think of shared security as a family of technologies that include optimistic rollups, zk-rollups, sharding, and Interchain Security, then Interchain Security is the Cosmos-specific category of shared security that uses IBC (Inter-Blockchain Communication).

At a very high level, Interchain Security allows for a provider chain (like the Cosmos Hub), to be in charge of producing blocks for a consumer chain (any app chain which wishes to lease security from the Hub validator set). It does this by sharing the set of validators who are in charge of producing blocks. Under IS, the participating validators run two nodes, one for the Cosmos Hub and one for the consumer chain, and receive fees and rewards on both chains.

There are two primary reasons that Interchain Security is valuable to the Cosmos Hub. The first reason is that it allows for “Hub minimalism”. The second is that it lowers the barrier to launching and running secure and sovereign blockchains, which in turn increases the reach of the Cosmos ecosystem.

What is Hub minimalism and how does Interchain Security allow for it?

Practical Hub minimalism is the strategic philosophy that the Cosmos Hub should have as few features as possible in order to:

1. Decrease the surface area for security vulnerabilities
2. Reduce the chance of a conflict of interest between user groups

In the words of Billy Rennekamp (Cosmos Hub Product Lead):

A hub minimalist might be against a name-service module being on the same blockchain as a DEX protocol, for example, since users of the name-service module must now accommodate users of the DEX even when they have different interests. At best, divergent user groups can peacefully coexist and, at worst, differences may result in hard forks that diverge in the features of an application.

The current Cosmos Hub is adding more features, which carries some of the risks that hub minimalism is concerned with. Should Interchain Security become available, it would be possible to satisfy hub minimalists by allowing for each distinct feature of the Cosmos Hub to be an independent chain that is validated by the same set of ATOM-delegated validators. This way, the operation of each function could occur independently without affecting the operation of other ATOM-secured hub-specific applications. These separate consumer chains may even want to have their own token for governance, fees or other application specific uses that could furthermore be used to pay provider chain validators for their services.

When will Interchain Security launch?

Interchain Security is expected to launch in August of this year. Anyone who's been in this space long enough however knows that complex features like IS can take a lot longer to ship than expected. For reference, the Cosmos Hub took a year or two longer than expected, the Cosmos SDK took a year longer, IBC two years longer.

Given this, it might not be prudent to bet all of the future product success for the Cosmos Hub on a product that is still under development.

Even when Interchain Security launches, it won't be feature complete. Much like IBC, it will take years of iteration to unlock the full spectrum of possibilities.

What other features can CosmWasm unlock for the Hub?

The leading candidates for Hub applications are a name service and things related to interchain DAO coordination: for example CosmWasm could unlock the ability for a non-multisig DAO on the Hub to house all of the funds from the Cosmos chains that are contributing to core development (the so-called Cosmos builders DAO); going further still, CosmWasm could enable the Hub to act as the credibly neutral home for Interchain Governance within the wider Interchain.

A distinct but nevertheless appealing vision for the Hub, as expressed by Billy, is as a sort of google search for the internet of blockchains. This would require it to act as an index of assets, accounts, and chain ids. While achieving this vision is possible without CosmWasm, it's questionable whether the Hub would be able to move fast enough to achieve it without CW.

Something that's less talked about is the time it would free up for the Hub team. As it stands it's very complicated for everyone to run Cosmos SDK modules and fit them into the same binary. Co-ordinating this for every upgrade is the main purpose of the Hub team right now. In Billy's words: "Our full time job is just to glue the pieces for everyone together". CosmWasm would liberate this extremely talented team to think deeply about and ship the features that they feel the Hub needs to flourish.

Could Hub stability be a unique selling point?

Doing the same as everyone else can make you less relevant. There's certainly an argument to be made that ATOM is better off trying to resemble BTC than ETH.

Jae Kwon has written that:

"On platforms like Ethereum or Polkadot, perhaps they would have a better time rolling back the chain to undo a hack as in the DAO hack. The major difference with an IBC hub is that it cannot simply reverse the transactions of other chains."

While this is true, it's also true that two well-governed BFT-PoS Cosmos chains connected by IBC can come to an agreement about what to do in case of a zone or Hub failure. While IBC aims for fault isolation, rollbacks are possible through an app layer protocol if both chains opt in.

What's the worst that could happen if CosmWasm is included?

A zero day exploit from anywhere in the CosmWasm stack that leads to a significant amount of assets being moved out of the Hub combined with an inability to come to an agreement (vis-a-vis a rollback) with the chain(s) these assets have been moved to.

What's the worst that could happen if CosmWasm is not included?

If a single player launches it's own app-chain and ends up dominating the liquid staking market there is a possibility that it will be able to effectively determine the Hub validator set without being accountable to the ATOM community.

Putting all the Hub's eggs in Interchain Security is a risk. It's a highly complex product which may take longer to ship than expected. Product-market fit is not a guarrantee: the immediate market it's trying to attract are SDK devs who could just as easily deploy their own chains.

If CosmWasm is not added to the Hub, and Interchain Security is delayed, there is a risk that DeFi yields start seriously competing with ATOM staking yield. This may make ATOM a poor choice of asset to use in DeFi in the medium term which in turn creates a risk that ATOM will miss its chance to cement itself at the heart of interchain DeFi (an important counterpoint here is that DeFi yields suffer greatly during bear markets so the immediate risk may not be all that great).

Proposal text

Summary

Signaling proposal to include CosmWasm on the Cosmos Hub in v8-Rho upgrade targeting Q2 2022. Further details and discussion at https://forum.cosmos.network/t/proposal-draft-include-cosmwasm-in-rho-upgrade/6243.

Details

This is a signaling proposal to include CosmWasm in the v8-Rho upgrade. The Cosmos Hub team at Interchain GmbH has done technical feasibility research by speaking with CosmWasm core contributors and validators to understand the burden of integration and believe it is technically feasible with resources in Interchain GmbH and Lido as well as regular advice meetings from Confio.

The instance of CosmWasm included on the Cosmos Hub will be governance gated and use Cosmos SDK v0.46.x. The governance feature set created by Confio, funded by Prop 25, works so that all of the wasmd Message types can be executed by the chain’s governance module. These messages all otherwise have configurations so that they can be executed by one account, any account, or no accounts. Each message type should be set to “no account” so that it is only possible to execute messages with Governance. One alternative possibility that needs further review is whether to allow “one account” and designate it as the new governance module account to take advantage of the new features in the governance module coming in v8-Rho.

CosmWasm on the hub comes with benefits and drawbacks that deserve serious attention. A summary and background of the topic has been posted to https://forum.cosmos.network/t/proposal-draft-include-cosmwasm-in-rho-upgrade/6243 where further discussion is taking place. Please visit and take these into consideration when voting.

How should I vote?

The following items summarize the voting options and what they mean for this proposal:

Why you should vote YES

YES - You approve this signaling proposal to include CosmWasm on the Cosmos Hub in v8-Rho upgrade targeting Q2 2022.

You should vote YES if you believe that CosmWasm is necessary for ATOM to play a large role in the IBC economy and that the opportunity cost to waiting any longer is simply too great.

In particular, you might vote YES if you believe:

• CosmWasm gives the Hub crucial optionality at a critical time
• The Hub team will integrate themselves responsibly into the governance-gated deployment process of CW contracts
• The Hub team will bring in the necessary expertise to be able to react quickly to potential CW vulnerabilities
• CW on the Hub is a worthwhile hedge against delays to and/or poor market adoption of Interchain Security, even if it entails sacrificing some level of Hub reliability/stability

Why you should vote NO

NO - You disapprove of this signaling proposal in its current form (please indicate why in the Cosmos Forum)

You should vote NO if you are either philosophically against adding CosmWasm to the Hub, or if you believe that now is not the right time to do so.

You may be philosophically against if:

• You are a Hub minimalist at heart
• You believe the role of ATOM in the Cosmos ecosystem should be more akin to that of BTC than ETH
• You'd like for the Hub to continue moving slowly and deliberately and are unwilling to risk compromising the Hub’s reputational position of being the most minimal and therefore the most stable and reliable zone in the Cosmos

While you may not be philosophically opposed to a more feature-full Hub, you might vote NO if you believe that hedging against delays to and/or poor market adoption of Interchain Security is not worth the increase in risk you associate with including CosmWasm in Rho – whether this perceived risk has to do with CW's immaturity, the lack of clarity as to the Hub team's role in the governance-gated deployment process, or your confidence in the team's ability to respond quickly and effectively to CW vulnerabilities given their lack of in-house CosmWasm expertise at this stage.

Why you should vote NO WITH VETO

NO WITH VETO - You are strongly opposed to this change and will exit the network if passed.

You should vote NO WITH VETO if you are so strongly against this proposal that you would go as far as to censor transactions to prevent it from passing.

You might vote NO WITH VETO if you are strongly against this proposal, feel this proposal breaks with the conservative precendence of the Hub, and/or believe the Hub should require a 2/3 majority to pursue what you consider to be a new vision.

Why you should vote ABSTAIN

ABSTAIN - You are impartial to the outcome of the proposal.

You should vote ABSTAIN if you are impartial to the outcome of the proposal.

How do I vote?

If you do nothing, you will inherit your validator's vote. To check how your validator has voted scroll to the bottom here. If you wish to override your validator's vote you'll need to open the Keplr app/extension and select the Cosmos Hub chain, then follow the steps outlined here.

Further reading

• Forum discussion
• Proposal status (mintscan)