Verifiable Randomness in Blockchain: Chainlink VRF and Commit-Reveal Schemes

Why On-Chain Randomness Is Hard

Blockchain is deterministic. Given the same state, every node in the network produces the same output from the same computation — this is what makes consensus possible. But randomness requires unpredictability. These two requirements are in fundamental tension.

Early smart contracts used block hashes as a randomness source: keccak256(blockhash(block.number - 1)). This is manipulable: miners can choose not to publish a block if the hash produces an unfavorable outcome for them, paying only the block reward to influence the random result. For games or lotteries with large payouts, this is worth doing.

In 2026, two approaches dominate: Chainlink VRF (Verifiable Random Function) for applications where randomness must be cryptographically verifiable and manipulation-resistant, and commit-reveal schemes for applications where a simpler, cheaper mechanism with different trust assumptions is acceptable.

Chainlink VRF v2.5: How It Works

Chainlink VRF generates randomness using a cryptographic VRF function applied to a private key held by Chainlink oracle nodes and a seed derived from the requesting contract.

The critical property: the oracle cannot manipulate the output. The VRF proof mathematically demonstrates that the output was produced from the specified seed using the oracle's key — not chosen to favor any outcome. If the oracle tried to provide a different output, the proof would fail verification.

VRF v2.5 request flow:
1. Contract calls requestRandomWords() on the VRF Coordinator, specifying the subscription ID, number of random words, confirmation blocks, callback gas limit, and key hash (which oracle node to use).
2. After the specified confirmation blocks, the Chainlink oracle generates a VRF proof and calls fulfillRandomWords() on your contract.
3. Your contract receives the random words array and processes them.

Subscription model: pre-fund a subscription with LINK tokens. Multiple contracts can share a subscription. The subscription balance is charged per request based on gas used for fulfillment.

Number of confirmation blocks: more confirmations = more security but more latency. For high-value randomness (lottery jackpot, rare NFT reveal), use 5-10 confirmations. For low-stakes gaming interactions, 3 is sufficient.

Implementing VRF in a Lottery Contract

A VRF-powered lottery example:

Inherit from VRFConsumerBaseV2Plus and initialize with the VRF Coordinator address.
Declare state: subscriptionId, keyHash, callbackGasLimit, numWords, requestConfirmations.
Map requestId to lottery round: mapping(uint256 => uint256) public requestIdToRound.
On draw: call s_vrfCoordinator.requestRandomWords() with your parameters. Store the returned requestId mapped to the current round.
In fulfillRandomWords(): receive randomWords array. Use randomWords[0] % totalTickets to select the winner. Pay out. Emit WinnerSelected event.

Edge cases to handle:
Multiple outstanding requests: a new draw should not start until the previous one is fulfilled. Use a bool drawInProgress or compare requestId to expected.
Failed fulfillment: if the oracle never responds (node down, insufficient LINK), implement a timeout mechanism that allows a manual re-request after N blocks.
Large ticket counts: modulo bias is negligible when totalTickets << 2^256. For very large ticket counts, use rejection sampling.

Always test VRF integration against Chainlink's VRF Mock on testnet. The mock allows synchronous fulfillment in tests without waiting for oracle responses.

Commit-Reveal Schemes

Commit-reveal is a two-phase protocol that achieves manipulation-resistant randomness without external oracles, at the cost of requiring multi-party participation and two transactions per reveal.

Phase 1 — Commit: each participant computes a hash of their secret: keccak256(abi.encodePacked(secret, address)). They submit this hash on-chain. The smart contract stores all commitments.

Phase 2 — Reveal: after all commits are received (or a deadline passes), each participant submits their secret. The contract verifies keccak256(secret, address) matches the stored commitment, and accumulates all revealed secrets into a combined hash: combinedRandom = keccak256(combinedRandom, secret).

The final random value is the combined hash of all revealed secrets. No single participant can manipulate the outcome without knowing all other secrets in advance. A participant who reveals last sees others' reveals but cannot change their own committed value.

Weaknesses:
Last-revealer advantage: the last party to reveal knows the current combined hash and can choose to reveal or not. If not revealing is cheaper than an unfavorable outcome, they may withhold. Mitigation: slash non-revealers, or use a timeout mechanism that uses the partial randomness if not all reveal.
Small participant sets: with few participants, collusion is easier. Best suited for games where many users each commit independently.

Choosing Between VRF and Commit-Reveal

Decision framework:

Use Chainlink VRF when:
- A single trusted outcome is needed (lottery winner, NFT trait generation, loot box drop).
- Manipulation-resistance is critical.
- You can afford LINK fees and oracle latency.
- The application is single-player or the random outcome is applied to all participants uniformly.

Use commit-reveal when:
- Multiple participants each contribute entropy.
- You want no oracle dependency.
- Transaction cost minimization is more important than oracle security.
- All parties are incentivized to reveal (each has something to gain from the outcome).
- Example: a card game where each player commits their hand selection.

Cost comparison for Ethereum mainnet in 2026:
Chainlink VRF: approximately 0.1-0.5 LINK per request (~$0.50-$2.50) plus gas for fulfillment (~50,000-200,000 gas depending on callback logic).
Commit-reveal: two transactions per participant. Gas cost scales with participant count.

For NFT drops, gaming loot, and single-outcome randomness: Chainlink VRF is the clear choice. For multi-party card games, dice games, and interactive randomness where every player provides entropy: commit-reveal scales better and eliminates oracle risk.