zkVM & STARK Glossary
Sixteen terms, defined the standard way first, then grounded in exactly where each one shows up in this repo's real code — not a generic crossword-style dictionary disconnected from an actual implementation. Each term also has its own page, linked below and from every heading.
zkVM
zero-knowledge virtual machineA virtual machine whose execution can be proven correct with a cryptographic proof, so a verifier can check the result without re-running the program. Despite the name, most zkVMs (this one included) don't hide any inputs — "zk" here is industry shorthand for "provable," not a guarantee of privacy.
In this repo: a small accumulator-plus-registers machine defined in zkvm-isa, executing .zkasm programs (ADD/SUB/MUL/JZ/JNZ/LOAD/STORE). See the homepage for the full instruction set.
STARK
Scalable Transparent ARgument of KnowledgeA type of cryptographic proof that a computation was performed correctly. "Scalable" means proving/verifying cost grows well with computation size; "Transparent" means it needs no trusted setup ceremony (unlike many SNARKs); "Argument of Knowledge" means it proves the prover actually knows a valid execution, not just that one could exist.
In this repo: produced by zkvm-stark::prove_program and checked by verify_program, built on Winterfell. Real proof, ~11 KB, ~5.5ms to verify — see the verify-time benchmark post.
SNARK
Succinct Non-interactive ARgument of KnowledgeThe other major family of proof system. SNARKs typically produce smaller proofs and cheaper on-chain verification than STARKs, at the cost of larger proving keys, often a trusted setup, and (for most constructions) vulnerability to quantum attacks that STARKs' hash-based commitments resist.
In this repo: not used directly, but relevant to the honest scope of the on-chain path — wrapping this system's STARK in a SNARK cheap enough to verify on-chain is one of two paths described in docs/ONCHAIN_VERIFIER.md for closing the current trust gap. See the trust-boundary post.
AIR
Algebraic Intermediate RepresentationThe set of polynomial constraints that describe "what makes an execution trace valid" for a STARK. An AIR splits into transition constraints (checked between consecutive rows) and boundary constraints (checked at specific rows, like the first or last).
In this repo: VmAir in crates/zkvm-stark/src/lib.rs — one transition constraint for the accumulator, one per register, and nine boundary assertions per row. Full walk-through: Reading a Winterfell AIR.
Execution trace
A table recording the full state of a machine at every step of a computation — one row per step, one column per piece of state. The AIR's constraints are checked against this table.
In this repo: one row per static instruction (not per executed step — a skipped branch still gets a row with active = 0), 10 fixed columns plus two per register. Produced by zkvm_isa::execute.
Transition constraint
A polynomial equation that must hold between every consecutive pair of rows in the trace — the algebraic way of saying "this column evolves correctly from one step to the next."
In this repo: exactly two shapes — the accumulator's update, and each register's update — both walked through line by line in Reading a Winterfell AIR, including why the declared degree is 4 even though the interpolated degree is usually 3.
Boundary constraint
A polynomial equation that must hold at one specific row of the trace — typically the first, the last, or (less commonly) every row when the verifier already knows the correct value there.
In this repo: used unusually heavily — nine values are boundary-asserted on every row, not just the first/last, because there's no secret witness to hide them behind. See why this zkVM's soundness doesn't need a lookup argument.
FRI
Fast Reed-Solomon Interactive Oracle Proof of ProximityThe low-degree testing protocol that lets a STARK prover convince a verifier that a committed polynomial really is close to low-degree, without the verifier evaluating it everywhere. It's the piece that makes STARKs "scalable" and avoids a trusted setup.
In this repo: handled entirely inside Winterfell — this project doesn't implement FRI itself, it configures and calls Winterfell's implementation via ProofOptions in zkvm-stark.
Winterfell
A Rust STARK prover/verifier library, originally released by Facebook/Novi. It handles the FRI protocol, polynomial commitments, and Merkle tree machinery; callers define an Air implementation describing their own transition and boundary constraints.
In this repo: the entire cryptographic engine underneath zkvm-stark. One quirk worth knowing if you're using it too: its debug-only validate_transition_degrees self-check is stricter than actual soundness requires — see the reproduction and why release mode is correct here.
Witness
The private input to a computation that a prover knows but a verifier doesn't — the thing a zero-knowledge proof lets you prove something about without revealing. Contrasted with public inputs, which both parties see.
In this repo: there isn't one — see no secret witness.
No secret witness
This project's own term (not standard industry vocabulary) for a specific design choice: the program and its inputs are entirely public, so the verifier can re-execute the program itself and knows the correct value of almost every trace column in advance — turning most of what would need an algebraic gadget elsewhere into a direct boundary assertion.
In this repo: the reason branch outcomes and register selectors don't need an is-zero/lookup gadget. Full argument: Why This zkVM's Soundness Doesn't Need a Lookup Argument.
One-hot selector
A set of columns where exactly one is 1 and the rest are 0, used to encode "which of N options is active" in a way that's cheap to check and multiply against algebraically (multiplying by a 0/1 selector acts like a conditional).
In this repo: two uses — seven columns selecting the opcode (s_add...s_store), and NUM_REGISTERS columns (reg_sel) selecting which register a LOAD/STORE addresses. See A Register File Without an Algebraic Mux.
Prover
The party that runs a computation and produces a proof of its correctness. Proving is typically far more computationally expensive than verifying — that asymmetry is the whole value proposition of a STARK/SNARK.
In this repo: zkvm-stark::prove_program, callable via the CLI, POST /v1/proofs, or the prove MCP tool. Real measured proving times: ~1.2s at 1,000 instructions, ~32s at 4,000 — see the hardening post for why that curve matters.
Verifier
The party that checks a proof without needing to trust the prover or re-run the full computation. A sound proof system guarantees a verifier will reject any proof of a false claim, no matter how the prover tries to cheat.
In this repo: zkvm-stark::verify_program, ~5.5ms measured end to end including re-execution — see the verify-time post for the exact methodology.
Attestation
In this context: a signed statement from a designated party that something is true, used as a (trusted, not cryptographic) stand-in for a check that isn't otherwise implemented. Different from a proof — an attestation asks you to trust who's speaking, a proof doesn't.
In this repo: AttestedVerifier.sol accepts a proof once a designated attester address calls attest(...) — an explicit trust bridge, not a cryptographic on-chain check. See The Trust Boundary, Written Down.
MCP
Model Context ProtocolAn open protocol for connecting AI applications (like Claude or Cursor) to external tools and data sources over a standard initialize → tools/list → tools/call handshake.
In this repo: prove and verify exposed as real MCP tools via the rmcp crate, on their own port (4478) rather than nested onto the HTTP API. See Connecting Claude to a Real STARK Prover via MCP.