PlonK Deconstructed 6: Round 1
Ben Bencik
Round 1
Finally, we can start with the first round of the prover algorithm where the prover computes wire polynomials and commits to them. But before that, we need to return to KZG and solve some of the problems we left unanswered. Specifically, we will show who generates evaluation challenges and how to hide the polynomial evaluations to get a zero-knowledge protocol.
Round overview:
Generate random blinding scalars
Compute wire polynomials
Compute and output commitments
Challenges
When describing KZG, we said the challenge is "somehow" given. In the interactive case, this value could be given by the verifier, but we aim for a non-interactive protocol. Transforming an interactive protocol to a non-interactive might be done by the Fiat-Shamir heuristic, which suggests that the prover computes all of the challenges by himself using a random oracle. This oracle could be a cryptographic hash function which takes variable-length input and gives fixed-length output. There is a formal definition of how this secure hash function should look, but we will not go into the details. The important properties are:
- the oracle is deterministic - it always returns the same results if given the same input values
- generated answers "look random" - outputs from the oracle should be indistinguishable from randomly generated sequences
When the prover needs to get a challenge, he will query the oracle with some input. In the case of PlonK, the input to will be the protocol transcript. Think of it as a summary of the protocol composed of:
- the common preprocessed input described in the previous post
- public input to the circuit
- polynomial commitments and openings computed by the prover so far
The random oracle is also accessible by the verifier. Since it is deterministic and the transcript is public, the verifier can reconstruct the challenges in the verification phase. The main idea is simple, but this heuristic has some security assumptions one should be aware of. Possible vulnerabilities of incorrect implementations are mentioned in Weak Fiat-Shamir Attacks on Modern Proof Systems.
How does the verifier know that the prover did not cheat in picking the challenge? (optional section)
Based on the protocol, the prover queries the random oracle to obtain challenges. But what is stopping him from picking a suitable challenge by himself? The verification phase of KZG essentially checks that:
However, if the prover tries to forge the proof and calculates the witness and evaluation using that was not determined by the random oracle we get:
The values are fixed because is determined by the generation of SRS and by the random oracle. That means we are checking the equality of two different polynomials evaluated at . From the post about math perliminaries we know that this check succeeds only with negligible probability. As result is it not possible to cheat the protocol because the verifier can retrieve the challenge from the random oracle check the validity of the polynomial opening.
PlonK diagram revisited
With all that we have explained, we can reiterate the diagram of the PlonK protocol and be more detailed. In each round of the prover algorithm, we will create polynomials from the ingredients we've already computed. Finally, the prover sends the proof , composed of polynomial commitments and polynomial evaluations at a challenge given by the random oracle. The verifier reconstructs the transcript to calculate the challenges. Thanks to the polynomial commitment scheme he can verify the validity of openings and finally perform the check described in the verification algorithm.
Blinding
So far, we have discussed vanilla KZG polynomial commitment scheme that is not zero-knowledge. Opening a committed polynomial at challenge a point naturally reveals information about the polynomial. We are aiming to make the protocol zero-knowledge, so absolutely no information could leak. We will alter KZG in a way that the prover can convince the verifier about the validity of the evaluation, but the verifier does not discover the actual evaluation. To achieve this, we will use blinding scalars (randomly sampled numbers with a fancy name) and a vanishing polynomial (a polynomial with a fancy name).
Vanishing polynomial
The vanishing polynomial is a polynomial with roots as all elements of the domain , meaning . Therefore the polynomial could be factored as . We set the evaluation domain to be generated by the primitive -th roots of unity . Given this fact, the vanishing polynomial could be compactly written as as showed in the previous post.
Blinding of the committed polynomial is achieved by introducing randomness. PlonK achieves this by mangling the former polynomial as follows:
The polynomials agree on all points of domain , because is 0 over the whole domain . So, we have randomized the polynomial, but made sure that the evaluation on remains the same.
Blinding scalars
Consider that a polynomial is opened at challenge points chosen by the oracle. The PlonK paper protocol suggests altering the committed polynomial with random blinding scalars as:
The number of blinding scalars should be at least the number of openings of plus 1. Now, does reveal some information about ? Well, it does because for . However, the challenges are chosen by the random oracle, which guarantees that they are chosen randomly. Since the size of the evaluation domain is small compared to the order of the field , the probability of picking a random element of is , which is considered to be negligible.
If the chosen challenges are not from then the polynomial is blidned and it is hard to extract the original polynomial from the blinded one. The proof of why this masking guarantees zero knowledge was not initially included in the PlonK paper. If you are interested in proof, take a look at section 4.2 of the PlonKup protocol.
Computing wire polynomials
We will use the notation for commitments to polynomials. Commitments will be polynomials evaluated at the secret (using SRS) and encoded as a point of an elliptic curve.
Round 1 essentially binds the prover to the witness by constructing polynomials from the computational table and committing to them. The vectors introduced in arithmetization represent the colums of the computational table. We represent each column as a wire polynomial by applying Lagrange interpolation and adding randomization in the form of blinding scalars. The blinding scalars are uniformly randomly and independently sampled by the prover.
After constructing these polynomials, the prover constructs commitments as specified in KZG.
We will continue with round 2 of the prover algorithm and show how to ensure that the copy constraints of an arithmetic circuit hold.
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