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

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…

Excerpt (1194 of 6406 characters). Read the whole post on the forum ↗

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.

For this testnet, we will airdrop significant staking tokens to every Cosmos Hub address that votes on this proposal (yes or no), which signals their interest in the idea. This allows interested parties involved in the Cosmos Hub to have the voting power on this network.

Airdrop what kind of token to which addresses, exactly?

This entire proposal, from writing the code to launching the testnet will be completed in 2-4 months.

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?

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…

Excerpt (1195 of 2102 characters). Read the whole post on the forum ↗

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

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.

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

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

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: • This proposal passes • We implement the proposed features • We demo features on the testnet and integrate feedback from the community. • (Outside of CosmWasm scope) Cosmos Hub updates to cosmos sdk 0.39+ with IBC support • Governance discussions and proposal to use this deliverable (with possible changes) on the hub • 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…

Excerpt (1189 of 1916 characters). Read the whole post on the forum ↗

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…

Excerpt (1196 of 1739 characters). Read the whole post on the forum ↗

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…

Excerpt (1196 of 1662 characters). Read the whole post on the forum ↗

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)

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

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…

Excerpt (1199 of 3204 characters). Read the whole post on the forum ↗

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.

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

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.

veryyyyyyyyyy niceeeeeeeeeeeee