PlonK Deconstructed 4: Polynomial Commitment Scheme
![author](/_next/image?url=%2Fprofiles%2Fbenjamin-bencik.jpeg&w=96&q=75)
Ben Bencik
![](/_next/image?url=%2Fkzg%2FKZG.png&w=3840&q=75)
Polynomial commitment scheme is a crucial component of the protocol, which is why understanding it will explain many steps in the protocol. In this part, we will briefly explain commitment schemes and then look at the KZG procedures in detail.
Commitment Scheme
First of all, commitment schemes are not specific to the PlonK protocol. They are a widely used cryptographic primitive. These schemes allow the prover (or in this context the committer) to commit to a piece of information while keeping it hidden from the verifier. The property that ties the committer to a specific piece of information is called binding. The second important property is hiding, which means that the prover cannot extract the committed information from the commitment. To use a metaphor, imagine that the committer locks his precious information into a container and gives it to the verifier. After this point, the committer does not have access to the committed information and thus cannot change it anymore. Moreover, since the box is locked, the verifier cannot reveal the information on his own. However, he can get access to the information by requesting the committer to unlock the box.
![](/kzg/commitment_drawing.png)
In the context of PlonK, we will be talking about polynomial commitment schemes (PCS). The secret information that the committer has is a description of a polynomial with some degree bound (maximum degree) . To have a knowledge of a polynomial means to know its coefficients. The point of a PCS is to be able to commit to a polynomial and then prove its evaluation on an arbitrary point without giving away the coefficients. Understand it as a tool by which the verifier can reliably check the evaluation of a specific polynomial. So, PCS is not related to arguing that the prover has the correct polynomial. Instead, it is used to ensure that the answers provided by the prover are correct evaluations of the committed polynomial at a specific point. A standard non-interactive polynomial commitment scheme should have these procedures:
: generate public parameters
: calculate the commitment to - make the prover "stick to"
: given a challenge the prover computes and returns the tuple where is proof of the claim
: given the verifier is checks and outputs accept or reject
![](/kzg/poly-pcs-diagram.png)
For now, we will be somewhat secretive about the challenge and take it as given. Later, we will describe who provides the challenge. The motivation behind PCS is that the prover remains bound to the committed polynomial and cannot choose it depending on the query he gets. This is formalized by the binding property.
KZG commitment scheme
There are numerous approaches to designing polynomial commitment schemes. We are specifically interested in KZG commitments since that is the one that was used in the PlonK paper. The nice thing about KZG is that commitment and opening consist of a constant number of elements. A disadvantage is that KZG has a trusted setup. Very informally, a trusted setup means that an enemy cannot discover a key that was used to generate the public parameters.
The following part is going to get a bit more technical, so if you do not know what elliptic curves are, we highly suggest reading Math Toolkit for KZG first. Let's summarize a list of all the public "ingredients" needed for KZG:
: pairing friendly groups of points on an elliptic curve over a finite field where is the target group
: pairing
: generators of the groups
: upper bound on the degree of committed polynomial
: public parameter - structured reference string
The last item on the list is the public parameter created by the procedure. The is necessary for anyone who wants to make a commitment to a polynomial. In essence it is just a collection of points: where is unformly randomly selected secret key used to generate the . The important thing is that the committer (prover) must not discover because that would allow him to forge openings and invalidate the protocol. That is why it is good practice to delete right after the procedure and forget about it forever. Notice that some information about is known by everybody because it is contained in . However, the value is encoded as an elliptic curve point, which means it is hard to extract it due to the discrete logarithm problem on the elliptic curves. The can be reused to prove evaluations of an arbitrary polynomial that satisfies the degree bound . So, it is said that the KZG has a one-time trusted setup.
Evaluation check
The whole scheme relies on the following simple fact. For any univariate polynomial of degree the assertion is equivalent to checking if there exists polynomial of degree smaller than such that:
What is the intuition behind this check? (optional section)
We have a polynomial , and we know that . Using we can construct which is 0 at . If then is the root of so could be also written as . Now we do a bit of reordering: Just like that, we can change from checking equality to checking divisibility.
It might look intimidating, but this is just an observation that it is possible to effectively transform an evaluation check into this divisibility check and vice versa. As discussed in the section about comparing polynomials, the equality of these expressions can be verified with high confidence just by evaluation at a single randomly chosen point.
Now, we can finally proceed with the description of KZG procedures. The scheme is sketched below, which might help you understand it better. If looking at the code works better for you, make sure to look at our implementation of KZG.
Generate
The value is chosen uniformly at random and is generated by exponentiation of the group generators . As discussed above the prover cannot discover the key . So the setup procedure cannot be done by the prover.
Commit
The prover has some secret polynomial of degree at most . To commit to , the prover sends commitment which he claims is equal to . This means that commitment is a group element, which is just a point on the curve.
It might feel sneaky that the prover is asked to compute the evaluation even though we explicitly said that the prover could not have access to , so how is the evaluation calculated? Now, it will finally make sense why we need the . As described in the previous post polynomial evaluation of in the exponent of the group generator can be calculated as:
We know how to compute commitment for general , so now we just plug in as: . Note that contains all needed , which means that the prover does not (and in fact cannot) know to evaluate . So, the committer gives an evaluation of polynomial on point (encoded as a group element) without knowing the actual point. What a cool trick, right?
To sum up, we took the prover's secret polynomial and showed how to transform it into a group element by putting it into exponent . Rewriting it like this allows us to use the SRS and evaluate without knowing .
Open
Given the query the prover opens the polynomial at that point , nothing complicated. Then, the committer needs to compute the witness: There is nothing special about that, the prover just needs to perform polynomial division. Showing the existence of is the same as verifying . Therefore the polynomial is the proof that . Then the prover calculates which is also possible to compute without knowledge of using the same approach as in the procedure. Finally, the prover outputs the tuple .
Verify
Here might be a good place to revise that the polynomial commitment scheme is used to ensure polynomials are evaluated correctly. If the verification procedure succeeds, the verifier is convinced that the evaluation at the point on the committed polynomial is supposed to be . As we have seen above, this could be achieved by showing the existence of . Without the fancy group pairings, the check is just:
The prover does not know but can send as elliptic curve points . The check changes to:
The verifier knows only and the public parameter SRS. Let's describe the expression from the left side. The verifier has the commitment which was sent by the committer. He is was given and needs to calculate and is part of the .
On the right side, the verifier got the witness and is part of . He has the value and can calculate , because G_2^ is part of the . The thing to notice is that the verifier would not be able to calculate without the pairings. Remember that would just give , but the pairing property makes it possible to calculate this operation.
![](/kzg/kzg-diagram.png)
Even though the SRS string is big, notice that the verifier only needs to know , and the rest of is not needed. Another important thing is that the verifier discovers the evaluation , which makes this not zero-knowledge. We will show how to fix this before giving the first commitment in Round 1 of the prover algorithm.
There are also more advanced flavors of KZG, where it is possible to batch: evaluations of a single polynomial at multiple points, evaluations of multiple polynomials at single points, or evaluations of multiple polynomials at multiple points. These are much more effective than running the commitment scheme for each separately.
One more important thing is that the calculation of the commitment can be generalized by the term multi-scalar multiplication (MSM), which is simply multiplication the elements of the by the coefficient of the committed polynomial. And MSM is a major bottle-neck of the protocol and based on the Ingonyama can take up to % of prover time in .
We will continue with the post about the setup algorithm for the protocol, which produces preprocessed input for both the prover and the verifier.
List of the PlonK blog posts:
- 1: Overview
- 2: Arithmetization
- 3: Math Preliminaries
- 4: KZG
- 5: Setup
- 6: Round 1
- 7: Round 2
- 8: Round 3
- 9: Round 4
- 10: Round 5
- 11: Verification
If you have any suggestions or improvements to this blog, send an e-mail to contact@maya-zk.com