← Studio Toriumi

Quantum Roulette · IBM Quantum

Experience real randomness.

Presets

How this result was decided

01 The server commits before you spin
02 The hardware bits are revealed
03 Take the modulo of the option count
04 Check the commitment, here in your browser

Ordinary computer randomness is not random

This is the important part, so please try it rather than take my word for it.

The "random numbers" a computer produces are a sequence computed from a seed. Multiply, add, take a remainder. That is all. So put in the same seed and the same "random" numbers come back, every time.

Press it again without changing the seed.

That is a pseudo-random number. It looks scattered, but anyone holding the seed knows exactly what comes next. Math.random() and the Mersenne Twister are the same shape — more digits and more mixing, nothing more.

Cryptographic randomness (crypto.getRandomValues) is better: it stirs in noise from the outside world — mouse movement, electrical jitter — as seed material. But the shape is unchanged: gather a seed, run a deterministic calculation. If the seed leaks, so does every output.

This is where quantum differs. A measurement outcome is not determined by any variable that existed before the measurement. There is no seed. Not "we haven't found it yet" — this is Bell's theorem, a mathematical result, confirmed experimentally (the confirmation won the 2022 Nobel Prize in Physics). So the quantum roulette can say "before this spin, nobody knew."

Why commit first?

The thing worth being suspicious of is whether the server is choosing the result. If the bits were generated at the moment you spin, the server could look at all your options and pick bits that land wherever it likes.

So the order is reversed. Before you spin, the server fixes the bits and hands you only a hash. At that moment it does not even know how many options you have. Deciding the bits without knowing the option count makes steering toward a particular option impossible in principle.

After the spin the bits and salt are revealed, and the hash is recomputed inside your browser (step 04 above). If it matches, nothing was swapped in afterwards.

The spin is theatre

Being straight about it: the result is decided before the wheel starts moving. The bits are revealed first, the winner comes out of them, and the animation is calculated backwards to land there.

Spinning it "physically" in the browser would just mean Math.random() decides, which has nothing to do with quantum mechanics.

The "superposed glow" before you measure is also a metaphor. The real superposition happens inside IBM's hardware; this screen only draws the result it receives. There is no superposition in your browser.

About modulo bias

Taking a 32-bit value modulo the number of options makes small indices slightly more likely (232 is not divisible by most numbers). Values outside the divisible range are discarded and redrawn — and when that happens, the page says so and shows the redrawn bits.

The rigged one is right next door

The fastest way to understand why the commitment matters is to see what happens without one. On the rigged roulette you pick the winner first — and the bits it shows and the modulo genuinely check out, because the bits were computed after the winner was chosen.

While they spin, you cannot tell the two apart. The difference only appears when you check the commitment. → Try the rigged one

What you still have to take on trust

All of it, plainly. Hiding this would defeat the point of the page.

You cannot verify that the bits really came from IBM hardware. I display "hardware", and that is all. The job-submitting code is public, but whether it is actually running is something you take on trust.

The commitment only rules out swapping after the spin. When the seal is made, I know what the bits are. I cannot aim them, because I don't know the option count — but that is the limit.

If you need something stronger, see the randomness beacon. It publishes bits at a fixed time each day and publishes the hash of tomorrow's bits today, so anyone can confirm that tomorrow's randomness is already frozen.

When you need a proper draw

The roulette keeps no records. You can spin as often as you like and there is no evidence you did, which makes it unsuitable when you need to show a draw was done properly. For that, use Quantum Draw, which issues a certificate and publishes verification code anyone can run.

Open source

Including the IBM hardware integration: toriumib/quantum-roulette (MIT).

Other things on the same hardware

Quantum Draw, the randomness beacon, Quantum Koan, and the Quantum Itinerary Solver.