VRF crate
Adding traits for Verifiable Random Functions. See #1728.
The vrf name on crates.io is taken. The current crate under this name seems unmaintained, the last commit being 3 years ago.
The exact structure of the traits is not defined yet, I'm mostly looking for some input until we resolve the crate name and have some confidence that we have a good interface.
For a crate name, verifiable-random-function would fit our naming scheme
We could ask in the vrf repo about potential crate ownership transfer. Another option is to use something like crypto-vrf.
We could ask in the
vrfrepo about potential crate ownership transfer.
Yes, the maintainers seem active on github. If we decide to try getting the name vrf, let me know if I should be the one contacting them. I think if a maintainer of RustCrypto does then we have more credibility but I'm open to doing it.
Otherwise, we could abuse the Signer and Verifier traits, and implement them with a type parameter that implements proof (this is very likely not a good idea). We wouldn't need the Prover and Verifier traits. Or maybe we just want the Prover trait and we reuse the Verifier trait from signature, because all vrfs that I know of are based on asymmetric signatures.
Yes, traits from the signature crate could be used instead if we want. If the only thing that's really needed is a trait for VRF_proof_to_hash, we could potentially just add that to signature.
The nice thing about a separate crate is it could have stricter bounds which would make things a bit easier to use. Instead of having to bound on Signature: SignatureEncoding + VrfProofToHash (or whatever), those bounds could simply be automatic (in addition to the trait names being more idiomatic for VRFs)
Yes, traits from the
signaturecrate could be used instead if we want. If the only thing that's really needed is a trait forVRF_proof_to_hash, we could potentially just add that tosignature.The nice thing about a separate crate is it could have stricter bounds which would make things a bit easier to use. Instead of having to bound on
Signature: SignatureEncoding + VrfProofToHash(or whatever), those bounds could simply be automatic (in addition to the trait names being more idiomatic for VRFs)
After some time off, I think what we should do is use the Verifier trait from the signature crate, and keep the Proof and Prover traits.
A question I would like answered: should we add VRFs as a module in signature (perhaps behind a feature) or should we keep it in a separate crate?
Since signature is a post-1.0 crate I think it would be nice to prove it out in a separate crate. It could eventually be merged.
FYI: the vrf crate seems to be getting regular updates, so I didn't attempt to contact them
Indeed. I was thinking we could group vrf, oprf, voprf, etc. under a random-function crate.