-
Notifications
You must be signed in to change notification settings - Fork 360
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
bug: Using Range Checking component leads to incorrect # of inputs in Solidity verifier #860
Comments
Hi, this is a known issue: #524 In short, we use something called commitment API in range checking which on a high level is a way to compute an efficient in-circuit challenge. The verifier has to do a bit more work to actually verify the correctness of the challenge and we haven't implemented it yet in the Solidity Groth16 verifier. It is there though for PLONK verifier. It is quite high on our list, we just have few other more pressing priorities right now. |
@ivokub thanks for the quick response! I apologize--I didn't realize that this was already an issue. Is there a easy way to add this to the Solidity groth16 verifier? Would it be basically re-implementing the logic here in Solidity? I believe this issue would also need to be resolved around including this information in the serialized vkey as well? In particular, for our circuit we notice that the groth16 version has 6 million constraints, but the Plonk version has 20 million. Also the pkey size is significantly smaller with groth16 as well as proof generation time, which is why we're motivated to use groth16 if possible. (Although the constraint count grows significantly if we don't use the range-checker, which is why we want to use the range-checker + groth16). |
No need to apologize -- that issue was a bit poorly worded and lacks issue description. I added it mostly for backreference :) Yup, there is about 4x blowup from Groth16 to PLONK. But usually the deciding factor to go with PLONK is that it doesn't require circuit-specific trusted setup (can reuse existing setup for KZG SRS). For Groth16 trusted setup is needed though (but there is an MPC implementation for generating the trusted setup in distributed manner. But its a bit slow for now). In essence, yes, you should follow the verifier logic in the native verifier. Additionally you need hash-to-field in Solidity what we have already implemented for PLONK verifier (see here). I'm right now not 100% sure, but I think #580 may already be obsolete. Pinging @gbotrel and @Tabaie, maybe you have anything to add? We're actually quite interested in having the commitment verification in Groth16 Solidity verifier, but probably won't be able to get to it in a few months, unfortunately. |
Thanks @ivokub yes I think you covered everything. |
By the way, @ivokub has there been any update on implementation of a Solidity verifier for groth16 using the logup range checking component? We profiled a groth16 circuit with and without the logup range check and found that the proving time was 5x faster using logup, so it would be great to be able to use logup +groth16 with onchain verification! |
see --> #1063 |
Implemented in #1063 |
Description
In a simple circuit when using the range checking component (as shown in a simple test example below), the
Verifier.sol
that is exported has4
public inputs, even though the circuit only has 3 public inputs. When generating a proof and outputting the public witness to verify the proof in Solidity the public witness has only has 3 public inputs (which makes sense). What is the 4th public input that should be passed to the on-chain verifier?Note that the generated proof still verifies in
go
when usinggroth16.Verify(proof, vk, publicWitness)
. If the rangecheck component is removed, then the generatedVerifier.sol
has the correctverifyProof
function signature with 3 public inputs.Generated
Verifier.sol
function signature:The text was updated successfully, but these errors were encountered: