Hi all, I am the lead maintainer of CosmWasm and just recently in discussions with the Enigma team. Looking forward to learning more about the private contracts (cool stuff!) but for now mainly looking at integrations.
CosmWasm provides (and requires) a pretty minimal set of extern “C” functions for the bridge between wasm and it’s environment and was designed to be pretty flexible (less requirements means easier to write bridges). You can look at how we set this up in some boilerplate: https://github.com/confio/cosmwasm-examples/blob/master/nameservice/src/lib.rs
In engima contracts, you define a struct with a #[pub_interface] macro to derive functions. I can imagine Engima updating this macro to output CosmWasm compatible bindings with little to no changes inside the existing code. But could also allow the more verbose format for those who want to actually have a bit more control (or use the extra functions). Just as Avret write above:
Why not just write it as a dsl that compiles down to rust, with a choice whether to use the dsl compiler? Fully backwards compatible but allows improvement
The storage model of CosmWasm is the same as engima. The three points to discuss are encrypt/decrypt (which I would have to add to the CosmWasm runtime), how external calls to other contracts are handles (we can’t support calls to Ethereum contracts if no running on Ethereum, so this will have to change somehow. CosmWasm does allow cross-contract calls to other CosmWasm contracts now), and most importantly, how to get the Wasm code and Wasm runtime to all run inside the TEE.
The bonus of CosmWasm integration (in my view), is that this is actively being developed and many Cosmos Zones are looking to run it. And rather than having a pure engima-wasm zone, this will allow you to easily import a growing ecosystem of (non-encrypted) contracts from other zones. Also, we will are working hard on IBC integration to provide support for cross-chain contract calls… all of which would come for free to Engima with an integration. The truth is that some contracts need this privacy, but not all, so integration with an ecosystem of non-encrypted contracts is very valuable (which is currently available on Ethereum iiuc).
Another point that came up is stability, and the fact that we are only alpha software right now. We have a working full-stack solution (from rust contracts, to go blockchain, to js/react frontend sdk). The frontend side is rather immature and changing rapidly now, but we are on proper semver for the other levels (0.6.x). We have worked on a number of other sdk projects before and are well aware how important it is to find a stable API early on, and freeze as much as possible, with future iterations improving implementation and adding non-breaking features, especially when you have people actively building on your project.
We are in progress for a breaking 0.7 release of the rust contract framework, with a lot of internal changes, and enabling a few more features. It shouldn’t break the contract code much, mainly a few imports and a recompile. This came up after trying to run wasm code from other non-rust languages (AssemblyScript bindings) and doing a deep review of the architecture in practice. Beyond 0.7, there are a number of desired features on the roadmap, but they all seem to be supersets of existing functionality, so it may be possible to maintain backwards compatibility from 0.7.x on (although I will not commit to backwards compatibility until there is a real need), but we start could potentially provide a stable environment once a possible Enigma integration is completed and deployed on a testnet.
