Welcome to the bob v2 image! For a higher-level conceptual overview, please visit our forum post: https://collective.flashbots.net/t/searching-in-tdx/3902

For the video version:

• Intro to Bob V2: https://www.loom.com/share/4f6a5705f5024d1a9d17b0f915cf9f19?sid=f029156c-cf8d-431d-9abf-4176580164a8 (43 seconds)
• Image Overview: https://www.loom.com/share/d7f29b56a8c9431daf68ebc242f5933d?sid=1570456e-d751-4b03-a02c-0bc1634a331a (2min 30s)
• Codebase Deep Dive: https://www.loom.com/share/0d934aa034754898a920ac576e7f7d21?sid=b922cf7a-1232-494b-8bb7-4de71442c02e (18 min)

Intro to Bob V2

TDX Mental Model

First, searchers verify that the TDX operator, in this case Flashbots, cannot access or observe code inside a TDX machine through a process called attestation:

• Searchers audit the TDX VM image that only their public SSH key can access the machine, and then build and measure (hash) the image locally.
• Then, searchers request and verify the measurement from the cloud provider (in our case Azure) is the same to confirm the exact image they audited is running on the TDX machine they will upload their code to.

But, in the bob image, the searcher is also restricted to its own user group without root privileges. This allows us to implement sandboxing and log delays on the host safely, without the searcher being able to override or interfere with these restrictions. So, even though the searcher is given ssh access to the machine, the searcher is sufficiently restricted to guarantee they would not be able to expose any sensitive data submitted by the builder.

Importantly, implementing searcher sandboxing, log delays, and mode toggling inside the VM also allows block builders and their users to verify their orders cannot be frontrun using attestation.

Image Overview

There are three key features of the image:

1. Network namespaces and firewall rules that enforce a searcher cannot SSH into the container while state diffs are being streamed in, and the only way information can leave is through the block builder’s endpoints.
2. A log delay **script that enforces a two-minute (~10 block) delay until the searcher can view their bot’s logs.
3. Mode switching which allows a searcher to toggle between production and maintenance modes, where the SSH connection is cut and restored respectively.

Together, they provide the “no-frontrunning” guarantee to order flow providers while balancing searcher bot visibility and maintenance.