Circuit Design for variable sized inputs

[shreyas-londhe]

I came across this issue when I compiled the circuit with more number of variables. But then when I passed less number of variables, it gave me this error. Not sure why I'm getting this error. My circuit logic demands that the inputs will be of variable length everytime. is there a workaround? Any help will be appreciated, thanks!

TLDR - How to design circuit and compile for variable sized inputs.

[gbotrel]

hi -- not sure what you mean by "variable sized inputs". Constraint systems (i.e circuits) have fixed-size input at compile time. Do you have a code sample you can share?

[ivokub]

Have a look at the Groth16 verifier gadget https://github.com/ConsenSys/gnark/blob/develop/std/groth16_bls12377. The only caveat with the gadget is that it is only possible to recursively verify proofs on a 2-chain of curves. This means that if you generate the proof on BLS12-377 (or BLS24-315), then it can only be verified on BW6-761 (respectively BW6-633).
This has to do with the compatibility of the base and scalar fields of the corresponding curves. If the fields are not compatible then we would need to use some alternative methods, which are either not implemented yet or very inefficient. See https://medium.com/delendum/field-selection-for-recursive-snarks-726ad56c3a3c for longer explanation.

There is additional way to compress the recursive checks using SnarkPack, but gnark doesn't yet support it out-of-box.

[shreyas-londhe]

Thanks for such a detailed answer!

I'm using the curve BN254 for my circuit and even the hash function and everything uses BN254, so does that mean that I'll have to shift to BLS12-377 in order to use recursive proofs or is there some other workaround?

[ivokub]

Short-term there isn't a better solution than to change the underlying curve. Currently the only viable alternative would be to verify the Groth16 proof using non-native arithmetic, but it is really-really inefficient. The ideas is that we can emulate any field on any scalar field (i.e. any curve), but this needs a lot of binary decompositions and this adds up to a lot of constraints, making proof generation quite time-consuming. I haven't myself tried it out, but theoretically it should be doable (maybe you would have to reimplement Groth16 verifier gadget to take as inputs nonnative.Element values, not frontend.Variable values). Check the field emulation gadget in std/math/nonnative. It is currently only available in develop branch.

[ivokub]

Long-term we are looking into instantiating proof systems on any field, but it is still yet very early.

[shreyas-londhe]

Thank you so much for this answer. So I think the only way for me to move forward is to set a max number of constraints and fill in dummy values.