Add entry inequality module to GPC #1892
Conversation
| "maxLists": 0, | ||
| "maxListElements": 0, | ||
| "maxTuples": 0, | ||
| "tupleArity": 0, | ||
| "includeOwnerV3": true, | ||
| "includeOwnerV4": false | ||
| }, | ||
| 6842 | ||
| 6843 |
There was a problem hiding this comment.
Looks like something is costing 1 constraint even when the number of EI modules is zero.
Do you have any insight into what it is? Not a big deal, but I'd expect everything to collapse to zero.
There was a problem hiding this comment.
This comes from the bit-packed signal associated with the module.
There was a problem hiding this comment.
Num2Bits(0) has a constraint? Naughty.
There was a problem hiding this comment.
Literally naught-y in the sense that Num2Bits(0) constrains its input to be zero. ;-)
| // NumericValueModule}. | ||
| signal output out <== LessThan(NUM_BITS)( | ||
| [ | ||
| value + ABS_POD_INT_MIN(), |
There was a problem hiding this comment.
I feel like this "offset value" should be a template parameter rather than being hard-coded here. The proto-pod-gpc layer should be where the decision on int size is made. The same suggestion might apply to the bounds check module too. Actually it could be a template parameter at the proto-pod-gpc level too, though that might be overkill since I don't anticipate ever generating with different sizes.
This PR adds an entry inequality module to GPCs. Summary of changes:
lessThan,lessThanEq,greaterThanandgreaterThanEqfields to the GPC proof entry config.This PR depends on the artifact changes in proofcarryingdata/snark-artifacts#14.