Post Idea: MEV-SGX: A sealed bid MEV auction design

Paper / Discussion Title

MEV-SGX: A sealed bid MEV auction design

  • Link to source
    MEV-SGX: A sealed bid MEV auction design

  • Content type tag (summary, discussion)
    Discussion

  • Category

  • Proposed tags
    Mechanism Design

  • Description of why this would be an interesting post
    There are a few different proposals for completely private and permissionless MEV auctions. In this section we will briefly review each as well as their associated tradeoffs. What is the best way to ensure privacy, permissionless and transparent?*

  • Links to background reading (0 to 3 items)
    Daian, P., Goldfeder, S., Kell, T., Li, Y., Zhao, X., Bentov, I., … & Juels, A. (2020, May). Flash boys 2.0
    Vitalik (2021, March). Using flashbots as a backdoor path to account abstraction.

TLDR:

Current MEV extraction techniques and avoiding the existential risks MEV could cause to state-rich blockchains like Ethereum. MEV-SGX uses secure enclaves, specifically Intel’s SGX, to provide complete privacy, permissionless and transparent using Intel’s SGX. This plan to achieve this by: (1) Bringing transparency to MEV activity. (2) Democratizing access to MEV revenue. (3) Distributing MEV revenue in a way the benefits the community

Citation

Background

  • Miner Extractable Value(MEV): Miners can make profit from a special strategy of transactions when mining blocks. MEV includes both ‘conventional’ profits from transaction fees and block rewards, and ‘unconventional’ profits from transaction reordering, transaction insertion, and transaction censorship within the block a miner is producing.
  • Priority Gas Auctions (PGAs): instances where arbitrage bots bid against each other to submit a transaction (essentially frontrunning competition), driving up transaction fees.
  • MEV-geth: is a fork of go-ethereum. Flashbots is a research and development organization formed to mitigate the negative externalities and existential risks posed by MEV to smart-contract blockchains.
  • MEV-relay: A transaction bundle relayer. It contains a public relay for accepting transactions from searchers. It also contains an example reverse proxy for miners to run in front of their mev-geth nodes. This relay is meant only to protect participating miners from abuse via DoS attacks, but otherwise does no bundle filtering or censoring.
  • MEV-Explorer: A public dashboard and live transactions explorer of MEV activity.
  • MEV Searcher: Users that “search” for MEV to extract. For example if the price of ETH/DAI is high on Uniswap and low on Sushiswap, then the searcher could buy on Sushiswap and sell it on Uniswap, thus making a profit from the price difference. The searcher would capture this profit by creating a transaction to perform the aforementioned arbitrage and send it to miners, who would include it in return for a transaction fee from the searcher.
  • Externally-Owned Account(EOA): Controlled by a private key, transactions could start directly from contracts.
  • Zero-gas-transactions: Transactions start from an EOA, and the EOA pay the gas fees, so someone using a smart contract wallet must have some of their ETH in an EOA to pay for gas, adding significant complexity such as ArcherSwap, CowSwap and MistX.

Summary

  • Flashbots Alpha phase by establishing a proof-of-concept communication channel between searchers and miners. This is made of two components: MEV-Geth and MEV-Relay. But this structure has three problems.
    • It is not permissionless because miners who adopt it have to be whitelisted by MEV-Relay in order to be forwarded bundles.
    • It is not completely private because bundles can be seen by miners prior to inclusion on-chain.
    • Flashbots Alpha offers no finality protection against chain reorgs. While finality is important, we are focusing first on permissionless and complete privacy as the next design goals to achieve.
Guarantee PGA Dark-txPool MEV-Geth Alpha
Permissionless 𝑽 :heavy_multiplication_x: :heavy_multiplication_x:
Efficient :heavy_multiplication_x: :heavy_multiplication_x: 𝑽
Pre-trade privacy :heavy_multiplication_x: 𝑽 𝑽
Failed trade privacy :heavy_multiplication_x: :heavy_multiplication_x: 𝑽
Complete privacy :heavy_multiplication_x: :heavy_multiplication_x: :heavy_multiplication_x:
Finality :heavy_multiplication_x: :heavy_multiplication_x: :heavy_multiplication_x:

