链上游戏中的“AMM时刻”

当我们描述一款产品、技术或创新在特定行业中所产生的革命性影响时，我们常常称之为该行业的 “iPhone 时刻”。这个类比源于 2007 年苹果公司推出的 iPhone 对整个手机和计算机行业的深远影响。

在 DeFi 世界中，这一变革时期被称为 “AMM 时刻”，因为 AMM 模型在 DeFi 领域中发挥了关键作用，特别是在增强市场流动性方面，这直接导致了 2021 年的牛市。那么，链上游戏的 “AMM 时刻” 是什么呢？让我们在文章中深入探讨一下。

AMM 在 DeFi 中的重要性#

DeFi 是区块链技术与金融的结合，将金融规则编码到智能合约中，从而实现去中心化、隐私和自动化。那么，这些金融平台的关键组成部分是什么呢？显然是 “流动性”。例如，三种主要商业模式 —— 借贷、交易和支付（稳定币）—— 都在很大程度上依赖流动性以实现持续增长。

借贷：流动性是借贷操作的核心。传统银行和金融机构依赖短期存款和其他来源来提供长期贷款。流动性不足可能导致这些机构在满足贷款请求或偿还短期债务时面临困难。流动性风险在金融危机中发挥了重要作用 —— 当银行无法获得足够的资金履行其承诺时，便会崩溃。

交易：在资本市场中，流动性至关重要。高流动性表明资产可以迅速买卖而不会造成显著损失。低流动性可能导致更大的买卖差价或在出售资产时难以找到买家。这可能导致价格剧烈波动和市场不稳定。

支付（稳定币）：支付系统的流动性，尤其是涉及稳定币的支付系统，至关重要。个人和企业在转移资金时依赖高效和可靠的支付系统。这些系统中的流动性不足可能导致支付延迟或失败，从而妨碍经济的整体运作。

在 Web3 环境中，交易成为金融操作的核心，因为借贷和支付主要存在是为了促进交易（杠杆和作为交易媒介）。但是，为什么会出现 “AMM 时刻”？这主要是由于区块链固有的性能限制。

传统的集中金融机构依赖高性能服务器来存储其金融规则，以确保顶级的匹配效率。相比之下，DeFi 将这些规则嵌入智能合约中，牺牲了匹配效率以换取去中心化和隐私的好处。

鉴于智能合约的性能相对较低，被描述为一种 “世界计算机” 层，最初的 DeFi 项目（无论是借贷平台还是交易所）都基于传统的订单簿模型进行匹配。在这种背景下，DeFi 在 AMM 出现之前无能为力。

如何利用这种 “世界计算机” 的有限性能来大幅提升流动性匹配效率？AMM 模型的解决方案利用流动性池和算法进行自动配对。虽然具体细节在文献中有广泛讨论，这里不再深入，但其好处包括：

消除传统做市商：在传统金融中，做市商通常为买卖订单提供报价以确保市场流动性。AMM 模型允许流动性提供者将资金存入智能合约，然后根据预定算法自动调整价格并执行交易，从而不再需要传统做市商。

流动性池：在 AMM 模型中，流动性池为交易者提供了一个始终可用的对手方。流动性提供者可以将资金存入这些池中，以换取交易费用，从而鼓励更多参与者并增强市场流动性。

减少交易摩擦：由于 AMM 的自动化，交易可以随时执行，消除了等待传统买卖订单匹配的时间，从而减少了交易摩擦。

促进 DeFi 创新：AMM 模型为 DeFi 领域引入了许多创新，包括流动性挖掘和双代币流动性池。这些创新进一步加速了 DeFi 的增长和采用。

AMM 的创新机制显著提高了 DeFi 的流动性匹配效率，使其与 CeFi 具有竞争力。这一突破导致了被称为 DeFi 夏季的迅猛崛起。

游戏与区块链之间的根本冲突是什么？#

