feat(sp1): Add zkVM-based fault proofs via SP1 integration#3051
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests.
☔ View full report in Codecov by Sentry. |
Integrate SP1 zero-knowledge proof capabilities into the Kona monorepo, derived from OP-Succinct, to enable validity proofs for OP Stack state transitions. This provides an alternative fault proof mechanism that generates cryptographic proofs of execution verifiable on-chain. kona-sp1 is _experimental_. This PR establishes the initial crate structure and foundational logic that future work will build on. The SP1 integration is not yet complete; the goal here is to land a clean, minimal baseline. Code from [OP-Succinct](https://github.com/succinctlabs/op-succinct) has been brought into the repo with the following adjustments: - Renamed crates with the kona-sp1- prefix - Removed Eigenda and Celestia support - Removed Hokulea and Hana programs - Restructured modules to follow Kona’s layout conventions - Merged range-ethereum and range-utils into a single crate
Inphi
requested review from
einar-oplabs,
emhane,
op-will and
theochap
as code owners
There was a problem hiding this comment.
Pull request overview
This PR integrates SP1 zero-knowledge proof capabilities into the Kona monorepo, derived from OP-Succinct, to enable validity proofs for OP Stack state transitions. The implementation provides an experimental alternative fault proof mechanism that generates cryptographic proofs of execution verifiable on-chain.
Key Changes:
- Addition of SP1 zkVM programs for range proofs and aggregation
- Host and client utilities for witness generation and proof orchestration
- Ethereum-specific data availability support
- Build infrastructure and ELF binary management
Reviewed changes
Copilot reviewed 53 out of 57 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| sp1/programs/range/src/main.rs | Main zkVM program for verifying L2 block state transitions across a range |
| sp1/programs/aggregation/src/main.rs | Aggregation program to combine multiple range proofs into a single proof |
| sp1/crates/client/ | Client-side utilities for witness execution, precompiles, and types |
| sp1/crates/host/ | Host utilities for witness generation, fetching, stats, and logging |
| sp1/crates/ethereum/ | Ethereum-specific DA implementations for both host and client |
| sp1/crates/proof/src/lib.rs | High-level proof utilities for SP1 integration |
| sp1/crates/elfs/src/lib.rs | Management of compiled ELF binaries for zkVM programs |
| sp1/crates/build/src/lib.rs | Build utilities for compiling SP1 programs |
| Cargo.toml | Workspace configuration adding SP1 dependencies and crate members |
| deny.toml | Security advisories for unmaintained dependencies and license clarifications |
| .github/codecov.yml | Code coverage exclusion for experimental SP1 code |
| sp1/README.md | Documentation explaining the SP1 integration structure and usage |
| sp1/LICENSE-THIRD-PARTY | Attribution for OP-Succinct derivative work under MIT license |
| sp1/justfile | Build recipes for compiling ELF files with cargo-prove |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@Inphi can you fix the |
| # Ignore noop files | ||
| - "**/noop.rs" | ||
| # TODO(inphi): Remove sp1 ignore once tests are added | ||
| - "sp1/**/*" |
There was a problem hiding this comment.
I think it is fine not to ignore sp1. I'd rather see code coverage actually decrease than having a fake coverage info
There was a problem hiding this comment.
The codecov thresholds are pretty low - https://github.com/op-rs/kona/blob/main/.github/codecov.yml#L15. Preventing the PR from being merged with a drop in coverage. Would you be open to relaxing the ci check?
| Bytes48::from_slice(proof).map_err(|_| PrecompileError::BlobVerifyKzgProofFailed)?; | ||
|
|
||
| KzgProof::verify_kzg_proof(&commitment, &z, &y, &proof, &self.kzg_settings) | ||
| .map_err(|_| PrecompileError::BlobVerifyKzgProofFailed)?; |
There was a problem hiding this comment.
nit: Since all of the BlobVerifyKzgProofFailed wrap a KzgError, I'd actually make sure the BlobVerifyZkgProofFailed contains the inner failure reason so that we can know what exactly failed in the verify_kzg_proof
There was a problem hiding this comment.
BlobVerifyKzgProoFailed is a flat variant that doesn't wrap anything. We could add a custom failure reason using PrecompileError::Fatal(err.to_string()). But this would be unconventional. Revm itself doesn't include the inner failure reason and opts to return a BlobVerifyKzgProofFailed.
|
|
||
| Ok((oracle, beacon)) | ||
| } | ||
| } |
There was a problem hiding this comment.
This looks a lot like our oracle providers. We should probably think of merging this with the kona-proof structs in some follow-up work
There was a problem hiding this comment.
I don't think so.
We need a fully in-memory oracle for the sp1 proof as all the witness must be loaded up front into the zkvm.
But the fpvm proof oracle isn't and cannot be adapted into this model because it'll be too expensive to load them into the fault proof.
| /// on-chain, so switching to a different hash function is not a concern, as long as the config hash | ||
| /// is consistent with the one on the contract. | ||
| pub fn hash_rollup_config(config: &RollupConfig) -> B256 { | ||
| let serialized_config = serde_json::to_string_pretty(config).unwrap(); |
There was a problem hiding this comment.
Not an immediate concern but using serde_json here could be an issue. Json is not a determinstic serialization scheme and things like HashMaps or HashSets or anything with a hasher won't be deterministically encoded. We should think about using serialization formats like https://docs.rs/borsh/latest/borsh/. Probably worth opening an issue
There was a problem hiding this comment.
I agree. We plan on replacing the rollup config hash with the l2 chain ID. This doc goes over the details - https://www.notion.so/oplabs/op-succinct-Program-Alterations-2aaf153ee16280489147ca821da0ce48?pvs=26&qid=1%3A77c2afb8-172a-4b81-8616-1077cabea0a0%3A2.
| #!/usr/bin/env bash | ||
|
|
||
| cd programs/range | ||
| ~/.sp1/bin/cargo-prove prove build --elf-name range-elf-bump --docker --tag v5.2.2 --output-directory ../../elf |
There was a problem hiding this comment.
How do I set up the .sp1 dir? Is there a just recipe to easily install cargo-prove
There was a problem hiding this comment.
You have to install sp1 toolchain to do this. See https://docs.succinct.xyz/docs/sp1/getting-started/install.
I'll set this up in github CI later once we're in a good state to begin testing all of this.
| "Zlib", | ||
| "0BSD", | ||
| "CDLA-Permissive-2.0", | ||
| "LicenseRef-BOSL", |
There was a problem hiding this comment.
What is that license? Just making sure we know that we can use it
There was a problem hiding this comment.
It's the Bootstrap Open Source License. Derivative works have to make the source available if they're distributed. Which is compatible with the software we build and most downstream consumers of kona that I could think of. But maybe not all?
| kzg_rs::Bytes48(*commitment.to_bytes()), | ||
| kzg_rs::Bytes48(*proof.to_bytes()), | ||
| ) | ||
| } |
There was a problem hiding this comment.
All this host code can be combined with kona-host in a follow-up work
There was a problem hiding this comment.
Similar to my other comment, blob retrieval in kona-sp1 differs from kona-fpvm. The host currently collects all blobs into memory so they can be efficiently loaded into the SP1 VM. While we could refactor this to use the OracleBlobProvider
to load blobs on demand when generating an SP1 proof request, it would introduce some inefficiency.
theochap
left a comment
theochap
left a comment
There was a problem hiding this comment.
Looks good. I left a bunch of nits. Most of them can be tracked in follow-up issues. I am approving to unblock the PR, feel free to merge whenever you feel comfortable with the state of that PR. I'm okay merging as is and tracking all the comments as follow-up PRs.
|
This pull request has been automatically marked as stale because it has been inactive for 3 weeks. |
Integrate SP1 zero-knowledge proof capabilities into the Kona monorepo, derived from OP-Succinct, to enable validity proofs for OP Stack state transitions. This provides an alternative fault proof mechanism that generates cryptographic proofs of execution verifiable on-chain.
kona-sp1 is experimental. This PR establishes the initial crate structure and foundational logic that future work will build on. The SP1 integration is not yet complete; the goal here is to land a clean, minimal baseline that is syntactically correct.
Off-chain op-succinct integration
Code from OP-Succinct has been brought into the repo with the following adjustments: