In this article, let’s find out how a rock-paper-scissors game on the Aleo blockchain is technically structured.
Rock-Paper-Scissors is a two-person game. Players choose an item (where 0 is rock, 1 is scissors, and 2 is paper) and determine the winner as follows: rock beats scissors, scissors beats paper, and paper beats rock.
In real life, players simultaneously choose an object and immediately determine the winner, but in web3 this is very difficult to implement. Blockchain is usually something very slow and public, so the process of creating such a game can be difficult. There is already a Solidity solution for “rock-paper-scissors” using encryption, but even so the program has some limitations.
The Solidity solution.
You can find it here: link. This is an incomplete solution, you need to augment the encrypted answer with the encrypted key, but further on we will proceed exactly from the hypothetical correct solution.
The idea of the solution is the following: we create a smart contract (i.e., third address), where participants send an encrypted number (e.g., 2 with the key 12345) and a bid (e.g., 1 ETH). Then participants will have to provide a key to decrypt their choice and then the program will choose a winner and send him the money. However, the following scenario is possible: one of the participants reveals his choice and his opponent, seeing that he lost, decides not to send the key to his answer. Hence, the logical solution to the problem is to set a time interval in which the second player must provide the key. But what if one of the players has an internet or power outage? Can’t we make the function work atomically?
Unfortunately, no. Privacy in blockchains is limited to fact that only information stored off-chain can be properly protected.
In the picture we see how the solution cannot be executed without time constraints (mentioning the fact that the participants do not trust each other).
The solution on Leo (in the Aleo blockchain)
Link to the solution: here.
How it works:
- Issue the challenge.
We send a record with an encrypted number and key (key and choice ciphers add up) to whoever we want to play with.
2. Then the second player will have to accept the challenge by sending his choice:
Here we see that the author of the program decided to do the following: not to encrypt the answer of the second participant, and then
3. The caller will have to confirm his key and the program will reveal the winner:
It is not yet possible to work with timestamps in the Aleo blockchain. Therefore, it is impossible to recreate trustless “rock-paper-scissors” game here.
Unfortunately, we see all the same limitations as in the Solidity solution. You can’t make it so that players can know the winner without trust. Even if we make it so that the second player encrypts his answer, both participants will have to reveal their key later.
Why do we need a key? The answer for beginners
Encryption only works one way. This means that the number is easy to encrypt and hard to decrypt. If we use the most popular encryption method (sha-256), then here the same message cannot have different hashes (as in any other normal encryption principles). That is, if I give the program a choice “2”, the output hash will always be the same (as on the picture). You can check it yourself via the following link: https://emn178.github.io/online-tools/sha256.html
Therefore you have to add the key to the encrypted message. An arbitrary number can not be decrypted if it’s encrypted with sha-256 or other advanced enough methods.
Original blog: link
