BlOClatCh is a simple, educational Solidity smart contract designed to explore one of the most fundamental challenges in blockchain development: generating verifiable randomness for games.
It simulates a basic "flip and match" game where players try to match two hidden "cards" (numbers) drawn by the contract. While it's a fun, lightweight concept, it serves as a critical demonstration of why relying on simple on-chain data for randomness is risky!
The mission of BlOClatCh is to:
Help new blockchain developers understand:
How on-chain state works
How randomness is generated
Why insecure randomness is dangerous
Show the gap between:
Simple, predictable on-chain randomness
vs.
True verifiable randomness (VRF)
And guide developers toward secure standards.
By letting users:
Deploy the contract
Play the game
Examine event logs
Analyze randomness behavior
They develop an intuitive understanding of blockchain behavior.
The project emphasizes that blockchain game development requires trustlessness, fairness, and unpredictability, and that shortcuts can lead to exploits.
Randomness is a critical component in blockchain-based games, lotteries, and decentralized applications. However, secure and unpredictable randomness is extremely difficult to generate on-chain.
Most developers new to Solidity rely on block variables such as block.timestamp, msg.sender, or predictable hashing patterns.
These methods look random, but they can be manipulated or predicted, especially by miners/validators.
This leads to major risks:
Players may exploit patterns to predict outcomes.
Miners can influence block data to tilt the result.
Games involving rewards become insecure and vulnerable.
There is a lack of simple, educational examples that demonstrate this issue clearly to beginners.
BlOClatCh is designed as a minimal and educational smart contract that simulates a matching/flip game while highlighting the core problem of insecure on-chain randomness.
The contract provides:
Players call play().
The contract generates two “cards” (numbers between 1 and 10).
If they match, the player earns a point.
Random numbers are generated using:
block.timestamp
msg.sender
totalPlays
These inputs are public, predictable, and manipulatable.
This provides a hands-on demonstration that such randomness should never be used in real games involving monetary value.
GamePlayed events broadcast all results openly.
View functions allow anyone to read:
total plays
total matches
The contract includes a built-in warning explaining why:
This randomness is not secure.
Real production games must use secure randomness sources such as Chainlink VRF.
India