Original title: "Understanding Flashbots' SUAVE chain from a developer's perspective: In addition to MEV, what other possibilities does EVM + TEE have?"

Original author: ZHIXIONG PAN, DUGUBUYAN, ChainFeeds Research

The SUAVE chain brings enough powerful capabilities to application development by introducing the TEE environment, and its potential application scenarios are very numerous. In addition, its simple and convenient cross-chain operation also brings enough imagination space to the design of Dapp.

SUAVE is a decentralized project developed by Flashbots. It has established a network with a TEE environment to solve problems encountered in the MEV process, such as key custody and multi-party mutual trust. At the same time, the addition of TEE to the SUAVE project gives SUAVE more possibilities besides solving MEV problems.

SUAVE related code base

The SUAVE project is based on Ethereum extensions, so it is inherently compatible with EVM. Its current related projects on GitHub include: SUAVE-geth, SUAVE-std, SUAVE-examples, etc.

Among them, SUAVE-geth is the execution layer code that is extended on the basis of geth. It mainly adds an encrypted computing environment and some precompiles in the encrypted computing environment. It is particularly worth mentioning that the precompile of standard HTTPS requests has been added, which allows developers to use the TEE environment to provide users with the function of accessing other networks. In addition, it includes a series of precompiles based on TEE usage functions, such as obtaining encryption parameters, storing encryption information, and obtaining encryption information, which constitute the development infrastructure based on a trusted environment.

SUAVE-std is a project built for developers to use conveniently, and can be understood as a development tool library. For example, it packages how to use HTTP requests, and even packages a code library that uses ChatGPT on this basis, so that developers do not need to assemble ChatGPT's request messages and parse ChatGPT's return messages by themselves. They only need to replace their own API key when assembling HTTP request messages. The TEE security environment ensures the security of the API key because all this is done in the TEE environment. Initially, the standard library of ChatGPT used the GPT-3.5-turbo model by default, and the temperature defaulted to 0.7. Now a flexible interface has been added, and the model can also be passed in as parameters.

The SUAVE-examples project is mainly to show some examples of how to develop applications, or it is more appropriate to say that it is a beginner's tutorial. For developers who are new to SUAVE application development, they can learn and compare with the examples in this project.

SUAVE Development Practice

Since SUAVE is based on Ethereum extensions (its executable environment is called MEVM, or Modified Ethereum Virtual Machine), the development of smart contracts is EVM-compatible, and the official development documents are all introduced in Solidity. Therefore, for developers, Solidity development experience is fully useful. In SUAVE application development, smart contract development can be understood as Solidity development with encrypted computing functions in the TEE environment.

There are several key SUAVE MEVM precompiles. The first one is confidentialInputs. This precompile accepts encrypted parameters from application requests. This parameter is usually some private information that needs to be encrypted, such as private keys, API keys, etc. Its security must require that its plain text can only appear in the TEE environment. In application development, this information is obtained through this interface. The transmission process is fully encrypted and safe and reliable. We will talk about its principle later. The second one is confidentialStore, which is used to store private information. When we get private information from the parameters, we often don’t need it to participate in the calculation at that time, so we store it for subsequent use. The third one is confidentialRetrieve. This interface is used to request data plain text from the TEE context environment when private information is needed for calculation in the future.

SUAVE's secure storage of private information allows developers to achieve the following scenario: "The user uploads the private key, and then the third party performs business calculations. When the conditions are met, the third party can directly use the user's private key to sign. In this way, the third party can use the user's private key to sign under certain rules, but the third party will never be able to obtain the private key plaintext."

SUAVE uses HTTPS requests for cross-chain operations. There is a library called gateway in its tool set for direct cross-chain information reading. Its essence is that users set the RPC node of a certain chain. More commonly, users upload API key information such as Infura and Etherscan, and then directly use HTTP requests to the corresponding node when they need to call. When cross-chain information needs to be written, there is a transaction package in the tool set that can help developers encode messages such as EIP1559, and finally broadcast transactions through the eth_sendRawTransaction interface.

Another use case worth mentioning is uploading and storing the compiled bytecode of Solidity as a private parameter, and deploying and calling it when the conditions are met, thus forming a private library. This use case can be expanded to: private key + private bytecode library. In this way, when making a third-party delegated call, a completely private transaction can be achieved.

SUAVE Features

The final state of SUAVE is a chain, which we call the SUAVE chain. We can regard the SUAVE chain as a chain that implements MEVM. Since it is an EVM-compatible blockchain, we can also build assets such as ERC20, ERC721, etc. on SUAVE, and its on-chain operations are no different from those of the EVM series of chains. However, its uniqueness lies in the addition of off-chain operations, such as sending transactions to nodes of other chains. The results of off-chain operations or usage conditions can be stored on the SUAVE chain, and the stored results are guaranteed by consensus. In this way, the consistency of off-chain calculations and on-chain states can be achieved. For example, developers can write a smart contract, record some conditions on the chain (which can also be modified), and when accessing a certain chain network node, the returned results meet the requirements, and a pre-set ERC20 asset transfer is performed.

