Ligero Polynomial Commitment Scheme

References: GLS+21, page 46, AER24.

Prerequisites

As described within the committed input layers section, the Ligero polynomial commitment scheme (PCS) consists of a and an phase such that

  • During , the prover sends a commitment for the input layer MLE .
  • After running the rest of the GKR claim reduction process, we are left with a claim .
  • During , the prover sends an evaluation proof showing that .

Short Introduction to Reed-Solomon Codes

We provide a brief introduction to Reed-Solomon codes, as these are prominently featured within the Ligero construction. First, we describe a few properties of general linear codes which will be useful:

  • An -linear code is a subspace of dimension (i.e. is spanned by linearly independent basis vectors of length each) where implies that for all nonzero codewords .
  • We define the Hamming weight is the number of nonzero entries in .
  • For all distinct we have that , since the difference of two codewords is itself a codeword.
  • The encoding step of a linear code can be described by a matrix-vector multiplication , where is the unencoded message and is the code's generator matrix. For simplicity we will just use as the encode function notation.
  • We call the rate of the code, as it describes (the inverse of) how much redundancy the code has. is then the "expansion factor", or how much larger the codeword is than the original message.

Next, consider the set of (univariate) polynomials of degree and a domain . Let .

  • Let be the restriction of to . Note that can be treated as just a vector of length by taking its evaluations .
  • We define a Reed-Solomon code , i.e. all the restrictions of to evaluations over for degree functions .
  • If we let and call the evaluation domain size , then an RS code is just an linear code (codewords are the evaluations of over , and the un-encoded messages are just polynomials of degree , which can be specified with coefficients).
  • Note that two polynomials of degree agree on at most points, and thus the Hamming distance between codewords is .

The last property of Reed-Solomon codes is extremely useful for the purposes of code-based PCSs such as Ligero and FRI -- if we have that , for example, then for two polynomials where we have that , which is over half of the evaluation domain. This intuitively makes it very easy for a verifier to catch a prover who commits to one polynomial's codeword and attempts to evaluate using another's, since sampling even a single random point within will reveal the difference with probability .

Vector-Matrix-Vector Product Observation

(Reader's note: the construction described here is identical to that in the Hyrax PCS section.) Let our input layer MLE have evaluations over (for example, ).

As described in the introduction above, the prover is trying to show that . As described in the Hyrax PCS section, one way to compute the evaluation is as follows:

The column vector on the right can be viewed as the tensor product and we will use this shorthand going forward. Just this observation, however, is not enough to motivate our description of Ligero PCS. Instead, we consider an alternative formulation for the evaluation .

Rather than simply linearly arranging the coefficients of as above, we can instead arrange them in a square matrix (for now, assume that is even) of size by enumerating the coefficients in row-major order:

Given the matrix formulation of above, we can write the evaluation of as the following vector-matrix-vector product:

We denote the left vector as and the right vector as . This allows us to create the following PCS:

Commitment Phase

The commitment phase of Ligero works as follows:

Let be the 'th row of , . Recall that since is a square matrix.

  • First, the prover treats the values within as the (monomial basis, i.e. usual) coefficients of a degree- univariate polynomial. They compute using a Reed-Solomon encoding function. Let be the code rate; we then have that .
  • The encoded matrix now looks like the following:

The prover commits to as follows:

  • Using a cryptographic hash function , the prover first computes a hash over each column:

  • Next, the prover takes the vector of column-wise commitments and computes a Merkle tree using those commitments as the leaves. In other words, the bottom layer of the tree is , with pairs of leaves being hashed, and the root of the tree is the commitment.
  • The (interactive) prover sends to the verifier. Note that with this commitment setup, the verifier is able to "open" any column of and ensure that it is consistent with the commitment .

Evaluation Phase

The prover wishes to show that . It does so by first computing and sends this to the (interactive) verifier (note that the prover is sending product of against the unencoded ). Since the verifier doesn't (yet) trust this value, we'll denote its view of this prover message as .

The verifier asserts that . If the prover is honest and then this proves that the evaluation was correct.

The verifier then computes , with . To ensure that the prover computed correctly, it will check random values in against .

  • Note that because is a linear operation, we have that , where is the row-wise encoding as described earlier (check this for yourself -- use the intuition that Reed-Solomon encoding is just polynomial evaluation over a domain)

The verifier picks a set of indices and "opens" those columns of . For each , the prover sends over , as well as a Merkle path for against .

The verifier checks that , and verifies the Merkle path from to the it received during the commit phase.

The verifier is now convinced that the columns which the prover sent over are columns of the which was committed to during the commitment phase.

Finally, the verifier checks that . This last check ensures that the prover sent honestly -- if they attempted to cheat by sending for some , we have that each row of would differ from each row of in at least proportion of coordinates (as mentioned earlier, we generally have ), and therefore WHP (using a result from AER24), that (the honest ) differs from (the dishonest ) in at least proportion of coordinates as well.

With queries, the verifier catches a cheating prover at least

proportion of the time. We set such that the above probability is at least , where is our security parameter.

Costs

Assume that the prover is committing to a multilinear polynomial in variables. Let our code rate be , and assume that a Reed-Solomon encoding for a message with coefficients to a codeword with evaluations can be computed in time . Let be the set of columns we query during the evaluation phase.

Prover Cost

  • During the commitment phase, the prover first computes the encoded matrix of coefficients by encoding each row of . There are rows and each row's encoding takes time for a total runtime of .
  • Next, the prover computes hashes of the columns of , and then constructs a Merkle tree comprised of those for the final commitment. This costs hashes.
  • During the evaluation phase, the prover first computes and sends the result to the verifier. This takes operations.
  • Next, the prover sends over columns plus associated Merkle proofs to the verifier. The prover doesn't need to compute anything here, so this is free for the prover.
  • Assuming the cost of a single hash is , the total prover computation is

Proof Size

  • The commitment is a single Merkle root, and is thus just one field element.
  • The evaluation proof consists of the following for each column :
    • A column of with field elements
    • A Merkle path with field elements
  • Thus the total proof size is field elements.

Verifier Cost

  • During the commitment phase, the verifier receives a single Merkle root element and does nothing else.
  • During the evaluation phase, the verifier first receives the prover's claimed and computes . The encoding step takes field operations.
  • Next, the verifier computes and checks this against the claimed evaluation value. This requires field operations.
  • Next, the verifier receives columns of from the prover. For each column, the verifier must
    • Compute a hash over elements to get the column hash value.
    • Check the Merkle proof over a path of length against the root received in the commit phase.
  • The verifier's runtime for the check phase is hashes.
  • The verifier's total runtime is