SP1 Testnet Launch: the fastest, feature-complete zkVM for developers

In its February release, SP1 did not have recursion and onchain verification, limiting it to offchain use-cases. Today, we are excited to announce the implementation of SP1’s performant STARK recursion, enabling blazing fast end-to-end ZK proof generation with onchain verification on any EVM-compatible chain.

With this testnet launch, SP1 is the fastest, feature-complete zkVM for developers. It is the only zkVM that is fully open-source, supports the Rust standard library, has customizable precompiles for state of the art performance, and leverages the latest techniques in STARKs for performant recursion and onchain verification. Furthermore, SP1’s novel precompile-centric architecture for common operations like hashing, elliptic curve operations, and more allows for an order of magnitude performance gain for blockchain use-cases like ZK rollups, ZK bridges, and more. 

Get started with the docs today or clone the project template.

SP1 is the fastest, feature-complete zkVM 

Get started today: Developers can get started by following the installation instructions and creating a new project with “cargo prove new” or cloning the template repo here. Follow the docs to write programs that implement ZK light clients, ZK rollups and more. Using SP1’s SDK, developers can deploy an SP1 EVM verifier to any testnet of their choosing and generate Groth16 proofs that can be verified onchain for ~300,000 gas.

SP1 is the only zkVM with all of the features that developers need:

• Can write Rust (including std) and use existing crates: With SP1, developers can utilize existing Rust crates (including revm, alloy, tendermint-rs, serde, json, etc.) to write verifiable programs. SP1 has standard library support, allowing developers to code in Rust as they normally would.
• Recursion + Onchain verification: SP1 uses performant STARK recursion and a Groth16 STARK to SNARK wrapper to shrink the size of SP1 proofs to one that can be verifiable on any EVM chain for ~300k gas.
• Blazing fast performance: SP1’s novel “precompile-centric” architecture allows for extremely fast and cost-effective proof generation (often by an order of magnitude) for common blockchain applications like ZK rollups (including zkEVMs), ZK light clients and more.
• 100% open-source: SP1 is 100% open-source, with all constraint logic in the open and an MIT licensed codebase. 
• SP1 recursion within SP1: for many use-cases, like proof aggregation or rollups, the ability to verify an SP1 proof within SP1 is critical for chaining together many proofs. SP1 supports efficient SP1 recursion and users can check out an example of this functionality in this example repository.

SP1 Mainnet Timeline: For the past few months, we have been getting SP1 audited by several world-class ZK auditing firms (alongside Plonky 3, one of SP1’s core open-source dependencies). Expect more details on SP1’s mainnet timeline in the upcoming weeks!

SP1 outperforms other zkVMs by an order of magnitude

Over the past few months, SP1’s performance has improved significantly thanks to support for AVX-512 in Plonky3, batched lookup arguments, optimized prover memory usage, and improved arithmetization. We benchmark SP1 and Risc0 on end to end proving time to get an onchain verifiable proof on a suite of realistic programs, including Merkle proof verification, a Tendermint light client and a type 1 zkEVM that leverages Reth. 

We’re excited to see the vision of a precompile-centric architecture for zkVMs become a standard across the industry. RISC0 and Jolt have both recently announced that their roadmaps include adding support for precompiles. It will be interesting to revisit these results when these features get implemented by others.

Note that benchmarking is always a point in time comparison and given the complex, multi-dimensional nature of zkVM performance, any benchmark presents only a simplified view of performance. We choose to benchmark on CPU, similar to the open-source JOLT zkVM benchmark repo, but Risc0 also has support for GPUs.

SP1’s Recursion Architecture 

To build performant recursion, we built an entirely new proving stack (the first open-source zkVM recursion stack) that allows for programmable verification of SP1 proofs.

• Recursion zkVM. A zkVM that implements our recursion-specific ISA (leveraging many similar primitives from our core RISC-V VM) and is heavily optimized for succinct verification.
• Recursion DSL. A custom Rust-based domain-specific-language that natively supports fields, extension fields, accelerated recursion primitives, and ZK-friendly memory. We implement a STARK verification program in this DSL.
• Recursion Compiler. A compiler that compiles programs written in the recursion DSL into multiple target backends, including our Recursion zkVM ISA and a Gnark circuit (used for PLONK-KZG verification of STARK proofs).

We believe that this toolchain, including our recursion DSL and recursion compiler, are generally useful public goods that can be utilized by many different teams to implement recursion for new proof systems, including JOLT and Binius. Please reach out to us if you’re interested in using this tooling and we are happy to provide guidance!

SP1’s updated performance vs. JOLT

We also benchmark SP1 against the newly released JOLT to provide an updated view of how SP1 compares, given its latest performance improvements. JOLT is still a work in progress, and currently does not support recursion or on-chain verification, cannot accelerate workloads with precompiles, has a relatively small upper bound on the maximum cycle count (~16 million), and only supports the RISCV32I variant of RISC-V which does not support instructions for multiplications or divisions. As a result, we can only benchmark JOLT on simple programs, such as their SHA-2 chain program used in their benchmarks (shown below). Nonetheless, given JOLT’s recency and room for further optimizations, we are impressed with its performance and find it quite an interesting line of work. 

We show that SP1 out-performs JOLT for similar proof size and similar cycle count.

Appendix

End to end benchmarking on recursion and time to get to EVM verifiable Groth16 proof.

Benchmarking Methodology

The benchmarking programs can be found in this repo, including Merkle Proof Verification (SSZ withdrawals), the Tendermint ZK Light Client and SP1-Reth. For each program, we generated a proof for both zkVMs, and patched all relevant crates (including the revm, reth, sha2, crypto-bigint, curve25519-dalek and k256 crates). The “# of Cycles'” column is the number of RISC-V instructions executed by the program. The proof generation time is in seconds. Note that the cycle count for the Tendermint and Reth program is provided as 2 numbers because it is significantly smaller in the SP1 zkVM because of SP1's first-class support for precompiles. Note that all the times in the above table do not represent latency as that can be decreased with parallelized proof generation across the core and recursive stages. The core proving time + recursive proving time is the time it takes to get to a constant-sized proof. Note that SP1’s Groth16 wrapper time also includes a “shrinking” stage not present in Risc0 that adds a constant overhead of ~50 seconds, which is why the timing in that phase is longer.

SP1 was benchmarked using the poseidon2 hash function and all standard settings. All other settings were the default Risc0 prover settings in their version 0.21 release. The benchmark was run on a AWS Linux CPU machine (r7i.16xlarge) with 64 vCPUs and 512GB of RAM, with a 3-year reserved pricing of $1.92 per hour.

SP1 vs. JOLT benchmark

We benchmark JOLT with its default settings and SP1 using the poseidon hash function and with a shard size of 2^21 to make the proof size comparable to JOLT’s. The benchmark was run on a AWS Linux CPU machine (r7i.16xlarge) with 64 vCPUs and 512GB of RAM, with a 3-year reserved pricing of $1.92 per hour.

NB: Note that due to the very complex, multi-dimensional nature of zkVM performance (including factors like hardware, single-node vs. multi-node performance, memory usage, recursion cost, hash function selection) these benchmarks only present a simplified view of performance. We tried our best to provide as fair of a comparison as possible, although it is difficult for a single benchmark to capture all nuances.