I suggest asking for the random number once in the startDrawPeriod function and recording a seed for the following reasons:
The number draws will be faster. As VRF flows will require 2+ blocks for every number + the cooldown.
The code will be simpler.
We will know how much LINK to use.
If we agree on this, we'd only need to modify startDrawPeriod() and add fulfillRandomWords(...). fulfillRandomWords(...) could store the random word as a variable. And then we could use that variable and nonces in drawNumber() only by changing the variables we put into the hash functions.
Design considerations:
The contract must be resilient to Chainlink VRF failing to call the fulfillRandomWords function.
The contract must not change its random number once it is set. Otherwise, advanced players can change the number to increase their chances of winning.
It's the time to integrate Chainlink VRF.
The documentations are available on:
Here's the example contract getting randomness from Chainlink docs: https://remix.ethereum.org/#url=https://docs.chain.link/samples/VRF/VRFv2DirectFundingConsumer.sol
I suggest asking for the random number once in the startDrawPeriod function and recording a seed for the following reasons:
If we agree on this, we'd only need to modify startDrawPeriod() and add
fulfillRandomWords(...)
.fulfillRandomWords(...)
could store the random word as a variable. And then we could use that variable and nonces indrawNumber()
only by changing the variables we put into the hash functions.Design considerations:
fulfillRandomWords
function.@daggerhashimoto you should review this issue.