Breaking the hashes-proven-per-second world record on Vitalik’s laptop
Ingonyama, a leading expert in vertically integrated Zero-Knowledge (ZK) provers, and the Starknet Foundation, which supports the development and growth of the Starknet ecosystem, a secure scaling technology bringing Ethereum’s benefits to the world, are excited to announce a partnership focused on prover infrastructure for the Starknet ecosystem.
Starknet is powered by a robust ZK prover, developed, maintained and operated by Starkware, pioneers in the field of ZK for scaling. Soon Stwo, the new generation of prover tech from Starkware, will merge into the network. We are here to make sure it enjoys the optimal hardware support.
As of today, Stwo prover holds the world record for prover speed with a whopping 620,000 Poseidon2 hashes proven per second on an M3 laptop. We aim to break this world record by running Stwo end-to-end on an NVIDIA GPU using ICICLE.
Stwo
Stwo is a Rust-based implementation of StarkWare’s next-generation STARK prover, intended to replace the current Stone prover. At its core, Stwo leverages the recent Circle STARK innovation, allowing it to run efficiently on the Mersenne31 field. The Stwo prover boasts several notable properties. It is:
- Extremely efficient
- Easy to run
- Implemented in a modular way
In a recent talk at StarknetCC, Vitalik described his adventures in building and optimizing a Circle STARK prover in Python. A gentle introduction with technical details can be found in Vitalik’s blog post and the excellent LambdaClass blog post. See the Stwo demo breaking the world record for hash provers here. Our goal is to break this world record by running Stwo end-to-end on an NVIDIA GPU.
What are we Measuring?
Benchmarking Zero Knowledge (ZK) Proofs is known to be complex and lacks a standard, a challenge we discussed in our ZK Score blog post. We find the hashes-proven-per-second (HPPS) metric used by Starkware to be particularly useful because it is easy to benchmark and is a determining factor for many blockchain use cases today. For example, HPPS is relevant for statelessness with a binary Merkle tree, aggregating hash-based signatures and proofs, and data availability sampling with Merkle trees instead of KZG.
Benchmarking
We have two reasons for choosing GPUs over other accelerators. First, GPUs have demonstrated strong performance results for ZK prover workloads and are used by leading projects implementing STARKs with similar field sizes, such as Risc0. Second, referring back to Vitalik’s talk, the first optimization he made was transitioning to a GPU; the NVIDIA 3070 gaming GPU found on his laptop. Our choice of hardware aims for the most common hardware accelerator available today, which is easily accessible if not already present on your work or home machine.
Building on ICICLE
In his talk, Vitalik suggested the idea of “Zorch”, which offers a PyTorch-like development experience but for ZK proving. PyTorch is a popular framework for implementing AI over CPUs and GPUs. According to Vitalik, the goal of Zorch is to enable writing ZK provers in high-level languages while abstracting low-level arithmetic and memory management of the accelerator. For instance, the framework will decide between copying and editing-in-place.
In fact, ICICLE is just that. Originally a CUDA library with kernels for computational bottlenecks encountered in ZK, ICICLE v2 introduced a polynomial API which allows for running provers end-to-end on the device. Stwo’s fantastic modular architecture and implementation make it a great target to implement on ICICLE.
The upcoming ICICLE v3, which decouples the CUDA backend from the ICICLE API, will allow the same ICICLE-based Stwo to run natively on different platforms. The API will make ICICLE a “plug & play” backend hardware architecture, abstracting hardware-specific details from users and enabling the execution of complex computations across various backends including CPUs, GPUs (via CUDA, METAL, and others), ZPU (ZK Processing Unit), and potentially other specialized devices. This means users will not need to manage or understand the underlying hardware specifics, making it easier to integrate ICICLE (and Stwo) into various environments, including client-side proving.
Roadmap
Ingonyama’s collaboration with Starkware and the Starknet foundation dates back to mid-2023. We have been hard at work exploring hardware acceleration for the current Starknet prover, Stone, and more importantly, ways to make it more cost-efficient to run. ICICLE now supports the 252-bit STARK field. We encourage teams building stand-alone Stone-based applications to reach out. We would love to help with hardware support!
In recent months, our focus has shifted to Stwo and the goal stated above. As usual, our work is fully open source. You can track our progress by following the updates on our fork of Stwo, where we integrate the GPU code from ICICLE piece by piece and check for correctness. The first version will be ready by the end of this year.
Once ready, we will continue to iterate and improve performance. Our algorithms team already has some promising directions saved for future iterations. We also expect to benefit from relying on ICICLE with the upcoming support for client-side proving, which will apply to Stwo as well.
Looking Forward
There are exciting times ahead! We are grateful for the opportunity to contribute to the Starknet ecosystem. We would like to thank Starkware and the Starknet foundation, and in particular Uri, Eli, Avihu, Louis, Diego and Derek.
