Forgeries contest - izhelyazkov's results

Gas optimizations:

• Replace immutable variables with constant in VRFNFTRandomDraw.sol - the variables don't get instantiated in the constructor, thus have no need to be immutable. Constant variables are cheaper.
• Settings struct in interfaces/IVRFNFTRandomDraw.sol can be re-ordered to pack the token and subscriptionId variable into a single slot, because token is an address type - 160 bits, and subscriptionId is of uint64 type - 64 bits, their total is 224 bits, which is less than the EVM word size of 256 bits. So, packing them together will save a potential cold read / write.
• CurrentRequest struct in interfaces/IVRFNFTRandomDraw.sol can be changed to pack hasChosenRandomNumber and drawTimelock in a single slot, again potentially saving additional reads/writes gas cost. This can be done by reducing the number of bits drawTimelock takes - since the drawTimelock represents a timestamp, it can be safely represented in a uint64 type (which accounts for a max timestamp in the next 550 years) or a uint72 type (which can account for max time of the next 150k years). Additionally, currentChosenTokenId in the same struct can be reduced to uint176 type or even less, accounting for the maximum token ids which can be chosen in a given collection (usually less than 10 000 NFTs are in most collections). With smart packing of the variables relative to their maximum values, it may be possible to pack all of the variables into the struct in a single slot.
• No need to cache msg.sender in makeNewDraw function in VRFNFTRandomDrawFactory.sol or winnerClaimNFT function in VRFNFTRandomDraw.sol - will be more expensive than using msg.sender directly - using msg.sender costs 2 gas, while caching it in a variable costs 3 gas to push in on the stack.
• transfer / safeTransfer can be used in lastResortTimelockOwnerClaimNFT and winnerClaimNFT function in VRFNFTRandomDraw.sol instead of transferFrom to save on gas.