Understanding Flashbots SUAVE Chain from a Developer's Perspective

Beyond MEV, What Are the Possibilities of EVM + TEE?

*Thanks to George Zhang from Flashbots for helping us understand the technical details.

SUAVE is a decentralized project developed by Flashbots that establishes a network with a TEE (Trusted Execution Environment) to address issues such as key management and multi-party trust encountered in the MEV (Maximal Extractable Value) process. The integration of TEE in the SUAVE project not only solves MEV-related issues but also opens up many other possibilities.

SUAVE Codebase

The SUAVE project is an extension of Ethereum, making it inherently compatible with EVM (Ethereum Virtual Machine). Currently, relevant projects on GitHub include SUAVE-geth, SUAVE-std, and SUAVE-examples.

SUAVE-geth extends the execution layer code based on geth by adding an encrypted computing environment and some precompiles (precompiled contracts) within this secure environment. Notably, it includes a precompile for standard HTTPS requests, allowing developers to provide users with access to other networks using the TEE environment. It also includes a series of precompiles for using TEE functions, such as obtaining encryption parameters, storing encrypted information, and retrieving encrypted information, forming the development infrastructure based on a trusted environment.

SUAVE-std is a project designed for the convenience of developers, essentially a development toolkit. For example, it encapsulates how to use HTTP requests and even includes a library for using ChatGPT, allowing developers to replace their API key when assembling HTTP request messages without manually assembling and parsing ChatGPT's response messages. The TEE environment ensures the security of the API key since all operations occur within the TEE. Initially, this ChatGPT standard library used the GPT-3.5-turbo model with a default temperature of 0.7. Now, it also includes flexible interfaces allowing models to be passed in as parameters.

SUAVE-examples is a project showcasing case studies on application development or beginner tutorials. Developers new to SUAVE application development can learn and compare through the cases in this project.

SUAVE Development Practice

Since SUAVE is an extension of Ethereum (its executable environment is referred to as MEVM, Modified Ethereum Virtual Machine), smart contract development is EVM compatible, and the official development documentation is introduced in Solidity. Therefore, developers can fully leverage their Solidity development experience. Developing smart contracts in SUAVE can be understood as Solidity development with added encrypted computing functions in the TEE environment.

There are several key SUAVE MEVM precompiles. The first is confidentialInputs, which accepts encrypted parameters from application requests. These parameters typically include sensitive information such as private keys or API keys, which must remain plaintext only within the TEE environment. In application development, this interface is used to obtain plaintext information securely. The entire transmission process is encrypted and reliable. The second is confidentialStore, used to store sensitive information when it is not immediately needed for computation. The third is confidentialRetrieve, used to request plaintext data from the TEE environment when sensitive information is needed for computation subsequently.

SUAVE securely stores sensitive information, enabling scenarios like "a user uploads their private key, and a third party performs business calculations. When certain conditions are met, the third party can directly use the user's private key for signing. This allows the third party to use the user's private key for signing under certain rules without ever obtaining the plaintext of the private key."

SUAVE performs cross-chain operations using HTTPS requests. The toolkit includes a library called gateway for directly reading cross-chain information, essentially allowing users to set RPC nodes for certain chains. More commonly, users upload API key information for services like Infura or Etherscan, then use HTTP requests to the respective nodes as needed. For cross-chain writing operations, the toolkit includes a transaction package to help developers encode EIP1559 messages and broadcast transactions through the eth_sendRawTransaction interface.

Another noteworthy use case is uploading and storing the compiled bytecode of a Solidity contract as a confidential parameter and deploying it when conditions are met, forming a private library. This scenario can be expanded to include the private key + private bytecode library, enabling fully private transactions during third-party delegated calls.

SUAVE Features

The ultimate state of SUAVE is a chain, referred to as the SUAVE chain. We can view the SUAVE chain as a chain implementing MEVM. Being an EVM-compatible blockchain, we can also create assets like ERC20 and ERC721 on SUAVE, with on-chain operations similar to other EVM-compatible chains. Its uniqueness lies in integrating off-chain operations, such as sending transactions to nodes of other chains. Off-chain operation results or conditions can be stored on the SUAVE chain, with the stored results guaranteed by consensus. This ensures consistency between off-chain computations and on-chain states. For example, developers can write a smart contract to record or modify conditions on-chain. When accessing a network node of another chain, if the returned result meets the criteria, it triggers the transfer of a pre-determined ERC20 asset.