链上游戏现在正处于一个类似于 DeFi 的时刻：游戏如何在低性能的 “世界计算机” 上运行？要回答这个问题，我们需要深入分析游戏与区块链之间的内在矛盾。

我曾写过一篇文章，标题为 “链上游戏引擎架构 ARC 与 ECS 之间的区别是什么？” 在其中，我讨论了游戏循环的概念，强调传统游戏是基于循环的。

传统游戏基于循环模型运行，因为其核心机制是游戏循环。这个循环是一个重复的过程，通常涉及处理用户输入、更新游戏状态和渲染游戏世界。循环在游戏运行期间持续进行，通常每秒执行数十到数百次，以确保游戏世界的流畅性。在这个结构中，游戏系统（如物理引擎、AI 系统等）在每个循环中检查和处理它们关心的游戏实体和组件。

相比之下，区块链的架构是推送式的。区块链是一个分布式数据库，在网络中的节点之间共享和存储信息。当一个节点生成新交易（例如，转账、合约调用）时，这个交易会被推送到网络中。其他节点在接收到这个交易后，会对其进行验证并将其添加到区块链中。这是一个被动的过程；节点不会主动寻找新交易，而是等待网络中其他节点发送给它们。因此，区块链的架构被称为推送式。

这个澄清基本上回答了我们最初的问题。游戏架构通常是基于循环的，而区块链架构是推送式的，这标志着游戏与区块链之间的内在矛盾。那么，我们如何解决这个差异呢？有人可能会争辩说，一旦这个矛盾得到解决，我们将见证链上游戏的 “AMM 时刻”。

为了更深入地探讨，让我们看看游戏如何实现游戏循环。

每个游戏都涉及捕捉用户输入、更新游戏状态、处理 AI、播放音乐和音效以及渲染游戏视觉的序列。这个序列由游戏循环管理。在不深入讨论上述每个任务的具体细节的情况下，我们将重点关注游戏循环本身。为了简单起见，这些任务可以简化为仅更新和显示游戏。以下是一个基本游戏循环的示例：

bool game_is_running = true; 

while( game_is_running ) {
    update_game();
    display_game();
}

让我们引入三个术语：

Tick：
游戏循环的同义词。1 tick = 1 游戏循环。

FPS（每秒帧数）：
在上述实现的上下文中，它指的是每秒调用多少次display_game()。

游戏速度：
这表示每秒更新游戏状态的频率，换句话说，就是update_game()被调用的频率。

总之，Tick / 游戏循环是游戏的基本周期，决定了游戏逻辑的更新方式。FPS 决定了游戏的视觉流畅度，表示每秒渲染的帧数。游戏速度决定了游戏逻辑的进展，通常与 tick 速率相匹配。理想情况下，tick 速率、FPS 和游戏速度应该相等，这意味着每次逻辑更新都有相应的渲染。然而，在现实中，它们可能会有所不同，尤其是在性能限制或其他技术限制下。

链上游戏的核心挑战#

在建立了上述理解后，我们现在可以深入探讨链上游戏面临的核心挑战。

游戏循环与区块链的不匹配：
传统游戏基于游戏循环运行，这意味着游戏状态在每个 tick 或帧中更新。然而，区块链是事件驱动的，仅在发生新交易或操作时更新状态。这种根本的不匹配确实使得在链上游戏中实现传统游戏循环变得复杂。
延迟和实时要求：区块链中的交易确认时间可能会导致游戏响应的延迟，这对需要快速反应的游戏（如动作游戏或竞技游戏）来说是个问题。一个高效的 tick 机制需要考虑这种延迟，尽量减少其对游戏体验的影响。
资源限制和计算成本：每次更新区块链状态都会消耗计算资源，并可能产生费用。在链上游戏中频繁的状态更新可能导致高昂的成本。因此，需要一个高效的 tick 机制来平衡游戏流畅性和费用。

