Randomness on Chain

Every node must reach the same result from the same inputs. That requirement makes genuine randomness impossible on-chain, and several things need it anyway.

Why it is needed

Validator selection in proof of stake. Who proposes the next block must be unpredictable, or the proposer could be attacked in advance.

Lotteries and games.

Fair distribution of limited items.

Sharding assignments, where participants must be allocated unpredictably.

The naive approaches and why they fail

Block hash. Frequently used and exploitable. The block producer sees the hash before publishing and can discard a block whose hash produces an unfavourable outcome, at the cost of the block reward. If the prize exceeds the reward, this is profitable.

Timestamp. Controlled by the producer within a tolerance.

A future block hash. Better, because it is unknown at commitment time. Still influenceable by whoever produces that block.

External data from an oracle. Moves the trust to the oracle.

The approaches that work

Commit and reveal. Participants commit to a secret value by publishing its hash, then reveal it later. The combined values produce the result. The weakness is that the last participant to reveal can decline, which biases the outcome, so designs add penalties for non-revelation.

Verifiable random functions. A participant produces a value along with a proof that it was generated correctly from their key and an input. Anyone can verify the proof; nobody can predict the output without the key. This is the mechanism used for validator selection on several networks.

Verifiable delay functions. A computation that takes a known minimum time regardless of parallelism. Combined with commit and reveal, this prevents last-mover manipulation, because the manipulator cannot compute the outcome in time to act on it.

Threshold schemes. Multiple parties jointly produce a value, none able to determine it alone.

What to check in any application using randomness

Where does the randomness come from. If the answer is a block hash, the application is manipulable by block producers.

Who could influence it, and what would they gain. Manipulation is an economic question: it happens when the prize exceeds the cost.

Is there a delay between commitment and outcome that prevents last-mover advantage.

The general lesson

This is a good example of a problem that is trivial in ordinary computing and genuinely hard in a system where every participant must reach the same answer and some participants are adversarial.

Most of the difficult problems in this field have that shape: the constraint is not computation, it is that everything must be verifiable by parties who do not trust each other.