Currently, in the goblin pipeline, we're only checking that $\mathbb{F}_q$ (bigfield/goblin_field) elements coming from the EccOpQueue are $< 254$ bits. It means that one can potentially create a proof with aliased reps of $\mathbb{F}_q$ elements (commitment coordinates), such that native and ultra recursive verification would fail (we're imposing strict $<q$ checks in these cases) but goblin (mega+merge+eccvm+translator) verification would pass.
The cleanest solution would be to tweak the range constraints in Translator, such that we have consistent verification behaviour across these 3 scenarios. If that's hard to achieve, we need to carefully analyze if this can be exploited client-side on in AVM recursive verification.
Remark: currently aliased reps would fails Mega assert_equal constraints but those can be avoided.
Currently, in the goblin pipeline, we're only checking that$\mathbb{F}_q$ (bigfield/goblin_field) elements coming from the $< 254$ bits. It means that one can potentially create a proof with aliased reps of $\mathbb{F}_q$ elements (commitment coordinates), such that native and ultra recursive verification would fail (we're imposing strict $<q$ checks in these cases) but goblin (mega+merge+eccvm+translator) verification would pass.
EccOpQueueareThe cleanest solution would be to tweak the range constraints in Translator, such that we have consistent verification behaviour across these 3 scenarios. If that's hard to achieve, we need to carefully analyze if this can be exploited client-side on in AVM recursive verification.
Remark: currently aliased reps would fails Mega
assert_equalconstraints but those can be avoided.