impl From<u64> for Fp about blstrs

[dot-asm]

Great! I'll try to make suggestion for the remaining rest.

Meanwhile I've added exports for sqrt and inversions for fp and fp2. Just in case for reference, difference between eucl_inverse and inverse is constant-time-ness.

[dot-asm]

As a follow-up to last note in previous message. This

https://github.com/dignifiedquire/blstrs/blob/df8c49dbe3f1621ff10c393691cbd59358c29bb2/src/fp.rs#L507-L513

should rather use blst_uint64_from_fp.

[dot-asm]

Speaking of blst_fp used in FpRepr. I oppose the idea of reusing blst_fp for FpRepr, because it gives misleading impression. General idea is that application should abstain from making specific assumptions about internals of blst types. The fact that they are expressed as collection of 6-element array of 64-bit values is rather for memory management purposes than for application to dig into. For now it works because both supported platforms are 64-bit ones, but it should be viewed as circumstantial.

To elaborate further. Ultimate idea is to have application treat blst data as opaque. Imagine a platform with hw-assisted 512-bit multiplier emerging. It might mean that storage for field elements would have to be increased, but even if not, it would definitely have effect on Montgomery representation. And at the same time it would be desired that application code wouldn't have to be modified, it should be sufficient to compile it for another target. Yes, it means that application shouldn't have constants in Montgomery representation and pass them directly to blst. Even though it can now, it's appropriate to work toward omitting them from the start. Two options.

• Have application keep constants in non-Montgomery representation and use suitable blst_fp_from_*. (It's shame that Rust doesn't have constant constructors, so that constants could be instantiated in more uniform manner.)

• Add blst interface that would convert between "natural" Montgomery representation and internal blst representation for application to instantiate Montgomery constants. For now it would be just equivalent of memcpy, which might feel silly, but it will serve the greater purpose.

Formally speaking these are not mutually exclusive, but in either case application should not pass constants to blst verbatim.

[dignifiedquire]

I have switched FpRepr to use [u64; 6] directly and updated the u64 conversions as described by you here: 108181c

[dignifiedquire]

(It's shame that Rust doesn't have constant constructors, so that constants could be instantiated in more uniform manner.)

You can have constant constructors, just not using ffi calls

const FOO1: Foo = Foo::new(1);

struct Foo(u32)
impl Foo {
  pub const fn new(val: u32) -> Self {
	Foo(val)
  }
}

works fine

[dignifiedquire]

* Add blst interface that would convert between "natural" Montgomery representation and internal blst representation for application to instantiate Montgomery constants. For now it would be just equivalent of memcpy, which might feel silly, but it will serve the greater purpose.

This would be really nice to have, especially for testing.

[dot-asm]

(It's shame that Rust doesn't have constant constructors, so that constants could be instantiated in more uniform manner.)

You can have constant constructors, just not using ffi calls

My understanding is that you can't call a function, i.e. it has lesser to do with ffi. Well, it appears that you can call const fn but it's limited by its constant-ness. And I naturally meant constant constructors that wouldn't be as constrained, implying that blst_fp constants would be initialized with calls to Montgomery conversion (of either kind) prior application code executes.

This [conversion between 6-limb "natural" Montgomery representation and blst_fp] would be really nice to have, especially for testing.

OK...

[dignifiedquire]

Except for some tests and constants, the reprs and conversions are now all using the transformation methods and not the internal representation anymore.

[dignifiedquire]

should all be fixed now