These are the features brought by off-chain trusted computing in SUAVE. As developed by the Flashbots team and considered "The Future of MEV," handling bundle transactions is inherently supported. The MEV-related principles are straightforward: assemble bundle transactions and send them to Flashbots' relay nodes. Private keys and even code can be securely stored, providing significant potential usage. For instance, builders can receive rewards not only in gas on the target chain but also in digital assets on the SUAVE chain. In the MEV market, flexible business definitions with secure private information are not currently possible (currently, they rely on traditional off-chain trust, contracts, reputation, etc.).

SUAVE Development Tools and Infrastructure

For developers, building a dapp involves not only on-chain smart contract development but also front-end tools like ether.js. In SUAVE application development, since the SUAVE chain is an EVM modification, tools like ether.js and web3.js can be used. These tools interact with smart contracts on the SUAVE chain just like any other EVM-compatible chain but can only call non-confidential functions. A SUAVE chain smart contract involves both on-chain (SUAVE chain) and off-chain (cross-chain operations included) operations, with off-chain operations referring to confidential environment computations. For confidential environment computations, the Flashbots team provides SDKs in two languages (Go and TypeScript), with usage described in SUAVE documentation. When sending a confidential compute request (CCR) involving private calculations to a SUAVE node, confidentialInputs can be included, ensuring that the plaintext of these parameters only appears within the TEE environment.

Finally, the SUAVE chain's testnet, initially named Regil and now upgraded to Toliman, has detailed deployment methods in the SUAVE documentation. The deployment process and post-deployment interaction are similar to Ethereum smart contract deployment.

Kettle

The actual operation of smart contracts on SUAVE differs from Ethereum. The main execution unit in SUAVE is called Kettle, the TEE runtime environment (including an MEVM node and a confidential data store). When developers write and deploy smart contracts, user requests (CCR) involving confidential compute are handled by Kettle.

Kettle structure is as follows:

Developers use Solidity to develop and deploy applications. When requests reach Kettle, MEVM processes them. MEVM includes geth functions with additional precompiles for storing and retrieving confidential data. It also handles the state of the SUAVE chain.

Kettle mainly receives and processes confidential computations and handles confidential data storage and retrieval. For storing confidential data, the process involves the front-end SDK or suave geth tool sending a CCR to a smart contract on the SUAVE chain. The SDK or suave geth tool encrypts the confidential data with a data key (symmetric key), which only appears within Kettle. The SUAVE RPC node only sees ciphertext. Whether Kettle and the node have a one-to-one relationship is unclear from the documentation. However, based on the known encryption process, developers can trust that data protection from the front-end to Kettle's TEE environment is ensured.

Confidential data is stored in the confidential data store, with access and modification rights specified by developers in smart contracts. Kettle publishes through its transport network. If a contract-specific access is specified, subsequent CCR requests must be sent to the same Kettle, as Kettle's data storage is not globally updated. After deploying smart contracts, users access the relevant Kettle (specified in the CCR request) to retrieve confidential data. Data access in smart contracts uses the ID and key established during storage.

HTTP requests and similar operations are also handled by Kettle, which is essentially single-node work outside the SUAVE chain. Given that off-chain resources cannot guarantee idempotency, these are node-dependent operations. Developers must specify Kettle addresses during deployment, and subsequent user CCR requests must include the relevant Kettle address.

A critical point for developers: Currently, on the Toliman testnet, Kettle does not guarantee TEE environment execution. When developing smart contracts on the testnet, ensure confidential data protection to avoid leaking actual sensitive data.

Conclusion

By introducing the TEE environment, the SUAVE chain offers powerful capabilities for application development with numerous potential use cases. Its simple and convenient cross-chain operations provide ample room for dapp design innovation.

The Kettle design in the SUAVE chain, capable of handling off-chain resources, brings verification and consensus challenges. Dishonest Kettles can be destructive to the network. Ensuring Kettles do not act maliciously, or that malicious actions incur penalties or high costs, are issues that need addressing. The SUAVE chain's PoA consensus model's practical viability is something developers eagerly anticipate.