Generating Random Numbers using Blockchain Technology for Gaming

Nicole Cai, Tony Nguyen, and Paul Whitman

Abstract

Blockchain-based random number generation represents a provably fair mechanism for online games of chance if implemented correctly. Depending on the blockchain technology, seeds used for random number generation may not have sufficient entropy as most inputs are deterministic or inherently favor a participating party. This paper explores possible implementations of pseudorandom number generators (PRNG) using Turtle Network (v1.2.6) which implements the Waves open blockchain protocol (v1.2.6).

1. Introduction

Players of traditional (or centralized) games of chance are exposed to many of the same risks as any centralized system. The lack of transparency in a centralized system introduces the possibility of systemic risks both intentional (GGB News, 2016) and unintentional. Without transparency, it becomes possible for a centralized system owner (i.e., “the house”) to bias outcomes in their favor. Decentralized blockchain-based applications (dApps) using smart contracts offer a provably fair consensus-based system to determine outcomes that can be openly reviewed and improved upon by all participants.

This paper addresses two decentralized blockchain gaming uses: a transaction-level PRNG and block-level PRNG systems.

These solutions have the characteristics of generating random numbers that are:

1. Not determined by the miner
2. Not biased toward the smart contract invoker
3. Not biased toward the game master
4. Eventually uniformly distributed

2. Ride smart contracts

Ride is the functional programming language for smart contracts and decentralized applications (dApps) in the Waves open blockchain protocol.

2.1 Complexity cost

Ride v4 scripts have a fixed complexity limit of 4000 (Waves, n.d.). The following table contains several RNG-related functions and the associated complexity cost.

Selection of a PRNG mechanism for a game of chance must be balanced with the complexity cost. If a PRNG is too complex (e.g., NIST HMAC_DRBG which consumes 4 hash function calls per round (Barker and Kelsey, 2015: 92)), there will not be enough complexity remaining to implement the game.

2.1 Complexity limitations

Ride is non-Turing complete (Waves, n.d.) and lacks a loop function (e.g., for, while/do, do/while). The FOLD<N> macro is available and enables operations on a list of values against an accumulator.

2.2 Selected hashing function

The SHA-256 hashing function was selected for the following properties:

1. Collision resistance: It is the computational infeasibility of finding two different inputs to the hash function that have the same value (Dang, 2012).

2. Preimage and second preimage resistance: Given hash_value, it is computationally infeasible to find such that hash(x) = hash_value or find a second input x (Dang, 2012).

3. Availability in Ride: The SHA-256 range of functions are natively available in Ride (Waves, n.d.).

2.3 Miner impact on randomness

As both methodologies utilize the signature of miners, there is a relationship between the source of entropy and the number of miners and/or distribution of blocks within the network.

BLAKE2b-256 hashing function is used to generate block signatures in Waves (Waves, n.d.). This hashing function also has the properties of collision resistance and preimage/second preimage resistance (Chang, S.-J. et al., 2012).

3. Sources of Entropy

One of the challenges of generating random numbers in a blockchain system is the limited sources of entropy. Examples of possible sources of entropy include:

4. Transaction-level PRNG

4.1 Single Number Generation

A transaction-level PRNG assumes that a random number must be generated and returned within the same user transaction.

All variables beside those calculated or determined by the miner or the specific block are unsuitable as they can be pre-calculated. Therefore, the most appropriate source of entropy is the generation signature which uses the signature of the VRF of the block (Waves, 2019). However, miners can choose not to publish the results of the block and trigger a “re-roll”. As such, miners should be economically disincentivized.

To mitigate the opportunity of a miner utilizing their advantage multiple times in a block (i.e., via broadcasting more than 1 transaction within the same block), a transaction-level computed variable should be incorporated (the suggested being the transaction ID).

The following formula can be used to generate random numbers within a single transaction:

𝑅𝐴𝑁𝐷 = (𝑆𝐻𝐴256(𝑇𝑟𝑎𝑛𝑠𝑎𝑐𝑡𝑖𝑜𝑛𝐼𝑑 || 𝐺𝑒𝑛𝑒𝑟𝑎𝑡𝑖𝑜𝑛𝑆𝑖𝑔𝑛𝑎𝑡𝑢𝑟𝑒)) % 𝑀𝐴𝑋_𝑅𝐴𝑁𝐺𝐸 (1)

4.2 Calculating the miner advantage

By using a combination of entropy sources, advantage to either party can be eliminated. However, this is not the case for transaction-level PRNG as it inherently gives an advantage to the miner with a “re-roll”. This should be economically mitigated by ensuring the probabilistic advantage does not exceed the miner punishment for denying the block causing a “re-roll”. The miner advantage can be calculated with the following formula:

