filecoin-project / blstrs Goto Github PK

This is rather a wonder. Why is following needed?

https://github.com/dignifiedquire/blstrs/blob/df8c49dbe3f1621ff10c393691cbd59358c29bb2/src/fp.rs#L556-L563

I mean there is life-time-d version above...

Hello,

On the below environment, we are building libfilcrypto.so from filecoin-ffi/rust/

Platform : s390x
Endianness : Big
OS : Ubuntu 20.04

But ran into this below issue

src/lib.rs

#[cfg(not(target_endian = "little"))]
compile_error!("blstrs is only supported on little endian architectures");

Would you have plans on supporting blstrs on s390x platform for Big Endian architecture ?

Thank you,

We are working on Filecoin integration to the Brave Wallet and we need support for x86 versions for blstrs

https://github.com/dignifiedquire/blstrs/blob/df8c49dbe3f1621ff10c393691cbd59358c29bb2/src/fp2.rs#L59-L69

I don't think this is "lexicographical" comparison. Or what am I missing? Otherwise I can arrange export of sgn0_fp2...

Any plans to add serde serialization support, perhaps as an optional feature flag?

The version of the blst dependency is always fixed to exactly match a specific version, like here.

Is that a true requirement, or was the = left in by accident? It makes it difficult to use libraries built on this one with something else that requires a higher patch version. For example v0.5.0 wants =0.3.9, but another dependency I have wants 0.3.10 of blst. If blstrs was happy with 0.3.9 without = the cargo should be able to pick the higher version.

https://github.com/dignifiedquire/blstrs/blob/df8c49dbe3f1621ff10c393691cbd59358c29bb2/src/g1.rs#L593-L596

I make no promises about x and y being zero along with z.

https://github.com/dignifiedquire/blstrs/blob/df8c49dbe3f1621ff10c393691cbd59358c29bb2/src/fp.rs#L808-L815

Doesn't straight bytes.as_ptr() work? And I don't follow raw.try_into().ok().

Same applies to from_bytes_be... And to_bytes, modulo out.as_mut_ptr()...

Given the points G1 (x1, y1), G2 (x2, y2), the modulus of the finite field is P, then (G1-G2)=G1+(- G2), (- G2)=(x2, (- y2)+P), I want to confirm that this is the case?

I don't follow this

https://github.com/dignifiedquire/blstrs/blob/df8c49dbe3f1621ff10c393691cbd59358c29bb2/src/fp.rs#L600-L612

raw is 6 limbs, 4 are set, 4th is masked... So if FpRepr(raw) < MODULUS is always true... And it would hold true even without masking...

Formally speaking you don't need this loop at all, because conversion to blst_fp does implicit modulo reduction. Yes, you can pass full-width 384-bit input to conversion subroutine and it will be reduced modulo field prime, i.e. you'll get random % prime for free. Which is obviously as good as checking for < MODULUS. (Provided that one would fill 6 limbs and mask 6th.)

Hi! I am getting an assertion error in the following basic case. Is it a bug in the mult_exp implementation or is there anything I am missing here? Will appreciate any help.

    let a = G1Projective::generator();
    let b = G1Projective::multi_exp([a].as_slice(), [Scalar::one()].as_slice());
    assert!(a.eq(&b))

I am using blstrs = { version = "0.6.1", features = ["serde"] } in my Cargo.toml file.

I am also on an Apple M2 pro machine.

My understanding is that "G1_affine" type points (x, y) are all points on the finite field of an elliptic curve, where x and y are both points on Fq_ P is the result after taking the modulus, so x and y should be less than Fq_ P。 But I found that x and y are not necessarily less than Fq_ P。 I want to know the meaning of "G1_affine" point in the project?

I'm using this crate for an implementation of KZG polynomial commitments, and creating a witness requires computing a "sum of products" of the form elem[0] * scalar[0] + ... + elem[n-1] * scalar[n-1], which is slow for large degrees.

blst has a fast (4-5x faster than naive on my MB Pro 16 for 1000 elements) implementation of peppinger multiexponentiation in blst_p1s_mult_pippenger. Would y'all be open to adding a multi_exp associated function to G1Projective and G2Projective for this?

