SUAVE smart contract programming model: TEE-based smart contracts for block building

💡

Summary: In this talk, Andrew Miller explains SUAVE and its primary benefits as an open and contestable marketplace for mechanisms. These benefits include trust replacement, decentralized execution, and user programmability. He frames SUAVE first as an ideal functionality and then as a decentralized TEE-based smart contract platform, with decentralized execution through ‘TEE kettles’. Miller discusses TEE deployment and the Motte & Bailey strategy to address common concerns with TEEs. He introduces the idea of 'Builder Solidity' and possible SUAVE apps written in this language with pseudocode. He also shares a hacking insight about “getting rollup for free using TEE”. Finally, he talks about open research questions that still need to be answered. He concludes by emphasizing the multi-faceted nature of SUAVE and the need for a unified understanding of its functionalities. This is the abridged transcript adapted from Andrew Miller’s talk at Flashbots’ TEE party on June 23, 2023 in New York. Slides

Encrypted Mempool is not enough SUAVE: An Open and Contestable Marketplace for Mechanisms SUAVE as an Ideal Functionality SUAVE as decentralized TEE-based smart contracts The TEE Deployment and the Motte & Bailey Strategy SUAVE Programming Examples Flashbots Builder WalruSuave MEV-Share Protected Order Flow (PROF)TEE Smart Contract Insights Open Questions The SUAVE elephant

My background

I recently joined the Flashbots team and, for the past few weeks, I've been meeting with many colleagues from the computer security and distributed systems fields. I have been explaining why I chose to work on Flashbots for my sabbatical project. For those who are either unfamiliar with Flashbots or have pre-existing strong negative interpretations of Flashbots, I've put together a series of slide decks. However, please note that these are fairly opinionated. The following explanation gets many details wrong or oversimplified. Some over simplification is deliberate and intended to dodge rabbit holes and save time.

Flashbots is doing two things: preventing front-running and make back running (arbitrage) benefit users rather than just searchers, without bogging down the network.

I am from the world of computer security research and have experience with zk-SNARKs and Multi-Party Computation (MPC) crypto. Recently, I have been focusing on hardware-based smart contracts, like the Secret Network, which has a private mempool because all transactions in the Secret Network are encrypted.

Encrypted Mempool is not enough

Secret Network's UniSwap V2 clone, Sienna Swap, eliminates the possibility of front-running through encrypted mempool and therefore fair ordering (or more specifically “blind ordering”). However, this alone doesn't solve the whole problem because if you just have fair ordering, you would still have:

Unsophisticated trades create arbitrage opportunities

These are only revealed to arbitrageurs in the next block

Users capture zero of the benefit when the arbitrage eventually occurs

A PGA battle could break out as arbitrageurs fight over top of block position

In this scenario, MEV-Share, another Flashbots protocol, allows back-runners to bid on placing the transaction immediately after the initial one, even in the same block. When bidding, they must share a significant portion of the arbitrage they take back with the original user. Technically, it's implemented as an extraction and redistribution process. Still, I prefer to think of it as an automatic upgrade of a subpar user transaction into a sophisticated arbitrage-free transaction.

SUAVE: An Open and Contestable Marketplace for Mechanisms

Now, how does SUAVE compare to the current status? SUAVE brings three main additions:

Trust Minimization: Replace trust in the operator with trust in TEEs, and/or cryptography and threshold MPC

Decentralized Execution: Make the operation of the service decentralized, geographically and administratively. This is only possible once trust in the operators is replaced with TEEs. But, then, execution can become decentralized and the system can operate with multiple nodes.

User Programmability: These market mechanisms will now be user-programmable because they are written as smart contracts. If users are not satisfied with how MEV-Share distributes MEV among users, they can fork the MEV-Share smart contract and replace it with a different rule.

This also makes SUAVE an open and contestable marketplace for mechanisms because Flashbots doesn't have to design the perfect auction structure; smart contract designers can do so and compete with each other. As a starting point, the aim would be to replicate everything that's in the ecosystem today.

The idea of an open marketplace for mechanisms, similar to SUAVE, was introduced in a paper 20 years ago. Although it did not account for smart contracts and private negotiation, it focused on market efficiency. The paper suggests that aiming for the right level of lightweight components is the best approach, as it is impossible to have the best auction mechanism. This means having an open system where innovative market mechanism components can be composed and interact with each other. Market designers can then innovate on parts of the system, leading to an ecosystem of improving market mechanisms. Smart contracts are currently the only tool available for open composition and innovation, making them a natural fit.

This paper does not delve into the Flashbots “doomer thesis,” which is a natural follow-on. This thesis is that without an open and contestable marketplace, where market designs are public smart contracts that can be examined, analyzed, and forked, the market dominator may become entrenched through private negotiated deals. At that point, it becomes impossible to dislodge them.

SUAVE as an Ideal Functionality