𝐵𝑅 + 𝐸𝑃 > 𝑀𝐴𝑋_𝐵𝐸𝑇 ∗ 𝑃𝑂𝑅 I𝑃𝑃 ∗

((𝐵𝑃 ∗ 𝑃𝑃)! − 1) (𝐵𝑃 ∗ 𝑃𝑃) − 1 L

(1)

Example:

BP = Miner assignment probability

𝑃𝑃 = The payout probability of the game MB = Max bet size

BR = Block reward n = Number of “rolls”

MAX_BET = max_bet that can be taken by a miner in a transaction POR = Payout ratio i.e., 1:1

EP = Extra punishment for abuse (i.e., potential for leasers to un-lease)

Suppose the outcome of a coin flip is wagered where the maximum bet size is $1 and the winning payout doubles the bet. If the miner has a 20% chance of being allocated a block, the calculation would be:

$1 ∗ 1 ∗ I0.5 ∗

(0.2 ∗ 0.5)”## − 1

(0.2 ∗ 0.5) − 1 L (1)

In this case, the miner’s opportunity cost on rejecting the block must be > $0.555*.

5. Block-level PRNG

This system enables random numbers to be generated across more than one block. A commitment scheme with miner-sourced entropy should be used if the “game master” is incentivized to also win the game.

5.1 Commitment scheme

A commitment scheme (or “Commit and Reveal”) is a pattern that enables multiple parties to assert a statement without it being immediately visible and then revealing the values to all parties at a later point. As a random number generator can span across transactions and blocks to allow multiple participating parties to interact, it is possible to remove the miner bias. This methodology is used in several PRNG reliant blockchain games today (Axiomzen, 2019).

5.2 Using the game state to generate random numbers

Fair pseudorandom number generators can be achieved by maintaining a game state that is stored across multiple blocks. This methodology works as follows:

1. Commitment: Game master commits a randomized string © to the game state to begin a new game.

2. Betting phase: The betting phase (BP) begins for any quantity of blocks from the transaction of commitment.

3. Miner signing: The block before the end of the game is signed by the miner (Sig(𝐵!)).

4. Reveal: Once all betting is complete, the game master reveals their verifiable signature (Sig(c)) which is hashed with the signature of the block before the end of the game to generate a random number.

Figure 1. Example of block-level PRNG implemented across 3 blocks.

This methodology assumes there is no collusion between the miner and game master as they would represent two opposite parties in a game (one being the winner and one being the loser). Everyone can verify the revealed signature using a Public Key stored within the dApp data (PublicKey(Sig)).

The game master cannot change the committed answer to influence the outcome, and the miner does not know the outcome when committing their signature. Therefore, this methodology meets the criteria:

1. Not biased toward the miner

2. Not biased toward the smart contract invoker

3. Not biased towards the game master.

A* as defined by the period within the final block before the generating transaction can be also used as the betting phase if the game master does not have an inherent interest in also winning the game. If the game master has an inherent interest, during the commit phase they would know the signature of the previous block and could pre-calculate the outcome during phase A*.

Multiple random number generation

In some games, multiple random numbers may be required from one entropy source. Using the techniques described in section 4 and 5 and the multiplicative group modulo p (Ireland, 2013), multiple numbers can be generated. This methodology is as follows:

1. Determine the MAX_RANGE of a random number.

2. Find a prime number (p) that satisfies the equation:

𝑃 = 𝐽 ∗ 𝑄 + 1

J = Large even number Q = Prime number

(1)

3. Use the technique from section 4 or 5 to generate a random number R.

4. Convert R to H such that H satisfies:

1 < 𝐻 < 𝑃 − 1 (2)

This can be done by using H = R % (P−1); if H < 2, R = HASH(R) and repeat.

5. Apply the formula below, incrementing j for every additional random number to be generated.

𝑅𝐴𝑁𝐷$ = 𝑆𝐻𝐴256(𝐻$(𝑚𝑜𝑑 𝑃)) % 𝑀𝐴𝑋_𝑅𝐴𝑁𝐺𝐸 (3)

Example:

To generate multiple numbers in a single transaction that meets the criteria:

The follow equation can be used:

0 < 𝑅𝐴𝑁𝐷 < 65 (1)

𝑅𝐴𝑁𝐷” = 𝑆𝐻𝐴256(𝐻% (𝑚𝑜𝑑 𝑃)) % 64 + 1 (2)

