Assaf Morami, developer at Enigma, shares a major update on running CosmWasm inside an enclave with encryption — the latest step on the journey to Secret Apps.
Hello to the Secret Network community!
Today we have exciting news. Enigma has reached our third milestone of three on the path to enabling secret contracts: smart contracts that can run on a distributed system of nodes equipped for trusted computation. This allows applications to use encrypted data without revealing the information. We have achieved this goal by running CosmWasm contracts inside secure enclaves across the Secret Network!
This post covers the technical details of this milestone, the significance of this achievement, and next steps for the network and ecosystem.
Since participating in the launch of Secret Network (Cosmos SDK / Tendermint blockchain) earlier this year, Enigma has focused on building a compute module for private computation on a distributed system of nodes equipped with Trusted Execution Environments (TEEs). This work, led by myself, Tom, Itzik, and Reuven, and Guy comprises many specific tasks, organized into these project milestones on GitHub:
- Milestone 1 — Integrating Smart Contracts into the Enigma Blockchain (complete)
- Milestone 2 — Executing CosmWasm Smart Contracts Inside the Enclave (complete)
- Milestone 3 — Adding Encryption for Secret Contracts Running Inside the Enclave (now complete)
Achieving Milestone 3 involved working on the compute module in parallel with the CosmWasm team and building encryption capabilities into the system. This milestone also resulted in our updated encryption specs (feedback welcome!). Next, our team is excited to conduct further testing with the Secret Network community in the upcoming Secret Games.
Read on for all the details!
Achieving Milestone 3 — Technical Details
First, allow me to say we are happy to contribute open-source technology alongside our community of privacy advocates, developers and infrastructure providers. Enabling privacy-preserving smart contracts will create significant benefits for users of decentralized applications. As we continue building our Secret Hub, I hope we connect and collaborate as much as possible with members of the Cosmos ecosystem. Enigma believes multichain governance and coordination is extremely important for the long-term sustainability and health of the overall ecosystem.
This section is quite technical, so if you’re mostly interested in what’s next, scroll down to the “What does this mean for…” sections below.
Now, let’s recall this post by Enigma’s CEO Guy Zyskind:
“A key design choice in this protocol was to remove the need for off-chain communication. Everything needs to be handled on-chain for simplicity and consistency.”
guy
Secret Network Key Management / Agreement
This forum post includes descriptions of the bootstrap protocol, along with 3 phases in the process by which validators obtain shared keys to be used in secret contracts. For the time being, we assume all keys are derived from a single source of true randomness: a master seed. The registration protocol essentially allows all validators to share a truly random seed that is only ever accessible from a validator’s enclave. Learn more in that post.
Our team continued the journey developing the initialization logic for the enclave. We created a bootstrapping protocol to get a shared random seed to all validators, then we built processes for key generation and node registration. This GitHub issue documents our work on lifecycle management for new nodes, which are not able to start syncing blocks until they are confirmed as registered nodes. That way, our system protects the integrity of the trusted execution environments running across the Secret Network.
In this task, hello world local node to enclave, we prepared a skeleton for the implementation of (register_validator and share_seed) functionalities, as well as any other API we need between a node and its enclave. This task, on-chain bootstrap skeleton, outlined the interface of the bootstrap module. It has a list of registered validators , and validators are in one of two states (pending, registered). There is a register_validator() tx handler to deal with new validators joining, plus a share_seed() tx handler to deal with sharing encrypted seed values for new validators. Also, there is a confirm_validator() transaction handler.
Phase 1
See the logic described here in Phase 1 (register_validator()):
register_node()~ enclave part | node part | on-chain partconfirm_node()~ node part | on-chain part
Phase 2
See the logic described here in Phase 2:
share_seed()~ on-chain part | node part | enclave part
Next, let’s recall this additional post by Guy:
guyInput / Output / State Encryption Protocol
This forum post includes a sketch of the encryption / decryption protocol. We assume validators start with shared keys. Those keys are used to generate the initial keys once the random seed has been shared with a new validator.
INPUTS
Secret contract execution should enable users to encrypt their inputs, which will only ever be decrypted inside of secure enclaves. Therefore, this protocol is part of a larger user transaction that should trigger a secret contract.
OUTPUTS
Encrypted outputs (where the output is encrypted with the sender’s key), are handled largely the same way as encrypted inputs. We can use the same ephemeral_secret to encrypt the output (which is stored as part of the contract’s state), and only the sender will be able to decrypt it.
STATE
The simplest solution to get to an encrypted state, and assuming we have a public state which allows for arbitrary values, is to allow selective encryption of specific state dict entries (i.e., the key is public and the value is encrypted). If a developer wants to encrypt the whole state, they should have a single attribute called ‘state’ and fully encrypt a state dictionary as the value.
In order to implement key management inside the Enclave, we had to properly set IV for AES bug and implement CSPRNG key derivation. Tom did a nice job fixing the nonce in encryption/decryption by implementing a pseudo-random nonce in encryption/decryption (should be deterministic).
Initially, we were using only master_state_key, but we managed to enable simple state encryption/decryption:
read_db()for wasmiwrite_db()for wasmi
As part of register_validator(), we need to verify report signatures on-chain and inside an enclave. We also implemented a connector to new remote attestation service (using API keys instead of two-way TLS).
Generating Secret Contract IDs
Reuven went on a quest to investigate alternative algorithms for generating secret contract IDs: “One of the issues we hit recently when thinking about key-derivation for the storage of secret contracts was how to make sure a different key is derived for each deployed contract. We reached the conclusion that the best option we have is to derive the key from the hash of the WASM binary the enclave is executing. This has the disadvantage that two contracts deployed with the same code will end up using the same keys for their storage.
One of the ideas that came up is to generate the contract ID after running the contract’s init, based on some data or properties that are unique to it (maybe related to the signature of the deployer or using SGX randomness), and then have the enclave sign the result.”
After we managed to fix bootstrap trust issues, our team generated a signed contract ID. Then, we handled encryption for inputs and outputs in CosmWasmJS. Along with that, our dev team had to fix a bunch of things in order to match our finished encryption specs. For example, in state encryption, we fixed contract_id & field_name. The name contract_id was renamed to contract_key, which needs to be derived and used in a secure manner, so field_name can now be encrypted.
Finally, our team successfully managed to achieve stateful contract execution in SGX (with encryption). This particular GitHub issue is almost the same as #38 from Milestone 2, except with a secret contract that has state. We had to define more ins and outs between the enclave and the CosmWasm Rust and Go components.
Now, we have an encrypted version of get_state and set_state from CosmWasm. This should overlay the existing implementation of CosmWasm as much as possible. The complexity is in actually navigating between running contracts inside of the enclave, plus actually storing and fetching data that lives outside of the enclave (in the untrusted part of the validator).
Read the Full Encryption Specs
What does this mean for developers?
Just imagine all the possibilities! You might have heard us talk about sustainable growth and usability of privacy solutions. Now you can build CosmWasm secret contracts and help with testing as we prepare to upgrade Secret Network later this year — hopefully in the fall. There are many potential use cases for truly decentralized applications which enable app developers to use encrypted data without revealing users’ personal information.
You can get started by reviewing our evolving documentation. Any feedback would be much appreciated! We have a guide for setting up your dev environment for building CosmWasm smart contracts. Let us know if you are interested in working on a demo app. Also, if you haven’t already, please join our new Secret Chat and Secret Forum to talk with the Enigma team and Secret Network community of validators and developers. You’re also welcome to share information about your experience by filling out this brief survey.
Developer Community Onboarding
What does this mean for validators?
The next step after further internal testing of secret contracts is the launch of the Secret Games: an exciting period of network testing and development for Secret Network! As part of this, there will be an incentivized testnet for validators, with more information on this shared in the coming days. If you are interested in participating in this testnet, please fill out this form!
In the future, as secret contracts are introduced on mainnet, the network will need to be upgraded to add the compute module. That requires active participation by all the node operators who support Secret Network. Validators will also have to register machines equipped with secure enclaves.
Keep track of the state of Secret Network and on-chain proposals using your choice of block explorer: Secret Explorer, SecretScan or Puzzle.
What does this mean for everyone?
As we know, privacy is a fundamental human right. Now all kinds of developers have a more accountable solution for privacy-preserving computation. Secret Network is designed to enable new kinds of solutions with encryption services built on a distributed network of secret nodes. This offers developers a practical and interoperable way to protect sensitive data in their applications, giving users the power to control how their valuable information is used and shared.
Let’s work to build privacy-first solutions with unique capabilities, empowering people to create more useful systems for humanity.
Assaf Morami — Enigma Dev Team
To discuss Secret Network and join our community, visit our official channels:
Website | Forum | Twitter | Discord | Telegram
