When people in the cryptocurrency space say “zero-knowledge proofs”, they’re usually referring to a particular type of proof — zk-SNARKs.

The math underpinning zk-SNARKs is difficult to understand, but unless you’re implementing them, attacking them, or too paranoid to take a cryptographer’s word for it, you can skip the math and focus on what they do.

Let’s talk about the name. The “zk” stands for zero-knowledge. Amazingly, there are a number of other “snarks” in computer science, including a theorem prover and a type of graph, and outside of computer science, including imaginary creatures, video games, and sarcastic remarks.

This particular SNARK stands for succinct non-interactive adaptive argument of knowledge³.

You can read “succinct” as “efficient enough that it can be computed in a reasonable amount of time”, which is especially important for verification.

“Non-interactive” means that SNARKs don’t require the verifier to interrogate the prover. Instead, the prover can publish their proof in advance, and a verifier can make sure it’s correct, similar to hashing a file.

Finally, an “adaptive argument of knowledge” refers to a proof of knowledge of some computation.

What does that mean, exactly? Imagine your grade-school math teacher gives you a complex arithmetic problem. Instead of providing the answer (and showing your work!), zk-SNARKs let you prove you know the answer, without actually sharing it.

That’s a neat trick, but there are some caveats.

SNARKs are resource intensive. As we’ll see discussing Zcash, some of the computation involved makes certain use cases, including mobile and low-power device usage, difficult, though recent progress in this space has been encouraging.

There’s also the issue of losing access to a secret. SNARKs allows a user to prove they have access to a secret, but the onus is still on the user to maintain the integrity and availability of the secret. We’ll discuss this restriction in more detail when we discuss SNARKs on Ethereum.

The most significant, structural drawback to SNARKs, however, is what’s called the setup phase.

Setup phase

For each type of problem you want to solve with SNARKs, there’s an upfront communication step called the setup phase. In this phase, the circuit, or computation you want to prove, is fixed. Because of this restriction, SNARKs aren’t a good fit to run arbitrary Turing-complete smart contracts — each new contract would require a new setup phase.

To make this more concrete, each problem your math teacher gives you would need a separate setup phase. There might be one for addition, and another for multiplication. Once you’ve done the setup phase between you and your teacher for addition, it doesn’t need to be repeated again each time you’re given an addition problem. Any new sorts of problems require a new setup.

There’s another noteworthy aspect to the setup phase. In this phase, a secret is generated that allows fake proofs to be published, undetected. In a 2-party setup, that’s okay — the verifier (your math teacher) is the one generating the secret, and as long as the verifier doesn’t share the secret with the prover (you), security is maintained.

If you want to use a particular circuit publicly, with more than one verifier, there needs to be a “trusted setup”. Instead of a single verifier generating (and hopefully destroying!) the proof-manufacturing secret, a group of people can generate the secret together. As long as one of those people is honest, and destroys their share of the secret, the security of the setup is guaranteed.

For a more detailed, yet remarkably accessible introduction to SNARKs, check out Christian Lundkvist’s “Intro to zk-SNARKs with examples”. For more on the math, check out Zcash’s explainer, “zkSNARKs in a nutshell” or Vitalik Buterin’s series on “Zk-SNARKs: Under the Hood”.

Zcash