Try   HackMD

BaseFold±: A Simple Improvement to BaseFold's Multilinear Polynomial Commitment Scheme using Point-Check

Yuval Domb
yuval@ingonyama.com

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

fM(x), where
x(x0,x1,,xn1)
. Transforming it into a univariate polynomial
fU(x)
can be done by substituting
xix2i
for all
i[n]
. The resulting univariate polynomial has degree
deg(fU)=2n1
, as expected. We refer to
fM(x)
and
fU(x)
as the multilinear-univariate twins, hereafter.

Notably, executing

n rounds of the FRI protocol on the univariate polynomial
fU(x)
with the randomness sequence
r(r0,r1,,rn1)
results in a constant polynomial
f(x)=cr
where
cr=fM(r)
, the evaluation of
fU(x)
's multilinear twin at
r
. 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

fM(x) and aims to construct a transparent PCS for evaluating it at
zFn
.
The Prover begins by committing to
fU(x)
, the univariate twin of
fM(x)
. It then concurrently executes the FRI protocol on
fU(x)
and the Sum-Check protocol on the modified polynomial
f~M(x)fM(x)eq(x,z)
, where

eq(x,z)=i=0n1xizi+(1xi)(1zi)

The Sum-Check sum naturally evaluates to

x{0,1}nf~M(x)=fM(z)

which, by definition of a Multi-Linear Extension (MLE), provides the desired sample at

z.
At the end of the protocol, the Verifier checks that

creq(r,z)=f~M(r)

where

cr and
f~M(r)
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

fM(z) and FRI as its random oracle instance, binding Sum-Check to the random sample
fM(r)
.
We identify two shortcomings of this method that are not addressed in this blog:

  1. The randomness sequence
    r
    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
    z
    but different randomness sequences
    r
    .
  2. 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

fM(z), an evaluation of an MLE polynomial.
The protocol proceeds as follows:

  • Note that we use
    f^M
    in place of
    fM
    to highlight that it is a Prover's claim rather than the ground-truth. For an honest Prover, they are the same.
  1. The Prover sends the claimed evaluation
    f^M(z0,z1,,zn1)
    to the Verifier, along with the linear polynomial
    f^M(x,z1,,zn1)
    .
  2. The Verifier checks that the polynomial satisfies
    f^M(x,z1,,zn1)|x=z0=f^M(z0,z1,,zn1)
    and then provides the Prover with a random sample
    r0
    .
  3. The Prover responds with the linear polynomial
    f^M(r0,x,z2,,zn1)
    , which the Verifier checks using

f^M(r0,x,z2,,zn1)|x=z1=f^M(x,z1,z2,,zn1)|x=r0

  1. In the
    i
    -th round, the Prover sends the polynomial
    f^M(r0,,ri1,x,zi+1,,zn1)
    .
  2. In the final round, the Verifier receives
    f^M(r0,r1,,rn2,x)
    , evaluates it at the last random sample
    x=rn1
    , and verifies it against the random oracle output
    fM(r0,r1,,rn1)
    .

A tabular representation of the Prover-Verifier interaction is presented below.

# Prover Verifier
f^M(z0,z1,,zn1)
0
f^M(x,z1,,zn1)
assert:f^M(x,z1,,zn1)|x=z0==f^M(z0,z1,,zn1)
r0
1
f^M(r0,x,z2,,zn1)
assert:f^M(r0,x,z2,,zn1)|x=z1==f^M(x,z1,z2,,zn1)|x=r0
r1
i
f^M(,ri1,x,zi+1,)
assert:f^M(,ri1,x,zi+1,)|x=zi==f^M(,ri2,x,zi,)|x=ri1
ri
n1
f^M(r0,r1,,rn2,x)
assert:f^M(r0,r1,,rn2,x)|x=rn1==fM(r0,r1,,rn1)

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

eq(r,z).

A Concluding Remark

Interestingly, in BaseFold’s PCS, Point-Check (or Sum-Check) serves two key purposes:

  1. Mapping the security guarantees from the random sample
    fM(r)
    to the target sample
    fM(z)
    with high probability.
  2. 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
    fM(z)
    to
    fM(r)
    .
  • FRI, an IOP of Proximity (IOPP), functions as a constrained, in-domain PCS, providing the evaluation
    fM(r)
    .
  • 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.