1.
Dataset: state of the genesis wallet’s transactions at fixed height (699 in this case), saved to a file that’s saved and signed with our validator key on the Emer chain. Whatever the filename the hash stays and can be validated on chain in Emer block 508398 (showcase File Validator and Name-Value Storage).
2.
Extraction of eligible participants: We have removed team controlled wallets at this point and others that I knew for a fact didn’t belong in the draw (delta with dataset can be verified, also saved to file, signed and checked on chain (block 508450). For this occasion and thanks to small sample it was possible to put both on chain (data and hashsum of said data). You can see here that 4 entries make 2 that self-reference one another, this is for provability.
3.
The PRNG seed key (also file and data) used to generate actual list of random number. Same seed will always produce same numbers. There were 64 participants admissible so it generated 64 numbers at highest possible decimals:
4.
With:
vrf:sha256=c25a3209676970ab5b118357622097e720750b82c2efc7cebc1b0a60c4936fb7
and
ness:sha256=50fc90ac22cfbb6f0996eac1e5c6405de131ba90eb4b0b0dbad3f7ee90bb766d
we have 2 lists on 64 items provably verifiable that can be used together in whatever form to pick a winner/winners. The provably fair is done at this point.
5. [In Part 2 of the documentation, we are here]
Now each participant has a random number associated to it. At this point, for a one winner draw, we could just take the largest or smallest number to determine a winner but we’re doing full proof-of-concept and that includes Randpay. If we would like to determine a winner at this point, it is all on chain and about to become read-only. But for the full PoC Randpay another layer is added.
6.
Randpay challenge is simple: ask for a lottery ticket with 1/64 risk of paying and first (or last) to pay wins, keep running it will eventually (in less than 64 rounds) that every entry has a probabilistic position. That’s where the true magic is: as blockchains can’t do probabilistic very well by default, we’re going the extra-mile for a draw that’s not just a mere draw.
To add more randomness, it is now also possible to put participants and random numbers side-by-side and sort by random number from smallest to largest hence affecting the order in which the participants ‘do their draw’:
1/64 risk means that one will pass eventually.
Randpay is stateless, it doesn’t remember. When a Randpay challenge is provided, the node creates x-participants UTXOs and signs them all but 1 and that’s where the challenger win/lose (doesn’t pay or pay).
