Skip to main content

Confidential Computation

Confidential computation enables you to handle orderflow privately and securely.

In SUAVE, we achieve this with Kettles (eventually running on TEEs) performing compute offchain, but according to programs (smart contracts) written onchain. In this way, offchain compute is not constrained by chain consensus.

How It Works​

info

For practical examples of how Confidential Compute Requests (CCRs) work, please follow this tutorial. The below will explain CCRs conceptually, without code.

1

Starting Point: A user sends "Confidential Compute Request" using eth_sendRawTransaction, which is received by the JSON RPC.

2

MEVM Execution: Upon receiving the request, the JSON RPC triggers the MEVM (Modified Ethereum Virtual Machine) to run. MEVM execution can use multiple APIs depending on the context, with two possible paths:

1

Request to an External Domain: The MEVM can make API requests to external domains: i.e. if you're running an Ethereum node, it can fetch state from there for simulations etc., or if the SUAPP uses the doHttpRequest() precompile, it can fetch arbitrary information required for the offchain compute.

2

Request to the Confidential Datastore: The MEVM can make API requests directly to the "Confidential Datastore" to fetch or store data.

3

Suave Chain Interaction: Eventually, after processing the request the MEVM can take the results and, depending on the SUAPP's logic, send a SUAVE transaction, which is a transaction object that contains the result of the CCR in its calldata (and the signature of the Kettle which computed said result), which enables other users or contracts to take action.

4

Transaction Hash Output: A transaction hash for the Suave transaction above is produced and returned to the request's originator, just like Ethereum.

Computing over Confidential Data​

How to index, store, and use confidential data is left up to each SUAPP.

For example, in the Private OFA Suapp, to submit a valid backrun, a searcher must include the recordId of the user transaction in order for the Suapp to match them. Therefore, the Suapp emits the user transaction recordId as a log on chain, which searchers can listen for and use to construct valid backruns.

However, the NFTEE example demonstrates how to store a private key in the confidential store. In order to get it to sign a transaction intended for Ethereum L1, we store the recordId associated with that private key in the contract's memory, which ends up onchain. In this context, this is not a concern, since it's gated, so only that Suapp can access the key for signing purposes.

Restricting Access​

You need not use confidential requests in the ways which our examples illustrate. For instance, if you wish to restrict access to methods with a modifier requiring some confidential secret, you can do so. This can be achieved by following the below steps, contributed by Miha:

  1. When you initialize a contract, pass it a secret key which is stored in confidential storage.
  2. Use this key with the local nonce to derive the next secret.
  3. The hash of the present secret is in public (evm) storage.
  4. Whenever a restricted method is accessed, the present secret needs to be provided.
    1. This is only accessible through confidential execution.

You can find Miha's implementation of ConfidentialControl here, along with a good example which illustrates its use.

This particular approach, and the reason it currently works in this manner, is being discussed in this suave-geth issue.