ChoosingRam::increaseValuesOfParticipants
and ChoosingRam::selectRamIfNotSelected
are using on-chain values for randomness seed which results in weak randomness.
ChoosingRam::increaseValuesOfParticipants
hashes msg.sender
, block.timestamp
, and block.prevrandao
to create a supposedly random number to decide whether to improve the value of the challenger's NFT or that of the other player's NFT.
ChoosingRam::selectRamIfNotSelected
hashes block.timestamp
and block.prevrandao
to create a supposedly random number to chose the Ram for the event.
However, hashing these values does not create truly random numbers. Malicious users can manipulate these values or know them ahead of time:
Validators can know ahead of time the block.timestamp
.
User can mine/manipulate their msg.sender
value to result in their address being used to generate the winner.
prevrandao
suffers from biasibility, miners can know its value ahead of time. Furthermore, prevrandao
is a constant in multiple target chains, which further diminished randomness:
-- in zkSync, it is 2500000000000000
Blockchains are deterministic systems by nature, designed to achieve consensus across all nodes. Using on-chain values as a randomness seed is a well-documented attack vector in the blockchain space.
In the following test, player1
precalculates the "random" number used to determine the winner of the challenge,
challenges the other player only if he would win,
keeps challenging the other player until his NFT reaches maximum value.
Malicious users can game the system and challenge others only if they are going to win.
Manual review, Foundry.
Consider using a cryptographically provable random number generator, such as
Chainlink VRF v2 or v2.5 for deployment on Ethereum, BNB, and Arbitrum,
Randomizer.AI for ZkSync.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.