Setup and shape

audience: ai

Before any code runs, the bridge operator fixes two things: the crate dependencies and the bridge-β coalition shape. That is the whole setup.

Dependencies

Three groups: mosaik layer, cloud SDKs, crypto.

# Cargo.toml, [dependencies] (excerpt)
mosaik             = "0.3"
shuffle            = "0.5"      # e.g. zipnet
coalition          = "0.1"
coalition-compute  = "0.1"
tokio              = { version = "1", features = ["full"] }

# Cloud SDKs, feature-gated; only the enabled ones compile.
aws-sdk-ec2        = "1"
google-cloud-compute = "1"
azure_mgmt_compute = "0.22"
russh              = "0.49"

# Crypto for the SSH access receipt.
x25519-dalek       = "2"
chacha20poly1305   = "0.10"
ed25519-dalek      = "2"
blake3             = "1"

The coalition-layer crates do not yet exist. The backing crate at examples/compute-bridge/Cargo.toml carries local stand-ins; when the real crates land (see roadmap) the stand-ins become version deps.

The bridge-β coalition

bridge-β is the smallest coalition that satisfies this chapter: one standalone organism (the bridge) plus one basic service (Compute), referenced by a CoalitionConfig fingerprint.

use coalition::{
    CoalitionConfig, OrganismRef,
    COALITION_ROOT_SEED, SCHEMA_VERSION_U8,
};

const BRIDGE_ORG: OrganismRef<'static> = OrganismRef {
    role:         "compute-bridge",
    stable_id:    const_blake3!(
        b"instance|bridge-β.compute-bridge|",
        UNIVERSE.bytes(),
    ),
    content_hash: Some(BRIDGE_IMAGE_MRTD),
};

const COMPUTE_ORG: OrganismRef<'static> = OrganismRef {
    role:         "compute",
    stable_id:    const_blake3!(
        b"instance|bridge-β.compute|",
        UNIVERSE.bytes(),
    ),
    content_hash: Some(COMPUTE_MODULE_MRTD),
};

pub const BRIDGE_BETA: CoalitionConfig<'static> =
    CoalitionConfig {
        schema_version:    SCHEMA_VERSION_U8,
        coalition_seed:    COALITION_ROOT_SEED,
        instance_name:     "bridge-β",
        lattices:          &[],
        organisms:         &[BRIDGE_ORG],
        atlas:             None,
        almanac:           None,
        chronicle:         None,
        compute:           Some(COMPUTE_ORG),
        randomness:        None,
        ticket_issuer:     None,
        retirement_policy: Default::default(),
    };

Same notes as in web3 setup: coalition names are operator-scoped (uniqueness comes from BRIDGE_BETA.stable_id()); members are referenced rather than re-derived. The Compute module’s derivation routes under COALITION_ROOT.derive("module").derive("compute") internally when the meta-crate’s compute() accessor returns the matching OrganismRef.

The Compute module’s own OrganismConfig folds the coalition root, the committee ACL, and optionally a provider_reputation reference (added in chapter 7). No separate ComputeModuleConfig, no SettlementKind enum, no manifest. See basic services — Compute.

Public surface

The bridge exposes two mosaik primitives and nothing else:

• Collection<ProviderId, ProviderCard> — the provider card this bridge publishes on the Compute module’s registry. One entry keyed by the bridge’s ProviderId, refreshed on capacity change.
• Stream<RetirementMarker> — a single marker at end-of-life (chapter 7).

The usage log stream lives on the Compute module, not on the bridge — the module is the authority on usage (see provisioning). SSH access receipts are sealed to the requester’s x25519 public key and returned via the shuffle (receipts); they never appear on any public mosaik stream.

Boot config

At boot the operator supplies one TOML file, measured into the TDX quote:

# /etc/compute-bridge/bridge.toml

# Coalition the bridge registers with.
coalition = "<hex of BRIDGE_BETA.stable_id()>"

# Enable one or more backends. At least one.
[aws]
access_key_id     = "…"
secret_access_key = "…"
regions           = ["us-east-1"]

[gcp]
service_account_key_path = "/keys/gcp.json"
project_id               = "infer-corp-prod"
regions                  = ["europe-west1"]
tdx_machine_types        = ["c3-standard-4"]

[baremetal]
machines = [
  { host = "10.0.1.5", ssh_key_path = "/keys/bm-01",
    region = "home-01",
    cpu_millicores = 32000, ram_mib = 131072,
    tdx_capable = true },
]

# Dashboard port + per-backend $/core-hour rates for the
# operator's local cost estimate.
[dashboard]
port              = 8080
rates_core_hour   = { aws = 0.05, gcp = 0.045, baremetal = 0.0 }

One file, no separate manifest. The Rust shape it deserialises into is in src/config.rs. At least one backend must be enabled or Fleet::from_boot_config refuses to start. All secrets sit on disk inside the TDX initrd; the running binary’s Measurements would not match if they were swapped.

TDX posture

The bridge itself is TDX required. A non-TDX build cannot produce the self-quote the provider card folds, and the Compute module rejects cards that do not carry a valid quote.

The backends’ posture varies:

Grants marked tdx = required route only to TDX-capable backends. Grants without that marker land on any enabled backend. The provider card declares both the region union and whether the bridge is TDX-capable at all, so the market’s clearing filters before the envelope is opened.

Layout

compute-bridge/
  Cargo.toml
  src/
    main.rs          # entry point — chapter 2
    config.rs        # BootConfig — this chapter
    tdx.rs           # TDX self-quote — chapter 2
    provider.rs      # provider loop — chapter 5
    zipnet_io.rs     # request intake — chapter 5
    receipt.rs       # sealed receipts — chapter 6
    dashboard.rs     # dashboard — chapter 7
    backends/
      mod.rs         # Backend + Fleet — chapter 4
      aws.rs
      gcp.rs
      azure.rs
      baremetal.rs

Each module is introduced in a subsequent chapter.

Cross-references

• web3 — setup and shape
• Part I — compute
• Part III — contributors — Compute