-
Notifications
You must be signed in to change notification settings - Fork 7
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
Use default_prover #110
Use default_prover #110
Conversation
…0-ethereum into victor/use-risc0-main-on-main
…0-ethereum into victor/use-risc0-main-on-main
…e-risc0-main-on-main
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! This is a very helpful refactor
contracts/src/groth16.rs
Outdated
uint256[2] c; | ||
} | ||
} | ||
pub struct Seal {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why have this type? It seems to simply be a container for the ABI encoding methods, and with that I think we might as well drop the struct and simply have the methods live on the module.
@@ -47,7 +47,7 @@ abstract contract RiscZeroCheats is CommonBase { | |||
/// Uses the Bonsai proving service to run the guest and produce an on-chain verifiable | |||
/// SNARK attesting to the correctness of the journal output. URL and API key for Bonsai | |||
/// should be specified using the BONSAI_API_URL and BONSAI_API_KEY environment variables. | |||
function prove(string memory elf_path, bytes memory input) internal returns (bytes memory, bytes32, bytes memory) { | |||
function prove(string memory elf_path, bytes memory input) internal returns (bytes memory, bytes memory) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the comment above is out of date now, with no post state digest.
…/refactor-zkvm-usage
…0-ethereum into capossele/refactor-zkvm-usage
… to match zkVM 1.0 (#124) In risc0/risc0#1841 where changes to the control root (due to an updated `resolve` program) as well as a changes to how the `Gorth16ReceiptVerifierParamters` are hashed. This PR addresses those.
Co-authored-by: Victor Graf <victor@risczero.com>
More context here #91 (comment) This is built on #110 Draft until: - [x] Update examples and usages to new API - [x] Add docs - [x] Deprecate `ViewCall` constructor - [x] Update old deprecation warning to point to this API - [x] Remove function added in pull 91, as that was between released versions (keep if this comes in after release) Although I think this API is better for now and to future proof, I don't feel strongly about any names or specific APIs. My goal was to try to match alloy as close as possible, while keeping necessary patterns or naming that existed before (also to minimize breaking changes like re-using `ViewCall`. Opinions or comments welcome! This _should_ only give deprecation warnings from 0.10 Details that might be missed: - Generic bounds loosened at type level (where it made sense to) - `new` and `preflight` are the constructors for `Contract`. They both have the `call` method at the end of the chain, but the guest one implicitly unwraps the error. I don't love this pattern, but I'm matching the existing one - Happy to give argument of why we maybe should have it both return a result - Contract and view call types moved into `contract.rs` - `SteelEnv` trait the internal implementation is based on is kept pseudo-public, to avoid exposing the trait type to the public API. Just used to be able to use `CallBuilder` in a generic way internally. - This doesn't lend the APIs well for people to create their custom implementations outside of our supported ones. Intentionally so that the API surface we have to maintain is smaller, at least until someone asks for this. --------- Co-authored-by: Victor Graf <victor@risczero.com> Co-authored-by: capossele <angelocapossele@gmail.com> Co-authored-by: Wolfgang Welz <welzwo@gmail.com>
Closes #77