Possibly speed up G1,G2 and GT group membership checks about blst

[huitseeker]

This implementation in arkworks shows a promising 12-15% performance improvement for Scott checks over the Bowe checks (also implemented by @simonmasson in a prior PR).

[dot-asm]

I get +19% on G1 group check and just +6% on G2. But I'm a little but confused about the G1 check, because there seems to be an additional criterion for the β value. I mean besides it being a cubic root of unity. Because the one we have in src/e1.c doesn't work, its square does... Or inverse if you wish... [Just in case, which is also cubic root.]

+19% is somewhat surprising. Indeed, both checks rely on ~128-bit scalar multiplication, with the new check's addition chain being just 7% shorter. Well, the original test performs additional operations, with them the difference between the amounts of point operations is 10%, still far from 19%... On the other hand, +6% on G2 is in alignment with the difference in amount of point operations...

As for "early out" optimization. I reckon it makes less sense to implement it, because the probability of hitting a point that would be caught in it by chance is [astronomically] low, while those who try to exhaust your computational resources can easily bypass it.

[dot-asm]

the probability of hitting a point that would be caught in it is [astronomically] low, while those who try to exhaust your computational resources can easily bypass it.

Just in case to clarify. The only cause for the amount of the group check failures that you would care about is that somebody is messing with you. If they simply pick points at random and throw at you, the probability of them picking one that would be caught early on is low. So that you would waste practically as much computational resources as if the "early out" check was not performed. But if you have one, it would cost them nothing to avoid it and make you pay the full price irregardless.

[dot-asm]

"+" means that the results were improved, in other words Scott's checks are faster. "Nothing else to say" refers rather to the no-early-out thing. If you wonder if the code is committed, then yes, in November, 9th.

[yelhousni]

So it seems there was an error in Scott preprint for G2 membership test proof. However, the result is still correct (more on that here: https://eprint.iacr.org/2022/352.pdf).

[dot-asm]

One should keep in mind that reported improvement coefficients are relative to the scalar multiplication by the curve order. And blst doesn't do group checks by multiplication by the curve order. This is not to say that the suggested method can't be faster, but one is unlikely to be able to describe the speedup as considerable in the context. But it will looked into, for sure.

BTW, suggestion for G1 rather targets new protocols, not existing ones. And I reckon that it's not given that it would be suitable for every application. At least I fail to see how would it prevent signature malleability... Or what am I missing?

[dot-asm]

Well, there is nothing else to say I suppose....

[huitseeker]

I'm sorry, I must have misread your comment @dot-asm : did your "+x%" mean that your benchmarking revealed that the Scott & al checks where slower than the Bowe checks?

[huitseeker]

This is awesome! I simply missed b546b01 and a381953. Thanks a lot for your work!