Zero-Knowledge Proof Systems for Developers

You are a ZK cryptographer and developer who has built zero-knowledge applications on multiple proving systems. You can explain complex ZK concepts in terms that application developers can understand and act on.

CONTEXT: Zero-knowledge proofs are transforming blockchain infrastructure — they power ZK rollups (scalability), private transactions (privacy), and verifiable computation (trust minimization). As a blockchain developer, I need to understand ZK well enough to choose the right tools for my applications and potentially build ZK-enabled features. I have strong programming skills but limited cryptography background.

TASK: Create a ZK proof systems developer guide:
1. ZK fundamentals for developers: explain what zero-knowledge proofs are without deep math — the prover/verifier model, the properties (completeness, soundness, zero-knowledge), the difference between ZK-SNARKs and ZK-STARKs (trusted setup, proof size, verification cost, quantum resistance), and interactive vs. non-interactive proofs. Use analogies and practical examples.
2. Proving system landscape: compare the major proving systems — Groth16 (small proofs, trusted setup), PLONK (universal setup, flexible), Halo2 (no trusted setup, used by Scroll and Zcash), STARKs (no trusted setup, post-quantum, used by Starknet), and Boojum (used by zkSync). For each: proof generation time, proof size, verification gas cost on Ethereum, and maturity level.
3. ZK development frameworks: compare developer-accessible ZK tools — Circom + SnarkJS (most established, JS-based), Noir (Rust-like DSL by Aztec), Cairo (Starknet's language), Halo2 (Rust, used by Scroll), and ZoKrates (Ethereum-focused). For each: learning curve, documentation quality, ecosystem, and best use case.
4. Practical ZK application patterns: explain 5 patterns developers can implement — (a) ZK identity verification (prove you are over 18 without revealing your age), (b) Private voting (prove you are eligible and your vote is valid without revealing who you voted for), (c) Verifiable computation (prove you ran a computation correctly off-chain), (d) Private transactions (prove a transfer is valid without revealing amount/parties), (e) ZK bridging (prove state from one chain on another). For each, provide the high-level circuit design.
5. Getting started tutorial path: design a learning path — Week 1 (theory and concepts), Week 2 (Circom basics — build a simple circuit proving knowledge of a hash preimage), Week 3 (build a more complex circuit — Merkle proof verification), Week 4 (integrate with Solidity verifier contract), and recommended resources for each stage.
6. ZK in production considerations: proof generation infrastructure requirements (GPU acceleration, distributed proving), on-chain verification costs and optimization, trusted setup ceremony management (if using SNARKs), and current limitations (proving time, circuit size limits, auditing difficulty).