Distributed Randomness Beacon

A distributed randomness beacon generates publicly verifiable random values that no single party can predict or manipulate.

Key Takeaways

A distributed randomness beacon produces unpredictable, unbiasable random outputs by combining entropy from multiple independent parties using cryptographic techniques like BLS threshold signatures or commit-reveal schemes.
Blockchains rely on unbiased randomness for critical operations: validator selection, lottery protocols, NFT reveals, and fair transaction ordering. Using block hashes as a randomness source is insecure because miners and validators can manipulate them.
Major implementations include the drand network (League of Entropy), Chainlink VRF, and Ethereum's RANDAO, each making different tradeoffs between decentralization, speed, and bias resistance.

What Is a Distributed Randomness Beacon?

A distributed randomness beacon is a service that periodically produces random values no single participant can predict, bias, or suppress. Unlike a conventional random number generator running on a single server, a beacon distributes trust across multiple independent operators. Each operator contributes entropy, and the contributions are combined cryptographically so that no subset of participants below a defined threshold can influence the output.

The concept addresses a fundamental problem in decentralized systems: who picks the random number? In a centralized lottery, the operator could rig the draw. In a proof-of-stake blockchain, a single source of randomness for validator selection would let the operator choose favorable validators. A distributed beacon eliminates this single point of manipulation by requiring cooperation from many parties, where each party can verify the output independently.

The earliest public randomness beacon was operated by NIST, which began publishing 512-bit random pulses every 60 seconds using hardware random number generators. However, NIST's beacon was centralized: users had to trust NIST not to manipulate outputs. Modern distributed beacons remove this trust requirement entirely through cryptographic proofs.

How It Works

All distributed randomness beacons share a common structure: multiple participants contribute randomness, the contributions are combined in a way that prevents manipulation, and the result is publicly verifiable. The differences lie in the cryptographic mechanism used to combine contributions. Three primary approaches dominate.

BLS Threshold Signatures

The most widely deployed approach uses BLS (Boneh-Lynn-Shacham) signatures with a threshold scheme. During a setup phase, distributed key generation creates a collective public key and gives each participant a private key share. To produce a random value:

Each participant signs the current round number with their private key share, producing a partial signature
Once a threshold number of partial signatures are collected (for example, 11 out of 15 participants), they are combined into a single group signature
This group signature is deterministic: the same round number always produces the same output, regardless of which specific participants contributed
The resulting signature is hashed to produce the beacon's random output for that round

The security guarantee is straightforward: as long as fewer than the threshold number of participants collude, nobody can predict or bias the output. The BLS signature scheme makes this efficient because partial signatures can be aggregated without interaction between participants.

Commit-Reveal Schemes

A commit-reveal scheme splits randomness generation into two phases:

Commit phase: each participant generates a random value, hashes it using a hash function, and publishes the hash as a binding commitment
Reveal phase: after all commitments are collected, participants reveal their original values. Anyone can verify each reveal matches its commitment
All revealed values are combined (typically via XOR) to produce the beacon output

Commit-reveal is conceptually simple but suffers from the "last-revealer problem": the last participant to reveal can see everyone else's values and choose whether to reveal or withhold, giving them a one-bit bias on the output. Adding penalties for non-revelation mitigates this but does not eliminate it for high-stakes applications.

Verifiable Delay Functions

A verifiable delay function (VDF) takes a minimum amount of sequential computation time to evaluate, but the result can be verified quickly. When applied to randomness beacons, VDFs solve the last-revealer problem: even if a participant sees all other contributions, they cannot compute the final output fast enough to decide whether to withhold.

The process works by feeding the combined contributions into a VDF. The sequential computation requirement ensures no participant can "look ahead" to see the output before the reveal deadline. Ethereum's research roadmap has explored adding VDFs to strengthen RANDAO against bias attacks.

Why Blockchain Needs Unbiased Randomness

Randomness is not optional in blockchain protocols: it is a security requirement. Any process that selects participants, distributes rewards, or determines ordering must use randomness that resists manipulation. Predictable or biasable randomness undermines the fairness guarantees that decentralized systems exist to provide.

Validator and leader selection: proof-of-stake consensus mechanisms randomly select which validator proposes the next block. If this selection is predictable, attackers can prepare targeted attacks against upcoming proposers or collude to censor transactions
Lottery and gaming protocols: on-chain lotteries, prediction markets, and gaming contracts require randomness that neither the operator nor participants can influence. Biased randomness turns a fair game into a rigged one
NFT reveals and fair minting: when NFT collections assign traits or reveal metadata, the randomness source determines rarity distribution. Predictable randomness lets insiders snipe rare items
Fair transaction ordering: randomized ordering mitigates maximal extractable value (MEV) strategies like front-running and sandwich attacks
Sharding and committee selection: protocols that partition validators into committees (for sharding or data availability sampling) must randomize assignments so attackers cannot concentrate stake in a single shard

The Problem with Block-Hash Randomness

Early smart contracts often used block hashes, timestamps, or difficulty values as randomness seeds. This approach is fundamentally insecure because miners and validators can influence these values.

A miner who finds a block can inspect the resulting hash before publishing. If the hash produces an unfavorable outcome in a randomness-dependent contract (a lottery they would lose, for example), they can simply discard the block and try again. As long as the value at stake exceeds the block reward the miner forfeits, this manipulation is economically rational.

