We recently hosted a white elephant game. Going over the code and explaining the important bits would be neat and help players get a behind the scenes look.
Using truffle (I was a big fan) will waste a ton of your time when it comes to deploys. It works today, but tomorrow it will tell you that it won’t deploy. We have moved completely to hardhat.
For the skeleton of the project, we have used this: https://github.com/wighawag/template-ethereum-contracts. It has everything that you need for Solidity development. The final product is here: https://github.com/RENTFT/white-elephant-contracts.
Rules of the game are the following:Players buy tickets before the deadline. Max number of players is set at 255 NFTs are loaded up into the contract; this version of the game supports ERC721s. Only whitelisted depositors can deposit. This is required to forbid external parties from spamming the contract with subpar NFTs.
Interestingly, it is claimed that ERC-1155 is ERC-721 backwards compatible. And, in fact, you can find some hints of this in the official Ethereum EIP GitHub issue: https://github.com/ethereum/EIPs/issues/1155. We found out that Rarible, for example, does not have a function transferFrom, nor does OpenZeppelin’s interface or implementation.On or after that date, the deployer calls the initStart function, passing the number of times he wishes to invoke Chainlink (to obtain VRF). He must also supply random seeds for each call. The above populates our entropies array. This is done by Chainlink. Now we have blockchain verifiable randomness. At this stage, we can slice and dice the randomness to produce deterministic randomness. Since there are only 255 players in total, we could slice Chainlink’s response into chunks of uint8. Chainlink will give you back a random uint256, and so essentially you get 32 random numbers of size uint8. They may overlap! We are taking binary slices here. We call initEnd having applied our dete...