The above are all features brought by SUAVE's off-chain trusted computing. We know that SUAVE was developed by the Flashbots team, and SUAVE is regarded by the Flashbots team as "The Future of MEV", so bundle transaction processing must be available. Based on the SUAVE chain in a trusted environment, the MEV-related principle is very simple: assemble bundle transactions and send them to the Flashbots relay node. Private keys can be stored privately, and even codes can be stored privately, which constitutes a huge potential for use. For example, in addition to the gas reward on the target chain, the builder can also obtain certain digital assets on the SUAVE chain. For the MEV market, it is possible to flexibly define business while ensuring the security of private information, which is something that MEV cannot do at present (currently it can only provide traditional off-chain guarantees based on trust, contract, goodwill, etc.).

SUAVE development tools and infrastructure

For developers, in addition to on-chain smart contract development, front-end development tools such as ether.js are also an important part of a dapp's development. In the development of SUAVE applications, because the SUAVE chain is based on EVM, tools such as ether.js and web3.js can also be used. These tools are no different in interacting with smart contracts on the SUAVE chain and other EVM-compatible chains, but can only call functions in non-confidential environments. A SUAVE chain smart contract is divided into on-chain (referring to the SUAVE chain) and off-chain (cross-chain operations are also considered this category) operations. Off-chain operations actually refer to confidential environment computing. For confidential environment computing, the Flashbots team provides SDKs in two languages ​​(Go and TypeScript), and the usage is introduced in the SUAVE documentation. When sending a privacy computing transaction (called Confidential Compute Request by the Flashbots team) to a SUAVE node, confidentialinputs, which are private parameters, can be passed in. During the entire transmission process, the plain text of this parameter will only appear in the TEE environment.

Finally, when it comes to the deployment of smart contracts, the test network of the SUAVE chain is called Regil, but it has now been upgraded to Toliman. The deployment method is detailed in the SUAVE document. The deployment method, post-deployment interaction method, etc. are no different from the deployment of Ethereum smart contracts.

Kettle

After the smart contract is deployed, its actual operation mode is different from that of Ethereum. The main execution unit of SUAVE is called Kettle. Kettle is the TEE operating environment of SUAVE (it includes a MEVM node and a confidential data store). When the developer writes and deploys the smart contract, the user sends a confidential compute request (hereinafter referred to as CCR). When the smart contract needs to use confidential compute, it is actually run by Kettle.

The structure diagram of Kettle is as follows:

We can see that developers use the solidity language to develop and deploy applications. When the final request reaches Kettle, it is all processed by MEVM. In addition to the functions of geth, MEVM also adds some precompiles on it, which can store and retrieve private data. In addition, it also processes (including modifying and retrieving) the status on the SUAVE chain.

Kettle's main job is to receive and process private calculations, as well as to process private data storage and retrieval. Taking the storage of private data as an example, the whole process is as follows: the user front-end uses the SDK or suave geth tool to initiate a CCR request to a smart contract on the SUAVE chain. The SDK or suave geth tool will use the data key (symmetric key) to encrypt the private data. This data key will only appear in the Kettle environment, and SUAVE's RPC node will only see the ciphertext. Whether kettle has a one-to-one relationship with the node is not seen in SUAVE's documentation. Similarly, the detailed principles of Kettle itself, nodes, and key exchange are not introduced in the document. However, based on the known encryption and decryption process, developers have reason to believe that the protection of private data can be guaranteed from the user front-end to the Kettle internal TEE environment.

The private data Kettle will be stored in the confiditial data store. When the developer develops the smart contract, he will specify the accessor and modifier of the data. Kettle will be published through its Transport network. If the contract is specified for access, the subsequent CCR request must also be sent to this Kettle, because the data storage of Kettle is not updated globally. After the developer deploys the smart contract, the user accesses the corresponding Kettle (there is a parameter in the CCR request, and the Kettle address must be specified), and its private data can be accessed. When the user sends a CCR and requests private data in the smart contract, the ID and key established when the corresponding data is stored are used for retrieval. In other words, private data access is accessed and used through its key value.

Regarding HTTP requests, Kettle also handles them. Obviously, these are tasks outside the SUAVE chain, which means that these tasks are run by a single node. Although SUAVE is a chain, its blockchain properties are weak. When Kettle runs CCR requests, there will not be many nodes running and then verifying. The reason is simple. Accessing resources outside the chain cannot guarantee a certain idempotence. Therefore, the results of these tasks outside the SUAVE chain are actually dependent on the node. Therefore, developers should pay attention to the Kettle address when deploying (from this point of view, Kettle can be regarded as a special smart contract), and subsequent user CCR requests must carry the corresponding Kettle address.

In addition, there is another issue that developers should pay attention to. On the current test network Toliman, kettle is not guaranteed to run in the TEE environment. Therefore, when developing smart contracts on the test network, pay attention to protecting private data and do not leak real private data.

Summarize

The SUAVE chain brings enough powerful capabilities to application development by introducing the TEE environment, and its potential application scenarios are very numerous. Its simple and convenient cross-chain operation also brings enough imagination space to the design of Dapp.

The Kettle of the SUAVE chain is designed to handle off-chain resources, which brings up verification and consensus issues. A dishonest Kettle is destructive to the network. How to ensure that Kettle does not do evil, or that evil can be punished, or that the cost of doing evil is high enough, these are all issues that need to be solved. The PoA model adopted by the consensus of the SUAVE chain is still waiting to see whether it can withstand practical considerations.

Original link