A couple of weeks back, Axiom dropped an intriguing [open source ZK puzzle](https://hackmd.io/@axiom/rkIujYOt2) that had the ZK hobbyists and gigabrains buzzing.

What ensued was a quasi-competition on Twitter, kicked off by [@axiomintern](https://twitter.com/axiomintern), with enthusiasts sharing screenshots of their zkREPL solutions, each trying to prove that they have the most optimized solution ([sol1](https://twitter.com/0xa9a/status/1685460099567865856), [sol2](https://twitter.com/therunningmyle/status/1685665797304426496)).

But the problem with screenshots?

Simply put, it's easy to modify these screenshots, which could result in a bunch of unrelated or improperly constrained circuits pretending to be valid solutions.

And, Given that Axiom is planning to launch one such puzzle every month from now on (alpha leaked by Yi Sun at ETH CC Paris), it's clear we need a more robust system for ZK circuit engineers to showcase their skills.

## Problem statement

Allow ZK circuit engineers to:
- Prove they have a solution to an Axiom puzzle
- Keep their solution private
- Reveal non-linear constraints of their solution

## Potential solution

To ensure a solution's correctness and legitimacy, we'd need to:
- Create a test suite, ensuring all cases are covered.
- Verify that the circuit is not under-constrained.

And for every valid solution, we also reveal the number of non-linear constraints as public output.

All this logic could be programmed in a circuit with the following inputs:

#### Private inputs
- Circom solution (as text)

#### Public inputs
- Test suite
- Compiler version?

#### Public outputs
- Number of non-linear constraints

### Test suite

The main circuit calls the solution circuit against the test suite to verify it's correctness.

Ideally, the team that releases the open-source ZK puzzle (in this case, Axiom), could generate the test suite. Taking [puzzle 1](https://hackmd.io/@axiom/rkIujYOt2) as an example, the suite would encompass all possible scenarios: no tuples matching, all tuples matching, only the first or last tuple matching, and randomly generated arrays with matching values.

For now, for simplicity, we could hardhcode the test suite inside the main circuit per puzzle. But it could also be abstracted out as a public input.

### Detect underconstrained circuits

The challenge here is to ensure the circuit is not under-constrained, an undesirable outcome in the context of zk-SNARKs.

> [x] Not sure how would one go about doing this yet.

### Reveal number of constraints

One approach to consider could be "SNARKifying" the Circom compiler, enabling us to extract this information. Given that the Circom compiler is written in Rust, would RiscZero be a suitable tool for this task?

> [x] Not sure how would one go about doing this yet.

## End game

This idea could be extended to a full-fledged **ZK competitive programming system on-chain.**

Every month, Axiom releases a new puzzle, accompanied by a solution verifier smart contract on-chain. They also deposit the bounty in the smart contract, setting the stage for the month's competition. Participants submit their "**Proof of Solution**" to the on-chain contract, which verifies the proof and stores the corresponding constraints for each solution. At the end of a defined block, bounties are automatically released to the top solutions.

---

Author: [0xSachinK](https://twitter.com/0xSachinK)
*Edited by ChatGPT*