There are a lot of low-level details in PlonK which typically get low attention (or are completely swept under the rug) in many popular expositions.
Today, I want to talk about a different (from canonical PlonK paper GWC19) opening scheme, suggested in the subsequent work BDFG21. I will not discuss the PlonK itself (though, a bit of familiarity will help a lot in understanding this text).
Notably, this approach is used in practice in many currently existing PlonK systems; but explanations tend to follow GWC19. So maybe it makes sense to do a some sort of writeup on this.
This explainer is first and foremost for me (best way of understanding something is trying to explain it!); though I hope it will be useful for the general audience.
Plonkish protocols, generally, look like this:
In fact, typically these equations are supposed to hold on the polynomials themselves, and their rotations, where
Therefore, in general, to check these equations, in the last step, verifier sends a challenge point
I did not talk about quotient polynomial
There are actually few closely related things called KZG commitment scheme, we will talk about one used in PlonK:
SRS:
Here,
We will also denote
Now, we would like to describe how to "open" a commitment - i.e. prove that a committed polynomial satisfies
This is done as follows: prover computes
Verifier, then, checks:
Let's rewrite it in a bit more convenient way:
And further, using bilinearity, open up the rhs and reorganize the check a bit:
This is a very convenient way of representing the check, because you can notice that in these equations the right term in the pairing is always constant (
I.e., if we had multiple such equations, for multiple polynomials, we could add them up with random coefficients and only then check. Moreover, this addition would be only cheap
Notably, any homomorphic polynomial commitment scheme admits batching for the opening in the same point - but here were can do it even for different points.
Therefore, final PlonK verifier costs 2 pairings, and an MSM (random linear combination) of size total amount of points opened.
Here, I will talk about SHPlonK, which is a way of reducing the size of this MSM using multi-opening arguments.
Before we proceed, let's discuss how to open a polynomial in multiple points simultaneously.
Let's denote as
This could be achieved, for example, if we had a more extended SRS (having more powers of tau in the second group) - we would just write something like:
There are tricks in SHPlonK paper explaining how to batch these equations (but still inconvenient because they involve a lot of
But there is also an alternative idea (which I will try to first explain as how I understand it, and then check against the paper).
So, we have commitments to polynomials:
This, of course, still requires computing
Now, armed with our "first impression" argument, let's take a look what the authors of SHPlonK actually do in their paper. Let's denote the union of
Let's take a deep breath; first of all, to see how this is related to what I've said before, let's imagine we only had a single polynomial, and a single set
That's similar to the naive protocol I've described, but we do not open
Let's abstract a bit: imagine we had some (committed) polynomials
// Mary Maller's argument generally also deals with the situation where both
This is exactly what happens in the general argument, too. We need to check that
In order to do it, we get a variable
The equations provided above should also be optimized in a same fashion that we have did for a single opening proof - i.e. rearranged in a form
This approach is typically advantageous. Notably, verification is much cheaper provided we have a lot of different rotations of a same polynomial ("narrow" config). We also do not need to have a separate column for public inputs, like in normal PlonK - which is a notable difference. Instead, we can just use multipoint opening argument to ensure that some values of some polynomials in some cells are constrained to be public inputs.
As far as I understand, the FFlonK is also an extreme version of a similar idea, though I do not understand it well enough to judge yet.