Real exploits have demonstrated this vulnerability. In 2018, the popular Ethereum game Fomo3D used a combination of block.timestamp, block.difficulty, msg.sender, and block.coinbase as randomness seeds. Attackers deployed contracts that pre-computed the random values within the same block and only proceeded when the outcome was favorable: if unfavorable, the contract simply reverted the transaction. The lottery contract SmartBillions lost 400 ETH through similar block-hash manipulation.

// INSECURE: block-hash-based randomness
// A miner or contract can predict/manipulate this value
uint256 insecureRandom = uint256(
  keccak256(abi.encodePacked(
    block.timestamp,
    block.difficulty,
    msg.sender
  ))
);

// SECURE: using an external randomness beacon
// The oracle provides a value with a cryptographic proof
// that the contract verifies before accepting
uint256 secureRandom = beaconContract.getVerifiedRandom(requestId);

Major Implementations

drand (League of Entropy)

drand is the most widely used distributed randomness beacon. Development began in 2017 at the DEDIS lab at EPFL, building on research into scalable bias-resistant distributed randomness published at the 2017 IEEE Symposium on Security and Privacy. In June 2019, Cloudflare, Protocol Labs, Kudelski Security, the University of Chile, and EPFL announced the League of Entropy consortium to operate drand in production. The network has since grown to approximately 15 mainnet members, including the Ethereum Foundation, ChainSafe, and cLabs.

drand uses BLS threshold signatures on the BLS12-381 curve. Each round, participating nodes sign the round number with their key share. Once a threshold of partial signatures is collected, they combine into a single deterministic group signature that serves as the random output. The network operates two chains:

Default mainnet: 30-second round frequency, chained mode (each round is linked to the previous one), signatures on G2 of BLS12-381
Quicknet: 3-second round frequency, unchained mode (each round is independently verifiable), signatures on G1 of BLS12-381 for smaller and faster verification. Quicknet is recommended for new applications

Filecoin was drand's first major production user, relying on it for leader election in its consensus protocol.

Chainlink VRF

Chainlink VRF provides on-chain verifiable random function outputs for smart contracts. Unlike drand, which operates as a standalone beacon, Chainlink VRF is designed as a request-response oracle service: a smart contract requests randomness, and a Chainlink node generates a random value paired with a cryptographic proof.

The oracle holds a pre-committed secret key on the secp256k1 curve. When a randomness request arrives, the oracle combines block data (unknown at request time) with its secret key to produce both a random number and a proof. The proof is verified on-chain before the requesting contract receives the value, ensuring the oracle cannot manipulate the output.

The current version, VRF v2.5 (launched November 2024), is deployed on Ethereum, Arbitrum, Avalanche, BNB Chain, and Polygon. It supports payment in both LINK tokens and native gas tokens.

Ethereum RANDAO

Ethereum's beacon chain uses RANDAO as its built-in randomness mechanism. Every block proposer includes a randao_reveal field containing their BLS signature over the current epoch number. The beacon chain verifies this signature, hashes it with SHA-256, and XORs it into the running RANDAO accumulator.

With over 900,000 active validators contributing, RANDAO provides sufficient entropy for validator committee assignments and proposer selection. However, RANDAO is known to be biasable: the last proposer in an epoch can see all prior contributions and choose whether to reveal or withhold their value, giving them a choice between two possible outputs. This last-revealer bias is acceptable for validator selection (the cost of withholding a block outweighs the benefit of biasing selection) but insufficient for high-stakes applications like on-chain lotteries. Ethereum's research roadmap has explored VDFs as a long-term fix.

Security Properties

Academic literature evaluates randomness beacons against four canonical security properties:

Unpredictability: no adversary can compute any nontrivial information about future beacon outputs. The output must remain unknown until the designated revelation time
Unbiasability: beacon outputs must be uniformly distributed and independent of adversarial influence. No participant can skew the output to their advantage, even by choosing to participate or abstain
Availability (liveness): the protocol must continue producing valid outputs even when some participants are offline, unresponsive, or actively malicious, up to the threshold of compromised nodes
Public verifiability: any external observer can verify that a beacon output was generated correctly without trusting any individual operator. This is what distinguishes a beacon from a trusted random number service

Different implementations prioritize these properties differently. drand achieves all four when its threshold assumptions hold. Chainlink VRF achieves unpredictability and verifiability but relies on oracle operator honesty for availability. RANDAO achieves availability and verifiability but sacrifices full unbiasability due to the last-revealer problem.

Risks and Considerations

Threshold Assumptions

BLS threshold beacon schemes assume that fewer than t out of n participants collude. If an adversary compromises enough key shares to meet the threshold, they can pre-compute future beacon outputs and destroy unpredictability. The security of the beacon is only as strong as the independence and operational security of its participants.

Liveness vs. Safety Tradeoffs

Beacon protocols face a tension between liveness and safety. A low threshold (for example, 5 out of 15) makes the beacon resilient to outages but easier to compromise. A high threshold (12 out of 15) resists collusion but may stall if too many participants go offline. Protocol designers must calibrate this tradeoff based on the trust model and operational environment.

Oracle Trust in VRF Models

Chainlink VRF and similar oracle-based solutions provide verifiability (the proof prevents manipulation of the output) but introduce availability risk. If the oracle node goes offline or censors requests, the application receives no randomness. This is a weaker guarantee than a fully distributed beacon where no single node is critical.

On-Chain Verification Costs

Verifying beacon outputs on-chain requires cryptographic operations that consume gas. BLS signature verification on BLS12-381 is computationally expensive on the EVM, though precompile proposals and alternative curves (like BN254 for drand's evmnet) reduce costs. For applications that need randomness frequently, these verification costs can be significant.