Descripción de la fase III

All of our efforts so far can be seen as having one main goal: reducing everything to the 2 polynomials’ comparison protocol presented in this subsection. This is because this protocol satisfies two main properties that we’re after, and that are typically harder to achieve in a universal proof system:scalabilityandzero knowledge13

How does this problem take form? Essentially, the Verifier is given (the evaluations of) two polynomials and asked to verify whether they’re equal or not. We want to do this in the fastest way possible. Here is our typical language definition:

2POLY(F) {︂ (f,g)⃓⃓f(x)=g(x)∧d e g(f)=d e g(g)=d∧f,g∈F[x] }︂ 14_{or just} {︂ (f,g)⃓⃓∀i∈D:f(i)=g(i), f :D→C, g:D→C, |D| =d+1 }︂

For now, we will assume that the polynomials (i.e. lists) are of the same degree, and we will focus on building a protocol to check their equality; Section3.1.7will take care of the degree check. The first approach the Verifier can take to solving this problem is just naïve comparison:

∀i_∈D:f(i)₌? g(i)

This method gives usperfect soundness, but it also takesO(d+1) steps to run. Assuming that each polynomial is an extremely long execution trace, this check would force the Verifier to waste too much time, thus precludingverifier scalabilityfrom our final solution. We can do much better byslightly increasing the soundness error, the same way that PCPs (Section1.2.1) employ “probabilistic checks”. Let us, then, consider the error probability of checking the polynomials against just a single element of the domain, which I will call “succinct query”. The error occurs on any index which makes our check succeed, in spite of having two different polynomials; here is an example with the errors highlighted in red:15 x 1 2 3 1 2 3 f(x) g(x)

13_{universalityis another important one, but that’s precisely what we achieve through our problem reductions!} 14_{You will notice that we’re using polynomials with coefficients taken from a field, this is useful for efficiency}

optimisations that we will outline later. For now, just consider all elements to be integers.

15_{again, note that in this plot the polynomials map to real numbers, but they will be part of a field when used} for real programs.

3.1 zk-STARKs We can see by the plot that the size of the errors space is much smaller compared to the rest of the domain, but is it really the worst case scenario? Thankfully, there is a well-known theorem regarding polynomials which can answer this question:

Th. Polynomial Comparison two differing univariate polynomials of degree d are equal

in at most d evaluation points.

Now we have all the necessary information to calculate the error rate of a succinct query:

P r[error] _⇐⇒P r[X_∉L_∧check(X)₌T rue]

⇐⇒P r[(f,g)_∉2POLY_∧prob_check(f,g)₌T rue] ⇐⇒P r[f(x)_̸=g(x)_{∧ ∃}x₀.f(x₀)₌g(x₀)]₌ d

|D|

NOTE: an alternative way to visualise this problem, and leading to the same probability, can be seen as the application of the Schwartz–Zippel Lemma [55]–[57] to probabilistic polynomial identity testing.

So, our error rate is dependent on the degree of the given polynomials, and the size of the domain they’re evaluated on. In order to decrease this ratio, we have two available methods:

1. Compress the polynomials: to decreased, we need to replace our lists with equivalent alternatives of lower degree. In the given 2POLY problem this is not possible because the lists are given as is, but within the STARK context the polynomials actually relate to execution traces. Each element of a trace can be anything, as long as it complies with the given constraints – it may also contain irrelevant local variables, after being extracted from a complex program! Carefully crafting such execution traces can result in a reduction of their size, and of our polynomials’ degrees. Another technique is that of carefully interpolating the execution traces: the authors of the paper convert an execution trace to multiple Reed Solomon codes, obtaining further compressions because each local variable is considered separately!

2. Add Redundancy: to increase|D|, we need to increase the space from which we can pick our succinct queries. To do this, we can simply have the Prover give polynomial evaluations over a domain that is much larger than their degree, and this easily be obtained through interpolation.

Since the second method can always be applied to our 2POLY problem, we can always apply it to obtain any desired soundness errorϵ:

ϵ= d

|D_| =⇒ |D| = d

ϵ

This protocol will be completed with theF R Iprotocol in Section3.1.7for checking our original assumption that the two polynomials have the same degree.

NOTE: the approach of adding redundancy can also be applied to to probabilistic polyno- mial comparison using directly coefficients instead of evaluation points, with an even better

3 Universal VC Compilers

soundness error. The basic idea is to multiply both polynomials with a random polynomial of large degree, thereby spreading out single coefficients across multiple ones.

NOTE2: it is also possible to use multiple dependent queries to further improve the accuracy. Care must be taken to respect the zero-knowledge requirements described in Section3.1.6.