RESEARCH: WASM in the Cosmos SDK

I can think of a number of use cases(Staking derivatives, asset issuance, cross chain collateralization etc) where it on chain code would be a helpful.

WASM seems like a great target for some SDK applications for on chain code.

One option is Perlin’s Life golang Wasm engine:

perlin-network/life

A secure WebAssembly VM catered for decentralized applications. - perlin-network/life

Concerns are mostly that it doesn’t seem to have good support for Host functions to inject into the runtime environment. This pretty crucial if you want your wasm code to actually interact with the rest of the Cosmos SDK.

Wasmer has a C api that looks like it would wrappable in go and could be a nicer path to golang integration.

wasmerio/wasmer-c-api

Example of the C API to embed the Wasmer runtime. Contribute to wasmerio/wasmer-c-api development by creating an account on GitHub.

One downside of Wasmer is that host functions are either going to trampolines in C or rust to golang.

I would like to echo support for this being a focus. Lack of on-chain WASM support is a major downside of the current SDK, and is something thats crucially needed. Its rather trivial to integrate SNARK verifier’s (and the examples you provided). This is also something being explicitly built out for Polkadot, Eth, DFinity, so perhaps there is some potential for standardization that could happen on how WASM code interacts with the blockchain for state. (Or is there a clear way to do this in WASM, I haven’t looked too much into it?)

The typical way to interface on chain code with state is via host functions. For instance, a Host function that provides the ability to query data from the multistore. Serialization and deserialization of data from inside the WASM engine is an interesting challenge.

WASM support would be great!
Rust amino should help with serialization/deserialization, right? AFAIK it is almost production ready, right?

One of the big open questions in my in integrating WASM into the SDK is how to serialize and deserialize golang structs into the WASM virtual machine.

Oasis Lab’s made has a proposal I think we can align strongly with.

Blockchain WASI

We have just released a Go integration for the Wasmer WebAssembly runtime

It’s in average between 50 and 100x faster than Life.

wasmerio/go-ext-wasm

🐹🕸️ Go library to run WebAssembly binaries. Contribute to wasmerio/go-ext-wasm development by creating an account on GitHub.

We also published an article analyzing the API and comparing it with Life/Wagon:
https://medium.com/wasmer/announcing-the-fastest-webassembly-runtime-for-go-wasmer-19832d77c050

I’d love to hear your feedback!

Rust Amino is almost done?

Hey @syrusakbary I am super interested in adding support for wasmer in the Cosmos SDK.

I think we will make a demo relatively soon.

Awesome! Let me know if we can help in any way

PS: feel free to send me an email to [email protected] if you have feedback/suggestions so we can follow up in a faster way

One thing that seems exciting about the wasmer interface is the ability to move back and forth between the wasm memory space and golang memory space.

This enables much more complex apis between the go world and the wasm world.

In wasi interface proposed by oasis, the interface is largely confined to serialized data into $HOME and STDIN/STDOUT.

In the wasmer interface, the interface is defined by the cgo api.

A winning team from HackAtom Berlin integrated WASMER into the SDK.

See diff below

cosmos/cosmos-sdk

:chains: Blockchain Application Framework :sparkles: - cosmos/cosmos-sdk

any more infomation?

I worked on this, unfortunately I do not personally have time to continue on it, but one of my teammates will be. Some points of interest: • Wasmer does not have gas metering. Another interpreter, Life, does. But Wasmer was easier to integrate in the short time available. • Passing data and calling functions back and forth across the go-wasm boundary was a pretty insane experience, but doable. We were able to get it into a pretty clean api by passing everything as JSON. • That brings me to the next point- we used Rust’s serde JSON library because it is usually the standard choice. This is the fastest JSON library in existence because it uses macros to generate custom code for each data structure. But this bloated out the contract size quite a bit, to 50-100kb for a very trivial contract. This would be prohibitively expensive to deploy. • There are a lot of other things in that were not really optimized for the miniscule bytecode sizes that would make deploying custom contracts viable. A good course of action would be to give contract developers a standard set of dynamically linked libraries instead of having everything compile into the deployed contract. • But if you just…

Excerpt (1197 of 1475 characters). Read the whole post on the forum ↗