对链游的一些技术性思考
本文是对这篇文章的理解和整理：https://dialectic.ch/editorial/thoughts-on-chain-gaming
去年的 Axie，今年的 Stepn 的爆火，让越来越多游戏开发者意识到区块链的魔力，与区块链技术的结合也许会彻底改变游戏行业格局，重塑玩家与游戏之间的关系。
但区块链技术有个什么毛病呢，就是每个节点都需要验证用户交易的有效性，这涉及交易的执行和对执行结果的验证。区块链可扩展性的主要瓶颈之一是如何在不增加验证成本的情况下增加计算带宽。验证成本越高，运行区块链节点所需要的资源就越多。
目前大多数区块链网络，都是大而全的单体式设计，与交易相关的计算与验证，都要在每一个独立节点完成。单个节点计算资源的稀缺性，导致区块链使用成本的居高不下，开发者也必须在这个严格的资源限制下编写业务代码，某种程度上也限制了链上应用的发展。
随着 Optimistic Rollups (ORU) 和 Zk-Rollups (ZRU) 这些基于 Rollup 的二层技术的出现，情况开始发生改变。
通过使用 Rollup 技术，交易的计算在主链外执行，并在主链(结算链)上发布欺诈证明（使用 ORU 时）或有效性证明（使用 ZRU 时）来证明计算的完整性，从而保证主链外的计算是根据系统共识规则执行的。
相较于对交易计算本身的验证，网络节点可以更快更便宜的验证附加证明，使得区块链网络可以用相当便宜的成本来完成复杂的计算，比如复杂的游戏交互。这使得在我们以指数方式增加计算复杂度和吞吐量的同时保持验证成本线性甚至更低成为可能。
区块链的可扩展性由此得以根本性的转变。
不管是现在还是可遇见的未来，完全在一个单体区块链上运行游戏在经济上是不可行的。这就是为什么过去几年发布的大多数区块链游戏都是混合型的，这些游戏只有少数组件在链上部署运行的，而其核心游戏逻辑则在链下专有服务器上运行。我们将这类区块链游戏称为弱上链游戏（weakly on-chain games）。
Axie Infinity, Crabada, The Sandbox 都可以归为此类。
通过链下扩展，用户可以以低廉的成本使用几乎无限的计算资源。游戏的核心逻辑最终以智能合约的形式部署在链上。我们将这一系列游戏称为强上链游戏（strongly on-chain games）。
Dope Wars, Briq, Loots, The Realms, The Ninth 以及 Influence 等等，都属于这一类。
接下来，我们简要分析一下他们的优劣势。
弱上链游戏
image.png
优势
- 扩展更方便
- 更容易为公众观众所接受
- 成熟的用户体验
- 低延迟
- Bug 可以快速修复
- 更容易进行反作弊
劣势
- 自上而下的开发
- 闭源
- 需要信任游戏发行商
- 几乎没有可组合性和互操作性
- 资产所有权
- 持久性一般不佳
弱上链游戏更容易扩展，因为它们将大部分游戏组件保留在了链下。链上的游戏部分通常是以 NFT 为代表的游戏内资产和游戏内代币，这些资产可以在开放和无许可的市场上自由交易和转移。游戏活动发生在链下，经济结算完成在链上。
弱上链游戏的缺点可以追溯到中心化的根本问题，游戏发行商是中心化权威，随着时间的推移几乎不可避免的会有寻租行为的发生。游戏发行商可以单方面审查、更改规则或直接跑路。互操作性和可组合性也几乎是不可能的，因为游戏逻辑是脱链的。
从好的方面来说，弱上链游戏用户体验与传统游戏非常相似，不存在游戏过程中的延迟或卡顿问题。任何更新升级都可以快速顺利推出。由于游戏访问是中心化控制的，游戏发行商可以直接禁止违反服务条款的玩家。
强上链游戏
image.png
优势
- 开源
- 自下而上的发展
- 潜在的可组合和可互操作的
- 客户端抽象
- 信任最小化
- 免许可
- 更持久
劣势
- 用户体验
- 默认不隐藏信息
- 玩家会遇到 backrunning 和其他形式的 MEV
- 延迟
- bug 修复可能需要社区协调
- 下注
对于强链上游戏来说，开发人员可以使用任何公开的链上组件，包括但不限于：
- 物理引擎
- 用于获取随机数的链上 VRF
- 可移植到游戏，代表技能树的 NFT
- 一个 quest 任务工厂合约，任何人都可以使用它在游戏中部署和导入他们的 quest 任务
任何游戏组件都是可组合、可互操作、可无限复制的。
这为强大而无边界的自下而上的协作提供了坚实的基础。MatchboxDAO 是往这方面努力的一个典型案例。
强上链游戏解锁的另一个重要功能是客户端抽象。用户不会被迫使用特定平台来玩他们的游戏。他们需要的只是访问一个节点。他们也不需要等待游戏发行商在他们的平台上发布他们最喜欢的游戏。模组制作者不会面临任何可移植性问题。
现在让我们来看看强上链游戏的一些劣势和未来挑战。
UI/UX
在强上链游戏中，游戏合约的每一次状态变化都需要在链上注册。因此，用户需要为每个游戏动作签署并发送一笔区块链交易。这种方案对于 RTS 这种实时性比较高的游戏是不可行的。
账户抽象（AA）是对以太坊账户模型的一个相当引人注目的改进，Starknet 和 Optimism 以及 zkSync 等二层方案都在实施。有了 AA，每个外部账户都可以是一个智能合约，允许部署强大、安全和高度可定制的智能合约钱包。
玩家可以使用本地私钥为每个游戏生成一个智能合约账户。这些受限的智能合约账户可以只被允许做下面的事情：
- 将游戏内的资产或代币发回给本地私钥对应的主账户钱包。
- 从代理合约中调用有限的函数集，这将其映射为目标游戏合约的函数. 每次用户点击游戏内指定动作时，智能合约钱包会调用模块上的对应函数，然后代表用户修改目标游戏合约的状态。
Backrunning
当玩家将交易发送到区块链节点的公共内存池时，如果交易以可读的形式提交，内存池的任何观察者都将能够提前知道该玩家下一个动作将是什么并采取相应的行动。
例如在一个格斗游戏中，玩家 Player图片 要做 High-Kick 这个动作并把相关交易提交给内存池。与此同时， 玩家 Player2 正密切监控着内存池中来自 Player1 的任何交易。交易一旦发出，Player2 就可以预见对手的下一步行动，并能够通过提交完美的反击动作交易来反击对手。
image.png
Player1 将 High-Kick 动作提交到公共内存池。Player2 正在监听内存池
image.png
Player2 用 High-Parry 反击 Player1 的 High-Kick
信息隐藏
大多数竞技游戏是要依赖于某种程度的信息不透明的。
不幸的是，从本质上讲，公链是以清晰易读的方式存储所有信息的，世界上任何可以访问节点的人都可以访问这些信息。它允许任何观察者通过读取存储在智能合约上的信息来窥探其他玩家。
想象一个实时战略游戏，玩家们通过生产每个单位类型具有不同属性的战争部队来相互对抗。每个用户都有一个受限于他们视线的不完整地图视象。由于部队的人口结构对战斗胜负至关重要，因此在战争迷雾中看到对手的生产是一种竞争优势。可以读取智能合约存储的老练用户可以根据对手的行为调整策略。
当本应保密的信息在游戏合约上公开时，可以读取存储字段的人和不能读取存储字段的人之间存在不对称性。由于区块链游戏通常带有激励机制，对这种不对称性的利用会更加严重。
异步回合制游戏可能会实现这样一种提交-显示方案。玩家先分别以哈希而非明文形式发布他们的行动，一旦每个参与者都发布了他们的哈希值，他们就可以明文提交他们的行动。智能合约将验证每个行动是否与附加的哈希一致。
另一种解决方案是利用零知识证明（ZKP）。让外部方（例如执行游戏规则的智能合约）验证状态转换的有效性，同时通过隐藏所采取的步骤及其基础输入来保持计算的私密性。
Dark Forest是一款完全上链的 MMO 游戏，率先使用 zkSNARKs 来保护游戏内信息的私密性。在 DF 中，玩家在无限宇宙中发现并征服行星。但是，他们不需要提交他们征服的行星的坐标。相反，玩家提交坐标的散列并附加本地生成的零知识证明。同样的，每当他们想从 A 星球移动到 B 星球时，他们需要提供两个星球坐标的哈希值加上对应的 zk-proof。只有玩家知道坐标和状态转换，因为它们存储在本地。每个外部用户只会看到哈希和 zk-proof。
ZKP 的最大缺点是生成它们的计算量非常大。目前在主流设备上生成 zkSNARK 通常至少需要几到几十秒。不过，我们也可以选择委托远程服务代理来帮我们生成 ZKP 。
延迟
当成千上万的用户通过调用公共 RPC 节点进行每秒数十万次的智能合约读取时，他可能会使节点很多进入过载状态，从而降低游戏中的延迟。理想情况下，每个用户都应该能够在他们的浏览器/设备上运行他们的本地节点。实际上一个链游短期拖垮一条链的事情已经发生过很多次了。
由于伪造攻击造成的经济损失要小几个数量级，链游很多时候并不需要金融级别的安全性。从安全的角度来看，运行本地轻节点可以被认为是足够好的。
以太坊的无状态客户端 + Verkle 树、Mina 的递归 zkSNARKs和 Polkadot 的Substrate Connect都在往这个方向努力。
然而，RPC 堵塞问题只是造成延迟的原因之一。由于网络是 p2p 的，玩家也可能会因为网络拓扑而遭受高延迟的问题。
此类延迟问题的一种解决方案是 Xaya 团队的游戏通道。作为一种状态通道，如果合约状态需要根据游戏规则被覆盖，玩家可以打开一个直接的链下通信通道，他们可以在其中玩自己的动作，同时不断更新链上状态。
玩家在他们的直接通信通道中进行链下交互，仅在需要时进行链上结算
但是，在两方之间打开链下通道可能会带来两个主要问题：
- 无法在没有中央化机构在场的情况下确定事件顺序
- 拒绝服务攻击
考虑一个 FPS 游戏的两个玩家之间的游戏通道，两个对手之间有一些延迟。在某些时候，它们会同时扣动扳机。从玩家 A 的角度来看，他们先出手。但是玩家 B 看到了相反的情况。我们如何确定谁先开枪？以上可以追溯到分布式系统中的根本时序问题。除此之外，当打开一个直接通道时，玩家会互相暴露他们的 IP，使他们可能容易受到拒绝服务攻击。
目前尚不清楚如何以可扩展和信任最小化的方式解决这些问题。
结论
上面我们只是列举了一小部分强上链游戏所面临的挑战，甚至都没有涉及到可能的交易回滚、数据存储膨胀等等这些问题。行业开拓者将不得不直面这些由区块链架构带来的技术挑战和负面外部性。
尽管如此，链上可组合性和互操作性仍然是非常有威力的。全新水平的人类协作、元游戏和 MEV 机会也许会在未来几年内出现。
现在区块链扩容问题正在慢慢被落地解决，着眼于构建强上游戏将会是一种自然的转变。
