MEV BooTEE: Partial Block Building with TEEs

General Goals

(Main) Increase proposer's power:

• Proposer can specify transactions to be included

Reduce reliance on the relayer:

• Remove trust assumptions for the relayer
• Reduce the work performed by the relayer

(Bonus) Improved block building guarantees

• Build block inside the TEE

Overview

There are three entities involved:

1. Builder - has an ordering of transactions that must be preserved
2. Proposer - has the right to propose a block
3. Relayer - holds block auctions and proxies Builder-Proposer communication to prevent either from cheating; requires trust from both Builder and Proposer

The Role of the Relayer

Currently, there is a powerful assumption that the Relayer is honest. We want to remove this assumption and enforce stronger guarantees by forcing the Relayer to behave honestly. One way to achieve this is by running the logic of the Relayer inside a TEE - the trustworthyness of the Relayer is now provable, instead of assumed.

Running the Relayer logic inside a TEE ensures that:

1. The Builder's bundle is not unbundled and the transaction order is maintained.
2. The auction is fair and profitable for the Proposer.

To this end, we designed various approaches that rely on a TEE to put together a block that contains a ToB (Top of Block) coming from a Builder, and an RoB (Rest of Block) coming from a Proposer:

1. The first approach is to replace the Relayer with a TEE-enabled system that allows Builders to bid for ToB. The ToB that wins the auction is combined with the RoB submitted by the Proposer to assemble a block. We call this new system the TEE Assembler.
2. The second approach is to run the Assembler logic inside a TEE deployed at either the Proposer's or Builder's end. This TEE is called a TEE Aide and replaces the need to run an Assmbler as a separate entity. Since the TEE Aide can be deployed at either the Builder or the Proposer, we present two distinct solutions: Proposer Aide and Builder Aide.
3. The third approach is to fully build the block inside a TEE using an RoB coming from the Proposer - full TEE partial block building.

Design Decisions

There are a couple of things we considered while designing these approaches, the most important being:

• Who runs the TEE? - This will greatly impact how many systems need to be enhanced with a TEE.
• Who holds the auction?
• What is the communication model: who initiates the connection and how many rounds are there?
• What runs inside the TEE? - It is important to note that in all approaches, the RoB will only be sent to the TEE logic to prevent unbundling.

The table below summarizes how each of these approaches tackles these questions.

	Assembler	Proposer Aide	Builder Aide	Full Builder
Who runs the auction	3rd party (Relayer)	Proposer	Proposer	Proposer
Who runs the TEE	3rd party (Relayer)	Proposer	Builder	Builder
What runs in the TEE	auction, bid computation, block assembly	auction, bid computation, block assembly	bid computation, block assembly	bid computation, block assembly
Connection Model	n to 1 (Builders to Assembler), 1 to 1 (Proposer to Assembler)	1 to n (Proposer to Builders)	1 to n (Proposer to Builders)	1 to n (Proposer to Builders)

Apart from these choices, we also need to answer the following question: how computationaly intense should the work done inside the TEE be? This questions is related to how bid computation and block assembly are being performed.

Default Computation

Bid Computation: One of the reponsibilities of the Relayer is to ensure that the bid advertized by the Builder is correct. By default, the TEE will compute the value associated with each ToB submitted by Builders.

Block Assembly: The job of the TEE is to put together a ToB and an RoB. By default, the TEE will ensure that the ToB and RoB do not include transactions that conflict with each other.

Optimistic Computation

Bid Computation: With optimistic computation, the TEE will collect collateral from the Builder and assume that advertized bids are legitimate. If a bid turns out to be untruthful, the TEE will slash the Builder and compensate the Proposer.

Block Assembly: With optimistic computation, the TEE will ensure that the ToB and RoB do not contain the same transactions, but will not do any more verifications. I.e., if a transaction in the RoB conflicts with the ToB, it will be reverted.

TEE Assembler

Replace the Relayer with a TEE Assembler: the Assembler receives partial blocks (ToBs) from Builders, and a list of transactions (RoB) from the Proposer and will select the block with the highest bid.

1. TEE Assembler receives partial blocks from multiple Builders. The bids are computed and ordered.
2. The Proposer submits a transaction list and asks for a block from the TEE Assembler.
3. TEE Assembler combines the ToBs and the RoB (this can be done in parallel) to find the block that is most profitable for the Proposer.
4. TEE Assembler returns the header of the block to the Proposer.
5. If the Proposer selects the block, it will send the signed header to the TEE Assembler.

The transaction list submitted by the Proposer can contain transactions that MUST be included, and transactions that COULD be included. The TEE Assembler will ensure that MUST include transactions are in the block (either ToB or RoB), and COULD include transactions are included "best-effort". We can define more ways for the Proposer to specify how to include transactions in the future.

Disadvantages:

1. There must be an altruistic thrid party (TEE Assembler) with even more duties compared to the Relayer.

Exposed APIs

For Builders:

- submit_tob(block_number, txns) -> id
- retract_tob(id) -> bool

For Proposers:

- get_highest_bid(block_number, inclusion_list) -> (bid, header)
- commit_header(signed_header) -> bool

Embedded Approaches

This section explores how we can embed the logic of the Relayer inside either the Builder or the Proposer. We refer to this logic as the TEE Aide.

Proposer Aide

Proposer employs a TEE module that knows the private key of the Proposer and can sign on behalf of the Proposer.

The TEE-Aide holds an auction for the ToB selecting the Builder that submits the ToB with the highest bid. Below we describe the interaction between the selected Builder and the TEE Aide:

1. Proposer sends a list of transactions to the TEE Aide.
2. Builder sends ToB and bid to TEE Aide.
3. TEE Aide computes the bid of the ToB.
4. TEE Aide includes as many transactions from the list specified by Proposer.
5. TEE Aide releases the block to the Builder.
6. TEE Aide releases the block to the network.

The TEE Aide will first release the block to the Builder to give the Builder the chance to propagate it to its preferred peers. The TEE Aide will release the block to its peers before it's too late in case the Builder does not propagate it.

Disadvantages:

1. TEE Aide is controlled by the Proposer. A malicious proposer may try to get access to the ToB by mounting side-channel attacks, or may try to interfere with the timing of the TEE Aide to affect the release of the block.
2. TEE Aide will include transactions from the Proposer's list in a "best effort" manner, i.e., Proposer cannot require that transactions MUST be included.
3. All proposers who want to support this have to undergo modifications.
4. Since the auction is performed on the Proposer side, Builders have to directly connect to the Proposer, or the Proposer must ask all Builders to send their ToBs. The latter incurs another round of communication.

Exposed APIs

For Proposer:

- submit_inclusion_list(inclusion_list) -> bool

For Builder:

- submit_tob(block_number, txns) -> id
- retract_tob(id) -> bool

Builder Aide

Builder employs a TEE module that the Proposer can connect to to ask for a bid or submit a list of transactions to include - the TEE module will includes as many transactions as possible from this list (such that the block remains valid).

1. Builder builds a ToB and sends it to the TEE Aide.
2. TEE Aide computes the bid.
3. Proposer asks all Builders their bids.
4. Proposer selects a bid and sends a list of transactions to be included.
5. TEE-Aide includes as many transactions and sends the header of the block to Proposer.
6. Proposer sends back the signed header and everything follows MEV-Boost from here onwards.

Disadvantages:

1. TEE Aide is responsible for slashing if optimistic computation is used. Since the TEE Aide resides on the Builder, it is possible for the Builder to cheat and disconnect before slashing occurs.
2. TEE Aide will include transactions from the Proposer's list in a "best effort" manner, i.e., Proposer cannot require that transactions MUST be included.
3. The block is built is the untrusted domain.

Exposed APIs

For Proposer:

- get_bid(block_number) -> bid
- get_header(block_number, inclusion_list) -> (bid, header)
- confirm_header(signed_header) -> bool

For Builder:

