Forem: 0xluk3

Hello Noir! [Part 1]

0xluk3 — Tue, 07 Apr 2026 07:28:57 +0000

ZK is a hot topic. But what does it even mean to build a ZK circuit? Let's build a barebone, super basic circuit so you can have a better understanding what its part of.

1. What we're building and the toolchain

What we're building through this series is a SNARK - a Succinct Non-interactive Argument of Knowledge. Barretenberg, the proving backend we'll use, implements UltraHonk - a PLONK-based proof system. PLONK and its descendants are SNARKs. The zero-knowledge part is actually optional (Barretenberg has a --zk flag for that), so what we produce is strictly a SNARK, not necessarily a zkSNARK - but the ecosystem loosely calls everything "zk" since the tooling supports it.
Here's the high-level flow of what we're doing:

We, the prover (the user), want to prove something - some statement, like "I am more than 20 years old"
We do this by supplying evidence that backs our statement - a blob of bytes, mathematically encoding our proof in a privacy-friendly way
Another party, the verifier, checks our proof according to some math formula
Since the verifier can live on-chain, it can be queried for the result and act upon it

So we use these tools to:

Noir - write the circuit (the constraints)
Barretenberg - generate proofs and verifier contracts
Foundry - deploy and test on-chain

Now, why those? We should be doing Noir ZK right?

Yes, but Noir is only the language of constraints - it tells the system what to prove. We also need to generate a proof (this will be what users submit) and a component to check if it's verifiable. Barretenberg is the proving backend that takes the compiled circuit and your inputs, produces the actual cryptographic proof, and can also generate a Solidity verifier contract. Foundry handles the on-chain side - deploying and testing that verifier. We won't use Foundry in this post, but it shows up in Part 2.

This is a barebone implementation of a ZK app.

2. Setting up the environment

Noir's toolchain depends on Rust. If you don't have it:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Install Noir via noirup:

curl -L https://raw.githubusercontent.com/noir-lang/noirup/refs/heads/main/install | bash
noirup

Verify with nargo --version.

Install Barretenberg via bbup:

curl -L https://raw.githubusercontent.com/AztecProtocol/aztec-packages/refs/heads/master/barretenberg/bbup/install | bash
bbup

Verify with bb --version.

That's it. You're ready to write a circuit.

3. Writing a sample circuit

Let's try to write a sample circuit. This will be a super dummy, in fact meaningless thing from ZK standpoint - just to understand the process and see how things work. We will build something actually working in the next article.

nargo new hello_world
cd hello_world

Project successfully created! It is located at /home/dev/noir-hello-world/hello_world

This creates Nargo.toml (the project manifest, think package.json or Cargo.toml) and src/main.nr - your circuit.

[package]
name = "hello_world"
type = "bin"
authors = [""]

[dependencies]

And the default src/main.nr:

fn main(x: u64, y: pub u64) {
    assert(x != y);
}

#[test]
fn test_main() {
    main(1, 2);

    // Uncomment to make test fail
    // main(1, 1);
}

Our circuit just checks if x is not equal to y. Simple. But notice the types - x is u64 and y is pub u64. In Noir, every input is private by default. If you want an input to be visible to the verifier (and to the world), you mark it pub.

So here, x is private and y is public. When a proof is generated, the verifier can see y but learns nothing about x. The proof only guarantees that some value of x exists that satisfies the constraint.

Here's a more intuitive example - imagine an age verification circuit:

fn main(age: u8, pub min_age: u8) {
    assert(age >= min_age);
}

Here min_age is explicitly set to public. While we generate the proof, age is not revealed, while min_age is public - anyone can see you're checking against 18. The proof says "this person is old enough" without revealing whether they're 19 or 90.

Now, we can run:

nargo check

This validates your circuit and creates a Prover.toml file - a template for your inputs:

x = ""
y = ""

Let's input some values:

x = "2"
y = "1"

And run:

nargo execute

[hello_world] Circuit witness successfully solved
[hello_world] Witness saved to target/hello_world.gz

The circuit compiled, the inputs satisfied the constraint (2 != 1), and nargo saved the result.

And what if we tried to prove something that does not meet constraints? Change Prover.toml so both values are equal:

x = "2"
y = "2"

Run nargo execute again:

error: Failed constraint
  ┌─ /home/dev/noir-hello-world/hello_world/src/main.nr:2:12
  │
2 │     assert(x != y);
  │            ------
  │
  = Call stack:
    1. /home/dev/noir-hello-world/hello_world/src/main.nr:2:12

Failed to solve program: 'Cannot satisfy constraint'

