Bandersnatch VRF

[davxy]

This PR introduces a new kind of VRF which uses bandersnatch-vrfs backend.

• Primitive codename used within Substrate : bsnvrf (→ Bandersnatch-Vrf)
• gated behind bandernatch-experimental feature flag

---

The primitive is used by Sassafras (#11879).

IMO is worth splitting the sassafras PR in smaller pieces to be more easily reviewable (is already +9K)
so first I propose to introduce this VRF to trim it a bit.

---

Open points:

1. Key derivation.

• sr25519 supports both hard and soft secret key derivation (see here). While ecdsa and ed25519 support only hard secret key derivation (e.g. see here). What about bandersnatch?

2. When a first version bandersnatch-vrfs crate on crates.io?

3. Missing Ring proof integration. Is not clear if in the end bandersnatch-vrfs crate will provide a single sign function to get both thin and ring proofs.

[davxy]

requires #14036

[koute]

2. To be fair this is an ed-on-bls12-381-bandersnatch with vrf capabilities etc etc. What is an appropriate (please not verbose) name synthesizing this primitive capabilities and that fits well with the rest of the primitives? (e.g. "schnorr using ristretto -> sr25519)?

Probably incredibly-stupid-random-totally-uninformed-suggestion: maybe bb12381, with the bb pronounced as "baby" (one "b" is for bls, other is for "bandersnatch", and the numbers are numbers). Fits a similar pattern as sr25519. (:

[davxy]

Because this key type will be used by a consensus protocol, is required to implement all the traits required by session pallet. One of these is RuntimeAppPublic which in turn required RuntimePublic.

This trait offers some methods requiring access to the keystore: sign and generate_pair

Was my intention to keep the required host functions to the minimum.

• generate_pair should be implemented. Apparently there is nothing we can do. As it is invoked at startup by the session pallet and also from the rpc interface to generate new keys on demand. I've added an host function for this...

• sign: this may be useful if we want to sign something from an offchain worker. Currently we don't. Maybe I can just return None here?

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate-macos
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2873610

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2873593