This project is open to cryptography researchers. We use ideal functionalities in cryptography to create a specification that represents a hypothetical trusted third party. Today, we have actual trusted third parties, so the comparison is not far off.

To clarify, assuming we neglect the Trusted Execution Environments (TEEs) and the concept of decentralization, we can envision a trusted smart contract system executed by a central third party, as in this illustration. Cryptographers know to interpret this as a security definition that defines the interface to the actual decentralized implementation.

This interface represents a service specified by smart contracts and private data storage, similar to the Secret Network. The various interface types enable market designers to create and integrate new contracts onto the chain. Users can interact with these smart contracts, while searchers (or arbitrageurs) can receive explicit hints such as MEV-Share hints or anything they can infer from side channels (which should be acknowledged in the specification). This system ultimately produces an L1 block for Ethereum.

SUAVE as decentralized TEE-based smart contracts

In SUAVE, there are smart contracts and a dedicated SUAVE chain that coexist with a mempool of pending SUAVE bids, as well as bids that have been finalized and placed on the chain. However, being committed to the SUAVE chain does not necessarily mean that a bid has been satisfied. Instead, it simply indicates that the bid has been sequenced, ensures data availability, and cannot be ignored on the SUAVE chain.

To avoid potential bottlenecks and latency issues, not all executions occur on the SUAVE chain. Instead, we propose an off-chain execution model. This model essentially becomes a roll-up of a roll-up or a side-chain of a side-chain. The execution is carried out in trusted hardware execution enclaves, which we call TEE kettles. Executors can have access to confidential data through their kettles, but only according to the rules defined in the smart contracts. Every smart contract outlines the program rules for interacting with its private data.

This is my mental model of SUAVE. Think of it as an ecosystem comprising separate market components, represented as contracts. For instance, there's MEV-Share that bundles a user transaction with a backrun. Towards the right hand side, we have larger block bundles, nearly-complete blocks, and finally a PBS export.

Now let's imagine a mempool of pending SUAVE bids. Off-chain execution allows SUAVE blocks to be created faster than L1 blocks, although not infinitely fast. This approach remains realistically performant by enabling concurrent execution of various tasks by separate enclave nodes, each with multiple cores. According to the permission set by contract rules, each node could be doing execution simulation. For instance, in the Secret Network, transactions could be simulated even before they were finalized in a block, which could allow potential MEV extraction. After our SGXonerated security disclosures, they patched this, only allowing execution after block finalization.

However, it would be useful if smart contract authors could approve some functions for local simulation, providing more flexibility to SUAVE app designers. This is a new programming framework design challenge.

The TEE Deployment and the Motte & Bailey Strategy

Here are some arguments to address the natural concerns of TEE. The "Motte & Bailey" concept from military can also be applied here. The concept is that you want people to work in the field where it is sunny and you have all of your crops, but you are spread out. When you are attacked, then everyone retreats to motte (the fortress), but it is dank and musty there and you cannot work in the field. So, you want to be in the bailey whenever possible and retreat to the motte when necessary.

There are various ways to deploy TEE, each with its own level of security. The most aggressive approach, similar to the bailey, is adopted by the Secret Network. Here, anyone with a TEE can join, regardless of their location. However, you have no control over who is running the TEEs, and they may have physical access to them.

Over time, there have been numerous security vulnerabilities on SGX. Some of these vulnerabilities can be exploited remotely through software, which is the worst case scenario. Other, harder-to-exploit vulnerabilities would at least require physical access to exploit. In this deployment scenario, even the narrower type of vulnerabilities would be problematic, as individuals may have physical access to their own nodes.

An intermediate approach would be to only permit approved cloud vendors to run the TEE kettles. While anyone could have an account in any country where these cloud providers offer services, you would rely on the security provided by these cloud vendors. Although exploiting a vulnerability could be profitable, the cloud providers would be unlikely to do so, as it could harm their business reputation and jeopardize lucrative enterprise deals.

On the extreme end, or the motte, you could use multi-party computation (MPC) or Threshold fully homomorphic encryption (FHE) where multiple nodes perform each interaction. This means that even if one node is breached, no useful information can be extracted unless some number of the nodes are compromised.

These are all possible solutions, and they could even be dynamically implemented. For example, when a new vulnerability emerges, access to physical access nodes could be shut off temporarily, and the system could run only on reputable cloud providers. It's important to note that this is a bit of a grey area, and these solutions aren't meant to completely convert someone who dislikes the TEE approach. However, it's important to realize that we aren't just talking about the worst-case scenario operating point.

SUAVE Programming Examples

The main topic of this talk is viewing SUAVE as explicitly implemented with smart contracts, specifically using the programming language Solidity Builder. Solidity Builder is essentially Solidity with additional pre-compiles in your EVM (shall we call it “MEVM”?) that are useful for building blocks and simulating EVM transactions. For example, you can use keywords that refer to Ethereum L1 and simulate EVM transactions passed as data using a pre-compile that can do so efficiently.

