7

I would like to create a gambling Dapp and for this I need a provably fair RNG. What are the best solutions for provably fair randomness in Cardano

Will Cardano add Chainlink VRF in the future?

6
  • Thanks for asking a question @hanno! It is, though, on the edge of guidelines... 'wen' is almost never helpful question here. If you rephrase to ask about the best solutions for randomness in Cardano, I think it will add more value. (And people will be more likely to respond, as that is more in scope). PS-- I'll answer about how to stay informed in discord :) Oct 8, 2021 at 4:24
  • Also, look into the ergo raffle dapp. I would assume they need verifiably fair randomness for that, and it's in EUTxO like Cardano. Oct 8, 2021 at 4:26
  • Ergo does not use a provably fair RNG
    – Hanno
    Oct 8, 2021 at 6:31
  • Thanks for updating @hanno, and checking out my (ultimately disappointing) reference. Upvoted your question! Oct 8, 2021 at 6:36
  • @MatthewCapps you are really great helper as you are trying hard to help. Great attitude Ergo as I understood is taking randomness from the previous block header
    – Hanno
    Oct 8, 2021 at 7:16

4 Answers 4

1

Have you checked genSeed function from Cardano.Crypto.VRF.Praos module?

This module is the Haskell implementation of libsodium, the library used by Algorand and Cardano to generate Verifiable Random Functions (VRF), which are key at the time of randomly choosing validators in both chains.

4
  • 1
    I don't think this can be compiled to Plutus in on-chain code
    – Mateus
    Jun 1 at 9:00
  • Can you please explain the reason? I'm just starting with Plutus and I understand that all Haskell code can be compiled to Plutus. Jun 1 at 10:19
  • Not all Haskell code, we have some builtins and only they can be used inside validators. So you wound't be able to use any haskell function at all since they don't use those builtins, but we can use the plutus prelude which contains a bunch of equivalent functions
    – Mateus
    Jun 1 at 13:49
  • Thanks for clarifying! Jun 1 at 21:03
0

It depends on the use case, but nut.link has been submitting the League of Entropy randomness beacon.

0

For The Open Source Cardano Lottery, I have created a pseudo random number onchain validator that uses parts of a tx id for the source of a random number. I am open to any feedback on this approach, but from what I have tested, I can't guess what the winner lotto ticket number will be in advance :)

https://github.com/lley154/cardano-lottery

13
  • But I guess you could "select" the result, since you you can use any of the N UTxOs you have and each UTxO has a different tx id
    – Mateus
    Jun 1 at 9:00
  • To clarify @Mateus, the lottery number is chosen by players before the final close tx is created. Only after the window to choose a winning number is closed is another transaction created that is used to derive the winning numbers. So someone would have to predict in advance what a tx id will be - which I believe is not possible.
    – lley154
    Jun 1 at 13:39
  • I see, so the tx id of the script it self is used?
    – Mateus
    Jun 1 at 13:41
  • yes, but only after the window to choose a winning number is closed. I created a state machine smart contract that ensures that only when the lotto is in the correct state that a winning number can be chosen from a UTXO (that must inclue the lottery thread token).
    – lley154
    Jun 1 at 13:50
  • It is not possible to generate random numbers on-chain. In your lottery, you set the winner with the closing transaction. The party doing this will inevitably have the power to chose the winner freely. There is no way to effectively prevent this. using the tx-id does not help. You can fine-tune your UTxO to get the tx-id you need.
    – Jey
    Jun 1 at 20:52
0

Getting randomness into smart contracts is a bit difficult on Cardano due to it's deterministic nature. In some cases, committment schemes can be used: https://www.youtube.com/watch?v=JXKf1JwVAOE which rely on the one-way property of hash functions. In this example, it's applied to a game between two parties, which are real competitors, so neither of them wants to reveal their secret information to the other and the outcome is indeed random. This doesn't work when the different parties might have some incentive to cooperate (e.g. against the operator)

One can also "collect entropy" from multiple parties as it was done here: https://github.com/input-output-hk/lobster-challenge

One can use a RNG oracle, but still has to deal with the determinism. So even if it's a perfectly fair random number, the gambler might just decide not to play (=submit their tx) in case they would loose. Maybe one can overcome it with validity intervals for tx and penalties for not submitting a tx, but it has some obvious drawbacks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.