如何使用OPStack构建全链游戏的时钟周期

一般来说，游戏是基于循环的系统（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 的位置，并有一个外部帐户定期调用它。

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

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