This is an implementation of an elliptic curve-based verifiable random function construction designed by Goldberg et al. and specified in an IETF internet draft, draft-irtf-cfrg-vrf-03 (https://www.ietf.org/id/draft-irtf-cfrg-vrf-03.txt). The specification is still a draft and may change before it becomes standardized. In particular, this implements the ECVRF-ED25519-SHA512-Elligator2 suite.
The code is structured to closely follow the pseudocode given in the spec, with a few notable exceptions described below, and we point to the relevant section of the draft spec in comments before each function.

For readability, the code is separated into a few files: keygen.c (key generation), prove.c (constructing vrf proofs), verify.c (verifying VRF proofs and turning them into output hashes), convert.c (helper functions used in prove and verify), and vrf.c (boilerplate). vrf_ietfdraft03.h is used internally so that prove.c and verify.c can use the helper functions defined in convert.c.

keygen.c contains key generation functions. In this VRF scheme, key generation is identical to standard ed25519 key generation from RFC8032, so these functions are essentially copied directly from libsodium/crypto_sign/ed25519/ref10/keypair.c.
In libsodium's ed25519 signature implementation, the "secret key" returned by keygen is not the 32-byte string RFC8032 calls the secret key -- libsodium calls that 32-byte string the "seed" -- but is instead the seed with the public key appended. This precomputation saves a scalar multiplication during signing. We do this same optimization in the VRF implementation, saving a scalar multiplication during proving, and we use the same terminology (32-byte seed / 64-byte secret key). keygen.c defines functions for converting back and forth between 32-byte seeds and 64-byte secret keys. Our terminology here differs from the VRF draft spec, where "secret key" refers to the 32-byte seed.

convert.c has some internal utility functions: point_to_string, string_to_point, hash_to_curve_elligator2_25519, hash_points, and decode_proof. These correspond to the similarly-named subroutines in the VRF draft spec.

verify.c contains verification-related code: verify, proof_to_hash, validate_key, and helper functions. Verification runtime depends only on the message length (assuming verification succeeds).

prove.c contains the prove function. As mentioned above, to save a scalar multiplication, prove() takes in a 64-byte secret key where the first half is the secret seed and the second half is the public key. If the second half doesn't encode a valid curve point, prove() will fail early; otherwise prove's runtime depends only on the length of the message. (If the second half of the secret key encodes a valid curve point that but not the correct public key, the proof returned may fail to verify.)
prove.c also contains the helper function vrf_nonce_generation (specificed in section 5.4.2.2. of the draft spec). In the draft spec, the nonce generation function takes in the seed and computes a truncated hash of it; we instead compute this same truncated hash earlier in a helper function (vrf_expand_sk, which already hashes the seed to derive x) and pass that to vrf_nonce_generation directly, giving the same result.
