MEV-Boost connecting to a SGX builder network

early draft & work in progress

This doc outlines an idea for mev-boost to connect directly to a network of SGX-based block builders, obviating the need for relays as intermediaries.

Such a setup could:

• remove the need for relays as trusted intermediaries
• produce higher value blocks for proposers, because builders have more time building them (don't need to submit to a relay up-front)
• pave the way to enclave-based privacy-preserving orderflow sharing between builders
• pave the way for PEPC by allowing for arbitrary commitmentsfrom builders to proposers

Rough flow outline

• Have a registry of SGX builders (could be on-chain, i.e. via a smart contract).
  • why: we need some discovery mechanism for proposers to find builders, it could be a p2p network, or a simple registry.
• Validators (via their mev-boost instance or otherwise) read that list and validate each builder's SGX proof (attestation report).
  • why: proposers need guarantees that the builder will deliver the payload and not grief them.
• With a verified attestation, validators have a guarantee that builders run a certain version of the code (which will deliver the payload when asked for it).
• Whenever it is the validator's turn to propose a block, the proposer then requests a bid from all the builders, chooses one, signs it and requests the payload (standard mev-boost flow)

In this model, users and searchers could send their bundles directly to the SGX builders, having guarantees about their transactions/bundles staying private until they're on-chain.

Next steps & questions (comment your own!)

• Registry

  • We would need to investigate how to make builders joining the network permissionless, and if a permissioned setup is good enough to start with?
    • Would it be ok for many builders joining the registry? is there a risk of a spam attack? perhaps there could be a low fee required to join the registry?
  • Somebody needs to define what are acceptable code versions builders can run. if they modify what happens inside the enclave, they need to make the proposers accept that code. who can define the code that needs to run inside the TEE?
    • MEV-Boost could ship with a default set of accepted enclave code setups?

• Griefing attacks

  • Theoretically the builder operator could cut the network connection when the SGX builder delivers the block, thus causing a missed slot for the proposer.
  • What are possible ways to detect withholding, as well as remedies for this?
    • The encrypted payload could be distributed beforehand (i.e. to validators, or storing it on a chain or gossip layer, providing it to other SGX actors.
    • Cryptoeconomic incentives could be possible
    • Technicall we should explore monitoring of such attacks through special entities as well as committees, self-reporting by the SGX enclave, as well as other means.

• Privacy-preserving orderflow sharing

  • if orderflow is expected to be private but shared to various' builders' SGX instances, we would need to investigate covert-channel attacks on geth-based builders inside SGX. this seems to be the main impediment to make this work.

• PEPC

  • how could such a system be re-used for PEPC-like commitments from builders?

• misc

  • if such a system is widely adopted throughout the network, are we worried about the barriers to entry for running SGX instances and of potential infrastructural centralization risks (everyone is on Microsoft Azure)?
  • SGX is undesireable as an end-goal system, what would be a credible roadmap from the proposal above to being less reliant on SGX or enclaves? should we promote enclave diversity?
  • impact on censorship-resistance?

Notes

• This design isn't necessarily tied to SGX in particular, but could also work with other enclave types (TEEs) that are third-party attestable and able to run a block builder.