𝑅𝐴𝑁𝐷% = 𝑆𝐻𝐴256(𝐻& (𝑚𝑜𝑑 𝑃)) % 64 + 1 (3)

…

MAX_RANGE = 65

P = 17729

J = 64

Q = 277

H = (𝑆𝐻𝐴256(𝑇𝑟𝑎𝑛𝑠𝑎𝑐𝑡𝑖𝑜𝑛𝐼𝑑 || 𝐺𝑒𝑛𝑒𝑟𝑎𝑡𝑖𝑜𝑛𝑆𝑖𝑔𝑛𝑎𝑡𝑢𝑟𝑒)) % 17728 (4)

Terms and Definitions

Project Website & Socials Website: https://nightlifecrypto.com/ Twitter: https://twitter.com/nightlifecrypto Discord: https://discord.gg/9xFMsfupMY Telegram: https://t.me/nightlifecrypto Flote: https://flote.app/nightlifecrypto Medium: https://nightlifecrypto.medium.com/ Bittube: https://bittube.tv/profile/NightLifeCrypto Facebook: https://www.facebook.com/nightlifecrypto/ Youtube: https://www.youtube.com/channel/UCDiZBl8RrXoPxiB98rDWwcg/ Reddit: https://www.reddit.com/r/NightLifeCrypto/ Bitcointalk: https://bitcointalk.org/index.php?topic=5342748 NLIFE Casino: https://nlife.casino/ BSC Contract Address: 0x86cbBEDCa621Ae78a421A40365081cAafDA24296 Coingecko: https://www.coingecko.com/en/coins/night-life-crypto CoinPaprika: https://coinpaprika.com/coin/nlife-night-life-crypto/ Dextools: https://www.dextools.io/app/pancakeswap/pair-explorer/0x56971ea2cf2a5b9a5c700d2d644c5ca999fa9113 Pancakeswap: https://exchange.pancakeswap.finance/#/swap?inputCurrency=BNB&outputCurrency=0x86cbbedca621ae78a421a40365081caafda24296(edited)

Night Life Crypto

Website: https://nightlifecrypto.com/

Twitter: https://twitter.com/nightlifecrypto

Discord: https://discord.gg/9xFMsfupMY

Telegram: https://t.me/nightlifecrypto

Flote: https://flote.app/nightlifecrypto

Medium: https://nightlifecrypto.medium.com/

Bittube: https://bittube.tv/profile/NightLifeCrypto

Facebook: https://www.facebook.com/nightlifecrypto/

Youtube: https://www.youtube.com/channel/UCDiZBl8RrXoPxiB98rDWwcg/

Reddit: https://www.reddit.com/r/NightLifeCrypto/

Bitcointalk: https://bitcointalk.org/index.php?topic=5342748

References

Axiomzen (2019) RNG on Ethereum blockchain. Available at: https://github.com/axiomzen/eth- random (Accessed: May 28, 2021).

Barker, E. B. and Kelsey, J. M. (2015) Recommendation for random number generation using deterministic random bit generators. National Institute of Standards and Technology.

Chang, S.-J. et al. (2012) Third-round report of the SHA-3 cryptographic hash algorithm competition. Gaithersburg, MD: National Institute of Standards and Technology.

Dang, Q. H. (2012) Recommendation for applications using approved hash algorithms. Gaithersburg, MD: National Institute of Standards and Technology.

Ireland, D. (2013) The multiplicative group modulo p, DI Management Services. Available at: https://www.di-mgt.com.au/multiplicative-group-mod-p.html (Accessed: May 28, 2021).

Rigged online gambling network busted in Italy (2016) GGB News. Available at: https://ggbnews.com/article/rigged-online-gambling-network-busted-in-italy/ (Accessed: May 28, 2021).

Waves Technologies (2019) WEP 8: Adding VRF in Consensus, Waves.tech. Available at: https://forum.waves.tech/t/wep-8-adding-vrf-in-consensus/17563 (Accessed: May 28, 2021).

— (n.d.) About Ride, Waves.tech. Available at: https://docs.waves.tech/en/ride/#predictable- computational-cost (Accessed: May 28, 2021).

— (n.d.) Generation signature, Waves.tech. Available at: https://docs.waves.tech/en/blockchain/block/block-generation/generation-signature (Accessed: May 28, 2021).

— (n.d.) Limitations, Waves.tech. Available at: https://docs.waves.tech/en/ride/limits (Accessed: May 28, 2021).

— (n.d.) Sha256, Waves.tech. Available at: https://docs.waves.tech/en/ride/functions/built-in- functions/hashing-functions (Accessed: May 28, 2021).