Games with Oracles on Blockchains (Part I)
By F.
Many games only become interesting with randomness. The first popular app using Bitcoin was Satoshi Dice, which relied on betting whether a random number between 0 and 64000 would end up below some threshold, with gains corresponding to the odds of each threshold.
Randomness on the blockchain is a nontrivial problem. The typical use of block hashes is flawed, as it gives miners/bakers the power to intervene by manipulating blocks, especially in proof-of-stake designs. One better solution is to use an Oracle: an outside account which provides random numbers on demand. As always in the world of cryptocurrencies, this oracle cannot be trusted blindly, it should be held accountable. This is the role of the Alea/Mediator contract, which serves as an on-demand provider of randomness for various dApps.
Let’s consider various ways in which the Oracle might inject randomness into a game of, say, Rock Paper Scissors (RPS). Alice signals her willingness to play against the RPS contract. The RPS contract asks the Oracle to pick a random number and commit to it. Alice reveals her play, the Oracle reveals its play, and the winner is decided. In this article, we examine various ways to implement this game and the challenges encountered along the way. In the next article, we will go into further details and present a working prototype.
The Oracle
The Oracle is a provider of randomness, much like the maker of a slot machine: it provides a number between, say, 0 and 99, to anyone who requests it. The main property we expect from the Oracle is to commit to a random number, and then stick to it while it is being used in a game, without the ability to change it and influence the outcome while someone is playing. The side issue of bias in the randomness of the Oracle is not considered here: we will make the assumption that if the Oracle is biased, someone will eventually notice and take advantage of it.
Blind Trust
The simplest model one could imagine would be to blindly trust the Oracle:
- Alice plays Rock, Paper or Scissors;
- the Oracle inputs its random number, 0 for Rock, 1 for Paper, 2 for Scissors;
- the RPS contract decides who wins.
Of course the Oracle could easily cheat by conveniently always choosing a number that makes it win.
Commit and Reveal
A simple model with trust would be one in which the Oracle commits to a random number (with a hash of this number along with a nonce to prevent a brute force attack), and then the RPS contract:
- waits for the Oracle to input their commitment;
- waits for a player input;
- waits for the Oracle to reveal their random number (and a nonce to match the previous commitment);
- decides on the winner and finalizes the game;
- if the Oracle never reveals its random number, it is punished in some way (this will be examined below).
One inconvenient of this method is that it is heavy in terms of data transmitted: for every random number queried by the app, the Oracle has to send a hash (32 bytes for SHA-256) and a nonce (8 bytes for a 64 bit search space).
Batch Commit and Reveal
This is roughly how Satoshi Dice works:
- The Oracle commits to a batch of random numbers (u₀ … uₙ) — which we call “prophecies” — at the beginning of the day;
- Every play (pᵢ) is processed by blindly trusting the Oracle to provide a prophecy (uᵢ). In Satoshi Dice, this is done on a web page; now this can be done on a smart contract;
- At the end of the day, Satoshi Dice publicly reveals the commitment and anyone can check that the sequence of numbers provided by the sequence of reveals matches this commitment. Once again, using smart contracts, this step can be automated.
Punishment of the Oracle in Case of Malicious Behavior
In the last example, the only damage done to Satoshi Dice if it were to cheat on its commitment would be reputational: flouted players would still lose their bets for the day, but in the future no one would trust the website anymore. This is already better than nothing, but it can be improved on with smart contracts.
On Chain Alea
For this, we introduce an intermediate contract OnChainAlea which is meant to deal both with dApps and with the Oracle account.
Specification
On the Oracle side, the OnChainAlea contract records commitments (hₖ), sent by the Oracle, corresponding to a secret list (u₀ … uₙ) of random numbers — prophecies — , in the shape of a SHA-256 hash of the concatenation of a number nonce and the list (u₀ … uₙ):
hₖ = sha256( nonce, u₀ … uₙ)
As they are requested, the Oracle reveals batches of prophecies (uᵢ) until, after all prophecies have been revealed, it reveals the nonce. The OnChainAlea then verifies this nonce and the recorded prophecies against the corresponding commitment (hₖ).
On the dApp side, OnChainAlea may be queried using an id for each request. The contract then books this slot for the dApp – RPS, for example – and marks it as reserved.
The corresponding prophecy is not revealed right away, however, due to the risks of the chain reorganizing: someone might intercept the prophecy and use this information to their advantage in a different branch of the chain. Thus, a waiting period is enforced between reserving and revealing a given prophecy. Depending on the stakes, the waiting period could be chosen anywhere between one minute and one day: we envision several levels of risk embodied in different versions of the contract.
Reputational Punishment
A first step is to model exactly what happens on Satoshi Dice, up to the reputational loss: put a Boolean trusted flag on the OnChainAlea contract which immediately turns to false if the Oracle does not meet its obligation, for example by:
- not providing the sequence of random numbers it committed to, after a reasonable amount of time;
- providing a sequence of random numbers which does not match the commitment.
In this case, the information that the Oracle cheated is immediately and inalterably (by virtue of the immutability property of blockchains) published for all to see.
Financial Punishment
We might go further and propose a financial penalty on the Oracle.
The Oracle sends a bond to OnChainAlea which needs to be higher than the “value” of the risk taken in blindly trusting a random number supplied by OnChainAlea from the Oracle. If foul play is detected (once again, by either not revealing the sequence or revealing an incorrect sequence), the Oracle will forfeit this sum. In fact, this sum might be distributed in turn to the “fooled” dApps; they might then repair the damage to their users in any predefined way they choose, such as refunding the cost of playing if there is one.
Next Time
Next time we will examine a working prototype for an oracle and an instance of the OnChainAlea contract on the Dune Network blockchain. Stay tuned for more!
Connect with us:
Discord: https://discord.gg/JBUGqFg
Telegram: https://t.me/dune_network
Medium: https://medium.com/dune-network
Twitter: https://twitter.com/dune_network
Reddit: https://www.reddit.com/r/dune_network/
Gitlab: https://gitlab.com/dune-network
Website: https://dune.network
Email: contact@dune.network
