Fix randomness computation

[burdges]

At https://github.com/paritytech/substrate/blob/master/frame/babe/src/lib.rs#L577 we use RawVRFOutput directly for randomness, which should never happen.

You should call schnorrkel::VRFInOut::make_bytes similar to what sc_consensus_babe::authorship::check_primary_threshold does. In schnorrkel, we produce these VRFInOuts inside vrf_sign* and vrf_verify*, so you could call make_bytes once on block import, and save those bytes as non-serialized block metadata.

If you'd rather reproduce those bytes again elsewhere, then you recreate the VRFInOut by first creating the transcript with sc_consensus_babe::authorship::make_transcript and calling schnorrkel::PublicKey::vrf_attach_hash/schnorrkel::VRFOutput::attach_input_hash with the signers public key and the schnorrkel::VRFOutput (the actual bytes being used here).

I should apologize for not making this aspect of schnorrkel as missuse resistant as possible, but exposing VRFOutput separate from VRFProof, and exposing these VRFInOuts simplified the interface dramatically. I should rename schnorrkel::VRFOutput to VRFPreOutput really.

[burdges]

I've renamed the VRFOutput type to VRFPreOut in w3f/schnorrkel@030e686 to reduce confusion in future, but I have not yet published an ew version and any update should be completely orthogonal to #5788

[Demi-Marie]

Is this a security hazard @burdges?

[burdges]

We safe from any attacks I know because Ristretto accepts only one point encoding. It'd degrade the randomness by a factor of 8 if we'd used another VRF like VEd25519 instead: w3f/ring-vrf#15

We do need Wei's fix in #5788 because (a) the make_bytes methods give us the VRF's PRF-like assumptions in the security proof, and (b) validators could conceivably choose related keys. We
forbid (b) but it becomes more likely if folks play games like w3f/General-Grants-Program#273