Proposal: The Turbo-PLONK program syntax for specifying SNARK programs
Last updated
Last updated
Recent zk-SNARK constructions such as Marlin and PLONK relying on Polynomial commitment schemes are not inherently tied to R1CS constraints to specify the statement to be proven. This is roughly because the verifier equation is checked "in the clear" on a random opening of the prover polynomials, rather than "in the exponent" using a pairing. We provide a framework to capture more general and flexible constraints which we call turbo-PLONK programs. We give an example of how this framework allows for more concise representation of fixed-base elliptic curve scalar multiplication (only 1 turbo-PLONK gate for each two input bits), a primitive useful for constructing Pedersen hashes. We also include benchmarks of proving time for scalar multiplication on the Grumkin curve (a 255 bit curve embedded over bn254). Our results indicate a 2x improvement over Groth16.
A turbo-PLONK program can be thought of as sequence of states , where the state size is chosen by the program designer. The proof size and prover run time increase linearly in and standard choices are 3 or 4.
A valid execution trace for satisfies 's transition gate and copy constraint.
transition gate - A transition constraint of is a -variate degree at most polynomial , where is the degree of , and is recommended to be set to , and is the selector number.
The transition gate of consists of all the transition constraints together with selector vectors . is said to satisfy the transition gate if for each transition constraint , .
copy constraint - this is a partition of into distinct sets . is said to satisfy the copy constraint if whenever and belong to the same set in the partition.
The copy constraint can be thought of as enabling memory access, since we can force a subsequent value in the execution trace to be equal to a preceding one.
Let's see how an arithmetic circuit can be represented in this format. Every row will correspond to a gate, and the row values will be the incoming and outgoing wire values of the gate; so to represent fan-in circuits we'll use . For example, for fan-in 2 the row values will correspond to the left,right and output wire values of the gate associated with the row.
The transition constraints will be somewhat "degenerate" in the sense that we won't use the "next row" values. They will check if the correct input and output relations hold inside the row according to whether it's an addition or multiplication gate. This can be done with 3 selectors and one constraint polynomial of degree . E.g., for fan-in 2 we use:
By setting for an addition gate and for a multiplication gate, we can see the above equation checks the correct input/output relation in both cases.
The copy constraint will enforce the wiring of the circuit. For example, if the left wire of the 4th gate is the output wire of the second gate, we will enforce .