noir circuit profiler: experimental analysis framework

[symulacr]

So what?

i am building the noir circuit profiler, an experimental library and command-line tool that performs some static and dynamic analysis of noir circuits at the acir level to predict constraint costs and identify optimization opportunities. by decomposing acir opcodes into their constituent msm (multi-scalar multiplication) and ntt (number theoretic transform) operations to provide developers with detailed insights into the computational bottlenecks of their circuits.

the constraint explosion problem

all my technical claims are backed up by research citations, just presented as findings.

my research reveals a need between high-level noir code and low-level constraint generation. a simple noir function with low acir opcodes can generate high backend gates, yet developers have no insight into this amplification factor.

i discovered that the problem is compounded by backend-specific variations: keccak256 operations have completely different implementations across backends and what's optimal for turboplonk may be inefficient for halo2. actually, without zoom out into these differences, we write suboptimal circuits unknowingly.

computational bottlenecks in zk proving

my analysis of existing research reveals the performance constraints:

• msm operations account for approximately more than half of proof generation time in typical snark systems
• ntt computations consume approximately less than half of proving time, with the remainder dominated by other operations
• msms are really parallel but memory-intensive, while ntts require frequent data shuffling that complicates acceleration on some memory archi

acir to constraint mapping

found that acir employs a directed acyclic graph (dag) model where gates represent basic operations connected by wires that direct data flow. the transformation from acir to backend constraints involves:

• circuit transformation that remaps operations to alternate versions
• expression decomposition when acir expressions contain too many terms
• plonkish arithmetization using selector polynomials to define customizable gates

methodology

experimental analysis framework

i am designing this profiler as an tool to explore the relationship between noir code patterns, acir structures, and backend constraint generation. my analysis proceeds through four distinct stages:

stage 1: acir decomposition and msm/ntt analysis

first parse the acir output from nargo compile and decompose each opcode into its fundamental operations:

acir opcode analysis flow:
1. parse acir json structure
2. identify opcode types (arithmetic, black box, memory, brillig)
3. decompose into msm and ntt operations
4. calculate theoretical hard bounds

for arithmetic operations, research shows:

• linear combinations map to field additions (negligible cost)
• multiplications generate msm operations in the proving backend
• plonk uses constraint polynomials of the form

for black box functions, i've identified:

• sha256: generates thousands of constraints, dominated by boolean operations
• keccak256: generates tens of thousands of constraints, heavy ntt usage for state permutations
• ecdsa verification: generates thousands of constraints, primarily msm operations on curve points

stage 2: constraint system modeling

model how different proving backends transform acir into constraints:

ultraplonk (barretenberg) transformation:

plonkish circuits are defined in terms of a rectangular matrix of values with polynomial constraints that must evaluate to zero for each row.

my transformation process:

1. map acir arithmetic gates to width-4 plonkish gates
2. expand black box functions into their gate representations
3. apply custom gate optimizations for common patterns
4. estimate memory requirements based on witness count

stage 3: performance bottleneck identification

analyze the circuit structure to identify performance bottlenecks:

msm hotspot detection:

msm operations are characterized by predictable memory access patterns allowing high parallelization but demanding significant memory resources.

analysis focuses on scalar multiplication density in the circuit and witness variable reuse patterns

ntt conceptual analysis:

ntt relies monstly on frequent data shuffling, which complicates acceleration by distributing load across computing clusters.

here, i track polynomial degree requirements and fft butterfly operation counts

my experimental framework includes pattern detection for common inefficiencies:

unconstrained computation opportunities:

operations that are easy to verify but hard to compute should be moved to unconstrained functions.

patterns i detect:

• expensive bit manipulations in constrained context
• iterative computations where only the result needs constraints with some arithmetic that can be verified with simple checks

memory access optimization:

dynamic array access converts rom to ram, increasing costs significantly.

iidentify:

• dynamic indices that could be made static
• exploratory way for witness value caching on repeated memory

technical implementation

backend cost models

i am implementing cost models for different proving backends based on empirical measurements:

barretenberg (ultraplonk) cost model:

• width-4 nor 8 arithmetic gates: unity constraint per gate
• custom gates for common operations: variable constraints
• lookup tables for small computations: minimal constraints

