全链游戏内核剖析：MUD引擎与World Engine

作者: Solaire, YBB Capital

过去由于区块链链表结构的限制，在链上构建一个实用的DApp一直不是件简单的事情。但即便受此限制，探索者们也从未停下过前进的步伐，随着”x * y = k”这段著名的恒定乘积池公式诞生于世，短短数百行代码的Uniswap引领DeFi彻底改变了Crypto的叙事。简单的DApp在开发者的巧思下尚能达到如此高度，那么复杂的DApp应用呢？比如把游戏或者社交平台完全搭建在链上？这在过去可能是一个疯狂的想法，但在Rollups打开可扩展性的今天，这种可能性开始变得微妙。

DeFi曾给Crypto带来了数千亿美元的TVL，复杂性倍增的DApp如何实现？会引领Crypto再次走上一个新的高度吗？或许处在发展初期的全链游戏能给我们答案。本文的内容将从全链游戏的历史、全链游戏目前的定义、全链游戏创造与运行的实现方式以及全链游戏对Crypto未来的意义，这四个部分对全链游戏进行一次剖析。

全链游戏的起源与发展

全链游戏的历史可以追溯到10年之前，Mikhail Sindeyev分叉 Namecoin 并构建了世界上第一个区块链游戏《Huntercoin》。《Huntercoin》于 2013 年作为一个实验原型开始，并迅速发展了一批在线狂热追随者，得到了许多著名的 bitcointalk.org成员的支持。凭借科技爱好者对视频游戏的热爱，最受欢迎的Huntercoin帖子获得了超过 380,000 次的浏览。然而遗憾的是Mikhail Sindeyev在2014年2月中风去世了，《Huntercoin》的开发也陷入困境，代币HUC在2015年几乎归零，虽然全链游戏的第一次尝试并没有成功，但庆幸的是全链游戏的故事仍在继续。

2020年Gubsheep（Brian Gu）、Alan Luo、SCOTT SUNARTO ，受到小说《三体：黑暗森林》的启发，开发了一款同名MMORTS太空征服游戏《Dark Forest》。游戏建立在以太坊之上，并将所有规则、逻辑写入到智能合约，即每一步动作都是一笔链上交易的全链游戏。游戏内容的核心部分则利用了ZK-Snarks（零知识证明）技术去制作战争迷雾以复现三体小说中黑暗森林法则的定义（一旦某个宇宙文明被发现，就必然遭到其他宇宙文明的打击）。

比如当玩家想要采取行动时，受到黑暗森林的法则影响，玩家不能暴露自己的坐标，却要从A星球移动到B星球，他们需要提交A跟B的坐标以证明这是有效的，但以太坊的区块信息是完全透明的，《Dark Forest》则通过以下方式去实现信息隐藏。玩家选择要离开的星球和目的地星球，这两个星球的位置是玩家的私有信息。计算要离开的星球和目的地星球的位置的哈希值，然后将这两个哈希值提交到区块链。在这个阶段，玩家会提交一个承诺（Commit阶段），由于哈希函数的单向性，这些提交的哈希值不能用来确定玩家的实际行星位置。而下一个阶段是验证（Reveal阶段），在此阶段，玩家生成并提交一个零知识证明，证明他们的行动是有效的。这个证明可以被任何人验证，但不会透露任何关于玩家星球位置的信息。

如此，第一个在信息透明的以太坊上做到隐藏信息的全链游戏就诞生了，这个疯狂又极富想法的实验，很快在整个Crypto圈子里引起了轰动，Vtalik（以太坊创始人）甚至在Twitter直接转发并称赞了这个游戏。

但《Dark Forest》首发后随着超过10000名玩家的涌入，困境也开始显现，以太坊的性能不足以支撑这种复杂应用的运行。游戏上线当天直接堵爆了整个区块链，数万亿的Gas被花费。并且由于游戏是基于DeFi应用的库和架构设计的，后期再进行优化也只是减缓痛苦并不解决问题。

