Proposal: use dependency for EC operations indirectly through mathlib

[ale-linux]

This proposal recommends changing the dependency used to handle the operations on elliptic curves needed by the BBS+ implementation.

Currently, an implementation from kilic is directly used. We recommend switching to mathlib: mathlib is a module that exposes a common set of API backed by a number of different libraries (amcl, ConsenSys/gnark-crypto and kilic). It currently supports the following curves: FP256BN, BN254, BLS12_377 and BLS12_381 (the latter in two different variants, standard and BBS compliant). mathlib is already being used by fabric, the idemix implementation used by fabric, the fabric token sdk and the fabric smart client.

The reasons that motivate this switch are:

• switching implementation of the same curve is simplified; using mathlib, a developer operates on a curve instance that implements the common set of methods. Changing implementation can be achieved for instance by substituting

var curve = ml.Curves[ml.BLS12_381_BBS]

which uses the customised, BBS+ compliant implementation of bls12-381 (which used to be here and is now implemented by mathlib) with

var curve = ml.Curves[ml.BLS12_381_BBS_GURVY]

which uses the version of bls12-381 backed by gnark-crypto with the necessary customisations to make it BBS+ compliant. The rest of the code wouldn't have to change

• similarly, switching curve (e.g. using bls12-377) may be achieved through similar means. This might be necessary either because over time the degree of security offered by curves weakens and curves need to be changed to remain secure, or because one might want to use different curves to achieve different goals (e.g. because one wants to generate SNARK proofs over BBS+ artefacts, and an efficient instance of that would use bls12-381 for the SNARK and bls12-377 for BBS).

• the ease of switch also permits changing implementation easily, should a curve provider either become unmaintained or because a more performant implementation is available.

This proposal is supported by @ale-linux and @adecaro.

We would kindly ask @sudeshrshetty to please have a look - we're happy to discuss the proposal in-depth with the community.

[sudeshrshetty]

@ale-linux I appreciate the thorough details provided, and the proposal looks good to me.