BAM Attestations: Road To Transparency

Attestations are a crucial component of BAM's trustless guarantees. Performance, stability and customizable ordering through Plugins are core to what BAM offers, but attestations are what allow market participants to verify that BAM's transaction ordering is fair, deterministic and transparent.

This post covers what attestations are, why they matter for BAM's roadmap, and where we are in shipping them.

What are Attestations?

Attestations are cryptographic proofs issued by the Trusted Execution Environments (TEEs) where BAM Nodes run. They allow stakeholders to verify that any given BAM Node is running the correct source code and TEE configuration, unmodified.

Together with open sourcing BAM's scheduling logic, attestations provide BAM's transparency guarantees. Anyone can audit how the scheduler orders transactions (by fees per CU plus any custom Plugin ordering), and attestations prove that this exact code is what each node runs.

The result is verifiable assurance that BAM Nodes order transactions as specified.

Why are they important?

Today, trust in BAM still resides on Jito’s reputation. Attestations, alongside open sourcing the BAM Node code, provide all stakeholders with the expected execution guarantees and fair ordering without needing to trust Jito. Ultimately, they enable:

• Market participants to get deterministic inclusion guarantees, because the scheduling logic is known and provably enforced.
• Validators to get assurances that the orderflow they receive was scheduled according to known, pre-set rules.
• BAM Node decentralization at scale. Once third parties operate BAM Nodes, attestations are what let the network trust a specific node without trusting its operator.

Building Blocks for Attestations

Attestations sit on top of two pieces of infrastructure, each answering a critical question:

TLS (Transport Layer Security): “Can I trust I’m connected to a BAM Node?”

Before a validator can trust what a BAM Node is running, it needs to know which node it is talking to. TLS establishes the identity of the BAM Node before any application data flows, as an attestation from an unverified source is worthless. TLS is the critical piece that ensures validators that they are actually connected to a valid BAM Node.

BAM Registry: "Which BAM Node should I connect to?"

BAM's TLS certificates are bound to IP addresses rather than DNS names. This is deliberate design choice, as BAM is intended to be permissionless to run, and binding certificates to IPs means operators don't need a DNS provider to run a BAM Node. 

Each certificate is tied to the lifetime of a specific TEE instance, and each node must be able to obtain and renew its own certificate independently. A shared DNS name would leave a failover node unable to serve HTTPS until it was promoted and DNS had propagated.

The tradeoff is discoverability: without DNS, validators need another way to find which IP and certificate are currently authoritative. The BAM Registry solves this by telling validators which nodes are healthy, letting them move to the next-best BAM Node automatically and keeping downtime to a minimum.

In addition, the Registry also acts as a central point for discovering BAM Nodes. As third parties begin operating nodes, validators won't need to track each operator and their endpoints individually, as the registry will handle that for them

TEE Attestations: "Is the BAM Node running what they say they’re running?"

With identity and discovery in place, attestations are the end goal, establishing trust in the source code and configuration running on the node itself. 

On its own, though, an attestation report only proves that some machine is running the correct code, not that the specific machine you're connected to is. This is known as the relay-attack gap: a dishonest node could forward a validator's request to an honest node and pass its genuine report back as its own.

To close this gap, attestations are bound to the TLS session. The validator requests an attestation report over its TLS session and supplies a fresh nonce. The BAM Node binds that nonce and the TLS session's key material into the report, and the validator checks that binding along with the rest of the report. A relayed report would carry another session's details and fail verification, so a report is only valid for the exact connection it was requested on.

Attestation Flow

Here's how the pieces fit together when a validator connects to BAM:

1. The validator queries the BAM Registry for a healthy BAM Node and its current IP
2. The validator opens a TLS connection and verifies the node's certificate
3. The validator requests an attestation report over that session, supplying a nonce
4. The BAM Node generates a report inside the TEE, binding in the nonce and TLS key material
5. The validator verifies the report against published measurements before streaming begins

Progress to Date

TLS

TLS is currently live on all mainnet BAM Nodes, with certificates issued and renewed automatically. This is powered by Certio, a library for automated TLS provisioning and management inside TEEs.

This setup as been verified live, with the Dublin BAM Node producing blocks over HTTPS with one of Jito’s internal validators

Additionally, internal testing of the TLS and attestation binding has commenced. It closes the relay-attack gap and de-risks adding attestations to BAM, paving the way

BAM Registry

The BAM Registry is currently being tested internally on our Testnet BAM fleet.

What's Next

The remaining work is to roll out the BAM Registry to Mainnet, move validator connections from optional to TLS-only, and finally, open attestations to the public with open sourcing of the BAM scheduling code.

On the validator side, two BAM Node components hold leaders to their end of the contract: the BAM Verifier checks the ordering of transactions sent to leaders against what lands on-chain, and Autobahn automatically bans validators the Verifier flags.

Together with attestations, these components cover both directions of the BAM “arrangement” between BAM Nodes and BAM validators to provide trustless guarantees of fair and transparent execution.

Questions

If you have questions about BAM attestations, please reach out on the Jito Developer’s Discord.