# Why and How zk-SNARK Works 1: Introduction & the Medium of a Proof

The article is an adaptation of thePDF version.

Despite the existence of multiple great resources on *zk-SNARK* construction, from original papers [Bit+11; Par+13] to explainers [Rei16; But16; But17; Gab17], due to the sheer number of moving parts the subject remains a black box for many. While some pieces of the puzzle are given one can not see the full picture without the missing ones.

The first time author discovered how things fit nicely together, one was astounded by the beauty of math, and the more dimensions were uncovered, the more it kept the spirit of wonderment. Hence the focus of this work is sharing the experience by shedding light onto the topic with a straightforward and clean approach based on examples and answering many whys along the way so that more individuals can appreciate the state of the art technology, its innovators and ultimately the beauty of math.

The work’s contribution is a simplistic exposition with a sufficient level of complexity, necessary to understand *zk-SNARK* without any prerequisite knowledge of the subject, cryptography or advanced math. The primary goal is not only to explain how it works but why it works and how it came to be this way.

# Preface

While initially planned as short, the work now spans several dozens of pages, nevertheless it requires very little pre-requisite knowledge, and one can freely skip familiar parts.

Do not worry if you are not acquainted with some of the used math symbols, there will be just a few, and they will be introduced gradually, one at a time.

# Introduction

*Zero-knowledge* *succinct non-interactive arguments of knowledge *(*zk-SNARK*) is the truly ingenious method of proving that something is true without revealing any other information, however, why it is useful in the first place?

*Zero-knowledge proofs* are advantageous in a myriad of application, including:

1) Proving statement on private data:

- Person
*A*has more than*X*in his bank account - In the last year, a bank did not transact with an entity
*Y* - Matching DNA without revealing full DNA
- One has a credit score higher than
*Z*

2) Anonymous authorization:

- Proving that requester
*R*has right to access web-site’s restricted area without revealing its identity (e.g., login, password) - Prove that one is from the list of allowed countries/states without revealing from which one exactly
- Prove that one owns a monthly pass to a subway/metro without revealing card’s id

3) Anonymous payments:

- Payment with full detachment from any kind of identity [Ben+14]
- Paying taxes without revealing one’s earnings

4) Outsourcing computation:

- Outsource an expensive computation and validate that the result is correct without redoing the execution; it opens up a category of trustless computing
- Changing a blockchain model from everyone computes the same to one party computes and everyone verifies

As great as it sounds on the surface the underlying method is a “marvel” of mathematics and cryptography and is being researched for the 4th decade since its introduction in 1985 in the principal work “The Knowledge Complexity of Interactive Proof-systems” [GMR85] with subsequent introduction of the non-interactive proofs [BFM88] which are especially essential in the context of blockchains.

In any *zero-knowledge proof *system, there is a *prover *who wants to convince a *verifier *that some *statement *is true without revealing any other information, e.g., *verifier *learns that the *prover* has more than *X *in his bank account but nothing else (i.e., the actual amount is not disclosed). A protocol should satisfy three properties:

- Completeness — if the
*statement*is true then a*prover*can convince a*verifier* - Soundness — a cheating
*prover*can not convince a*verifier*of a false*statement* - Zero-knowledge — the interaction only reveals if a
*statement*is true and nothing else

The *zk-SNARK* term itself was introduced in [Bit+11], building on [Gro10] with following Pinocchio protocol [Gen+12; Par+13] making it applicable for general computing.

# The Medium of a Proof

Let us start simple and try to prove something without worrying about the zero-knowledge, non-interactivity, its form, and applicability.

Imagine that we have an array of bits of length 10, and we want to prove to a verifier (e.g., program) that all those bits are set to 1.

Verifier can only check (i.e., read) one element at a time. In order to verify the statement one can proceed by reading elements in some arbitrary order and checking if it is truly equal to 1 and if so the confidence in that statement is ⅒= 10% after the first check, or statement is invalidated altogether if the bit equals to 0. A verifier must proceed to the next round until he reaches sufficient confidence. In some cases, one may trust a prover and require only 50% confidence which means that 5 checks must be executed, in other cases where 95% confidence is needed all cells must be checked. It is clear that the downside of such a proving protocol is that one must do the number of checks proportionate to the number of elements, which is non-practical if we deal with arrays of millions of elements.

Let us consider polynomials, which can be visualized as a curve on a graph, shaped by a mathematical equation:

The above curve corresponds to the polynomial: *f*(*x*) = *x*³ – 6*x*² + 11*x *– 6. The degree of a polynomial is determined by its greatest exponent of *x*, which in this case is 3.

Polynomials have an advantageous property, namely, if we have two non-equal polynomials of degree at most *d*, they can intersect at no more than *d *points. For example, let us modify the original polynomial slightly *x*³ – 6*x*² + **10***x *– **5 **and visualize it in green:

Such a tiny change produces a dramatically different result. In fact, it is impossible to find two non-equal polynomials, which share a consecutive chunk of a curve (excluding a single point chunk case).

This property flows from the method of finding shared points. If we want to find intersections of two polynomials, we need to equate them. For example, to find where a polynomial crosses an *x*-axis (i.e., *f*(*x*) = 0), we equate *x*³ – 6*x*² + 11*x *– 6 = 0, and solutions to such an equation will be those shared points: *x *= 1, *x *= 2 and *x *= 3, also you can clearly see that this is true on the previous graph, where the blue curve crosses the *x*-axis line.

