我们希望一些 NPC 或者虚拟环境可以自动随时间演化，而不是跟随被推送到区块链的交易输入被动演化。

撰文：Bytes

一般来说，游戏是基于循环的系统（loop-based）。游戏循环是一个不断重复的过程，通常包含处理用户输入、更新游戏状态和渲染游戏世界这几个步骤。这个循环在游戏运行期间持续进行，通常每秒运行数十次到数百次，以保持游戏世界的流畅性。

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

因此，在全链游戏中实现一个带有时钟周期的循环系统就变得非常重要。毕竟在所谓的「自治世界」中，我们都希望一些 NPC 或者虚拟环境是可以自动的随时间演化，而不是跟随被推送到区块链的交易输入被动演化。

@therealbytes 开发了一个基于 OP Stack 的概念验证型滴答链（带有时钟周期的链），它运行了一个自动滴答的康威生命游戏实现，我们下面来了解他到底是如何实现的。

为保持翻译的简单，我们把 tick 直译成「滴答」，意思就是「循环时钟周期」。

Ticking-Optimism 是一个基于 Optimism Bedrock rollup 架构的「滴答区块链」的概念验证实现。

在滴答链中，有一个特殊的智能合约叫做「滴答合约」，每个区块都会被协议自动调用。这允许其他智能合约在特定的时间或间隔自动触发，无需用户发送交易。

如何实现

Optimism 的新的模块化 rollup 架构，Optimism Bedrock，引入了一种新的交易类型叫做「存款交易」（Deposit Transaction）。与常规交易不同，存款交易：

• 来自 Layer 1 的区块。
• 不需要签名验证。
• 在 L1 上购买 L2 的 gas，所以 L2 的 gas 是不可退还的。

在原始的 Bedrock 中，存款交易用于两件事：

• 执行直接发送到 L1 的交易。
• 在每个区块中为预先部署的 L2 合约设置 L1 属性（编号、时间戳、哈希等）。

在后一种情况下，交易由 rollup 节点创建。它不支付 gas，使用的 gas 不会从 gas 池中扣除。

Ticking-Optimism 修改了 rollup 节点，也创建了一个「滴答交易」（tick transaction），工作方式相同，但不是设置 L1 属性，而是在预先部署到地址 0x42000000000000000000000000000000000000A0 的合约中调用 tick() 函数。这个合约可以通过设置其目标变量来调用另一个合约。

动机

为了说明滴答链的威力，想象一个区块链上的游戏，其中多个 NPC（非玩家角色）在地图上移动。没有滴答链，我们有两种主要的设计方法：

• 懒更新（Lazy updating）。在客户端，NPC 似乎连续移动，但它们的位置只有在用户发送与它们互动的交易时才在链上更新。然后，合约根据其最后的链上更新和自那时起经过的区块数计算 NPC 的新位置。
• 手动滴答（Manual ticking）。我们定义一个更新函数，设置地图上每个 NPC 的位置，并有一个外部帐户定期调用它。

使用滴答链，解决方案与手动滴答相似，但滴答合约会自动调用更新函数，而不是手动调用。

使用滴答链的「自动滴答」而不是手动滴答的优点是：

• 更新由协议保证。
• 更新将在块中的所有交易之前执行，不能被前置，因为它是协议本身的一部分。
• 更新交易不参与常规的 gas 市场。

然而，自动滴答需要一个定制的区块链。如果更新率相同，手动和自动滴答对节点的计算资源需求相同。另一方面，懒更新通常更便宜，因为链上更新更小、更少。

此外，随着需要更新的状态增长，滴答交易的计算成本也增加。这给开发者带来了额外的压力，要求他们设计他们的应用程序，确保成本永远不会超过链所能支持的。

尽管有这些巨大的缺点，自动滴答对于某些类型的应用程序比懒更新更合适。

1, 状态始终明确地在链上并且是最新的

滴答使智能合约能够以恒定的成本访问一个动态状态，该状态使用开放形式的表达式更新。

状态（在上面的例子中，是 NPC 的位置）总是可以在链上以恒定的、相对较低的 gas 成本读取。但是计算当前状态的成本会随着自上次更新以来的区块数增加时，gas 成本增加的也比较多。

如果我们正在更新一个以恒定速度移动的实体的位置，我们可以从其最后设置的位置和自更新以来的区块数计算出它应该在任何给定的区块中的位置。这个操作的成本不会随着更新之间的区块数增长。

另一方面，如果我们更新的状态是像康威的生命游戏（或三体重力模拟）这样的东西，更新的成本与自上次更新以来的步骤数成线性增长。这是一个问题，因为它可以增长到超过用户愿意支付的或链所能支持的。

2, 客户端的作用不同

使用懒更新，更新逻辑需要在智能合约和客户端中都实现。使用滴答，只需要在区块链上实现，客户端可以简单地对链上事件做出反应。

3, 代码更简单，更容易审核

懒更新使开发者将他们的更新逻辑分散在许多函数和智能合约中，每个函数只在执行某些交易时触发。相比之下，滴答方法只需要一个保证定期触发的更新函数。后者使得更容易维护状态的一致性和完整性。

此外，每次添加一个新的懒更新状态（例如，一个新类型的 NPC）时，所有更新函数可能都需要修改以考虑它。这使得代码库更复杂，更容易出问题。

4, 用户不支付更新成本

懒更新的成本通常变化很大，用户可以制定他们的交易，使大部分更新的负担落在其他人身上。使用滴答，所有操作的成本都相对稳定，不容易受到 MEV 攻击。

康威的生命游戏演示

我构建了一个滴答链的演示，运行一个交互式版本的康威的生命游戏。链已经修改，包括在执行引擎中的细胞自动机逻辑，使其更高效，允许比作为智能合约字节码实现的更大的游戏板。

演示的源代码：https://github.com/therealbytes/ticking-conway

演示视频：https://www.youtube.com/watch?v=za12aa5FS6E&list=PL_97Yn8lCzTI_P_4vO1HEXA9k6gF6lawF&index=11

原文地址：