Introduction to SP1 zkVM
SP1 end to end, benchmarked against RISC0 on a Taiko block.
TL;DR
- SP1 is a zkVM proof system based on the RISC-V instruction set and STARK. It supports Recursion proofs , enabling the generation of proofs of the same size for the execution process of any program.
- 2. SP1 can convert the STARK proof obtained through Recursion into a SNARK proof using Groth16 or Plonk.
- We make a detail comparison with RISC0 and evaluate the performance of SP1 zkVM on the generation proof for a Taiko block.
1. Purpose
SP1 is a zkVM (zero-knowledge Virtual Machine) proof system based on the RISC-V instruction set and STARK (Scalable Transparent Argument of Knowledge). It supports Recursion proofs , enabling the generation of proofs of the same size for the execution process of any program. Additionally, SP1 can convert the STARK proof obtained through Recursion into a SNARK proof using Groth16 or Plonk, further compressing the proof size.
Since SP1’s proof process is similar to that of RISC0, and we have previously analyzed RISC0’s proof process ( https://medium.com/p/0666216b654b/edit ), we will briefly introduce SP1’s proof process and key steps. Following this, we will compare it with RISC0 and finally discuss the performance, CPU, and memory usage when proving a Taiko block.
2. SP1’s Proof Process
As shown in the figure above, for a program to be proven (composed of numerous RISC-V instructions, compiled from a high-level language such as Rust) and its given input, the SP1 zkVM executes the program and generates a proof file to verify that the program was executed correctly. This proof file must not contain any sensitive information, such as data generated during execution or private inputs.
To achieve this, the SP1 zkVM performs the following steps:
A. Execute the program, split it into multiple Shards/Checkpoints , and record all memory data required for executing each Shard.
B. Generate proofs for each Shard individually using the STARK protocol .
C. Merge the proofs from the previous step into a single proof via Recursion Proving , ensuring that proofs for programs of varying sizes result in a proof file of identical length.
D. Convert the Recursion Proving-generated proof into a SNARK proof using Groth16 or Plonk , further reducing the proof size. Since generating Shard Proofs consumes the most memory and computational resources, the following section will briefly explain the Shard Proof generation process.
3. Generating Shard Proof
As shown in the figure above, when generating a Shard Proof for a program, SP1 employs three independent threads : Checkpoint Generation , Trace Generation , and Shard Proof Generation . This enables parallel processing of multiple tasks, significantly improving performance.
The details are as follows:
A. Checkpoint Generation Thread. This thread executes the program to be proven, splits it into multiple Shards based on a predefined Shard size, and records the instructions within each Shard along with the memory data required to execute them.
B. Trace Generation Thread. For each Shard generated by the Checkpoint thread, this thread sequentially executes the instructions in the Shard, logs the register states and memory access patterns, and ultimately produces a normal execution trace . Notably, all Shards are processed independently, allowing hardware acceleration (e.g., GPU or multi-CPU parallelism) to achieve high performance.
C. Shard Proof Generation Thread. Using the STARK protocol , this thread generates commitments and opening proofs for the traces obtained from the Trace thread, resulting in the final Shard Proof .
4. Generating Recursion Proof
The size of the final proof is roughly proportional to the length of the execution trace of the program being proven. In other words, longer programs result in more Shards (and corresponding Shard proofs), and proof size is a critical metric for proof systems (since proofs must be transmitted from the prover to the verifier).
Get Computation Frontier’s stories in your inbox
Join Medium for free to get updates from this writer.Subscribe
To minimize the final proof size, SP1 supports compressing pairs of adjacent Shard Proofs into Reduce Proofs using the STARK protocol. These Reduce Proofs are then recursively compressed further until a single root proof is generated. This ensures that, regardless of the program size, the final proof size will be fixed-length.
Finally, the root proof at the base of the recursion tree is wrapped into a Groth16-compatible proof for efficient on-chain verification. Figure 3 illustrates this process.
5. SP1 vs. RISC0: Similarities and Differences
5.1. Similarities
Fundamental Principles There is no fundamental difference in their underlying principles. As shown in Figures 1 and 4, both proof processes follow these steps:
A. Split the program into multiple parts ( Segments in RISC0, Shards in SP1).
B. Generate proofs for each part using STARK .
C. Merge the proofs recursively via STARK-based recursion proving .
D. Convert the final recursive proof into a Groth16-compatible proof for verification.
Finite fields which both proof systems operate on are the same finite field structure: base field: BabyBear, extension field: 4-degree extension.
5.2. Differences
Implementation Transparency SP1: Fully open-source CPU implementation (GPU implementation is closed-source). Code is modular and easier to audit. RISC0: Critical components (e.g., trace generation, polynomial checks) are auto-generated via Zirgen , making the code harder to understand or modify.
Hardware Acceleration SP1: Optimized for AVX256/512 and CUDA (closed-source GPU code). RISC0: No SIMD support but supports Metal (Apple GPUs) and CUDA.
Precompile Support SP1: Allows custom precompiles (e.g., elliptic curve operations) by manually designing trace tables and constraints, reducing trace length and improving performance. RISC0: Precompiles are auto-generated via Zirgen, limiting user flexibility to add custom circuits. Proof Generation
Dependencies. SP1: Relies on the Plonky3 library (open-source) for commitments, FRI, and other proof components. RISC0: Implements all components in-house.
6. Proving Taiko Block Performance
To evaluate SP1’s performance in proof generation, we tested a real-world use case: generating a proof for a Taiko block using SP1 and verifying its correctness locally.
We measured the runtime, CPU usage, and memory consumption. The results are as follows.
Test Configuration: Hardware: AMD Ryzen 9 9950X 16-Core Processor, 96 GB RAM. Block Details: Gas limit of 5,944,801 (5.9 million), total cycles counted during proof generation: 488,808,529 (488 million).
Results: Total Proof Generation Time: ~1.5 hours. Shard Proofs Phase: ~1 hour, with memory peaking at 50 GB during the final Shard Proof generation. Recursion Proof Phase: ~0.5 hours, primarily spent merging proofs. CPU and Memory Usage: The figure below shows the CPU and memory utilization during the proof generation process.
