Context
Flashbots' products rely heavily on TEEs. While we have driven renewed interest in this tool (buildernet, dstack, teleport, ...), we also acknowledge the need for far superior solutions to today’s commercially available TEEs in terms of security guarantees. As such, one of our flagship projects aims at building a trustless and fully open TEE, but this will take time. In the meantime, multiple academic papers suggest alternative TEE (alt-TEE) designs and claim to offer better security guarantees than what the major TEEs such as Intel SGX/TDX and AMD SEV-SNP offer. So far, no one has really attempted to build on them, and neither have they found an industry application beyond the lab.
We believe this represents an under-studied area offering a trade-off between the maximal security of trustless TEEs and the readiness and simplicity of commercially available TEEs. The goal of this project consists in reproducing all or part of the software stack we are currently running in TEEs.
This project is complementary to our other TEE initiatives, as it could also fuel a more diverse and decentralised fleet of TEEs made available to the Web3 community.
Current workflow
This project concerns any application of TEEs we have at Flashbots and beyond, so there is not a single workflow and set of actors, but as many as there are TEE applications. We will describe some cherry-picked use cases to instantiate some of the project's requirements.
Running a block builder will require a large amount of memory and the ability to support complex workloads inside the TEE.
Another challenge arises when supporting backrunning via BOB-style or more generally mev-share strategies that demand support for a dynamic, non-auditable workload as part of the design requirements. This setting does not allow inspecting the strategy's code and thus cannot be included as part of the enclave's measurement.
Common Requirements
- clear threat model, in particular with regard to physical adversaries, since this determines whether the TEE can only be used via a trusted cloud provider or deployed on premises
- low overhead resembling that of TDX (~5% compared to non-isolated workload)
- some level of portability for existing software stacks: it would be a huge endeavour to re-implement a whole block builder without some level of portability from existing codebases
- development stack suitable to reproducible builds
Open problems
- develop a taxonomy and formal models to reason about security guarantees from one alt-TEE to another, but also when comparing with commercial TEEs
- develop tooling in the spirit of DStack
- establish a common benchmark of MEV-related workloads to compare and evaluate various TEEs against
- can we obtain cloud assurance from these alt-TEEs too? Several platform requirements must be met for successful Proof-of-Cloud deployments:
- The platform should include a root of trust provided by a TPM.
- The TPM should have an endorsement key certificate by a trusted location provider.
- To mitigate a malicious host's capabilities, we require technology similar to Intel TXT, which can ensure PCR extensions all the way to the hypervisor and ideally beyond.
- As part of the TEE attestation flow itself, we require runtime registers, similar to RTMRs 0-2 of Intel TDX. The registers should include values which correspond to vTPM PCR values to provide successful binding.
References / ongoing efforts
- RISC-V based (Keystone, ...)
- BYOTEE (FPGA)
- Argos (TPM based)