受到这场实验对ZK-Snarks前景的启发以及对全链游戏困境的思考，游戏创始人Brian Gu创建了0xPARC作为ZK-Snarks的研究院，以推动零知识证明的发展，而0xPARC的另外一个分支Lattice则负责设计维护全链游戏引擎MUD。另一位创始人SCOTT SUNARTO则开始研发全链游戏运行专用的分片Rollup框架——World Engine。

零知识证明在今天已经开始了广泛运用，并被各位所熟知，我们接下来讨论的主要是后两者，MUD引擎与World Engine，即创造与运行。但在此之前我们需要了解驱动者（0xPARC）对全链游戏的定义与新的认知方式。

Autonomous Worlds

基于0xPARC加密游戏论文合集《Autonomous Worlds》中的观点，全链游戏至少需要遵循五个标准：

l数据来源于区块链：区块链不仅仅是数据的辅助存储，也不仅仅是存储在专有服务器中数据的 "镜像"。所有有意义的数据都可以在区块链上访问，而不仅仅是资产所有权等数据。这样，游戏就能充分利用可编程区块链的优势——透明的数据存储，可无权限互操作；

l逻辑和规则通过智能合约实现：例如，游戏中的战斗，而不仅仅是所有权，都是在链上进行的；

l游戏的开发遵循开放生态原则：游戏合约和可访问的游戏客户端都是开源的。第三方开发者可以通过插件、第三方客户端、互操作智能合约，实现完全重新部署，定制甚至分叉自己的游戏体验。这反过来又使游戏开发者能够利用整个(激励一致)社区的创造性产出；

l游戏永久存于链上：这一点与上述三点密切相关，因为检验一款游戏是否是加密原生游戏的试金石是:如果明天核心开发者提供的客户端消失了，游戏还能玩吗?答案往往是肯定的，如果(也只有当)游戏数据存储是无权限的，如果游戏逻辑可以无权限执行，如果社区可以与核心智能合约交互而不依赖于核心团队提供的接口；

l游戏可与我们认为有价值的事物互通：区块链为价值概念本身提供了一个本地应用程序接口，数字资产默认情况下可与我们关心的其他资产互操作。这既反映了游戏的深度和意义，也有助于提升游戏的深度和意义，并将游戏世界与"真实"世界联系起来。

基于这个标准下构建的全链游戏也可将其看为基于区块链为低层的世界，或者说Autonomous Worlds（自主世界）。

那么何谓世界？世界并非只能指代现实世界，世界的载体可以是小说、电影、游戏、诗歌甚至法律体系。但在这些世界里都是由中心（作者、开发者或者群体）制定框架与规则再传达给我们。这些世界里自主性的程度也是不一样的，比如开放世界游戏里非常知名的《Minecraft》（《我的世界》），玩家拥有极高的自主性，通过对不同方块的搭建，以及规则修改，玩家可以创造只属于他们的世界。而自主性较低的世界可能是小说世界，比如《Harry·Potter》，我们看到的这个魔法世界都是基于JK罗琳所创造的规则和框架。

如果把区块链作为世界的基底，区块链毫不含糊地保存了其状态下所有节点实体的集合。此外，它们还用计算机代码正式定义了引入规则。拥有区块链底层的世界可以让其居民参与共识。它们运行一个计算机网络，在每次引入新的实体时达成一致。

从世界的角度来看，有两个区块链概念需要定义:

l区块链状态根:状态根是对世界中所有实体的压缩。有了状态根，人们就可以确定任何实体是否是虚拟的，相信一个世界的状态根就等于相信世界本身。0x411842e02a67ab1ab6d3722949263f06bca-20c62e03a99812bcd15dce6daf26e 是 2022 年 7 月 21 日 07:30:10PM UTC 时的以太坊——一个拥有区块链底层的世界的状态根。在计算这个状态根时，以太坊世界的所有实体都被考虑在内。它代表了该世界在该特定时间内的全部内容；

l区块链状态转换函数:每个区块链都定义了一个状态转换函数。它可以被视为一个明确的引入规则。它定义了"世界"的前一个状态——虚拟实体的集合——如何通过人和机器的输入引入新的虚拟实体。就比特币而言，状态转换函数定义了余额如何在地址之间消费和转移。

