Production ZK Concerns

Building a ZK system is dangerous:

1. Sound Fiat-Shamir:

• Hash MUST include all public inputs + commitments.
• "Frozen Heart" attacks: Plonky2, Bulletproofs implementations missed inputs in 2022 → forgeable.
• Domain separation: prefix with protocol/version.

2. Trusted setup:

• If required (Groth16): run a multi-party ceremony.
• Toxic waste must be deleted. Hardware-airgapped destruction.
• Document the ceremony. Audit logs.

3. Side channels:

• Witness must be in a constant-time-friendly form.
• Memory layout matters. Use libraries that thought about this (libsnark, arkworks).

4. Circuit bugs:

• Underconstrained circuits: missing constraint → prover can lie about that aspect.
• Tornado Cash bug (early version) had withdrawn-fund tracking off by an under-constraint.
• Auditing tools: Picus, Circom-Pairing, formal verification of circuits.

5. Library choice:

• Mature: arkworks (Rust), libsnark, gnark, snarkjs (Circom + JS), halo2 (Rust, used by Zcash).
• Less mature: avoid for production.

6. Recursion:

• Modern systems compose proofs of proofs (zk-STARK + Halo recursion).
• Used to compress whole blockchain histories.
• Even more careful — bugs in inner proofs propagate.

7. Operational:

• Prover can be GPU-heavy. Plan capacity.
• Proof generation latency matters for UX. Sub-second for interactive apps; minutes acceptable for batched rollups.

8. Auditability:

• Public circuits (so anyone can audit constraints).
• Independent audits (Trail of Bits, Spectre, Veridise).

9. Upgrade paths:

• Cryptographic agility: support migrating between schemes (Groth16 → PLONK → STARK).
• Ceremony-based setups create tech debt.

Recommendation: don't roll your own. Use Aztec's Noir, StarkWare's Cairo, or Aleo's Leo if you want to ship a ZK product.

ZK is a 50-year-old idea finally going mainstream. Expect rapid evolution.