The Procedure
We've already explained in rough detail the idea of error-correcting codes, as well as our most important particular code, the binary-field Reed–Solomon code. At this point, we're ready to describe Binius's multilinear polynomial commitment procedure.
Again, the problem is to describe what we should do to a multilinear polynomial in order to commit it. To fix notation, we again pick an integer and a huge tower field . Our input thus will be an -variate multilinear . (We will describe how to commit to small-field polynomials—or that is, how to reduce the small-field case to the large-field case—shortly.)
We're also going to pick a rate parameter , a positive integer. We can think of as a "blowup factor" parameter: during the prover's commitment phase, he will "stretch" his polynomial -fold. Thus, if , it will double in length; if , it will quadruple in length, and so on. As we hinted at earlier, our rate parameter controls a prover–verifier tradeoff. The higher gets, the costlier things get for the prover (because the code's rate gets worse), while the cheaper they get for the verifier (because the code's distance gets better). The real-life selection of is quite complicated (the verifier's returns on higher diminish very quickly, for example).
Finally, we fix a domain of size . In fact, as usual, we will set , where is the -basis of we used to construct the novel polynomial basis.
The Steps
There are just a few short steps we need to do to our input .
- We first take our input 's coordinates in the multilinear Lagrange basis, or in other words its evaluations over the -dimensional cube. (In practice, will be represented concretely this way at rest to begin with! So this is a no-op.)
- We're now do a flattening step. We already know how to identify with the flat, ordered integer range : we use the little-endian lexicographic identification . Using this identification, we flatten 's coefficients into a list —indeed, we just need to set .
- We use this flattened list as the coefficients of a univariate polynomial in the novel polynomial basis. That is, we write .
- We then evaluate this polynomial over our domain . Using the additive NTT, this key step can be performed in quasilinear—that is, —time. In this way, we get a long list, say ; this list can be viewed as constituting a function .
- The prover submits the entire list to the string oracle, which "sits on it" and notifies the verifier of receipt.
At this point, the commitment is complete. In the last step above, we exploit our use of the string oracle, an abstract machine present in the IOP model (by definition of that model). In practice, the prover will rather compute a Merkle commitment to this list, and send the resulting Merkle root to the verifier.