所以把全链游戏看作以区块链为底层的世界，则这个去中心化世界拥有无限大的自主性，也可以称之为自主世界。

创造的困境

在早期探索全链游戏的新设计过程中，开发者多次受到传统 DApp 架构和用于构建 DeFi 应用的库的局限性的影响。《Dark Forest》和其他早期的全链游戏构建在当时不得不遵循用于构建 DeFi 应用的架构和库，这些架构成为了当时构建全链游戏的默认选择。

早期在创造全链游戏方面的模式可总结为四点：

l当不同合约触及相同状态：多个智能合约可能会修改同一个数据或状态，这可能会导致数据不一致或其他问题。有时使用Diamond Pattern去解决（钻石模式是一种解决Solidity智能合约中多重继承问题的方法）；

l编写多种数据结构：每种实体（如游戏中的士兵、行星等）都有其自己的数据结构和类型；

l编写Getters函数：此为数据结构返回批量元素的函数，用于从链上获取初始状态或数据。例如，getPlanets()函数可能会返回所有行星的列表；

l事件：每个数据结构都包含一个事件，这是智能合约中的特定功能，允许应用在新块被添加到链上时同步或更新其状态。例如，当一个新的行星被创建时，可能会触发一个事件，应用会监听这个事件并更新其显示的行星列表。

通过这种模式构建全链游戏非常痛苦，虽然可以不断进行优化以减缓痛苦，但我们都明白这种构建方式还是与使用真正的通用引擎构建相差甚远。

世界的创造者——MUD引擎

MUD引擎的诞生来自于开放者们对过去以及现有问题的思考，MUD是一个构建复杂应用的以太坊应用程序的框架。MUD 提供了一些组织数据和逻辑的约定，并抽象了低级复杂性，使开发者可以专注于应用程序的功能。它标准化了链上数据的存储方式。有了这种标准数据模型，MUD 可以提供所有网络代码来同步合约和客户端状态。

MUD最新版本目前配备了五个组件：

• Store：一个链上数据库；
• World：一个入口点框架，带来标准化的访问控制、升级和模块；
• tools：基于Foundry的超快速开发工具；
• 客户端数据存储：可以神奇地反映链上状态；
• MODE：可以使用SQL查询的Postgres数据库。

EVM完全兼容性，极高的自由度

MUD的通用性并不止于以太坊主网，只要语言支持，MUD可以无缝地运作在任何EVM兼容的链上，无论是Polygon、Arbitrum、Optimism还是Gnosis Chain。

此外，尽管MUD在Autonomous Worlds（自主世界）和链上游戏社区中是首选框架，但它的应用远不止于此。与此同时，MUD提供了极大的自由度，不强迫开发者受限于特定的数据模型。简而言之，任何可以通过Solidity映射和数组实现的功能，都可以轻松地在MUD中完成。而在数据可用性上，无论是在主网还是Rollups上部署的MUD应用，它们都可以与ENS和Uniswap等传统以太坊应用程序相媲美。

核心思想

MUD作为一套为链上复杂应用设计的高度协同的库和工具，其核心思想围绕三点：

l所有链上状态均保存在MUD链上数据库Store中：Store是一个嵌入式EVM数据库，类似于 SQLite 数据库，它具有表、列和行的概念。使用 Store 可以更加结构化地管理数据，并且不需要依赖 Solidity 编译器提供的存储方法。并且，它支持在运行时创建表，并允许注册挂钩以自动创建索引视图，从而带来更多灵活性；

l逻辑是无状态的，并且通过自定义权限跨不同合约进行分区："World" 充当一个入口点，协调不同的智能合约对 "Store" 的访问。当一个“World”被部署时，它会随即创建一个“Store”，每个在“Store”中的表都是在一个特定的命名空间下被注册的。当功能（比如地址之间转账的逻辑）被添加到“World”时也在命名空间下注册，并被称为“系统”。这些“系统”实际上是智能合约，但与传统的智能合约不同的是，它们是无状态的，不直接持有数据。而是利用“World Store”进行数据的读取和写入。由于这种设计，只要部署在同一条链上，这些“系统”可以在不同的“World”之间重复使用；

