Plonkish Arithmetization in zk-SNARKs

• Plonkish arithmetization is a circuit representation technique that encodes computations as a table of field elements using custom low-degree gates.
• It reduces constraint counts dramatically compared to traditional R1CS by using selector and ROM-based dispatch for efficient opcode implementation.
• Widely adopted in zkEVM systems, it enhances proving efficiency and supports cryptographic primitives like ArionHash, achieving sub-minute proofs and low overhead.

Plonkish arithmetization is a circuit representation methodology central to modern zero-knowledge proof systems, notably those based on polynomial commitments such as PLONK and its descendants. It encodes computations as tables of field elements where local, low-degree algebraic relations—custom gates—are conditionally activated by selectors, enabling efficient, modular constraint encoding for complex protocols such as zkEVMs, hash functions, and proof-agnostic circuit compilers. Plonkish techniques offer explicit advantages in constraint minimization, modular gate design, and flexibility in opcode dispatch over traditional R1CS and monolithic AIR approaches.

1. Formal Structure and Gate Semantics

Plonkish arithmetization represents computation as a row-column table $T$ of size $n \times k$, where each row indexes a local computational step and each column corresponds to a register, wire, opcode, or memory slot. Constraints are enforced row-wise by activating a small family of fixed-degree "gate polynomials" $G_\ell(T(i),T(i+1))$. The activation is controlled either via dedicated selector polynomials $s_\ell(i)$ or by sparse polynomials keyed to the opcode value.

A canonical 3-wire Plonkish gate takes the form:

$$q_L \cdot l + q_R \cdot r + q_O \cdot o + q_M \cdot (l \cdot r) + q_C = 0$$

where $l, r, o$ are wire values from the trace and $q_*$ are selector polynomials specific to each gate instance. Four-wire and higher gates generalize this by encoding higher-degree relations or additional wires. In formal terms, a Plonkish constraint system is a collection of such constrained vector identities, with wire indices referencing the global trace and selectors typically supporting constant or row-specific nonzero values (Stronati et al., 20 May 2024).

The trace table is committed as arrays of degree-$(n-1)$ polynomials over the base field, and SNARKs such as PLONK use succinct opening proofs (e.g., KZG commitments) to ensure soundness.

2. Custom Gates: EVM Opcodes and Algebraic Primitives

The expressiveness of Plonkish arithmetization is exemplified by its use of custom gates for individual EVM opcodes or cryptographic primitives:

• Simple arithmetic gate: For EVM addition, a single degree-2 gate suffices:

$s_+(i) \cdot (a_i + b_i - c_i) = 0$

where $s_+(i)$ is 1 exactly when the opcode in row $i$ is ADD.

• Branching control flow gate: For the JUMPI opcode:

$$s_J(i) \cdot [(1 - \mathrm{cond}_i) \cdot (pc_{i+1} - pc_i - 1) + \mathrm{cond}_i \cdot (pc_{i+1} - tgt_i)] = 0$$

A degree-3 constraint captures all conditional logic in one row, avoiding unrolling all possible branches (Hassanzadeh-Nazarabadi et al., 6 Oct 2025).

Complex cryptographic primitives (e.g., SHA3, advanced hash functions) are encoded via custom gates that bundle multi-stage bit operations, S-boxes, and affine layers into a constant number of constraints per operation. For example, modern hash functions such as ArionHash leverage Plonk-friendliness by polynomially rewriting high-degree exponents into equivalent low-degree forms (via CCZ-equivalence), minimizing the gate and constraint count. In ArionHash with $n=4$, the total Plonk custom gates (2-wire | 3-wire) are (276 | 211), whereas comparable primitives like Poseidon require more than 1,300 gates (Roy et al., 2023).

3. Constraint Count Minimization and Proving Efficiency

A primary advantage of Plonkish arithmetization is the compression of logic into few, low-degree constraints. In legacy R1CS, multi-word arithmetic and byte decomposition dramatically inflate constraint counts—for instance, 256-bit addition costs ~250 R1CS constraints, SHA3 can require 150,000. In contrast, Plonkish’s custom gates often replace hundreds or thousands of R1CS constraints with $O(1)$ degree-2/3 constraints per operation.

This reduction translates nearly linearly into lower proving times and memory usage, as the overall SNARK prover time is dominated by the number of enforced constraints and the resources spent opening polynomial commitments. Empirical results in zkEVMs show a reduction from $>2^{24}$ ($\sim$16M) constraints and hours-long proofs for R1CS-style circuits to as low as $2^{20}$—$2^{24}$ constraints and sub-minute proofs (e.g., 40--80s for 8M constraints on commodity hardware), producing $\sim$1 KB proofs verifiable within 200–400 thousand gas (Hassanzadeh-Nazarabadi et al., 6 Oct 2025).

