This page gives the context behind ZisK. It traces zero-knowledge proofs through SNARKs, STARKs, and recursion/aggregation, explains the shift from hand-written circuits to general-purpose zkVMs, surveys the axes that distinguish one zkVM from another (ISA, proof system, prime field, continuation strategy, architecture, and security), and shows the specific position ZisK takes on each.

Background

Before getting into how ZisK works, it helps to understand the problem it solves. Zero-knowledge proofs are powerful but historically painful to use; zkVMs are the response, and ZisK is one specific point in that design space. This page walks through how the field got here, what every zero-knowledge virtual machine has to choose, and where ZisK lands among the alternatives.

A short history of zero-knowledge proofs

Zero-knowledge proofs as a cryptographic concept go back to the 1980s, but they only became practical relatively recently. The shift came in three waves, each one expanding the range of things a ZK proof could plausibly be used for.

SNARKs

The first practical wave was the rise of SNARKs (Succinct Non-interactive ARguments of Knowledge. Proof systems whose proofs are short, fast to verify, and produced without requiring any back-and-forth between prover and verifier. Frameworks like Groth16 and PLONK made it tractable to express small circuits and generate proofs for them on commodity hardware.

The catch was a trusted setup: SNARK schemes typically require a one-time ceremony whose secret randomness must be honestly discarded. If anyone retains it, they can forge proofs. The setup is per-circuit (or, with universal schemes, per-curve), and getting its security right is a non-trivial operational concern.

STARKs

The next wave was STARKs (Scalable Transparent ARguments of Knowledge). Proof systems built on collision-resistant hash functions and polynomial commitments rather than elliptic-curve pairings. The trade-off is larger proofs, but two things are gained:

Property	What it means
No trusted setup	STARK's parameters are public; there is no ceremony whose output you have to trust.
Post-quantum security	The underlying assumptions (collision-resistant hashing, low-degree testing) are believed to remain hard against quantum adversaries.

STARKs made it possible to prove much larger computations and to operate proving systems without an ongoing trust burden, at the cost of producing larger proofs, which then motivated the third wave.

Recursion & aggregation

The third wave was the realization that a verifier is itself a computation, and so a proof of a verifier running is itself a proof. Recursive proof systems turn this into a tool: many small proofs can be combined into one, and one proof system's output can be re-proved in another (smaller, faster-to-verify) proof system. This is what made the practical pattern of "prove with a STARK, wrap with a SNARK for on-chain verification" possible, and what makes proving systems horizontally scalable, since independent proofs can be aggregated up a tree.

ZisK uses all three layers: STARKs over the Goldilocks prime field for the per-segment proofs, recursion for aggregating them, and optional PLONK wrapping for on-chain verification.

Why zkVMs are now plausible

With these primitives in hand, the cost of proving a general-purpose computation dropped enough that the question shifted from "can we prove a circuit at all?" to "can we prove an arbitrary program fast enough to be useful?" That is exactly the problem zkVMs answer.

From circuits to zkVMs

The first generation of ZK systems asked developers to hand-write arithmetic circuits for every computation. Every application needed ts own circuit, its own security review, and its own maintenance. Nothing that looked like ordinary software engineering.

zkVMs invert that pattern. One general-purpose circuit verifies the execution of any program targeting a known ISA, so developers write ordinary code and never touch a constraint. The engineering effort moves from "a new circuit per application" to "one circuit reused across millions of programs".

The trade-off is precision and efficency: a hand-tuned circuit will always beat a general-purpose one running the same task as a program. zkVM design is largely the work of closing that gap without giving up the developer experience.

The zkVM design space

The choices that distinguish one zkVM from another fall along a small number of axes: which instruction set to prove, which proof system to build on, which finite field to work in, how to split long executions into segments, and what security level to target. Some are settled across the industry; others are still genuinely contested.

ISA

The first decision in any zkVM design is which instruction set to prove. This determines the entire downstream toolchain: the language a developer writes in, the compiler that produces the binary, the libraries that work, and how expensive each instruction is to constrain. Two main camps exist:

Camp	What it gives	What it costs
ZK-native ISAs	Compact constraints as operations are chosen to be cheap to encode in finite-field arithmetic.	A new programming model: new compilers, toolchains, debuggers, libraries. Mainstream Rust/C does not run without porting.
Standard ISAs	Existing Rust/LLVM toolchain works directly; any RISC-V binary runs unchanged.	A general-purpose register machine is expensive to constrain as operations that look trivial in hardware become many constraints per step.

ZK-native ISAs tend to fit application-specific provers where you control the source. Standard ISA fit general-purpose proving of existing Rust or C code and RISC-V is the universal pick.

Proof Systems

Three options exist in the broader proof-system space:

Option	Trade-off
Pure SNARK	Small proofs and cheap on-chain verification; trusted setup required and not post-quantum.
Pure STARK	No trusted setup, post-quantum; larger proofs and more expensive on-chain verification.
STARK with SNARK wrap	STARKs do the heavy lifting; an optional final SNARK wrap shrinks the proof for on-chain use.

For general-purpose zkVMs, STARK with an optional SNARK wrap has become the standard. Pure SNARK persists in domain-specific provers where minimum proof size outweighs the cost of a trusted setup.

Prime Field

STARKs operate over small prime fields chosen so that field arithmetic is cheap and the FFT / FRI machinery works efficiently — concretely, a small modulus and high two-adicity. Within that category, several named options have emerged and zkVMs do genuinely diverge:

Field	Parameters	Notable for
Goldilocks	p = 2⁶⁴ − 2³² + 1; two-adicity 32	64-bit prime that maps cleanly onto native CPU words; the natural pick for 64-bit RISC-V.
BabyBear	p = 2³¹ − 2²⁷ + 1; two-adicity 27	31-bit prime; two field elements fit in a 64-bit word. Faster on 32-bit / wasm hardware but needs deeper extension fields for soundness.
Mersenne-31	p = 2³¹ − 1; two-adicity 1	Mersenne prime with the fastest possible modular reduction; low two-adicity means standard FFT does not work directly.
KoalaBear	p = 2³¹ − 2²⁴ + 1; two-adicity 24	31-bit compromise between BabyBear and Mersenne-31.

Continuation Strategy

A single proof can only cover a fixed-height trace, so any zkVM that proves long programs has to split execution into segments. The mainstream approach is checkpointed continuations. A minority of systems use trace splitting instead.

Option	Trade-off
Checkpointed continuations	Run for N steps, halt, save the state, prove, resume. Simple but introduces padding overhead in every chip in every segment.
Trace splitting	Run the program first, then partition each chip's trace independently. Eliminates most padding but introduces cross-chip and cross-segment consistency complexity at the recursion layer.

Architecture

zkVMs also differ in how the proof itself is structured.

Approach	What it looks like	Trade-off
Monolithic	One large circuit covers every ISA instruction; the prover runs through every constraint on every execution step.	Conceptually simple, but the prover is a single sequential job and scaling is bounded by the slowest part of the circuit.
Modular	The proof is decomposed into many small specialised sub-circuits ("chips"). Consistency between chips is enforced by a bus-balancing argument.	Each chip proves only its own local constraints; chips can be optimised independently and proved in parallel. The bus-balancing argument has to be enforced globally at the recursion layer.

Modular designs dominate performance-oriented zkVMs. They also enable extensibility as a new primitive (a hash function, an elliptic-curve operation, a bulk memory transfer) can be added as a new chip with a defined bus interface, without modifying the rest of the system.

Security

A cryptographic scheme has provable security when breaking it can be reduced to a well-studied hard problem. The reduction tells you precisely how much work an attacker has to do: as long as the underlying problem stays hard, the scheme stays unbroken.

That work factor is measured in bits of security. A scheme with κ bits is conjectured to require ~2^κ basic operations to break, so larger numbers mean a more conservative system. The cryptography-industry default is 128 bits; the level NIST recommends and most modern primitives target.

ZisK proof system design

ZisK takes a specific position on each axis from the design space above.

Axis	ZisK's choice	Why
ISA	Standard, RV64IMA (+ optional F/D/C)	Reuse the LLVM/Rust toolchain; the constraint cost of a general-purpose register machine is absorbed by the modular chip architecture, not by porting code.
Proof system	STARK + recursion + optional PLONK wrap	No trusted setup, post-quantum; the PLONK wrap is a deployment option for EVM verification when on-chain cost dominates.
Field	Goldilocks (p = 2⁶⁴ − 2³² + 1), cubic extension 𝔽[X]/(X³ − X − 1) for soundness	The 64-bit prime aligns with 64-bit RISC-V instructions: field elements fit in a single CPU word, and arithmetic runs fast on commodity x86 and ARM.
Continuation strategy	Trace splitting, with LtHash for cross-chip consistency	Padding is limited to the final segment of each chip; LtHash lets challenges be derived in parallel without ordering constraints.
Security	~128 bits, lattice-backed	Standard industry target. Rests on hash collision-resistance, FRI low-degree testing, and SIS (post-quantum).
Architecture	Modular chips on a shared bus	One specialised sub-circuit per primitive (memory, ALU, Keccak, SHA-256, EC, …). New primitives add as new chips without touching existing ones.