Docs

The short version

zkFlash helps developers building with zero-knowledge proofs see the whole cycle of a test: whether a proof is valid, how long each step took on their machine, which public inputs it used, and why a test failed. The focus is understanding the cycle, not only producing a proof.

Everything labelled as a result on this site came from a real circuit, a real witness and a real verifier. There are no mock proofs and no stored sample timings.

Bundled circuits

Four Noir circuits are compiled in advance and served by this site. Uploading your own is planned, not built.

• hash_opening (946 gates, 6,464 byte proof). The prover knows two field elements whose Poseidon hash equals the public digest. It does not prove: who the prover is, or where the digest came from.
• range_gate (3,756 gates, 7,232 byte proof). The value behind a public commitment lies inside the public bounds. It does not prove: that the value is true in the world. the prover chose it.
• path_member (8,797 gates, 8,000 byte proof). A leaf derived from a private secret sits under the public root, and the public tag came from the same secret and the public scope. It does not prove: that the wallet sending a transaction is the holder of the secret. address, ip and timing stay visible.
• tally_floor (10,273 gates, 8,000 byte proof). Eight private counts behind a public commitment add up to at least the public floor. It does not prove: that the counts were measured honestly. the prover supplied them.

Generating a proof

Pick a circuit in the lab and press Generate. A Web Worker loads the compiled circuit, the WASM and the public setup points from this site, solves the witness with noir_js and generates an UltraHonk proof with Barretenberg on one thread. The page keeps responding while it works.

The setup points are the public Aztec Ignition ceremony values, cut to the first 2^17 points. Your inputs are not sent anywhere. Even so, these circuits are test material: do not type real secrets into them.

Verification engine

Two checks exist. The local check runs the verifier in your browser with the circuit's key and works for all four circuits. The on-chain check sends the same proof and public inputs to ZkflashPathCheck through an eth_call, for the path_member circuit only. A call costs no gas and sends no transaction. In a Foundry test, one check used 2,917,904 gas.

The inspector also lets your browser derive the verification key hash itself and compares it with the one in the bundle.

Test scenarios

Each case states its expected outcome before it runs. There are four kinds, and three possible outcomes: verified, witness rejected, or verification rejected.

• Valid. A true statement. The proof must verify.
• Invalid. A false statement. The circuit must refuse to produce a witness, so no proof exists.
• Tampered public input. A valid proof, then one public input is raised by one. Verification must fail.
• Tampered proof byte. A valid proof, then one bit of one byte is flipped. Verification must fail.

You can add your own cases with other values, another byte position and any expected outcome. A case whose result differs from what you wrote is shown as differing, and that is often the useful part.

Timeline and monitor

The timeline splits a run into preparation, witness, proving and verification. The monitor collects your runs per stage and per circuit, and stores them only in this browser. The first run of a session includes loading WASM in its preparation stage.

Report files

A report holds the circuit hash, verification key hash, environment, cases with expected and actual results, stage timings, the first valid proof with its hash, and a list of limitations. Export it as JSON or Markdown. Private inputs are not in it.

Two hashes matter. The report hash covers the whole canonical JSON, so it changes with every run, since proofs are randomised and clocks differ. The outcomes hash covers only circuit, cases, expected and actual results, so two machines that see the same behaviour get the same one. Anyone can upload a report file and have both hashes recomputed in their browser.

The run book

ZkflashRunBook is a public record with no owner, admin, fee or upgrade path. It takes no ETH and holds no tokens. Before it is deployed, the Reports page runs the same rules as a labelled practice mode in your browser.

• Workspaces. Anyone can open one. Roles are per workspace: lead, runner, reviewer. An invite does nothing until accepted, and a workspace always keeps a lead.
• Circuit registry. Leads register a circuit hash, key hash and optional verifier. A new version supersedes the last. Retired circuits take no new reports.
• Anchors. Leads and runners anchor a report hash, outcomes hash, proof hash and case counts. The author can withdraw only while nobody has attested it.
• Attestations. Any wallet other than the author, or only reviewers and leads if the workspace says so, can attest once. "Reproduced" must carry the same outcomes hash, which the contract compares. "Not reproduced" carries a different hash. A report reads as disputed until reproductions outnumber disagreements.
• Proof check. Anyone can run a report's proof through the verifier its circuit names, inside a transaction. The workspace chose that verifier, so check which address it is.

What this does not show

• A verified proof does not show that inputs are true in the world, or who the prover is.
• An anchor shows when a hash was published. It does not show that the report is correct: results are self-reported.
• An attestation counts a wallet. One person can hold many wallets.
• Timings do not carry over to other devices.
• The bundled circuits have had no outside review. Do not use them to protect value.
• Passing these cases does not show a circuit is sound. It shows these cases came out this way.

Planned, not built

• Custom circuit upload.
• Developer SDK and API.
• Hosted test runs, premium reports and $ZKFLASH credits.

None of these exist today, and no date is promised.

Deployments

Robinhood Chain (4663). Check any address yourself with npm run verify-deployment from the source.

Token

$ZKFLASH is a community token on Robinhood Chain with no promised value. The studio does not need it. Its possible uses (hosted test credits, premium reports, API access) are planned, not built. See the token page.

Questions