Importing Randomness into Ethereum

An Outline for a Random Number Oracle Service

This article proposes an oracle service, a smart contract proxy for an external data-source, dedicated to providing random numbers to other smart contracts in the Ethereum blockchain.

Random Numbers Don’t Exist in Ethereum

Ethereum has no pseudo-random number generator (PRNG).

But that sure hasn’t stopped DApp developers; tons of smart contracts depend on some element of chance or randomness like lotteries, for example.

Since Ethereum can’t provide a built-in method for generating a random number these smart contract authors have turned to alternative and “clever” (emphasis on the sarcastic air-quotes) methods, such as using block variables or past block hashes.

Arseny Reutov, in his excellent article “Predicting Random Numbers in Ethereum Smart Contracts”, explores the multitude of mistaken paths developers have taken in trying to achieve randomness in their contracts, some with disastrous consequences — including losing funds.

He identifies four major groups of these random number seeking vulnerabilities:

PRNGs using block variables as a source of entropy

PRNGs based on a blockhash of some past block

PRNGs based on a blockhash of a past block combined with a seed deemed private

PRNGs prone to front-running

Arseny goes on to propose a safer method of using future block hashes as sources of entropy, which would require registering the random number request in one block, while the actual random number is generated in a subsequent block and made retrievable.

He also documents several external, oracle-service style methods (which bridge the gap between on-chain and off-chain data) such as using Oraclize’s URL connector to fetch data from random.org.

Why Not Make An Actual Oracle For It?

The problem with the oracle services mentioned are that they’re using one-size-fits-all web connectors and not really proving the incoming data is trustworthy (a full discussion of TLSNotary is available in this thread).

Additionally, the data retrieval is not instantaneous/available-in-block. That is to say, once a request is made there’s an associated round-trip occurring and the requester has to be messaged back by the oracle service with the new data.

But an RNG oracle service could be built as a single smart contract that receives regular updates of a “cache list” of random bytes that can be sources of entropy for same-block requests.

By partnering officially with organizations like random.org such an oracle service could demonstrate on both sides that the data was valid and sourced correctly.

This would allow smart contracts to rely on a trusted oracle service for same-block execution of their code while mitigating look-ahead and prediction vulnerabilities.

Such an oracle service could even monetize itself through rate-limits for free-loading smart contract addresses, while allowing subscribers at nominal costs.