zkPHIRE: Custom Accelerator for Zero-Knowledge Proofs

• zkPHIRE is a programmable accelerator that leverages a flexible SumCheck engine to support high-degree custom gates, reducing gate counts by up to 30× on real workloads.
• It integrates specialized units like the programmable SumCheck Unit, Multifunction Forest, and MSM engine to efficiently perform polynomial evaluations and MLE extensions in a 7nm design.
• The design achieves up to 1486× speedup over CPU implementations while scaling to 2^30 constraints and enabling versatile support for modern zkSNARK protocols.

Searching arXiv for the named paper and closely related work to ground the article in current literature. arxiv_search query: "(Daftardar et al., 22 Aug 2025) zkPHIRE" zkPHIRE is a programmable accelerator for zero-knowledge proofs over high-degree, expressive gates, designed around the SumCheck protocol and integrated into a full-system HyperPlonk prover. It addresses a specific limitation of prior SumCheck hardware: earlier accelerators were fixed-function and targeted only a small “vanilla” set of low-degree gates, whereas recent languages and protocols such as Halo2 and HyperPlonk expose custom, high-degree gates that can reduce gate count by $10\times$–$30\times$ on real workloads. In the reported implementation, zkPHIRE is a 294 mm$^2$, TSMC 7 nm design running at 1 GHz; it scales to problem sizes of $2^{30}$ nominal constraints, maintains small proof sizes with proofs smaller than 5 kB, and achieves $1486\times$ geomean speedup over CPU and $11.87\times$ speedup over the state of the art at iso-area (Daftardar et al., 22 Aug 2025).

1. Problem setting and motivation

Zero-knowledge proofs enable one party to convince another of a statement’s validity without revealing anything else. The paper situates this capability in machine learning, blockchain, image authentication, and electronic voting, while emphasizing that deployment has been limited by exceptionally high computational overhead during proof generation (Daftardar et al., 22 Aug 2025).

The central problem addressed by zkPHIRE is the interaction between modern custom-gate ZK systems and the SumCheck protocol. In SumCheck-based zkSNARKs, each gate’s arithmetic constraint is encoded into a polynomial $f(X_1,\ldots,X_\mu)$ over a finite field $\mathbb{F}$, and the prover must show that

$\sum_{X\in\{0,1\}^{\mu}} f(X)=0.$

Recent systems permit gates whose polynomial structure is substantially more expressive than the low-degree patterns assumed by fixed-function accelerators. The paper gives the example

$$f = q_1\cdot w_1 + q_2\cdot w_2 + q_{H1}\cdot w_1^5 + q_{H2}\cdot w_2^5 + \ldots$$

and states that such high-degree custom gates reduce gate count by $30\times$0–$30\times$1 on real workloads. However, supporting these polynomials with fixed-function SumCheck hardware either leads to massive over-provisioning, which wastes area, or to outright failure to implement the gate.

The architectural consequence is that SumCheck becomes both a performance bottleneck and a design bottleneck. Each term of $30\times$2 may be a product of $30\times$3 different witness polynomials $30\times$4. Each such polynomial must be extended from its 2-element MLE table, given by values at $30\times$5, to all $30\times$6 points $30\times$7, then multiplied and accumulated. The dataflow is therefore irregular, bandwidth-intensive, and gate-dependent. zkPHIRE is presented as the first accelerator intended to close this gap by providing a programmable SumCheck engine that handles arbitrary polynomial shapes and degrees efficiently.

2. SumCheck formulation and the role of high-degree gates

The paper presents SumCheck in both an application-oriented and a protocol-oriented form. In the custom-gate discussion, classic SumCheck runs in $30\times$8 rounds. In round $30\times$9, the prover sends the univariate polynomial

$^2$0

whose degree is at most $^2$1, where $^2$2 is the maximum degree of $^2$3 in variable $^2$4. The verifier checks that $^2$5 equals the claimed sum from the previous round, samples a random $^2$6, and fixes $^2$7 for the next round. After $^2$8 rounds, the verifier evaluates $^2$9 directly. In this presentation, prover cost is $2^{30}$0, where $2^{30}$1 is the number of gates, communication is $2^{30}$2, and the protocol is described as having perfect soundness (Daftardar et al., 22 Aug 2025).

