Skip to main content

Key Terminology


A mathematical construct that acts as the "CPU" of the zkVM in a manner that enables creating proofs.
See also: Arithmetic Circuits

Clock cycles

The smallest unit of compute in the zkVM circuit, analogous to a clock cycle on a physical CPU. The complexity of a guest program's execution is measured in clock cycles as they directly affect the memory, proof size, and time performance of the zkVM.

Generally, a single cycle corresponds to a single RISC-V operation. However, some operations require two cycles.


Append data to the journal.
See also: env::commit()


As of our 0.15 release, the zkVM uses continuations to enable proof generation for very large programs without blowing up memory requirements. Large proof generation is made possible by splitting the execution trace for a single session into a number of segments, and proving those segments independently.
See also: Continuations study club, Continuations blog

ELF Binary

The executable format for the RISC-V instruction set. Each method in a guest program is written in Rust and compiled into an ELF binary before execution begins. Then, the ELF binary is executed and proven.


Run a method inside the zkVM and produce an execution trace which can be used by the prover to create a proof of correct execution.


The portion of the zkVM responsible for generating the execution trace.
See also: Executor documentation, Prover

Execution Trace

A complete record of a computation. The execution trace is organized as a rectangular array, where each row describes a complete snapshot of the state of the zkVM at a given moment in time. The width of the execution trace relates to the number of registers/components in the machine, and the length of the execution trace relates to the number of clock cycles of the program's execution.

The execution trace is generated by the executor and checked for validity by the prover. A valid trace means that the ELF binary was faithfully executed according to the rules of the RISC-V instruction set architecture.


The system running inside the zkVM.
See also: Rust crate for zkVM guest

Guest Program

The portion of a zkVM application that gets proven. The guest program receives inputs from an (untrusted) host. Depending on the application, the guest program can commit results to the journal and/or send them to the host.
See also: Rust crate for zkVM guest


The system the zkVM runs on.

Host program

The host-native, untrusted portion of a zkVM application. The host program loads the guest program and provides inputs to the guest program as necessary.

Image ID

A small cryptographic identifier that indicates the method or boot image for zkVM execution.
See also: ImageID documentation, ImageID excerpt from Study Club, segment


The portion of the receipt that contains the public outputs of a zkVM application.
See also: commit


A single 'main' entry point for code that runs inside the zkVM.


Generate a receipt that serves as proof of correct execution of a guest program.


The portion of the zkVM that uses the execution trace to construct the seal.
See also: Prover documentation, Executor


A receipt attests to valid execution of a guest program. Verifying the receipt provides cryptographic assurance that the journal was indeed constructed using the expected circuit and the expected imageID. The receipt consists of a journal and a seal. The journal attests to the public outputs of the program, and the seal is the opaque blob that cryptographically attests to the validity of the receipt.


The 5th edition of UC Berkeley's reduced instruction set computer architecture. RISC Zero uses RISC-V, specifically the rv32im instruction set, as the basis for the RISC Zero zkVM.


The portion of the receipt that cryptographically attests to the correct execution of the guest program. Concretely, the seal is a zk-STARK and is generated by the prover.
See also: Validity Proof


The execution trace of a portion of a guest program. The execution of a segment begins at some initial memory image (identified by the ImageID) and proceeds until terminated by the system or user. This represents a chunk of execution work that will be proven in a single call to the ZKP system.
See also: Session


The execution trace of a guest program. The session's execution starts from an initial memory image (which includes the starting program counter) and proceeds until either a sys_halt or a sys_pause syscall is encountered. This record is stored as a vector of Segments.


A STARK (scalable, transparent argument of knowledge) serves as proof of validity for a zkVM program.
See also: About STARKs, Sequence Diagram for RISC Zero's STARK, RISC Zero's ZKP Whitepaper

Validity Proof

A validity proof is a cryptographic argument that attests to the validity of an execution trace. The seal on the receipt serves as a validity proof for the RISC-V instruction set.


A program on the host that verifies a receipt.


Check that the receipt is valid. Verifying segment receipts requires checking that the seal is valid and was generated by the expected ImageID. Verifying session receipts requires checking the validity of each segment and checking that the initial/final memory snapshots for each segment align appropriately.

Zero-Knowledge Virtual Machine (zkVM)

A virtual machine that runs trusted code and generates proofs. RISC Zero's zkVM implements the RISC-V instruction set architecture and uses a STARK-based proof system.