SNARKs: why a proof can be 256 bytes

Groth16 proves that you know values satisfying a system of equations of the form a · b = c, where a, b and c are sums of your variables. That's called a rank-1 constraint system. A circom circuit compiles down to one.

MiMC7, the hash in the lab's first experiment, runs 91 rounds of x ↦ (x + c)⁷. Each round takes four multiplications (x², x⁴, x⁶, x⁷), so 91 × 4 = 364 constraints. The allowlist circuit, with twelve Poseidon hashes up the tree plus the commitment and the nullifier, comes to 3,370. The proof is the same 256 bytes either way, and that is the point of a SNARK.

The prover turns the constraint system into polynomials and evaluates them, in the exponent, at a secret point τ that nobody knows. The output is three points, A and C on the curve's first group (64 bytes each) and B on the second (128 bytes). The verifier checks one equation with a pairing, a map that lets you multiply hidden exponents:

e(A, B) = e(α, β) · e(vk_x, γ) · e(C, δ)

Here vk_x folds the public inputs into the check. Solana programs rearrange it as e(−A, B) · e(α, β) · e(vk_x, γ) · e(C, δ) = 1, which is why the groth16-solana crate expects A already negated.

Somebody has to generate τ (and α, β, δ), publish points that encode them, and then destroy the numbers themselves. Those numbers are the toxic waste. Anyone holding them can make a valid proof of anything.

Ceremonies spread that risk. In phase 1, “powers of tau”, many people contribute randomness in turn, and the result is safe if even one of them destroyed their share. Phase 2 does the same per circuit. This site's keys use the Privacy & Scaling Explorations Perpetual Powers of Tau for phase 1 and a single phase-2 contribution made by our build script. That is fine for a demo, and it's also a good example of why you should check who ran phase 2 before trusting a verifier with money.

Keep this in mind for Chapter 4: the published points are public, and Shor's algorithm computes discrete logs. On Q-day the toxic waste can be recomputed.

Since July 2024 Solana has had syscalls for BN254: sol_alt_bn128_group_op (add, multiply, pairing) and sol_alt_bn128_compression. Agave's cost table prices them like this:

End to end, groth16-solana's own benchmarks measure 78,293 CU with one public input and 91,448 with four. Both are well under a transaction's 1.4 million CU. Byte for byte, the proof plus a few public inputs fits easily in a 1,232-byte transaction, and the lab serializes a real one to show it.

The curve used to be called alt_bn128, after the 128 bits of security it was thought to give. In 2016 the extended tower number field sieve (exTNFS) changed the estimate. The IETF's pairing-curves draft now puts BN254 at no more than about 100 bits against classical computers. That's still far beyond any real attack, but it's one reason newer systems moved to BLS12-381. Solana added BLS12-381 syscalls in June 2026.