Technical Overview
In this section, we describe a multi-table variant of the circle FRI low degree test. This variant supports domains of different sizes, thereby avoiding excessive padding overhead.
This section does not provide a detailed analysis of how FRI works, but instead focuses on the protocol as implemented in Stwo. Analyzing soundness and explaining why FRI works is out of scope. Interested readers are advised to consult "A summary on the FRI low degree test".
Introduction
Circle FRI tests the proximity of a function over a canonical coset 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
- is the space of polynomials interpolated by circle FFT, defined as follows: Let , then we can represent as:
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. Thus, the evaluations sent by the prover need not be exactly equal to evaluations of some polynomial of bounded degree.
In Stwo, we can represent the trace over multiple tables, with each trace table defined for a domain of different size. Thus, we are interested in circle FRI for the multi-table setting. We will now see an adaptation of circle FRI for the multi-table setting using an example. Consider three functions: defined over the domain , defined over the domain , and defined over the domain :
The domains , and are canonical cosets which form a chain using the squaring map : Suppose for the sake of our example, for in the domain , where is a canonical coset of size . For each in , we need to check that the functions are "close" to the polynomial space . For example, for , we need to check that the function defined over is close to the polynomial space .
Circle FRI follows a similar divide-and-conquer strategy as the Circle FFT algorithm. The prover recursively decomposes the functions 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.
We reduce the functions up to folded functions evaluated over a domain . For the sake of our example, consider . Then the sequence of domains for circle FRI in the multi-domain setting is as follows:
As shown in the above diagram, we use two different maps, as in the circle FFT algorithm: the projection map and the squaring map . Here, is the "line" domain; for every in , , where is the "line" domain of size .
Using circle FRI, the prover will prove proximity of functions to polynomial space , to space , and to space by reducing these three checks into a single check i.e. checking proximity of function to the polynomial space . The verifier will have oracle access to the evaluations , , . The protocol proceeds as follows.
Protocol
-
Commit phase: Consists of rounds.
- Round 0: The prover will decompose the function over the domain into two functions over the domain as follows The prover will find the evaluations of functions over the domain using the evaluations of over domain as follows: Note that this decomposition and the process of finding evaluations of the decomposed functions is very similar to the circle FFT algorithm. Now the prover will fold the evaluations of and over the domain using the randomness from the verifier as follows: The prover commits and gives the verifier oracle access to the evaluations .
- Round 1: The prover will decompose the function over the domain into two functions over the domain , same as the decomposition of in Round 0. The prover will also decompose the function over domain into two functions and over the domain as follows: The prover will find the evaluations of functions and over the domain using the evaluations of over domain as follows: Now the prover will fold the evaluations of , , , and over the domain using the randomness from the verifier as follows: The prover commits and gives the verifier oracle access to the evaluations .
- Round 2: This round is very similar to Round 1. The prover will decompose into and , then decompose the function into and . Then fold all their evaluations as follows: This is the final round, so the prover will send to the verifier in plain.
Let us describe the protocol for the general case. In each round , the prover has previous evaluations (for round we take ). The verifier sends and the prover commits to , defined as follows:
where are the decomposition of and are the decompositions of . The prover gives the verifier oracle access to , and in the final round is sent in plain.
-
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 queries the oracles for their values to spot-check the folding identities along the projection trace . That is, for all the verifier checks that:
If in each of the query rounds all spot-checks hold, and if is "close" to the polynomial space , then the verifier accepts. Otherwise, it rejects.
Security Analysis
In this section, we analyze the security of the FRI protocol at a high level. There are roughly two ways a prover can cheat:
- The functions are "far" from the polynomial space but somehow the prover gets lucky and ends up with . 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 are "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.