Lecture 16: Hardware Acceleration of ZKP

What this lecture covers

This lecture, given by a hardware-acceleration engineer at Supranational, explains why generating a zero-knowledge proof is orders of magnitude more expensive than running the underlying computation natively, and what can be done about it in hardware. It answers what operations dominate proof-generation time, what hardware platforms suit those operations, and what limits speedups even after acceleration.

The lecture closes out the course's applied, systems-level material by moving from proof-system theory to the engineering of making proving practical at scale. After watching, you should be able to name the three computationally dominant operations in most proof systems, explain why some are easy to parallelize and others are not, and reason about which hardware platform (CPU, GPU, FPGA, ASIC) suits a given proving workload.

Key ideas

• Hardware acceleration: using dedicated hardware, either commercial off-the-shelf (CPU, GPU, FPGA) or custom silicon (ASIC), to run an operation faster or more efficiently than general-purpose software.
• Proof generation overhead: estimated at roughly 1 million to 10 million times the cost of native computation, illustrated with zkEVM and zkVM examples showing overheads from 25,000x to over 100,000x.
• Multi-scalar multiplication (MSM): a sum of elliptic-curve scalar multiplications, highly parallelizable and often the dominant cost in KZG/Groth16-style SNARKs.
• Number-theoretic transformation (NTT): a finite-field analog of the FFT used to multiply polynomials, not easily parallelizable and often the dominant cost in Stark-style systems using FRI.
• Arithmetic hashes: ZK-friendly hash functions like Poseidon, chosen because they are cheaper to represent inside a circuit than traditional hashes like SHA, even though they are costlier to compute natively.
• Modular multiplication as the common bottleneck: MSM, NTT, and arithmetic hashing all reduce, at the hardware level, to large numbers of modular multiplications, which is why hardware platforms are compared by their multiplication throughput.
• Amdahl's law limit: even eliminating the three dominant operations entirely caps the possible speedup at roughly the fraction of time they account for (about 3x if they make up 65% of proving time), so acceleration alone cannot close the full overhead gap.

Walkthrough

Why accelerate ZK proofs (1:03)

The lecture defines hardware acceleration and traces its history from early floating-point co-processors through DSPs, GPUs, TPUs, and cryptographic accelerators for hashing and encryption already built into modern processors and Bitcoin mining rigs. It positions ZK proofs as the newest cryptographic primitive worth accelerating, given estimates that proof generation can cost a million times more than the computation it proves.

Goals of acceleration (6:08)

The lecture distinguishes three goals that shape hardware design differently: throughput (operations per unit time), cost (capital and operational expense per operation), and latency (time to complete a single operation), noting that low latency matters for user-facing cases like ZK bridges.

The three core primitives (8:09)

The lecture introduces MSM, NTT, and arithmetic hashing as the operations that dominate proving time across most systems, though which one dominates depends on the commitment scheme: KZG-based systems lean on MSM, FRI-based systems lean on NTT. It explains that MSM parallelizes easily across independent scalar multiplications, while NTT does not because its elements interact throughout the computation, giving it high memory requirements instead.

Estimating and choosing hardware (15:17)

The lecture shows how to estimate proof-generation performance by counting the number and size of each operation, plus the field and curve size, then comparing that to a platform's modular-multiplication throughput. A worked comparison of a desktop CPU, server CPU, FPGA, and GPU shows the GPU winning on raw multiplication power in this example, due to its combination of multiplier count, size, and clock frequency, while also noting that deployment cost, tooling, and achievable real-world performance also matter.

Building an accelerated implementation (21:18)

The lecture describes the two-step process of picking a hardware-friendly, parallelizable algorithm and then implementing it efficiently, often requiring low-level restructuring. It flags practical pitfalls: memory-access speed and communication bandwidth between host and accelerator often bottleneck real systems more than raw compute, and for small problems, computing directly on the host CPU can beat using an accelerator at all.

Real-world example and outlook (24:24)

Using Filecoin's proof-of-replication as a case study, the lecture reports that GPU acceleration cut Poseidon hashing time from about 100 minutes to about 1 minute, and Groth16 proof generation from about an hour to about 3 minutes. It closes with current GPU performance benchmarks for MSM, NTT, and Poseidon hashing, and four directions for future gains: better algorithms, new low-cost primitives, simpler proof systems designed for hardware, and improved implementations on both commodity and custom silicon.

Before you watch

• Know roughly how SNARK and STARK proof systems are structured, including commitment schemes like KZG and FRI, from earlier lectures.
• Basic familiarity with elliptic curves and finite fields helps with the MSM and NTT sections.

Check your understanding

1. Why is MSM easy to parallelize across hardware cores while NTT is not?
2. What determines whether a proof system's proving time is dominated by MSM or by NTT?
3. Why are ZK-friendly hash functions like Poseidon preferred over SHA inside a circuit, despite being more expensive to compute natively?
4. According to Amdahl's law, why can't accelerating MSM, NTT, and hashing alone close the full million-times overhead of proof generation?
5. Why might communication bandwidth between a host CPU and an accelerator limit performance even when the accelerator has ample compute power?