Diving into Bat-Channels: New Technology Unlocking Scalability for On-Chain Games
TechFlow Selected TechFlow Selected
Diving into Bat-Channels: New Technology Unlocking Scalability for On-Chain Games
For a Web3 game, the main chain is where commercial transactions, character stats, and reputation are managed, while the core gameplay loop exists off-chain.
Navigating Web3 tides with focused insightsAuthor: Will Robinson
Compiled by: TechFlow
In this article, I propose a game design pattern to scale Web3 games by moving the processing of game loops off-chain in a permissionless and trustless manner. This requires anchoring game logic into zk circuits on the blockchain. I call this design pattern "Bat-Channel".
With Bat-Channels, we can support sustainable large player populations by amplifying the number of concurrent state changes. The main trade-off is the isolation of competitive players. Massively multiplayer games where thousands interact with the game state simultaneously will be impossible. Instead, theoretical limits are closer to 30 players, with simplifications for single-player and cooperative gameplay. To justify this trade-off, I present an engaging game design that leverages the scalability of Bat-Channels while enjoying the benefits of running on-chain. Future articles will include deeper technical explorations of this design.
In 2021, Galcon was ported onto the blockchain and released as Dark Forest. For about a year, hundreds of players competed across several maps lasting approximately one week each. Thanks to the openness of blockchain game design, players built frontends, scripts, and smart contracts atop the game. Many of the top Solidity researchers and engineers challenged themselves by testing and exploring this new form of gaming. They established community markets where players began trading resources—and even information—to achieve in-game objectives. Similar games emerged around the same time, such as Conquest.eth and Mithraeum.io. In these games, all players competed on the same map at the same time.
Unfortunately, these games were limited by the throughput of the blockchains they were built on. For example, Dark Forest ran on Gnosis Chain, which only allows 30 transactions per second that alter the game state.
But even in a game consuming just a quarter of a block, where players carefully move once every three minutes, there could still be at most 1,440 concurrent players (180 seconds/action * 8 actions * players per second). Developers must either believe that the lifetime value of such players is 100x that of Web2 users, or accept that this number is unacceptable—especially since successful Web2 games today have over 100,000 concurrent players. While we may see 10x scaling in the coming years, we need 1,000x scaling to support some successful games.
Scaling with Bat-Channels
The simplest scaling solution might be creating more sidechains like Gnosis or Polygon PoS.
However, sidechains do not inherit the security of the chains they operate on. Instead, they typically rely on their own set of validators who stake assets to ensure honest behavior and receive block rewards in return. They are called sidechains because they usually reuse the same virtual machine, maintain a cross-chain bridge, and publish state snapshots to the main chain (for emergency recovery via social coordination). With 1,000 such sidechains, we could accommodate enough players. But the problem becomes player fragmentation, liquidity fragmentation, bridge security risks, and compromised overall security.
To better align with the security assumptions of major blockchains, many developers opt for Optimistic and zkRollups. These offer similar scalability to sidechains but must publish every transaction to their L1. However, Ethereum’s block space is insufficient to accommodate 1,000 additional game-focused rollups alongside other ecosystem demands.
A third scaling approach is state channels. The Lightning Network is a popular implementation on Bitcoin, serving as a payment channel between two parties. Each participant locks funds into a smart contract, then exchanges messages off-chain to update their balance state.
For example, Alice and Bob each lock 0.1 BTC. Alice sends Bob a message every minute, signing over 0.00001 BTC. Occasionally, Bob pays Alice back some BTC. After a year, Alice's final balance is 0.05 BTC and Bob's is 0.15 BTC. Alice exits the channel and publishes the latest state on-chain. Bob has a time window to dispute with a more recent update; otherwise, the smart contract releases the funds to both.
State channels (like Lightning) allow orders of magnitude more transactions since intermediate states don’t need to be recorded on-chain. For two-player games, state channels may be suitable. Why? The trade-off is a significant reduction in the total number of players who can interact simultaneously. You also need mechanisms for players to dispute cheating or unresponsiveness. I hope to address those issues in future articles; however, for brevity, this article focuses on a cooperative setup. In cooperative mode, all players act consistently, and the game is positive-sum.
Proof of Game
To prevent fraudulent gameplay, the game itself must be programmable in a provable way. Current solutions may involve Cairo and Cairo VM, or Solidity with various zkEVMs. A structure resembling a zkRollup can be built without a third-party sequencer. Since players aren't concerned about malicious ordering of their actions (because they're friends and no outsiders are inside the rollup), they can negotiate the order among themselves. This approach is scalable because it supports an arbitrary number of actions while only requiring a single proof and state difference to be submitted on-chain.
Game Design
Using the bat-channel architecture (shared blockchain state and parallelized game sessions), let's consider which games are best suited for adaptation. I chose the massively multiplayer online role-playing game World of Warcraft as a canonical example. While most people view World of Warcraft as a competitive shared-state game, I argue it is primarily a small-team cooperative experience. From a game theory/security assumption perspective, it functions as a single-player game. Although millions of concurrent players enjoy World of Warcraft, they are distributed across hundreds of servers. These servers are further divided into dozens of regions, which are segmented into hundreds of dungeons known as instances. This is why millions of players can fight the same monster simultaneously. Two different teams can enter the same cave yet never encounter each other. The larger metaverse—including auction houses—is used for trading, repairing gear, and managing character progression.
For a Web3 game, I suggest adopting a similar structure as the primary design goal. That is, the mainchain is where commerce, character stats, and reputation reside, while the core game loop exists off-chain.
Players can launch their own instances, bring in their characters and equipment, and then exit these instances in a provable way, earning more gear and experience. While this reduces composability due to missing game details, it grants player privacy. No one will know how to beat a dungeon. And if you want to restore composability, you could issue a special NFT to players who kill 100 rats in a dungeon. Players can review their action logs and generate a proof showing they completed the task. Data availability can be driven by players themselves since they face no risk.
Next Steps
The project closest to implementing bat-channels is Dojo. This game engine is built for Cairo VM and proves that the game has progressed correctly. Currently, the system hasn't been used to create a game ecosystem where the economy lives on layer 1 while the game loop operates in separate bat-channels. The team has announced a live demo is forthcoming.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Alliance
