ZKProphet: GPU ZK Proof Profiling

• ZKProphet is a performance characterization study that examines GPU-accelerated zero-knowledge proof generation using the Groth16 protocol.
• The study finds that after aggressive MSM optimization, number-theoretic transforms can account for up to 91% of proof-generation latency, shifting the optimization focus.
• It offers a measurement-driven roadmap by analyzing finite-field arithmetic, highlighting key optimization targets in MSM precomputation, affine arithmetic, and NTT redesign.

ZKProphet is a performance-characterization study of GPU-accelerated zero-knowledge proof generation, centered on the Groth16 prover and its dominant kernels on modern NVIDIA GPUs. Rather than proposing a new proof system or a single new kernel, it analyzes where prover time is spent after recent GPU acceleration of multi-scalar multiplication, and argues that the optimization frontier has shifted toward number-theoretic transforms and the finite-field arithmetic beneath them (Verma et al., 17 Sep 2025). The study’s main conclusion is that, once MSM is heavily optimized, NTT can account for up to 90% of proof-generation latency in the abstract and up to 91% in the detailed results, making ZKProphet primarily a measurement-driven roadmap for the next phase of GPU-accelerated proving (Verma et al., 17 Sep 2025).

1. Definition and analytical scope

ZKProphet is framed as an end-to-end and microarchitectural study of zero-knowledge proof proving on GPUs, with Groth16 as the concrete proving system under examination. Its subject is not verification, proof theory, or protocol design in the abstract, but the prover-side execution profile of real implementations across libraries, input scales, and GPU generations (Verma et al., 17 Sep 2025).

The paper treats GPU proof generation as being dominated by two kernels. The first is multi-scalar multiplication, written as

$Q = \sum_{i=0}^{N-1} k_i \cdot P_i,$

where $P_i$ are elliptic-curve points and $k_i$ are scalar integers. The second is the number-theoretic transform, the finite-field analogue of the FFT, used for polynomial processing inside the prover (Verma et al., 17 Sep 2025). It states that these two kernels account for more than 90% of end-to-end execution time, and cites prior work placing that share above 95% (Verma et al., 17 Sep 2025).

The study is Groth16-centered, but it explicitly notes that MSM and NTT are also central in other proving systems, including Marlin, PLONK, Sonic, Halo, Virgo, STARK, Aurora, and Ligero. This suggests that its conclusions are narrower than “all ZK provers,” yet broader than Groth16 alone in practical relevance (Verma et al., 17 Sep 2025).

2. Experimental basis and evaluated software stack

The empirical analysis spans input scales from $2^{15}$ to $2^{26}$ and uses both kernel-level and end-to-end measurements. The primary CPU baseline is a dual-socket server with AMD EPYC 7742 64-core processors and 2 TB RAM. The primary GPU platform is an NVIDIA A40 with 48 GB, while cross-generation analysis includes the V100, T4, RTX 3090, A100, L4, L40S, and H100 (Verma et al., 17 Sep 2025).

The study compares publicly available high-performance libraries compatible with Groth16: arkworks as a CPU baseline, bellperson, sppark, cuZK, yrrid, and ymc. The curve support discussed includes BLS12-377 and BLS12-381. Finite-field elements are represented as multi-limb integers; the paper gives the example that a 377-bit integer is represented with 12 32-bit limbs (Verma et al., 17 Sep 2025).

Profiling uses NVIDIA Nsight Compute 2025.1, CUDA C++ kernels built with CUDA Toolkit 12.8, and cuZK with CUDA 11.5. The measured quantities include latency, speedup over CPU, instruction throughput, CPU–GPU transfer time, energy, roofline position, occupancy, SASS instruction mix, branch efficiency, and warp stall breakdown (Verma et al., 17 Sep 2025).

This methodology matters because ZKProphet is not just a benchmark table. It combines library comparison, arithmetic analysis, and GPU execution analysis, so that kernel-level bottlenecks can be tied to specific architectural resources rather than only to aggregate prover time (Verma et al., 17 Sep 2025).

3. Shift from MSM dominance to NTT dominance