l不需要索引器或子图，前端也可保持同步：当使用 Store（以及扩展的 World）时，链上数据自动内省（Introspection，自我检查），任何改变都通过标准事件进行广播。通过 "MODE" 节点，实时地将链上状态转换为 SQL 数据库，从而保持最新状态（毫秒级延迟）。此外，MUD 提供了一系列查询工具，如 MUD QDSL 和 GraphQL，使得前端同步变得更加简化。对于 React 开发者，MUD 还提供了专门的 Hooks，允许自动绑定和更新组件状态。

突破枷锁

通过三点核心思想我们再以过去的困境为例，看看MUD是如何打破复杂应用的枷锁的。

l当不同合约触及相同状态：通过使用 "World" 和 "Store" 结构来集中管理链上状态。所有的智能合约（在 MUD 中称为“系统”）都通过 "World" 来访问和修改 "Store" 中的数据。这确保了所有的状态修改都经过一个集中的入口点，从而减少了数据不一致或冲突的风险。通过命名空间和路径，MUD 提供了对数据的细粒度访问控制。不同的“系统”可以有不同的权限，从而确保只有授权的“系统”可以修改特定的数据或状态；

l数据结构：与传统的 Solidity 存储方法不同，MUD 的 "Store" 提供了类似于 SQLite 的表、列和行的概念，从而可以更加结构化地存储和管理数据。每种实体（如游戏中的士兵、行星等）都可以有其自己的表，每个表可以有多个列来存储该实体的不同属性；

lGetters函数：由于 MUD 的 "Store" 提供了结构化的数据存储，获取数据变得更加简单和直观。开发者可以使用 SQL-like 的查询语言来获取数据，而不需要编写专门的 getters 函数。例如，要获取所有的行星，开发者可以简单地查询行星表，而不需要编写一个 getPlanets() 函数；

l事件：MUD 提供了自动内省功能，这意味着任何数据更改都会自动被系统识别并触发相应的事件。应用可以监听这些事件来同步或更新其状态，而不需要为每种数据结构手动定义事件。

以上是对MUD基本构建块，组件的部分使用方式说明，MUD还可以构建更复杂的场景与应用。

运行世界，World Engine

全链游戏的运行对于以太坊来说一直是个巨大的挑战，随着Rollups的快速发展，以及坎昆升级的临近，成本大幅下降，速度大幅提高的将来。全链游戏已经蓄势待发，但目前的主流Rollups基本是为交易设计的，并没有真正为全链游戏所量身打造的Rollup。

而Argus旗下的核心产品World Engine则是真正为了全链游戏所打造的分片架构Rollup，由于目前还没有公开测试，我们将从项目的博客与演讲中分析World Engine。

全链游戏需要怎样的Rollup

l高吞吐量与高TPS：更快的交易处理，更低的延迟，更好的可扩展性；

l扩展读写：大多数Layer2为了高并发处理，都设计成进行大量写入，但游戏需要读取以获得玩家位置，所以读与写同样重要；

l水平可扩展的链：水平可扩展性是指通过添加更多的节点和资源来增加系统的处理能力，以适应不断增长的需求。这样可以避免Noisy Neighbor 问题（一个应用或实体的活动可能对其他应用或实体产生负面影响，导致资源争用和性能问题）；

l灵活与定制：灵活性与可定制性，方便修改状态机，使其为游戏设计。这包括有一个游戏循环，使其自我执行等等；

lTick rate：Ticks是游戏时间中的原子单位，游戏想要足够低的延迟需要更高的Tick rate或者每秒更多的区块以降低延迟。

分片架构

