Gaming continues to be cited as one of the top potential use cases for Zero Knowledge Proofs (ZKPs), and O(1) Labs’ SDK is a strong basis for building and running ZK elements within games. However, a focused discussion of ZKPs and games can be challenging. The space is:
- Diffuse — very different categories of games exist.
- Noisy — there’s a hangover from unfulfilled early hype around Web3 gaming and many Web2 gamers have been vocally opposed to NFTs.
- Nascent — it’s also still very early. The core engines of many games require technology that is at the leading edge of performance for consumer technology in terms of speed and capacity, whereas all blockchain technology today is leagues away from that.
There are of course some non-ZK Web3 capabilities that are already being used in games, such as NFT issuance and interactions, wallets, trading, and reward tokens, but the purpose of this article is to focus on ZK-related use cases. There are two broad categories of ZK use cases under gaming:
True ZK game dApps:
- The game is based on an approach involving ‘incomplete information’ (e.g., a card game where each player knows their own hand, but not those of other players, nor the make-up of the undealt deck). This is achieved by having private elements of the game running off chain, within the local environment of each relevant participant and proofs passed between participants.
- The game is ‘provably fair’. This is achieved by having each private element of the game run within a ZK smart contract, and proven to have operated according to the rules.
- The game can be played with multiple turns, or even multiple games, conducted free from on-chain transaction costs (by passing ZKPs between participants off-chain and then settling to the chain with a single final proof).
ZK Augmentative capabilities for games (Web2 or Web3):
- Anti-bot / anti-spam measures, to increase the enjoyment of a game by limiting it to humans, or to reduce claiming of benefits, such as give-aways, by bots. This can be achieved using ZKPs by requiring a participant to prove activity that they have undertaken in their private, local environment that is highly unlikely to have been conducted by a bot, but without exposing that activity externally.
- Non-doxxed credentials, to allow a more personalized relationship between the game and the player, without unduly exposing the player’s information. For example, a new player could be accelerated to a higher level within a multi-level game, or could be pitted against similarly-experienced players, if they could prove that they were experienced with other games. It could also be used for more tailored matchmaking within a game based on a range of external factors, such as matching up players who are high profile as measured by having thousands of Twitter followers. ZKPs could allow that to happen without the player disclosing the exact addresses and details of wallets and accounts they had used in other platforms.
- Non-doxxed compliance-oriented activity, to reduce risk for a game provider engaging in activity with a user that could be interpreted in some jurisdictions as subject to regulation. For example, facilitating trading of in-game NFTs, or handling payments for in-game purchases and sales, while allowing the user to retain some privacy. As a first step, the proof might simply be that the user has a non-US residency and citizenship.
- Private voting, to allow users either to vote as part of the game, or for governance of the project / DAO that publishes and maintains a game.
Some of these augmentative capabilities, in particular those related to identity, may well become early break-out successes when applied to games. However, they are quite likely to emerge as stand-alone utilities that serve multiple use cases, gaming and non-gaming (albeit that they may have game-specific twists). In that vein, we have discussed some of them in other posts, and so we will not discuss them further here.
The potential for using “true” zero-knowledge (ZK) technology in decentralized application (dApp) games varies. Some types of games, like Poker with a limited number of players, can already be well served by ZK technology. However, more advanced games that have more complex rules and require high-performance graphics, like eSports, can only use ZK technology in a limited way. 0xPARC’s community has made progress in this area with their work on Autonomous Worlds, where partial information is used to hide the location of players or the game environment in certain scenarios, and for procedurally-fair generation of worlds.
Additionally, the utility of ZKPs in games varies greatly. The utility of privacy and provable fairness in Poker is high. Provable fairness in, for example, a decentralized equivalent of Mario Kart as currently used is more arguable, versus delivering the privacy required for the game via a centralized server, but there have been cases where players have alleged unfairness in centralized games, e.g., claiming that company employees had unfair access to high value in-game items. Indeed, many games that are experimenting with in-game NFT usage have Web2 arrangements in place to buy or win the assets, meaning that they are not trustless. Furthermore, parts of the industry are predicting that eSports and other graphics-heavy games could in the future become venues for high stakes activities that include digital assets, for betting, valuable rewards, or self-sovereign reputation that will increase the utility of full trustlessness.
Is trustless provable fairness in Poker, for example, important enough to justify a zkApp, and is there a viable self-sustaining operating model around it? Online poker is already available and widely played using centralized Web2 apps. Some Web3 apps have built a degree of decentralization into their assets. However, they all rely to a significant extent on centralized operation and therefore trust in the operator to ensure fairness and availability. With a ZKP-based off-chain smart contract, two or more players could download code, and play a game peer-to-peer with the same degree of trustlessness, without any interaction with a central entity other than to access the code for initial download. This would bring operational efficiency and potentially different regulatory treatment (as is the case for P2P defi). It could also make the game more accessible than a centralized game. Finally, it might allow composability given the standardization that Web3 enforces.
There are various ways to create a self-sustaining operating model for a game. One option is to design and run the game as a public good, with or without its own token. Another possibility is to take a small percentage of the stakes in each game to finance the game’s continued development. Additionally, a governance system, using voting tokens, could be implemented to manage the funds. These tokens could be distributed randomly, based on game usage, or through a combination of both methods to determine how the funds should be used.
Why is O(1) Labs’ SnarkyJS SDK a good basis for building a ZK game like Poker?
- An overriding benefit is recursion of the succession of proofs generated in a game. SnarkyJS was the first ZKP SDK to allow unlimited recursion using its Pickles code. O(1) Labs has published several tutorials illustrating how recursion could be used e.g., in Poker and in Mastermind.
- The ability to create a game without requiring a trusted set up ceremony, which is a major overhead in many proof systems. SnarkyJS’ plonk-based Kimchi system can deploy a new ZK circuit immediately.
- The ability to run a ZK Smart contract and create proofs rapidly in a browser, thanks to SnarkyJS’ use of WASM.
- The ability for non-cryptographer developers to author ZKP-based games using SnarkyJS thanks to it being written with Typescript libraries, which not only gives them a familiar development experience when writing ZK smart contracts, but also allows them to use natively some important Typescript tooling such as the entirety of the JavaScript and NodeJS ecosystem.
- The fact that proofs from SnarkyJS smart contracts can be verified on the Mina blockchain. SnarkyJS and the Mina blockchain were built for optimal cost and performance for ZK smart contracts. This is key given the relatively early state of the technology (we have heard of proofs built using other technology taking hours to be generated and thousands of dollars per proof in gas and transaction fees to be verified).
Our technology and thinking can bring value to gaming in various ways, not just through the use of ZK elements. For example, our cryptography team has developed a new approach to randomness, using a polynomial-based shuffling mechanism, for provably random card shuffling and other setup routines, and we are available to discuss this with projects interested in game development.
The Mina Protocol is in the final stages of the next release to allow easy programmability of zkApps on the Mina mainnet blockchain, with testnet already well underway. The Nil Foundation is finalizing the Mina bridge to Ethereum, co-sponsored by the Ethereum Foundation and Mina Foundations. We are moving into prime time for ZKPs!
O(1) Labs will continue to explore with market participants the potential for ZKPs in gaming. We are keen to talk to anyone in the market interested in this topic — please reach out to us at partners@o1labs.org.