Generate public inputs for verifier also via ConstraintSystem API

[Pratyush]

Problem Definition

Right now, when the verifier needs to verify the public input, they have to implement and call ToConstraintField on the input. This is error prone for two reasons:

• the order of calling ToConstraintField on various parts of the public input must match exactly the order of new_input calls in the ConstraintSynthesizer.
• the impl inside ToConstraintField must match that of new_input exactly, leading to another source of errors.

Proposal

I propose that we instead leverage the existing ConstraintSystem API to generate these inputs: we add a Verifier variant to the Mode enum, which generates variable assignments only for instance/input variables.

My only worry is that this could cause extra memory/computation for the verifier, but we can at least try it and see. I have two ideas to minimize this overhead:

• a way to minimize these costs alternative would be to provide ConstraintSynthesizer with a finalize_public_input_generation method that allows it to specify when it has completed generating public inputs, so that it can early return.

• Make a related instantiation of ConstraintSynthesizer that only generates public inputs, and does not have the rest of the circuit logic. This is still better than the ToConstraintField idea because it is easy to match up the new_input statements on both sides.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[Pratyush]

what do y'all think, @ValarDragon @weikengchen @npwardberkeley?

[weikengchen]

I agree. We should add a Verifier mode. This is useful in general.

As for the two optimizations, we feel they are not very crucial for now---but surely good to have. If we are unable to get both of them done it should still be fine since one who really wants a very efficient verifier can still do ToConstraintField themselves.

[weikengchen]

That said, it is better that we still leave an interface for one to run the verifier with a list of field elements, for compatibility and for use cases where the verifier cost needs to be very low.

[Pratyush]

That said, it is better that we still leave an interface for one to run the verifier with a list of field elements, for compatibility and for use cases where the verifier cost needs to be very low.

Yeah I was thinking the same

[Pratyush]

Make a related instantiation of ConstraintSynthesizer that only generates public inputs, and does not have the rest of the circuit logic. This is still better than the ToConstraintField idea because it is easy to match up the new_input statements on both sides.

Note that the above approach is compatible with this requirement:

That said, it is better that we still leave an interface for one to run the verifier with a list of field elements, for compatibility and for use cases where the verifier cost needs to be very low.

This is because you set the VerifierInputSynthesizer to directly call to_constraint_field, instead of going via the constraint system API