Table 1 Flashbots Alpha Design Goals

Source: Ethereum Research

Improvement takes into consideration

  • Using block headers for privacy

Using block headers miners would be able to perform proof-of-work, but they would not see the full block or the transactions that went into it. After a miner finds a proof-of-work solution the searcher would reveal the full block data to the miner, at which point the transactions would become visible to the miner and the block would be sent to the network for inclusion.

  • Bonded block headers

A variation of the block header mechanism would be to require searchers to post bonds before they can send block headers to miners.

  • Timelock encryption

A cryptographic primitive that ensures an encrypted message can only be decrypted after a certain period of time has passed.

  • Threshold encryption

A committee of block producers is required to decrypt encrypted transactions sent by searchers. Each miner would have a share of a decryption key and some threshold would be needed to decrypt transactions.

  • Secure enclaves

Searchers would use an enclave to validate that their bundles are valid and profitable, thus mitigating DOS and enabling permissionless interactions between searchers and miners. Miners would use an enclave to store encrypted blocks from searchers, and receive truncated header hashes they can use to perform proof-of-work. The miner’s enclave would unencrypt and seal the searcher’s block when provided a proof-of-work solution.

Summary of approach and tradeoff

Permissionless Complete privacy Latency Drawbacks
Secure Enclaves 𝑽 𝑽 Low - Medium Non-falsifiable guarantees for the searcher, potentially latency
Timelock 𝑽 Correlated to delay Low High transaction execution delay
Threshold Encryption 𝑽 𝑽 High Assumes an honest committee and is bandwidth expensive
Block headers :heavy_multiplication_x: 𝑽 Low Malicious searchers can spam miners or send invalid blocks
Bonded block headers High startup cost 𝑽 Low Requires significant capital (commensurate with the opportunity cost of a DOS) to become a searcher

Table 2 Flashbots Alpha Design Goals Improvement Analysis

Source: Ethereum Research

Method

  • MEV-SGX solution

MEV-SGX uses secure enclaves, specifically Intel’s SGX, to provide complete privacy and permission lessness. In MEV-SGX both searchers and miners have their own SGX, and here we use “miners” interchangeably for “mining pool.” Searchers and miners perform a handshake and use cryptographic attestations to ensure that each party is running the right software in an SGX. Tamper-proof nature of SGX these attestations provide cryptographic trust to searchers and miners, as they have guarantees that their counterparty is running specific code in an environment that cannot be tampered with or broken into.

Figure 2 MEV-SGX Architecture and Process

Source: Ethereum Research

  1. Handshake: The searcher and miner perform a handshake to discover each other, exchange public keys, and verify that each party is running MEV-SGX in an SGX through cryptographic attestations.
  2. MEV Opportunity Detection: The searcher detects some MEV then creates transactions that extract it and pay the miner upon successful extraction.
  3. Block Creation: Searchers use their node to generate a block including their MEV-extracting transactions. They also generate the block witness and input both the block and the witness into their SGX.
  4. Block Validation: The searcher’s SGX processes the block to ensure it is valid and profitable for the miner by using the block witness generated in the block creation step.
  5. Block Transfer: The searcher’s SGX encrypts the block with the miner’s public key and sends it to the miner. The searcher’s SGX also sends the miner the block’s truncated header hash and how profitable that block was.
  6. Block Selection: The miner selects the most profitable block they’ve received.
  7. Proof-of-Work: The miner uses the most profitable block’s truncated header hash to request proof-of-work from workers.
  8. Block Sealing: After finding the proof-of-work solution the miner passes that into their SGX. With this solution, the miner’s SGX decrypts, seals, and exports the block outside of their SGX.
  9. Block propagation: The miner’s node propagates the decrypted and sealed block to the network.

Figure 3 MEV-SGX block production process diagram

