traits icon indicating copy to clipboard operation
traits copied to clipboard

VRF crate

Open carloskiki opened this issue 11 months ago • 9 comments

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.

carloskiki avatar Mar 12 '25 23:03 carloskiki

For a crate name, verifiable-random-function would fit our naming scheme

tarcieri avatar Mar 13 '25 00:03 tarcieri

We could ask in the vrf repo about potential crate ownership transfer. Another option is to use something like crypto-vrf.

newpavlov avatar Mar 13 '25 00:03 newpavlov

We could ask in the vrf repo 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.

carloskiki avatar Mar 13 '25 11:03 carloskiki

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.

carloskiki avatar Mar 16 '25 16:03 carloskiki

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)

tarcieri avatar Mar 18 '25 17:03 tarcieri

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)

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?

carloskiki avatar Apr 24 '25 23:04 carloskiki

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.

tarcieri avatar Apr 24 '25 23:04 tarcieri

FYI: the vrf crate seems to be getting regular updates, so I didn't attempt to contact them

tarcieri avatar Jul 20 '25 13:07 tarcieri

Indeed. I was thinking we could group vrf, oprf, voprf, etc. under a random-function crate.

carloskiki avatar Jul 20 '25 18:07 carloskiki