The central empirical finding is that the long-standing view of MSM as the prover’s dominant bottleneck no longer holds once MSM is aggressively optimized on GPUs. The paper reports that MSM speedup over CPU rises from 34.1× at scale $2^{15}$ to 799.5× at scale $2^{26}$, while NTT speedup rises from 12.5× at $2^{15}$ to a peak of about 50.6× around $2^{22}$ (Verma et al., 17 Sep 2025). The asymmetry is decisive: MSM acceleration has advanced much faster than NTT acceleration.

As a result, the proof-time split changes materially. ZKProphet reports that NTT already consumes about 50% of runtime at moderate scales and reaches up to 91% of total prover runtime at larger scales (Verma et al., 17 Sep 2025). The abstract states the same phenomenon as “up to 90%,” and the detailed results refine it to 91% (Verma et al., 17 Sep 2025).

The library winners vary with scale. For MSM, sppark is fastest up to $2^{20}$, yrrid becomes best at $P_i$0, and ymc is best from $P_i$1 to $P_i$2. For NTT, bellperson is fastest for $P_i$3–$P_i$4, cuZK is fastest for $P_i$5–$P_i$6, and bellperson is used again above $P_i$7 because cuZK fails with memory-allocation or segmentation errors at larger scales (Verma et al., 17 Sep 2025). There is therefore no single best implementation across all proof sizes.

The paper also argues that the runtime problem is not only arithmetic throughput. The prover performs seven NTT operations, each involving multiple kernel launches, and current NTT implementations often fail to hide CPU–GPU data movement. By contrast, optimized MSM implementations already overlap data transfers and compute effectively through asynchronous copies and decomposition techniques (Verma et al., 17 Sep 2025). This makes NTT a combined arithmetic-and-data-movement bottleneck.

Energy measurements reinforce the same pattern. CPU NTT consumes on average about 3.1× more energy than GPU NTT, whereas CPU MSM can consume up to roughly 398.4× more energy than GPU MSM at scale $P_i$8 (Verma et al., 17 Sep 2025). The gap shows that MSM has benefited much more completely from GPU acceleration than NTT has.

4. Finite-field arithmetic and the GPU execution bottleneck

ZKProphet traces both MSM and NTT back to a common arithmetic substrate: finite-field addition, subtraction, doubling, multiplication, squaring, and inversion. The decisive observation is that $P_i$9 and $k_i$0 account for 93.8% of NTT time and 80.0% of MSM time (Verma et al., 17 Sep 2025). In other words, the prover bottleneck is ultimately the throughput of large-integer finite-field multiplication and squaring.

The paper reports the following single-operation latencies in cycles. On CPU, $k_i$1, $k_i$2, $k_i$3, and $k_i$4. On GPU, $k_i$5, $k_i$6, $k_i$7, $k_i$8, and $k_i$9 (Verma et al., 17 Sep 2025). Individual operations are therefore much slower in latency terms on GPU than CPU; GPU advantage arises from throughput, not from faster single operations.

At the microarchitectural level, the paper finds that these operations execute almost entirely on the GPU’s 32-bit integer pipeline. The dominant SASS instructions are IADD3 for $2^{15}$0 and $2^{15}$1, SHF for $2^{15}$2, and IMAD for $2^{15}$3 and $2^{15}$4 (Verma et al., 17 Sep 2025). This means recent architectural improvements aimed at tensor cores, floating-point throughput, and AI workloads do not directly accelerate the core arithmetic of current ZKP kernels.

Instruction-level parallelism is limited. The schedulers issue new instructions every 3.2 cycles on average instead of every cycle, and 67.5% of cycles have no eligible warps to issue from (Verma et al., 17 Sep 2025). The dominant explanation is dependency chains, especially in multi-limb multiplication and modular reduction. For $2^{15}$5, average warp stall latency is 6.2 cycles, with Stall Wait and Stall Math Pipe Throttle as key contributors (Verma et al., 17 Sep 2025). Adding more warps does not solve the problem once the INT32 math pipeline is saturated.

Branch divergence is also significant. Branch efficiency is 52.5% for $2^{15}$6, 56.2% for $2^{15}$7, 77.5% for $2^{15}$8, 84.0% for $2^{15}$9, and 96.9% for $2^{26}$0 (Verma et al., 17 Sep 2025). For $2^{26}$1 and $2^{26}$2, divergence increases execution cycles from 72 to 244, a 2.4× increase (Verma et al., 17 Sep 2025). Achieved occupancy is only 25.0%, and the paper stresses that simply increasing occupancy is not a cure when the dominant limiter is integer-pipeline contention rather than latent memory misses (Verma et al., 17 Sep 2025).

