Defunding CosmWasm is a Threat to the Cosmos Hub and Cosmos Ecosystem

[jacobgadikian]

@mr-t

thx Ethan, Simon and Confio team for building CosmWasm

Very this

@kakucodes

My primary concern is that relegating CosmWasm to purely maintenance mode could have far-reaching consequences.

It will, and I may have suggestions on the matter. I love the cw syntax and style. I hate wasmvm, when using a go chain, I think it’s dangerous.

In the immediate term, I think it’s a good bet to port the virtual machine to go. (Or the cosmos stack to rust)

@dakom

Those of us who have written a fair amount of CosmWasm code are very aware of the devrel and tooling problem. We know the tooling needs some love (notwithstanding the resources @adairrr shared)- but that’s exactly the point. CosmWasm is much better positioned than EVM to get over that hurdle and make more kinds of application development on blockchain tech easier. It takes resources to get there

Yeah it’s pretty good

@jtremback

On the other hand, I can’t think of an instance where a really iconic platform used the VM of another platform. Users of the EVM tend to be tightly associated with Ethereum itself, such as Polygon, and all the rollups. Do you think this is just an accident of history and that Cosmos and the Hub will be the first platform to break out with a VM agnostic approach, or do you think there’s a risk that dividing effort will result in Cosmos not knocking it out of the park with any of these VMs?

There was a time when I didn’t believe that smart contracts are a good idea at all, but that time has passed. I think that what we should do is Port the VM to go, which is underway here:

• use wazero by faddat · Pull Request #582 · CosmWasm/wasmvm · GitHub

Right now everything works except instantiate – and of course that is important. Anyhow, what I think all of this could do is allow for CW to use much more SDK like terminology and to be a much easier integration. I also believe that it is possible there are better routes than webassembly.

But for now, I’d be super happy with just finishing the go integration for the virtual machine bits. I think it would be huge.

Anyhow, having a native go contract implementation opens the door to all kinds of other contract implementations and I think that’s good.