I have an implementation here at https://github.com/Sladuca/blstrs/tree/multiexponentiation, but wanted to raise this for discussion anyways.

KZG commitments probably aren't the only applications that would benefit from this. Off the top of my head, Pederson commitments would too.

https://github.com/dignifiedquire/blstrs/blob/df8c49dbe3f1621ff10c393691cbd59358c29bb2/src/fp.rs#L316-L322

This doesn't appear right. blst_fp_from_uint64 takes array of 6 uin64-s as input, while this implementation takes reference to single uint64, so that blst_fp_from_uint64 would receive val followed by some random data. One should do something similar to impl From<u64> for FpRepr above. I.e. initialize 6-element uint64 array on stack with first element set to val and rest zeroed.

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.

The blst crate support an optional adx feature:
https://github.com/supranational/blst/blob/7f6aa706670aa090f0cb69850bc1c388b459c438/bindings/rust/build.rs#L85

The CPU of our build machines are support adx instruction but our target machine are not.

The current code of blstrs does not support an optional adx feature. It means that even we remove the adx optimize here and there is no '+adx' arg in rust's target feature, adx instruction will still be enabled.

So,may be a optional adx feature support here?

Why not replace this

https://github.com/dignifiedquire/blstrs/blob/df8c49dbe3f1621ff10c393691cbd59358c29bb2/src/g1.rs#L569-L582

with call to blst_encode_to_g1 with random msg instead? No loops, predictable time, reliable output... And you can omit get_point_from_x and scale_by_cofactor.

Same applies to g2.

As pointed out by @dot-asm there might be some more improvements that can be done:

Ref #30 (comment)

What prevents you from omitting fp6.rs?

Hello,
blst exposes blst_map_to_g1 and blst_map_to_g2. These APIs are useful in the case when a user of this library wants to do hash-to-curve using different XMD and XOF based hashing of the messages. It would be nice if wrapper of these APIs are added in blstrs.

Below is the link for an implementation where I have copied hash-to-curve generic traits from zkcrypto/bls12_381 and implemented the wrappers under a feature flag. I have used zkcrypto/bls12_381's test cases too(test vectors are from hash_to_curve spec draft 10) and the tests pass.

Implementation: master...dev0x1:blstrs:gaurav/h2c

To test,

cargo test --features h2c_generic_hash --features alloc

Thanks,

https://github.com/dignifiedquire/blstrs/blob/df8c49dbe3f1621ff10c393691cbd59358c29bb2/src/g1.rs#L615-L621

blst_p1_double. It's faster.

On vaguely related note. Lucky you since double type is called f64 in Rust :-)

Currently these https://github.com/dignifiedquire/blstrs/blob/master/src/tests/engine.rs#L35-L49 tests are failing, while all other pairing checks are passing, this might be an issue in blst itself.

@dot-asm could you take a look if this might be an issue in blst for these special cases?

I'd like to make a case for deep makeover of this [module]. I feel that this is serious mischaracterization to mix together "scalar" and "fr" field operations. Scalars are something you multiply points by, "fr"-s are something you operate on in their own [capacity]. They have different internal representations and should be treated as independent types. Most notably, I'm considering switching for bytes in scalars.

It's not exactly my business, but I'm opposed to the idea of implementing methods just for the sake of "completeness." For example there is no point implementing fp12 addition or subtraction. Is it actually so that caller of the module is dependent on them, or are they used only in internal tests? If latter, then what's the actual point of implementing them? Same applies to sqrt and inverse. So far assessment is that need for sqrt would disappear if #6 is resolved as suggested. At least for fp and fp2. Is it correct or what am I missing? As for fr, is it's actually so that sqrt and inverse are required for something? If so, I'm ready to add them to blst...

Given the points G1 (x1, y1), G2 (x2, y2), the modulus of the finite field is P, then (G1-G2)=G1+(- G2), (- G2)=(x2, (- y2)+P), I want to confirm that this is the case?