Commit-Reveal and On-Chain Randomness Schemes

Generating randomness that neither party can manipulate — and that anyone can verify afterward — is one of the harder problems in distributed systems. The provably fair mechanism used by most crypto casinos is one solution, operating entirely off-chain. But games running on smart contracts face a stricter version of this problem: the randomness must be both unpredictable and verifiable on-chain, where no trusted server exists and every computation is public.

This article examines commit-reveal as a general cryptographic primitive, traces why naive on-chain randomness is exploitable, and explains how Verifiable Random Functions (VRFs) solve the problem — while noting that all of these schemes prove only that randomness was generated fairly, not that the game’s house edge is reasonable or the outcome is profitable for players.

Commit-Reveal as a Primitive

Commit-reveal is a two-phase protocol for making a binding commitment to a value before revealing it, preventing the committing party from changing their mind based on subsequent information.

Phase 1 — Commit:

commitment = HASH(secret_value || salt)
publish(commitment)

The committer publishes a hash of their secret, combined with a random salt to prevent preimage attacks on short secrets. The hash is binding: the committer cannot change the underlying value without producing a detectable mismatch.

Phase 2 — Reveal:

reveal(secret_value, salt)
# Anyone can verify:
assert HASH(secret_value || salt) == published_commitment

The verification step is simple, deterministic, and requires no trust in any third party. This is the foundation of provably fair gambling’s server seed commitment: the casino commits to a server seed hash, and the reveal lets you verify the seed was not swapped.

Mutual Commit-Reveal

For stronger randomness guarantees, commit-reveal can be made mutual — both parties contribute a value, and the final randomness is a function of both:

final_random = HASH(player_secret || operator_secret)

Neither party can bias the outcome without knowing the other’s secret first. If either party refuses to reveal, the protocol can include slashing conditions or timeouts. This structure is used in some smart contract game designs, though it introduces complexity around what happens if one party times out.

Naive Block-Hash Randomness: Exploitable by Design

Before oracle-based solutions became available, many blockchain games used the hash of a future block as their randomness source. The appeal is obvious: future block hashes appear unpredictable and are computed by the network, not by any single party.

// Simplified vulnerable pattern
function reveal(uint256 betId, uint256 revealBlock) external {
    bytes32 blockHash = blockhash(revealBlock);
    uint256 outcome   = uint256(blockHash) % 100;
    // pay based on outcome
}

This pattern has a critical flaw: the entity that produces the block controls the block hash.

Miner/Validator Manipulation

In proof-of-work blockchains, miners who are also players (or who collude with players) can selectively withhold blocks whose hashes produce unfavorable outcomes. If a miner produces a block, checks whether the resulting hash wins them a large bet, and discards the block if it loses, they can re-mine until a favorable hash appears. This is called block withholding or hash grinding.

In proof-of-stake systems, validators similarly choose whether to propose a block. A validator who controls the timing can observe game outcomes before finalizing the block and choose to propose or skip based on whether the outcome favors them.

# Simplified attack model
for each block_hash in candidate_blocks:
    if game_outcome(block_hash) == WIN:
        publish(block_hash)
        break
    else:
        discard and try next block

The economic feasibility of this attack scales with the bet size relative to the block reward. For small bets, the cost of forgoing or delaying a block reward exceeds the expected gain. For large bets, the math can favor manipulation.

The BLOCKHASH Opcode Limitation

On Ethereum, the BLOCKHASH opcode only returns hashes for the 256 most recent blocks. Games that use a future block’s hash must enforce a reveal window, and if the player or contract fails to reveal within that window, the randomness is unavailable — creating a class of griefing attacks where a player simply waits for a favorable block and reveals only then, or refuses to reveal unfavorable ones.

Verifiable Random Functions (VRF)

A Verifiable Random Function is a cryptographic construction that takes a secret key and an input (called the seed or alpha string) and produces both a pseudorandom output and a proof that the output was computed correctly from that key and input — without revealing the key.

