Docs / Architecture

Architecture

Confidential services review source and build deployment images. Proofs connect their attestation evidence to records on Base. A live endpoint signs a challenge so a caller can check its identity against those records.

How it is built

The CLI

Runs on your machine. It hashes your code, checks the reviewer's approved release, and encrypts the source to its key. The reviewer sends source to Phala's separately attested inference service for semantic analysis. Later, the CLI deploys through your local Azure session.

The enclaves

Epoche runs the reviewer and builder in Azure confidential containers. You run the loader in your Azure subscription. Each creates fresh keys at boot, and Azure signs an attestation that identifies its measured configuration and keys. The reviewer signs the review result. The builder creates an image and signs its build record. The loader fetches the image, checks its hash, and runs it.

The provers

Two RISC Zero programs run on the Boundless proving market. One checks an Azure attestation and publishes the measurement and enclave keys. The other checks privately that a review receipt and a build record describe the same source, then publishes their hashes. A relayer posts the proofs to Base.

The chain

Base records enclave signing keys, approved releases, review receipts, and admitted images. Signing-key registrations last thirty days under the current policy. Runtime registration connects an authorized key to an admitted image. Callers read these records through RPC providers and the public verifier.

Every stage names the last one by hash.

Source hash into the receipt, receipt hash into the build record, build record into the artifact id. Nothing can be swapped without breaking the link, which is what the four pictures below trace.

Inside an enclave

An enclave is a virtual machine whose CPU encrypts its memory to protect it from the host. Epoche's Azure confidential containers use AMD SEV-SNP hardware. Source confidentiality also depends on the measured software and any service that receives source from it, including the inference service.

The reviewer needs source access to do its work. The hardware protects that memory and produces signed evidence of the measured environment. The client checks the evidence before encrypting source to the reviewer.

An Azure confidential container holding Epoche code and Microsoft's attestation sidecar, exchanging a hardware quote for a signed JWT with Azure Attestation, and sending that JWT to the CLI and to a prover. — Every enclave Epoche runs has this shape. The reviewer, builder, and loader differ only in what the Epoche code does once it is running.

Each enclave is a container group with two containers: Epoche's own code, which is open source, and Microsoft's attestation sidecar. At boot the Epoche code makes a fresh signing key and a fresh encryption key and keeps them in memory only. The sidecar asks the CPU for a signed quote, attaches those keys, and sends it to Azure Attestation, which checks the quote and returns a signed JWT. The JWT carries the measurement, a hash of every image, command, and setting in the group, plus the two keys. Change anything that is measured and the hash changes, so it no longer matches an approved release.

That JWT is the enclave's identity. Your CLI reads it before encrypting anything to the reviewer. A prover turns it into an on-chain registration of the signing key. The keys die with the container. The next boot makes new ones and attests again.

You run the loader in your Azure subscription. For a sealed deployment, it fetches the Docker image built from reviewed source, checks its hash against the Base record, and starts it.

The reviewer checks Phala's gateway attestation and pins its TLS key before sending source for inference. The admitted prototype provider has a known failure-log limit: an upstream error can expose a single-line fragment of up to 240 characters, which may contain source or prompt material. The prototype acceptance does not support a production confidentiality or zero-data-retention claim. See source confidentiality for that boundary.

Why trust the reviewer

The reviewer's code is public. A release record identifies the source, Docker image, and measured policy. Azure signs attestation evidence for the running image and its fresh keys. A prover checks Azure's signature, and Base records the signing key for thirty days under the approved reviewer release.

Three steps from approved reviewer code to a registered signing key on Base. — Receipt verification requires a signature from a registered reviewer key. Step 1 says DAO. Today Epoche's release key approves the release, and the DAO page describes the plan.

Register a review on chain

A sealed deployment includes review, build, and image admission. The CLI sends encrypted source to the reviewer, which signs a receipt after completing the review. A builder enclave builds the reviewed source and signs a record containing the source and image hashes. A prover checks that the receipt and build record describe the same source without revealing either document. Base records the review and admitted image. Running epoche register alone requests a review; it does not build or deploy.

Four steps from encrypted source to two records on Base: review, build, prove, and the two writes. — Every stage carries the hash of your code. Change one byte and nothing downstream matches.

Prove your endpoint runs the verified code

For a sealed deployment, the CLI starts Epoche's loader in your Azure subscription with the image identity in its configuration. Azure signs a JWT containing the loader measurement and fresh keys. The loader presents that evidence to obtain the image decryption key, checks the image hash against Base, and starts it. A prover checks the JWT and registers the loader's signing key. You authorize that key for the image with the presentation key from your review.

Three steps from a self-hosted deployment to a registered runtime signer on Base. — The loader is an approved Epoche release like the reviewer. What Azure measures is the loader plus your artifact's identity, and the loader refuses to start any image whose hash is not the admitted one.

Check a live endpoint

For a sealed deployment, the verifier requests the endpoint's credentials and signing key, then sends a random challenge. It checks the signature and reads Base to confirm the key's registration, image identity, current status, and matching credential. Open deployments use the separate source and attestation check.

Sequence of requests between a checker, a live endpoint, and Base, ending in a verdict. — Every check fails closed. Missing, stale, or mismatched evidence produces a reason, never a guessed pass.

This is what @epoche/check does when given a URL, and what verifyAgent in the SDK does before it lets a buyer pay. The What it proves page says exactly what a verified result does and does not mean.