Add AsRef<[u64]> trait bound to GroupAffine/GroupProjective ScalarField

[ValarDragon]

This allows mul to take in an AsRef<[u64]>, and allows one to naturally multiply by a scalar field element.

This does restrict the set of fields that can be scalar fields, since it would have to use u64 as its data type, precluding dalek-style f32 backend optimizations for scalar fields. (Dalek has an f32 backend for the base field, not the scalar field AFAIK) This restriction does feel natural in the elliptic curve context, since there you really do want the bit-wise representation of a scalar field element for scalar multiplication. (At least until we consider endomorphism optimizations) The base field can still have an arbitrary representation for efficient MSM's.

In the case of doing an elliptic curve based SNARK, and wanting to do FFTs with the fastest scalar field representation, you would have to do a conversion between the FFT/polynomial representation and the ScalarField representation. This conversion would have to exist regardless of API decision. However before, you could just push this conversion into the Into<BigInt> method. I suspect this would be handled by making the field representation you implement polynomials with also implement Into

So doing this would be a trade-off between allowing easy scalar multiplications by an integer at the expense of making non-u64 backed implementations of scalar fields (for FFT/polynomial arithmetic speedups) more complex to integrate into elliptic curve based polynomial commitments.

I think this is a fine trade-off to make right now until we have preliminary understandings of how much of a speedup we stand to gain from non-u64 based arithmetic in scalar fields. (We can learn this independently, since you can still use FFTs with any FFTField)

This issue is a transcription of the result of a conversation with @Pratyush.

[huitseeker]

(Dalek has an f32 backend for the base field, not the scalar field AFAIK)

It does have it for the scalar field as well.