This is a great initiative, thanks for starting it.

Your Fisher–Yates implementation biases selection of early entrants by use of modulus (Wiki explanation).

I suspect that reuse of the same entropy will introduce other biases, but how the affect the implementation is less immediately obvious. My initial thoughts are that you need to use the entropy from VRF in a construction like keccak256(abi.encode(vrf_entropy, counter)) so that each selection is independent. However this becomes expensive.

FWIW I'm @divergence_art in the NFT world should you want to chat on Twitter.

I love the batched reveal idea, but it's not clear to me how you would go from a single random number (entropy) for a batch of tokens to a unique id within a larger range. Do you have an idea for how this would be accomplished?

Thanks for sharing this @Anish-Agnihotri - really great ideas and helpful examples.

My question:
The design of the claimRaffle function seems to require the caller to know where their entry lies in the raffleEntries array. Is the idea that the results could be indexed once and then provided to customers via a frontend UI?

Ideally you'd have some way of quickly finding the indices by address, but storing that might get expensive quickly.

What do you think about _safeMint(msg.sender, ticket[i]) instead? Currently, if there's any value in a low tokenId then there's an incentive for gas wars / people gaming the system, but if you stop tracking nftCount and instead issue the shuffled position then that's negated.

Hey @Anish-Agnihotri, thanks for providing this sample contract. Both this and the article are really good resources!

I'm looking at the refund mechanism and wondering if it wouldn't be easier to just compare the number of winningTickets
with the entriesPerAddress(address) and just send the MINT_COST * (entriesPerAddress - winningTickets) as a refund ?

The advantage here is that we don't need to keep track of the losing tickets as well (which would have swapped indices because of the shuffling.

        // Refund losing tickets

        uint256 entriesPerAddress = entriesPerAddress[msg.sender];

        if (winningTickets != entriesPerAddress) {
            // Payout value equal to number of bought tickets - paid for winning tickets
            (bool sent, ) = payable(msg.sender).call{
                value: (entriesPerAddress - winningTickets) * MINT_COST
            }("");
            require(sent, "Unsuccessful in refund");
        }

        // Emit claim event
        emit RaffleClaimed(msg.sender, winningTickets, entriesPerAddress - winningTickets);

here are the reported gas numbers from the dapp-tools test suite if you run the specs around this method:

Running 5 tests for src/test/Benchmark.t.sol:MultiRaffleBenchmark
[PASS] testShuffleOneThousand() (gas: 231041478)
[PASS] testShuffleTen() (gas: 228839717)
[PASS] testShuffleHundred() (gas: 229039899)
[PASS] testShuffleTwenty() (gas: 228861935)
[PASS] testShuffleTenThousand() (gas: 251057487)

when i do the calculation of 10 shuffles vs 10,000 shuffles based on the approximate gas costs:

// total = gas for shuffle * current gwie cost
// gas low - 111 gwie -> 0.00000011 eth
// gas medium - 120 gwie -> 0.00000012 eth
// gas high - 140 gwie ->  0.00000014 eth

// shuffle 10 times
> 231041478 * 0.00000011
=> 25.414562580000002 eth
> 231041478 * 0.00000012
=> 27.724977359999997 eth
> 231041478 * 0.00000014
=> 32.3458069 eth

// shuffle 10000 times
> 251057487 * 0.00000011
=> 27.616323570000002 eth
> 251057487 * 0.00000012
=> 30.126898439999998 eth
> 251057487 * 0.00000014
=> 35.14804818 eth

I have a few questions around the shuffle according to these example calculations, assuming they are correct:

1) the costs are high, shuffling 10000 times though is only approximately 2-3 ether more than shuffling 10 times - why is this cost so close considering shuffle count in total is drastically different?

2) I understand the paradigm blog post and this repo come with no guarantees that this style of contract could be run on L1, I assume its mainly because of the shuffle costs - is there a way that anyone can think of to provably run the shuffle offchain and only write the final state of the shuffle back on chain?

I was thinking a merkle proof potentially but im unsure of the exact correct steps to prove-ably run the shuffle off chain so I was hoping someone might be able to provide guidance on what that might look like if you can go that route.

3) if the shuffling cannot be done offchain in a provable and appropriate fashion - is there a randomish enough shuffle implementation that would be more cost efficient or not so heavy -- that could be implemented in the place of the Fisher-Yates shuffle?

one piece im looking at is this requirement:

// Ensure raffle requires clearing (entries !< supply)
require(raffleEntries.length > AVAILABLE_SUPPLY, "Raffle does not need clearing");
// Ensure raffle requires clearing (already cleared)
require(shuffledCount != AVAILABLE_SUPPLY, "Raffle has already been cleared");

if AVAILABLE_SUPPLY = 10000:
if raffleEntries.length == 9999 then no shuffling is required
if raffleEntries.length == 10001 then 10000 shuffles are required
if raffleEntries.length == 10500 then 10000 shuffles are required
etc

this boundary of all or nothing seems like it could be reduced if you wanted to ratchet down the intensity of making an exact shuffle - potentially an adjusting threshold in which fluctuates iterations based on AVAILABLE_SUPPLY + AVAILABLE_SUPPLY > raffleEntries.length > AVAILABLE_SUPPLY if that makes sense.. the Fisher-Yates shuffle seems like it requires the entire supply to be shuffled in order to truly create randomness, wondering if there is an in between alternative shuffle that would still be somewhat respectable level of randomness.. thoughts?

Hey nice stuff!

uint256 winningTickets = nftCount - tmpCount;

 if (winningTickets != tickets.length) {
            // Payout value equal to number of bought tickets - paid for winning tickets
            (bool sent, ) = payable(msg.sender).call{
                value: (tickets.length - winningTickets) * MINT_COST
            }("");
            require(sent, "Unsuccessful in refund");
        }

here there is cpmparison of winning ticket != tickets.length.

What if number of tickets is 100 and nobody is a winner. since there is no winner winningTickets is 0. And the function will transfer the money as refund?

Am I missing something?

When minting token id starts from 1, not 0:

functions that depend on tokenId, e.g. tokenURI will return unrevealed data for id 0.

Probably want to add LINK_TOKEN.transfer(msg.sender, LINK_TOKEN.balanceOf(address(this))); to withdrawRaffleProceeds() or some other helper.

There's all kinds of scenarios where we end up with $LINK trapped in the contract after it's no longer active, easy to forget.