Introducing SP1 Reth: A performant type-1 zkEVM built with SP1

We’re excited to announce SP1 Reth: an open-source proof of concept that showcases how any rollup can build a performant (type-1, bytecode compatible) zkEVM with less than 2000 lines of maintainable Rust code using SP1. SP1 Reth is an early POC, but already achieves incredible performance (around $0.01-$0.02 proving cost for an average Ethereum transaction) by leveraging SP1’s open-source, customizable precompile system, with substantial improvements to come. SP1 Reth points to a future where all rollups can become ZK rollups, utilizing the magic of ZKPs with maintainable software written in Rust.

The future of EVM rollups is a maintainable zkEVM, written in Rust.

Optimistic rollups face many challenges: 7 day withdrawal times, complicated interoperability, and (in some cases) reliance on multisigs in production instead of a fraud proof mechanism. ZK rollups leverage cryptographic truth and provide a solution to these problems, making them the endgame solution for scaling Ethereum. But today, creating a zkEVM requires a long, expensive development period from a specialized team with expertise in hand-rolling a custom ZK stack.

This complex process is why we built SP1:  a 100% open-source, customizable zkVM with performance competitive with custom circuits. With SP1, any rollup team can build a zkEVM in Rust that reuses components from existing open-source libraries and node software, with performance good enough for practical use.

The SP1 Reth proof of concept leverages existing components from the open-source Ethereum ecosystem (Reth, Revm, Alloy, Zeth) with less than 2000 LOC, and generates a ZKP of execution of full Ethereum blocks (proven with SP1). This approach has significant advantages over the status quo of zkEVMs built with custom circuits.

Because of code reuse, SP1 Reth is far more maintainable and secure, with a smaller audit surface compared to custom circuits. The usage of normal code allows for any developer to easily customize the zkEVM when adding new precompiles or making other changes.  Finally, the development time for SP1 Reth is 100x faster than with custom circuits and requires no specialized expertise.

Leveraging SP1’s open-source, customizable precompile layer for state-of-the-art performance

SP1 is 100% open-source and fully customizable, with a “precompile” system that can accelerate almost any performance bottleneck without much additional recursion overhead. This precompile system is critical for achieving SP1 Reth’s state-of-the-art performance.

SP1 Reth achieves $0.01-0.02 proving cost on typical Ethereum transactions

We benchmark SP1 Reth’s performance on a range of Ethereum blocks, showing state-of-the-art results on proving cost: $0.01-0.02 average proving cost per transaction in typical Ethereum blocks. Rollups already pay Ethereum between $0.10-$0.25 for calldata for L2 transactions–making the $0.02 cost for a ZKP of transaction execution negligible compared to DA costs, and quite practical for most L2s today.

Our benchmarks measure end-to-end proving time on a single AWS machine with 64CPUs and 512GB of RAM. Cost is calculated based on AWS reserve pricing. In production, latency can be significantly decreased with parallelized proving across a cluster. See our appendix for a detailed methodology.

Recently, Polygon Zero announced a type 1 compatible zkEVM with custom plonky2 circuits with proving costs of $0.2-0.5 per block ($0.002 to $0.003 per transaction). This benchmark shows that with a 100% open-source, customizable zkVM like SP1, the cost of proving a zkEVM implementation written in a general-purpose language is already within an order of magnitude of the cost of custom circuit-based approaches (currently 5-6x).

The Key Insight: Leveraging Precompiles for SOTA performance

Previous general-purpose zkVMs have required large clusters for proving zkEVM programs with a cost of ~$10-20 of compute per block. SP1 Reth leverages SP1’s precompile system for an order of magnitude reduction in cost, making proof generation of a zkEVM written in Rust finally practical.

SP1’s 100% open-source and customizable precompile system is the key reason why SP1 Reth’s performance is competitive with custom circuits. The key insight is most of the time spent verifying execution of an Ethereum block is in repetitive, expensive cryptographic operations like hash functions or signature verification. With SP1’s multi-table, precompile-centric architecture, the cost of “precompiles” for these operations is very similar to the cost one would pay in a circuit. Because overall cost is dominated by these precompiled operations, the overhead of a zkVM ends up mattering very little: the 80-20 principle in action.

SP1 Reth uses the precompiles that SP1 has to offer today: keccak, secp256k1, and sha256. But because SP1 is 100% open-source and customizable, there is a clear path to further reductions in proving cost, as other performance bottlenecks can also be precompiled, including big integer arithmetic and more. If you want to become an open-source contributor and help us on this mission, check out the list of Github issues in SP1 today.  

Orders of magnitude improvements to come

SP1 Reth is a simple POC and only a preview of what is possible with SP1. There are several orders of magnitude improvements on the way that we are excited about.

Precompile BigInt: Ethereum uses 256 bit arithmetic, resulting in a significant amount of zkVM cycles being spent in BigInt operations. It is straightforward to add a BigInt precompile to SP1 that will reduce this performance bottleneck. 

Optimized Serde/Deserde: Right now, many of the zkVM cycles are spent on memory operations around serializing and deserializing inputs. It should be possible to utilize more efficient zero-copy Serde/Deserde libraries that reduce cycle count and improve performance significantly.

Specialized Hardware on the Succinct Proving Network: The Succinct proving network will provide a competitive marketplace for the best hardware teams to compete on proof generation costs by leveraging custom hardware–making costs go down another 10-100x.

Build with SP1 Reth or SP1

The code for SP1 Reth can be found at: https://github.com/succinctlabs/sp1-reth and the code for SP1 can be found at: https://github.com/succinctlabs/sp1. Note that SP1 and SP1 Reth are in alpha and not intended for production use. Start building with SP1 today: https://succinctlabs.github.io/sp1/. 

Contribute to SP1: If you’re interested in contributing to SP1 itself, check out the list of open issues in the Github repository!

If you are a rollup team interested in building with SP1 or extending SP1 Reth, please reach out to us by filling out this form.

Acknowledgements

SP1 Reth leverages a lot of high-quality, open-source work in the Ethereum ecosystem, including Reth, Revm, Alloy and Zeth. SP1 Reth utilizes core execution primitives from Reth & Revm, RPC types from Alloy, and a MPT library as well as inspiration on execution from Zeth (a zkEVM built with Risc0’s zkVM). We also want to acknowledge Polygon Zero’s plonky2 zkEVM that is type-1 compatible and utilizes plonky2 circuits.

Appendix

Benchmarking Methodology:

The benchmarking code was run from the sp1-reth repository: https://github.com/succinctlabs/sp1-reth. The details on how the benchmark was run can be found by running the command in the README.

We ran SP1 with the Poseidon hash function and shard size of 2^19. The benchmark was run on a AWS i4g.16xlarge Linux machine with NVME disk IO  with 64 vCPUs and 512GB of RAM, with a reserved pricing of $2.286 per hour and a spot pricing of $1.928 per hour. We used the reserved pricing for computing our proving costs. The end-to-end proving time does not include fetching of witnesses or runtime execution time, as that is single-threaded and would be run on a separate, inexpensive machine with a single CPU in a production setting.

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 an intellectually honest assessment of cost, although it is difficult for a single benchmark to capture all nuances. Also because SP1 is still a work in progress, the performance numbers are not final and are expected to improve over time.