什么是全链游戏的“AMM 时刻”？

当我们描述某个产品、技术或创新在特定行业中产生的革命性影响，喜欢说这是该行业的“iPhone 时刻”。因为这是基于 2007 年 Apple 发布 iPhone 后，它对整个手机和移动计算行业产生的深远影响。

在 DeFi 行业，我们则称之为“AMM 时刻”。因为 AMM 模型在 DeFi 领域中起到了关键的作用，特别是在提高市场流动性方面，直接促成了 2021 年牛市的到来。那么，什么是全链游戏的“AMM 时刻”？我们在本文一探究竟。

一 AMM 在 DeFi 中的重要作用

DeFi 是区块链技术和金融领域的结合，也就是把金融规则写入到智能合约，从而实现去中心化，隐私化和自动化。既然是金融领域，那么各种项目最关键的是什么呢？显然是“流动性”。比如三大业务模式，借贷，交易和支付（稳定币业务），如果没有流动性，三个业务是没法持续性展开的。

借贷：流动性是借贷业务的核心。银行和其他金融机构依赖于短期的存款和其他资金来源来提供长期的贷款。如果金融机构无法确保足够的流动性，它们可能无法满足客户的贷款需求，或者在需要偿还短期债务时可能会面临困境。流动性风险是金融危机中的一个关键因素，当银行无法获得足够的资金来满足其贷款承诺时，它们可能会崩溃。

交易：在资本市场中，流动性是交易的关键。流动性高意味着资产可以迅速而不损失价值地买卖。如果一个市场或资产缺乏流动性，投资者可能会面临更大的买卖价差，或者在想要出售资产时难以找到买家。这可能会导致价格的剧烈波动和市场的不稳定。

支付（稳定币）：支付系统（稳定币）的流动性至关重要。当人们或企业需要转移资金时，他们依赖于高效、可靠的支付系统。如果支付系统（稳定币）缺乏流动性，可能会导致支付延迟或失败，从而影响到整个经济的运作。

在 Web3，交易是金融业务的核心，因为借贷和支付都是为了服务交易而存在的（加杠杆和充当交易媒介）。那为什么会有“AMM 时刻”？这是因为区块链的本身性能限制决定的。

我们知道，中心化金融机构的金融规则是放在自己公司的高性能服务器上，所以撮合效率极高，而 DeFi 是通过把金融规则放在智能合约里面，牺牲了撮合效率而带来去中心化和隐私化的优势。

智能合约做为一种“世界计算机”层的模拟，性能相对来说极为低下。在最初的 DeFi 项目中，不管是借贷还是交易所，撮合方式都是基于传统金融的订单薄模式。在这种模式下，DeFi 在 CeFi 面前毫无还手之力，直到 AMM 的出现。

如何使用超低性能的“世界计算机”来极大提高流动性的撮合效率？AMM 模型的解决方案是使用资金池和算法来自动匹配。具体玩法已经有很多文章做介绍，这里不再展开讨论。在优点方面我们现在已经知道：

无需传统做市商：在传统的金融市场中，做市商通常需要为买卖订单提供报价，以确保市场的流动性。而 AMM 模型允许流动性提供者存入资金到一个智能合约中，该合约自动根据预定的算法调整价格和执行交易，从而无需传统的做市商介入。

流动性池：AMM 模型中的流动性池为交易者提供了一个始终可用的交易对手方。流动性提供者可以存入资金到这些池中，并获得交易费用作为回报，从而激励更多的人参与并提高市场流动性。

降低交易摩擦：由于 AMM 的自动化特性，交易者可以随时进行交易，无需等待传统的买卖订单匹配，从而降低了交易摩擦。

推动 DeFi 创新：AMM 模型为 DeFi 领域带来了许多新的创新，如流动性挖矿、双币流动性池等。这些创新进一步推动了 DeFi 的发展和普及。

AMM 机制的创新居然促使 DeFi 的流动性撮合效率可以和 CeFi 相媲美，并最终带来了 DeFi Summer。

二 游戏和区块链的本质矛盾是什么

现在全链游戏来到了和 DeFi 同样的时刻：在一台极低性能的“世界计算机”上面如何运行一个游戏？这需要深入分析游戏和区块链的本质矛盾是什么。

我曾经写过一篇文章《全链游戏引擎架构 ARC 和 ECS 有什么区别？》，在里面介绍过游戏循环的概念，并且指出传统游戏是基于循环的（loop-based）。

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

然而，区块链的架构是基于推送（push-based）的。区块链是一个分布式的数据库，它通过网络中的节点共享和存储信息。当一个节点产生一个新的交易（如转账、合约调用等）时，这个交易会被推送到网络中，其他的节点收到这个交易后会验证它并将它添加到区块链中。这是一个被动的过程，节点不会主动去查找新的交易，而是等待网络中的其他节点发送新的交易。因此，区块链的架构被称为是基于推送的。

其实这段话已经回答了上面的问题。游戏架构一般是 loop-based，而区块链架构是 push-based，这就是游戏和区块链的本质矛盾。那如何解决这个矛盾？可以说，只要解决了这个矛盾，就迎来了全链游戏的“AMM 时刻”。

为了更深入的讨论，我们来看看游戏是如何实现游戏循环的。

每款游戏都包含一系列获取用户输入,更新游戏状态,处理 AI,播放音乐和音效以及显示游戏的顺序。这个顺序通过游戏循环来处理。我们暂时不详细讨论上述任何任务,而是将注意力集中在游戏循环本身，所以可以将任务简化为仅更新和显示游戏两个函数。下面是游戏循环最简单形式的示例代码:

bool game_is_running = true;

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

先引入三个术语：

Tick

Tick 是 game loop 的同义词（拟声词），1 tick = 1 game loop