Flashbots Builder

To illustrate this, consider this pseudocode for the Flashbots builder. This builder process involves two steps:

Simulate all the bundles as if each bundle was the only one in the block.

Sort these bundles based on their estimates, and then conduct a confirmation pass by simulating them in order. If the bundles fail during this step, or if their estimates deviate significantly, they are discarded.

Since the builder logic is now implemented in available code, you can fork it and modify the builder functions as desired. To get your implementation adopted, simply convince users to send transactions to it.

WalruSuave

An exciting proposal for a SUAVE app is the WalruSuave, proposed by one of the new Flashbots researchers, Sergio. This app aims to optimize the processing of batches of Uniswap transactions. The proposed steps are as follows:

Determine which transactions can settle amongst themselves first, in order to avoid paying unnecessary fees to liquidity providers.

Process these bids and forward the residual demand to Uniswap's pools.

This process can be modeled in pseudocode with two entry points. The first is submit_bid, which submits the bid to this contract and adds it to a storage location. This storage is encrypted and only processed by hardware enclaves, keeping your quantity and reserve price hidden. The second entry point, process_bids, handles the settling and forwards the bundle to the builder contract.

MEV-Share

Another significant concept here is MEV-share, which can be modeled as a contract with three entry points:

One to submit a bundle and specify what hints you want to reveal.

Another to submit a blind arbitrage. It does not simulate it, rather just packages the bundle and forward that onto builder contract.

The third is to give user the kickback by modifying the builder contract.

Protected Order Flow (PROF)

An interesting point to consider is how fair ordering fits into the SUAVE process and how it can be implemented. Fair ordering is indeed compatible with SUAVE and can be treated as a special case. One possible implementation is to create a fair ordering PROF-style builder contract that enables PROF blocks to bypass any simulation required to estimate them for ordering. So they simply get added at the end of the block.

TEE Smart Contract Insights

To delve a bit further into this notion of off-chain smart contract-driven computing: at the recent IC3 summer hackathon, we explored the use of this approach for Secret Network. One of the vulnerabilities we disclosed in Secret Network is access pattern leakage, which compromises the privacy of senders and receivers. To address this, we propose implementing off-chain oblivious RAM, which is less expensive than doing it on-chain. The interesting thing is that it doesn't require a new system or separate rollup for Secret Network. The concept involves performing computations off-chain and then putting the results back on-chain.

In a rollup, you typically need a SNARK proof or an optimistic fault proof, but in the TEE world, you can use a signature from the TEE smart contract instead of a SNARK. The TEE has a secret signing key, so only the TEE running that smart contract can produce a signature under that public key associated with the smart contract. As long as you trust the TEE model, you already have cheap roll-ups in the existing TEE-based smart contract programming model.

For example, if you want to perform a linear scan concurrently (touching everything regardless of the item you are actually accessing), you can do so using read-only views. Each view can output an encrypted and signed updated state, which is computationally expensive but doesn't require gas payments. Only the output of the query needs to go back on-chain, where it can be easily verified. To recap, this is a new smart contract programming model, that’s like a roll-up already but it’s already available on Secret Network. The same programming model can be used for SUAVE to perform off-chain distributed block building.

Open Questions

Designing MEV-Share is a pure mechanism design challenge. It is a novel mechanism that does not exist anywhere else. For example, it's conjectured that MEV-Share outperforms PROF for every user. These topics are ripe for research and analysis.

There is also question regarding ideal functionality model, like whether we can instantiate the design from an ideal functionality of TEE-based smart contracts.

An open question in our research concerns the programming model for Builder Solidity. Since Solidity is widely used for Ethereum development and based on the principles of least surprise, the design should strive to mirror familiar patterns of Solidity, unless there are compelling reasons to deviate. This will provide a consistent foundation for developers and potentially ease the transition to this new technology.

However, note that one key consideration in this context is the need to incorporate privacy settings and the use of signatures. While these aspects may be familiar territory for those who have experience with privacy-centric platforms such as Oasis and Secret Network, they might be less well-known in the broader developer community.

This is also an opportunity for developers to consider the types of SUAVE apps they want to create and how to make them. It's a good time to gather input on what pre-compiles make sense and what programming patterns might emerge. Developers can start with existing designs from the transaction supply chain, customize them to improve and innovate, and help guide the design of the SUAVE framework.

The integration of cryptography with TEEs to make them interoperable is also still an open question, leaving plenty of challenges for innovation and research.

The SUAVE elephant

In wrapping up, it's important to mention that SUAVE, like the parable of the blind men and the elephant, is viewed and understood in many different ways by various stakeholders, including within Flashbots. These viewpoints are not incompatible, but they do emphasize different aspects and come with different interpretations. The aim of this discussion is to attempt to bring together these disparate understandings and offer a more unified and comprehensive perspective of SUAVE. This is a collective endeavor to help all of us grasp the 'whole elephant'.