A second formulation is given in terms of variable-wise degree bounds. Let $2^{30}$3 be a $2^{30}$4-variate polynomial over $2^{30}$5 with $2^{30}$6. The prover claims

$2^{30}$7

In round $2^{30}$8, the prover computes

$2^{30}$9

which has degree at most

$1486\times$0

If

$1486\times$1

then

$1486\times$2

The prover sends the $1486\times$3 evaluations $1486\times$4, the verifier checks $1486\times$5, samples $1486\times$6, and sets $1486\times$7. In this formulation, total communication is $1486\times$8 field elements and soundness error is bounded by $1486\times$9.

Within zkPHIRE, the importance of this formulation lies in the fact that modern gate definitions may have large $11.87\times$0, such as $11.87\times$1 or $11.87\times$2, and may involve products of many witness polynomials. The accelerator is therefore designed around the exact workload induced by repeated MLE extension, product formation, and accumulation over variable-size and gate-specific term graphs.

3. Block-level organization

At block level, zkPHIRE integrates a programmable SumCheck engine with the remaining major prover components required for HyperPlonk. The design is described as a 294 mm$11.87\times$3, TSMC 7 nm chip operating at 1 GHz, with a global on-chip interconnect of up to 19 TB/s and a 2 TB/s HBM3 off-chip interface (Daftardar et al., 22 Aug 2025).

Unit	Stated resources	Stated function
Programmable SumCheck Unit	6 MB local scratchpad tiled into 16 MLE buffers	Handles arbitrary custom gates via SumCheck
Multifunction Forest	Shares modular multipliers with SumCheck PLs	Implements tree-structured steps, including polynomial openings, wiring checks, and batch evaluations
MSM engine	32 PEs using fixed-prime Montgomery multipliers	Performs multi-scalar multiplication
PermCheck Generator	266 batched modular-inverse units	Builds Numerator, Denominator, Fraction, and Product MLEs in one pass
MLE Combine unit	—	Performs the final polynomial opening checks
Interconnect and memory subsystem	Up to 19 TB/s on-chip, 2 TB/s HBM3 off-chip	Connects the prover pipeline and supplies bandwidth

The Programmable SumCheck Unit includes local scratchpad banks, MLE Update Units that halve the MLE table after each round by linear interpolation, Extension Engines that take 2 values in round 1 or 4 values in later rounds and compute the $11.87\times$4-point extensions, Product Lanes with $11.87\times$5 pipelined modular multipliers per lane, and on-chip registers for degrees at most 31 with spill to scratchpad for higher degree. The Multifunction Forest implements all tree-structured steps and shares its modular multipliers with the SumCheck Product Lanes. The MLE Combine and PermCheck blocks provide the remaining arithmetic transformations needed by the HyperPlonk pipeline.

The iso-area resource allocation described in the paper is similarly explicit. At approximately 300 mm$11.87\times$6 and 2 TB/s, zkPHIRE allocates 105 mm$11.87\times$7 to MSM with 32 PEs, 48 mm$11.87\times$8 to the Multifunction Forest with 80 trees, 16.7 mm$11.87\times$9 to SumCheck with 16 PEs and 7 EEs and 5 PLs per PE, and approximately 27 MB SRAM plus 2 HBM3 PHYs, listed as 59 mm$f(X_1,\ldots,X_\mu)$0 plus 14 MB. The stated design objective is a balanced architecture in which neither memory nor compute is the bottleneck.

4. Programmable SumCheck microarchitecture

The internal organization of the SumCheck unit is explicitly programmable. It is built from $f(X_1,\ldots,X_\mu)$1 processing elements, and each PE contains three stages: an MLE Update Pipeline, an Extension Engine, and a Product Lane (Daftardar et al., 22 Aug 2025).

Stage 1 is the MLE Update Pipeline. An input register latches the 2 or 4 MLE table values for the current round. Two cascaded modular add/sub units compute

