You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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_ID etc. This leads to inability of using garaga verify-onchain because 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 Address to the garaga verify-onchain command 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 verifiers mapping 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)
Yes
No
I think this is a very serious PR so I think that most likely this issue should be split in several smaller ones. I can help with some them.
The text was updated successfully, but these errors were encountered:
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.
feltroidprime
changed the title
feat: Implement a python equivalent of the verifier selector map in RiscZeroVerifierRouter.sol
feat: Implement an equivalent of the verifier selector map in RiscZeroVerifierRouter.sol
Oct 18, 2024
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_ID
etc. This leads to inability of usinggaraga verify-onchain
because 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 Address
to thegaraga verify-onchain
command 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
verifiers
mapping 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)
The text was updated successfully, but these errors were encountered: