-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor prover to use the risc0-zkvm API #92
Comments
Waiting on risc0 1689 before being able to move forward with this. |
nategraf
added a commit
to risc0/risc0
that referenced
this issue
May 2, 2024
… `Prover::compress` (#1762) This PR adds support for producing a `CompactReceipt` through the `BonsaiProver` impl of the `Prover` trait. This unblocks moving proving in `risc0-ethereum` and the Foundry template to the `risc0-zkvm` API (risc0/risc0-foundry-template#92), and helps simplify the implementation of receipt metadata (coming in a PR soon). This PR additionally fixes up some missing logic in the `Prover::compress` implementations, and changes the semantics of `opts.receipt_kind`. With this PR, the receipt kind field is interpreted a _minimum_ compression level, rather than exact. As a result, it is no longer an error to call `compress` on a `Compact` receipt, with `ReceiptKind::Succinct`. Instead, it is a no-op. I believe this better aligns with the expectation of a caller, and prevents needing to check the receipt type before calling compress. --------- Co-authored-by: Erik Kaneda <[email protected]> Co-authored-by: Frank Laub <[email protected]>
Unblocked by |
Merged
Related to |
Fixed by #106 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently the Foundry template includes code to call Bonsai with the Bonsai SDK. Proving with Bonsai is also provided under the unified API with
risc0-zkvm
, and this API is a much better user experience. We should refactor the template to use therisc0-zkvm
API and drop theBonsaiProver
type. This may require changes to therisc0
monorepo.Note that using the
risc0-zkvm
API does not immediately mean support for local proving. The blocker for local proving as an easily supported mode is the fact that the only prover option that works today is rapidsnark, and rapidsnark does not integrate nicely with our Rust workflows. As a result, we cannot yet provide a seemless local proving experience for Groth16, as some of the steps are manual and require Docker on x86 to run.Resolved by: #106
The text was updated successfully, but these errors were encountered: