Monday, August 30, 2021

Decentralised Random Number Generation (DeRNG) for Blockchain gaming

I've recently co-authored a paper on DeRNG for Blockchain gaming. It explores possible implementations of pseudorandom number generators (PRNG) using Turtle Network (v1.2.6) which implements the Waves open blockchain protocol (v1.2.6).

Generating Random Numbers using Blockchain Technology for Gaming

Nicole Cai, Tony Nguyen, and Paul Whitman

So, what's the actual problem with generating random numbers on blockchain?

Random Number Generators are difficult to create, as illustrated by Scott Adams in this Dilbert comic.

Published in 2001, still relevant as ever.

Random numbers can be used in online games to create variation and deliver unpredictable outcomes (e.g. the contents of a gaming loot box, the next card in an online card game, type of enemy to spawn). Traditionally, random numbers are generated by a Pseudorandom Number Generator (PRNG) which is an operating system (OS) level function.

The deterministic nature of computer systems makes it difficult to “instruct” an OS to generate a random non-deterministic output. How do you instruct a computer to do something random? If the computer followed your instructions twice, would it generate the same random number? OS PRNGs sidestep this by collecting non-deterministic chaotic input or "entropy" from externally observable events such as user input, disk, network, or system interrupts to "seed" an RNG. Because blockchain smart contracts don't typically have access to these observable events or entropy sources, random number generation needs to be seeded in an alternate manner.

The stakes are high: without random numbers, online gaming becomes predictable: the contents of a loot box can be predicted before it is opened or purchased, the dealer's hidden cards are known, and it becomes possible for bots to play a perfect game. The problem of OS-based RNGs has been solved, but the next generation of decentralised Blockchain-based games don't have an effective RNG solution.

Isn't this just an entropy source problem? Have you tried using X?

There's an added dimension to blockchain RNG that doesn't exist with OS RNGs: the miners. In the traditional RNG context, an OS can be trusted to execute the RNG code and return the output. By contrast, smart contracts/distributed applications are executed by miners who might be incentivised to interfere with the result. Therefore, it comes difficult to use the few entropy sources actually available.

  • Block hash. This advantages the miner, as the miner can choose not to mine the block after determining the outcome. In effect, this allows a miner to "re-roll the dice".
  • Block timestamp. This advantages the miner, as the block timestamp can be manipulated to allow the miner to win.
  • Signature. Again, this advantages the miner, as the minster can choose not to mine the block after determining the outcome. This effectively allows a miner to "re-roll the dice".
  • External oracles. The solution becomes dependent on a service outside of the smart contract. It is possible for other players to front-run the oracle's results.
  • Verifiably Random Functions (VRFs). These were introduced in Waves 1.2, but have the same constraint as signatures.

So, what's the solution?

Read the paper -