ZK proofs: from theory to practical engineering

ZK went from "interesting math" to "production infrastructure"

When we first started studying zero-knowledge proofs at kcolbchain, they were an academic curiosity. The math was beautiful but the practical applications were limited by proving time, circuit complexity, and a near-total absence of developer tooling.

By 2023, that's changed dramatically. ZK rollups (zkSync, StarkNet, Scroll, Polygon zkEVM) are processing real transactions. ZK proving is being used for identity, compliance, voting, and cross-chain bridges. The question is no longer "will ZK work?" but "where does it make sense and what are the engineering trade-offs?"

The proving system landscape

The choice of proving system determines everything downstream: performance characteristics, trusted setup requirements, proof size, verification cost. Here's our practical assessment:

• Groth16: Small proofs, fast verification, but requires a per-circuit trusted setup. Still the best choice when proof size and on-chain verification cost are the binding constraints. Used by Zcash, Tornado Cash, many production systems.
• PLONK/PLONKY2: Universal trusted setup (one ceremony covers all circuits). Larger proofs than Groth16 but much more flexible. The basis for many zkEVM implementations.
• STARKs: No trusted setup at all (transparent). Larger proofs but post-quantum secure and very fast proving. Used by StarkNet and StarkEx. Proof size is the main drawback.
• Halo2: Recursive proof composition without a trusted setup. Used by Zcash and Scroll. Elegant but complex to work with.

Our take: There is no "best" proving system. The choice depends on your specific constraints: proof size budget, verification gas cost, trusted setup tolerance, post-quantum requirements, and developer team capability.

The real engineering bottlenecks

Academic papers focus on proof generation time and proof size. In practice, the bottlenecks are different:

1. Circuit design is the hard part.

Writing ZK circuits is like writing assembly code for a very constrained machine. You're expressing computation as polynomial constraints, and every operation has a "constraint cost". Operations that are trivial in normal code (like comparison, branching, memory access) are expensive or impossible in circuits.

A skilled circuit engineer can make a 10x difference in proving performance for the same computation. This is where most of the engineering value lives.

2. Memory is the real constraint, not CPU.

Proving large circuits requires enormous amounts of RAM. A zkEVM proving a single block might need 64-256 GB of memory. This limits who can be a prover and creates centralisation pressure in prover networks.

3. Developer tooling is still immature.

Circom, Noir, Cairo, and other circuit languages are improving but are nowhere near the developer experience of Solidity. Debugging ZK circuits is painful — a failing constraint gives you a polynomial identity error, not a stack trace.

We believe developer tooling is the biggest bottleneck to ZK adoption. The teams building better compilers, debuggers, and testing frameworks for ZK circuits are doing the most important work in the space.

Where ZK actually matters

Not everything needs a zero-knowledge proof. ZK is powerful but expensive. It makes sense when:

• Scaling: ZK rollups batch thousands of transactions into a single proof. The verification cost is amortized across all transactions. This is the highest-value use case today.
• Privacy: Proving you meet a condition without revealing the underlying data. Know-your-customer compliance, voting, credential verification.
• Bridges: Proving the state of one chain to another without trusting a committee. ZK-verified bridges are the most secure cross-chain design possible.
• Verifiable computation: Proving that an off-chain computation was done correctly. This will be huge for AI x blockchain (verifiable inference, on-chain ML verification).

Where ZK doesn't make sense: anything where the data is already public and verification is cheap. Don't add ZK complexity to problems that don't need it.

ZKVMs: the next frontier

The most exciting development in ZK is the emergence of ZK virtual machines — systems that can prove the execution of arbitrary programs, not just purpose-built circuits.

RISC Zero, SP1, and other ZKVMs are approaching the point where you can write normal code (in Rust, for example), and automatically generate a ZK proof of its execution. This would make ZK accessible to any developer, not just circuit specialists.

We're actively researching ZKVMs and will be publishing benchmarks and engineering notes as the space matures.

Our open-source contributions

We're open-sourcing our ZK engineering notes — circuit patterns, performance benchmarks, and reference implementations for common proof patterns. We believe the ecosystem needs more practical engineering documentation, not more whitepapers.