Blockchain gaming is having a moment. With record-breaking fundraising, a new business model called Play-to-Earn, promises of better interoperability, more control for players in the upcoming metaverse; it's met with both excitement and skepticism.

I want to pitch in and list down some issues that I believe are still not solved and offer perspectives on how to solve them.

I refer to blockchain games as games that have some of their core mechanics handled by the blockchain. It's a spectrum ranging from weakly on-chain games like Sorare, that only require you to buy an NFT to play the off-chain game, to strongly on-chain games like Cometh that actually require the player to interact with the blockchain to play the game. I highly recommend watching this EthCC talk by @wighawag on how he built a game entirely on-chain.

I'm not considering block time and overall blockchain speed as a problem as it's a general issue for most blockchain projects. I'm interested in problems that will remain even after blockchains have sped up.

Problem #1 Multi-accounting

Overview

Most games implicitly rely on the following rule one player == one human. If not, this means that someone else could be playing in your place, and we usually don't want that.

This rule is easy to verify in meatspace, you can check with your own two eyes or ask for an ID. It's more difficult on the Internet.

It's currently mitigated, not fixed, by a mixture of pseudo-KYC, SSO and ban threats. You can lend your World of Warcraft account to someone and change the username and password to regain control of this account later (provided you still have access to the email address controlling this account). This is a technique used to "boost" accounts: have another player use your account to advance your ranking or get gold coins for you.

The consequences of multi-accounting can range from getting destroyed by a pro player having fun reaping kills in the minor leagues to higher in-game inflation.

Let's say we use a blockchain address as a unique identifier for a player. It has several advantages. In blockchain you can't just lend your address because it would mean lending the private key controlling this address. If I lend you my private key I can't be sure that you're not going to forget it afterwards and that you're not going to steal my funds. Blockchain accounts are theoretically "stickier" than web2 accounts.

But that's only if you've ascertained the identity of the person behind the account. If you can't rely on a solution to ascertain someone's identity you might have the same player running several of your game's accounts. Furthermore, creating a blockchain address is free on most blockchain, so there's nothing deterring bad actors from creating new accounts every time they're banned from a game.

Solutions

NFT-based access

• How do you deter people from creating fake accounts? Make it costly and price smurfs out. In Axie Infinity, buying the three required Axies currently costs around $600 which is enough to deter most multi-accounting.
• Arguably, Axie's scholarship system could be considered as a form of multi-accounting to beat the NFT-based access. Rather than playing on 25 mobile phones you could buy up the required Axies and have someone else play for you. The one player == one human rule isn't breached gameplay-wise but the reward fairness is. Players with more capital can buy up more Axies, delegate to more scholars, and therefore get more money.

Proof of humanity

• Rely on the player holding a proof of humanity on-chain to allow them to play the game. This can come in many forms, like passing the proof of humanity KYC, pledging your eternal soul to the Orb, etc.
• Rather than asking for a specific KYC you could also require the player to have performed certain actions on-chain and and consider it proof enough. The one player == one human rule could become one player == one address with a lot of actions rule. For example: the person must have voted on an Aave proposal, have an ENS domain, made more than 10 transactions, etc.

Reputation system

• The above solutions are based on a "ask for permission" type of check, the player has to prove that they're human before playing. Another way of doing it is to "ask for forgiveness". This solution rests on giving tools to the community to weed out bad actors. Players are regarded as humans from the get-go but this status can be challenged.
• Players could raise doubts on a given player's identity and requiring them to formulate a proof that will be verified through a judiciary process, maybe on a Kleros court, similar to Steam Overwatch.
• This article explores the idea of proof-of-playtime as a suitable measure for humanity in governance systems. In order to get to the higher leagues you will require your players to spend hours in-game, therefore continuously generating a proof of humanity through a proof-of-playtime.

Problem #2 Key management

Overview

"With great power comes great responsibility". Blockchain technology puts responsibility in the hand of the user's via its private keys. Users are the only one that can use these keys meaning game developers can't natively perform actions on-chain for the user.

For a weakly on-chain game like Sorare it's not much of an issue gameplay-wise. The player has to buy some cards, they can do it through Ramp, they might not even know they're using the blockchain at all. All of the game is managed off-chain.

For strongly on-chain games like Cometh it's more of an issue. The more actions players can perform, the more they will have to sign transactions, the more the Metamask Fox will pop up and annoy you.

