Secret Contracts on Enigma Blockchain

Secret Contracts and Secret Apps
1

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.
8 Likes
2

Hey, Guy, good to be back. Some questions:
Currently, validator hardware isnā€™t listed as requiring SGX support ā€“ additionally, idt it makes sense to tie tendermint finality times to computation times (and all the obv ways to make every validator node an SGX node do that)
Also, why not at least split the validator nodes up to reduce the risk of someone breaking SGX on one machine?

3

Moreover, is there no plan for key rotation?

4

See: ā€œfuture optimizationsā€. Implicit key rotation is under discussion!

1 Like
5

Yup, thatā€™s my bad :slight_smile:

6

Specifically, either the nodes will all run Compute simultaneously (in which case one nonhalting computation wipes the networkā€™s Compute times out) or sequentially, in which case you get gimped on speed.

7

Once we have secret contract functionality integrated to Enigma chain, we will look into interoperability options with Ethereum and the Cosmos ecosystem.

@guy Does that mean initially, secret contracts will not be compatible with Ethereum? Will secret contracts not be able to interact with Ethereum smart contracts as if Enigma network was deployed as a layer 2 on top of Ethereum?

2 Likes
8

@Enigma thatā€™s partially correct. First improvement to the network will be secret contract functionality. We will then look into interoperability with Ethereum.

When we first launch secret contracts, they will function in enigma ecosystem. If a game is being built itā€™s going to be limited to Enigma blockchain and SCRT participation, if a mixer like Salad is being built, it will be for assets on Enigma chain.

As Iā€™ve mentioned in another post, this is the right architectural decision to build secret dApps.

Once we are able to provide secret contract functionality on Enigma chain, we will explore ways to support the Ethereum ecosystem.

This approach helps us ship code in a more consistent manner.

2 Likes
9

Iā€™m glad to see Enigma on itā€™s own chain. Iā€™ve been an advocate of it from the start and am elated that we donā€™t have to wait several iterations for independence.

Enigma has enough technical challenges to worry about. The limitations that come with being built on another system would be a constant struggle. Ethereum has no obligation to keep Enigmaā€™s best interests or performance in mind.

While I think they can coexist peacefully ,Enigmaā€™s private aspects could strongly compete with Ethereum someday. In that scenario it would be a bit of a conflict to be dependent on them. interoperability rather than dependence is a better approach.

2 Likes
11

Yes, validators are going to be like Secret Nodes in Discovery.

1 Like
12

Hi all! Interesting stuff here. Iā€™m a random guy from the internet and want to add some thoughts to this excellent summary.

Oh, but this also means only validators have the data available. No read-only blockchain node can collect blocks, execute them and replicate the state. This also means when a new validator joins, it cannot replay the chain but must trust another validatorā€™s state dump.

While the same data must not be encrypted to the same output multiple times for security reasons, this does not mean the encryption needs to be non-deterministic. When you look at symmetric encryption schemes you use an initial vector IV that needs to be unique, not random. In the excellent documentation of libsodium, you find recommended ways to generate IVs/Nonces for various algorithms: https://libsodium.gitbook.io/doc/secret-key_cryptography/aead#nonces. A typical way to ensure uniqueness is using counters. This is not desired in many environments since it requires storing the most recently used counter. But in a blockchain you can simply count the transactions because you have global execution order anyways. When you now use a PGP-style symmetric/asymmetric encryption combination, you can encrypt outputs for a target pubkey provided by the user.

There is impressive work done by the corestario team on distributed generation of fair randomness inside of Tendermint: tendermint/README.md at dcr-random Ā· corestario/tendermint Ā· GitHub. I did not study this in detail but it is probably worth looking into the approach.

The randomness would probably be world-readable using this implementation. But then you can use validatorā€™s private key material to turn the fair public randomness into fair private randomness.

