UniZK: Accelerating Zero-Knowledge Proof with Unified Hardware and Flexible Kernel Mapping

Zero-knowledge proofs let you prove you know a secret without revealing it, and the newer protocols replaced expensive elliptic-curve arithmetic with hash functions — which made them far cheaper but also scattered the work across many different computation kernels instead of two, so the accelerator playbook of building a dedicated unit per hot kernel now runs into Amdahl's law at under 7x; UniZK (Xi'an Jiaotong and Tsinghua) instead builds one homogeneous grid of modular-arithmetic cells, adds a vector mode and a few backwards links between neighbours, and spends its cleverness on mapping strategies that fold transforms, an irregular hash and general polynomial work onto the same array.

Why this problem is worth solving

The interesting shift here is not cryptographic but architectural, and it happened because the cryptography changed underneath.

The replacement family swapped that expense for a different one.

What people did before, and where it broke

• Accelerate the two dominant elliptic-curve kernels with dedicated modules. This is what the leading custom chip for the older protocols does, and it is the textbook-correct response to a workload with two hot spots. Where it broke. It is the wrong shape for the new protocols. With Merkle tree at 60% and transforms plus polynomial work at 35%, catching only the top two kernels leaves enough behind that Amdahl caps the whole design at under 7x. That design also leaves some work on the host, so intermediate data has to cross the link both ways.
• Build one dedicated unit per kernel and put them all on a chip. The obvious extension: if there are now six kernels, build six units. Where it broke. Chip area, and utilisation. The paper’s objection is specifically about variability — the polynomial share of runtime swings from 11% to 25% across workloads, so a static area split leaves one unit as the bottleneck while others sit finished and idle, and which one that is changes with the input.
• Specialise for the specific cryptographic primitive. A Poseidon hash unit, for instance, would be very efficient at Poseidon. Where it broke. The protocols are moving fast. The paper notes plainly that a unit built around one hash choice becomes dead area the moment the next protocol version picks a different one.
• Use GPUs. A CUDA implementation exists for the protocol UniZK targets, covering transforms, Merkle trees and element-wise polynomial work. Where it broke. It cannot generate a whole proof by itself — the remaining kernels stay on the host, with data crossing back and forth — and the transforms it does run need irregular memory access patterns that GPUs handle badly. The measured result is a speedup capped at 4.6 times over the CPU.
• The gap. Nobody had asked what an accelerator should look like when the workload has no dominant kernel and its profile is unstable. The answer the paper proposes was already sitting in a neighbouring field, where accelerators for neural networks long ago stopped building a unit per operator and started building general arrays with good mapping.

How UniZK folds four different kernels onto one array

The idea

When the profile is flat and unstable, a general array beats dedicated units. The motivating calculation is one line of Amdahl arithmetic and it does most of the work in the paper. With Merkle tree at 60% and the two next kernels at 35% between them, a chip that catches the top two is capped at under 7x — and that is before considering that the polynomial share moves between 11% and 25% depending on what you are proving, which means any static allocation of silicon between fixed units is badly matched to most workloads. The older protocols had two dominant kernels and rewarded specialisation; these have six and punish it. Contrast this with the accelerators built for the multi-scalar multiplication that dominated the elliptic-curve era, covered elsewhere on this site, which could reasonably pour everything into one kernel because that kernel really was the workload.

The hardware stays boring on purpose, and the contribution is the mapping. The array is a conventional systolic grid of cells that each hold a modular multiplier, two modular adders and a register file. Two things are added, and both are small. A vector mode lets each column act as an independent vector unit, which is what the mass of element-wise polynomial work wants, while the systolic links between columns still allow useful things like forwarding a vector sideways or accumulating one down to a scalar. And a few reverse links run back up certain columns — deliberately neighbour-to-neighbour rather than global wires, to keep placement and routing cheap — because one specific round of the hash needs a value computed at one end sent back to every row. Everything else is mapping strategy: decomposing variable-length transforms into fixed-size ones the array can hold, reusing cells that would otherwise idle because their twiddle factor happens to be one, and tiling the polynomial work so operands stay resident. Building one array that many different computation shapes are mapped onto, rather than one unit per shape, is the same bet as the multi-dataflow sparse matrix accelerator covered elsewhere on this site.

Accelerate the obvious things and the leftovers become the bottleneck. The most honest part of the evaluation is what it finds after the big kernels are dealt with. Transforms and hashes reach up to 191 times, but the miscellaneous polynomial operations manage only 20 to 92 times, and having sped up everything else, they now account for the majority of the remaining runtime. The reason is specific and unglamorous: evaluating gate constraints produces pseudo-random accesses whose indices come from bit-reversal, and the size of each access is bounded by the width of the arithmetic circuit — often only 135, with other parameters as low as 2. Small scattered reads cannot fill a terabyte per second of memory bandwidth, and the one workload that does better is the one whose circuit is 400 wide. That memory access patterns rather than arithmetic set the ceiling for this workload is exactly what the GPU acceleration work for zero-knowledge proofs covered elsewhere on this site concluded from the other side of the hardware divide.

Walking the Poseidon hash across the array

This is where the claim of generality gets its first qualification. The array is general across the kernels of this protocol family, but its dimensions were chosen to fit one hash function in one protocol. The paper is upfront that the design has several such choices — the field width, the hash — and argues the philosophy transfers even though the instance does not.

Why it works