$f(X_1,\ldots,X_\mu)$2

for linear interpolation. This stage implements the per-round table-halving step required by SumCheck’s progressive variable fixing.

Stage 2 is the Extension Engine. It is a small network of adders and subtractors that generates the $f(X_1,\ldots,X_\mu)$3 evaluations of each MLE pair. Because the degree of the gate polynomial can vary substantially across custom gates, this stage is the first point at which programmability over degree materially affects datapath shape and register pressure.

Stage 3 is the Product Lane. Each PL contains $f(X_1,\ldots,X_\mu)$4 fully pipelined modular multipliers to multiply $f(X_1,\ldots,X_\mu)$5 extensions per term, and the outputs are accumulated in extension-indexed registers or scratchpad. The paper models throughput, in field multiplies per second, as

$f(X_1,\ldots,X_\mu)$6

where

$f(X_1,\ldots,X_\mu)$7

is the initiation interval for degree-$f(X_1,\ldots,X_\mu)$8 polynomials. The given example uses 5 PLs, degree 7, and $f(X_1,\ldots,X_\mu)$9, yielding $\mathbb{F}$0, so each cycle issues approximately 2 multiply chains per PL.

A distinctive microarchitectural feature is the graph-based decomposition used by the SumCheck scheduler. Each polynomial term is decomposed into a sequence of “steps,” and partial products are accumulated in a single Tmp-MLE buffer to minimize on-chip temporary buffers. The counts of PEs, EEs, and PLs are programmable at configuration time, allowing explicit trade-offs among area, throughput, and memory bandwidth. This is the mechanism by which the accelerator generalizes from low-degree “vanilla” gates to arbitrary polynomial shapes.

5. System integration and measured performance

The SumCheck engine does not operate as an isolated kernel. It interfaces to the Multifunction Forest through the shared bus, fetching MLE tiles, writing back half-size tables, and streaming out $\mathbb{F}$1 challenge values into the SHA3-driven ZeroCheck MLE builder. The Forest’s pipelined trees consume the challenge vectors, build permutation and zero-check polynomials, and feed back into SumCheck for the Wire and Open checks. In parallel, the MSM engine overlaps ZeroCheck with wiring identity checks in order to hide SumCheck latency (Daftardar et al., 22 Aug 2025).

For standalone SumCheck, the paper evaluates 23 polynomial constraints, including Spartan, Verifiable-ASICs, Halo2 EC gates, HyperPlonk vanilla, and Jellyfish. On this set, zkPHIRE’s programmable unit achieves up to $\mathbb{F}$2 geomean speedup over a 4-threaded CPU SumCheck at 1 TB/s and $\mathbb{F}$3 at 2 TB/s, while maintaining at least 50% utilization across high- and low-degree gates.

The comparison to zkSpeed is presented in iso-area terms. At approximately 35 mm$\mathbb{F}$4 for SumCheck, zkPHIRE is only 30% slower than a heavily pipelined, fixed-function zkSpeed+ core, while supporting all custom gates. When Jellyfish gate-count reductions of $\mathbb{F}$5–$\mathbb{F}$6 fewer gates are accounted for, overall SumCheck time drops further; the paper reports net speedups over vanilla SumCheck on zkSpeed+ of up to $\mathbb{F}$7 on OpenCheck and $\mathbb{F}$8 on combined Zero+Perm checks at a $\mathbb{F}$9 gate reduction.

