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:
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 S-two, 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:
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
- 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:
- 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:
- 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.