Groth16 Systems
Core principle
Make the exact relation explicit, then trace the same claim through witness generation, constraints, compiled artifacts, and verification. A successful proof establishes only the constrained relation, not the developer's unstated intent.
Scope
Use this skill to:
- design the relation, public inputs, private witness, and boundary cases before writing a circuit;
- explain or derive the R1CS → QAP → Groth16 chain;
- debug failed proofs, unexpected witnesses, or public-signal mismatches;
- review circuit constraints, generated R1CS, verifier integration, and CRS assumptions;
- bind verified public inputs to application policy, domain, freshness, and state transitions.
Do not apply its R1CS/QAP model directly to PLONKish arithmetizations, Halo2, AIR, or STARK systems. Use their native model unless the request is explicitly comparative.
Route the request
| Request |
Read |
| Design, debug, or review a relation/circuit |
review-checklist.md |
| Recall fields, polynomials, groups, or pairings |
algebra-foundations.md |
| Explain or derive relation → R1CS → QAP |
relation-r1cs-qap.md |
| Reason about circuit compilation or witness generation |
circuit-compilers.md |
| Explain Groth16 setup, proving, verification, or zero knowledge |
groth16-protocol.md |
| Bind public inputs to application semantics, domain, or replay state |
application-binding.md |
| Inspect Circom/snarkjs artifacts or commands |
tooling.md plus the review checklist |
Read only the references needed for the request.
Working method
- State the scalar field and relation
R(public, witness).
- List public values in verifier order; list private and intermediate witness values separately.
- Define valid boundaries and at least one invalid assignment.
- Map every intended predicate to an actual constraint.
- Treat witness generation and constraint generation as separate programs.
- When artifacts exist, compare source, R1CS, symbols, witness, public signals, keys, and verifier behavior.
- Give every artifact set and flattened public-input layout one reproducible identity.
- Separate cryptographic verification from application authorization, replay protection, and state transition.
- Follow the QAP and pairing layers only as far as the question requires.
- Create examples independently, label pedagogical parameters, and verify version-sensitive claims against current official documentation.
Output contract
For design work, return the relation, ordered interface, required constraints, application bindings, edge cases, and a minimal verification plan.
For explanations, keep one notation from relation through verification. If an example helps, derive a fresh one and show at least one valid or invalid substitution.
For debugging or review, lead with the verdict. Support each finding with the intended property, actual constraint or artifact behavior, a concrete counterexample when possible, impact, and the smallest verifiable correction.
1---2name: groth16-systems3description: Use when designing, explaining, debugging, testing, or reviewing Groth16 circuits and integrations, especially for R1CS/QAP derivations, underconstrained witnesses, setup provenance, artifact mismatches, public-input semantics, verifier boundaries, or replay/domain binding.4---56# Groth16 Systems78## Core principle910Make the exact relation explicit, then trace the same claim through witness generation, constraints, compiled artifacts, and verification. A successful proof establishes only the constrained relation, not the developer's unstated intent.1112## Scope1314Use this skill to:1516- design the relation, public inputs, private witness, and boundary cases before writing a circuit;17- explain or derive the R1CS → QAP → Groth16 chain;18- debug failed proofs, unexpected witnesses, or public-signal mismatches;19- review circuit constraints, generated R1CS, verifier integration, and CRS assumptions;20- bind verified public inputs to application policy, domain, freshness, and state transitions.2122Do not apply its R1CS/QAP model directly to PLONKish arithmetizations, Halo2, AIR, or STARK systems. Use their native model unless the request is explicitly comparative.2324## Route the request2526| Request | Read |27|---|---|28| Design, debug, or review a relation/circuit | [review-checklist.md](references/review-checklist.md) |29| Recall fields, polynomials, groups, or pairings | [algebra-foundations.md](references/algebra-foundations.md) |30| Explain or derive relation → R1CS → QAP | [relation-r1cs-qap.md](references/relation-r1cs-qap.md) |31| Reason about circuit compilation or witness generation | [circuit-compilers.md](references/circuit-compilers.md) |32| Explain Groth16 setup, proving, verification, or zero knowledge | [groth16-protocol.md](references/groth16-protocol.md) |33| Bind public inputs to application semantics, domain, or replay state | [application-binding.md](references/application-binding.md) |34| Inspect Circom/snarkjs artifacts or commands | [tooling.md](references/tooling.md) plus the review checklist |3536Read only the references needed for the request.3738## Working method39401. State the scalar field and relation `R(public, witness)`.412. List public values in verifier order; list private and intermediate witness values separately.423. Define valid boundaries and at least one invalid assignment.434. Map every intended predicate to an actual constraint.445. Treat witness generation and constraint generation as separate programs.456. When artifacts exist, compare source, R1CS, symbols, witness, public signals, keys, and verifier behavior.467. Give every artifact set and flattened public-input layout one reproducible identity.478. Separate cryptographic verification from application authorization, replay protection, and state transition.489. Follow the QAP and pairing layers only as far as the question requires.4910. Create examples independently, label pedagogical parameters, and verify version-sensitive claims against current official documentation.5051## Output contract5253For design work, return the relation, ordered interface, required constraints, application bindings, edge cases, and a minimal verification plan.5455For explanations, keep one notation from relation through verification. If an example helps, derive a fresh one and show at least one valid or invalid substitution.5657For debugging or review, lead with the verdict. Support each finding with the intended property, actual constraint or artifact behavior, a concrete counterexample when possible, impact, and the smallest verifiable correction.
mysteryon88