Introduction
The previous article in the series explored the reliance on trusted actors in the present Ethereum ecosystem, namely in Order Flow Auctions (OFA) and the implementation of Proposer-Builder Separation (PBS). These are just two examples of solutions that are beneficial to the users and ecosystem, yet heavily rely on trusted actors. Their trust reliance presents ecosystem risks in the form of centralization, censorship, single point of failure, and high barrier of entry.
The current compromises, though understandable given the solutions that are available today, cannot be the endgame. The search for alternatives is needed and the challenge lies in minimizing the reliance on trusted actors while offering performant and inexpensive computation, privacy, access to off-chain sources, and enabling rapid coordination within Ethereum's block time.
Numerous teams are exploring various solutions to address this challenge, and Flashbots' SUAVE is one of them.
The approach Suave takes aims to create a platform where trusted actors participating in the ecosystem today can be replaced by a set of "magic" specialized privacy-preserving hardware, known as a trusted execution environment (TEE), alongside a censorship-resistant chain managing them.
First, let's clear up what TEEs are and why some people see these "magic boxes" as a necessary stepping stone toward building the future of crypto, while others see it as flawed technology that has no place in the ecosystem.
Trusted Execution Environments
Trusted execution environment (TEE) is a secure area within a processor, isolated from the rest of the system and other hardware components. This isolation ensures that even the system's root user cannot access or alter what's occurring inside the TEE. This is particularly beneficial for privacy-preserving applications, especially in scenarios where users might distrust the entity operating and managing the service.
Therefore, even if the service is operated by someone untrustworthy, sensitive data sent for processing remains safe, assuming the hardware's integrity. That said, it is worth noting that the operator could still interfere with the delivery of the messages between the user and TEE.
This sounds very useful, but couldn't the operator just lie and claim the service is running in TEE although it isn't, or claim that a certain program is running on the TEE while it is actually a malicious one revealing your private information?
Fortunately, there is a way to check this! TEEs offer a process for verification, known as remote attestation, to ensure that the service indeed runs in a TEE and that the program on it is what it is expected to be.
Great! But a TEE is part of the processor, so aren't its storage capabilities limited? How can we expect to run any application requiring more than a few hundred megabytes of storage?
To address this, a TEE can interact with external storage and memory components and use encryption to maintain data confidentiality. Similarly, asymmetric encryption is used for secure communication with the outside world, with a TEE's private key baked into the hardware at the time of manufacture. This key is not accessible to anyone outside the secure enclave, not even to the manufacturer or the user of the device.
Sure, but wouldn't constant encryption and decryption of low-level messages affect the performance? Is it actually feasible to run a complex computation on it?
In March 2023, Flashbots successfully built a block with a block builder in a TEE first on the Ethereum Sepolia testnet and later mainnet; demonstrating that running core components of Ethereum is not just a theory but is practically achievable. Although the blog post detailing this demonstration notes that the TEE builder's performance was half that of a non-TEE builder, it also mentions significant potential for improvements in the implementation that could narrow this performance gap.
So is this technology only for experimental products like this block builder and research purposes or can we actually already use it?
One might be surprised that it is already in the pockets of many among us. Users of the latest iPhone use Apple's implementation every day while unlocking their phones or accessing their storage. Similarly, major cloud providers such as Azure, Google Cloud, and OVH Cloud offer confidential computing enabled by Intel’s TEE implementation Software-Guard-Extension (SGX). The latter was also the choice for Secret Network, Avalanche bridge, and mentioned Flashbots’ block-building demonstration, among others.
Okay, so does that mean we just spin up a TEE node and all trust assumptions vanish?
Replacing a trusted party with a TEE doesn't mean that all the trust assumptions vanish. Instead, one still has to trust in the manufacturer's ability to create secure hardware and rely on the operator's liveness. Regularly discovered exploits show this shouldn't be taken lightly.
Andrew Miller, a core researcher working on SUAVE, was part of the team that exploited SGX vulnerability on Secret Network and BluRay discs detailed on https://sgx.fail/. This was just one of many SGX vulnerabilities warning us that even though SGX is secure and very difficult to break, it is not wise to blindly go all-in with it.
Although it is difficult to account for all limitations of TEE, being vigilant, implementing safeguards against known vulnerabilities and avoiding shortcuts could mitigate against the known attack vectors. Likewise, a careful design around TEE could limit the extent of the damage and the window of opportunity when TEE’s security is compomised.
For protocol and application designers it is important to consider that the damage an attack could cause is limited to the value of the revealed information at the time of the attack. So, while revealing a social security number or private key associated with managing a cross-chain bridge would be devastating, revealing your trade intention from a month ago wouldn’t carry the same level of risk.
In short:- Confidential computing: Even the system admin can’t access or alter the process in TEE.
- Verifiable: Remote attestation offers a way to verify the authenticity of programs running in TEE.
- Performant enough: TEEs are less performant than non-TEE counterparts, yet good enough to run something like a competitive block builder.
- Trust minimizing, not trustless: TEEs still require trust in the manufacturer and the operator’s liveness.
- Vulnerabilities expected: TEEs were and still could be exploited in the future, thus requiring vigilance, careful security considerations, and limiting the extent of the damage in a potential attack.
With a better understanding of what TEEs can offer, let's look at how SUAVE plans to use them to reduce trust assumptions associated with trusted actors in the present ecosystem.
Learn more about TEEs from Flashbots compiled resources on the subject, along with a blog post addressing misconceptions about SGX.The missing piece?
At the beginning of the article, we indicated that the current ecosystem is in need of a solution that minimizes trust assumptions yet delivers affordable, private computation and storage, along with off-chain access and speedy resolution.
With what we now know about TEEs, could they fill this void?
Unlike current blockchain technology, TEEs do indeed offer access to external resources, speedy resolution, and privacy. And although it is true they are not a match for the performance of non-TEE units, they are nonetheless capable of performing intensive computations at a low cost. At the very least, significantly better than any existing "trustless" solution.
Likewise, they do indeed minimize trust. Although not to the likes of a blockchain like Ethereum, but still better than existing solutions offering similar performance as TEEs do. Moreover, the trust assumptions could be minimized further by coupling TEEs with other security measures.
The takeaway seems to be that while there are alternatives surpassing TEEs in either performance or trust minimization, TEEs stand out as a compelling choice when a balance of both performance and privacy is needed. They may not excel in individual aspects compared to specialized solutions, but their combined strengths make them a viable option for scenarios requiring both efficient computation and reduced trust. This is exactly what is needed to replace present trusted actors with more trust-minimizing alternatives.
Don't take my word for it, in the following recordings from ETHDenver 2023, Phil Daian and Andrew Miller consider the risks and benefits of using SGX to replace some of the present trusted actors in the ecosystem and compare it to alternatives, like ZK, and MPC - Why TEEs suck both less and more than you think, Private Smart Contracts are Worth the Price of the SGX.
Establishing that TEEs could be the right direction, what does this mean in reality? Do we just replace trusted actors behind PBS or OFA with a single TEE and call it a day?
Why a TEE on its own is not enough
OFA using a single TEE might work for a few users, but how can we realistically scale for the ever-increasing demand for the service? Moreover, what happens if this single TEE goes down - it would be great to avoid a single point of failure. Therefore, ideally, we need multiple interconnected TEEs - a network of them!
However, like a single TEE node, a network of TEEs also isn't infallible. We can learn from Secret Network's data reveal in 2022 that it is not wise to place all your security assumptions solely on TEEs. Other security measures around the network of TEEs could help us mitigate this.
Also, someone needs to verify that specific computation is performed on TEEs and that the code being run is what it is promised to be.
This highlights a need for other entities in the system or a set of them that will validate the network of TEEs in a credible and permissionless manner. Unlike the use cases we explored earlier, this attestation network can be public and transparent like the already implemented blockchains we see today.
This public chain can also serve as a place to host programs as well as a store of other information that would benefit from being transparent and verifiable. The users would want to know what programs they will run, much like it is the case with the smart contract we see today. Additionally, hosting them in a public place not only makes them transparent, but also benefits from composability.
As a result, we get a network of TEEs alongside a public credible permissionless chain, managing them and hosting information such as programs to be run in the TEE. This is a rough idea of SUAVE.
With the reasoning behind SUAVE, let's look at how Flashbots plans to implement it.
Broad SUAVE Architecture
SUAVE is planned to be composed of a network of nodes living in TEEs called Kettles and SUAVE chain, a permissionless public chain accompanying it.
One of SUAVE chain's roles is to serve as a place to deploy programs to be executed in the TEE environment, called suapps, short for SUAVE Applications. Users could interact with these programs publicly via SUAVE chain or confidentially through a Kettle.
Kettles will have access to:
- SUAVE chain: Access to public storage and programs living on it;
- Confidential storage broadcasted between Kettles;
- Cheap performant computation;
- Domain resources: eg. Ethereum node running alongside the Kettle;
- External resources: Coingecko, Binance...
Flashbots envisions different versions of Kettles suited for different application requirements - while one suapp might need more storage, the other might require more performance or access to a specific domain (eg. Solana). Likewise, the Kettles are designed to support various VMs. The first iteration of an EVM based VM is already live, enabling developers to utilize familiar tools and expertise from other EVM chains, and there is already some work done for support of WASM.
Deeper down the rabbit hole
SUAVE is not just a theory or merely a plan, you can already interact with the early version of it today!
In the next piece, we will explore how the latest version of SUAVE (Rigil) works under the hood, what features it offers, and walk through an example application.
Special thanks to A. Miller, Dmarz, Turan Vural, Can Kisagun, Lily, L.V. and Eden team members for feedback and suggestions.
Note that the article contains assumptions and conclusions that are only my interpretations based on the available information and do not necessarily reflect the stance of Eden Network or Flashbots.