Zero-Knowledge Proofs (ZKPs)
Writing ZK Circuits with Domain-Specific Languages
A developer's guide to the workflow of arithmetization and circuit design using high-level ZK languages like Noir and Cairo.
In this article
The Transition from Logic to Math
Traditional software engineering relies on the sequential execution of logic gates and memory registers where the source of truth is the processor state. In the world of zero knowledge proofs, we replace this execution model with a system of mathematical equations known as arithmetization. This process transforms a program from a series of steps into a single verifiable statement that can be checked without repeating the original work.
The underlying problem we solve is how to prove that a specific computation was performed correctly without revealing the sensitive inputs used during that computation. By converting logic into polynomials over finite fields, we enable a verifier to check the integrity of the result by evaluating a small number of random points. This shift requires a mental model where variables are no longer just memory locations but elements in a large prime field.
Arithmetization acts as the bridge between the high level code written by a developer and the low level cryptographic primitives required for proof generation. Depending on the proof system, this transformation might result in a Rank One Constraint System or an Algebraic Intermediate Representation. Understanding which model a language uses is essential for optimizing the performance and security of the final circuit.
Arithmetization is the process of reducing a computational statement to an algebraic statement involving polynomials of a bounded degree. This is the foundation upon which all modern zero-knowledge proof systems are built.
The Role of Finite Fields
Every variable in a zero knowledge circuit lives within a finite field, which is a set of numbers that wraps around a large prime modulus. This means that standard integer operations like addition and multiplication behave differently than they do in general purpose languages like Python or C. If an operation exceeds the prime modulus, it will wrap around to zero, which can lead to unexpected security vulnerabilities if not handled with care.
Developers must be aware that there are no native floating point numbers or negative integers in these fields. All complex data types must be mapped to field elements, which usually range from two hundred fifty-four to three hundred eighty-four bits in size. This mapping is the first step in designing a circuit and dictates the precision and scale of the logic being proven.
Constraint Systems and R1CS
A Rank One Constraint System represents a computation as a set of linear equations of the form a times b equals c. Each equation represents a single gate in the arithmetic circuit, and the entire set of equations must hold true for a proof to be valid. This structure is the most common format for SNARK based systems and requires a developer to think in terms of wires and constraints rather than lines of code.
The efficiency of a circuit is measured by the number of constraints it generates during the compilation process. Fewer constraints lead to faster proof generation times and lower computational costs for the prover. When writing high level logic, the goal is always to minimize these constraints while ensuring that the mathematical model perfectly mirrors the intended program behavior.
Building Circuits with Noir
Noir is a domain specific language that brings the ergonomics of the Rust programming language to the world of zero knowledge circuits. It abstracts the complexities of the underlying mathematics, allowing developers to focus on the business logic of their private applications. By using a familiar syntax, Noir reduces the barrier to entry for engineers who are not specialized cryptographers.
When you compile a Noir program, it produces an intermediate representation called the Abstract Circuit Intermediate Representation. This bytecode is backend agnostic, meaning it can be proved using different cryptographic backends like Barretenberg or Marlin. This flexibility is a key advantage for developers who want to future proof their applications against changes in the proof system landscape.
1use dep::std;
2
3fn main(
4 // The private input stays on the user device
5 birth_year: Field,
6 // The public input is visible to the verifier
7 current_year: pub Field
8) {
9 // Calculate the age using field arithmetic
10 let age = current_year - birth_year;
11
12 // Constrain the result to ensure the age is 18 or older
13 // Noir uses the assert method to create circuit constraints
14 assert(age as u32 >= 18);
15}In the example above, the birth year is a private input that the prover knows but never shares with the verifier. The circuit proves that the difference between the public current year and the private birth year is at least eighteen. If a user tries to generate a proof with a birth year that does not satisfy this constraint, the underlying mathematics will fail and no valid proof will be produced.
The Abstract Circuit Intermediate Representation
The compilation process in Noir transforms the high level syntax into a series of opcodes within the Abstract Circuit Intermediate Representation. These opcodes describe the logical gates and black box functions like hash algorithms that the proving system must implement. This layer of abstraction allows for high level optimizations, such as removing unused wires or merging redundant constraints, before the final arithmetic circuit is built.
Developers can inspect the output of the compilation to see exactly how many constraints each function in their code produces. This feedback loop is vital for performance tuning, as certain operations like bitwise logic or string manipulation can be surprisingly expensive in a zero knowledge context. Using built-in standard library functions is usually more efficient because they are pre-optimized for the target backend.
Witness Generation and Proving
Before a proof can be generated, the developer must provide the specific values for every input variable, which is known as generating the witness. The witness is a complete assignment of values to every wire in the circuit that satisfies all the defined constraints. This step happens locally on the prover device to ensure that private data remains confidential throughout the entire workflow.
The time it takes to generate a proof depends on both the complexity of the circuit and the hardware capabilities of the prover. While verification is almost instantaneous for the verifier, the prover must perform heavy cryptographic operations over the entire witness. Managing this asymmetry is a core part of designing a scalable user experience in decentralized networks.
Verifiable Computation with Cairo
Cairo takes a fundamentally different approach than Noir by focusing on a provable CPU architecture rather than a static circuit. Instead of building a custom circuit for every program, Cairo uses a single universal circuit that represents a virtual machine. This allows developers to write general purpose code, including loops and recursions, which are then proved as a trace of the virtual machine execution.
The arithmetization used by Cairo is the Algebraic Intermediate Representation, which describes the state transitions of the Cairo Virtual Machine over time. This model is particularly well suited for the STARK proof system, which offers high scalability and does not require a trusted setup. For a developer, this means the focus shifts from managing wires to optimizing the execution trace of their program.
1// Cairo code looks like Rust but executes on a provable VM
2fn main() {
3 let mut current_sum: u128 = 0;
4 let mut iterations: u128 = 0;
5
6 // Loops are native and generate an execution trace
7 while iterations < 100 {
8 current_sum += iterations;
9 iterations += 1;
10 };
11
12 // The final state is constrained to match the expected result
13 assert(current_sum == 4950, 'Incorrect sum calculated');
14}In this Cairo program, the entire loop execution is recorded as an algebraic trace where each row represents a point in time for the registers. The STARK prover then creates a proof that there exists a sequence of register states starting at zero and ending at the final sum that follows the instruction set rules. This enables highly complex computations to be verified on chain with minimal gas costs.
The Cairo Virtual Machine and Execution Traces
The Cairo Virtual Machine executes instructions deterministically to produce a two dimensional table known as the execution trace. One dimension represents the various registers of the CPU, while the other dimension represents the steps of the computation. Each entry in this table is a field element that must satisfy the transition constraints defined by the Cairo architecture.
Because the execution trace can have a variable number of rows, Cairo is inherently more flexible than fixed circuit systems. This flexibility allows for dynamic branching and variable length loops that would be difficult to represent in a standard Rank One Constraint System. However, this comes at the cost of requiring a more complex prover infrastructure to handle the algebraic commitments of the trace.
Transition Constraints and Boundary Checks
Transition constraints are the rules that dictate how the values in one row of the execution trace relate to the values in the next row. For example, a constraint might specify that the program counter must increment by one unless a jump instruction is executed. These constraints ensure that the prover cannot inject arbitrary values into the middle of the computation to cheat the system.
Boundary constraints are used to pin specific values at the beginning or end of the execution, such as the initial state of a database or the final hash result. Together, these two types of constraints define the entire logic of the program. If the prover can provide a trace where every row satisfies the transition rules and the boundaries are correct, the verifier is mathematically certain that the program was executed faithfully.
Security and Performance Trade-offs
One of the most dangerous pitfalls in circuit design is the under-constrained circuit, where a developer fails to provide enough mathematical equations to lock down the behavior of the prover. In a standard program, an unconstrained variable might lead to a crash, but in a zero knowledge proof, it allows a malicious prover to forge a valid proof with fraudulent data. This is why testing for soundness is even more critical than testing for correctness.
Performance in these systems is often a trade-off between the complexity of the code and the time required for proof generation. Using unconstrained hints or black box functions can significantly speed up the prover by moving expensive logic outside the arithmetic constraints. However, every hint must be carefully verified within the circuit to ensure that the prover is not providing incorrect data to the system.
- Field Overflow: Always check if your field operations wrap around the prime modulus unexpectedly.
- Under-constrained Logic: Ensure that every variable that influences the outcome is strictly constrained by an equation.
- Prover Costs: High constraint counts or large execution traces will lead to long proving times on client devices.
- Trusted Setup: Determine if your chosen proof system requires a ceremony to generate initial parameters.
- Data Privacy: Declare variables as private or public explicitly to avoid leaking sensitive information through proofs.
Recursive proofs represent the cutting edge of zero knowledge scalability, where a single proof is generated to verify the validity of multiple other proofs. This allows for horizontal scaling where thousands of transactions can be compressed into a single succinct proof for the main blockchain. Implementing recursion requires a deep understanding of proof composition and the mathematical overhead of the verification logic.
The Under-Constrained Circuit Vulnerability
An under-constrained circuit occurs when the mathematical statement being proven is less restrictive than the intended logical statement. For example, if you want to prove that you know two numbers that multiply to ten, but you forget to constrain the numbers to be non-zero, a prover could use zero and an undefined value. This subtle gap between logic and math is the source of the vast majority of security bugs in zero knowledge applications.
To mitigate this risk, developers should use static analysis tools and formal verification where possible to check that every input and intermediate result is properly constrained. It is also a best practice to keep circuits small and modular, making it easier to reason about the mathematical properties of each component. Soundness is a property that must be earned through rigorous design rather than just inherited from the language.
Scaling via Proof Recursion
Proof recursion works by writing a circuit that implements the verification logic of another proof system. When this circuit is proved, it results in a single proof that represents the validity of the entire chain of previous computations. This technique is essential for building zero knowledge rollups where thousands of user actions are verified in a single step on the layer one blockchain.
The main challenge with recursion is the computational overhead of the inner verification process, which often requires complex elliptic curve arithmetic. Modern languages like Noir and Cairo provide built-in primitives to handle this complexity, but developers must still manage the depth of the recursion to keep proving times manageable. Successfully implementing recursion can reduce the on-chain verification cost by orders of magnitude.