Gaming on the Blockchain — Making it Work

In a previous article, we have argued in favor of crypto-gaming. The blockchain is ideal for hosting games for a variety of reasons, including the fact that it is easy to represent fungible and non-fungible assets in the form of tokens. These can be game characters and other digital assets, for example, 3D role-playing heroes and items, such as weapons and armor in CryptoFights. Another reason for gaming on the blockchain is the decentralized and transparent nature of the underlying platform, which has the potential to convert gaming in a fair and open process.

However, as we have also already pointed out, most crypto-games fail to meet these expectations and are nothing more than gambling or collectible trading sites. So why has crypto-gaming so far failed to take off properly? The answer is simple: It’s actually very hard to implement an exciting game on today’s blockchain technology.

There are several limiting factors that make it hard to implement the type of interactive experiences gamers would like to see:

• Transaction speed: Transactions take a while to process. On Ethereum the average block time is around 15 seconds. This means that any operation that requires changing state on the blockchain is subject to a serious response lag, particularly in times of network congestion.
• Lack of entropy: Most games require some form of random number generation. The blockchain is deterministic, as all transactions have to compute to the same value on all participating nodes. This makes it very difficult to find the necessary source of entropy to generate random numbers.
• Execution cost: All operations in state-changing transactions have an associated cost. This helps to keep the blockchain protected from spam and denial of service attacks. However, it also means that gamers have to pay for these interactions. This can quickly add up and become impractical.

In order for CryptoFights to be implemented on the blockchain in a practical way, the developers have adopted the following guidelines:

• Work asynchronously whenever possible. This means not waiting for transaction results, unless unavoidable. Gamers should not be idle waiting for things to happen. In reality, there are often things that can be done to ease the waiting process, like showing battle instructions or animations during opportune moments.
• Reduce the number of transactions per battle or game move to a minimum.
• Finally, and closely related to the previous point, the developers try to be creative with off-chain solutions. This means, only implementing those parts of the game on-chain that really benefit from the blockchain’s properties.

The above does not mean CryptoFights forgoes decentralization. On the contrary, key blockchain primitives are used, borrowed from basic algorithms, to implement fair and verifiable off-chain solutions, using the underlying smart contracts as settlement layers.

As previously published, CryptoFights consists in 3D heroes battling in an arena, modeled on traditional role-playing games. Whilst, there is an important strategic aspect to playing the game, players also roll a dice to provide a degree of randomness for the battles. Whilst, the developers have devised a clever way of generating randomness on-chain reliably, they have also designed ways to execute battles off-chain fairly and verifiably.

To illustrate this, let’s discuss two examples of how battles can be implemented off-chain.

The first solution is based on the same concept that is used in proof of stake consensus algorithms in some blockchains, namely, allowing participants to stake some of their wealth to correctly execute the battle algorithm off-chain. The result can be verified by anyone and if found fraudulent, the validator loses the staked amount. If validation is performed correctly, the validator is incentivized with a reward.

This works as follows: CryptoFights allows gamers to fight for a bounty in the arena. The bounty, paid in Ether, is paid to the winner of the battle. Therefore, in those battles in which gamers have decided to fight for a bounty, we can incentivize a third party that wishes to act as a validator with a percentage of this bounty for executing the battle contract.

The battle algorithm is implemented in a pure function, which on Ethereum means the function can be called in a gas-free local node call. The input to the battle algorithm is a random number seed, used for deciding the outcome of dice rolling. The future block method is used to provide the required seed, which is the only secure transaction-free on-chain solution for random number generation.

An outside validator executes the algorithm using the following steps:

1. The battle is requested by issuing a challenge and placing a wager.
2. The opponent accepts the challenge.
3. The smart contract raises an event to notify potential validators of the upcoming battle.
4. The first participant requesting to act as a validator is accepted to perform this role.
5. The validator stakes a pre-defined percentage of the battle bounty in Ether
6. The validator executes the transaction-free battle contract using the current on-chain calculated random number seed as an input.
7. The validator submits the result to the blockchain.
8. An event is issued to indicate the battle validation.
9. Any participant can verify that the correct outcome has been submitted and force settlement in the case of detecting a fraudulent validation.
10. The smart contract settles the battle outcome after a timeout.
11. The winner of the battle receives the wager minus the validator percentage.
12. The validator percentage is either paid to the validator or to the detector of the fraudulent validation. A fraud detector also receives the Ether staked by the validator.

Validator Staking

The above process greatly reduces the gas cost for battle execution and improves the interactive user experience for the players.

Another option for executing turns in battles off-chain is to use an adapted state channel approach and use the blockchain for settlement and conflict resolution. This can be achieved by the following procedure:

1. Each user chooses a 256-bit random number in a challenge / accept pattern that we have previously described.
2. Each random number is hashed as many times as there are possible turns in the game, resulting in a separate seed for each turn.
3. A turn consists in validating the opponent’s previous turn, increment the turn counter, provide the next random number seed and call a read-only blockchain function without causing a transaction to be executed. This state transition provides the game logic that allows players to update their game state.
4. At the end of every turn, the player signs an off-chain message with their private key. This can be achieved efficiently and in a user-friendly way using Metamask’s off-chain messaging.
5. At the end of the battle, or whenever a player wished to do though, the battle can be committed in an on-chain checkpoint.
6. Players can also force conflict resolution by calling a dispute function, which causes on-chain battle verification.

Using the above algorithms most battles can be resolved in only three transactions.

Validation staking and proof of turn are just two examples of how game logic can be executed off-chain, whilst conserving the key transparency properties of the blockchain.

It is essential for crypto-game developers to be creative with off-chain solutions, in order to make blockchain gaming viable with current technology.

Beta operation of some CryptoFigths functionalities has already started. Sign up at cryptofights.io. See you in the arena!

Originally published at hackernoon.com on June 22, 2018.