There is no Math.random() on a blockchain

When a developer wants a random number, they simply type in the command “Math.random()”, and a random number will be generated.

Though helpful for developers to come up with a random number, on the blockchain, it doesn’t work. Instead of numbers being completely random, computers in the network need to arrive at the same number, not together, but independently.

The reason is that using Math.random() would result in many different computers coming up with many different numbers. This would produce different results for each computer and break blockchain agreement.

Because of this, blockchain protocols don’t just randomly generate numbers. They manufacture numbers that behave unpredictably.

Sealed Envelopes, and Who Opens Last

Ethereum runs a commit-reveal scheme. Simply, everyone submits a sealed answer first and opens it later, so nobody can change theirs after seeing anyone else’s.

Validators, which are operators who confirm the transactions, each pick a secret number and then publish it scrambled. The scrambling runs one way only, so the sealed version gives nothing away.

They then reveal the number in a set order, and each is mixed into a running total. Every validator sees the same reveals in the same order, so every machine calculates an identical total, which is what consensus needs. That total then decides which validators get assigned to verify which blocks.

With such a process, everyone contributes blind except whoever goes last. This allows them to calculate the outcome first, check whether it suits them, and withhold their number if it doesn’t.

A fix to such a process is developing a puzzle that takes a certain amount of time to solve but only takes seconds to check. Such a process has been designed in detail, yet there’s no plan to deploy one.

Asking Somebody Else

Another approach outsources the job, using a program on the chain that requests a number from a service outside it, called an oracle.

The job of the oracle is to produce a number, all while returning mathematical proof that it followed its randomness procedure.

When the program receives a number, it checks for proof before accepting anything. With a fabricated number, there’s no proof, so the number won’t be accepted.

The Same Problem, Solved by Audit

Long before blockchains, games built on drawn numbers or randomness had this exact requirement. A bingo online room pulling from 75, 80, or 90 numbers needs results recorded to settle disputes, all while being random so no one can predict the outcome.

The answer here, however, is institutional rather than mathematical. A certified random number generator is examined and signed off by an independent testing laboratory, like iTech Labs or eCOGRA.

Both work well, but they ask very different things of you. One expects you to trust a laboratory’s verdict and the other to verify the proof yourself. Neither of them eliminates trust; they just end up relocating it.

What Actually Gets Decided

Randomness of numbers decides a lot. They decide who gets paid to confirm a transaction, who gets through the door on a limited release, or who hits the jackpot.

A number doesn’t have to be predictable to be exploited. All it takes is one person to know it slightly sooner than everyone else to become an issue.

That’s the very reason that Math.random() has no place in the blockchain. Every machine would get a totally random result, resulting in consensus breaking.