Arithmetization-aware hash designs, as in ArionHash, exhibit similarly pronounced savings, with Merkle trees of height 32 taking $\sim$2s in Plonk versus $>4$s in Poseidon-based Plonk circuits (Roy et al., 2023).

4. Dispatch and Activation Mechanisms: Selector-Based vs. ROM-Based

Plonkish gates are conditionally activated per row by one of two principal mechanisms:

• Selector-based dispatch: A dedicated selector column $s_\ell$ is assigned per active gate. At each row, only the gate with $s_\ell(i)=1$ enforces its constraint; other gates remain inactive. While this provides fine-grained control, it inflates the overall table width (e.g., $k$ increases substantially with $m$ gates), leading to extra interpolation/prover costs.
• ROM-based (sparse) dispatch: Uses a read-only memory table for code. The program counter column $PC(i)$ selects the opcode for each step via a lookup. A single sparse polynomial $G_\text{sparsity}$ then encodes all gate logic, often reducing hundreds of selectors to one. This approach limits trace width and overhead, with a small cost for each memory lookup per row, which is typically dominated by the saving in selector columns (Hassanzadeh-Nazarabadi et al., 6 Oct 2025).

Only executed control-flow paths appear in the trace; unused code and inactive branches are not trace/proved, improving efficiency in highly dynamic workloads.

5. Practical Deployment in zkEVMs and Cryptographic Protocols

Plonkish arithmetization is now the standard in production zkEVMs, including projects such as Polygon zkEVM, Scroll, Taiko, Linea, and zkSync Era, for its ability to encode EVM’s diverse opcode set compactly and efficiently (Hassanzadeh-Nazarabadi et al., 6 Oct 2025). The approach has also become prevalent in arithmetization-aware cryptographic primitives—for example, ArionHash, Griffin, and Anemoi—engineered for minimal Plonk gate complexity.

In modern zkEVM systems, a typical 256-bit operation is enforced by a single degree-2 constraint, and full EVM batch constraints are in the low millions, with prover throughput reaching 1–2M constraints/sec on multicore hardware. Proofs are sub-kilobyte, and on-chain verification is cost-effective. Official benchmarks comparing ArionHash to Poseidon and similar hash constructions in Plonk circuits demonstrate significant gains in proof generation times and gate/resource usage (Roy et al., 2023).

6. Comparison: R1CS, Plonkish, and AIR

Plonkish arithmetization occupies a middle ground between R1CS and AIR (Algebraic Intermediate Representation). The following table summarizes key features:

Feature	R1CS	Plonkish	AIR (e.g., Cairo/Miden)
Constraint form	Bilinear products	Row-wise low-degree gates	High-degree global transition
Opcode dispatch	Inlined everywhere	Selector or ROM	Algebraic, $(opcode-OP)^{p-1}$
Bit/byte ops	Bit decomposition, $O(1)$ constraints per step	Lookup/table per row	High-degree vanishing polys
Control flow	Branch unrolling	Selector/ROM-driven	Monolithic transition
Recursion	No native support	Verifier in-circuit only	Native recursion via FRI
zkEVM usage	Impractical	Mainstream (Polygon, etc.)	Not used for EVM

Plonkish achieves modularity and succinctness by allowing per-row conditional activation with low-degree gates, unlike AIR, whose monolithic transition logic is mismatched to VM opcodes, and unlike R1CS, whose fine-grained bilinearization causes constraint blowup (Hassanzadeh-Nazarabadi et al., 6 Oct 2025).

7. Circuit Construction, DSLs, and Optimization

High-level embedded DSLs such as Clap provide a semantic-preserving, proof-system-agnostic pipeline for authoring, optimizing, and compiling Plonkish circuits (Stronati et al., 20 May 2024). Clap’s compilation flow starts with a shallow-embedded Rust DSL mapping circuit code to abstract circuits, which are then symbolically optimized (e.g., by gate merging, Boolean simplification, and inlining). Each circuit is compiled to a concrete Plonkish constraint system (list of per-row vector identities), with tabulation and selector scheme abstracted to support multiple proof-system variants.

Soundness and completeness theorems are established between witness generation and constraint construction: any executable trace is guaranteed to satisfy the derived constraint system (completeness), and any satisfactory constraint assignment can be extended to a valid trace (soundness), modulo auxiliary wire conventions. This ensures that automatic optimizations in circuit synthesis do not introduce under- or over-constraining bugs—critical for safety at scale.

In summary, Plonkish arithmetization delivers both proven efficiency and explicit semantic structure, enabling performant, modular, and formally robust zero-knowledge circuit development and deployment across both VM emulation and cryptographic primitive design (Hassanzadeh-Nazarabadi et al., 6 Oct 2025, Roy et al., 2023, Stronati et al., 20 May 2024).