Groth16 needs a per-circuit phase-2 trusted setup. That setup produces the proving key the browser uses and the verification key the on-chain verifier embeds. If anyone who participated in the setup retained their contribution randomness — the so-called "toxic waste" — they could forge withdraw proofs. The point of a public ceremony is that the result is independently verifiable and the trust assumption is explicit.
What the ceremony produced
A phase-2 ceremony anchored to a public Bitcoin-block beacon. The beacon's role is unpredictability: because the block was mined after the contribution was recorded, no contributor could have known the future block hash, so no contributor could have crafted their entropy to bias the result.
| Input | Artifact |
|---|---|
| Phase-1 input | Hermez Powers of Tau (powersOfTau28_hez_final_18.ptau), the public, multi-party Hermez ceremony |
| Compiled circuit | the withdraw circuit's R1CS |
| Beacon | a public Bitcoin block hash |
| Proving key | withdraw_final.zkey — served to the browser |
| Verification key | verification_key.json — embedded as constants in the on-chain verifier |
Phase-1 reuse of the Hermez Powers of Tau is industry standard: it is a large, public, already-multi-party ceremony.
Roadmap
A public multi-party MPC ceremony — many independent contributors — is planned as the protocol matures. Distributing the setup across many independent contributors makes the trust assumption robust. The migration produces a new proving key and verification key, deployed together: the on-chain verifying key and the client-side proving key must come from the same ceremony, or proofs fail at submission.
How to verify the ceremony yourself
The whole point of a public ceremony is that anyone can replay the math: you can independently verify that the final proving key corresponds to the public phase-1 input and the published circuit.
Step 1: Get the public inputs
# The phase-1 Powers of Tau file (the Hermez ceremony, depth 18)
curl -fL https://storage.googleapis.com/zkevm/ptau/powersOfTau28_hez_final_18.ptau \
-o pot18_final.ptau
# Compile the circuit's R1CS from the published circuit source
circom withdraw.circom --r1cs --wasm --sym -o build/
Step 2: Verify with snarkjs
yarn dlx snarkjs zkey verify build/withdraw.r1cs pot18_final.ptau withdraw_final.zkey
A passing verification means the final proving key is a valid Groth16 setup for this exact circuit, derived from this exact phase-1 file, with a valid history of contributions and beacons. It does NOT prove that a contributor discarded their entropy — that part is unverifiable for any phase-2 ceremony and is exactly what a multi-party MPC ceremony addresses.
Step 3: Verify the on-chain verifying key matches
The verification key embedded in the on-chain verifier is generated deterministically from the published verification_key.json. Re-running the same generation against the published JSON and diffing against the deployed verifier confirms the on-chain verifier uses the same key as the proving key — the three artifacts form a chain you can walk end-to-end.
Step 4: Verify the beacon
The beacon is a public Bitcoin block hash, fetchable from any block explorer. Hashing it into the snarkjs beacon step and confirming the result matches the published withdraw_final.zkey closes the loop.
Threat model notes
| Risk | Mitigation |
|---|---|
| Contributor retains entropy | Beacon randomization is unpredictable at contribution time; a public multi-party MPC ceremony distributes trust across many independent contributors |
| Beacon chosen too late | The beacon block is fixed publicly at finalize time |
| Compromised phase-1 input | Reuse of the large, public, multi-party Hermez Powers of Tau |
| Mismatched proving key ↔ verifying key | The artifacts are diff-able end to end (Step 3) |
If you find a discrepancy at any step of the verification, file an issue and do not deposit. The verification artifacts are the only thing standing between honest users and a forged-proof drain. Treat them like you would a kernel checksum.