πͺ Session chair: Jan (Duties: Read material above-average carefully π€; prepare fallback discussions/questions (worst-case: just prepare some quiz questions about the material) π. Prepare a few slides to guide the session through subtopics (this is not supposed to be a detailed summary of the material)
βοΈ Notetaker: Akira (Duties: Take notes during the session, push them to the wiki afterwards π. Moderate to get input for the wiki pages π§ . Make people summarize / dumb down discussion results to keep things comprehensible for everyone π§ββοΈ.)
π― Goals
This session covers the KZG commitment and PLONKish PolyIOP. We will particularly focus on the following contents from Lecture 5 (see π Material).
-
The KZG polynomial commitment scheme
- Efficiency: commitment size, proof size, proving time, verification time
- Compiling the equality check IOP with KZG
- Security will be covered in the next session
-
Simple-PLONK PolyIOP
- Gadgets for univariate polynomials: ZeroTest, SumCheck, ProdCheck, (Prescribed) Permutation Check (cf. Univariate Poly Tricks)
- PLONKβs arithmetization
β Quiz Questions
KZG
- Why does have to be discarded? How would you break the binding property using ?
- What does the Lagrange βselectorβ polynomial do?
- Can you safely publish both the βnormalβ KZG pp and the βLagrangeβ KZG pp at the same time?
- If proofs are so much shorter, why donβt we just use KZG as a vector commitment everywhere instead of Merkle trees?
Polynomial gadgets
- Whatβs the advantage of using the subgroup as a set for the ZeroTest/ProdCheck?
- Can we do an efficient ZeroTest/ProdCheck on arbitrary subsets? Or do we crucially need the subgroup properties?
- What is the role of the second polynomial variable () in the prescribed permutation check?
Arithmetization
- does the prover actually have to run FFT to compute the coefficients of the computation trace polynomial?
- how many polynomials does the IOP prover commit to? How many are computed by the verifier? How many can be computed during preprocessing?
π Material
π Notes
Subsession 1-3 (July 13, 20, 27)
Overview of KZG Polynomial Commietment
- To support polynomials of degree at most as input, of KZG must be run by a trusted party who makes sure to βforgetβ the secret exponent . Revealing is devastating in many ways. For example, it is easy to break evaluation binding with the knowledge of :
- Given , generate a commitment
- Upon receiving an evaluation point , pick an arbitrary fake statement . Generate a fake opening proof . Such always gets accepted by a verifier.
- With known , one can generate arbitrary power of tau , which also allows to break the maximum degree bound of supported polynomials.
- To verify KZG opening proof, the verifer does not need to know the entire SRS---only is sufficient. This is because the verification equation is simply .
- Some times, the input polynomial is represented in point-value form rather than a vector of coefficients. In that case, it is more convenient to turn the SRS into Lagrange form . Then the committing operation only takes linear time in , instead of spent on NTT to move to the coefficient representation.
- Feist-Khovratovich algorithm for fast multi-point proof generation
- To generate KZG proofs for opening proofs in such that , a naive method requires time if .
- The FK algorithm can speed it up to achieve , taking advantage of NTT!
Commit-and-Prove IOP gadgets
Zero Test on :
- The vanishing polynomial of of size is . By choosing where is a primitive -th root of unity, the vanishing polynomial splits completely in . This form is easy to deal with, because evaluation of of is simple double-and-add and only takes field multiplications.
- Compiled ZeroTest on can be slightly optimized using KZG. That is, the prover directly computes as amortized opening proofs for . The verifier can check
Product Check on :
- Core idea: (1) Construct a degree- polynomial which encodes βthe -th parttial product of β (i.e. ) at for , and (2) invoke Zero Test on for the polynomial .
- Q. How many queries does the verifier make? - 5
- at
- at
- at , , and
Permutation Check: for some permutation
- Q. To prove is a permutation of , why canβt we just rely on the equality check for and ?
- A. Without Product Check, the verifier cannot (efficiently) check that are correctly constructed from
- Q. Why 6 queries?
- at
- at
- at
- at , , and
Prescribed Permutation Check:
- Naive approach (i.e. invoking Zero Test on ) is still okay for constructing SNARK in theory.
- Linear time prover is usually not a requirement for SNARK. We only care about the verification time and proof size.
Simple-PLONK
-
Remark: The original PLONK construction encodes left, right, output wires separately into polynomials , respectively. The present construction simplifies it by combining them in a single of degree .
-
The selector polynomial only encodes binary info, but if we need more gate types than just addition and multiplication, we can generalize in a straightforward manner.
-
We can construct PolyIOP for PLONK constraint systems by taking advantage of the above commit-and-prove gadgets:
- Input Check:
- Gate-by-Gate Check:
- Wiring Check:
-
Q. Why the soundness error ?
- A. In Gate-by-Gate Check (realized by Zero Check on the polynomial F(X)), the prover sends which has degree at most because:
- ;
- ;
- ;
- assuming ;
- and therefore,
- A. In Gate-by-Gate Check (realized by Zero Check on the polynomial F(X)), the prover sends which has degree at most because:
-
Q. On page 53, why and are βuntrustedβ?
- A. Anyone can publicly check that and are correctly constructed from the circuit constraints (in the offline phase). No need to rely on any trusted third party generating them correctly.