The inputs don't satisfy the rules. No witness is generated, no proof to produce.

4. What did nargo just produce

Look in the target/ directory. You'll find two files:

hello_world.json - the compiled circuit (ACIR) in a structured format. It contains the constraints and instructions that define your program after compilation. This is generated by nargo compile and doesn't depend on your specific input values - the same circuit can be used with different inputs.
hello_world.gz - the witness. This contains the specific values (both public and private) that satisfy the constraints. This is generated by nargo execute and does depend on what you put in Prover.toml.

These are two different artifacts, not compressed and uncompressed versions of the same thing.

To generate an actual cryptographic proof, you need both: the circuit (what to prove) and the witness (the values that satisfy it). That's where Barretenberg comes in.

5. What's next

So we have constraints (not equality requirement) and a proof that we were able to achieve that. But what nargo execute produced is not a cryptographic proof - it's just a confirmation that your inputs work. A verifier contract can't do anything with a .gz file.

I don't want to make articles too long. Because people tend to be scared and walk away when they see the scrollbar - so I moved that part to Part 2. In Part 2, we'll use Barretenberg to take the compiled circuit and witness, generate an actual cryptographic proof, verify it locally, and generate a Solidity verifier contract for on-chain verification.

Part 2 coming soon

Math cheatsheet before you deep-dive into ZK

0xluk3 — Mon, 06 Apr 2026 15:26:59 +0000

We're not going to explain ZK in five minutes here. We're not even going to touch it. But there are a handful of math topics you have to understand before anything in this series makes sense.

Are you scared of those nasty math symbols? Does opening an arxiv paper make you want to hide under your bed? Good. Same here. So let's get comfortable with it slowly, one concept at a time, with zero greek letters and some things you can click on.

1. Modular arithmetic