usage as library/cli tool

i am designing the profiler for manual analysis workflows:

command-line usage:

noir-profiler analyze <circuit.json>
  --backend barretenberg|halo2|gnark
  --output-format json|markdown|csv

noir-profiler compare <circuit1.json> <circuit2.json>
  --metric gates|msm-ops|ntt-ops|memory
  
noir-profiler patterns <circuit.json>
  --pattern unconstrained-opportunities|memory-optimization

library integration:

import from dependency:
- parse_acir(json_path) -> ACIR
- analyze(acir, backend) -> Report
- detect_patterns(acir) -> Vec<OptimalHint>

deliverables

1. noir-profiler cli tool: standalone binary for circuit analysis
2. profiler library: rust crate for integration into other tools
3. cost model documentation: detailed explanation of constraint cost calculations
4. optimization pattern catalog: documented inefficiency patterns found in real circuits
5. technical report: analysis methodology and validation results

development stages and timeline

starting july 7, 2025, the development of the noir circuit profiler will unfold over 22 weeks, with a structured timeline and key deliverables integrated into the process. in weeks 1-3, i’ll dive into deep research on the acir specification, barretenberg’s constraint generation internals, and msm and ntt algorithm implementations. this phase will also produce the architecture design and cost model framework, setting the stage for the tool’s development.

parsing acir output: in weeks 4-6, i’ll implement the acir parser, handling json deserialization, building opcode dependency graphs, and creating a canonical representation for consistent analysis. this deliverable ensures the tool can process noir’s intermediate representation accurately.

modeling backend constraints: during weeks 7-9, i’ll develop the cost model, focusing on barretenberg. this involves counting msm operations, analyzing ntt costs, and estimating memory needs—key deliverables that quantify circuit performance across backends.

bottleneck detection: in weeks 13-15, the profiler will gain bottleneck analysis capabilities, detecting msm hotspots, analyzing ntt-intensive sections, and tracking witness variable flow. this stage delivers algorithms to highlight performance issues.

optimization suggestions: in weeks 10-12, i’ll build the pattern detection engine, identifying unconstrained computation opportunities, memory access inefficiencies, and optimization potential in bit operations or black-box functions. this deliverable provides actionable insights for developers.

tool design and deliverables

the noir circuit profiler will function as both a command-line interface (cli) and a library. the cli, developed in weeks 16-17, allows commands like noir-profiler analyze <circuit.json> --backend barretenberg --output-format json to generate detailed reports or compare circuits. the library, packaged in weeks 18-19, offers functions like parse_acir and analyze_costs for integration into other noir tools. these deliverables enhance usability and flexibility.

key deliverables include:
noir-profiler cli tool: for standalone circuit
analysis.profiler library: a rust crate for integration into workflows
cost model documentation: detailing backend-specific analysis
optimization pattern catalog: derived from real noir circuits

this’ll be in the spirit of minimal implementation and low on complexity for a notch above basic utility

team

i am a solo researcher with background in compiler optimization and performance analysis. this experimental tool emerged from my frustration with manual circuit optimization work on client projects. here is my email : [email protected]

[symulacr]

noir language is beautiful through simplicity, not complexity

i previously thought complexity was noir magic, but noir is good because of its simplicity

here is something showing how the noir circuit profiler analyzes circuit.json files.

https://github.com/symulacr/noir-profiler

next one will be more precise and collect data for understanding circuits in two (02) ways:

¤ what makes a "good" circuit noir for general context

¤ what makes a noir circuit "good" for best practices

[symulacr]

¤ what makes a "good" circuit noir for general context

everything starts with minimal constraint count. this is non-negotiable since it's defined by:

▪︎ efficient use of underlying primitives
▪︎ good choice of data types and structures
▪︎ effective use of unconstrained computation
▪︎ minimized non-determinism & witness size
▪︎ under-constraint avoidance for correctness

[symulacr]

¤ what makes a noir circuit "good" for best practices

= using the right arithmetic
= good use of unconstrained functions
= minimizing loops and conditional logic inside constraints
= strong preference for static data access
= avoid type conversions as much as possible