(output, proof) = VRF_Prove(secret_key, alpha_string)

# Anyone with the public key can verify:
VRF_Verify(public_key, alpha_string, output, proof) == True

The key properties are:

• Pseudorandomness: Without the secret key, the output is computationally indistinguishable from random, even knowing the public key and the alpha string.
• Uniqueness: Only one output is valid for a given key and alpha string. The operator cannot produce multiple valid outputs and choose the favorable one.
• Verifiability: Anyone with the public key can verify the proof without the secret key.

Chainlink VRF in Practice

Chainlink VRF is the most widely deployed on-chain VRF solution. A smart contract requesting randomness sends a request on-chain with a seed value (typically derived from the requesting contract’s address, a nonce, and a user-supplied value). A Chainlink oracle node, holding the VRF private key, computes the output and proof off-chain and submits them to the VRF coordinator contract on-chain.

// Simplified Chainlink VRF v2 request
function requestRandomWords() external returns (uint256 requestId) {
    requestId = COORDINATOR.requestRandomWords(
        keyHash,          // identifies the VRF key pair
        subscriptionId,
        requestConfirmations,
        callbackGasLimit,
        numWords
    );
}

// Callback (called by Chainlink oracle after fulfillment)
function fulfillRandomWords(uint256 requestId, uint256[] memory randomWords) internal override {
    uint256 outcome = (randomWords[0] % 100);  // scale to game range
    // apply outcome to bet
}

The VRF coordinator verifies the proof before accepting the fulfillment. If the proof is invalid, the transaction reverts. This means the oracle cannot submit a biased result — the only valid output is the one correctly derived from the VRF key and seed.

# The oracle cannot cheat:
# - It cannot produce a different output for the same key+seed (uniqueness)
# - It cannot withhold a proof indefinitely without being slashed (economic mechanism)
# - The on-chain verifier rejects any invalid proof (cryptographic enforcement)

Trust Assumptions of Chainlink VRF

Chainlink VRF moves trust from “trust the casino” to “trust the Chainlink oracle node and the correctness of the VRF cryptography.” The oracle node holds the secret key. If that key is compromised or the oracle is dishonest, the randomness can be predicted. Chainlink mitigates this with multi-oracle setups, staking/slashing, and reputation systems, but the trust assumption is not zero — it is distributed rather than eliminated.

Comparing the Schemes

Property	Off-chain commit-reveal (provably fair)	Block-hash randomness	Chainlink VRF
Verifiable after the fact	Yes	Yes	Yes, on-chain
Exploitable by validators	Not applicable	Yes	No
Requires trusted third party	Casino server	No	Chainlink oracle
Available without blockchain interaction	Yes	No	No
Covers house edge or payout rules	No	No	No

The last row is the one that never changes. No randomness scheme — however cryptographically sound — touches the house edge or game economics. A game that uses Chainlink VRF with a 5% edge is verifiably random and economically unfavorable to players in exactly the same way as a game with a 5% edge using HMAC-SHA256. Randomness integrity and game fairness remain distinct properties.

Why This Matters for Players

Understanding the randomness stack helps you ask the right questions when evaluating a blockchain game or smart contract casino:

• Where does the randomness come from? Is it off-chain (casino server), block-hash (exploitable), or a VRF (cryptographically sound)?
• Who verifies the proof? For Chainlink VRF, the on-chain coordinator does. For provably fair, you do — but only if you actually run the check.
• What is the house edge? No randomness scheme answers this. Ask separately and check whether the disclosed edge matches the game’s payout structure.

For a broader overview of how smart contracts handle game logic and trust, see smart contracts fundamentals. For the player-side verification process under the standard provably fair model, see how to verify a provably fair bet yourself.

Technical soundness of the randomness layer is a necessary but far from sufficient condition for a game worth playing. Blockchain games carry all the risks of traditional gambling plus the added complexity of smart contract bugs, oracle failures, and the irreversibility of on-chain transactions.