Bump Noir toolchain to v1.0.0-beta.20

[BornPsych]

Moves the workspace from Noir v1.0.0-beta.11 to v1.0.0-beta.20. Most of the changes are for cargo.toml/cargo.lock.The interesting part is what the nine compiler releases did to our circuits, measured below.

Constraint counts

Measured with provekit-cli prepare from each toolchain:

circuit	beta.11	beta.20	change	padded size
t_add_dsc_720	362,446	413,191	+14.0%	2^19, same
t_add_id_data_720	156,408	174,071	+11.3%	2^18, same
t_add_integrity_commit	114,469	108,002	-5.6%	2^17, same
t_attest	22,845	22,275	-2.5%	2^15, same
complete_age_check	711,664	771,988	+8.5%	2^20, same

The growth has two sources, measured by changing one thing at a time on t_add_dsc_720:

• About a third is bignum hardening. v0.9 checks more in-circuit: #232 fixed a soundness gap (a witness could be off by a multiple of the modulus), #252 stopped trusting unconstrained hints, #241 widened the Barrett margin. On the beta.11 compiler this alone moves the circuit from 362k to 380k and explains all of the extra 120-bit range checks.
• The other two thirds is the compiler. beta.20 dropped the expression-width packing pass, so multiplication terms that beta.11 shared are now duplicated: 85k to 128k on the same circuit.

Downgrading bignum is not an option: nothing below v0.10.0 compiles on beta.20, and noir_rsa pins v0.10.0.

Circuits without wide arithmetic go the other way: t_add_integrity_commit lost 44% of its opcodes and t_attest shrank slightly. SHA256 and Poseidon2 cost exactly the same on both sides.

Prover time

hyperfine, release builds of both trees, same machine. Two independent sessions, each one warmup run plus three timed runs; the table pools all six:

circuit	beta.11	beta.20
t_attest	204.9 ms	198.7 ms
t_add_integrity_commit	420.4 ms	409.0 ms
t_add_id_data_720	613.4 ms	600.1 ms
t_add_dsc_720	1.152 s	1.139 s
complete_age_check	1.983 s	1.975 s

Flat, leaning 1-3% faster on beta.20 (complete_age_check is within noise). Two effects cancel: prover cost tracks the padded power-of-two sizes, which didn't move for any circuit, and witness generation got quicker because beta.20 makes fewer brillig calls. That speedup comes from sha256 v0.3.0 and the compiler, not bignum; the biggest drop is in a circuit with no bignum at all. On t_add_dsc_720, witgen goes from 113 ms to 88 ms with the commit phases unchanged. Proof sizes move under 1% and all proofs verify.

Notes for review

• The AND/XOR pipeline now asserts num_bits <= 32. The dsc circuit carries one 8-bit AND (on both toolchains); widths up to 32 are sound in the 4-byte decomposition, anything wider would truncate silently, so it panics instead.
• t_add_integrity_commit's dg1_padded_length is u32 now, following sha256 v0.3.0. The monolithic passport keeps u64 with a cast; happy to align them if you have a preference.
• The registry crates match upstream b4236c19 byte for byte apart from the vendored stdlib, and preparing the same circuit from the git pin and from the registry build gives identical .pkp/.pkv files.

Validation

Workspace tests, clippy and fmt are clean. The five shipped circuits prepare, prove and verify on beta.20, with the beta.11 runs above as the control. 56 of 58 example packages compile; the two failures predate this PR. cargo bench -p provekit-bench runs, prove_poseidon_1000 median 470 ms (a second run replicated within 1%).

---

AI Disclosure: The mechanical port and the measurement runs were done with Claude Code. I reviewed the diff, chose the library pin set and the binop-cap behavior, and checked the recomputed Barrett parameters against the moduli.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs-provekit-org	Error		Aug 20, 2026 5:07pm

[recmo]

Mostly straightforward syntactic changes. Only thing substantial is the AND and XOR behavior which now includes a num_bits.

[recmo]

operate on 32-bit values

Is this still true?

[BornPsych]

nope, updated the comment

[recmo]

Are we sure about this?

https://github.com/noir-lang/noir/blob/v1.0.0-beta.20/acvm-repo/acvm/src/compiler/optimizers/redundant_range.rs#L172

                // Barretenberg implementation of the AND and XOR blackbox constrain the inputs and output to be 'num_bit' bits

this flags the witness as range constraints, which allows further optimization to remove the RANGE opcodes.

[BornPsych]

Good catch, we can't rely on this RANGE opcode here.process_binop_opcode now adds range checks for witness operands when num_bits < 32.