Random number generation in a high-frequency decentralized betting

In order not to waste readers time — very short recall for randomness requirements on a blockchain:

1. Random numbers can not be published to the blockchain before a transaction with the bet using this random number is confirmed. (Otherwise mempool explorers can do a simple front-running).
2. Random number generation algorithms can not be solely based on previously known values such as blockhash, blocktime etc…
3. For high-frequency betting speed is crucial for users’ experience. As an example of a roulette game, users can not wait 15–20 seconds before a random number generated and GUI entertainment with wheel rotation starts.

The above leads to two widely accepted solutions implemented up to today:

1. Decentralized oracles (like Chainlink). No need to describe a solution here, just follow https://docs.chain.link/docs/vrf/v2/introduction/. Pros of this implementation are reliability, reputation, and good for marketing of your dApp. Cons are price and speed. Chainlink is quite costly, which becomes a bottleneck for high-frequency betting. Minimum two transactions are required to get a random number, several blocks waiting time. Not so great for user experience.
2. Commit-and-reveal scheme. In the commit-and-reveal scheme, first a commit word is assigned by an off-chain back-end server of the dApp. After that second transaction is coming from the off-chain server with revealed word and the check that hashes match is performed. The code snippet below explains the mechanism:

Typical commit-reveal scheme in Solidity

Very simple, cost effective and fair solution.

The bottleneck here is two transactions needed that leads to quite a long waiting time. The path of the random number generation is quite long:

User UI (bet generation) => Off-chain Server (commit word generation) => User UI (send bet) => Blockchain Node (sending to Mempool)=> Mempool (wait for mining)=>Blockchain Node (send to off-chain server) =>Off-chain Server (recover revealed word) => Blockchain Node (send to mempool) => Mempool (wait for mining)=> Blockchain Node (send to off-chain server) => Off-chain server (send to user) => User GUI. This scheme leads to an average of 15 seconds waiting time on the Polygon network. Remind, that Polygon block mining time is about 2–3 seconds.

In addition to above there is double spending for transaction costs.

How to optimize the algorithm above and melt it down to one transaction? At True Casino we implemented it as follows:

Commit-reveal scheme at True Casino

What can we see here? In one transaction we process the previous bet and set a new one. Along with that, once a transaction with a new bet is confirmed we can already publish a random number to the user from our off-chain server.

Voilà!!! One transaction and random number is available. The average waiting time achieved is 5 seconds along with an average transaction cost of about 0.007 USD on Polygon network.

Want to test it? Visit our truecasino.org website and go to a roulette game. It is currently implemented on Polygon mainnet, but uses test USDC ERC-20 token. You can mint it in the wallet dialog once the wallet is connected.