(Dev discussion/Issue) WASM implementation

One feedback that we’ve received frequently is that a lot of our development happens behind closed doors. We want to seriously improve on this, so we’re attempting to bring some of our discussions (mostly those that happens on our internal Slack) to the forum. We’re also looking for other ways to be more transparent and show our WIP as it happens, and not after the fact (we’re open to ideas here!).

This week, we’ve been looking into the best path forward with integrating secret contracts into the Enigma network. For Discovery, we’ve built an implementation called eng-wasm (and enigma-core surrounding it), which is essentially the WASM interpreter running inside of the enclave. It also includes all of the encryption/decryption/signing code to preserve privacy/correctness.

Right now we’re faced with two different options:

  1. Migrate eng-wasm into the Enigma Chain
  2. Use CosmWasm.

After several discussions, we’re leaning towards option #2 for the following reasons:

  1. pwasm, the implementation we’ve used a starting point for eng-wasm has been since deprecated by Parity.
  2. A lot of our serialization/deserialization code was made to be EVM compliant (Solidity ABI). We don’t see a need for that anymore.
  3. We’d have to materially change our state code anyway. CosmWasm has a state implementation that integrates well into Cosmos.
  4. There’s a whole smart contracts module (wasmd) that is Cosmos SDK compliant, making the integration faster.

The biggest downsides we currently see for this approach are:
a. CosmWasm is still changing rapidly and can (and potentially will) have breaking changes. We’ll have to keep up with that.
b. Integration will require more surgical precision.

Next step is to try to integrate CosmWasm in the clear, then look into enclave related components.

4 Likes

How different are the implementations/how much code does that mean nixing?

Unknown at this point. You can look at both enigma-core repo and CosmWasm repo to get an idea.

We’re sharing as we go :).

1 Like

Totally fair :slight_smile:

Time to do this thing

Yes :).

One other thing to keep in mind. We’re somewhat divided on whether to force the existing developer style for writing contracts (cc @ainsley) even if we use CosmWasm, or explore other avenues. This is an open topic.

I know @reuven thinks we can improve things. My position would be to keep it simple as long as changes are small - i.e., use CosmWasm’s style directly if there aren’t A LOT of changes, and maybe tweak them slightly to improve obvious areas.

TBD…

1 Like

Curious to hear @reuven’s thoughts on the tradeoffs. We want to help people re-use code they’ve already worked on… but I suspect if there are elements that are easier (i.e., a built-in analogue for msg.sender ) we would get some fans for change :). Not sure if something like that is within scope of this choice or not.

2 Likes

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

1 Like

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.

7 Likes

@ethan good to see you here! I have a couple of questions

Does this mean we can call contracts on cosmos sdk chains that are running CosmWasm?
Does this require IBC efforts to mature?
If so is there an easy way for me to see which ecosystem players are using CosmWasm?

3 Likes

Now that WASM is implemented in testnet (using CosmWasm), we’re looking at integrating it into SGX, and it’s more challenging than expected.

The main concern is that CosmWasm uses Wasmer, which is a JIT compiler. This is great, but it doesn’t seem to work inside of SGX currently (might change with SGX2), which means we have to revert back to an interpreter. We’re looking at integrating WASMI, which is the interpreter we used in Discovery. WASMI is enclave friendly, but CosmWasm right now is tightly integrated with Wasmer, so we’re now starting to explore how hard it would be to break that connection.

5 Likes

I`m not sure if I chose right topic here,but I try to learn how to be a node validator. I have the hardware, and got a link to an educational site. But I have two quest (for now) Do I need a “clean” HD with linux 18.4 ubuntu server? Or will the software run on win10?
Is it any place to follow webinars or something? I watch a great weekend on crowdcast, but would like to se more of stuff like that.

1 Like

You can check out https://secretnodes.org/#/tutorials/deploy-enigma-fullnode for educational stuff.
Also to ask node support related questions just start a thread in https://forum.scrt.network/c/enigma-nodes/8

1 Like

Try this guide, @Peres139: https://github.com/enigmampc/EnigmaBlockchain/blob/master/docs/validators-and-full-nodes/join-validator-mainnet.md

and feel free to ask for support help in our discord channel, it’s pretty active

2 Likes

can’t you compile once and just transmit the machine code out? or is there no way to inline wasm on an SGX machine

SGX doesn’t support this