Verifiable Random Function (VRF)

What Is a Verifiable Random Function?

A verifiable random function (VRF) is a cryptographic primitive that produces pseudorandom output along with a proof that the output was computed correctly. Introduced by Silvio Micali, Michael Rabin, and Salil Vadhan in 1999 at the IEEE Symposium on Foundations of Computer Science, VRFs extended the concept of pseudorandom functions so that the secret key holder can evaluate the function at any point and provide an NP-proof of correctness, without compromising unpredictability at other points.

In practical terms, a VRF works like a lottery machine that is transparent and tamper-proof. The operator (key holder) can produce a random-looking number for any given input, but they cannot choose what that number will be. Anyone watching can verify the number was generated honestly using only the operator's public key, the input, and the proof. This combination of unpredictability and verifiability makes VRFs essential for blockchain systems where fairness must be provable, not assumed.

How It Works

A VRF consists of three algorithms that work together to generate and verify randomness:

1. Key Generation (Gen): produces a key pair consisting of a public key (PK) and a secret key (SK), similar to standard elliptic curve cryptography
2. Evaluation (Eval): takes the secret key and an input (alpha) to produce a pseudorandom output (beta) and a proof (pi)
3. Verification (Verify): takes the public key, the input, the output, and the proof, then returns true or false indicating whether the output is correct

The critical insight is that for any given key pair and input, there is exactly one valid output. The key holder cannot "reroll" or choose among multiple valid results. This uniqueness property is what separates VRFs from ordinary digital signatures, which may allow multiple valid signatures for the same message.

Security Properties

RFC 9381, published by the IRTF Crypto Forum Research Group in August 2023, defines the formal security requirements that a VRF must satisfy:

• Uniqueness: for any fixed public key and input, no adversary can produce proofs for more than one VRF output. There is exactly one correct answer.
• Collision resistance: it is computationally infeasible to find two different inputs that produce the same output under the same key.
• Pseudorandomness: without the proof, the VRF output is indistinguishable from a truly random value, even to someone who has seen outputs on other inputs.

ECVRF Construction

The most widely used VRF construction is ECVRF (Elliptic Curve VRF), which builds on the same cryptographic foundations as elliptic curve cryptography. RFC 9381 specifies four ECVRF ciphersuites using the P-256 and Edwards25519 curves.

The evaluation process works as follows:

1. The prover derives a secret scalar x from the secret key and has a public key Y = x*B, where B is the curve's generator point
2. The input alpha is hashed to a point H on the elliptic curve using a designated encode-to-curve method
3. The prover computes Gamma = x*H (the core VRF computation)
4. A deterministic nonce k is generated, and a challenge c is derived from the public key, curve point, and nonce-derived values
5. The proof pi consists of Gamma, the challenge c, and a response value s = (k + c*x) mod q
6. The final output beta is the hash of Gamma

// Simplified VRF evaluation (pseudocode)
function VRF_eval(secretKey, input):
    H = hash_to_curve(input)
    Gamma = secretKey * H
    k = generate_nonce(secretKey, H)
    c = hash(publicKey, H, Gamma, k*G, k*H)
    s = (k + c * secretKey) mod order
    proof = (Gamma, c, s)
    output = hash(Gamma)
    return (output, proof)

// Verification (anyone can run this)
function VRF_verify(publicKey, input, output, proof):
    H = hash_to_curve(input)
    (Gamma, c, s) = proof
    U = s*G - c*publicKey
    V = s*H - c*Gamma
    c_check = hash(publicKey, H, Gamma, U, V)
    return c == c_check && output == hash(Gamma)

Why On-Chain Randomness Is Hard

Blockchain networks are deterministic by design: every node must execute the same transactions and arrive at identical results to reach consensus. This creates a fundamental conflict with randomness generation. If all nodes can compute the same random value, so can an adversary.

Naive approaches to on-chain randomness are vulnerable to several attacks:

• Blockhash manipulation: miners or validators can compute block hashes before publishing and discard blocks with unfavorable outcomes, effectively rerolling the random number until they get a result they prefer
• Timestamp manipulation: validators can adjust block timestamps within protocol-acceptable ranges to influence randomness derived from time values
• Selective transaction ordering: validators who see pending randomness requests can front-run or reorder transactions to influence outcomes

This vulnerability, classified as SWC-120 ("Weak Sources of Randomness from Chain Attributes"), has led to real-world exploits in blockchain games, NFT mints, and governance votes. The core issue is that any randomness derived from publicly observable chain state can be predicted or manipulated by participants who influence that state.

Use Cases

Chainlink VRF

Chainlink VRF is the most widely adopted on-chain randomness solution, operating as a decentralized oracle network service. As of late 2024, Chainlink VRF v2.5 has fulfilled over 21 million randomness requests across Ethereum, Arbitrum, Avalanche, BASE, BNB Chain, Polygon, and other networks. The service follows a request-and-receive pattern:

1. A smart contract calls the VRF coordinator contract with a randomness request and a seed
2. A Chainlink oracle node combines block data (unknown at request time) with its pre-committed private key to compute the VRF output and proof
3. The proof is verified on-chain before the random value is delivered to the contract
4. End-to-end latency is approximately 2 seconds

Notable projects using Chainlink VRF include Axie Infinity (random creature attributes), Aavegotchi (randomized portal traits), Bored Ape Yacht Club (Mutant Serum distribution), PoolTogether (no-loss lottery winner selection), and PancakeSwap Lottery.

Consensus and Leader Election

Several proof-of-stake protocols use VRFs as the foundation of their block producer selection:

• Algorand (Pure Proof-of-Stake): each token holder runs the VRF locally using their participation key and the current round's randomness seed. If the VRF output falls below a stake-weighted threshold, they are selected as a block proposer. This "self-selection" process is private: no one knows who the next proposer is until they broadcast their block and proof, preventing targeted attacks on known future leaders.
• Cardano (Ouroboros Praos): time is divided into epochs of 432,000 one-second slots. For each slot, every stake pool operator evaluates a VRF on the epoch nonce and slot index. Operators whose output falls below a stake-proportional threshold become eligible to produce a block. Leadership is determined locally, keeping proposer identities hidden until block publication.
• Polkadot (BABE): validators generate VRF outputs using epoch randomness and slot numbers. Those below the stake-weighted threshold may produce blocks for that six-second slot. All VRF outputs from block production feed into the randomness pool for the next epoch.

DNSSEC and Internet Protocols

Beyond blockchain, VRFs have applications in internet security. The NSEC5 proposal for DNSSEC uses VRFs to provide authenticated denial of existence for DNS records without enabling zone enumeration. Current DNSSEC mechanisms (NSEC and NSEC3) are vulnerable to offline dictionary attacks that allow adversaries to discover all domain names in a zone. NSEC5 prevents this by requiring online VRF computation, ensuring that only authorized queries receive proofs of non-existence.

VRF Standards and Constructions

RFC 9381, published in August 2023 by the IRTF Crypto Forum Research Group, defines two families of VRF constructions:

ECVRF provides stronger security guarantees than RSA-FDH-VRF, including full uniqueness (even against adversarially generated keys when key validation is enabled) and resistance to malicious key generation attacks. Most blockchain implementations use ECVRF due to its smaller proof sizes and faster verification.

Post-Quantum Developments

Current VRF constructions rely on the hardness of problems like elliptic curve discrete logarithms, which quantum computers could potentially break. Research into post-quantum cryptography has produced lattice-based VRF constructions. Algorand is developing LB-VRF (Lattice-Based VRF) built on Module-SIS and Module-LWE assumptions, producing 84-byte VRF values with approximately 5 KB proofs. Evaluation runs in about 3 milliseconds with verification taking roughly 1 millisecond, making it practical for consensus use.

Risks and Considerations

Key Compromise

VRF security depends entirely on protecting the secret key. If the private key is leaked, an attacker can predict the output for any input, completely defeating the randomness guarantees. The uniqueness property means the attacker can compute the exact output for any future input, making all randomness from that key predictable.

Single Point of Failure

When a single node holds the VRF secret key, that node becomes a critical dependency for both liveness and security. If the node goes offline, randomness generation halts. If the node is compromised, all outputs become predictable. Distributed VRF schemes (where the key is split among multiple parties using threshold signatures) mitigate this, but introduce coordination complexity.

Malicious Key Generation

Without proper key validation, adversaries may craft VRF key pairs that produce skewed output distributions, increasing their chances in stake-weighted selection protocols. RFC 9381 notes that ECVRF with key validation enabled mitigates this risk, but RSA-FDH-VRF requires additional verification steps that are not always enforced.

Oracle Trust and Liveness

In oracle-based implementations like Chainlink VRF, the oracle cannot manipulate outputs (the proof prevents this), but the system still requires trust that the oracle will respond to requests. A censoring or offline oracle can deny randomness to specific contracts. Chainlink addresses this through decentralized oracle networks, but the trust model differs from purely on-chain solutions like VRF-based consensus.

Gas Costs and Latency

On-chain verification of VRF proofs requires computation that costs gas. For applications like gaming or NFT mints, the request-and-receive pattern introduces latency (approximately 2 seconds for Chainlink VRF) and additional transaction costs. Applications requiring instant randomness must account for this asynchronous flow in their design.

VRFs and Related Cryptographic Primitives

VRFs sit at the intersection of several cryptographic concepts. They combine the unpredictability of pseudorandom functions with the verifiability of digital signatures. Unlike zero-knowledge proofs, which prove knowledge of a secret without revealing information about the output, VRF proofs are designed to convince a verifier that a specific output is the correct one for a given input. And unlike commit-reveal schemes (where a party commits to a value and later reveals it), VRFs produce the random value and proof in a single step, eliminating the delay and coordination overhead of multi-round protocols.

For blockchain systems that need provably fair randomness (whether for advanced cryptographic applications, gaming, NFT distribution, or consensus), VRFs provide a mathematically grounded solution that balances unpredictability with transparency.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.