- submit_tob(block_number, txns) -> bool

Full TEE Partial Builder

Builder runs entirely inside of a TEE. Proposer communicates directly with Builder and is able to specify a list of transactions that MUST be included.

1. Proposer can at any time submit a transaction list that Builder MUST include (Builder will verify that executing these transactions results in a valid state)
2. Builder builds the best block, ensuring that Proposer's required transactions are included
3. Proposer requests a bid from Builder, specifying the transaction list
4. Builder responds with a bid
5. If Proposer wants to select this Builder, it will send a get header request (specifiyng the transaction list ensures that the Builder and Proposer agree on what transactions must be included)
6. Builder responds with the header
7. Proposer sends the signed header to the Builder
8. Builder broadcasts header to the network and, after a delay, releases the block to the Proposer

Disadvantages:

1. TEE-related overheads could be prohibitive if they cause the Builders to build suboptimal blocks.

Exposed APIs

For Proposer:

- submit_transaction_list(block_number, transaction_list) -> bool
- get_bid(block_number, inclusion_list) -> (bid, header)
- confirm_header(signed_header) -> bool

No APIs are exposed for the Builder since the Builder is… the Builder!

Brief TEE Overview

TEEs are isolated enclaves protected by hardware, typically the CPU. The enclave is what we call the trusted world, while everything else (e.g., the host OS) is referred to as the untrusted world. The CPU employs strict protection mechanisms to safeguard the enclave data in order to prevent leakage and unauthorized access. These mechanisms ensure that the trusted world communicates with the untrusted world via strictly monitored interfaces, that data is encrypted before leaving the trusted world, and that all execution state belonging to the enclave is properly cleared when a context switch occurs between the trusted and untrusted world.

These protection mechanisms are not free and can incur performance degradation. For example, the first generation of Intel SGX was shown to be significantly slower at running computational demanding workloads due to hardware limitations [1]. However, as SGX technology advanced and hardware limits were pushed further, the overall performance of workloads running on SGX improved [2].

Moreover, enclave technology is continuously evolving and new approaches and improvements are being explored. One such technology is AMD SEV, a VM-based TEE. SEV was shown to have good performance while running high-performance computing workloads [1], as well as database workloads [3]. VM-based TEEs are also being explored by AWS (Nitro Enclaves) and Intel (TDX).

How will partial block building fare on TEEs?

Context switching between the trusted and untrusted worlds is usually the main culprit in performance degradation. In our case, we estimate the number of context switches required to be dependent on whether we do optimistic computation, default computation or full building inside the TEE:

• Optimistic Computation: Context switches occur as a result of communication initiated or accepted by the TEE, e.g., when the TEE receives a ToB from a Builder, or an inclusion list from a Proposer;
• Default Computation: In addition to the communication costs corresponding to optimistic computation, with default computation we have to explicitly verify that a block is valid and compute the bid; this incurs additional costs associated with fetching information about the state of the network and validating block transactions;
• Full Building: Building a block is a repeated verification as various combinations of transactions are checked in order to find the highest value block. In other words, we expect the costs of building to be some order of magnitude higher than the ones associated with default computation (how big the order of magnitude is depends on how many combinations we have to test).

We also expect the overheads to depend on what TEE technology we use and how we optimize certain operations to minimize the number of context switches.

References

[1] Akram, Ayaz & Giannakou, Anna & Akella, Venkatesh & Lowe-Power, Jason & Peisert, Sean. (2021). Performance Analysis of Scientific Computing Workloads on General Purpose TEEs

[2] Muhammad El-Hindi, Tobias Ziegler, Matthias Heinrich, Adrian Lutsch, Zheguang Zhao, and Carsten Binnig. (2022). Benchmarking the Second Generation of Intel SGX Hardware

[3] Maliszewski, Kajetan & Quiané-Ruiz, Jorge-Arnulfo & Traub, Jonas & Markl, Volker. (2022). What Is the Price for Joining Securely? Benchmarking Equi-Joins in Trusted Execution Environments