Bitget App
Trade smarter
Buy cryptoMarketsTradeFuturesCopyBotsEarn

Understanding Flashbots' SUAVE chain from a developer's perspective: In addition to MEV, what other possibilities are there for EVM + TEE?

BlockBeatsBlockBeats2024/08/08 12:00
By:BlockBeats

SUAVE is a decentralized project developed by Flashbots. It establishes a network with a TEE environment to solve problems encountered in the MEV process such as key custody and mutual trust among multiple parties.

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 such as key custody and multi-party mutual trust encountered in the MEV process. At the same time, the addition of TEE in the SUAVE project gives SUAVE more possibilities besides solving the MEV problem.


SUAVE related code library


The SUAVE project is based on Ethereum extension, 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 extended on the basis of geth. It mainly adds an encrypted computing environment on the basis of geth, as well as some precompiles in the encrypted computing environment. It is particularly worth mentioning that the precompile of the standard HTTPS request has been added, which allows developers to use the TEE environment to provide users with the function of accessing other networks. In addition, it contains 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 established for the convenience of developers and can be understood as a development tool library. For example, it wraps how to use HTTP requests, and even wraps a code base that uses ChatGPT on this basis, so that developers do not need to assemble ChatGPT request messages and parse ChatGPT 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 cases of how to develop applications, or it is more appropriate to say that it is a beginner tutorial. For developers who are new to SUAVE application development, they can learn and compare through the cases in this project.


SUAVE development practice


Since SUAVE is based on Ethereum extensions (its executable environment is called MEVM, i.e. 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, the development of smart contracts 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 the encrypted parameters from the application request. 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, it is often not needed to participate in the calculation at that time, so it is stored 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 that directly reads cross-chain information. Its essence is that the user sets 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 writing is required, 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 a third-party delegated call is made, 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 and ERC721 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 off-chain calculation and the on-chain state can be consistent. For example, developers can write a smart contract, record some conditions on the chain (which can also be modified), and when a certain chain network node is accessed and the returned result meets the requirements, 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 (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 transformation, 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 smart contract on a SUAVE chain 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 calculations. 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 (the Flashbots team calls it a Confidential Compute Request) to a SUAVE node, you can bring in confidentialinputs, which are private parameters. During the entire transmission process, the final 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 now it has been upgraded to Toliman. The deployment method is described in detail 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 method is different from that of Ethereum. The most important execution unit of SUAVE is called Kettle. Kettle is the TEE operating environment of SUAVE (it includes a MEVM node and a confiditial data store). When the developer writes a smart contract and deploys it, 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 to it, which can store and retrieve private data. In addition, it also processes (including modifying and retrieving) the status on the SUAVE chain.


The main work of Kettle is to receive and process private calculations, as well as to store and retrieve private data. Taking the storage of private data as an example, the whole process is as follows: the user front-end uses SDK or suave geth tool to initiate a CCR request to a smart contract on the SUAVE chain. 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 and nodes are one-to-one 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 publish it 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 globally updated. 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.


Related HTTP requests, etc. are also processed by Kettle. Obviously, these are tasks outside the SUAVE chain, that is, 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.


Summary


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 design of the SUAVE chain is capable of processing off-chain resources, which brings up the problems of verification and consensus. A dishonest Kettle is destructive to the network. How to ensure that Kettle does not do evil, or that it can be punished for doing evil, or that the cost of doing evil is high enough, these are all problems that need to be solved. The PoA model adopted by the consensus of the SUAVE chain, whether it can withstand practical considerations, developers are still waiting to see.


Original link


0

Disclaimer: The content of this article solely reflects the author's opinion and does not represent the platform in any capacity. This article is not intended to serve as a reference for making investment decisions.

PoolX: Stake to earn
CEC, QTLX, GDV and other popular new coins are in hot progress!
Stake now!