Circle STARKs: Arithmetizing Circles
Contents
This is Part IV of a four-part series on Circle STARKs. The original appeared on the ZK Security blog.
Recap#
- In Part I, we motivated Mersenne prime fields for fast modular arithmetic and detailed why the non-smooth multiplicative group prevents STARK instantiations.
- In Part II, we described the circle curve and the domains: twin-coset and standard position cosets. We also described polynomials over the circle curve and constructed vanishing polynomials over the two domains.
- In Part III, we described the Circle FFT algorithm as a Cooley–Tukey style algorithm that lets us move between evaluation and coefficient representations of bivariate polynomials over the circle curve. We also defined the basis induced by the Circle FFT algorithm and the dimension gap between the space of bivariate polynomials over the circle curve and the space of polynomials interpolated by Circle FFT.
Introduction#
This final post stitches everything together we built in Parts I–III. Our goal is to show how those ingredients combine into a complete Circle STARK.
We begin by describing the arithmetization over the circle curve. From there we introduce Circle FRI, the low-degree test to ensure polynomials satisfy a degree bound. Finally, we walk through the Circle STARK construction.
Arithmetization#
The execution trace is simply the record of the computation: each row captures a step or a clock cycle, each column records the evolution of a register and every entry lives in the Mersenne prime field . If the computation has cycles and operates on registers then the trace table is of size . Arithmetization is encoding the local transition rules of this table as polynomial identities that hold over the entire domain, so that reasoning about the computation reduces to checking evaluations of polynomials.
We define our computation in terms of a trace table with rows and columns. Each cell in this table is an element from . We can define the entire trace using column vectors:
Suppose is a standard position coset of size . We will interpolate each trace column over the trace domain using Circle FFT to obtain bivariate polynomials over the circle curve. The polynomials belong to the space of bivariate polynomials over the circle curve i.e.
The prover commits to the column polynomials by committing to their evaluations over an evaluation domain which is a factor larger in size than the trace domain i.e.
where . The evaluations of over the evaluation domain are committed using a Merkle tree.
Now we want to add constraints over the trace table. Suppose we add a total of constraints. For simplicity, we only describe constraints over the neighboring rows as follows:
Here, denotes translation by the generator on the column polynomial , where . The trace domain is a coset , where is a subgroup of size and is an offset. Each column is interpolated over the trace domain represented as:
Thus pulls in the “next row” of the trace. The constraints are polynomials defined in terms of the column polynomials and a predefined selector polynomial which determines the rows on which the constraint should apply.
Note
What do these selector polynomials look like?
Which polynomial space do they belong to?
Suppose we want to apply the constraint on the subdomain . Then the selector polynomial should evaluate to some non-zero value for points in and zero value for points in . Another way to describe is that it should vanish outside . They are defined as follows:
where and are the vanishing polynomials for and , respectively.
Even though is defined as a rational function, on the circle curve it is a polynomial. The reason is that the global vanishing polynomial vanishes on the smaller domain , so is divisible by . As a result, the ratio has no poles. For more details refer Lemma 10, Circle STARKs.
We know that and (refer to Dimension Gap, Part III). Thus also belongs to the polynomial space .
Now rather than proving all the constraints separately, we batch them into a single one. The verifier chooses a random from the extension field of . The prover computes the following:
In order to prove validity of the above identity over the entire trace domain , the prover computes the quotient polynomial as follows:
Such a quotient must exist because if all constraints are satisfied throughout , the left-hand side vanishes on and is therefore divisible by .
Note
What is the degree of the quotient polynomial ?
Which polynomials space does it belong to?
Let the degree of each be atmost . The polynomials
are in the space with maximum degree . Thus the maximum degree of the left-hand side of the following expression is .
Now the degree of is . Thus the degree of is and is in the polynomial space . Note that is over the extension field , since is sampled from .
Now the prover will have to prove that the columns polynomials are of degree and the quotient polynomial is of degree . To make the degree bound uniform (i.e. ) across all the polynomials, the quotient polynomial is split into polynomials as follows:
where is a disjoint union of twin-cosets of size .
Note
Intuition on the decomposition of the quotient polynomial
The quotient polynomial belongs to the space which has dimension . The decomposition of follows from the decomposition of polynomial space which can be decomposed as follows:
where the space is of dimension .
The above decomposition is very similar to the decomposition of in Dimension Gap, Part III.
Now we can further decompose polynomials from space as polynomials from the space combined with some basis of over i.e. are the polynomials from the space and are the basis of over .
This gives an intuition on the decomposition of the quotient polynomial . For complete proof, please refer Lemma 12, Circle STARKs.
Thus the prover has to prove the validity of the following equation:
and prove that the polynomials , are of degree . We will now describe Circle FRI to prove the latter.
Circle FRI#
Circle FRI tests the proximity of a function over the evaluation domain of size to some polynomial from the polynomial space . The function is represented as a vector of evaluations over the domain .
Here:
- is a field extension of
- is the log of blowup factor
- is the space of bivariate polynomials over the circle curve, which can be decomposed as follows (as described in Dimension Gap, Part III):
Note
Why check proximity to a polynomial?
The prover sends evaluations of a function to the verifier. However, the verifier does not know if this function is a polynomial, or if it satisfies a pre-specified degree bound. FRI allows the verifier to check that the evaluations sent by the prover are indeed “close” to some polynomial of bounded degree. Here, the verifier only checks for proximity; that is, the verifier accepts even if the evaluations sent by the prover are “close enough” to those of a polynomial of bounded degree.
Circle FRI follows a similar divide-and-conquer strategy as the Circle FFT algorithm. The prover recursively decomposes the function and folds the odd and even parts using randomness sent by the verifier. This reduction continues until the proximity test of the folded function to the polynomial space is small enough for the verifier to check directly; in this case, the prover sends the folded function directly to the verifier.
The following figure shows the sequence of domains for the circle FRI algorithm with folding rounds using a chain of -to- maps.
As shown in the above diagram, we use two different maps, as in the circle FFT algorithm: the projection map and the squaring map . The protocol starts with a standard position coset of size where and then takes projection onto the -axis using map to compute the quotient . Then subsequently apply the map for rounds to get the quotient with elements. To know more about these maps, please refer Sequence of Domains for Circle FFT, Part III. For notational convenience, we have defined the domain and map for the th round as and , respectively.
At each step of Circle FRI, the prover will decompose and fold functions over the sequence of domains as described above. But before folding, the prover decomposes as:
where is from the FFT space , , and is the vanishing polynomial of the standard position coset of size . This reduces the proximity claim of to to that of to the FFT space , which is checked through repeated folding of .
We start with the proximity claim of to the FFT space . In each round , we reduce the previous proximity claim of to to a new proximity claim of to the FFT space where
We will now explain the complete protocol and the above reduction in detail. The prover has a function and the verifier is given an oracle to . The protocol consists of a commit phase and a query phase.
Commit Phase#
- Decomposition: The prover decomposes and send to the verifier.
- Folding: The prover holds the function which it wants to prove proximity to .
- For the first round of folding i.e. ,
- The verifier sends a random challenge .
- The prover decomposes the function using the map as follows: where are as follows: As we have seen in Dimension Gap, Part III, we can also decompose the space of polynomials interpolated by Circle FFT as: Thus we have reduced the task of checking proximity of to to checking proximity of and to . But rather than checking two proximity claims, we fold them into a single proximity claim using the random challenge from the verifier. Thus after first round, we have reduced the proximity claim of to to that of to .
- For subsequent rounds i.e. we use the same procedure. The only difference is that we use the squaring map in each round i.e. . For the th round,
- The verifier sends a random challenge .
- The prover decomposes the function from the previous round as: where are as follows: The prover folds the functions as follows: Thus after th round, we have reduced the proximity claim of to to that of to .
- For each round, the prover sends an oracle for to the verifier. In the final round, the prover sends in plain which the verifier can directly check the proximity claim of to the polynomial space .
- For the first round of folding i.e. ,
Query Phase#
In the query phase, the verifier checks that the prover computed the folding correctly using the oracles sent by the prover. It consists of rounds. In each round:
- The verifier samples and applies each map to the element to get an element of each domain along the projection trace, shown as follows: Then the verifier queries the oracles for values of and on the points along the above projection trace.
- The verifier checks the first folding round i.e. equation at as follows. Note that here , since is the projection map .
- The verifier checks equation for subsequent folding rounds i.e. for all check:
If all the above checks pass for all rounds then the verifier accepts, otherwise reject.
Security Analysis#
In this section, we give some intuition on the security of the FRI protocol. There are roughly two ways a prover can cheat:
- The function is “far” from the polynomial space but somehow the prover gets lucky and ends up with which is “close” to . The proximity gaps paper analyzes that this happens with negligible probability. That is, if even one of the functions is “far” from the polynomial space , then the function will be “far” from with high probability.
- Now suppose is “far” from the polynomial space , then the function will be “far” from , but to cheat the verifier, the prover cheats in the folding rounds and sends some valid . Now the verifier must ensure that the prover has performed the folding correctly in each round using the oracles sent by the prover. This is exactly what the verifier checks in the query phase. From the “Toy Problem Conjecture” (ethSTARK, Section 5.9), each query done by the verifier gives (i.e. log of blowup ) bits of security. Thus, for queries, the security is bits.
Circle STARKs#
In this section, we will combine all the ideas we have covered so far in this series to construct the Circle STARK protocol. Given the trace table as columns of length i.e.
The protocol proceeds as follows:
- Trace Commitment: The prover interpolates each trace column as a bivariate polynomial over the trace domain using circle FFT. Then evaluates the polynomials over the evaluation domain and commits to the evaluation vector using a Merkle tree. The prover sends the Merkle commitment to evaluations of each to the verifier.
- Arithmetization: The verifier sends the random to batch all the constraints. The prover computes and decomposes it to obtain and polynomials. Each is committed over like the trace polynomials. The prover sends the Merkle commitment to evaluations of each and to the verifier. Now the prover has to prove validity of equation i.e.
- Opening: The above identity is checked on an out-of-domain point on the circle over the extension field. The verifier samples and requests openings of and from the prover. The prover responds with claimed values of at the points and , respectively, for each , as well as the values of at . The verifier checks the identity using these claimed values. Note that other values like evaluations of the vanishing polynomials can be succinctly computed by the verifier.
- Low-Degree Test: The prover and verifier engage in a low-degree test on the following quotients using the Circle FRI protocol. where and are the vanishing polynomials over and , respectively. All the above proximity tests can be batched into a single proximity test using randomness from the verifier. If the proximity test passes and if the claimed values satisfy the overall identity, the verifier accepts.
Conclusion#
This final post connected all the ideas from arithmetization, quotienting and Circle FRI low-degree test to describe the Circle STARK construction. This concludes the four part series on Circle STARKs.