From noir
Workflow for measuring and optimizing the ACIR circuit size of a constrained Noir program. Use when asked to optimize a Noir program's gate count or circuit size.
npx claudepluginhub critesjosh/noir-claude-plugin --plugin noirThis skill is limited to using the following tools:
This workflow targets **ACIR circuit size** for constrained Noir programs. It does not apply to `unconstrained` (Brillig) functions — Brillig runs on a conventional VM where standard profiling and algorithmic improvements apply instead, and `bb gates` won't reflect Brillig performance.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
This workflow targets ACIR circuit size for constrained Noir programs. It does not apply to unconstrained (Brillig) functions — Brillig runs on a conventional VM where standard profiling and algorithmic improvements apply instead, and bb gates won't reflect Brillig performance.
Compile the program and measure gate count with:
nargo compile && bb gates -b ./target/<package>.json
Libraries cannot be compiled with nargo compile. Instead, mark the functions you want to measure with #[export] and use nargo export:
nargo export && bb gates -b ./export/<function_name>.json
Artifacts are written to the export/ directory and named after the exported function (not the package).
If bb is not available, ask the user for their backend's equivalent command. Other backends should have a similar CLI interface.
The output contains two fields:
circuit_size: the actual gate count after backend compilation. This determines proving time, which is generally the bottleneck.acir_opcodes: number of ACIR operations. This affects execution time (witness generation). A change can reduce opcodes without affecting circuit size or vice versa — both matter, but prioritize circuit_size when they conflict.Always record a baseline of both metrics before making changes.
circuit_size.circuit_size to the baseline.circuit_size increased or stayed the same, undo the change. Not every "optimization" helps — the compiler may already handle it, or the overhead of the new approach may outweigh the savings.Candidate optimizations roughly ordered by impact:
if c { assert_eq(x, a) } else { assert_eq(x, b) } with assert_eq(x, if c { a } else { b }).<, <=) cost more than equality (==). But don't introduce extra state to avoid them — measure first.if/else expressions compile to the same circuit as c * (a - b) + b.<= with flag tracking without measuring: adding mutable state across loop iterations can produce more gates than a simple comparison.