feat(Groth16): add working examples of Groth16 verification#1964
feat(Groth16): add working examples of Groth16 verification#1964delovoyhomie wants to merge 4 commits intomainfrom
Conversation
|
|
||
| | Example | Stack | Circuit | What the proof exposes publicly | Tact test | | ||
| | ------------- | -------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------- | --------------------------------------------- | | ||
| | `Multiplier` | Circom | [`circuits/Multiplier`](https://github.com/zk-examples/zk-ton-examples/tree/main/circuits/Multiplier) | `c = a * b` | `npx blueprint test Verifier_multiplier_tact` | |
There was a problem hiding this comment.
tact
Here and below, let's only use and reference Tolk examples.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Thanks for expanding the ZK docs; I’ve left several suggestions in contract-dev/privacy-zk/groth16-examples.mdx plus a couple of small navigation and cross-link tweaks—please apply the inline suggestions to align with the content and safety guidelines.
| Select `Multiplier` for the smallest end-to-end Groth16 verifier flow in the repository. | ||
| The proof is generated at test time from `Multiplier.wasm` and `Multiplier_final.zkey`. |
There was a problem hiding this comment.
[HIGH] Subjective “smallest” marketing-style claim for Multiplier
Line 50 describes the Multiplier example as “the smallest end-to-end Groth16 verifier flow in the repository,” which is a comparative, marketing-style claim without concrete metrics. The style guide prohibits subjective intensity language like “smallest” when not backed by measurable criteria such as constraints, gas, or code size. As written, this description may become inaccurate if other examples change or new ones are added, and it does not help readers understand what is actually different about the example.
| Select `Multiplier` for the smallest end-to-end Groth16 verifier flow in the repository. | |
| The proof is generated at test time from `Multiplier.wasm` and `Multiplier_final.zkey`. | |
| Select `Multiplier` for a minimal end-to-end Groth16 verifier flow with two private inputs and one public output. | |
| The proof is generated at test time from `Multiplier.wasm` and `Multiplier_final.zkey`. |
Please leave a reaction 👍/👎 to this suggestion to improve future reviews for everyone!
| ```bash | ||
| cd circuits/Multiplier | ||
| circom Multiplier.circom --r1cs --wasm --sym --prime bls12381 | ||
| snarkjs powersoftau new bls12-381 10 pot10_0000.ptau -v | ||
| snarkjs powersoftau contribute pot10_0000.ptau pot10_0001.ptau --name="First contribution" -v -e="some random text" | ||
| snarkjs powersoftau prepare phase2 pot10_0001.ptau pot10_final.ptau -v | ||
| snarkjs groth16 setup Multiplier.r1cs pot10_final.ptau Multiplier_0000.zkey | ||
| snarkjs zkey contribute Multiplier_0000.zkey Multiplier_final.zkey --name="1st Contributor" -v -e="some random text" | ||
| snarkjs zkey export verificationkey Multiplier_final.zkey verification_key.json | ||
| cd ../.. | ||
| npx export-ton-verifier ./circuits/Multiplier/Multiplier_final.zkey ./contracts/verifier_multiplier.tolk --tolk | ||
| npx export-ton-verifier import-wrapper ./wrappers/Verifier.ts --force --groth16 | ||
| npx blueprint test Verifier_multiplier_tolk |
There was a problem hiding this comment.
[HIGH] Missing safety label on trusted-setup example randomness
Lines 53–65 show a full Groth16 trusted-setup sequence for Multiplier, including snarkjs powersoftau and zkey contribute commands that hard-code "some random text" as entropy. The block appears as a ready-to-run bash snippet without any “Not runnable” or safety note, despite the randomness being intentionally weak and unsuitable for real setups. The style guide requires that partial or context-dependent snippets be labeled as not runnable and that examples involving secrets or entropy call out the need for high-entropy values, so readers do not reuse insecure patterns in production.
Please leave a reaction 👍/👎 to this suggestion to improve future reviews for everyone!
| Select `Sudoku` for a larger verification key and many public inputs. | ||
| The current `Sudoku` source checks rows, columns, and diagonals. It does not check 3x3 boxes (subgrids). | ||
|
|
There was a problem hiding this comment.
[HIGH] Time-relative “current” in Sudoku description
Line 79 refers to “The current Sudoku source” when describing what the circuit checks. The style guide discourages time-relative qualifiers like “current”, “new”, or “soon” because they stale quickly and become misleading as upstream code evolves. In this case, the behavior being documented (rows, columns, diagonals; not 3×3 boxes) can be stated directly without implying a temporal state that may later change.
Please leave a reaction 👍/👎 to this suggestion to improve future reviews for everyone!
| <Aside type="tip"> | ||
| This page follows the upstream Tolk verifier tests and runs locally in the Blueprint sandbox, not on TON mainnet. | ||
| </Aside> |
There was a problem hiding this comment.
[HIGH] Environment warning uses tip instead of safety callout
Lines 44–46 use <Aside type="tip"> to state that the page runs locally in the Blueprint sandbox and not on TON mainnet. Given that later examples include a sendVerify call with a non-trivial TON amount, environment separation between sandbox, testnet, and mainnet is a safety concern rather than a mere tip. The style guide calls for using caution or danger callouts whenever there is potential funds movement or chain impact, and requires explicitly naming testnet and mainnet to prevent confusion.
| <Aside type="tip"> | |
| This page follows the upstream Tolk verifier tests and runs locally in the Blueprint sandbox, not on TON mainnet. | |
| </Aside> | |
| <Aside type="caution" title="Run in sandbox or testnet"> | |
| These examples follow the upstream Tolk verifier tests and run in the Blueprint sandbox by default. When adapting them to TON Testnet or TON Mainnet, start on TON Testnet with small amounts; transfers on mainnet are irreversible. | |
| </Aside> |
Please leave a reaction 👍/👎 to this suggestion to improve future reviews for everyone!
| Run-time verification succeeds when all of the following are true: | ||
|
|
||
| - `snarkjs.groth16.verify(...)` returns `true` | ||
| - The contract `getVerify` method returns `true` | ||
| - `npx blueprint test ...` exits with code `0` |
There was a problem hiding this comment.
[HIGH] Missing canonical reference link for snarkjs.groth16.verify
Line 159 lists snarkjs.groth16.verify(...) as a bullet without linking to any canonical reference or upstream documentation. The style rules specify that the first meaningful mention of an important API or constant should link to its official docs or internal reference anchor to support quick lookups and avoid duplicating behavior explanations across pages. Without such a link, readers must search manually for the function’s semantics and options.
Please leave a reaction 👍/👎 to this suggestion to improve future reviews for everyone!
| <Aside> | ||
| This guide is also applicable to circuits written in the [Noname](https://github.com/zksecurity/noname) language, since the [`export-ton-verifier`](https://github.com/mysteryon88/export-ton-verifier) library integrates with `snarkjs`, which in turn integrates with the Noname language. | ||
|
|
||
| Other examples can be found [here](https://github.com/zk-examples/zk-ton-examples/). | ||
| For repo-backed examples covering Circom, Noname, Gnark, and Arkworks, see [Groth16 verification examples](/contract-dev/privacy-zk/groth16-examples). | ||
| The upstream source repository is [`zk-examples/zk-ton-examples`](https://github.com/zk-examples/zk-ton-examples/). | ||
| </Aside> |
There was a problem hiding this comment.
[HIGH] Stub sentence around external examples repository
Lines 13–14 mention “For repo-backed examples…” and then add “The upstream source repository is …” as a trailing sentence whose only job is to label the repository. The revised text removes the banned “here” link but still violates the style rule against standalone stub sentences and redundant meta commentary around links. The link to zk-examples/zk-ton-examples can be integrated directly into a single descriptive sentence that explains its purpose without a separate explanatory fragment.
Please leave a reaction 👍/👎 to this suggestion to improve future reviews for everyone!
| "group": "ZK proofs", | ||
| "pages": [ | ||
| "contract-dev/zero-knowledge", | ||
| "contract-dev/privacy-zk/groth16-examples" | ||
| ] |
There was a problem hiding this comment.
[HIGH] ZK navigation group lacks how-to labeling and ordering clarity
Lines 463–467 introduce a "ZK proofs" subgroup in the contract-dev navigation containing "contract-dev/zero-knowledge" and "contract-dev/privacy-zk/groth16-examples". Both target procedural, task-focused flows rather than pure explanations, but the group label is generic and does not convey that it contains how-to content. The style guide requires grouping and ordering content as Explanation → How-to → Reference and using labels that reflect document type to aid discovery; keeping a non-type label here makes it harder for readers to distinguish conceptual ZK docs from step-by-step guides.
Please leave a reaction 👍/👎 to this suggestion to improve future reviews for everyone!
2 participants
Closes #1840