FPS

FPS 是每秒帧数 (Frames Per Second) 的缩写。在上述实现的上下文中,它是每秒调用 display_game() 的次数。

游戏速度

游戏速度是每秒更新游戏状态的次数,或者换句话说,每秒调用 update_game() 的次数。

总结一下，Tick/Game Loop 是游戏的基本周期，决定了游戏逻辑如何更新。FPS 是每秒渲染的帧数，决定了游戏的视觉流畅性。游戏速度是游戏逻辑如何进展，通常与 tick 速率相等。在理想情况下，tick 速率、FPS 和游戏速度应该都是相等的，这意味着每次逻辑更新后都会有一个对应的渲染。但在实际情况中，这三者可能会有所不同，特别是在性能受限或有其他技术限制的情况下。

三、全链游戏的核心挑战

有了上面的理解，我们现在可以讨论全链游戏中的核心挑战了。

1. 游戏循环与区块链的不匹配：传统的游戏是基于游戏循环（game loop）的，这意味着游戏的状态在每个 tick 或帧中都会更新。但是，区块链是基于事件驱动的，只有当有新的交易或操作时才会触发状态的更新。这种基本的不匹配确实使得在全链游戏中实现传统的游戏循环变得复杂。

2. 延迟与实时性：区块链的交易确认时间可能会导致游戏的响应延迟，这对于需要快速响应的游戏（如动作游戏或竞技游戏）来说是一个问题。一个有效的 ticking 机制需要考虑这种延迟，并尽量减少其对游戏体验的影响。

3. 资源限制与计算成本：每次更新区块链的状态都需要消耗计算资源，并可能产生费用。在全链游戏中，频繁的状态更新可能会导致高昂的费用。因此，需要一个高效的 ticking 机制来平衡游戏的流畅性和成本。

如果能够开发出一个适应区块链特性的新的 ticking 机制或游戏循环模型，这确实会是一个“AMM 时刻”。这可能需要结合传统的游戏开发技术和区块链的特性，创造出一个全新的游戏框架。

那么是否所有的游戏类型都是 loop-based 吗？虽然大多数游戏类型确实是基于循环的，然而，也存在一些“push-based”的游戏，这些游戏不需要持续的、实时的状态更新。例如，回合制策略游戏、棋类游戏或某些卡牌游戏。在这些游戏中，状态只在玩家采取行动时更新，这与区块链的事件驱动模型更为相似。因此，对于全链游戏来说，确实可以考虑首先开发那些更符合“push-based”模型的游戏，这样可以更自然地适应区块链的特性。

四、滴答链就是全链游戏的 AMM 时刻

Argus 的创始人 Scott 也表达过同样的看法：

游戏在一个循环驱动的运行时操作（loop-driven runtime）。即使没有用户输入，状态转换也会继续发生。火继续燃烧，水继续流动，作物继续生长，日夜的循环继续。

那么怎样才能设计一个适合区块链的 ticking 机制呢？@therealbytes 给出了答案。我曾经翻译过他的那篇经典文章《如何使用 OPStack 构建全链游戏的时钟周期》，里面对如何使用智能合约和预编译合约构造 ticking 系统做出了极为详细的解释，但可惜的是，因为比较技术性，这篇文章的浏览量在我所有文章里面是最低的。类似于 Vitalik 那篇在 DEX 引入 AMM 的文章《Let’s run on-chain decentralized exchanges the way we run prediction markets》，在那篇经典的文章中，第一次引入了著名的恒定乘积公式“A * B = k”。

（一个有趣的点：那个时候没有 DeFi 的叫法，只是叫 On-chain decentralized exchange，如同现在我们称全链游戏叫 On-chain game）

在这篇文章中，therealbytes 应该是第一个提出了利用链本身的预编译来实现 ticking：Ticking-Optimism 修改了 rollup 节点，创建了一个 “滴答交易”（tick transaction），工作方式与“存款交易”相同，但不是设置 L1 属性，而是在预先部署到地址 0x42000000000000000000000000000000000000A0 的合约中调用 tick () 函数。这个合约可以通过设置其目标变量来调用另一个合约。

把 Ticking 函数内置到链的节点，在 loop 效率方面是一个巨大的提升。这一点完全可以类比 DeFi 行业中，AMM 模型对比 Orderbook 模型在撮合效率上的巨大提升。究竟有多巨大呢？数据可以参考我翻译的另一篇文章《[为“数字神明”记时]()》：

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

五、小结

如果说，AMM 模型保证了金融系统在低性能的区块链上也可以有很高的撮合效率和流动性，那么，滴答链（Ticking Chain）是保证了游戏系统在低性能的区块链上也可以有很高的循环（loop）效率和流畅性。

上面介绍的只是 therealbytes 的概念验证，而实际中已经有全链游戏引擎开始使用这种滴答链的模式了。第一个开源的滴答链引擎是@0xcurio，他们使用的正是具有预编译 ticking 函数的 OPStack 来搭建 layer2，第二个开源的滴答链引擎是@ArgusLabs_，他们使用的是 Polaris 来构建具有预编译 ticking 函数的 layer2。我相信未来还会有更多的滴答链出现。

上面的表格是对金融和游戏领域在区块链方面的应用做的对比，可以看到两者确实有极大的相似性。DeFi 在开始使用的 Orderbook 模型，是一种主动式的撮合系统（Matching system），改为 AMM 之后，就变成了被动式地自动撮合系统。类似的，全链游戏在开始使用的是常规的“lazy update”和“manual ticking”来进行主动式的游戏循环，改为预编译的滴答链之后，就变成了被动式的自动游戏循环。AMM 提高了金融的流动性，滴答链提高的是游戏的流畅性。