As blockchains speed up, game developers will experiment with more interactive games rather than only turn-based games and asynchronous games. Allowing players to perform more actions on-chain means they will have to sign more transactions. As a former colleague would say "that's just too much click click".

Solutions

Local and temporary keys

• Mirror implements a clever system to save users from signing too often. A keypair is generated and stored on the client side and is only authorized to perform non-sensitive actions.
• In the same fashion a player could start a game session by generating a keypair stored locally and broadcast one transaction to the game smart contract with their main key to authorize the temporary key to validate game actions for a set time period. At the end of the session, the temporary key would be invalidated. The user's computer automatically signs transactions with the temporary key and the user's main key is kept safe. It's like a local temporary hot wallet.

Smart wallets and multisignature

• Rather than requiring the player to sign every single transaction they could use a smart wallet like Argent over which they have total control and give the right to other addresses to perform actions on their behalf.
  • For example, the Cometh renting contract works by spawning a multisignature wallet. A spaceship owner will delegate his asset through the multisig wallet to another player that can only use certain functions on the Cometh contract. This ensures that the player can only use the NFT spaceship for game-purposes and can't steal it from the owner.
• Smart contracts would benefit from having a "user settings" on-chain that would allow a user to permit someone else to use a contract on their behalf. As an Aave user I would be able to define that my friend's address is allowed to claim but not withdraw funds on my behalf (kudos to @btchip for the idea).

Problem #3: Hiding information on-chain

Overview

Let's build a game of rock paper scissors on-chain. One naive way to implement this would be to have a single play function that can be passed rock, paper or scissors. I play the game by feeding the play function my choice, and the contract will compare the moves from the two competitors.

The problem is that nothing stops my opponent from looking at the blockchain to check my move while it's being mined. If I've chosen rock they will surely play paper.

The problem gets even worse for imperfect information games like Battleship (AKA fog-of-war games). If the blockchain stores the state of our Battleship game my opponent can easily ask the smart contract where my ships are on the grid and beat me.

Hiding information on-chain is difficult since blockchain, by essence, is an open and decentralized database. Games that require hiding some informations from other players have a harder time being played on-chain because of this.

Solutions

Commit-reveal schemes

• For rock, paper scissors the contract could require both players to "lock" their choice by hashing their choice along with a number of their choosing. When both players have committed their choice they are asked to reveal their choice along with the number they had chosen, and the contract can verify that they have revealed what was committed. This article explains how to build a rock paper scissors game with this system.

Zero-knowledge proofs

• ZKPs are used to prove to someone that a given statement is true, without conveying any information apart from the fact that the statement is indeed true. For example, I can prove to someone I've solved a 9x9 Sudoku by having them sum up each individual line and row and verify the sum is always 45 (the sum of integers from 1 to 9) without revealing the Sudoku in its entirety.
• Dark Forest is a strategy game based on zero-knowledge proofs called SNARKS. Users play on their browser and send proofs of their move to the smart contract. The contract will then verify if the move they've made is legit, while users don't have to disclose what their move was.
  • There's a great podcast from the DarkForest team explaining the mechanics of the game and a blogpost detailing how the contract works.
• The funny thing with zero-knowlege games is that the state is not stored on-chain but usually on the user's side. If the player looses their "save state" the blockchain will not keep it for them. No one actually knows what is going on in Dark Forest, not even the game developer knows where all the players are unless they publicly disclose their location (which they can prove).
• ZKPs can also allow games to scale by handling most of the hard computation off-chain and publishing a proof of this computation on-chain, to be reviewed by a smart contract. I recommend checking this article by Killari on how to implement such a system for an auto battler.

Problem #4: Cheat-to-Earn

Overview

Play-to-earn means players are compensated for playing a game. Axie Infinity players are rewarded for completing quests with SLP tokens that they can trade. Sorare players compete in fantasy leagues and earn ETH.

Both games implement cheat-resistant P2E mechanics:

• Sorare's rewards are random, in true fantasy-gaming fashion. Unless you can read the future, there's no beating this. Multi-accounting could be used to beat a game like Poker that still relies on randomness.
• Some Axie rewards are time-based, meaning that the only way to cheat is to perform a Sybil attack through multi-accounting. By impersonating 25 players you earn 25 times the reward (which sounds a lot like an Axie scholarship).

Let's say we want to build a P2E economy on a skilled-based game like Fortnite. Each game won means you get airdropped some tokens. The game is quickly going to be flooded by cheaters.

