In Ethereum smart contracts, getting true randomness can be tricky and dangerous. Here’s why:
The Problem:
When you use common methods like blockhash or now for randomness in Solidity, it can be manipulated by miners. This makes your contract vulnerable to attacks, especially in games or lotteries.
The code in the below attached image seems to generate a random number, but it’s predictable and can be exploited.
The Solution: Chainlink VRF 👀
Chainlink’s Verifiable Random Function (VRF) provides a secure and verifiable way to get true randomness that cannot be tampered with.
Here’s how Chainlink VRF solves the problem:
- Chainlink VRF generates a random number off-chain and provides cryptographic proof that it was done fairly.
- The smart contract verifies this proof on-chain, ensuring the randomness is - reliable and cannot be tampered with.
- The cryptographic process ensures that even miners or oracles cannot influence the outcome, hence guaranteeing true randomness
Top comments (1)
Great overview of the randomness problem. One thing worth adding -- the choice of randomness source should really be proportional to the stakes involved. For low-value entertainment dApps, block hash combos might be "good enough" and save you significant gas costs. But once real money is on the line (jackpots, lotteries, anything with ETH at stake), Chainlink VRF becomes non-negotiable.
I've been working on cryptoshot.space, an Ethereum jackpot game, and this exact tradeoff was the hardest design decision. The hybrid approach -- using cheaper randomness for non-critical paths and VRF for the actual payout determination -- gives you both cost efficiency and security where it counts.
The commit-reveal pattern is underrated for PvP games though. Two transactions feels clunky but it's the only approach where neither party can front-run the other.