Skip to content
Blockchain LabTHE VENTURE STUDIO

LibraryPrivacy2013Design paperCorpus record

Pinocchio: Nearly Practical Verifiable Computation

Pinocchio. Bryan Parno, Jon Howell, Craig Gentry and Mariana Raykova.

Compile the program to a quadratic arithmetic program and prove it was satisfied. Verification is a small number of pairings, independent of the program's length, after a trusted setup.

A reading of the public document. Not a copy of it, and not a claim about a later network that reused the name.

A rollup that says 'we use SNARKs' should say who ran the setup and what program the circuit actually encodes.

The five-minute read

The defect

A client wants a server to run a program and return a proof that is cheaper to check than re-running the program.

The rule

Compile the program to a quadratic arithmetic program and prove it was satisfied. Verification is a small number of pairings, independent of the program's length, after a trusted setup.

How it is put together

The setup produces a proving key and a verification key. The prover's work is heavy. The verifier's work is small. The proof shows the computation, not a secret by itself. Secrets are an extra encoding.

Where the claim stops

The setup is trusted. Whoever knows the trapdoor can forge proofs.

One action, walked through

  1. Turn the program into constraints.
  2. The prover evaluates the witness.
  3. The verifier checks a constant-size proof against the verification key.
  4. Who could have kept the trapdoor?

The argument, unpacked

Why it is still on the desk

A rollup that says 'we use SNARKs' should say who ran the setup and what program the circuit actually encodes.

After the text

Zcash's first ceremony and almost every later pairing-based SNARK sit downstream of this compilation strategy.

What has to be true

  • The setup is trusted. Whoever knows the trapdoor can forge proofs.
  • Pinocchio is not Groth16, though Groth16 is a descendant.
  • It does not make an arbitrary program cheap to prove.

What happened after the paper

Zcash's first ceremony and almost every later pairing-based SNARK sit downstream of this compilation strategy.

What to check before you use the idea

  • Who could have kept the trapdoor?
  • What program is in the circuit?
  • Is verification constant in the program length?

Terms

QAP
A way to write a computation as polynomial constraints.
Trapdoor
Secret setup randomness that can forge proofs if it survives.

The problem the paper names

A client wants a server to run a program and return a proof that is cheaper to check than re-running the program.

What the design proposes

  • The setup produces a proving key and a verification key.
  • The prover's work is heavy. The verifier's work is small.
  • The proof shows the computation, not a secret by itself. Secrets are an extra encoding.

How the mechanism is specified

  • Turn the program into constraints.
  • The prover evaluates the witness.
  • The verifier checks a constant-size proof against the verification key.

What this page does not treat as proven

  • The setup is trusted. Whoever knows the trapdoor can forge proofs.
  • Pinocchio is not Groth16, though Groth16 is a descendant.
  • It does not make an arbitrary program cheap to prove.

Why a venture studio still reads it

A rollup that says 'we use SNARKs' should say who ran the setup and what program the circuit actually encodes.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.