Glossary
Plain-language definitions for every recurring term in the ComputeFlux series. No prior background assumed. Each entry links to the article that covers it properly.
Back to the series index.
The four load-bearing ideas
If you only learn four terms, learn these. Almost everything else in the series is a detail hanging off one of them.
TEE (Trusted Execution Environment) A locked compartment built into the processor. Code and data inside it are invisible to everything outside — including the operating system, the cloud provider, and anyone with physical access to the machine. The trade is that you must trust the chip manufacturer's design. → Article 1
Attestation A hardware-signed certificate proving exactly which code is running inside an enclave. Not "something is running securely" — a specific fingerprint of specific software. Change one line and the fingerprint changes and other machines refuse to talk to you. → Article 1
DKG (Distributed Key Generation) A way of creating a cryptographic key that is born split across several machines and never assembled anywhere. Signing requires a supermajority to cooperate. There is no moment when a complete key exists to be stolen. → Article 3
BFT (Byzantine Fault Tolerance) The mathematics of getting a correct answer out of a group of machines when some of them are broken or actively lying. Typically survives up to a third of participants misbehaving. → Article 4
Hardware and enclaves
SGX / SEV-SNP / TDX Three competing implementations of the enclave idea, from Intel (SGX, TDX) and AMD (SEV-SNP). They differ in how much they protect and how much memory they allow. SGX protects the smallest, most precisely defined unit of code; the other two protect an entire virtual machine, with a bigger memory budget and a correspondingly larger surface to trust. → Article 1
MRENCLAVE The fingerprint (a hash) of the exact code loaded into an enclave. The thing attestation actually proves. → Article 1
EPC (Enclave Page Cache) The limited pool of protected memory an enclave gets. Exceed it and the processor must encrypt and evict pages, which is hundreds of times slower than normal memory access (each page costs tens of thousands of CPU cycles). This is why enclave memory budgets are a design constraint, not a purchasing decision. → Articles 1 and 4
Sealing Encrypting data with a key derived from the chip itself, so the data can be written to disk and read back later by the same enclave — and by nothing else. A stolen drive yields ciphertext. → Articles 1 and 2
EGo The toolchain that lets ComputeFlux write nearly everything in ordinary Go and still run inside an enclave, avoiding the expensive boundary crossings that calling C code would require. → Article 1
Side channel An attack that infers secrets from indirect evidence — timing, power draw, cache behavior — rather than by reading data directly. The class of attack enclaves are weakest against. → Article 1
Cryptography
Threshold signature A signature produced by several parties cooperating, which looks to the outside world exactly like an ordinary single signature. → Article 3
Pedersen vs. Feldman Two schemes for splitting a key. Both are secure against today's computers. Pedersen additionally leaks nothing at all to an adversary with unlimited computing power — the reason ComputeFlux pays a little extra complexity for it. → Article 3
Ed25519 / BLS12-381 / secp256k1 Three families of signature mathematics. Different blockchains require different ones, which is why ComputeFlux supports more than one from a single setup ceremony. BLS has the special property that many signatures collapse into one cheap-to-verify signature. → Article 3
Nonce A number used once. Two distinct jobs in this series: preventing the same transaction from being replayed twice, and supplying one-time randomness during signing. Reusing one in the second sense leaks the private key outright. → Articles 3, 4, 19
NIZK (Non-Interactive Zero-Knowledge proof) A proof that a statement is true which reveals nothing beyond its truth, and requires no back-and-forth with the verifier. Used to prove a node did its part of a computation correctly without exposing its secret share. → Article 3
Proxy re-encryption Transforming a message encrypted for one recipient into a message encrypted for another, without anyone in the middle ever seeing the plaintext. → Article 3
Merkle proof A compact proof that a specific item is included in a large dataset, verifiable against a single short fingerprint of the whole set. The basis of trust-minimized bridges. → Article 11
MPC-TSS Splitting a wallet key across multiple parties so no single one can spend — the technique behind social logins that produce a real wallet without a seed phrase. → Article 16
Blockchain and consensus
CometBFT The consensus engine ComputeFlux uses: the software that gets independent validators to agree on an ordered list of transactions. Descended from Tendermint, battle-tested across the Cosmos ecosystem. → Article 4
Validator A machine that participates in deciding what goes into each block. In ComputeFlux, every validator must additionally prove via attestation that it's running unmodified code. → Article 4
Vote extension A slot in a block vote where a validator can attach extra data. ComputeFlux uses it to attach a fresh attestation certificate to every vote, so a machine compromised after joining is caught. → Article 4
Proposer The validator whose turn it is to assemble the next block. Chosen by a schedule everyone knows in advance, which is what makes proposing out of turn detectable. → Article 4
Finality The point after which a transaction cannot be reversed. Different chains reach it at very different speeds, which is why cross-chain operations wait. → Articles 10 and 11
Sudo The founding administrator key that can act without a vote. Exists because a brand-new chain has nobody to vote yet. In ComputeFlux it can be permanently switched off, with no code path to switch it back on. → Article 17
Slashing Confiscating a participant's staked deposit as a penalty for misbehavior. → Articles 6, 17, 18
Sybil attack Creating many fake identities to overwhelm a system that assumes one identity per person. The reason deposits and one-identity-per-address rules exist. → Articles 6 and 18
Contracts and storage
Smart contract Code that runs on the blockchain itself, where every validator executes it and agrees on the result. → Article 5
WASM (WebAssembly) A portable, sandboxed instruction format. ComputeFlux uses it to run user-deployed contracts safely — the sandbox is what stops one contract touching another's data. → Article 5
Native vs. WASM path ComputeFlux's two tiers of contract. Native contracts are compiled into the enclave binary, so attestation vouches for them directly. WASM contracts are loaded from chain data — more flexible, one tier down in trust. → Article 5
Migration Rewriting existing stored data so it matches a new code version. The genuinely hard half of upgrading a blockchain, and the half most designs skip. → Article 5
PebbleDB / LSM-tree The storage engine and the data structure underneath it. Optimized for fast writes, at the cost of periodically rewriting data in the background (compaction). → Article 2
Determinism The property that the same input always produces exactly the same output on every machine. Non-negotiable in consensus: a system where two honest validators can disagree has no consensus at all. → Articles 2, 5, 19
Atomicity All-or-nothing. Either every change in a batch happens or none of them do — never half. → Articles 2 and 5
Routing, serving, and failure
Gateway The front door: the service that accepts your API request, decides where to send it, translates it if needed, and returns the answer. → Articles 8 and 12
Provider Anyone offering AI capacity through the network — a company reselling access to a commercial API, or an individual with a GPU. → Article 6
KV cache The work an AI model has already done on your earlier text, held in the GPU's memory. Reaching the same machine again skips redoing it — often the difference between seconds and half a second. → Article 8
Session affinity ("sticky" routing) Deliberately sending the same user back to the same machine, so the cache above stays warm. The opposite of conventional load balancing, for a good reason. → Article 8
EWMA (Exponentially Weighted Moving Average) An average that gives recent measurements more weight and lets old ones fade. Used so one freak ten-second timeout doesn't poison an endpoint's score for the next hundred requests. → Article 8
Circuit breaker A switch that stops calling a failing service entirely for a while, rather than continuing to retry. Recovery is tested with a few probe requests, never a flood. → Article 9
Exponential backoff with jitter Waiting longer after each failed attempt, plus a random nudge. The randomness is essential: without it, everything that fails together retries together forever. → Article 9
Edge route A personal GPU connected to the network through an outbound tunnel, because home internet connections can't accept incoming connections. → Article 7
NAT / CGNAT The reason your home computer has no address the internet can dial directly. Carrier-grade NAT means hundreds of households share one public address. → Article 7
Yamux The multiplexing layer that lets one tunnel connection carry hundreds of independent simultaneous requests. → Article 7
Protocols and APIs
SSE (Server-Sent Events) The one-way streaming format behind the typewriter effect in every AI chat product. Plain text over ordinary HTTP, which makes it inspectable with standard tools. → Article 14
Backpressure What makes a fast producer slow down when its consumer can't keep up. Get it wrong and one slow user can exhaust the server's memory. → Article 14
Protocol adaptor The translation layer between the incompatible request formats used by different AI vendors. → Article 12
Hub-and-spoke conversion Translating everything through one canonical middle format instead of writing a converter for every pair. Turns quadratic work into linear work — at the cost of losing anything the middle format can't express. → Article 12
Tool call / function calling An AI model asking to run an external function rather than just producing text. The hardest thing to translate while streaming, because it arrives in fragments across many messages. → Articles 12 and 14
REST vs. GraphQL Two API styles. REST here is an obligation — thousands of existing tools speak it and would break otherwise. GraphQL is a choice, letting a dashboard request exactly the fields it needs in one round-trip. → Article 15
Protobuf / vtproto A compact binary format for structured data, and a tool that generates faster packing code for it. → Article 13
Serialization Turning a structure in memory into bytes for sending or storing, and back again. Ordinary-sounding, and a real cost when it happens four times per transaction. → Article 13
Money and operations
Settlement Recording who owes what, permanently and verifiably, on the blockchain. → Article 10
Token (two meanings — watch for context) In AI, a chunk of text roughly the size of a short word; the unit you're billed by. In crypto, a unit of currency. This series uses both, and the surrounding sentence disambiguates. → Article 10
Relay / bridge Machinery that carries information from one blockchain to another. Historically the most exploited component in crypto, which is why ComputeFlux's is deliberately narrow. → Article 11
Distributed tracing Recording the path and timing of a request as it passes through many components, so "it's slow" becomes "it's slow here." → Article 20
Span One timed step inside a trace. Assembled together, spans form the request's timeline. → Article 20
Sampling Recording only a fraction of traces, to control cost. The tension is that the interesting failures are usually the rare ones. → Article 20
Trusted Computing Base (TCB) The complete set of things that must be working correctly and honestly for a system's security to hold. Smaller is better, and shrinking it is what most of this series is about. → Article 21
Simulation mode Running enclave code without enclave hardware. No real security, full behavioral fidelity — which is what makes it possible to develop and contribute on an ordinary laptop. → Article 21