blst vs pairing backends

[cryptonemo]

In the next proofs release, we'll likely replace the pairing backend for the blst backend since it has several speed and security advantages (i.e. it's been audited).

This begs the question of what should eventually happen to the pairing backend. The options are:

1. Continue to maintain it going forward so that anyone can flexibly switch between them (although our resources on this may be limited, so we'd be welcoming contributions from the community), or
2. Drop support for pairing at some point in the future in favor of streamlining development and increased focus on supporting blst.

We are open to thoughts on this, so feel free to chime in.

[nikkolasg]

Except for a change import in Cargo.tomlI haven't had to install anything, no external dependency, which is a surprisingly good experience generally for a lib coded in C. From that user point of view, I'm all in for using only blstrs.

[jennijuju]

From: Charles Cao - FilSwan
blst ：This library has not yet been audited. Use at your own risk.

[cryptonemo]

The version of blst we're using specifically has been audited, as mentioned above, which is part of the reason why we're looking to use it.

[flyworker]

Thanks a lot. It looks pretty solid