[PROPOSAL #25][ACCEPTED] CosmWasm on Cosmos Hub

Hub Proposals Community Spend
1

Moderator edit to add link: Mintscan - Chain explorer by COSMOSTATION

Who is proposing?

  • Confio, creator of CosmWasm. This is Ethan Frey and Simon Warta.

What is this proposal for

  • Validator-reviewed smart contract capability for the Cosmos Hub.
  • Governance control over complete lifecycle of smart contracts on the Hub, including upgrades and freezing.
  • Working example of staking derivatives, deployed to a testnet

Benefits

This has been discussed on a few calls with some validators, but we see the addition of curated functionality via CosmWasm contracts an ideal way to allow the Hub to dynamically respond in a multi-chain ecosystem. Beyond adding a clear path for some long-requested single-chain features, like staking derivative, we provide a path for implementing “rented security” and relaying dynamic IBC packets (with protocols besides ICS20).

This allows upgrading functionality is a secure and responsive manner, and opens up participation of adding functionality to the Cosmos Hub to many more than the core Cosmos devs. The barrier of entry to uploading a new contract is much lower than adding Go code to the gaiad binary.

Details

A detailed proposal, which is prepared for an official on-chain vote is attached. Earlier versions of this have circulated on Discord. This is a chance to collect feedback before a formal proposal.

Full Proposal as PDF

This extract of the above PDF explains how governance control of a contract works.

TL;DR: It is all about adding governance control to all aspects of the CosmWasm contract lifecycle to make it compatible with the hub. Allowing governance to control code upload, contract instantiation, contract upgrades, and contract destruction (if needed).

Contract Lifecycle

There have been some questions as to how a contract lifecycle would work. This description here is for the proposal of govd, where a governance vote is able to make each decision. In wasmd, anyone can create contracts, and no one can modify it. Code for both would live in the same repo and you can mix-and-match which permissions belong to governance when setting up app.go and compiling the blockchain. This allows the hub to easily open up some functionality to be permissionless later on.

  • Upload Code: Here you upload Wasm bytecode, which provides potential functionality to the hub (eg ability to run a DEX), but doesn’t actually provide any useable instances. At this phase, the contract code should undergo an audit (formal or informal) and the Cosmos validators should debate if this general functionality is a useful addition to the Hub. Upon a successful vote, this bytecode will be installed on the hub, awaiting activation.
  • Instantiate Contract: Once the bytecode is uploaded (eg. an ERC20-like template), you need to make an instance to be able to use it. This will provide a token symbol and decimals, initial distribution, and a unique contract address. This stage requires a further governance vote, so they can decide if the requested use case makes sense. After agreeing to add ERC20-like functionality, we may also control who can issue such new tokens.
  • Upgrading Contracts: If a bug is discovered in the code, or a feature upgrade is desired, we will first Upload some new code with the requested fixes (see above), and then can vote to migrate existing contracts from the older version to a newer version. During an upgrade, we can run a state migration to change any data as needed. Upgrading must be voted on for each contract, and requires agreement from governance. We will allow a single vote to upgrade many contracts at once, but still allow more granular control than upgrade every contract using a given code id.
  • Disabling Contracts: If the hub decides a given contract is counter-productive to the goals of the Cosmos Hub, they should be able to disable it in an orderly way. This is an exceptional vote for governance, but will be possible if a majority agree. However, we need to do this in an orderly way not to destroy funds. For example, if there were a DEX on the hub, we can upgrade it to another contract that only has one supported message type “withdraw funds” and this lets users withdraw the funds they have locked in open trades. This would allow the Hub to freeze a DEX, but return all funds to users. You could also imagine a “brick” contract that deletes all data and returns error on any message. A migration to such a “brick” contract would be the same as destroying the contract.

Concrete example of contract lifetimes:

  • A project wrote a simple batch-trading orderbook as a CosmWasm contract and proposed to add this to the Hub. After some discussion and audit, the Hub approves it. This Wasm code is now available under Code ID 3 on the blockchain.
  • There are 3 proposals to add individual orderbooks for ATOM-PETH, ATOM-EEUR and EEUR-PETH. Each are approved and open up their own orderbook for trades.
  • There is concern that the trades are taking up too much traffic on the hub due to arbitrage, and they decide to add a variable “Tobin Tax” on each trade that goes to the community fund. This requires a code upgrade.
  • Developers modify the original contract with this new functionality and propose it to a vote. It is approved and now available as Code ID 4.
  • At the same time, hearing some complaints, they prepare a liquidation contract that would freeze all trades and let users pull out their tokens tied up in open orders. This is also approved and available as Code ID 5.
  • Hub governance decides that they only want trades that involve ATOM on the hub and decide to shut down the EEUR-PETH orderbook, by “upgrading” the contract to use Code ID 5. At this point all users may withdraw their funds, but no more trades may happen.
  • In a separate governance vote, hub governance decides to implement the “Tobin Tax” on the ATOM-PETH and ATOM-EEUR. They upgrade those two orderbooks to use Code ID 4.
  • In this final state, we have “improved” the experience of trading of the ATOM pairs and shut down the other trades, without anyone losing access to funds, or requiring a hard fork.

You can see the potential here for fine grained control of functionality on the hub, without requiring downtime or forking. All changes need to go through hub governance to ensure decisions are made after proper reflection.

Full Proposal as PDF

6 Likes
2

We’re supportive of this proposal - adding limited smart contract functionality significantly increases utility of the hub. However, I’ll also note that it also adds a lot of complexity and attack surface. WebAssembly contracts will be more opaque than the native Go code and require extra tooling and support in block explorers to review and make sense of.

Airdrop what kind of token to which addresses, exactly?

Sounds like a highly ambitious goal - I’m assuming that most of the necessary infrastructure already exists and this is mostly integration work and auditing?

1 Like
3

However, I’ll also note that it also adds a lot of complexity and attack surface. WebAssembly contracts and will be more opaque than the native Go code and require extra tooling and support in block explorer to review and make sense of.

We already have a Docker image for deterministic compilation and a code explorer that allows us to prove the original source code behind the uploaded wasm byte code.

This is explained here: Don’t trust. CosmWasm Verify.. If we have confidence that smart… | by Simon Warta | CosmWasm | Medium and you can check out the linked explorer (hit my link limit on a post): https demonet dot wasm dot glass

Airdrop what kind of token to which addresses, exactly?

We would airdrop testnet tokens to people who took the time to vote, so they can stake on the testnet and participate in the contract approval/upgrade process. The final deliverable of the proposal is a functioning chain (based on 0.38 or 0.39 depending on release timing) with this all working and able to be used by Cosmos Hub validators to get a better feel for the process and make any adjustments that are needed.

Sounds like a highly ambitious goal - I’m assuming that most of the necessary infrastructure already exists and this is mostly integration work and auditing?

Governance approval and contract migrations do not exist in CosmWasm yet. However, we have had a few public releases, ran on some public testnets (most notably Regen with 70+ validator and 150+ contracts instantitated), and built and tested a number of contracts. We also built out frontend tooling, like the block explorer above, as well as a simple nameservice dApp, running on our “demo net”.

So, we are building on a solid platform and customizing it to meet the needs of the Cosmos Hub. We have been working on a 0.8 release for the last 6 weeks and plan to finalize it within 2 more. This is a deeper overhaul of the platform than required by this proposal, so I think the time is fine (2 months to code, 2 months for the testnet and adjustments). We are two highly-productive developers working on this :smile:

1 Like
4

Full support here of the proposal, huge utility boost to the cosmos hub, this is perfect for huge value trades that require absolute security but do not require speed

5

First, I want to clarify that the governance type is communityFund, but the actual proposal not only includes a community fund funding for development of feature, but also includes “Hub adoptation of gov-approved CosmWASM smart contract”? Then, we should note that this proposal cannot be voted for “no to hub adoption” but “yes to communityFund funding”, or the opposite of this.

I saw in the proposal that it says “validator-reviewed” but, technically each smart contract should be passed by governance vote to be operated on the hub right? So not the validators but the actual gov voters have the final decision power?

I remember several devs who are/were working for Tendermint had opposite idea about smart contract on the hub. I hope to see the opposite point of view from them, so that we can discuss with more informed opinions.

I am quite neutral to the adoption, so the opposite opinions will help a lot for me and also others to decide whether we should vote for yes or no. But, regardless of my opinion on the adoption, I am quite positive on communifyFund funding.

1 Like
6

Very happy to see this proposal as a diversification of the community pool funds

1 Like
7

Hey Guys! Regarding the Cosmos Proposal - here’s our stance:

We very much share the sentiment that governance approval and contract migration are beneficial for CosmWasm and ultimately for the Hub once successfully integrated. There is no doubt that CosmWasm should be integrated into the Hub at some point or another. Yet, while we appreciate the initiative, we think the ask of 25k ATOMs seems a bit high given the fact that this proposal is not about the implementation but rather about updating an existing binary and launching a testnet thereafter.

Furthermore, CosmWasm is funded through other grants and not part of this proposal. As far as we understood it from the full proposal, the ask for this grant is considered to be “relatively small” and future grant requests are to be expected. Hence, we wonder how high the overall grant would be in order to advance from a testnet.

We really do not want to step on anyones’ toes here, especially not yours, Ethan. We just wanted to get this questions out of the way to cast our vote in full confidence. Again, thanks for the initiative - very much appreciated!

Best,
Florian

8

Hi @bharvest and thank you for the questions. I think they may also cover some of the concerns of @katernoir

Basically, this proposal would be to prepare both the module logic and a binary that would fulfill the prerequisites for deploying CosmWasm to the hub. The core devs have been hesitant to add too much functionality to the hub and definitely not an Ethereum-style permissionless smart contracting engine. However, there will be a need for faster feature iteration with IBC. Actually deploying it needs a much deeper discussion on if/when/how to do it, as well as agreements on what constitute valid features, and what not.

In my eyes the road to actually deploying on the hub is:

  1. This proposal passes
  2. We implement the proposed features
  3. We demo features on the testnet and integrate feedback from the community.
  4. (Outside of CosmWasm scope) Cosmos Hub updates to cosmos sdk 0.39+ with IBC support
  5. Governance discussions and proposal to use this deliverable (with possible changes) on the hub
  6. Activate this module in the binary and deploy (ideally using new in-place upgrade - no "dump genesis and restart chain)

This proposal only covers #1-3. Once 4 is delivered, I am happy to participate in 5 (but will not lead those - this needs input from many more people). The programming to actually add the functions and migration when gaia is using cosmos sdk 0.39+ would be less than a days work (which others can do as well).

So, yeah, this is getting everything ready technically. This is not a commitment, and we can proceed even if there are some open questions on if and how to activate, as long as it looks likely there will be some path.

And yes “validator reviewed” is probably a poor way of saying “governance approved”, but in the end most of the voting power is controlled by the validators (who would be responsible for reviewing contracts or getting someone to do so).

9

Hi @katernoir I think I explain the roadmap to adoption above. As to the pricing…

I wrote this proposal some weeks ago. Since then I have gotten some positive news and it seems quite likely a grant for CosmWasm-IBC integration will be finalized with the ICF. That is a large dev effort and was unclear if I would need to make a Hub proposal for that, luckily it seems not.

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.

Others could also submit proposals for contract development and I expect a competitive market to exist there - who can provide the best feature at the best price. I would be happy to work on some of those for the Hub if chosen, but there are also other Rust developer in the Cosmos ecosystem.

Actually opening up contract development to more developers in the Cosmos ecosystem would require adding bindings and support for writing contracts in AssemblyScript or TinyGo. This would bring down cost (and time) of contract development, but is a rather complex and costly item. Many people have asked for it, but no zone seems interested in funding it. This may be covered by a future ICF grant, or failing that, I may ask the Hub for that (once there are contracts live and such support has a clear benefit for the Hub).

After this proposal, there would be no essential work that only CosmWasm could perform that would be needed before going live with IBC-enabled, permissioned smart contracts on the hub.

10

Thanks for clarification. If the proposal does not include step 5, below statement should be modified in the full proposal.

Milestone One Value: Governance control over complete lifecycle of smart contracts on the Hub,
including upgrades and freezing.

“on the Hub” should be replaced to “on a testnet of the Cosmos Hub”. The current milestone statement says the proposal will result in smart contract “on the Hub”, which is not the real intention of this proposal.

Another point from mileston

Working example of staking derivatives.

Although I think it is worth testing the staking derivatives via smart contract, I am strongly against deploying any kind of staking derivatives on the Hub via smart contract.

The reason is that, most smart contract will have subset of domain in Cosmos Hub community. But, in staking derivatives case, the contract has a good chance to have a “full domain” of entire Cosmos Hub community. It implies that the malfunctioning of the contract will impact on the entire dPoS security mechanism of the Hub, threatening the stability and accumulated reputation of the Cosmos Network, Tendermint software and Cosmos-SDK.

So, if the proposal has an underlying intention to adopt the smart contract capability on the Hub partially to achieve staking derivatives via smart contract, I guess I am leaning to disagree.

What I prefer for this proposal is an independent technical implementation and testing procedure without any intention or mention of “Hub adoption” or “staking derivatives”. Those are the topics which should be discussed and decided from standard governance proposal, not a communityFund proposal.

1 Like
11

I agree to support the 25k community fund to the cosmwam dev team.

However, we are against smart contracts without autonomy.
I hope everyone can make it like ethereum and anyone can upload it on the network.

So these two issues have to be divided.
(comunity fund & cosmwasm policy on hub)

12

Hey Ethan,

thank you for the response. That cleared out our questions and we voted “Yes” to support the proposal today. Looking forward to the testnet.

Best,
Florian

1 Like
13

Thanks for this comprehensive proposal and for breaking down the future possibilities CosmWasm in general, and this proposal specifically, could open for the Hub Ethan!

Chorus One will vote YES on this community spend proposal because we agree that smart contract capability on the Hub is needed for reasons expanded on in the proposal, because we believe the Confio team is able to deliver what they described, and because we deem the requested amount as appropriate.

We generally think it is sensible to govern contract deployments and not have a completely permissionless system, since the Hub should be able to ensure all activities serve the clear focus on becoming the center of the IBC ecosystem. That being said, we are wary of the currently seemingly suggested process of having Hub governance needing to decide on each smart contract to be added/frozen/upgraded. We think this could introduce large overhead for validators and ATOM holders, who might not always have the ability to foresee which contract is desirable for the Hub. In addition, the current governance cycle may in some cases be too long (e.g. if there is some urgent upgrade to support a new zone or need to freeze some malicious contract, one would not want to go through the 2 week voting cycle).

So we believe that to make this really work, we would need to think about how to augment the governance process to make all of this happen as smoothly as possible. We could imagine introducing some form of council that is voted into via the standard governance process that would together hold the powers described in the proposal. We think introducing such councils/committees could also be useful in other domains (e.g. wrt to security upgrades). Another option could be to create an expedited governance process for contract deployments, upgrades, and freezes, but still requiring everyone to participate in each vote. We would be curious to hear how others think about this.

Since the discussion on how exactly governance would handle those upgrades can happen in parallel to the actual implementation of governance-enabled CosmWasm, we think this proposal to start the development should move forward now.

Finally, we would love to participate in testing, demonstrating the capabilities, and coming up with a proposal for a native Cosmos Hub staking derivative design. We have been exploring this topic in-depth this past year together with the Liquid Staking Working Group (Github and Telegram), which has led us to the conclusion that the benefits of staking derivatives seem to outweigh risks, that solutions are inevitably going to exist in some form, and that a standardized design directly on the Hub could benefit the Hub and help avoid some of the problems with external solutions (e.g. wrt to rented security, but also wrt to the real risk of having a large portion of ATOM staked on the Hub under the control of external entities, e.g. a different blockchain or custodial exchanges). We are in the process of finishing our ICF-funded research report on these issues that also highlight and evaluate different implementations; those interested can find our current draft for feedback and comments here.

14

Hi B-Harvest,

(Unfortunately?) I cannot modify the proposal now, as it is written on the blockchain and ipfs. But I can assure you that this community fund has the intention to prepare software for a future sub, but does not include an upgrade itself. Given the various opinions on how it should be integrated, this is clearly a much longer discussion on how the hub governance chooses to apply this potential.

I chose staking derivatives as it is a non-trivial contract that many have asked for. My plan was not to propose this for the hub, but rather use it in the testnet. Along with upgrade / disabling procedures for such staking derivatives. I would also recommend not to deploy this among the first contracts on the hub, but rather focus on more limited scope ones. But it is a bit boring to test deploy an escrow or generic erc20 token. So let’s play with this on the testnet. And everyone can vote on it, and then vote to remove it.

2 Likes
15

Fair enough! thanks for clarification. B-Harvest will vote yes for this proposal!

16

Chainflow voted Yes for this proposal. We feel it strikes a beneficial balance between continued innovation and risk management.

We’re confident the team can deliver, yet do feel the timeline is a bit aggressive.

Adding to our confidence is

  • Having had a very positive experience testing CosmWasm during the most recent Regen Kontraua testnet
  • Ethan’s conscious, thoughtful and well-reasoned responses to the above feedback

Our gratitude to the earlier respondents for their additional perspective as well.

P.S. @ethanfrey let me know if you need any help with the naming service. I’d be glad to try and leverage my experience, contacts and resources from 3 years as the Ethereum Name Service project manager to help.

17

veryyyyyyyyyy niceeeeeeeeeeeee