Think of a clock. A normal clock has 12 positions (0 through 11 if you're a programmer). If it's 10 o'clock and you add 5 hours, you don't get 15. You get 3. The number wraps around.

That's modular arithmetic. The mod operator gives you the remainder after division:

10 + 5 = 15 → 15 mod 12 = 3
7 + 7 = 14 → 14 mod 12 = 2

In crypto, the modulus isn't 12. It's a prime number so large it has 77 digits. But the principle is identical: every result wraps back into a fixed range, and that wrapping destroys information about the original inputs.

Try it yourself. The clock below uses a small modulus so you can watch values wrap around:

Interactive: Modular arithmetic clock visualization — try it on luk3.tech

Formal explanation: Modular arithmetic on Wikipedia

2. Finite fields

A finite field (also called a Galois field) is a set of numbers where you can add, subtract, multiply, and divide, and you never leave the set. Every operation wraps back into the same pool of values.

More precisely, a finite field GF(p) is the set of integers {0, 1, 2, ..., p-1} where p is prime, and all arithmetic is done mod p. Three properties matter:

Closed: No operation produces a result outside the set.
Every element has an inverse: For any number a in the field, there exists some b such that a * b = 1 (mod p). Division always works.
No escape: You can chain as many operations as you want. You're still in the field.

Why does crypto care? Because finite fields let you do complex algebra on huge numbers while guaranteeing that every intermediate result stays within a fixed, predictable range. No overflow, no floating point issues, no surprises. And the modular wrapping makes it extremely hard to reverse-engineer what inputs produced a given output.

Formal explanation: Finite field on Wikipedia

3. The discrete logarithm problem

Here's the core asymmetry that makes public-key cryptography possible.

The easy direction: Given a base g, an exponent k, and a modulus p, computing g^k mod p is fast. Computers are good at exponentiation.

g = 3, k = 5, p = 7
3^5 = 243 → 243 mod 7 = 5

The hard direction: Given g, p, and the result 5, find k. With small numbers you can just try them all. With numbers that have 77 digits? No known algorithm can do it efficiently. You'd be guessing until the heat death of the universe.

This is the discrete logarithm problem (DLP). "Discrete" because you're working in a finite field (discrete values, not continuous). "Logarithm" because you're trying to find the exponent.

When this same problem is framed on an elliptic curve (finding how many times a point was "multiplied" to produce another point), it's called the Elliptic Curve Discrete Logarithm Problem (ECDLP). Same idea, different algebraic structure, even harder to break.

Important distinction: "hard" here means computationally infeasible, not mathematically impossible. The answer exists. Nobody forbids you from finding it. It's just that the fastest known algorithms would take longer than the age of the universe on current hardware.

Formal explanation: Discrete logarithm on Wikipedia

4. Hash functions

A hash function takes any input (a single character, a novel, a video file) and produces a fixed-size output. SHA-256 always gives you 256 bits (64 hex characters). SHA-3 gives you the same. Doesn't matter if your input is four letters or four gigabytes.

But how? How does the word math turn into a0885e289f3e77a14e06e6887a1fc93b5ed2e14cfe7f7052805fe92e1a0e0e38?

What actually happens inside a hash

Let's walk through the rough steps. Different algorithms (SHA-2, SHA-3, BLAKE) vary in the details, but the skeleton is the same:

Step 1: Convert to binary. Your input becomes raw bytes. The string math becomes four ASCII values: 109 97 116 104, which in binary is 01101101 01100001 01110100 01101000.

Step 2: Pad the message. The algorithm needs the input to be a specific length (a multiple of the block size). So it appends a 1 bit, then enough 0 bits, then the original message length. Now you have a neat, fixed-size block to work with.

Step 3: Initialize state. The algorithm starts with a set of fixed constants as its internal state. These aren't secret. They're defined in the spec (for SHA-256 they come from the fractional parts of the square roots of the first eight primes, because why not).

Step 4: Compress, round after round. This is where the magic happens. The padded message gets split into chunks, and each chunk gets fed through a compression function that mixes it into the internal state. SHA-256 runs 64 rounds. SHA-3 runs 24. Each round does a combination of:

Bitwise operations: XOR, AND, NOT, rotations. These scramble the bits in non-linear ways.
Modular addition: Adding values mod 2^32, which causes carries to cascade unpredictably.
Mixing: Bits from different positions influence each other, so information spreads across the entire state.

The visualization below walks through the full SHA-256 computation for the word "math", step by step. You can see the padding, the message schedule, and how each round scrambles the working variables until the final hash emerges.

Interactive: SHA-256 step-by-step computation walkthrough — try it on luk3.tech

Step 5: Output. The final internal state (or a portion of it) becomes your hash.

The result is deterministic (same input, same output, every time) but practically irreversible. You can't reconstruct math from the hash any more than you can reconstruct an egg from an omelette. This makes hash functions a kind of trapdoor: easy to compute forward, impossible to reverse. You'll see this same pattern everywhere in cryptography. Your public key is derived from your private key through a trapdoor (the discrete log). Digital signatures use one. Hash functions are the simplest example: one-way, no way back.

Formal explanation: Cryptographic hash function on Wikipedia · Trapdoor function on Wikipedia

5. Constraints: how ZK thinks about computation

Here's where things start to feel unfamiliar.

Normally, when you want to prove you ran a computation correctly, you just re-run it and check the answer. ZK proofs take a completely different approach. Instead of re-running the program, you express the entire computation as a set of equations (called constraints) that must all be satisfied simultaneously.

A simple example. Say you want to prove you know two numbers that multiply to 35. Instead of revealing "5 and 7", you write a constraint:

a * b = 35

If you can provide values for a and b that satisfy this equation, you've proven you know them. The constraint system doesn't care how you found the values. It only cares that they satisfy the equations.

Real ZK systems express entire programs this way. A program that checks a password, verifies a merkle proof, or validates a transaction gets compiled into thousands (or millions) of constraints. The most common format for this is called R1CS (Rank-1 Constraint System), where every constraint has the form:

(left) * (right) = (output)

Each of left, right, and output is a linear combination of variables. The entire program becomes a system of these equations.

The key insight: "I know values that satisfy all these constraints" is a statement you can prove without revealing the values themselves.

Formal explanation: R1CS on Wikipedia

6. The idea behind zero-knowledge proofs

Now you have all the pieces. ZK proofs combine the concepts above into a single protocol.

The setup: there's a prover (who knows a secret) and a verifier (who wants to be convinced the prover knows it, without learning the secret).

A zero-knowledge proof has three properties:

Completeness: If the prover actually knows the secret, they can always convince the verifier. Honest provers always succeed.
Soundness: If the prover doesn't know the secret, they can't trick the verifier (except with negligible probability). Liars get caught.
Zero-knowledge: The verifier learns nothing beyond the fact that the statement is true. No information about the secret leaks.

Put those together with constraint systems and you get the full picture: the prover takes a program, compiles it into constraints, plugs in their secret values, and generates a proof that all constraints are satisfied. The verifier checks the proof without ever seeing the secret values.

The math that makes this actually work (polynomial commitments, elliptic curve pairings, Fiat-Shamir transforms) is deep. Future posts will go there. For now, the mental model is enough: constraints define what "correct" means, and ZK proofs let you demonstrate correctness without revealing your inputs.

Formal explanation: Zero-knowledge proof on Wikipedia