Zero-Knowledge Proofs
As conversations about LLMs continue to dominate computer science, the cryptographic community has been abuzz around a different three letter acronym: ZKP. Zero-Knowledge Proofs (ZKPs) allow a prover to convince a verifier that a statement is true without revealing the secret information that makes it true. In other words, ZKPs make it possible to verify computation without exposing private data behind it.
In a cloud computing context, ZKPs could allow a service provider to convince a client that they executed a service faithfully, without having to reveal their sensitive trade secrets, IP, or (for AI services) model weights. On the other hand, ZKPs could allow an edge user concerned about security or anonymity to prove identification, financial eligibility, or authenticity of image transformation to untrusting services.
Two flavors of ZKPs have emerged with particularly intriguing tradeoffs: zkSNARKs (zero-knowledge Succinct Non-Interactive ARguments of Knowledge) and zkSTARKs (zero-knowledge Scalable Transparent ARguments of Knowledge). zkSNARKs are attractive because they generate compact proofs (as small as 192 bytes!) which are fast to transmit and verify. This made them especially appealing for early blockchain adopters of ZKPs. zkSTARKs, on the other hand, offer both faster proving times and post-quantum security, but generate much larger proofs (upwards of several megabytes). This increases communication costs and requires more processing by the verifier. As such, zkSTARKs may be more advantageous in applications where proof size constraints are more relaxed or where the number of verifiers is small.
Both zkSNARKs and zkSTARKs suffer from the computational cost of proof generation. The proving time to generate a zkSNARK for a target application is roughly 5-6 orders of magnitude more than the time to run the original application itself. zkSTARK provers are similarly expensive. Further, as the problem complexity grows (e.g., running an AES is much simpler than running a GPT inference), the corresponding ZKP’s computational cost also grows. Consequently, many otherwise compelling and exciting ZKP applications remain out of reach today. To address this, researchers have begun accelerating both zkSNARKs and zkSTARKs with GPUs, FPGAs, and ASICs.
Dissecting a ZKP
Modern ZKPs are diverse and defined by combining a polynomial interactive oracle proof (PIOP), which reduces program correctness to polynomial checks, with a polynomial commitment scheme (PCS), which binds the prover to the relevant input polynomials and lets the verifier check claimed polynomial values at specific points. PIOPs and PCSs can be mixed and matched to define many ZKP protocols with different tradeoffs in proof latency, proof size, verifier latency, setup assumptions, and post-quantum security.
The diversity between PIOP and PCS schemes typically results in ZKPs built upon some kernels with extremely high arithmetic intensity on wide bitwidths and others with low arithmetic intensity and complex data movement patterns. Any hardware seeking to accelerate ZKPs must account for both flavors of computational kernel.
The high data volume follows from how PIOPs represent the execution of a function. Many PIOPs encode a program’s execution trace as one or more polynomials (represented as long vectors of polynomial evaluations). Verifying program correctness then reduces to checking that these polynomials are consistent with the program’s constraints and satisfy a number of algebraic identities. Polynomials are especially useful because, rather than checking these constraints individually across the entire execution trace, they can be encoded as polynomial identities that the verifier tests at a small number of randomly chosen points. These long vectors can range from 214–230 elements, amounting to 0.5 MB – 32 GB for a single such vector. These vectors may be repeatedly transformed, permuted, hashed, or combined, creating substantial pressure on memory capacity, bandwidth, and data movement.
While PIOPs often rely on more data movement with lower arithmetic intensity, PCSs often behave quite differently. The PCSs found in zkSNARKs primarily rely on modular arithmetic over large prime fields and elliptic curve (EC) groups. Generally, field elements are on the order of 256 bits wide, with some ECs’ field elements being upwards of 384 bits. EC computations are even more computationally expensive than large-bitwidth finite field computation, with the addition of two EC group elements requiring 16 (or more) modular multiplications. zkSNARK PCSs are dominated by the latency to calculate many EC group additions.
zkSTARK PCSs differ significantly from zkSNARKs. zkSTARK PCSs are built upon repeated hashing as opposed to EC arithmetic. Some zkSTARK PCSs use smaller, hardware-friendly finite fields, which can reduce arithmetic bit widths; others still operate over wide fields on the order of 256 bits. In either case, zkSTARK provers must perform extensive hashing and repeatedly process, reorganize, and extend large vectors of field elements, creating substantial memory-bandwidth and data-movement demands.
Due to differences between PCS and PIOP kernels, accelerating proof generation requires more than support for wide datatypes and long vectors. A practical architecture must efficiently handle both compute-intensive kernels, such as elliptic-curve arithmetic and hashing, and bandwidth-intensive kernels, such as polynomial transform and large-scale data rearrangement.
Accelerating ZKP Kernels
Seeing the promise and current computational limitations of ZKPs, many architects have begun work accelerating ZKPs on GPUs, FPGAs, and ASICs. This largely amounts to accelerating individual ZKP kernels.
The Multi-Scalar Multiplication (MSM) kernel serves as the bedrock of zkSNARK PCSs. MSMs compute the sum of many EC point multiplications, which can be thought of as dot products between vectors of scalar integers (derived from the polynomials) and vectors of two-dimensional EC points (derived from the protocol setup phase). However, scalar multiplication by an EC point is actually achieved via repeated EC point addition (or PADDs) described above. Naively, assuming 256-bit scalars, a single scalar multiplication requires 2256 PADDs. This cost can be tempered by employing a binary representation of scalars and performing a “shift-and-add” algorithm for multiplication, resulting in at most 255 PADDs and 255 PDBLs (point doubles) per scalar that must be computed serially. To improve upon this, most MSM implementations today use Pippenger’s algorithm, a technique that parallelizes computations across independent slices of the scalars, to further reduce the number of PADDs. However, Pippenger’s algorithm is data-dependent upon the scalars being committed. Many MSM workloads are sparse, meaning they contain a disproportionate number of zeros, ones, and other small scalars, while others are dense, consisting of randomly distributed full-width field elements. These differences can significantly change the amount of useful EC work performed, the load balance across parallel workers, and the memory-access behavior. Recent ASIC approaches have proposed dynamically scheduled microarchitectures, contention-free multi-PE datapaths, priority-based bucket scheduling, and reconfigurable modular arithmetic arrays. Recent GPU approaches have proposed fine-grained, load-balanced task mapping, sparse-matrix-based bucket accumulation, adaptive preprocessing for improved time–space trade-offs, and tensor-core-assisted arithmetic and multi-GPU orchestration.
Merkle Trees are the zkSTARK analog to MSMs, enabling commitments to a vector via hashing as opposed to EC cryptography. Constructing a Merkle Tree is equivalent to constructing a binary tree where the vector values being committed are the leaves, and parents are constructed by performing a hash seeded by its two children. The root node of the resulting Merkle Tree is a commitment to the polynomial. Constructing a Merkle tree requires a large number of hash operations: for a tree with N leaves, the prover must compute approximately N-1 internal-node hashes. However, performance is shaped not only by hash throughput, but also by how the tree is traversed. A conventional breadth-first construction materializes each tree level before computing the next, creating substantial intermediate-memory traffic. Recent ASIC approaches like the MTU use a hybrid traversal that preserves parallel execution while retaining partial reductions locally, reducing the need to repeatedly write and reread intermediate tree nodes from memory. Other approaches tile Merkle trees into scratchpad-resident subtrees and process each subtree entirely on-chip using spatial arrays, while GPU approaches pipeline batched Merkle trees across layer-specific GPU kernels to sustain thread utilization while overlapping data transfers with hashing. Recent work also explores FPGA acceleration of ZK-friendly hash functions to increase hash throughput.
Number Theoretic Transforms (NTTs) are analogs of the FFT but over large, ~256 bit finite field elements. NTTs are primarily used to reduce the cost of polynomial multiplication from O(N2) operations to O(N log N). The key challenge for NTTs is handling variable memory access patterns in between NTT stages and handling off-chip memory transfers when computing NTTs whose working set doesn’t fit into on-chip caches and scratchpads. Recent approaches have focused on recursive decompositions, pipelined MDC based architectures, and constant geometry approaches.
SumChecks are another major prover kernel for many PIOPs. At a high level, a SumCheck prover repeatedly streams large tables of polynomial evaluations, performs elementwise finite-field computations determined by the polynomial being evaluated, and reduces the results into progressively smaller tables. Although each round is built from additions, multiplications, and linear combinations, these operations are performed over wide field elements and must be applied across large vectors, creating substantial arithmetic and memory-bandwidth demand. While this seems relatively simple, unlike NTTs, SumCheck’s dataflow changes with the polynomial. More input polynomials or higher-degree expressions require more elementwise evaluation products, increasing both the compute load and memory pressure for storing intermediates during folding. Initial work addressed this with vector architectures and fixed-function ASICs to exploit short-term data reuse within streaming frameworks. Recent work like zkPHIRE has proposed programmable ASICs to efficiently handle variable dataflow, decomposing SumCheck into common primitives—table updates, extensions, and evaluation products—and mapping them onto programmable compute pipelines, allowing the support of arbitrary polynomial structures and gate types.
The above kernels typically account for the vast majority of ZKP compute time, but all ZKP protocols also rely on a variety of smaller kernels to stitch these major components together. In order to avoid Amdahl’s Law bottlenecks, it is essential ZKP hardware accelerates these kernels as well.
The Future of ZKPs
ASIC acceleration of ZKPs has evolved from fixed-function modules towards reconfigurable and programmable datapaths. Most existing accelerators remain specialized to one or a small number of protocols, while recent work has begun to support multiple protocols. Recent characterization studies on CPUs and GPUs show that execution bottlenecks, memory behavior, and scalability vary substantially across protocols and implementations. As ZKP protocols continue to evolve, there is growing interest in more general architectures that can accommodate its heterogeneous kernels, arithmetic requirements, and execution patterns. Understanding how different protocols stress the hardware stack remains an active area of research.
To learn more and join the conversation with architects working to make real-time, deployable ZKPs a reality, join us at the ZKARCH workshop at MICRO 2026!
About the Authors:
Alhad Daftardar is a Ph.D. candidate in Electrical and Computer Engineering at NYU. He received his BSEE from Georgia Tech and his MSECE in VLSI from the University of Michigan. His research interests are in computer architecture for Zero-Knowledge Proofs and privacy-preserving computation.
Brendan Sweezy is a Ph.D. student at New York University studying Electrical and Computer Engineering. He received his BS from Duke University. His research focuses on hardware acceleration for Zero-Knowledge Proofs, particularly targeting programmable and edge-scale devices.
Brandon Reagen is an Assistant Professor of Electrical and Computer Engineering at New York University with a focus on computer architecture. His work has been recognized with the ASPLOS’25 Best Paper Award, multiple best paper nominations (DAC, PACT, HASP), and multiple Top Pick/honorable mention awards. He has been a performer (and PI) on the DARPA DPRIVE, PROWESS, and COOP programs, was recognized as a DARPA Riser, and won the NSF CAREER award. He is a lead PI on the NSF CIRC Grand Cryptolets project and has generously received support from Google, DTCC, and AMD.
Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.
