ToolszkEVMArchitectureZkproverStark recursion

CIRCOM in zkProver

Although CIRCOM is mainly used to convert a STARK proof into its respective Arithmetic circuit, it is implemented in varied ways within the zkProver, specifical

Although CIRCOM is mainly used to convert a STARK proof into its respective Arithmetic circuit, it is implemented in varied ways within the zkProver, specifically during the STARK recursion process.

This document gives further elaboration on the Proving architecture by focusing on the CIRCOM Arithmetic circuits, while highlighting CIRCOM's pivotal role in the STARK Recursion process.

zkEVM batch prover

The first step in proving computational integrity starts with the zkEVM batch prover.

It is a circuit that proves correctness of the state transition from an oldStateRoot to a newStateRoot.

The zkEVM batch prover takes as inputs; the oldStateRoot, oldAccInputHash, oldBatchNum, chainID and forkID. And its outputs are; the newStateRoot, newAccInputHash, localExitRoot, and newBatchNum,

zkEVM Batch Prover

The localExitRoot is the Merkle root of the ExitTree used in the bridge to transfer information from the L2 to the Ethereum L1.

The oldBatchNum indicates which batch is being processed, and in each transition the numbering increments by 11, such that newBatchNum = oldBatchNum + 1.

All transactions being processed are encoded into the batch via the oldAccInputHash, read "old accumulated input hash".

Although built in a smart contract, the encoding of transactions resembles a blockchain, where transactions are chained together with the Keccak hash function. See figure below depicting this encoding.

Transactions chained into a batch

The main idea, when proving validity of a batch, is for the oldAccInputHash and its corresponding newAccInputHash to match accordingly.

The resultant STARK proof denoted by πbatch\mathtt{\pi_`{batch}`}, which involves 669669 committed polynomials each of degree 2232^{23}, is 1.91.9 Megabytes big.

Such a validity proof is not ideal in view of its storage cost in Ethereum.

The Polygon zkEVM's strategy to reducing the size of the ultimate validity proof is by implementing a recursive aggregation of many batch proofs into one.

CIRCOM circuits

As outlined in the Proving architecture subsection, the recursive aggregation of many STARK proofs (aimed at reducing the size of the validity proof) is accomplished in five stages;

  1. Compression stage using the c12a CIRCOM circuit,
  2. Normalization stage using the recursive1 prover\mathtt{recursive_1}\ \mathtt{prover} CIRCOM template,
  3. Aggregation stage using the recursive2 prover\mathtt{recursive_2}\ \mathtt{prover} CIRCOM template,
  4. Final stage using the recursivef prover\mathtt{recursive_f}\ \mathtt{prover} CIRCOM template,
  5. SNARK stage using the final prover\mathtt{final}\ \mathtt{prover} CIRCOM template.

In terms of code, the three CIRCOM templates used in the middle stages (Normalization stage, Aggregation stage and Final stage) are identical except for their public inputs which are; the root constants RootC and the respective input proofs.

As previously mentioned,

  • The recursive1 prover\mathtt{recursive_1}\ \mathtt{prover} only takes πc12a\mathtt{\pi_{\texttt{c12a}}}-type proofs as input,
  • The recursive2 prover\mathtt{recursive_2}\ \mathtt{prover} only takes any pair of πrec1\mathtt{\pi_{\texttt{rec1}}}-type or πrec2\mathtt{\pi_{\texttt{rec2}}}-type proofs as input,
  • The recursivef prover\mathtt{recursive_f}\ \mathtt{prover} only takes a pair of πrec2\mathtt{\pi_{\texttt{rec2}}}-type proofs as input.

Since the underlying proof scheme is PIL-STARK, there is a built-in Verifier\mathtt{Verifier} CIRCOM circuit in each of these prover circuits. Therefore, for any index x{1,2,f}\mathtt{x} \in \{1,2,f\}, the proof πx\mathtt{\pi_`{x}`} output by any of the recursivex provers\mathtt{recursive_x}\ \mathtt{provers}, is in fact a verified proof because PIL-STARK automatically verifies it.

A typical recursivex verifier\mathtt{recursive_x}\ \mathtt{verifier} CIRCOM template, for any x{1,2,f}\texttt{x} \in \{1, 2, f\}, looks like the circuit shown below.

Figure _ : Typical \mathtt{recursive_1}\ \mathtt{prover} CIRCOM template

Proof-size reductions

The below table displays 4:1\text{4}:\text{1} reduction in proof sizes as one progresses from one stage of the STARK recursion to the next.

The numbers presented below were first publicised by the Polygon zkEVM Technical Lead, Jordi Baylina, during the StarkWare Sessions held in February 2023. The video recording can be found here.

Parameter DescriptionzkEVM proverc12a proverrec1/rec2  proverrecf proverCommitted polynomials669121212Permutation checks18000Plookups29000Connection checks (copy constraints)2111Total number of columns1184654545Degree of polynomials (rows)n=223n=222n=220n=219Max degree of the constraint polynomial3n5n9n9nBlowup factor241616Proof computation time129 secs14 secs10 secs17 secsSize of the proof1.9 MB494 KB260 KB505 KB\begin{array}{|l|c|c|c|c|c|c|}\hline \bf{Parameter\ Description} & \texttt{zkEVM prover}& \texttt{c12a prover}& \mathtt{rec1 / rec2\ \ prover}& \texttt{recf prover} \\ \hline \texttt{Committed polynomials} & \texttt{669} & \texttt{12} & \texttt{12} & \texttt{12} \\ \hline \texttt{Permutation checks} & \texttt{18} & \texttt{0} & \texttt{0} & \texttt{0} \\ \hline \texttt{Plookups} & \texttt{29} & \texttt{0} & \texttt{0} & \texttt{0} \\ \hline \texttt{Connection checks (copy constraints)} & \texttt{2} & \texttt{1} & \texttt{1} & \texttt{1} \\ \hline \texttt{Total number of columns} & \texttt{1184} & \texttt{65} & \texttt{45} & \texttt{45} \\ \hline \texttt{Degree of polynomials (rows)} & \mathtt{n = 2^{23}} & \mathtt{n = 2^{22}} & \mathtt{n = 2^{20}} & \mathtt{n = 2^{19}} \\ \hline \texttt{Max degree of the constraint polynomial} & \texttt{3n} & \texttt{5n} & \texttt{9n} & \texttt{9n} \\ \hline \texttt{Blowup factor} & \texttt{2} & \texttt{4} & \texttt{16} & \texttt{16} \\ \hline \texttt{Proof computation time} & \texttt{129 secs} & \texttt{14 secs} & \texttt{10 secs} & \texttt{17 secs} \\ \hline \texttt{Size of the proof} & \texttt{1.9 MB} & \texttt{494 KB} & \approx \texttt{260 KB} & \approx \texttt{505 KB} \\ \hline \end{array}
Edit on GitHub

Last updated on