EspressoSystems / jellyfish

A Rust Implementation of the PLONK ZKP System and Extensions
https://jellyfish.docs.espressosys.com
MIT License
389 stars 94 forks source link

Make the BLS signature instantiation generic over curves #232

Open chancharles92 opened 1 year ago

chancharles92 commented 1 year ago

Currently, we keep two BLS signature instantiations; one uses blst under BLS curves, and the other uses BN curves https://github.com/EspressoSystems/jellyfish/blob/main/primitives/src/signatures/bls_over_bn254.rs https://github.com/EspressoSystems/jellyfish/blob/main/primitives/src/signatures/bls_over_bls12381.rs

We kept both as blst is more efficient but doesn't support BN curves. In the future, we may generalize the instantiation in https://github.com/EspressoSystems/jellyfish/blob/main/primitives/src/signatures/bls_over_bn254.rs to support arbitrary pairing curves.

cc @philippecamacho

alxiong commented 11 months ago

I had some brief attempts at this task today. Here're are some challenges:

  1. const CS_ID: &'static str associated constant declared under trait SignatureScheme. The only way I can think of to have a generic implementation for a type-dependent function is via downcasting and trait object, i.e.
    const fn cs_id<P: Pairing>(p: &dyn P) -> &'static str {
        if let Some(_) = p.downcast_ref::<ark_bn254::Bn254>() {
            "BLS-BN254-..."
        } else {
             // ....
        }
    }

    But the problem is most traits (including Pairing) from arkwork are marked as Sized, thus not object safe, and cannot be used as trait object.

  2. To support possibly different backend (e.g. blst or the default arkworks, or the faster bn mcl), we probably would introduce RUSTFLAG, and have cfg_if! like this in our code. note that we should use rustflags rather than feature flag IMO, because feature flag is additive, whereas rustflag is mutually exclusive.

With these headaches, I think it's wiser to just keep different instantiations separate for now.