Filecoin BLS difficulties

Working Groups Webnative Filecoin Integration
1

Alrighty a few updates after spending some days in the BLS mines :pick::construction_worker_man:

Problems with Zondax library

I ran into some difficulty with the @zondax/filecoin-signing-tools library:

With both of those issues addressed, I was able to successfully submit messages signed with BLS keys.

Key/signature aggregation

Next step is aggregating public keys & signatures

The Zondax libary does not have aggregation functions. However, the underlying bls-signatures library does have a signature aggregation function.

I added a function to my local fork of the zondax library that calls into that aggregation function. It compiles fine, but fails at runtime. I believe this to be because bls-signatures does signature aggregation in parallel which is not support with WASM. I tried doing this not in parallel, but can’t get it to compile at the moment. We can chalk that one up to being a Rust newbie :sweat_smile:

From what I can tell, the bls-signatures library also does not support public key aggregation, which is also necessary for us.

There are two options:

  • updating the zondax library
    • I can attempt to do this myself, but I feel that it’s getting dangerously close to “rolling your own crypto”, especially seeing as I’m very new to Rust
    • Would be great to get a hand from the Filecoin/Zondax team!
  • using another library
    • really the only JS/WASM library that I’ve found that seems to support both signature & key aggregation is noble-bls12-381
    • However, it calculates different public keys than Lotus does
    • I’m guessing that they’re using slightly different curve params. I have verified that both libraries use G1 for public keys and G2 for signatures
    • or worse, that library is just broken :scream:
    • I’ve opened an issue in the hopes of getting some clarity: Compatibility with Filecoin · Issue #24 · paulmillr/noble-bls12-381 · GitHub
1 Like
2

Update

After some discussion, it appears that the noble-bls12-381 does derive matching keys to ETH2. I’ve verified this against the herumi bls implementation which appears to be the gold standard for ETH2.

Still, none of these public keys match the public keys coming out of the filecoin world (both the zondax lib and keys exported from the Lotus node).

My understanding is that bls12-381 refers to a specific pair of curves. And that the only discrepancy that you should see between implementations is if PublicKeys/Signatures are on G1/G2.

To be honest, I’m not quite sure where to go from here :thinking: I’m not writing off the possibility of user error (on my end), but these seem to be two different implementations of the curve

3

BLS aggregation is… working?

I figured that since noble-bls12-381 & filecoin-signing-tools were deriving different public keys from the same private key, that doing aggregation of filecoin keys with the noble library was hopeless. But as a total shot in the dark, I attempted it, and it… worked!

This is great because we now have a path forward and I’m unblocked. But I am very confused why this is working (which implies that the two libraries are using the same curve), but that public key derivation and signing do not much up between the two (which implies that the two libraries are using different curves).

At the very least, it would be great to hear from the zondax folks so that I could understand what is going on and what could be causing these discrepancies between libraries. And I do think it would still be valuable to add key & signature aggregation to the zondax library. This is “working”, but it feels sketchy because I can’t rectify the difference in key derivation.