Likewise, we can equate our original and modified version of polynomials to find their intersections.

The resulting polynomial is of degree 1 with an obvious solution *x *= 1. Hence only one intersection:

The result of any such equation for arbitrary degree *d *polynomials is always another polynomial of degree at most *d*, since there is no multiplication to produce higher degrees. Example: 5*x*³ + 7*x*² – *x *+ 2 = 3*x*³ – *x*² + 2*x *– 5, which simplifies to 2*x*³ + 8*x*² – 3*x *+ 7 = 0. And the Fundamental Theorem of Algebra tells us that a degree *d *polynomial can have at most *d* solutions (more on this in following parts), and therefore at most *d *shared points.

Hence we can conclude that evaluation (more on polynomial evaluation: [Pik13]) of any polynomial at an arbitrary point is akin to the representation of its unique identity. Let us evaluate our example polynomials at *x *= 10.

In fact out of all choices of *x *to evaluate, only at most 3 choices will have equal evaluations in those polynomials and all others will differ.

That is why if a prover claims to know some polynomial (no matter how large its degree is) that the verifier also knows, they can follow a simple protocol:

- Verifier chooses a random value for
*x*and evaluates the polynomial locally - Verifier gives
*x*to the prover and asks to evaluate the polynomial in question - Prover evaluates his polynomial at
*x*and gives the result to the verifier - Verifier checks if the local result is equal to the prover’s result, and if so then the statement is proven with a high confidence

If we, for example, consider an integer range of *x *from 1 to 10⁷⁷, the number of points where evaluations are different is 10⁷⁷ – *d*. Henceforth the probability that *x* accidentally “hits” any of the *d *shared points is equal to (which is considered negligible):

Note: the new protocol requires only one round and gives overwhelmingconfidence (almost100%assumingdis sufficiently smaller than the upperbound of the range) in the statement compared to the inefficient bit check protocol.

That is why polynomials are at the very core of *zk-SNARK*, although it is likely that other proof mediums exist as well.

# References

[Bit+11] — Nir Bitansky, Ran Canetti, Alessandro Chiesa, and Eran Tromer. *From Extractable* *Collision Resistance to Succinct Non-Interactive Arguments of* *Knowledge, and Back Again*. Cryptology ePrint Archive, Report 2011/443. https://eprint.iacr.org/2011/443. 2011

[Par+13] — Bryan Parno, Craig Gentry, Jon Howell, and Mariana Raykova. *Pinocchio: Nearly Practical Verifiable Computation*. Cryptology ePrint Archive, Report 2013/279. https://eprint.iacr.org/2013/279. 2013

[Rei16] — Christian Reitwiessner. *zkSNARKs in a Nutshell*. 2016. url: https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell/ (visited on 2018–05–01)

[But16] — Vitalik Buterin. *Quadratic Arithmetic Programs: from Zero to* *Hero*. 2016. url: https://medium.com/@VitalikButerin/quadratic-arithmetic-programs-from-zero-to-hero-f6d558cea649 (visited on 2018–05–01)

[But17] — Vitalik Buterin. *zk-SNARKs: Under the Hood*. 2017. url: https://medium.com/@VitalikButerin/zk-snarks-under-the-hood-b33151a013f6 (visited on 2018–05–01)

[Gab17] — Ariel Gabizon. *Explaining SNARKs*. 2017. url: https://z.cash/blog/snark-explain/ (visited on 2018–05–01)

[Ben+14] — Eli Ben-Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. *Zerocash: Decentralized* *Anonymous Payments from Bitcoin*. Cryptology ePrint Archive, Report 2014/349. https://eprint.iacr.org/2014/349. 2014

[GMR85] — S Goldwasser, S Micali, and C Rackoff. “The Knowledge Complexity of Interactive Proof-systems”. In: *Proceedings of the Seventeenth Annual ACM* *Symposium on Theory of Computing*. STOC ’85. Providence, Rhode Island, USA: ACM, 1985, pp. 291–304. isbn: 0–89791–151–2. doi: 10.1145/22145.22178. url: http://doi.acm.org/10.1145/22145.22178

[BFM88] — Manuel Blum, Paul Feldman, and Silvio Micali. “Non-interactive Zero-knowledge and Its Applications”. In: *Proceedings of the Twentieth Annual ACM* *Symposium on Theory of Computing*. STOC ’88. Chicago, Illinois, USA: ACM, 1988, pp. 103–112. isbn: 0–89791–264–0. doi: 10.1145/62212.62222. url: http://doi.acm.org/10.1145/62212.62222

[Gro10] — Jens Groth. “Short pairing-based non-interactive zero-knowledge arguments”. In: *International Conference on the Theory and Application of Cryptology and* *Information Security*. Springer. 2010, pp. 321–340

[Gen+12] — Rosario Gennaro, Craig Gentry, Bryan Parno, and Mariana Raykova. *Quadratic* *Span Programs and Succinct NIZKs without PCPs*. Cryptology ePrint Archive, Report 2012/215. https://eprint.iacr.org/2012/215. 2012

[Pik13] — Scott Pike. *Evaluating Polynomial Functions*. 2013. url: http://www.mesacc.edu/~scotz47781/mat120/notes/polynomials/evaluating/evaluating.html (visited on 2018–05–01)