Unblocking On-Chain Games Pt. 5: Bat-Channels
This is Part Five of a series exploring constraints at the intersection of blockchains and games. The objects of inquiry are “autonomous worlds”, “crypto-native” or “on-chain” games, which trustlessly maintain their game state.
About me: I’m a core contributor to Alliance DAO, a startup accelerator and founder community. I hold a PhD in Game Design.
Summary
In this post, I propose a game design pattern that scales web3 games by processing game loops off-chain in a permissionless and trustless way. This requires representing game logic in a zk-circuit anchored to a blockchain. I’m calling this design pattern a “bat-channel*”. With bat channels, we enable a sustainable, large player-base by magnifying the number of concurrent state changes. The primary trade-off is the segregation of competing players. Massively multiplayer games where thousands of people touch the game state at any time would be impossible. Instead, the theoretical limit is closer to 30, with simplification for single-player and co-op games. In order to justify the trade-off, I propose a compelling game design that leverages the scalability of bat-channels, while also enjoying the benefits of running on a blockchain. Following posts will include more technical explorations of the design.
Introduction
In 2021, Galcon was ported to the blockchain under the name Dark Forest. Over the course of a year, hundreds of players competed on a handful of maps that persisted for about a week. Players built front-ends, scripts, and smart contracts on top of the game because of the affordances of open-source blockchain game design. Many of the greatest Solidity researchers and engineers tested themselves and explored this new form of play. They built community marketplaces, where players began trading resources and even information in order to progress towards their in-game goals. Similar games popped up around the same time, such as Conquest.eth and Mithraeum.io. In each, all players competed on the same map at the same time.
Unfortunately, these games were hampered by the throughput of the blockchains they were built upon. For instance, Dark Forest ran on Gnosis Chain, which allowed 30 game-state-altering transactions per second. Since expert players automated tasks, a single account could approach 30 moves on their own!
In an earlier post, I discussed ways to scale game design without improving or altering the cryptography they use. But even in a game that uses a quarter of a block, where players move once, very carefully, every three minutes, there is still a maximum of 1440 concurrent players (180 seconds/moves * 8 moves*players/second). Builders must either believe the total lifetime value of these kinds of players is 100 times more than Web2 users, or this is an unacceptable number, given that successful games today boast over 100,000 concurrent players. While we may see 10x scaling in the coming years, we are going to need 1000x scaling to support a handful of successful games.
Scaling with Bat-Channels
The naive scaling solution could be to create more side-chains like Gnosis or Polygon PoS. But side-chains do not inherit the security of the chain they run on. Instead, they generally rely on their own set of validators, which stake assets to guarantee good behavior in exchange for proportionate block rewards. They are called side-chains because they often re-use the same virtual machine, maintain a bridge, and post snapshots of their state to the primary chain (for some kind of socially coordinated emergency recovery). With 1000 of these, we could accommodate a sufficient number of players. The problem becomes player fragmentation, liquidity fragmentation, securing bridges and the undermining of security.
To more closely match the security assumptions of major blockchains, many developers have opted to use Optimistic and zkRollups. These offer similar scalability to side-chains, but they must each post transactions to their L1. However, there is not enough block space on Ethereum to accommodate 1000 additional gaming rollups and the rest of the ecosystem.
A third construction for scaling are state channels. Lightning Network is a popular implementation on Bitcoin, used as payment rails between two parties. Each party locks funds into a smart contract and then writes messages off-chain that update the state of their balances.
For instance, Alice and Bob each lock 0.1 BTC. Alice sends Bob a message every minute, signing away 0.00001 BTC. Every once in a while, Bob pays Alice for something and returns some BTC. After a year, the final balance is Alice’s balance is 0.05 and Bob’s is 0.15. Alice exits the channel and posts the latest state on chain. Bob has a window to contest with a more recent update, after which the smart contract releases the funds to Alice and Bob.
State channels, like Lightning, allow for orders of magnitude more transactions because none of the interim states need to be on chain. For two players in a game, a state channel might be appropriate. WHY? The trade-offs would be a massive reduction in the total number of players who can interact with each other at the same time. Instead of 1000 people on the same map, you would only have two (maybe a couple dozen if you use some sci-fi crypto). You’d also need players to be able to contest both cheating and non-responsiveness. In a later post I hope to address these issues; however, for the sake of brevity, this article focuses on a cooperative construction. In the case of co-op, all players are aligned and the game is positive-sum. The threat model is not that the players cheat each other, but that they cheat the game.
Proof of Game
To prevent fraudulent play, the game itself must be programmed in a provable way. Current solutions may include using Cairo and the Cairo VM or Solidity and the various zkEVMs. It is possible to build what looks like a zkRollup without a third-party sequencer. Since players are not worried about the ordering of their moves being compromised maliciously (because they are friends and no one else is inside the rollup), they can agree on the order themselves. It is scalable because there can be an arbitrarily large number of moves while only needing to commit a single proof and state differences** to the chain.
Game Design
Using the bat-channel architecture (a shared blockchain state and parallelized gameplay sessions), let’s consider what games are most appropriate to port. I have chosen the legendary massively multiplayer online role-playing game, World of Warcraft, as an exemplary choice. While most people think of WoW as an antagonistic shared-state game, I argue that it is largely a small-group co-op experience. And from the game theoretical/security assumption perspective, it is therefore a single-player game. While millions of concurrent players have enjoyed WoW, they are broken up over hundreds of servers. And these servers are broken up over dozens of zones, which are broken up into hundreds of dungeons called instances. This is how millions of players can fight the same monsters in parallel. Two different teams can walk into the same cave and never see each other. The larger meta-world, including the auction house, is used for trading, repairing gear and managing character development.
For a web3 game, I propose a similar construction be the first target of design. That is, the main chain is a place to do commerce, character stats and reputation, and core gameplay loop exists outside it. Players spin up their own instances, bringing in their characters and gear, only to provably exit those instances with more gear and exp. While this removes composability, as gameplay details are missing, we instead get player privacy. No one gets to know how beat the dungeon. And, if you want to bring back composability, you could, for instance, offer a special NFT to players who kill a hundred rats in the dungeon. Players can go through their backlog of moves and create a proof that this is something they accomplished. Data availability can be pushed onto the players because there is no risk for them.
Next Steps
The project that is closest to building bat-channels is Dojo. This game engine is built for the Cairo VM and proves that games have been played correctly. As of yet, the system has not been used to create a game system where an economy lives on one layer, while the game loops live in separate bat-channels. The team says live demos should be coming soon.
If you are a founder looking to start a bat-channel related project, my DMs are open. I’d gladly introduce you to the long list of people excited to meet you. And please, don’t forget to apply to Alliance.xyz, we’re very excited about trustless Web3 games.
Special Thanks
Yonada — Lattice, Ramon Canales and Rich Kim — Matter Labs, Tarrence Van As and Sylve Chevet — Dojo, Mohamed Fouda — Alliance, ycryptx, guiltygyoza — Topology, Feltroid Prime — Herodotus, Baz — Aperture Labs, Henry Caron.
End Notes
- *The name was inspired by both Yonada’s Battle Rollups and the way in which the Lightning Network scales Bitcoin through state channels.
- **At the time of this writing, it appears that Polygon’s zkEVM is unsuited to this approach as it compresses all transactions and posts these to chain, rather than only posting state differences. That said, this tradeoff offers additional composability, which may be suited to games with fewer moves that still need somescaling.
