Games and lotteries need numbers nobody can guess. On many blockchains, developers buy that randomness from an oracle, and @chainlink's VRF is a popular choice. On Internet Computer ($ICP), b
Games and lotteries need numbers nobody can guess. On many blockchains, developers buy that randomness from an oracle, and @chainlink's VRF is a popular choice. On Internet Computer ($ICP), built by @dfinity, apps get random values from the network itself.
Chainlink's documentation says random numbers cannot be generated natively in smart contracts, so randomness must be requested from an oracle. The oracle generates a number and a cryptographic proof, then returns the result to the contract that requested it. Chainlink says the proof is published and verified onchain before any consuming application can use it.
Internet Computer takes a different route. According to its developer documentation, canisters (the network's smart contracts) can generate cryptographically secure random numbers directly from canister code. The feature runs through the raw_rand method offered by the management canister.
The network uses a threshold verifiable random function. Per the docs, the result is produced collaboratively by the subnet's nodes using a random beacon that no single node can predict or bias.Every node independently verifies the output, and the same 32 bytes are delivered to all replicas.
Timing is what keeps the value unknown in advance. The documentation explains that the randomness is unknown when the request is submitted, and ICP resolves the call in the next execution round, which makes the value impossible to predict. Each new round brings a fresh value: the VRF generates 256-bit random blobs in each execution round.
There are practical limits. Only canisters can call raw_rand, not external clients through ingress messages.Randomness is not available in query calls, because a query runs on a single replica and cannot access the subnet-level random beacon.
For builders of games, lotteries and other fairness-sensitive apps, the difference is architectural. Instead of paying an outside oracle and waiting for a callback, a canister asks the management canister for randomness and receives it from the subnet's own consensus layer. Because the application can see the value before its users do, developers building lotteries should fix their rules before a draw takes place, so the outcome cannot be exploited.
The two designs aim at the same goal: results that no single party can steer and that anyone can check. Chainlink VRF does it with an oracle network and onchain proofs, while Internet Computer does it with its subnet nodes and chain-key cryptography.
Sources:
