crypto-zkp

What I do

• •Guide proof system selection with a multi-dimensional decision framework
• •Document circuit engineering discipline (R1CS, PLONKish arithmetization)
• •Enforce adversarial constraint testing through the constraint fuzzer directive
• •Cover formal verification tools and the ZKP tooling ecosystem

When to use me

Use this skill when designing ZK circuits, selecting proof systems, or implementing ZKP-based protocols. Pair with crypto-core for shared foundations, security invariants, and code review checklists.

Proof System Decision Framework

Decision Tree

Need post-quantum security?
  YES --> zk-STARKs (hash-based, no pairings)
  NO  |
      v
Need minimal proof size? (on-chain verification)
  YES --> Groth16 (~200 bytes, trusted setup per circuit)
  NO  |
      v
Need universal/updatable setup?
  YES --> PLONK variants (KZG setup, reusable across circuits)
  NO  |
      v
Need no trusted setup at all?
  YES --> Bulletproofs (no setup, O(n) verification)
          or STARKs (no setup, large proofs, fast verification)
  NO  |
      v
Need recursive proof composition?
  YES --> Nova/SuperNova (folding schemes)
          Halo2 (IPA-based recursion)
          Plonky2/3 (STARK-inside-SNARK)
  NO  |
      v
Need general computation (not custom circuits)?
  YES --> zkVM: SP1, RISC Zero, Jolt, Valida
  NO  --> Custom circuit: circom, halo2, noir

Comparison Matrix

Circuit Engineering

Arithmetization

The Critical Distinction

In circom, <-- is witness assignment (prover-side computation, not enforced by the verifier). === is a constraint (enforced by the verifier). A circuit with assignments but no constraints accepts ANY witness.

Always verify: constraint count matches expected count. Use the --inspect flag to audit constraints.

Optimization Patterns

• •Lookup tables for range checks and non-arithmetic operations
• •Custom gates for repeated sub-circuits (PLONKish only)
• •Batch inversions -- one inversion + n multiplications instead of n inversions
• •Algebraic tricks -- x^3 costs 1 constraint (xx=x2, x2x=x3), not 2
• •Constant propagation -- replace known-at-compile-time values to eliminate constraints

Constraint Fuzzer Directive

Before any circuit is considered tested, generate and verify rejection of these adversarial witnesses. Do not skip this step.

1. •All-zeros -- set every private input to 0
2. •All-max -- set every private input to (field_prime - 1)
3. •Perturbed valid -- take a valid witness, randomly change one value
4. •Swapped inputs -- swap two private input values
5. •Replayed witness -- use a valid witness from a different public input

All five must be REJECTED by the constraint system. If any passes, the circuit is under-constrained.

Under-constrained circuits compile, generate proofs with valid witnesses, and appear to work correctly. They silently break security. This is the most dangerous class of ZK bug.

Workflow: Designing a ZK Circuit

1. •Specify -- Define the statement: "I know w such that f(x, w) = true" where x is public. List all security properties needed.
2. •Arithmetize -- Decompose the computation into field operations (+, *, =). Choose R1CS or PLONKish. Estimate constraint count.
3. •Implement -- Choose tooling: circom for simple circuits, halo2 for complex circuits with custom gates, noir for portability. Separate witness generation from constraint logic.
4. •Test -- Valid witness passes. Run constraint fuzzer directive. Test edge cases: zero values, max field elements, boundary conditions.
5. •Optimize -- Profile constraint count per operation. Apply lookup tables, custom gates, batch inversions. Re-test after every change.
6. •Audit -- Run crypto-core code review checklist. Check for under-constrained values. Run formal verification tools.
7. •Deploy -- Generate or use trusted setup (if applicable). Deploy verifier contract (if on-chain). Monitor proof generation times.

Formal Verification

Use formal verification when: (1) the circuit handles financial value, (2) constraint count exceeds 10,000, or (3) the circuit will be deployed without further audit. Formal verification does not replace adversarial testing -- it complements it.

Tooling Ecosystem

Anti-Patterns