For full-system HyperPlonk with $\sum_{X\in\{0,1\}^{\mu}} f(X)=0.$0 Jellyfish gates, the reported runtimes are 182.9 s on a 32-core CPU, 0.123 s on zkPHIRE with 294 mm$\sum_{X\in\{0,1\}^{\mu}} f(X)=0.$1 and 2 TB/s, and 0.150 s on zkSpeed+ with 366 mm$\sum_{X\in\{0,1\}^{\mu}} f(X)=0.$2 and the same bandwidth. This corresponds to a $\sum_{X\in\{0,1\}^{\mu}} f(X)=0.$3 speedup over CPU, and zkPHIRE is reported as $\sum_{X\in\{0,1\}^{\mu}} f(X)=0.$4 faster at iso-application, with $\sum_{X\in\{0,1\}^{\mu}} f(X)=0.$5 geomean speedup across five workloads. The system also supports up to $\sum_{X\in\{0,1\}^{\mu}} f(X)=0.$6 nominal constraints: the paper gives as an example a rollup of 1600 private TXs, mapped from $\sum_{X\in\{0,1\}^{\mu}} f(X)=0.$7 to $\sum_{X\in\{0,1\}^{\mu}} f(X)=0.$8 Jellyfish gates, running in 0.208 s versus 355 s on CPU, corresponding to $\sum_{X\in\{0,1\}^{\mu}} f(X)=0.$9.

A common misunderstanding in this design space is that faster fixed-function SumCheck hardware is sufficient for modern ZK protocols. The reported results argue against that view. zkPHIRE can be slower than a fixed-function core on narrowly targeted kernels, yet still outperform it at the application level because it supports the custom-gate structures that reduce total gate count.

6. Programmability, scalability, and open directions

zkPHIRE’s defining property is full programmability of the SumCheck engine. Its controller can load any polynomial term graph and configure $$f = q_1\cdot w_1 + q_2\cdot w_2 + q_{H1}\cdot w_1^5 + q_{H2}\cdot w_2^5 + \ldots$$0 degree limits$$f = q_1\cdot w_1 + q_2\cdot w_2 + q_{H1}\cdot w_1^5 + q_{H2}\cdot w_2^5 + \ldots$$1. On-chip MLE buffers hold up to 31-degree tables, and higher degrees spill to scratchpad with slightly higher latency. The graph decomposition scheduler is used to minimize data movement and temporary storage (Daftardar et al., 22 Aug 2025).

The paper frames scalability in both problem-size and design-space terms. At the problem-size level, zkPHIRE is identified as the first accelerator to scale to $$f = q_1\cdot w_1 + q_2\cdot w_2 + q_{H1}\cdot w_1^5 + q_{H2}\cdot w_2^5 + \ldots$$2 nominal constraints while maintaining small proof sizes and programmability. At the design-space level, the main trade-off is bandwidth sensitivity. Extreme bandwidth from HBM3 is needed to sustain $$f = q_1\cdot w_1 + q_2\cdot w_2 + q_{H1}\cdot w_1^5 + q_{H2}\cdot w_2^5 + \ldots$$3 speedups on low-degree gates, whereas higher-degree gates are more compute-bound and can run with DDR5. The paper therefore places implementations on an area-versus-bandwidth Pareto frontier. One listed point is a 1 TB/s, 250 mm$$f = q_1\cdot w_1 + q_2\cdot w_2 + q_{H1}\cdot w_1^5 + q_{H2}\cdot w_2^5 + \ldots$$4 design, labeled Design B, which yields approximately $$f = q_1\cdot w_1 + q_2\cdot w_2 + q_{H1}\cdot w_1^5 + q_{H2}\cdot w_2^5 + \ldots$$5 speedup; another is a 512 GB/s, 200 mm$$f = q_1\cdot w_1 + q_2\cdot w_2 + q_{H1}\cdot w_1^5 + q_{H2}\cdot w_2^5 + \ldots$$6 design that still delivers $$f = q_1\cdot w_1 + q_2\cdot w_2 + q_{H1}\cdot w_1^5 + q_{H2}\cdot w_2^5 + \ldots$$7.

The stated future directions are extensions rather than departures from the present architecture. These include extending programmability to alternative polynomial commitment schemes, including Plonk-ish NTT-based SNARKs; dynamically reconfiguring EE and PL resources per gate at runtime; and exploring on-chip network topologies that further reduce memory pressure for ultra-large circuits. A plausible implication is that the long-term contribution of zkPHIRE is not only the reported speedup figures, but also the articulation of programmable SumCheck as a first-class hardware abstraction for custom-gate zkSNARK provers.