create vrf documentation

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 20, 2024 2:28am

[nialexsan]

could you please add some info regarding resetBet and revealBet? I need to run resetBet between committing bets and how to know whether my bet has won or lost from revealBet? it doesn't return anything, and I don't see any changes in my balance. I ran it 10 times and didn't win anything

[bthaile]

Are all the contracts available on testnet? I didn't see contract addresses.

[sisyphusSmiling]

Also, theres a similar example included in this PR (without the move obfuscation) as a contrast between Cadence & Solidity implementations. I think it would be helpful to link to the repo

[Aliserag]

Are all the contracts available on testnet? I didn't see contract addresses.

No

[Aliserag]

Are all the contracts available on testnet? I didn't see contract addresses.

None of the contracts are available, the user deploys them in the guide

[tarakby]

ok, good idea to omit to the commit-reveal section for now.

We should also omit the section https://developers.flow.com/evm/guides/vrf#generating-random-numbers-in-a-range as per my comment above as it's promoting an unsafe implementation, especially that is mentions applications like "lotteries".

[sisyphusSmiling]

@tarakby can you suggest a resource or point me to a methodology for safe implementation of function getRandomInRange(uint64 min, uint64 max) public view returns (uint64)? I've looked around and the only resources I could find referenced rejection sampling which doesn't pair well with the computational constraints of the contract environment IMO.

Edit: I revisited the article you shared on modulo bias and see the concept of modulo reduction. I'll explore this and see if it's workable in this context.

[tarakby]

@sisyphusSmiling there are two main ways to avoid the modulo bias:

1. rejection sampling as you pointed out. The number of rejections isn't deterministic but the performance isn't necessarily bad if implemented correctly. For instance, if you need a random less than 5 (encoded in 3 bits) and your random generator provides 64 bits. You should not iterate till the 64 bits number is less than 5, you should consider 3 bits at a time from the 64 bits, and check if those 3 bits are less than 5 (it is the case with more than 50% - I let you do the math). This is the method we implemented in Cadence for revertibleRandom(modulo).

2. get extra bits of randomness so that the modulo bias becomes negligible. If you need a random less than k and our security level target is 128 (considered safe enough and is used in Flow), we need to sample a log_2(k) + 128 bits, and not just 64 bits. Then we can use the % operator.

   These 2 methods are cryptographically secure and are recommended by the cryptography standards. Here is a more technical resource on why this works: https://www.zkdocs.com/docs/zkdocs/protocol-primitives/random-sampling/#sampling-from-zq

[sisyphusSmiling]

Thank you for the advice @tarakby! I've added a first pass in https://github.com/onflow/random-coin-toss/pull/22, would appreciate a cursory review when you get the chance 🙏