Skip to main content

Keeping it confidential

SUAVE computors have two modes of operation: regular and confidential (sometimes called off-chain).

Regular mode is the same as the normal EVM. Confidential mode uses the MEVM, with its additional APIs, and the precompiles available in builder solidity, to ensure that transaction data provided by users remains private until executed on their blockchain of choice.

Builder solidity uses (and extends) all the tools and patterns you know and love. However, the concept of confidential computation being done off-chain by specific SUAVE computors is new and worth emphasizing.

Users can encrypt their transaction data for specific SUAVE computors. Those nodes run the necessary computation (as defined in the public contract referenced in the transaction data), and insert the result into the calldata of a SUAVE transaction that is submitted to the public mempool, ensuring that only the results (and not the input) are broadcast publicly.

This is the way we combine the benefits of public, verifiable mechanisms with private data.

Flow

You can sign and submit transactions as you ordinarily would on Ethereum and they will work as expected.

Fairier Transformers

We describe here what occurs when you want your transaction data to remain confidential.

  1. Create a confidentialComputeRequest and specify a SUAVE computor: i.e. an address whose signature over the confidential computation result will be trusted.
  2. The MEVM instance executes the transaction in confidential mode, creating a confidentialComputeResult.
  3. The confidentialComputeResult is set as the calldata in a "SUAVE transaction", which is broadcast to the public mempool.
  4. We call this a "SUAVE transaction" because it is a normal EVM transaction, with an extra check to make sure that the SUAVE computor's signature matches the requested SUAVE computor in (1)

Please take a look through our how to write builder solidity guide if you want to dive deeper into the specifics of how each step occurs.

Key terms

For clarity, let's define confidentialComputeRequest and confidentialComputeResult, as well as introduce the idea of a confidentialDataStore.

confidentialComputeRequest

  1. confidentialComputeRequest is a request for confidential computation, encrypted to a specfic (set of) SUAVE computor(s).
    1. The "hint", which is some (or all) of an ordinary Ethereum transaction, is set as a "confidential input".
    2. It specifies the address(es) of the SUAVE computor for whom the data in the transaction is encrypted.
    3. A creationTx, which specifies the builder solidity contract that holds the logic which the MEVM instance on the specified SUAVE computor must execute.
    4. The request is sent via eth_sendRawTransaction and is not necessarily sent directly to the mempool.
      1. Before nodes broadcast RawTransactions they receive, they check if there are confidential inputs.
      2. If there are none, the node broadcasts the transaction directly to the public SUAVE mempool, operating in "regular" mode.
      3. If there are confidential inputs present, the SUAVE computor enters "confidential" mode, which uses the MEVM.

confidentialComputeResult

  1. confidentialComputeResult is the result of the confidential computation, shared with the whole SUAVE chain.
    1. Upon receiving a confidentialComputeRequest, the MEVM will enter into the builder solidity contract specified in the creationTx.
    2. This contract will use a precompile like fetchConfidentalInputs that enables the MEVM to fetch data encrypted for it, with which it computes a result.
    3. This confidentialComputeResult is placed alongside the confidentialComputeRequest initially received, and sent to the mempool.
      1. This is all happening in a view function, and we don't want to expose the confidential inputs.
      2. So, this result is really a callback to another function which does permute state, the inputs for which are stored on the SUAVE computor in question, in its confidentialDataStore.
    4. Therefore, confidential execution is not verifiable during on-chain state transition. However, we check that the signature of the SUAVE computor on a SUAVE transaction comes from the public address for which the original request was encrypted.
    5. State transition only depends on the result of the callback in the confidentialComputeResult, so it remains fully reproducible.
    6. SUAVE transactions are propagated through the mempool and inserted into blocks as expected, unifying confidential operation with regular operation.

confidentialDataStore

  1. confidentialDataStore is an offchain data store. Builder solidity contracts tell the MEVM where to store particular information, such that the MEVM can access information other functions (or other contracts) need without storing it in the contract on chain and thereby exposing it to everyone.
    1. Builder solidity contracts tell the MEVM to store data relevant to its operation in specific "keyspaces".
    2. This is done locally, on the specific SUAVE computor for whom the confidentialComputeRequest was encrypted.
    3. It's best to look directly at our how to write builder solidity guide to get a deeper intutition for how this happens.

Pictures

Full Lifecycle of a confidentialComputeRequest

FAQs

1. How do we ensure that a confidentialComputeRequest reaches its intended SUAVE computor(s)?
Ensuring users can send their requests directly to the specified SUAVE computor is an area of active research. One way to do this is to ensure that the logic for sending encrypted messages to their intended recipient lives within SGX, so we can be sure it won't be tampered with.
2. How do SUAVE computors get paid for confidential execution, or how do we protect against spam?
We require a signature for each confidentialComputeRequest. These requests also include a creationTx with a gas price, thereby limiting spam. How to price SUAVE gas correctly without leaking too much information about the nature of the request is an active area of research.
3. How do confidential transactions result in stuff happening (like blocks being built) on other blockchains?
What we describe above occurs on SUAVE. It is the responsibility of applications on SUAVE to broadcast blocks that have been built, or the result of various kinds of auction, back to other blockchains (like Ethereum). At first, we assume that this will happen via already-established relays. You can see a worked example involving block building here.