5. Scaling across GPU generations and optimization directions

Across the V100, T4, RTX 3090, A100, L4, L40S, and H100, the study finds that performance scales mainly with the number of streaming multiprocessors rather than with substantial per-SM improvements in the relevant arithmetic. Average warp stall latency is 6.26 cycles across GPUs, and average $2^{26}$3 latency is 2660.06 cycles (Verma et al., 17 Sep 2025). The paper therefore concludes that newer GPUs improve ZKP performance largely by providing more SMs, not by materially improving the execution of finite-field multiplication per SM.

This leads to several concrete optimization directions. One is MSM precomputation. With window size $2^{26}$4 bits and scalar width 253 bits, Pippenger requires $2^{26}$5 windows, each requiring about 16.7 million point additions; the paper discusses precomputing $2^{26}$6 to reduce later-window work, trading memory for arithmetic (Verma et al., 17 Sep 2025). It estimates that one set of affine points at scale $2^{26}$7 needs about 6 GiB, so larger-memory GPUs can support more aggressive precomputation (Verma et al., 17 Sep 2025).

A second direction is affine arithmetic with batched inversion via the Montgomery Trick. The paper notes that for $2^{26}$8 point additions, affine with batched inversion can reduce the number of $2^{26}$9 operations by 3.3× relative to XYZZ and 3.6× relative to Jacobian, though it requires substantial intermediate storage (Verma et al., 17 Sep 2025).

The third and perhaps most immediate direction is NTT redesign. bellperson’s large-scale NTT uses three radix-256 kernels and one radix-2 kernel, with the final radix-2 kernel launching 16 million blocks of 2 threads each and using less than 5% of available device memory (Verma et al., 17 Sep 2025). The paper treats this as direct evidence that current NTT implementations underutilize GPU hardware and fail to exploit asynchronous memory operations and better launch structures.

The paper therefore recommends autotuning over proof size, field choice, implementation, precomputation level, and hardware characteristics, and it advocates better interoperability across proof-system frontends and optimized kernels. It also argues that hardware support for higher-precision integer arithmetic would benefit ZKP workloads more directly than continued emphasis on AI-centric units alone (Verma et al., 17 Sep 2025).

6. Position in the broader zero-knowledge optimization literature

ZKProphet occupies a distinct place in the zero-knowledge literature. It is neither a new proof system nor a circuit-level algebraic optimization. Instead, it is a measurement-based analysis of prover execution on GPUs, with the explicit claim that the next performance frontier lies in NTT and in the integer-arithmetic substrate beneath both NTT and MSM (Verma et al., 17 Sep 2025).

This makes it complementary to workload-specific proof optimizations such as zkVC, which optimizes matrix multiplication by introducing a Constraint-reduced Polynomial Circuit and Prefix-Sum Query, reducing matrix-multiplication constraints from $2^{15}$0 to $2^{15}$1 and claiming more than a 12-fold increase in proof speed over prior methods (Zhang et al., 16 Apr 2025). ZKProphet operates at a different layer: it assumes the proof relation is already fixed and asks how its dominant kernels behave on GPUs. This suggests a two-level optimization picture in which algebraic reduction and hardware-level acceleration are cumulative rather than competing approaches.

The paper also differs from benchmark-and-selection frameworks such as zkSDK, which profile workloads and choose among proving backends such as Risc Zero, Gnark Groth16, and Gnark Plonk (Law, 5 Jul 2025). ZKProphet is not a backend recommender; it is an execution study of what happens inside a high-performance prover once a backend has already been chosen. A plausible implication is that backend selection, circuit optimization, and GPU kernel optimization should be treated as separate but interacting stages of prover design.

In that sense, ZKProphet is best understood as a hardware-conscious encyclopedia of current prover bottlenecks. Its lasting contribution is the claim that, in modern GPU proving, the decisive question is no longer merely how to accelerate MSM, but how to redesign NTT and finite-field arithmetic so that zero-knowledge proof generation scales with available hardware rather than remaining constrained by underused INT32 execution resources (Verma et al., 17 Sep 2025).