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:
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.
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.
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 want to make a cleaner/well-encapsulated alternative to Cosmos SDK, or maybe to port over Substrate or something, you don’t need tiny bytecode sizes. If the logic is being written in WASM by the developers of the chain, of course they don’t care about the size of the bytecode.
