In one sentence. ComputeFlux runs every part of its network inside a locked compartment built into the CPU itself, so the people operating the servers physically cannot read the prompts passing through them.
Picture it like this. Imagine renting an apartment whose lock was welded into the foundation at the factory. The landlord holds the deed but has no key and no way to cut one. Before you move in, you can ask the building itself for a manufacturer-signed certificate proving that not one wall has been moved since it was built. That certificate is what engineers call remote attestation, and the entire rest of this series is built on top of it.
Why it matters. Right now, everything you type into an AI product exists in readable form on a computer you don't control. The only thing between your words and the operator is a privacy policy — a promise. This article is about replacing that promise with a property of the hardware.
Already fluent in SGX and DCAP? Skip ahead to the Quote verification chain.
Every architectural decision in ComputeFlux traces back to one choice: run the entire decentralized AI-inference gateway — consensus engine, database, cryptographic modules, contract execution — inside a Trusted Execution Environment. This is the foundation the rest of this series builds on. Before we can talk about how ComputeFlux stores contract state, generates threshold signatures, reaches consensus, or upgrades contracts, we need to establish exactly what a TEE guarantees, what it costs, and what it explicitly does not protect against. Everything downstream depends on getting this right.
Traditional cloud security rests on a fragile trust chain: you trust your code → trust the container runtime → trust the operating system → trust the hypervisor → trust the cloud provider's employees. Every link is a potential attack surface. Worse, an attacker only needs to compromise one link — a single root-privileged SRE, one container escape vulnerability, one memory dump — to exfiltrate every API key and usage record in the system.
TEE (Trusted Execution Environment) collapses this entire chain into a single hardware root of trust: you only need to trust Intel's or AMD's CPU design. That collapse is what makes ComputeFlux's threat model tractable, and it's why this article opens the series rather than appearing as background material somewhere in the middle.
Trust Model Dimensionality Reduction
This is not an incremental improvement. It's a categorical shift in what you must trust:
| Approach | Trust Boundary |
|---|---|
| Bare metal | OS + all operators + hardware |
| Containers | Container runtime + OS + hypervisor + operators |
| KMS + HSM | HSM firmware + application code + OS |
| Software encryption | Keys in plaintext in memory — a single core dump leaks everything |
| TEE | CPU silicon design only |
The trust anchor in a TEE is the root key physically burned into the CPU at manufacturing. This key is physically unreadable — any probing attack triggers self-destruction. SGX's key hierarchy is:
Root Provisioning Key (burned at fab, physically inaccessible)
└── Root Sealing Key (derived from CPU firmware version)
└── Enclave Sealing Key (derived from MRENCLAVE + MRSIGNER)
Even two enclaves running on the same physical CPU have completely different sealing keys. Enclave A cannot decrypt data sealed by Enclave B — even on the same machine.
The Economics of EPC Memory: Why You Can't Put Everything Inside
SGX's most criticized limitation is EPC (Enclave Page Cache) capacity. First-generation SGX offered only 128MB. Second-generation supports up to 512GB in theory, but practical availability is far lower. ComputeFlux configures 2048MB (commit de94c4f) — a number chosen deliberately, not arbitrarily.
The cost of EPC isn't the capacity itself. It's paging. When enclave memory exceeds physical EPC, the CPU must evict pages to untrusted memory, which requires encrypting the page contents (AES-GCM), writing a MAC tag, updating the version tree (rollback protection), and updating the EPC mapping table. Each page eviction consumes approximately 10,000–50,000 CPU cycles. Under heavy paging, performance collapses. That is why so much engineering effort goes into shrinking PebbleDB's memory footprint (Article 2): not because PebbleDB is slow, but because EPC paging is catastrophically expensive.
ComputeFlux's decision to place the entire stack — consensus engine (CometBFT, Article 4), database (PebbleDB, Article 2), cryptographic modules (DKG, Article 3) — inside the enclave means accepting EPC paging overhead in exchange for full-stack TEE protection. There's no gray zone of "half inside, half outside" — that would create cracks in the trust boundary.
Remote Attestation, First Pass: "Prove My Code Hasn't Changed"
Remote attestation is frequently misunderstood as "proving you're running inside an enclave." What it actually proves is far more precise: the SHA-256 hash of the code running inside the enclave (MRENCLAVE) matches the expected value.
This has a crucial implication: modify a single line of code, and MRENCLAVE changes. Other nodes will refuse to connect. This is both a security guarantee and an operational challenge — every code upgrade requires network-wide synchronization of the expected MRENCLAVE.
ComputeFlux handles MRENCLAVE verification at two layers:
- P2P handshake layer: Nodes exchange TEE Quotes during connection establishment. Connections failing verification are rejected outright, preventing Sybil attacks — an attacker cannot join the network with a forged enclave.
- Consensus layer (Vote Extension): Every block vote carries a TEE Quote, so even a node that passed handshake verification has its state at block-production time re-verified. Any runtime tampering is detected.
That's the summary. The rest of this article is about what actually makes those two layers work — the trust bootstrapping problem, the full certificate chain behind a Quote, and the version-pinning discipline that prevents rollback attacks. Getting attestation wrong is the single biggest security risk in the whole system, so it's worth going deep here rather than treating it as a box to check.
The Trust Bootstrapping Problem: How Does a New Node Know the Expected MRENCLAVE?
This is the chicken-and-egg problem at the heart of every TEE deployment. MRENCLAVE is the fingerprint that attestation verification checks against, but a node joining the network for the first time has no prior knowledge of what MRENCLAVE is legitimate. Accept whatever MRENCLAVE peers present, and any machine running modified code (logging API keys, exfiltrating private data) could join the network unchallenged. Reject everything, and no node can ever join.
The naive fix — hardcoding the MRENCLAVE into the node binary — creates unacceptable operational coupling. Every code change, however trivial, alters MRENCLAVE, because SGX's build process hashes the entire enclave memory layout: even reordering global variable declarations changes the value. Hardcoded MRENCLAVE turns every upgrade into a flag-day event requiring coordinated downtime.
In ComputeFlux's current implementation, this problem is only partly solved. The P2P and consensus-layer verifiers described below do check three things: that a peer's attestation report is validly signed, that it is not a debug-mode report, and that it comes from the expected TEE type. What they do not yet check is which enclave is on the other end. The verifier has an explicit extension point for that broader policy question — whitelisting a specific code signer, product ID, or enclave measurement — but nothing is wired into it yet.
So "which MRENCLAVE values are legitimate" is a question the architecture anticipates rather than answers. A mature deployment needs a governance-driven allow-list here. Treat the on-chain registry, the genesis measurement, and the authorization flow as the intended direction, not as guarantees the code already enforces.
Connect-Time Attestation vs. Per-Block Attestation: Why Both
The P2P handshake verifier and the consensus-layer Vote Extension verifier address different threat windows, and omitting either leaves a gap the other cannot close.
Connect-time attestation establishes a node's identity the moment it joins the network's gossip mesh. When Node A initiates a TCP connection to Node B, the handshake interleaves attestation verification between the TCP handshake and CometBFT protocol negotiation. Node A sends its SGX Quote (or SEV-SNP/TDX attestation report), bound to its p2p public key; Node B verifies the report's signature chain and that it is genuinely bound to Node A's key. Failure means the connection is refused at the TCP level — Node A never reaches consensus messaging. This prevents a Sybil attacker from flooding the network with impostor connections that would consume CometBFT's connection pool and memory buffers before ever being caught at the consensus layer. As noted above, the deeper policy check — whether Node A's specific code measurement is on an authorized, governance-maintained list — is the part that's still an extension point rather than a wired-up on-chain check today.
But connect-time attestation is a point-in-time check. A node that passed attestation at connection time could, in principle, have its enclave memory corrupted afterward — through a Rowhammer attack on the EPC, a speculative execution side-channel, or a hypervisor-level memory remapping. The probability is low, but the cost of being wrong is catastrophic: a compromised node with a still-valid MRENCLAVE could inject fraudulent transactions the consensus layer would accept.
Per-block attestation, embedded in CometBFT's Vote Extension mechanism, closes that window. During each consensus round, a validator attaches a fresh TEE attestation report to its vote extension, generated within that block height's context (the block height is bound into the report's data). Other validators verify the report during VerifyVoteExtension before the vote is counted. A node compromised after connection time would need to produce a valid report from the compromised state — but that report would reveal an altered code measurement, no longer matching what's expected. Article 4 covers how this fits into CometBFT's consensus rounds. The short version: the dual-layer design buys defense in depth for a modest price. Generating a report every block costs time, but it stays well inside CometBFT's per-round budget and its vote extension size limits.
The SGX Quote Verification Chain: From Quote to Root CA
An SGX Quote is not self-authenticating. It's a data structure signed by the Quoting Enclave — a special Intel-provisioned enclave holding the attestation key. Verifying a Quote means walking a certificate chain from the Quoting Enclave's key to Intel's root of trust:
- Quote body — contains MRENCLAVE, MRSIGNER, ISV product ID, security version number (SVN), and report data, signed by the Quoting Enclave's ECDSA key (P-256 curve).
- QE Attestation — a self-report from the Quoting Enclave ("I am the genuine Intel Quoting Enclave with hash X"), signed by the Provisioning Certification Enclave (PCE).
- PCE Certificate — an X.509 certificate issued by Intel's PCK platform CA, binding the PCE's public key to the specific CPU's platform identifier, fused into the silicon at manufacturing. This is where hardware binding becomes concrete: the certificate attests that a specific physical CPU is a genuine Intel processor with SGX capability.
- PCK Platform CA — an intermediate CA operated by Intel, signed by the Intel SGX Root CA.
- Intel SGX Root CA — the self-signed root certificate, distributed out-of-band (embedded in the ComputeFlux binary or fetched from Intel with certificate pinning). The ultimate trust anchor.
Every step checks signature validity. The attestation library also reports TCB (Trusted Computing Base) status along the way, so the verifier can tell when a platform is out of date or known-vulnerable. Today it logs that as a warning and continues. A browser would refuse a certificate chaining through a broken TLS implementation outright; ComputeFlux does not. Treating specific TCB statuses as fatal is exactly the sort of policy the extension point above is meant to hold, once governance is wired to it.
Platform-Specific Attestation: SGX, SEV-SNP, and TDX
The attestation landscape is fragmented across CPU vendors, each with its own root of trust, report format, and verification protocol.
Intel SGX (via IAS or DCAP) provides the most mature ecosystem, attesting to the exact code hash (MRENCLAVE) and signer identity (MRSIGNER) — the strongest guarantee of "this specific binary is running." The cost is operational complexity: every code change alters MRENCLAVE, requiring governance to update the authorized hash. SGX also provides the finest-grained memory isolation: each enclave's EPC pages are encrypted with an enclave-specific key.
AMD SEV-SNP attests to a launch measurement — a hash of the VM's initial memory state and launching firmware — signed by the AMD Root Key (ARK), fused into the CPU at manufacturing. SEV-SNP's threat model differs from SGX's: it protects against a malicious hypervisor, while SGX protects against both a malicious OS and (in theory) a malicious hypervisor. Its trusted computing base is also larger: the entire VM firmware and OS kernel sit inside the boundary, which widens the attack surface. In exchange, the memory model is far simpler. No EPC size limit, no paging overhead, and the whole VM encrypted transparently. For workloads that need gigabytes of memory, SEV-SNP is the only practical option.
Intel TDX is Intel's answer to SEV-SNP — a VM-level TEE built on SGX's key management infrastructure. TDX attestation produces a TDX Quote chaining back to the Intel root CA, with a measurement covering the TD's initial memory, virtual firmware, and CPU configuration, preserving Intel's finer-grained attestation model relative to SEV-SNP.
ComputeFlux hides these differences behind one interface. Each platform implements its own issue/verify pair, and the codebase dispatches on the detected TEE type — SGX, SEV-SNP, or TDX — to the matching implementation. Everything above that layer calls a single IssueReport/VerifyReport and never needs to know which platform produced the evidence.
The abstraction leaks, because the security guarantees underneath genuinely differ by platform. But it keeps the consensus and P2P layers platform-agnostic, which is worth the leak. TEE type is detected at runtime by looking for the SEV/TDX guest device and falling back to an SGX enclave self-report; platform-specific dependencies are linked in with Go build tags.
Sealed Storage Key Derivation: Why Data Survives Restarts
Sealed storage faces a paradox: data must persist across reboots, but the encryption key cannot exist in plaintext on disk. SGX resolves this through key derivation:
CPU Root Key (on-die)
└── Enclave Identity (MRSIGNER + ProductID + SVN, or MRENCLAVE)
└── Sealing Key (AES-256-GCM)
└── Encrypts sealed application data
SGX offers two flavors of this derivation, and the choice matters. Derive the key from the exact code hash (MRENCLAVE — EGo calls this the "unique" seal) and the data unseals only on that exact binary, so any upgrade at all breaks decryption. Derive it from the signer identity plus product and security version (EGo's "product" seal) and the data survives upgrades from the same signer, as long as the security version only moves forward.
ComputeFlux's application database uses the product seal. A code upgrade signed by the same key therefore does not break decryption on its own, the way strict MRENCLAVE sealing would, because the binding is to signer and product rather than to a byte-for-byte enclave measurement. Copy that sealed data to a different signer's enclave, or to one for a different product, and it still fails to decrypt. Article 2 picks up exactly here, walking through how the sealing is applied to ComputeFlux's stored values.
Version Pinning and the MRENCLAVE Rollback Attack
The rollback attack is the most dangerous class of TEE vulnerability that doesn't involve breaking cryptography at all. The attacker doesn't need to extract enclave secrets or forge attestation signatures — they exploit the fact that older enclave code may have known vulnerabilities since patched. If the authorized MRENCLAVE set includes both the current patched version and an older vulnerable one, an attacker running the old code produces a valid attestation and joins the network with a compromised enclave.
Concretely: version 1.0 of the enclave has a buffer overflow in the contract execution engine allowing arbitrary code execution. Version 1.1 fixes it. If both 1.0's and 1.1's measurements remain acceptable to the network at the same time, an attacker can obtain the 1.0 binary, exploit the overflow to exfiltrate a DKG share (Article 3), and deploy it on a machine producing valid SGX Quotes. The network would accept the connection because 1.0 is still treated as legitimate.
The general defense is to keep authorization strictly monotonic: a small, explicit set of currently-acceptable versions, with each old version dropped on a firm schedule rather than left in place indefinitely. ComputeFlux is not there yet. As noted above, its verifier checks that a report is validly signed and non-debug, but it does not enforce a governance-tracked version allow-list with per-version expiration. That policy layer is the natural next use of the extension point already sitting in the verifier — not a gap to assume is already closed.
SGX's Historical Vulnerabilities and ComputeFlux's Defenses
SGX is not invulnerable. Known attack classes and how ComputeFlux defends against them:
| Attack Class | Mechanism | ComputeFlux Defense |
|---|---|---|
| Side-channel (cache timing) | Infer enclave data by measuring cache access latency | Application-level reduction of secret-dependent branches; DKG nonce pool eliminates timing variance |
| L1TF / Foreshadow | Speculative execution reads EPC via L1 cache | Intel microcode patches + EGo SDK built-in mitigations |
| Rollback attack | Replace current sealed data with an older version | SGX Version Tree guarantees data freshness |
| Denial of Service (EPC exhaustion) | Malicious process consumes all EPC, triggering paging storms | Limit non-enclave process EPC quotas |
What TEE Cannot Protect Against
Being honest about what TEE doesn't protect is equally important:
- Network-layer attacks: TEE protects memory and data, not transport. Proxy re-encryption and NIZK proofs (Article 3) provide end-to-end protection.
- Consensus-layer Sybil attacks: TEE cannot prevent an attacker from running multiple fake nodes. That's what BFT consensus — 2/3+1 Byzantine fault tolerance, Article 4 — solves.
- Economic attacks: Even with every node in a genuine enclave, 51% collusion can still tamper with the ledger. DKG threshold signatures (Article 3) and on-chain nonces guarantee transaction-level security.
- Physical side-channels: Power analysis, electromagnetic emissions, and other advanced physical attacks can partially bypass TEE. ComputeFlux's security model assumes these require nation-state resources and treats them as out of scope.
Why EGo Instead of the Raw SGX SDK
Intel's official SGX SDK is C/C++. Using it from Go requires CGO, and inside an enclave, CGO is catastrophic — every CGO call is an expensive context switch across the enclave boundary.
EGo (Edgeless Systems) takes a different approach: it compiles the entire Go runtime into the enclave. No CGO. All Go code, including the standard library, runs inside the enclave with no boundary crossings.
EGo builds on Intel's SGX SDK and the Open Enclave SDK rather than Gramine, wrapping them in a Go-friendly interface. It also ships an explicit sealing API — ecrypto.SealWithProductKey/Unseal — that application code calls directly to encrypt data before writing it to disk, instead of transparently intercepting every file I/O call. ComputeFlux's storage layer uses that explicit API, as Article 2 covers in detail.
Choosing EGo is a performance-versus-complexity trade-off. The raw SGX SDK allows finer-grained memory layout control, but at several times the development and maintenance cost. EGo lets ComputeFlux build the entire system in nearly pure Go, handling SGX complexity only at the configuration layer.
Key Takeaways
- A TEE collapses a long chain of trust into one link. Instead of trusting the operating system, the hypervisor, the cloud provider, and every engineer with root access, you trust the CPU vendor's silicon. That's not an incremental improvement — it's a different category of guarantee.
- Attestation proves which code is running, not just where it's running. The check is against a hash of the enclave's contents. Change one line and the fingerprint changes, and other nodes refuse the connection. Security and operational friction are the same mechanism here.
- ComputeFlux verifies twice, for two different threat windows. Connection-time attestation establishes who joined the network. Per-block attestation catches a node that was compromised after it joined. Either one alone leaves a gap the other closes.
- The honest caveat: the policy layer that decides which code fingerprints are legitimate is designed as an extension point but is not yet enforced by on-chain governance. This article says so explicitly rather than implying a stronger guarantee than the code delivers.
- TEE is a foundation, not a complete answer. It does nothing against network-layer attacks, Sybil attacks, or 51% collusion. Those are the jobs of threshold cryptography (Article 3) and BFT consensus (Article 4) — which is exactly why the series continues.
This is the hardware and attestation foundation everything else in the series rests on. Article 2 picks up the sealing key derivation introduced above and shows how it protects ComputeFlux's contract storage layer end to end, down to the LSM-tree internals of sealed PebbleDB.
Next — Article 2: Contract Storage & Sealed PebbleDB: the enclave protects data in memory. But data has to hit a disk eventually — and a disk can be stolen. Here's what happens then.