articleJul 6, 2025
Exploring PlonK
Prover-side walkthrough of PlonK: gate and wiring constraints, polynomial compilation, the five proof rounds, and how the verifier checks the batched opening.

Exploring PlonK
Review of PlonK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge
This note walks through the core of the PlonK protocol—specifically, the five logical rounds in which the Prover generates a proof, and the steps from a given arithmetic circuit and witness to the final proof generation, all from the Prover's perspective.
Seeing the rounds end-to-end makes clearer why each PlonK piece exists and how completeness and soundness hang together.
Before the round-by-round walkthrough, I define the two fundamental challenges that the Prover must address and examine the strategies PlonK employs to solve them. This conceptual foundation will be essential for understanding the technical flow of the five rounds that follow.
1. What Must Be Proven?
The Prover's task is to prove that they have performed some computation to obtain a specific public output , using a secret input in the process (i.e., ), without revealing . To achieve this abstract goal, we first express the computational process as an arithmetic circuit.
Proving the validity of this circuit specifically means demonstrating that the following two core constraints are both satisfied.
Start with the arithmetic circuit. The diagram shows a simple example of the calculation (x * y) + x = z expressed as a circuit.
Loading diagram…Two prover jobs fall out of that picture.
The circuit has two arithmetic gates. Gate 1 performs multiplication, while Gate 2 performs addition.
Data flows between these gates through what we call wires. Here, w1 through w5 are the wires, each carrying values like x and y.
For example, the values in w1 and w2—namely x and y—enter Gate 1 and are multiplied. The result x*y is then stored in wire w3.
This value enters Gate 2, where it's added to the x value from w4, producing the final result z in w5.
1.1. Gate Constraints
An arithmetic circuit consists of multiple arithmetic gates, and PlonK enables the representation of all gates within the circuit through a single unified equation:
- : Values of the gate's left and right input wires
- : Value of the gate's output wire
- : Selector values that define the type of gate (left input, right input, output term, multiplication term, constant term, etc.)
Let's look at Gate 1. This is a multiplication gate. PlonK expresses all types of gates through a single unified equation.
For multiplication, qM, the switch that turns on the multiplication term, is set to 1, and qO, the switch that flips the sign of the output term, is set to -1.
All other switches are turned off to 0.
Then the originally complex unified equation transforms into the simple multiplication formula you see: a1 * b1 - c1 = 0, which is a1 * b1 = c1.
In other words, the Prover must prove that multiplying Gate 1's input values truly equals the output value.
Gate 2 is an addition gate. This time qL and qR are set to 1, qO is set to -1, and substituting these gives us the addition formula a2 + b2 = c2.
The Prover must also prove that this equation holds.
For each gate, the Prover must show that all such 'gate equations' are true. This is precisely the step that ensures computational correctness.
1.2. Connection Constraints (Wiring/Copy Constraints)
Verifying that individual gate operations are correct is not sufficient—we must also ensure that the output value of one gate is accurately transmitted as the input value to the next gate. For example, if the output wire of gate 1 connects to the input wire of gate 2, we must guarantee the Connection constraint that the equation holds. Additionally, we must ensure the Copy constraint where wires and that should contain the same value satisfy the equation .
Consequently, the Prover's second challenge is to prove that all these wires are correctly connected according to the circuit's design and that values have been accurately copied. This ensures the correctness of the computational 'flow'.
These two constraints—computational correctness at every gate and connection integrity between all wires—constitute the concrete problem the Prover faces. In the next section, we will explore PlonK's strategy for efficiently transforming these numerous constraints into manageable mathematical structures.
2. Compiling Constraints into the Language of Polynomials
Checking every gate and wire constraint one by one does not scale. PlonK's core approach is to transform all these discrete constraints into continuous mathematical objects—namely, relationships between polynomials. Through this 'compilation' process, we can solve complex problems using the powerful tools of algebra.
PlonK's strategy can be viewed as the following two transformation processes:
2.1. Polynomial Representation of Wires
All wire values in the circuit have a specific ordering. PlonK considers these wire values as evaluations at specific points according to this ordering, and interpolates them to generate three polynomials:
- : A polynomial encoding all left input wire values of the gates
- : A polynomial encoding all right input wire values of the gates
- : A polynomial encoding all output wire values of the gates
For example, is constructed to have the left input value of the -th gate at the specific point . Through this process, we can view the entire state of the circuit as being compressed into three concise polynomials.
2.2. Permutation Argument for Wiring
The most unique aspect is how copy constraints are handled. Instead of direct equations like "the value of wire A equals the value of wire B," PlonK adopts the following perspective:
The diagram below illustrates the permutation concept, showing how a set of wire values undergoes permutation to become , with only their positions changed.
Loading diagram…"Wire values throughout the entire circuit merely exchange positions with each other; no new values are created or destroyed."
This means that a specific permutation relationship exists between wire indices in the circuit, and when values are moved according to this permutation, they must remain unchanged. The Prover's task transforms into defining a single permutation that satisfies these complex connection relationships and proving that their constructed wire polynomials respect this permutation . This proof is handled through an efficient technique called the "Grand Product Argument" using just one additional polynomial .
After that compilation step, the Prover's job is no longer a pile of discrete checks. They must prove that the polynomials they have constructed (, etc.) satisfy specific polynomial identities.
In the following sections, we will step through the five concrete rounds that the Prover performs to achieve this goal.
3. Prover: 5-Step Proof Generation Process
The Prover builds the final proof in five rounds. Each round involves responding to challenges received from the Verifier (or through the Fiat-Shamir Heuristic) and constructing the necessary proof components for the subsequent rounds.
Round 1: Wire Polynomial Construction and Commitment
Loading diagram…The Prover begins by transforming all known wire values (witness) into a mathematically tractable form. The goal of this phase is to compress the circuit's entire execution state into three polynomials and secretly commit to them before the Verifier.
Procedure
Using the circuit's wire values corresponding to left inputs, right inputs, and outputs, the Prover constructs the following three wire polynomials :
-
- This component forms the polynomial's core content. The Lagrange basis polynomial has the property of being 1 at the -th point of the multiplicative subgroup and 0 at all other points in . Thanks to this property, takes exactly the values in order at each point of . This is the process of encoding wire values as polynomial evaluations.
-
(Blinding)
- This term serves as a blinding factor to ensure zero-knowledge. The values are random scalars known only to the Prover, and the vanishing polynomial equals zero at all points in where constraints will be checked. Therefore, this term randomizes the polynomial values outside without affecting constraint verification on , preventing the Prover's secret wire values from being exposed through other polynomial evaluations.
Why This Design?
This phase serves two purposes. First, it represents the circuit's extensive wire values as three concise mathematical objects (polynomials), facilitating subsequent algebraic manipulations. Second, through a polynomial commitment scheme, the Prover commits to these values so they cannot be changed later, while simultaneously preventing information leakage through blinding.
Output: Components of the Complete Proof
The Prover performs KZG commitments on each of these three constructed polynomials, computing three group elements . This constitutes the first piece of evidence the Prover generates and forms the foundation for all subsequent processes. With this, the Prover has effectively declared: "I will now make claims about these three polynomials, and I absolutely will not change their contents."
Round 2: Permutation constraints Proof and Commitment
While Round 1 represented the circuit's state as polynomials, Round 2 proves that the wiring between these states are correct. The goal of this phase is to compress numerous individual copy constraints into a single polynomial relationship, demonstrating that the circuit's wires have been implemented according to design.
Loading diagram…Procedure
Using the polynomials generated in Round 1 and the circuit's permutation information , the Prover constructs the grand product polynomial . This polynomial is constructed using random challenges and generated through the Fiat-Shamir Heuristic.
must satisfy the following recursive relationship at all points in :
- Initial condition:
- Recursive relation:
Here we use to denote the identity permutation for clarity.
The core idea of this recursive relation is as follows:
-
Numerator : Terms that combine each wire value with its 'original position' information. are identity permutation polynomials representing the original position indices of the wires respectively.
-
Denominator : Terms that combine each wire value with its 'post-permutation position' information. are polynomials encoding the actual permutation , representing the position indices after wire values have been connected and moved.
-
, : These random challenges prevent the Prover from cheating on the permutation relationship and strongly bind each wire value to its position information.
The following shows the decomposition by type for better understanding—this is the method for constructing the unique polynomial that simultaneously satisfies both rules above:
(Here and refer to the polynomials corresponding to the numerator and denominator of the recursive relation above.)
The Prover actually constructs the polynomial satisfying these conditions using the Lagrange basis. This structure ensures that when elements of are substituted for , takes exactly the step-by-step results of the cumulative product. It also includes a blinding term for zero-knowledge.
If the wire connections are correct (i.e., the permutation relationship holds), the set of values composing the numerator and the set composing the denominator will be exactly identical, differing only in order. Consequently, the cumulative product starts at and ultimately returns to . The polynomial encodes precisely this cumulative product process.
What happens if all wire connections are correct?
The complete set of values in the numerator and the complete set of values in the denominator are exactly identical, differing only in order. For example, if the numerator contains (value A, value B, value C), then the denominator contains something like (value C, value A, value B)—the same values just rearranged. Therefore, as we continue multiplying these fractions, all terms eventually cancel each other out.
The Prover sets the start of this cumulative product as z(1) = 1.
If even a single connection is incorrect, the balance of this cumulative product breaks and the final value cannot equal 1.
Why This Design?
The purpose of this phase is to transform the circuit's most complex and unwieldy aspect—the connection constraints—into a single algebraically verifiable object . Instead of verifying millions of individual equality constraints , we now only need to check whether a single polynomial follows specific rules (starting and ending at 1, satisfying the recursive relation). This is a key idea for reducing the protocol's complexity.
Output: Components of the Complete Proof
The Prover performs a KZG commitment on the constructed permutation polynomial , computing the group element . This constitutes the Prover's second piece of evidence. The Prover has now cryptographically committed to the claim: "The wire values I presented in Round 1 satisfy all permutation relationships specified in the circuit's wiring."
Round 3: Compressing All Constraints and the Quotient Polynomial
In the previous two rounds, the Prover represented and committed to the circuit's state () and wiring relationships () as polynomials. The goal of Round 3 is to compress into a single concise proof that all these polynomials actually comply with all of PlonK's rules.
Loading diagram…Procedure
The Prover receives a new random challenge through the Fiat-Shamir Heuristic. Using this , they combine all circuit constraints into a single polynomial and divide it by the vanishing polynomial . The result is the quotient polynomial .
The core equation representing this relationship is:
Breaking this equation down by parts:
-
First Part (Gate Constraints): This is PlonK's gate equation. If all computations were performed correctly at every gate, this polynomial should equal zero at all points in . is the term handling public inputs, which includes adding the constant term .
-
Second and Third Parts (Permutation Constraints): This section transforms the recursive relation from Round 2, , into the form .
- Part 2a: Corresponds to the product of the permutation argument's numerator and . Here, are identity permutation polynomials encoding the 'original positions' of the wires respectively.
- Part 2b: Corresponds to the product of the permutation argument's denominator and . Here, are the actual permutation polynomials encoding the 'post-movement positions' of the wires.
- multiplies the entire permutation constraint (Part 2a - Part 2b) with random weight to separate it from the gate constraints (Part 1), and this equation must hold over .
-
Third Part (Permutation Start Constraint): This enforces the constraint that starts at 1 (). Since equals 1 only at and 0 at all other points in , this term extends the constraint across all of .
-
, (Random Weights): These random weights safely bind different types of constraints (gates, permutation rules, permutation start) into a single polynomial. Without , different constraints might accidentally cancel each other out, creating opportunities for the Prover to cheat. To prevent this, each constraint is assigned an independent weight.
If we simply add without α, a malicious Prover could cleverly manipulate different constraints so that, for example, the 'gate constraint' deviates by +5 while the 'permutation constraint' deviates by -5, making the sum coincidentally equal to zero through trickery. The random value α serves as a firewall that makes such 'accidental cancellations' impossible. Until the Verifier reveals α, it becomes impossible to design such deceptions.
Why This Design?
The key idea of this phase is to transform the complex problem of "simultaneous satisfaction of numerous constraints" into the single problem of "one polynomial divides another polynomial."
If the Prover has honestly followed all rules, the combined polynomial constructed above will equal zero at all points in , and therefore must divide perfectly by the vanishing polynomial . As a result, the quotient becomes a clean polynomial. If even one rule is violated, the division produces a remainder, causing to become a rational expression rather than a polynomial, which would cause the subsequent commitment process to fail.
In conclusion, the Prover's successful presentation of the 'quotient polynomial' itself serves as strong evidence that all previous constraints have been satisfied.
Output: Components of the Complete Proof
Since the quotient polynomial typically has very high degree, the Prover splits it into three lower-degree polynomials . They then perform KZG commitments on each of these three pieces, computing the group elements . This constitutes the Prover's third piece of evidence. The Prover has now effectively claimed: "All the polynomials I have presented satisfy all of PlonK's game rules."
Round 4: Polynomial Evaluation at Random Points
Up to this point, the Prover has formulated their claims as multiple polynomials () and cryptographically committed to them. The Verifier must verify that these polynomials satisfy specific identities, but cannot receive and check the entire polynomials. To solve this problem, PlonK leverages the Schwartz-Zippel Lemma (If two different curves (polynomials) exist, the probability that these two curves meet at a randomly chosen point is nearly zero (Negligible function)... Therefore, instead of comparing entire polynomials, the concept is that it's sufficient to randomly select one point and check whether the values are equal only at that checkpoint).
That is, instead of checking the entire identity, we only verify whether the equation holds at one randomly selected point.
The goal of Round 4 is to compute and reveal all necessary polynomial evaluations at this random point.
Loading diagram…Procedure
The Prover generates a new random challenge from all previous information through the Fiat-Shamir Heuristic. This is the random evaluation point at which all polynomials will be evaluated.
The Prover evaluates their polynomials at and its "neighbor" point , computing the following values:
These values will serve as the ingredients for the Verifier to directly construct the final identity in the subsequent verification phase.
Why This Design?
This phase achieves the proof's succinctness. Instead of sending entire polynomials that could have millions of coefficients, the Prover only needs to reveal a few numbers—the evaluations at specific points.
According to the Schwartz-Zippel Lemma, if two different polynomials exist, the probability that they coincidentally have the same value at a randomly chosen point is negligibly small. Therefore, by confirming that all constraints hold at the single point , the Verifier can be confident with very high probability that the original polynomial identities themselves are correct. The evaluation at is necessary because the permutation constraint identity from Round 3 includes the relationship between and .
Output: Components of the Complete Proof
The Prover reveals the set of all computed evaluation values . These values are plain field elements, neither encrypted nor committed. This constitutes the Prover's fourth bundle of evidence, providing public information that enables the Verifier to directly compute the final verification equation. The remaining round will prove that these revealed values are indeed the genuine evaluations of the polynomials committed to in Rounds 1-3.
Round 5: Constructing the Batched Opening Proof
In Round 4, the Prover revealed evaluation values for multiple polynomials. However, the Verifier still cannot know whether these values are actual evaluations of the polynomials committed to in Rounds 1-3. The goal of Round 5 is to batch all these evaluation claims into a single efficient proof, ultimately demonstrating the validity of the revealed values.
Loading diagram…Procedure
The Prover generates two new random challenges, and , through the Fiat-Shamir Heuristic. serves to batch evaluations at the same point (), while batches evaluations at different points ( and ).
Using these challenges, the Prover constructs two opening proof polynomials, and :
1. Batched opening proof at point , :
(Part separation):
2. Opening proof at point , :
- (Part 1) Linearization polynomial : This polynomial is the result of "linearizing" the complex identity related to from Round 3 with respect to . That is, it treats the evaluation values at () as constants. verifies consistency between the committed in Round 3 and the evaluation values revealed in Round 4.
- (Part 2) Terms batched with : This combines all evaluation claims at point , such as , , etc., into a single polynomial using powers of the random weight .
- Division by : If all claims are true, the polynomial inside the parentheses should equal zero when . Therefore, it divides perfectly by , and the quotient is precisely .
Why This Design?
This phase maximizes the protocol's efficiency by leveraging batching techniques for KZG polynomial commitments. Instead of opening individual evaluation claims one by one, the random challenges and transform all claims into a single polynomial identity problem.
As a result, the Verifier can verify all of the Prover's claims at once with just one final pairing equation, without needing to perform multiple expensive pairing operations. This makes the Verifier's computation constant regardless of the number of claims, enabling PlonK's fast verification speed—a crucial optimization technique.
Output: Components of the Complete Proof
The Prover finally performs KZG commitments on the two opening proof polynomials and , computing the group elements and . These constitute the Prover's final pieces of evidence.
Now, gathering all components generated from Rounds 1 through 5 (commitments, evaluation values, opening proofs), the final proof is complete and transmitted to the Verifier.
4. Verifier: Single-Pass Verification
The final proof generated by the Prover consists of a batched structure containing multiple commitments, evaluation values, and opening proofs. The Verifier's task is to use this proof to verify that the Prover actually performed valid computations—without the Prover's secret information (witness) and in a highly efficient manner.
The PlonK Verifier does not trace back through the Prover's process. Instead, it constructs a single final equation that can verify everything at once, and simply checks whether this equation holds.
Procedure
The Verifier receives the proof and public inputs , and performs verification through the following steps:
1. Proof Validity Check and Challenge Recovery
- Verifies that the group elements and field elements contained in the received are in the correct format.
- Using the same method as the Prover, sequentially hashes the public information and each part of the proof to recover all random challenges .
2. Vanishing and Lagrange Polynomial Evaluation
- Evaluates the vanishing polynomial at : .
- Evaluates the first Lagrange polynomial at : .
- Evaluates the public input polynomial at : .
3. Computing the Linearization Polynomial Evaluation
- Instead of constructing directly, computes its evaluation value directly:
(This term is used in computing the constant term ) (This part is replaced by computation) (Actually processed in commitment form)
- The Verifier separates into constant term and non-constant term for efficiency, computing the constant term separately...
4. Constructing Batched Polynomial Commitments
- The Verifier batches all polynomials opened by the Prover in Round 5 into a single commitment. This process compresses multiple opening verifications into one:
- : Commitment combining the non-constant part of and with challenge .
- : Final combined commitment batching together with all polynomial commitments evaluated at using challenge .
5. Constructing Batched Evaluation Values
- Similarly, all evaluation values are batched into a single field element:
6. Final Pairing Equation Verification
- Finally, the Verifier combines everything to check a single pairing equation. This equation verifies that the batched KZG opening proof is valid:
Why This Design?
The entire Verifier process is focused on efficiency:
- Succinctness: The Verifier performs no operations proportional to the circuit size
n. All computations depend only on the proof size, which is near-constant time. - Non-interactive: Verification can be completed using only the submitted proof, without needing to interact with the Prover.
- Batching: Multiple KZG opening proofs are compressed and verified with just two pairing operations. This is the key optimization enabling PlonK's fast verification speed.
If this final pairing equation holds, the Verifier can be confident with very high probability that all claims submitted by the Prover (gate constraints, permutation constraints, validity of evaluation values) are correct. If even a single value has been tampered with, the balance of this carefully designed equation will be broken. Thus, the Verifier can trust the validity of the computation without knowing any of the Prover's secret information.
5. References
Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge