Challenges We Faced During the Journey

Building a privacy-preserving payment system using Zero-Knowledge Proofs was far from straightforward. The journey involved deep technical challenges, design trade-offs, and tight constraints — each of which shaped the final solution.

Understanding Zero-Knowledge at a Practical Level

Zero-knowledge proofs are often explained conceptually, but implementing them in practice is a different challenge entirely.

• Understanding how circuits, witnesses, public signals, and verifiers interact took time
• Small misunderstandings (e.g. public vs private signals) caused proofs to silently fail
• Debugging ZK circuits provides very little feedback when something goes wrong

Lesson learned: ZK is unforgiving — correctness must be exact.

Circuit Design Trade-offs

Designing the circuit required careful decisions:

• Should the hash be an input or computed inside the circuit?
• How many public signals are safe and necessary?
• How do we keep verification simple while preserving privacy?

Every design choice affected:

• gas cost
• verifier complexity
• usability

Lesson learned: Minimal circuits are safer, cheaper, and easier to reason about.

Tooling & Ecosystem Friction

The ZK ecosystem is powerful but still maturing:

• Tooling errors were often cryptic or undocumented
• Small version mismatches between circom and snarkjs caused failures
• Some expected CLI commands simply did not exist, requiring workarounds

Lesson learned: Always rely on the circuit itself as the source of truth.

On-chain vs Off-chain Coordination

A major challenge was deciding what belongs on-chain and what must stay off-chain:

• Secrets must never touch the blockchain
• Hashes must be deterministic and verifiable
• Proof generation happens off-chain but must align perfectly with on-chain logic

Any mismatch broke the entire flow.

Lesson learned: Clear separation of responsibilities is essential in ZK systems.

Gas & Verifier Constraints

On-chain verification is expensive:

• Pairing-based verification consumes significant gas
• Public inputs directly impact verification cost
• Verifier contracts are rigid — one mismatch means failure

Lesson learned: Optimize public inputs early, not later.

Testing & Debugging Difficulties

Testing ZK systems is unlike traditional apps:

• A single incorrect constraint invalidates everything
• Failures often appear as a simple

  false

• Debugging requires inspecting witnesses, constraints, and generated proofs

Lesson learned: Build incrementally and test at every stage.

Conceptual vs Real Privacy

Designing for actual privacy, not just perceived privacy, was a constant challenge:

• Preventing front-running
• Avoiding on-chain data leaks
• Ensuring secrets cannot be inferred indirectly

Lesson learned: Privacy must be considered holistically, not feature-by-feature.

Final Reflection

Despite the challenges, this journey highlighted the power and necessity of zero-knowledge systems.
Each obstacle reinforced a core idea:

Privacy is hard — but worth building correctly.

This project represents not just a working prototype, but a deeper understanding of how cryptography can replace trust in modern systems.