Dice Rolls and Random Number Generation in CryptoFights
One hurdle to overcome when building games in the blockchain is how to achieve random number generation in a system where the all outcomes are deterministic. In order to achieve this in CryptoFights, we use a commit/reveal methodology which I present here.
Before each battle, all participant’s client generates a 256-bit random number locally. The client then hashes that number and subsequently hashes the resultant hash one time for each possible round of the battle. Let’s say battles are capped at 1024 rounds. In that case, each player’s client will store an array of random numbers 1025 elements long, with each random number generated from the previous number in the chain. These values are stored privately by the client.
As the players enter the battle, they submit the last number in the chain to the contract, locking in the entire chain, since each value is derived from the previous value. As the battle continues on, each player takes turns submitting an action to take. Once the action is submitted to the smart contracts, the opponent submits the next hash in their chain to resolve the acting player’s action. The submitted hash is hashed on the contract to validate that it is indeed the next hash in the chain. The submitted hash is then combined with the other player’s last submitted hash and the battle ID and hashed once again. The resulting hash is then used to determine a seed for all dice rolls within that turn.
This approach ensures that dice rolls are not determinable until after an action is taken, yet once the values are revealed, they produce a deterministic outcome of the battle which will produce the same output every time they are processed by nodes of the blockchain.
