feltroidprime
commented
2 weeks ago Those are valid points and we need to make a good Risc0 maintained contract indeed. I'm more of the team to only support the latest version or having the mapping offchain and tell people to update + Add CI to check what's the latest or retrieve the different versions.
Need more investigation and talks with RiscZero team. Thank you for raising this.
Feature Request
Describe the Feature Request
In the moment the Risc0 ZKPs should be created by a version of risc0 which has the same ZK constants as the hardcoded values in garaga, e.g.
RISC0_CONTROL_ROOT, RISC0_BN254_CONTROL_IDetc. This leads to inability of usinggaraga verify-onchainbecause of the inbuilt assertions in the python code. There should be a mechanism to have the "constants" dynamically update according the which kind of constants were used to generate the ZKP.Describe Preferred Solution
There should be a python function and a corresponding mapping similar to this which dynamically determines the constants that should be used based on the verifier selectors (the first 4 bytes of the seal). There should be also some kind of CI script, which scans the EVM Transactions for calls to the function
function addVerifier(bytes4 selector, IRiscZeroVerifier verifier)to the RiscZeroVerifierRouter Address since the last garaga version and automatically generates and hardcodes map additions.Describe Alternatives
We could just also push the responsibility on the user and add additional parameter
Ethereum Verifier Addressto thegaraga verify-onchaincommand and then make a lookup on the EVM for the needed constants. Another possibility is to update the code manually on each upstream update.Additional Context
Checkout the
verifiersmapping here. For each of the verifiers there are constants which can be found on their corresponding address, e.g the BN254_CONTROL_ID.If the feature request is approved, would you be willing to submit a PR? (Help can be provided if you need assistance submitting a PR)