The goal: generate random numbers on player input, similar to a dice roll.
From cursory exploration of Google, ETH Stackexchange, Medium, here’s my impression of the topic:
- randomness is really hard. Especially with blockchains, due to their deterministic nature.
- solutions relying on timestamps, blockhashes, block difficulty are vulnerable to local simulations to get the desired output.
- if there is monetary value tied to the transaction, miner collusion can happen beyond a certain threshold.
I’m thinking of using future blockhashes rather than instant. The player initiates the “dice roll” with his selected odds through one transaction. Then, after at least 1 block, he sends another transaction that will settle the dice roll, using the previously provided values and the “future” block hash (now mined).
I assume there’s no way to guess a future blockhash in advance. Is this assumption correct?
Likewise, because on POA we have validators who stake their identity and alternate mining blocks at regular intervals, collusion would be an easy-to-spot social suicide.
Let’s assume the above is correct. My current implementation for a random number is as follows:
uint(keccak256(abi.encodePacked(blockhash(resolveBlock[msg.sender]), resolveBlock[msg.sender]))) % 100;
where “resolveBlock[msg.sender]” is the next block number from the previous transaction.
It seems to generate a random number from 0 to 99, and I’m not seeing any problem with it. But, I’m green behind the ears in computer science, and I would love to know if anyone spots a problem with the idea.