Source: Ethereum Research

  • Limitations of MEV-SGX
  1. Increased latency from using SGX: Minimize what is done in the SGX, explore new generations of SGX, perform rigorous benchmarking, and move towards low-level implementation for optimal performance.
  2. Searchers could break their SGX: Falsifiable by the miner by checking for invalid blocks. If it happens the system falls back to Flashbots Alpha.
  3. Miners could break their SGX: This is non-falsifiable by the searcher. Currently exploring solutions like threshold committees that mitigate this limitation.
  4. Searchers must propose full blocks: If searchers need to propose full blocks then it is much more difficult to do bundle merging between multiple searchers. We are researching methods of partial block proposals for searchers and privacy-preserving bundle merging in the miner’s SGX as well.
  5. Reliance on SGX: Explore feasibility of offering multiple types of secure enclaves as well as continuing research into software and crypto economic-based methods of achieving complete privacy.
  6. Miners can see searchers transactions after sealing the block, but before propagating it: Explore alternative structures that don’t rely on the miner for data availability

Results

  • MEV-SGX could enable Flashbots to achieve its design goals of creating a completely private and permissionless system. Searchers would craft blocks with their bundles included, validate and encrypt those blocks in their SGX, and send them to miners alongside block truncated header hashes. Miners receive truncated header hashes and encrypted blocks they know are valid and profitable for them to mine. They use the truncated header hashes to perform proof-of-work on blocks without seeing them, and upon finding a proof-of-work solution are able to decrypt and seal blocks.

Discussion & Key Takeaways

  • MEV-SGX is in early stages of development. Flashbots intends to take this design and implement a proof-of-concept that can help us learn more, pressure test our assumptions, and carry out latency benchmarks. From there we will release our findings and start work on a version of MEV-SGX that searchers and miners can test, and will keep testing and iterating on MEV-SGX thereafter. In parallel, we intend to continue to research alternatives for ensuring complete privacy and permissionlessness.

Implications & Follow-ups

  • Threshold encryption may use BLS threshold signature.
  • How does the design of MEV-SGX change in ETH2.0?
  • Does ETH2.0 make it easier to achieve our design goals with cryptographic or crypto-economic methods besides secure enclaves?

Applicability

  • What are the alternatives to secure enclaves for achieving our design goals of permissionless and complete privacy? Which of these can be achieved without a protocol change?
  • Should MEV-SGX be considered an add-on to existing systems, or a replacement? In other words, should MEV-SGX be run in parallel to the existing non-private MEV-Relay or should it replace it?
6 Likes

Great post @Sean1992076. It’s interesting because my entire summer internship with Intel is based on Intel SGX and this paper is one example of how secure enclaves can be paired as a viable layer 2 solution to increase privacy.

There are a couple of important limitations to consider, however. Depending on what architectural standard you are using (ie: x86, Arm, etc.) for the secure enclave, you will have a different process of interfacing with the ledger. Based on this premise, to my knowledge, you cannot currently design a rigorous yet universal layer 2 implementation that would work across secure enclaves of varying architectures. This functionally means that you would need a permissioned Ethereum network where nodes can only participate if they can verifiably attest they have an SGX.

Also keep in mind that secure enclaves have limited memory capacity and only the most critical secrets are stored there. It is also worth noting that if you are designing an app to interface with any secure enclave, you need to optimize it according to the enclave’s esoteric SDK. Historically, it’s been quite painstakingly difficult to do this sort of integration.

4 Likes

@fmendoz7 Thanks for mention that MEV-SGX’s architecture does not have the architectural standard for the chip design. I think it may have a different chip design architecture for the MEV mechanism. It can make a benchmark for future work.

3 Likes

There have been multiple teams over the past 4 years attempting to apply secure enclaves to smart contract execution, Enigma arguably being at the forefront of this research.

I do have some concerns about the security of SGX for smart contracts, given all of the exploits that have come to light in recent years, especially Foreshadow.

A discussion post that accounts for all of these caveats would be fascinating @Sean1992076!

3 Likes