History has proved catching video game cheaters is difficult: it (allegedly) happened in the early days, it's an issue in competitive speedrunning, it's an issue even now on AAA games. Cheaters generally use some piece of software to give them an unfair advantage. Aimbots, for example, read the game's memory to show the position of other players on the screen before they've appeared so the cheater knows what to expect.

Current anti-cheat software are sometimes considered invasive and are geared towards producing the minimum viable inconvenience for players:

As many of these games are free to play, game developers also have to balance the ability for cheaters to simply create a new account if they get banned. That's increasingly difficult for the popular battle royale games that are purposely designed to make it quick and easy to jump straight into a game with a new account.

Source

If someone cheats in my Fortnite game it's a bad experience for me but it will only last a few minutes, and I'll quickly get on to my next game. But if I'm expecting a financial reward from this game and someone wins using an aimbot, I've not only been inconvenienced, I've also been robbed.

Token incentives are powerful mechanisms. If cheaters have a financial incentives to bot games and cheat, they will cheat and build AI bots to beat human players.

Solutions

Mitigate botting of P2E mechanics

• Easiest way to avoid someone from cheating your P2E system your game is to make it technically difficult to have a bot play it. For example it's still difficult for AI to beat 3D platform games with items to find or anything that involves conversation.
  • Games like Conquest are based on diplomacy: players have to actually talk to each other in Discord servers to build alliances and win. Until AIs routinely pass the gamer Turing test, we'll be safe. As @ronan, the game's developer, states: "The point is not to guarantee that they are zero bot, just that they will be sub-humans".
• There could be other game mechanics that either don't give an unfair advantage to bots or are based around human-bot interaction (@guiltygyoza touches on this in his Crypto-native games article).

Decentralized anti-cheat system

• A game could reward referees to verify if a game has actually taken place and that a player has won without cheating. If there's a suspicion of foul play a decentralized tribunal running on Kleros could judge the case.
• You could even have bounty hunters putting other players to trial and getting paid for building their case. The amount of work put into videos like this should be compensated.
• The above system could be enhanced with a skin-in-the-game mechanism, by asking players to wager when playing or accusing another player of cheating. If they're caught cheating or lying they would lose the wager.

Reputation system

• In combination with the above you could incentivize players to behave properly by rewarding them for good behavior. Some higher leagues with greater payout would only be accessible to players with a clean cheating record.
• This could also be implemented on the social side of the game. If a player repeatedly insults others in-game a temporary ban could be enacted on-chain and lifted after some time. Or a "three strikes and you're out" policy before deactivating their account for good and have them start the grind from scratch to get back to the higher leagues. These incentives might be a way to nudge toxic players into behaving.

The easy way out: just do it off-chain

All the problems outlined above are specific to strongly on-chain games and can be mitigated by using off-chain tools or run more of the game off-chain.

• Multi-accounting: have players sign in with an SSO and benefit from the service's KYC. This is the method implemented by Zebedee Infuse to run their Bitcoin-backed CS
  tournaments: they require players to have an active Steam account (I guess not be VAC-banned).
• Hiding information: if you store everything off-chain there's no issue anymore. Sorare and Axie don't have problems because most of the game mechanics are off-chain.
  • Xaya team has a proof-of-concept of a battleship game implemented with game channels. The gist of it is to have players communicate between themselves during the battleship game, each player cryptographically signing their move, and storing the final result of the game on-chain.
  • @EAThomson suggested using a cryptography mechanism called Private Set Intersection to have two players share information between each other but ensuring players can't read the game's memory to gain an unfair advantage.
• Client-side security: if key custody is managed by the game developer there is no issue anymore, but it would defeat the purpose of having the player in control in the first place. With a smart wallet the game developer could be a stakeholder in the player's security setup and could be revoked at will. This would be a good way to onboard users: have the game developer custody the user's key and help them ramp up on the security side before allowing to take full control of their account if they wish to.
• P2E: for skill-based games it is still an issue but you have more tools to monitor players. The rule of thumb is: the more you have the game engine running on the user's computer, the larger the attack surface for them.

Conclusion

I don't think that having all the mechanics on-chain should be a goal in itself but rather a mean for interesting player experiences and new game use cases. If games are to handle more of their mechanics on-chain there are indeed many challenges to overcome. Sorare and Axie showed us how to build strong games with few mechanics running on-chain, I'm excited to see what we will achieve once we solve these challenges.

Credits

Thanks @wraitii, Decentralized Game Alliance, @EAThomson @wighawag @Qhuesten @guiltygyoza @PEntremont @MerschMax_ for the brainstorms and reviews of the article.