Note I donā€™t know SGX. So you are saying there is a way to guarantee a validator uses the TEE and did not patch the code to execute the same logic in an open environment? That would be nice but I wonder if this is really possible with open source software.

In Tendermint, every validator must execute every transaction independently and come to consensus on the result. It is out of scope for Tendermint to let some validator do the execution and others simply trust the provided resukt. However, it is definitely worth discussing if secret contract execution at layer 1 is the best possible approach.

There are ways to ensure a computation runs out of gas and terminates unfinished at some point (causing the entire transaction to be reverted as if it never happened). Everything that happens as part of Tendermint consensus must happen sequentially, one transaction at a time. This is required for getting the exact same blockchain state at the end of every block. This means consensus guarantee on every single bit. Nice stuff.

3 Likes
13

Ah, alright, so most of the stuff Iā€™ve been annoyed by is tendermint limitationsā€“the ā€˜runs out of gasā€™ concept only works if the SGX enclaves are directly linked to the tendermint chain the same way machines typically are? I donā€™t know enough about decentralized vms to know how this works, tho

14

I think it is a matter of understanding how Tendermint works. It is a powerful distributed state machine that gives you a lot of guarantees and can be considered a top in class solution for what it was designed for. The better question would be if task XYZ is something that should be done by Tendermint, not why Tendermint cannot do things in a certain way.

That depends on how the contract execution VM is implemented. It could run in the enclave entirely and then you just pass a gas limit as a parameter into it. Or the enclave could report after every operation how much gas it consumed and the surrounding code terminates it at some point. But I donā€™t know which approach the team is working on. Details are discussed e.g. here: (Dev discussion/Issue) WASM implementation

The general idea is something like: executing + costs 2 gas, executing - costs 2 gas, executing * costs 3 gas, executing / costs 5 gas, executing << costs 1 gas and so on and so forth. You need a VM that can count the executed operations and report during the execution. Then you can calculate gas cost and set a limit. This is often called metering.

The whole metering is not specific to distributed VMs. Since the exact same full execution happens on every node, you can look at a single node only. The only additional aspect is that the execution needs to be deterministic to ensure the same result is computed on every node.

2 Likes
15

Totally fair! By ā€˜tendermint limitationsā€™ I didnā€™t mean to imply the inferiority of tendermint ex nihilo, only potentially for this specific task.

If you get that gas limiting, couldnā€™t you build attacks that offloaded specific data based on the success or fail state of a computation and use that to read out bits of the encrypted data one by one?

16

Hahaha, nice one. The information if an execution fails or passes depending on the input data would be a super interesting side-channel attack. However, my gut feeling is that you wonā€™t get much information per execution and the number of executions you can afford is limited. But totally worth exploring. You get much more information in the gas consumed report of sucessful executions ā€¦

17

The way around that is to have computations always charge the total gas allocated for them, which means youā€™ll have to request a number of computations to get that info out :slight_smile:

18

Correct, this is a trade-off. We are thinking of ways to improve this though.

Responded in the other thread - thereā€™s an assumption Iā€™m making that counters will go out-of-sync, but I might not understand well enough if that could ever happen in Tendermint (I assume it can).

This is great, will take a look!

Correct, there is. Code is signed by the developer, and then inside of the enclave both the code and the state of the computation (and whatever data you want) is signed with a key only known to the enclave. This is then verified by Intel (they have an attestation server). We need to do this once while generating a new key-pair inside of the enclave. From that point and on you know that anything signed with the key generated inside of the enclave is kosher (as long as your trust in the enclave holds, of course).

19

About counters (also responded in the other thread), why not just use block height?

20

Yeah we considered that. Iā€™m not sure itā€™s not game-able (need to think about it. Itā€™s probably safe), since itā€™s easier to control than say, taking the hash of the tx.

But anyway, Iā€™m more curious to see if internal counters can never go out of sync. That could be helpful for randomness.

21

Block height is not unique, different txs in the same block would have the same block height.