rsp
A minimal implementation of ZKPs of Ethereum block execution using Reth. Supports both Ethereum and OP Stack.
RSP generates zero knowledge proofs of EVM block execution
RSP is a minimal implementation that proves EVM block execution with Reth and the SP1 zkVM, covering Ethereum and OP Stack.
What RSP proves
RSP is a minimal implementation of generating zero knowledge proofs of EVM block execution. The README states it uses Reth as the base and supports both Ethereum and OP Stack, so the same approach applies to the Ethereum mainnet and to OP Stack based chains. The point is to produce a cryptographic proof that a block was executed correctly without rerunning the whole chain, which is the kind of primitive that layer two and bridging systems rely on.
The project links to hosted documentation at succinctlabs.github.io/rsp for users and developers. The README keeps the front page short and points readers there for deeper explanation. The proof covers block execution, meaning the transition from one state to the next as a block's transactions are applied, rather than a single transaction or a full historical replay. By calling itself minimal, the project signals that it aims to be a clear reference implementation instead of a feature heavy product. It builds directly on Reth's execution components, which the README names as the source of the block execution logic, and on SP1, which provides the zero knowledge virtual machine that actually runs the client program and produces the proof. The scope is narrow by design. That narrowness is intentional: a small, readable codebase is easier to audit than a larger one, which matters for cryptographic tooling.
How it is structured
The system splits into two halves. A host CLI prepares the execution data and orchestrates the proving process. A client program runs inside the zero knowledge virtual machine, which is SP1, and generates the proof. This host and client split is the standard shape for SP1 based projects: the host does the cheap setup and coordination on an ordinary machine, while the client runs the actual provable computation inside the zkVM.
The repository reflects that split in its layout. A book directory holds the documentation for RSP users and developers. The bin/client directory holds the program that runs inside the zkVM, and bin/host holds the CLI that prepares the proving process. A crates directory holds the RSP components such as the host and client executors. The README's own text repeats bin/client twice in its list, which reads like a small typo in the description, but the intent is clear: client code and host code live in separate bins and share logic through the crates folder. A contributor building from source would work across these four areas, with the book directory explaining how they fit together and the bins and crates providing the runnable and reusable pieces. The README keeps the description of each directory short, so the book directory is the place to look for the longer explanation of how a proof is assembled.
Status and dependencies
The README attaches a caution note to the whole repository. It says the project is still an active work in progress and is not audited or meant for production usage. That warning is direct and should set expectations: the code is a reference and research effort, not something to drop into a live bridge or wallet without further review. The note also implies the API and internals may shift as development continues.
Two external projects make RSP possible, and the README lists them under acknowledgments. Reth is described as a highly modular Ethereum execution layer implementation, and it supplies the execution machinery RSP proofs about. SP1 is described as a fast and feature complete zkVM for developers, and it is the environment where the client program actually runs. Both are linked from the README, Reth to its site and SP1 to its GitHub repository. The dependency on these two projects is central: RSP is essentially the glue that points Reth's block executor at SP1's prover. Because neither the license nor a release version is stated on the front page, anyone evaluating RSP should check the repository for those details before depending on it. The caution note is repeated in the README rather than buried in a separate file, so the work in progress status is hard to miss.
Editorial conclusion
RSP is written in Rust and hosted at github.com/succinctlabs/rsp.
Community notes