In BaseFold, the authors make a key observation about the connection between multilinear and univariate polynomials, and the FRI protocol, leading to the construction of a new multilinear Polynomial Commitment Scheme (PCS).
Consider a multilinear polynomial , where . Transforming it into a univariate polynomial can be done by substituting for all . The resulting univariate polynomial has degree , as expected. We refer to and as the multilinear-univariate twins, hereafter.
Notably, executing rounds of the FRI protocol on the univariate polynomial with the randomness sequence results in a constant polynomial where , the evaluation of 's multilinear twin at . This suggests that FRI can act as an instantiation of the random oracle for a Sum-Check Interactive Oracle Proof (IOP). Concretely, this entails executing the two protocols concurrently, round-by-round, using the same randomness and equating their outputs.
To construct a PCS, BaseFold proposes the following approach. Suppose a Prover is given a multilinear polynomial and aims to construct a transparent PCS for evaluating it at . The Prover begins by committing to , the univariate twin of . It then concurrently executes the FRI protocol on and the Sum-Check protocol on the modified polynomial , where
The Sum-Check sum naturally evaluates to
which, by definition of a Multi-Linear Extension (MLE), provides the desired sample at . At the end of the protocol, the Verifier checks that
where and are the outputs of FRI and Sum-Check, respectively.
Intuitively, BaseFold's elegant heuristic is to use Sum-Check as an IOP for deterministically sampling and FRI as its random oracle instance, binding Sum-Check to the random sample . We identify two shortcomings of this method that are not addressed in this blog:
The randomness sequence consists strictly of in-domain evaluations to facilitate the FRI query phase. This concretely lowers Sum-Check's security, as it relies on a smaller sampling subset for its randomness. A way to decouple this limitation is by sampling the randomness from an extension field, as mentioned in Remark 2 of the BaseFold paper. This allows increasing the domain size for Sum-Check while still working on the original FRI domain. Interestingly, we think that this method is similar to running the PCS multiple times for the same but different randomness sequences .
Since the PCS evaluation must be unique, FRI must operate within the Unique-Decoding-Radius regime. Potential approaches to mitigate this are discussed in Basefold in the List Decoding Regime, DeepFold, and Khatam.
Our Contribution
A simple improvement to BaseFold's PCS involves replacing the Sum-Check protocol with a Point-Check protocol. Instead of using a Sum-Check of degree two, we propose a simpler approach equivalent to an MLE Sum-Check (i.e., a Sum-Check of degree one). This marks a concrete improvement from a product Sum-Check to an MLE-equivalent Sum-Check.
Point-Check is an interactive protocol between a Prover and a Verifier, where the Prover attempts to convince the Verifier of the correctness of , an evaluation of an MLE polynomial. The protocol proceeds as follows:
Note that we use in place of to highlight that it is a Prover's claim rather than the ground-truth. For an honest Prover, they are the same.
The Prover sends the claimed evaluation to the Verifier, along with the linear polynomial .
The Verifier checks that the polynomial satisfies and then provides the Prover with a random sample .
The Prover responds with the linear polynomial , which the Verifier checks using
In the -th round, the Prover sends the polynomial .
In the final round, the Verifier receives , evaluates it at the last random sample , and verifies it against the random oracle output .
A tabular representation of the Prover-Verifier interaction is presented below.
#
Prover
Verifier
0
1
This approach concretely reduces the Sum-Check degree from two to one, simplifying the protocol. Additionally, it allows direct verification of the Point-Check output against the FRI random oracle instance, obsoleting the multiplication by .
A Concluding Remark
Interestingly, in BaseFold’s PCS, Point-Check (or Sum-Check) serves two key purposes:
Mapping the security guarantees from the random sample to the target sample with high probability.
Extending the PCS's sampling set from in-domain to out-of-domain.
This gives rise to the following schematic interpretation of BaseFold’s PCS:
Point-Check, a degenerate Sum-Check IOP, is used solely to bind to .
FRI, an IOP of Proximity (IOPP), functions as a constrained, in-domain PCS, providing the evaluation .
The binding between them is enforced through their round-by-round interleaving.
Finally, we ask: can this heuristic be formulated more compactly, or is it optimal?
Acknowledgments
I’d like to extend my gratitude to Hadas Zeilberger from Yale University for reviewing the blog and pointing out a few things that I missed. A special thanks to Suyash Bagad, Karthik Inbasekar, Tomer Solberg, and Omer Shlomovits from Ingonyama for invaluable discussions.