为了实现上述目标，团队回顾了21 世纪初和 20 世纪 90 年代末并受到启发，像 MMOs 这样的在线游戏刚刚兴起的情况。早期的在线游戏在服务器和网络技术相对有限的情况下，需要找到一种方式来支持大量玩家的互动。"分片"就是其中一种解决方案，它的核心思想是将玩家分布到不同的服务器或“分片”上，每个分片可以独立地托管一部分玩家、游戏地图和数据。

例如，Ultima Online 是一个早期的 MMORPG，它在服务器上实现了分片概念。游戏中的不同分片代表了不同的虚拟世界，每个分片可以容纳一定数量的玩家。这样做的好处包括：

• 扩展性：通过将玩家分布到不同的分片，游戏可以更轻松地扩展以适应更多玩家的加入；
• 减少负载：分片可以减少单个服务器上的玩家数量和数据量，从而降低服务器的负载，提高性能；
• 避免拥堵：分片可以减少玩家在同一区域的拥堵情况，提供更流畅的游戏体验；
• 地理位置优化：通过将玩家分配到就近的分片，可以减少网络延迟，提高游戏响应速度。

那么如何把这个概念带入World Engine？与过去的许多分片排序器不同，"World Engine" 的设计更适合特定的需求。它的优化方向包括吞吐量和运行时间。为了确保高效的 "Tick rate"（即每秒更新频率）和区块时间，它默认是同步的。设计的目标是确保交易被迅速处理，以保持高效的游戏体验或系统性能。在排序方式上采用的是部分排序的方式，而不是强制要求对所有交易进行总排序。这意味着并不要求每个交易都必须在所有其他交易之后发生。这可以减少排序的负担，从而更好地满足高吞吐量和快速区块时间的需求。

这里有两个关键组成部分，EVM Base Shard（EVM分片）与一个Game Shard（游戏分片），EVM分片就是存粹的EVM链。而真正的秘密武器是游戏分片，它本质上是一个设计成高性能游戏服务器的迷你区块链。World Engine具有一个 bring-your-own-implementation 接口，这样我们可以根据我们的喜好定制这个分片。构建的分片，注入到基础分片中。只需要实现一套标准的接口，就像我们熟悉的 Cosmos，Cosmos 有一个 IBC 接口。我们基本上可以将这个整合成一个类似的规范，将自己的分片带到 World Engine 堆栈中。

Cardinal 是 World Engine 的第一个游戏分片实现。它使用Entity-Component-System (ECS)游戏架构，一个具有面向数据的架构。这允许并行化游戏，并提高游戏计算的吞吐量。它有一个可配置的”Tick rate“，最高可达每秒 20 次Tick。对于这里的区块链来说，那就是每秒 20 个区块。另外它还是自我索引的，无需外部索引器。

并且分片还可以通过地理定位，以减少延迟。比如，游戏可能有在美国的排序器，然后亚洲玩家必须等待 300 毫秒的延迟，才能让 transaction 到达排序器。这在游戏中是一个巨大的问题，因为 300 毫秒是很长的时间。如果试图玩一个有 200 毫秒延迟的 FPS 游戏，那基本上就是，在玩PPT了。

结语：对全链游戏的思考

全链游戏一直是亚洲加密圈内较为冷门的方向，但随着Starknet的游戏引擎Dojo的推出，以及基于OP Stack 概念验证型滴答链的开发演示，关于全链游戏的讨论逐渐开始火热。而本文讨论的范围是《Dark Forest》所衍生出的生态，也是目前全链游戏最强大的生态。

通过对其历史和技术上的探究，我们可以发现Rollup以及DApp还具备极高的上限，以更远大的视角看，随着基建设施的提升，不仅仅是游戏而是各种复杂想法的构建与实现都会通过MUD进行，并在更复杂的Rollup方案上融合交互，区块链的新范式也许会从全链游戏开始。

关于全链游戏还有许多可扩展的内容，比如从Loot衍生出的全链游戏生态推动了Starknet发展，又或者是状态同步的实现，ESC架构的运用。我已将相关阅读链接放在下表，感兴趣的朋友可以阅读了解。

参考文献

1.原文：译文：

2.

3.

4.

相关阅读

1.

2.

3.

4.

5.

6.