All raffles are scams: How to raffle the Ethereum way
ETHCC 6 · July 2023 · 17:34
Kevin Tjiam presents a cryptographic raffle method designed to support any number of winners at constant gas cost. The speaker discusses avoiding modulo bias and compares the design with Fisher-Yates-based approaches.
Speakers
Topics
From ETHCC 6, hosted by Ethereum France.
Transcript
[Music] thank you [Music] [Applause] [Music] yep hey everyone uh thanks for coming to my talk my name is Kevin charm today I'm going to talk about how all Raffles are scams and how to raffle the ethereum way now obviously I'm not saying all Raffles
are scams this is kind of a clickbait title but you knew that already my argument is that all off-chain Raffles should be considered scams because inherently they're black boxes right they're in transparent so they could tell you how they draw random numbers and how they shuffle them but you can't really know for sure you can't really verify it the truss model is basically trust me bro right however on chain Raffles the way that we do them now um they're very inefficient right so so for example like if you're drawing like 100 winners on chain you're going to be spending like millions of gas you're kind of scamming yourself right
um this is a technical talk um I'm going to be talking a bit about Raffles wire Raffles um and then I'll show you how to perform Raffles on chain with a novel algorithm hopefully you've never seen before and then there'll be like no excuse for not ever doing a ravel on chain ever again right so what are Raffles when I'm talking about Raffles I'm saying um we're picking X number of winners from n number of participants and essentially technically that means that we are shuffling a list of participants and then we pick the top X as winners right uh why do we do Raffles well they're
good for if you remember doing the nft craze we did allow lists to kind of solve the gas War problem which kind of worked um they're also good for giveaways so like for marketing good marketing tool for Brands and communities uh but what's wrong with off-chain raffles well during the allow list like NFC craze there were you know allegations about insiders manipulating the allow lists themselves um or even the results um for example like this happened with like premium and moon Birds there's many such cases basically you need to trust
the influencer that's doing the giveaway of the raffle right that they'll do the whole process fairly and distribute the prices fairly and it comes down to like a lack of transparency verifiability and immutability like they can rug you right they can decide just not to give you the price at the end however they are cheap to run because you don't have to use the blockchain right why on chain Raffles well the blockchain gives us transparency we all know that everything is public or the logic on all the actions um it's all public anybody can see it anybody can verify it um and we use we can use cryptography to enforce fairness for example we can use
something like vrf to be able to verify that a random number was generated actually randomly um and we can use like Randa which is also enforced by cryptography and there's also trustlessness because uh we can use uh given we use immutable contracts um a raffle can load a price distribution contract and they can't decide to rug you right if the codes are deployed and I I believe that Raffles are actually like one of the main like one of the only use cases of blockchains where it like really makes sense um to only use the blockchain because the properties of a decentralized blockchain network is actually extremely important um
to enable like the best form of a raffle so why are people using on-chain Raffles right now well they're very inefficient it requires storing participants in a big like storage array on chain which is gas heavy on ethereum and winners are drawn usually by using an algorithm called Fisher Yates and these this has a few problems so one of them is like the naive implementation of Fisher Yates can introduce modular bias so that means that it's not so fair some people will have more chances to win than other people
depending of course on the parameters of the raffle and it's it's very expensive in terms of gas for every winner you want to pick it increases linearly right so if you want to pick like 100 winners starts costing like millions of gas 1000 winners like forget about it wouldn't even fit in the block right and the winners have to be picked in order so it has to be done synchronously you have to pick like the the 10th prize claim winner has to wait for the ninth has to wait for the eighth Etc right now to have a look at how it doesn't scale uh the Devcon raffle if you all remember they had like an auction raffle for the
tickets they picked 80 winners on chain it costed about 10 million gas right and Paradigm they try to optimize this um they did pretty good so the odd goblers contract can pick 250 winners with about 7.6 million guests but it's only like a minor Improvement right and it's only like two million gas Improvement there's other implementations of like this raffling shuffling Fisheries algorithm you can see the me bits mint and you can also see it in the HCC raffle that they did now can we do better I give you the lazy Marco raffle so this is a novel method of raffling
that I hope you've never seen before it's built on cryptography and it requires uh two components local trees and stateless Shuffles so everybody knows what a miracle tree here is right everybody knows what a Michael tree is I'll go through it anyway um so Miracle Roots can compress arbitrary large lists into like a single hash right so you can have any any list of any lengths and it can just be compressed down to this single 32 byte hash Merkel proofs can succinctly prove that a particular item is in the list right
and the last thing about Merkel trees that we Overlook most of the time is that local proofs also approve the index of that item in the list and that's important for the next step so this is just the visualization of uh Merkel tree so this is like the list of participants and this is how it would look like as a Merkel tree and if we wanted to prove that c is part of that list then we would have this proof right and this proof includes the index so it's two in this case so the second component is the stateless Shuffle right so I want you to forget about
array-based shuffling uh we we don't deal with arrays so sailor shuffles is an algorithm that can deterministically map bijectively using a random seed an original index to a shuffled index in the same domain without duplication that may be pretty hard to understand but it's actually used in ethereum consensus so there's the swap or not algorithm that can compute um the validators that need to validate an epoch and there's also something called the Faisal Shuffle which is what I'm going to be talking about
and so basically once we have a random seat we can lazily interact with the shuffled list right that's that's the important thing this is a visualization of a stateless Shuffle so on the left you have the original indices of the list and you can see that these are these are the stateless functions stateless shovels and every time you compute one it outputs the shuffled index using some random seed right and it's a it's a one-to-one mapping so there's no repetition now if we put them together
then what we have is we have each participant can generate a miracle proof that includes an index the original index and then we can feed that index into this stateless Shuffle function and then we can say that if that shuffled index is less than the number of winners we want to pick then they are a winner and we can compute this very efficiently on chain this is a visualization of the flow so if we have the Merkel proof and then we have the stateless shovel we can feed the index like so and then we end up with with this Shuffle index zero
and then we can decide is it less than the number of winners we want to pick if yes then the owner of that proof is the winner is a winner otherwise they're not a winner and that's that's basically the algorithm and now if we apply that to the Devcon auction raffle we can actually reduce the gas required to draw from 9.7 million gas to only 60 000 yes so you're no longer scamming yourself as a raffle holder right um if you're curious about how that works you can go to docs.ferry.dev there's a bit of like a light paper there that explains the whole thing
is in here yeah so in a nutshell um we can just store a miracle root instead of the entire participants array if we want to do a non-chain raffle and the cost of raffling is always constant for the raffler right it's better than the Fisher Yates Shuffle um because it's instant it doesn't require synchronous execution of the raffle draw so any winner can claim their prize at any time after a random seed has been chosen yeah and with this we can have a very gas efficient verifiable and very scaled launching rifles
so some of the trade-offs right because we're using Miracle proofs Merkel Roots we don't store the actual data that's required to create those proofs on chain so there's no da guarantee if you store it off chain it's basically like a validium right but in the future you could post this as a 4844 blob to the beacon chain and it'll be very cheap and then you have basically fully Unchained raffles um and yeah we we defer computation of the shuffling to the winner during the claim and that's what makes it super cheap and efficient it's only about a four thousand gas overhead for someone who's claiming a price
so what does this enable um well it enables uh portability of Raffles so you could do cross-domain Raffles for example you can collect entries off chain and then you can just post a local route to a raffle contract on ethereum and distribute prices on ethereum or you can collect entries on Arbiter Nova and bridge that Markle route to ethereum mainnet or you can execute the raffle on ethereum with a Randa or something and then you can Bridge the miracle route and the random seed to a prize distributed contract on optimism arbitrim wherever you want it basically enables like efficient 100 end-to-end trustless raffles on ethereum
and you can actually see it in action if you go to fairy raffles.com it's live it's on arbitrine one um it's pretty simple you just put in a list of participants and then I use vrf to create a produce a raffle and then it shows you how to create proofs for each winner to claim a prize you can even consume the miracle root on chain if you write a price distributor contract and it can be like a fully Unchained rifle uh we also experimented during East Denver with this fun thing we like uh collected entries on orbital Nova all sponsor transactions and then we just
bridged the medical route to ethereum Mana to distribute nft prizes so yeah that's my talk thank you [Applause] does anyone have any questions yeah if somebody have questions just raise your hand we will give you microphone I have two questions first of all I remember maybe I remember wrong but I remember on chain there is no true Randomness so far the VR I have the chain link one and the other options it's all fake Randomness so in order for your algorithm to work do you rely on
fake or true Randomness the second question is how exactly do you reduce the order of n to order of one that that part I didn't quite understand it sounds like it's a tremendous reduction of the amount of iteration that the algorithm has to go through then if you can expand a little bit on the second points as well thank you so the first question was uh does it require um like real Randomness so I didn't talk about where you would Source the randomness um that's still up to you to decide what source of Randomness is enough for you for your case if you want a verifiable source of Randomness you might use vrf although it has liveness issues you might use randow although it has bias
issues but there's there's always a trade-off right there's no like real true source of verifiable random that's like doesn't have any trade-offs not yet anyway maybe with Randa plus vdf but we are still pretty far from that so the let's answer your question first question yeah second question was was the second question oh yes how did I reduce the gas consumption like by orders of magnitude yeah so it's it's similar to if you imagine like an airdrop how you would do an airdrop naively is you would just send like you know n times to all the participants right and that would be very expensive right or you could just store a miracle route containing all the
people who could receive the airdrop and then everybody can claim uh asynchronously and that's how it works so we defer the computation we push some of that gas to the claimer of the price even though the overhead is very small it's only 4 000 yes so it's still a lot cheaper you could still do like you could still do the airdrop method with this and it would still be orders of magnitude cheaper than doing the naive raffle yeah question I didn't get why uh vrf is not true Randomness right now because uh it's yeah so vrf is like true Randomness right because it's uh it's a signature
it's a deterministic signature so uh the properties of the signature is that it must be uniformly distributed otherwise it's like guessable right um so it is like a good source of Randomness but there are problems with like liveness right uh so for example it's it's a very centralized vrf is like one chain link node if they choose to censor your um your vrf request they can just not answer your requests and then you can't do anything about it you just have to request another one friends if you don't have any more questions thank you for your attention thanks everyone
[Applause] [Music]