[Grant Application] Reusable Halo2 Verifier Security Testing Infrastructure (ZKCG Reference Implementation)

Grant Application: Reusable Halo2 Verifier Security Testing Infrastructure

I have submitted a full grant application on GitHub and am posting here as required for community review.

GitHub Issue: Grant Application - Reusable Halo2 Verifier Security Testing Infrastructure (ZKCG Reference Implementation) · Issue #392 · ZcashCommunityGrants/zcashcommunitygrants · GitHub


The Problem

Every new Halo2-based project in this ecosystem has to independently figure out how to systematically test its verifier. There is no shared library of “here is how you test a Halo2 verifier for malformed-proof rejection, replay protection, and cross-implementation equivalence.” Projects rediscover this methodology from scratch every time, which means security gaps in new Halo2 deployments go undiscovered longer than they should.

This is a gap that affects ZKCG directly, and the Zcash/Halo2 ecosystem broadly.


What This Grant Builds

ZKCG (Zero-Knowledge Compute Gateway) is an open-source Halo2-based ZK proof system for compliance enforcement decisions, using Halo2 over BN254 (k=6), roughly 76ms prove / 4ms verify. Published Rust crates: zkcg-verifier, zkcg-common, zkcg-halo2-prover v0.2.0 on crates.io. Apache-2.0. GitHub - MRSKYWAY/zkcg-public: ZK-Verified Computation Gateway - Trustless verification of off-chain computation using Rust + Zero Knowledge · GitHub

This grant funds two tiers of output using ZKCG as the reference implementation:

Tier 1 — ZKCG production security tests:

  • cargo-fuzz fuzzing harness with three targets: proof deserialization, field element parsing, pairing check inputs
  • 50+ malformed-proof rejection test cases covering truncated proofs, corrupted commitments, wrong curve points, out-of-range scalars
  • Replay and domain-separation tests confirming a valid proof for one context cannot be reused in another
  • Differential verification framework: 100 categorized inputs run through both Halo2 and RISC0 paths, outputs compared, zero divergence asserted
  • CI integration running the full suite on every pull request

Tier 2 — A reusable public good for the Halo2 ecosystem:

  • halo2-verifier-security-patterns/ — a standalone module containing extracted, documented, reusable test patterns any Halo2-based project can adopt without starting from scratch
  • THREAT_MODEL.md — verifier trust boundary, security assumptions, proof scope, out-of-scope items, responsible disclosure — structured as a template for other Halo2 projects

Why This Matters for Zcash

Zcash components use halo2_proofs. ZKCG uses halo2_proofs. The security testing methodology, fuzzing corpus, malformed-proof test vectors, and differential verification framework built here are directly applicable to any Halo2-based system in the ecosystem.

If the halo2-verifier-security-patterns/ module produces patterns relevant to Zcash’s own Halo2 tooling (PSE repository, Zebra’s proof verification paths), I will open a discussion with maintainers about contributing upstream. This is not a commitment — it is a realistic bonus outcome given the shared dependency.

A clean fuzzing campaign is itself a publishable result that increases confidence in Halo2 verifiers across the ecosystem. A finding would be responsibly disclosed. Either outcome is a win.

About Me

Solo founder. Built ZKCG from scratch including Halo2 circuit design in Rust, published verifier crates, and live proof flows running for Centrifuge, Maple Finance, Ondo Finance, and Securitize use cases.

GitHub: MRSKYWAY (Sujyot Kamble) · GitHub


Happy to answer technical questions. Feedback welcome.

Hi, since the halo2 verifier we use is the reference implementation. What makes you say this?

Thanks for replying that is a good question! If you know about the halo2_gadgets orchard vulnerablility disclosed this past June seems like a very concrete version of what i am trying to say!
It was an underconstrained scalar-multiplication check in reference implementation itself caught by targeted audit rather than any standing fuzzing suite…i think it was present for about 4 years or so. and yeah thats exactly the bug class tier 1 here builds fuzzing harness and malinformed proof test suite to catch systematically rather than relying on someone to eventually looking at the right gadget…but
apart from that this grant isnt about re-testing halo2 proofs’ own correctness…its more like its the layer every downstream project has to build once it deploys its own circuits and verification paths on top of it..like replay/domain separation at application layer, cross implementation equivalence when a projects runs its proof through multiple backends. That’s not covered by reference implementation’s test suite, because its specific to each project’s wiring, and everyone currently rebuilds it from scratch. like ZKCG(halo2+RISC0) is one such instance of that shape.

one more thing worth adding…i am not claiming that tier 2 produces a drop-in test suite that any halo2 project can adopt at scale..although that would lovely..but circuit specific correctness (like whether it actually enfoces the core rules) is inherently project specific and welp that cannot be captured in a shared suite.
But the shared layer is the security critical infrastructure underneath that..like for example, proof deserialization, field elemet parsing, parsing check inputs, malinformed proof rejections and the fuzzing infra around those parts. like those are the common entry points and curve types acroos halo2 projects which is whya resuable harness or a test template is useful. Helps a adopting project get started faster but doesnt eliminate the work of wiring in and testing their own circuits…does that make sense??

Thank you for submitting your proposal. After careful consideration by the ZCG and a period for community comments on the forum, the committee has decided not to advance this proposal.

We genuinely appreciate the work and dedication you put into your application and hope you’ll continue to participate and contribute to the Zcash community. Meeting minutes.