Why Noir + UltraHonk: how Sanect chose its proving system

The Trusted Setup Problem

Every ZK proof system requires some form of public parameters — a common reference string (CRS) that both the prover and verifier use. In many systems, generating those parameters requires a multi-party computation ceremony. The output of that ceremony is cryptographically bound to secret randomness that must be permanently destroyed. If any single participant retains their secret contribution, they can forge proofs undetected.

This destroyed randomness is often called the toxic waste. The ceremonies that produce it — like Zcash's Powers of Tau — involve hundreds of participants across months of coordination. The guarantee is probabilistic: the setup is secure if at least one participant was honest. That's a meaningful guarantee in practice, but it's still an assumption baked into the base layer of your privacy system forever.

For infrastructure designed to outlast its builders, a permanent cryptographic assumption tied to a one-time human ceremony is a liability. It cannot be patched. It cannot be re-run without migrating all shielded state. It is the kind of risk that compounds over decades.

How the Major Proof Systems Compare

Groth16

Groth16 produces the smallest proofs (around 192 bytes) and the fastest verification times of any general-purpose SNARK. This is why it is used in Zcash's Sapling upgrade and remains common in rollup designs. The cost: Groth16 requires a circuit-specific trusted setup. Every time you change your circuit — add a feature, fix a bug, extend a constraint — you must run a new ceremony and coordinate a new set of participants. The toxic waste problem recurs with every protocol upgrade.

Halo2

Halo2, developed by the Electric Coin Company, eliminates trusted setup entirely using inner product arguments over the Pasta curve cycle. This is a meaningful advance. However, the ecosystem around Halo2 is smaller than Barretenberg's, the tooling is less mature for EVM verification, and the Pasta curves are not BN254-compatible — which means generating an efficient Solidity verifier requires additional engineering. Halo2 is sound cryptography with a narrower developer ecosystem.

PLONK / UltraHonk (Barretenberg)

PLONK introduced universal trusted setups — a single ceremony that works for any circuit up to a maximum size. Barretenberg, maintained by Aztec, takes this further with UltraHonk: a PLONK variant that uses a universal structured reference string (SRS) that has already been generated and audited. The SRS is public, reusable, and does not need to be regenerated when circuits change. There is no per-circuit ceremony, no toxic waste per upgrade, and the parameters are fully transparent.

With Barretenberg's universal SRS, there is no moment in Sanect's history where a circuit upgrade requires re-running a trusted setup ceremony. The security model is cryptographic from the start, and it stays that way through every protocol upgrade.

Why We Chose Noir as the Circuit Language

Noir is a domain-specific language for writing ZK circuits, developed and maintained by Aztec. It compiles to an intermediate representation that Barretenberg's UltraHonk backend proves. The combination gives us several practical properties that matter for a production privacy system:

• Readable circuit code: Noir's syntax is Rust-like and high-level. Our 2-in/2-out spend circuit is ~200 lines of readable constraint logic, not thousands of lines of raw polynomial definitions. This makes auditing tractable.
• Automatic Solidity verifier generation: Barretenberg's bb write_solidity_verifier command produces an EVM-compatible verifier contract directly from the circuit. No hand-written Solidity, no translation layer. The generated verifier fits within EIP-170's 24,576-byte contract size limit.
• Browser proving via WASM: Noir's prover compiles to WebAssembly. Proof generation runs entirely in the user's browser in approximately 2-3 seconds on modern hardware. No server-side proving, no trusted third party seeing the witness.
• Active maintenance: Aztec is one of the most well-funded teams in the ZK space. Barretenberg and Noir receive continuous development, security patches, and performance improvements. This is not an abandoned academic project.

The Circuit: 2-in/2-out, Multi-Asset

Sanect's shielded pool uses a single circuit design: two input notes consumed, two output notes produced. The circuit proves eight properties simultaneously, all in zero knowledge:

• The prover owns the input notes (knows the spending key)
• Each input note exists in the Merkle tree (inclusion proof)
• The nullifiers are correctly derived (prevents double-spend)
• All notes share the same asset type (no cross-asset confusion)
• Output commitments are well-formed (Poseidon-2 hash)
• Value is conserved: sum of inputs + public amount equals sum of outputs

The same circuit handles shield (public to pool), internal send (pool to pool), and unshield (pool to public) — the publicAmount parameter determines which operation is being performed. Multi-asset support is built in via an asset_id field in each note commitment.

Why This Matters for a Long-Lived Chain

Sanect is designed to run for decades. Over that time period, circuits will be upgraded — new features, bug fixes, performance improvements. With Groth16, every upgrade requires a new multi-party ceremony. With Barretenberg's universal SRS, every upgrade is a recompilation and a new verifier deploy. The SRS does not change. The ceremony is not repeated.

When we evaluated proof systems for the shielded pool, the combination of no per-circuit ceremony, mature EVM tooling, browser-native proving, and active long-term maintenance was not a nice-to-have. For infrastructure at this layer, it was a hard requirement.