撰写：Will Robinson

编译：深潮 TechFlow

在这篇文章中，我提出了一种游戏设计模式，通过在无需许可且无需信任的方式下，将游戏循环的处理迁移到链外，从而扩展 Web3 游戏的规模。这需要将游戏逻辑锚定在区块链上的 zk 电路。我将这种设计模式称为“Bat-Channel”。

通过 Bat-Channel，我们可以通过放大并发状态变化的数量，实现可持续的大型玩家群体游玩。主要的权衡是竞争玩家的隔离。在任何时候都有数千人触及游戏状态的大规模多人游戏将是不可能的。相反，理论上的限制更接近于 30 人，并且对单人和合作游戏进行了简化。为了证明这种权衡的合理性，我提出了一个引人入胜的游戏设计，利用 Bat-Channel 的可扩展性，同时享受在区块链上运行的好处。接下来的文章将包括对该设计的更多技术探索。

在 2021 年，Galcon 在区块链上被移植，并以 Dark Forest 的名字发布。在一年的时间里，数百名玩家在几个持续约一周的地图上进行竞争。由于开源区块链游戏设计的便利性，玩家们在游戏之上构建了前端、脚本和智能合约。许多最优秀的 Solidity 研究人员和工程师通过测试和探索这种新形式的游戏来挑战自己。他们建立了社区市场，玩家们开始交易资源，甚至信息，以实现游戏内的目标。类似的游戏也在同一时间出现，比如 Conquest.eth 和 Mithraeum.io。在这些游戏中，所有玩家都在同一时间在同一地图上竞争。

不幸的是，这些游戏受到了它们所构建的区块链吞吐量的限制。例如，Dark Forest 运行在 Gnosis Chain 上，每秒只允许 30 个改变游戏状态的交易。

但即使在一个使用了四分之一个区块的游戏中，玩家每三分钟小心翼翼地移动一次，仍然最多只能有 1440 个同时在线玩家（180 秒/行动 * 8 行动 * 每秒玩家）。开发者们必须要么相信这类玩家的总生命周期价值是 Web2 用户的 100 倍，要么认为这个数字是不可接受的，因为如今成功的 Web2 游戏拥有超过 10 万个同时在线玩家。虽然我们可能会在未来几年看到 10 倍的扩展，但我们需要 1000 倍的扩展来支持一些成功的游戏。

使用 Bat-Channels 进行扩展

最简单的扩展解决方案可能是创建更多像 Gnosis 或 Polygon PoS 这样的侧链。

但是侧链并没有继承它们所运行的链的安全性。相反，它们通常依赖于自己的验证者集合，这些验证者抵押资产以保证良好行为，并获得相应的区块奖励。它们被称为侧链，因为它们通常重用相同的虚拟机，维护一个跨链桥，并将它们的状态快照发布到主链上（用于某种社会协调的紧急恢复）。如果有 1000 个这样的侧链，我们可以容纳足够多的玩家。问题变成了玩家的碎片化、流动性的碎片化、跨链桥的安全性和安全性的破坏。

为了更好地匹配主要区块链的安全假设，许多开发者选择使用 Optimistic 和 zkRollups。它们提供了与侧链类似的可扩展性，但它们必须将每个交易发布到它们的 L1。然而，以太坊上的区块空间不足以容纳 1000 个额外的游戏 Rollup 和其他生态系统。

第三种扩展构建是状态通道。闪电网络是比特币上的一种流行实现，用作两方之间的支付通道。每个参与方将资金锁定在智能合约中，然后在链下编写更新其余额状态的消息。

例如，Alice 和 Bob 各自锁定了 0.1 BTC。Alice 每分钟给 Bob 发送一条消息，签署掉 0.00001 BTC。偶尔，Bob 会向 Alice 支付一些 BTC 并返还一些 BTC。一年后，Alice 的最终余额为 0.05，Bob 的余额为 0.15。Alice 退出通道并将最新状态发布到链上。Bob 有一个时间窗口来提出更近期的更新，之后智能合约将资金释放给 Alice 和 Bob。

状态通道（如闪电网络）允许进行数量级更多的交易，因为中间状态不需要在链上。对于两个玩家的游戏，状态通道可能是合适的选择。为什么呢？这样做的权衡是可以同时互动的玩家总数大大减少。你还需要让玩家能够对作弊和不响应进行争议。在以后的文章中，我希望解决这些问题；然而，为了简洁起见，本文重点介绍了一种合作构建。在合作模式下，所有玩家都是一致的，游戏是正和的。

游戏证明（Proof of Game）

为了防止欺诈性玩法，游戏本身必须以可证明的方式进行编程。目前的解决方案可能包括使用 Cairo 和 Cairo VM 或 Solidity 和各种 zkEVM。可以构建一个看起来像 zkRollup 的结构，而无需第三方序列器。由于玩家不担心他们的行动顺序被恶意破坏（因为他们是朋友，没有其他人在 Rollup 内部），他们可以自行协商顺序。这种方法是可扩展的，因为可以有任意数量的行动，而只需要提交单个证明和状态差异到链上。

游戏设计

使用 bat-channel 架构（共享的区块链状态和并行化的游戏会话），让我们考虑哪些游戏最适合移植。我选择了大型多人在线角色扮演游戏《魔兽世界》作为一个典型的选择。虽然大多数人认为《魔兽世界》是一款对抗性的共享状态游戏，但我认为它主要是一个小团队合作的体验。从博弈论/安全性假设的角度来看，它是一个单人游戏。虽然数百万同时在线的玩家都喜欢《魔兽世界》，但他们分散在数百个服务器上。而这些服务器又分散在数十个区域，这些区域又分散成数百个称为副本的地下城。这就是为什么数百万玩家可以同时与同一只怪物战斗。两个不同的团队可以走进同一个洞穴，却永远不会见到彼此。更大的元世界，包括拍卖行，用于交易、修理装备和管理角色发展。

对于一个 Web3 游戏，我建议采用类似的构建方式作为设计的首要目标。也就是说，主链是进行商业交易、角色统计和声誉的地方，核心游戏循环存在于主链之外。

玩家可以启动自己的实例，带入他们的角色和装备，然后通过可证明的方式退出这些实例，获得更多的装备和经验。虽然这样做会减少可组合性，因为游戏细节缺失，但我们可以获得玩家的隐私。没有人会知道如何打败地下城。而且，如果你想恢复可组合性，你可以为在地下城杀死一百只老鼠的玩家提供一个特殊的 NFT。玩家可以回顾他们的行动记录，并创建一个证明表明他们完成了这个任务。数据的可用性可以由玩家来推动，因为他们没有风险。

下一步

最接近构建 bat-channels 的项目是 Dojo。这个游戏引擎是为 Cairo VM 构建的，并证明了游戏已经正确地进行。目前，该系统尚未被用于创建一个经济体存在于一层的游戏系统，而游戏循环存在于单独的 bat-channels 中。该团队表示即将推出实时演示。