• A general array cannot be left idle by a shifting profile. Every kernel runs on the same cells → when the polynomial share of a workload swings from 11% to 25%, no silicon is stranded because none of it was dedicated → the utilisation problem that would afflict a chip of fixed units simply does not arise.
• Covering every kernel keeps the host out of the loop. Nothing has to fall back to the CPU → no intermediate data crosses the interconnect in either direction → which matters because the GPU baseline, which does fall back, is capped at 4.6 times partly for this reason.
• The awkward cases were solved by adding almost nothing. One irregular hash round needs data to flow backwards → a few neighbour-to-neighbour reverse links in certain columns provide it → and because they are local rather than global wires, placement and routing complexity, and therefore area, barely move.
• Idle cells get reused rather than added. One transform stage always multiplies by a twiddle factor of one, and the constant multiplications of the variant transforms need somewhere to live → those cells are handed the extra work instead of new cells being added → the pipeline for a size-n transform stays at about log n cells.
• Layout changes stop being a cost at all. A global transpose buffer handles transposition implicitly while data is being fetched → the work overlaps with a compute kernel rather than occupying its own phase → the transposes that appear as a measurable slice of CPU runtime vanish from the breakdown entirely.

What it costs (trade-offs and scope)

• The 840 times headline is not a like-for-like comparison. It compares throughput in blocks per second against the older accelerator, on a workload where UniZK amortises the cost of recursive proof compression over many blocks while the baseline does not batch. The paper says directly that a fair comparison is difficult since both protocol and architecture differ. In the single-block, direct accelerator-to-accelerator comparison the figure is 3.5 to 8.1 times, and on the CPU the newer protocol is actually slower than the older one for a single block.
• The GPU baseline cannot do the job it is being compared on. It relies on the host for several kernels, pays for the transfers, and reaches only 4.6 times over the CPU. Being 46 times faster than that is a real result, but the baseline is structurally handicapped in exactly the way the paper is arguing against.
• The remaining bottleneck is untouched and the paper says so. Polynomial operations get 20 to 92 times against 191 for the others, show low utilisation of both bandwidth and compute, and become the majority of the post-acceleration runtime. The cause is pseudo-random accesses of small size bounded by the arithmetic circuit width, and nothing in the design fixes it.
• This is simulation, not silicon. There is RTL for the array, the transpose unit and the twiddle generator, synthesised at 7 nm, with buffers modelled analytically and a cycle-accurate simulator validated against the RTL. That is a careful methodology and it is still a model, not a chip.
• The compiler front end is manual. Converting library functions into the computation graphs the backend consumes is done by hand at present. The mapping and scheduling behind that is automated, but the entry point is not.
• Unified means unified across kernels, not across protocols. The array is 12 by 12 because the hash state is 12 elements; the datapath is 64 bits because of the specific field; the whole design is built around one protocol family. The authors argue the philosophy carries to other protocols with minor hardware changes and new mappings, examine three recent ones, and identify the sum-check function as a genuinely challenging new primitive — then state that evaluating this is beyond the paper’s scope.
• The comparison with the closest concurrent work is philosophical. A contemporaneous accelerator for different hash-based protocols takes the opposite approach with dedicated units per kernel. UniZK argues its unified design is more area-efficient. No measurement is offered.
• The extension field costs extra steps. A small part of the protocol works over a quadratic extension of the base field, which the hardware handles by treating each 64-bit piece as a limb and taking more steps rather than by widening anything.

The evaluation

Check yourself

Sources

The paper is “UniZK: Accelerating Zero-Knowledge Proof with Unified Hardware and Flexible Kernel Mapping” by Cheng Wang and Mingyu Gao, published at ASPLOS 2025 Volume 1, pages 1101-1117, DOI 10.1145/3669940.3707228. The first author is at Xi’an Jiaotong University, with the work done during an internship at the Institute for Interdisciplinary Information Core Technology; the second is at Tsinghua University. It is open access under a Creative Commons licence, and the simulator is open-sourced.

This explainer is written from the full text, read through a proxy of the ACM Digital Library copy. Everything above comes from the paper’s own sections 2 through 8: the review of elliptic-curve against hash-based protocols and the three-step structure of proof generation; the walkthrough of the Plonk and FRI phases with the worked arithmetic-circuit example, the low degree extension and its blowup factor, and the Merkle tree commitment; the time breakdown putting Merkle tree at about 60% and transforms plus polynomial work at about 35%; the four-part design argument covering the Amdahl ceiling under 7x, the 11% to 25% swing in polynomial share, the risk of specialising to one hash choice, and the cost of host fallback; the array description with its 12 by 12 cells, one modular multiplier and two adders per cell, 64-bit field elements, vector mode and reverse links; the transform mapping with its multi-dimensional decomposition, pipelined structure of about log n cells, splitting a row into two pipelines, batched transposition for the index-major layout, and reuse of idle cells for the variant transforms; the hash mapping with its 8 full and 22 partial rounds, the folding of a full round into a 12 by 8 region, the merged constant addition in the pre-partial round, the three-column partial round using reverse links, and the 145-cycle latency at one state per cycle; the Merkle tree and polynomial mappings with vector tiling and the partial-product scheme; the methodology with its 7 nm synthesis, analytical buffer modelling, validated cycle-accurate simulator, 32 arrays, 8 MB scratchpad, roughly 1 TB/s bandwidth and 64 W plus 32 W power; the results of 61 to 147 times over CPU and 46 over GPU, the per-kernel breakdown with polynomial work at 20 to 92 times and its diagnosis in circuit width, the utilisation table, the Starky results at up to 267 times, and the comparison with the previous accelerator at 3.5 to 8.1 times directly and 840 times on batched throughput; and section 8.1, where generality to three newer protocols is analysed and the sum-check function identified as the challenging case.