Secret Contracts on Enigma Blockchain
This post describes our current thinking around bringing Secret Contract functionality to the Enigma Mainnet, a proof-of-stake-based blockchain based on Cosmos SDK/Tendermint.
This chain is currently transaction-only, and secret contract functionality will be added in the future via proposals.
The goal of this post is to provide a window into our current thinking. It is not a final roadmap, proposal, or concrete plan, and is subject to change and improvement as we learn more. We encourage discussion, questions, and additional proposals.
On-Chain Secret Contracts
We are exploring ways to bring Secret Contract functionality to the Enigma Chain. One approach is to integrate secret contracts into the chain directly. This means that every validator performs every secret computation and achieves consensus on the results. This would be a Layer 1 chain, which accepts encrypted inputs, performs computations privately, and returns public outputs on-chain. There would be a public, shared state across all validator nodes, enabling them to reach consensus. This approach would require bringing a WASM-based runtime into the Enigma Chain.
Supporting Motivation
We believe this implementation is the most realistic goal to aim for right now. A few reasons for this choice:
- Consensus means we have strong correctness guarantees on each computation
- This approach has good data availability, as each task is available to every validator
- We will make minimal changes to developer-facing abilities of Secret Contracts
- This implementation meets requirements for existing products such as Salad, games, and secret benchmarking
- We can reduce centralized components like a key management node, which was present in Discovery
- We see a clear path to mitigate some of the challenges, including a shared on-chain state, randomness, and network-wide encryption/decryption.
Implications
Shared On-Chain State
In our described approach, shared on-chain state is a major design element. State is shared across all nodes on-chain, who reach consensus on the results of every computation. Shared state improves on availability and correctness metrics compared to Discovery, where one worker would be responsible for a secret contract for a given epoch.
Secret contracts still work with encrypted inputs. Therefore each validator node must be able to decrypt the userās encrypted inputs. We can do this through the creation of a network-wide encryption key (see āencryption and decryptionā section). This also means that each validator needs to be able to reach consensus on the output. Because good encryption is non-deterministic (the same data encrypted twice should not output the same result) this means that at least initially, output results will be public.
Encryption and Decryption
Each validator node must be able to decrypt the encrypted inputs. We can do this through the creation of a network-wide encryption key. A āgenesis validatorā will be tasked with creating a shared keypair, where the private key is shared between validators when they are securely brought online and the public key is used to encrypt the data inputs to the secret contracts. While this approach reduces centralization of a key management node (used in the Discovery design), it does increase the impact of an enclave being compromised. We will continue to research ways to address this risk.
Randomness
SGX-based randomness is not deterministic, meaning each validator will get a different result if asked to create a random number. One way to provide randomness (a frequently required service for our products) is to include a random seed with the shared keypair created within the enclave for the genesis validator. This way, we would be able to provide pseudo-randomness while still enabling validators to achieve consensus on the result.
Future optimizations
- Enabling encrypted outputs on-chain
- Implicit key-rotation
- Incentives for new validators
- Pseudo-randomness
Moving Forward
We plan to raise a proposal for integrating a network update within the next six months. This proposal would be voted on by the active validators supporting the Enigma network.
Moving the Enigma protocol consensus layer from Ethereum to an independent, fast blockchain was a necessary step to deliver better infrastructure to developers and securing the protocol long-term. No matter the path forward from here with respect to how secret contracts are integrated, we have full confidence in this fundamental technical decision.
We plan to update the community on our design decisions on public channels.Once we have secret contract functionality integrated to Enigma chain, we will look into interoperability options with Ethereum and the Cosmos ecosystem. We will discuss the implications of this design for validators separately.
Appendix: How this may work
- Validators are brought online in a secure way by existing validators, who check the attestations that they are indeed running TEEs.
- A āgenesisā keypair is created inside the enclave of the first validator. This keypair is securely shared with each subsequent validator node that is brought online. Each validator thus has two keypairs: the keypair specific to their enclave, and the shared keypair which they receive from the genesis node.
- Users encrypt their task data for a secret contract using the public key for the shared keypair and submit this as a transaction to the enigma chain. The task data is now on-chain in an encrypted form.
- Each validator node decrypts the task within the enclave, performs the computation, and returns the result on-chain.
- Validator nodes achieve consensus on the on-chain result of the computation.
- Users observe the result of their computation on-chain.