如果我们能够开发出一种适合区块链特性的新的 tick 机制或游戏循环模型，那确实会代表一个 “AMM 时刻”。这可能需要将传统游戏开发技术与区块链的独特特性相结合，从而诞生出一种创新的游戏框架。

但并不是每种游戏类型都是基于循环的？虽然大多数游戏确实是基于循环的，但也存在一些 “推送式” 游戏，它们不需要持续的实时状态更新。例如，回合制策略游戏、传统棋盘游戏或某些卡牌游戏。在这些游戏中，状态仅在玩家进行操作时更新，更加贴合区块链的事件驱动模型。因此，对于链上游戏，值得考虑开发那些自然符合 “推送式” 模型的游戏，因为它们将更顺利地适应区块链的特性。

Ticking Chain：链上游戏的 AMM 时刻#

Argus 的创始人 Scott 表达了类似的观点：

游戏在循环驱动的运行时中进行。即使没有用户输入，状态转换仍然持续。火焰继续燃烧，水流继续流动，作物继续生长，昼夜循环依然存在。

那么，如何设计一个适合区块链的 tick 机制呢？@therealbytes 在他的文章《呈现 tick 乐观》中提供了答案。它全面解释了如何使用智能合约和预编译合约构建一个 tick 系统。这让人想起 Vitalik 的经典论文，介绍了 AMM 概念到 DEX 的方式，标题为 “让我们以运行预测市场的方式运行链上去中心化交易所”。那篇论文首次引入了著名的恒定乘积公式 “A * B = k”。

（一个有趣的细节是：当时并没有 “DeFi” 这个术语；它被称为链上去中心化交易所，就像我们现在称之为链上游戏一样。）

在他的论文中，therealbytes 可能是第一个提出利用链的固有预编译来实现 tick 的人。Ticking-Optimism 修改了 rollup 节点以创建一个 “tick 交易”。它的运作方式类似于 “存款交易”，但不是设置 L1 属性，而是调用在地址 0x42000000000000000000000000000000000000A0 中预部署的合约中的 tick () 函数。这个合约可以通过设置其目标变量来调用另一个合约。

将 Ticking 功能嵌入链的节点中，显著提高了循环效率。这可以与 AMM 模型在 DeFi 中相对于订单簿模型的显著效率飞跃进行类比。你问有多显著？数据可以参考另一篇文章《数字神灵的计时》。

为了充分测试链本身的极限，他以两种方式实现了游戏：作为在链上运行的 Solidity 智能合约，以及作为链本身的预编译。在达到 70x70 网格时，Solidity 实现的 CPU 达到最大，且每个区块更新两次（1 个区块 / 秒，或～10k 单元 / 秒），而具有自定义预编译引擎的链在相同速率下，最大达到 256x256 网格，使用了～6% 的 CPU（~130k 单元 / 秒）。

结论#

如果 AMM 模型确保金融系统即使在低性能区块链上也能实现高匹配效率和流动性，那么 Ticking Chain 则保证了游戏系统也能在这些链上实现高循环效率和流畅性。

上述只是 therealbytes 的一个概念验证，但实际上，已经有完全链上游戏引擎采用了这种 Ticking Chain 模型。第一个开源的 Ticking Chain 引擎来自 @0xcurio，它利用 OPStack 的预编译 tick 功能构建了其 layer2。第二个来自 @ArgusLabs_，使用 Polaris 建立了一个具有预编译 tick 功能的 layer2。我相信未来会出现更多的 Ticking Chain。

Snip20230828_56

上表比较了区块链在金融和游戏领域的应用，突显了它们的巨大相似性。DeFi 最初使用订单簿模型，这是一种主动匹配系统。在转向 AMM 后，它演变为一种被动的自动匹配系统。同样，链上游戏最初采用传统的 “懒惰更新” 和 “手动 tick” 来实现主动游戏循环。在转向预编译的 Ticking Chain 后，它们转变为被动的自动游戏循环。AMM 增强了金融的流动性，而 Ticking Chain 则改善了游戏的流畅性。