We are comparing random number generation with Chainlink and with methods like:
uint256(keccak256(abi.encodePacked(block.timestamp, block.difficulty, i))
We examined the above posted code results programatically (in terms of distribution) and we came to the conclusion that the results are distributed uniformly.
But what about predictability? is it acutally possible to predict the outcome of
uint256(keccak256(abi.encodePacked(block.timestamp, block.difficulty, i))?
Did anyone ever use Chainlink random numbers? Is it really worth it?
hey @JP_1! If you are going to be using block.difficulty in POS networks I recommend using block.prevrandao instead of block.difficulty, as the former replaced the latter.
Using block.prevrandao for random number generation in Ethereum post-merge has some predictability issues due to the nature of the Randao mechanism.
The prevrandao value is biasable to some degree because of the "last revealer problem." Validators at the end of an epoch can choose to sign or not sign the data, influencing the final randomness. Each controlled validator at the end of a slot gives the attacker a one-bit influence on the output.
To use prevrandao more securely, it's recommended to use a prevrandao value at least four epochs in the future to ensure a new set of validators and reduce predictability. Additionally, avoiding slots near the beginning of an epoch is crucial, as an attacker could attempt to bribe or attack the known validators to gain early knowledge and influence the randomness. Waiting for at least 128 blocks guarantees waiting four full epochs.
Chainlink VRF is well-established and commonly used. However, it depends on the economic security of the Chainlink network and requires LINK.