原文编辑：Faust，极客 web3

导语：自上一轮周期中 Axie 和 StepN 横空出世以来，Gamefi 和全链游戏始终是区块链行业的热点之一，这一全新的游戏模式在区块链技术之上，在玩家资产所有权、价值转移与游戏内经济体系、规则透明化及社区治理方面，带来了传统游戏平台从未实现的独特体验。这些愿景听起来虽然美好，但却面临着一个始终没有解决的问题：

链游的可玩性普遍不高，趣味性不足，更偏向于金融投机，在投机回报下降后，用户规模会迅速萎缩。

显然这与传统游戏的发展模式背道而驰。传统游戏的顺利发展，往往是靠着游戏机制的趣味性，能吸引到大量用户，同时游戏的开发者可以建立起良好的盈利路径，还可能因自身的影响力拓展出一系列的周边与 IP。可以说，那些成功运营下来的传统游戏，其整个系统是正循环的，玩家可以体验到游戏的乐趣，往往也可以在游戏内和游戏外获得一定的经济利益。

相比之下，目前的链游更多是靠着单纯的回报率来吸引玩家。除了可玩性弱以外，Web3 游戏还面临着使用门槛高、交互流程繁琐等老生常谈的问题。

这一切的根源是什么？不同的人有不同的看法。TabiChain 团队认为，影响 Web3 游戏的一个重要因素，是优秀的传统游戏开发者因为技术和学习成本问题，难以进入 Web3 生态。对于那些不了解游戏或软件开发的人来说，从 Web2 到 Web3 只是换了一种叙事和环境而已，但实际情况远比想象中恶劣的多。

那么我们该如何通过技术实现，为传统的游戏开发者或相关厂商，缔造一种更友好的环境？下文中，我们将从多个方面，对 Web3 游戏面临的问题，及对应的解决方案进行全面解析，为大家阐述未来的 Web3 游戏业该如何在技术上更适配传统游戏从业者。

阻碍传统游戏开发者进入 Web3 生态的技术原因

在前文中，我们曾简单提到，技术不友好以及学习成本的高昂，是阻碍传统游戏从业者进入 web3 生态的核心因素，所谓的技术不友好和学习成本高昂，可以展开为以下几点：

1.Web3 应用与传统软件结构的不同

区块链和其上的应用（dApps）与传统软件架构有着本质不同，要求开发者具备全新的知识体系，如区块链的工作原理、共识协议、智能合约编程模型等。传统的游戏开发者需要花费大量时间来学习 Solidity 或其他智能合约语言，需要理解 EVM 的工作方式。

而且，传统的游戏逻辑通常在中心化的服务器上执行，可以灵活处理复杂的游戏状态和高频交互。在区块链上运行游戏逻辑则需要高度简化或重构，因为每个操作都要发布到分布式网络中执行，然后再上链，这受到区块链性能和成本的严重限制。

2. 智能合约的设计限制

EVM 虽然满足图灵完备，理论上可以表达任意逻辑，但其特性非常不利于游戏开发，例如：

· 缺乏定时器。以太坊链上的所有操作，必须由 EOA 账户手动触发。为了实现类似于定时器的效果，开发者需要额外部署一个服务，维护一个 EOA 账户以及事件列表，来手动触发定时任务。由于上链的延时问题，这些定时任务还不能保证按时完成。

· 没有回调等机制，不支持多线程和异步。由于 Solidity 是为以太坊智能合约开发而设计的，它的执行环境与传统的运行时环境有显著的不同。EVM 的操作是事务性的，每次函数调用都需在一个事务中完全执行，而不存在传统意义上的「异步」概念。这意味着在 Solidity 中一次函数调用开始直到结束，都是原子性的，不能被其他事务中断。

· 没有引用外部数据的能力。虽然有类似 Chainlink 这种预言机，但不论是从集成角度还是数据调用角度看，其易用性与直接通过 https 请求来获取数据调用有天壤之别，并且这又让开发者增加了额外的集成负担和依赖。

· 扩展性和性能限制。游戏逻辑必须被简化或分解成多个简单的交易，以避免单一交易的 gas 费变得过高或超出最大限制，这限制了复杂交互和功能的实现。

3. 数据存储与调用的限制

· 智能合约的存储空间昂贵且设计有限，不适合存储大量游戏数据。

· 可能需要用事件日志来间接跟踪游戏状态，而事件的抓取可能并不稳定。诸如何时刷新游戏状态等问题，常常需要玩家或者游戏运营方手动触发。

· EVM 采用的账户数据结构，导致其数据索引能力很差。当你查询某个账户的数据时，你只能了解其 ETH 或链原生 Token 的余额，但其拥有哪些 ERC-20 资产、每种资产的余额是多少，无法直接获知。对于 NFT 也是一样的道理。这些信息都封装在每种资产的专属合约中，而不是在用户自己的账户下存储。

我们能够从 Etherscan 等工具中看到某个地址具有何种 token 及其余额等信息，这些都是由区块链浏览器等周边工具索引而来，而后者要建立专属的庞大数据库，完整爬取所有的区块数据或监听链上事件，才能将链上的全部数据汇总归集。

Web3 开发者通常要集成类似 Etherscan，NFTscan，The Graph 等第三方数据提供方，甚至要为其 API KEY 付费。此外，这些第三方服务本质都是链下的数据库，可能出现迟滞、出错、超过调用限制、服务不可用等故障。

我们来对比一下，大多数游戏自身的数据库形态与区块链中数据存储方式的差异，两者的不同是显而易见的。大多数游戏的数据结构完全由自己定制，有良好的表达和索引能力，不需要依赖任何第三方服务。

4. 与现有游戏资产集成的困难

现有的游戏资产（比如道具和角色）通常不是在区块链上创建和管理的。将这些资产迁移到区块链上，通常要将通用但长尾的数据类型转换成标准的 NFT 或 Token，这涉及到复杂的迁移和集成工作，会影响到现有的游戏经济系统。

5. 升级、补丁与防灾

在以太坊上，智能合约一旦部署后，代码就是不可变的，这使得升级和修补程序比传统软件更为复杂。开发者经常使用代理合约或版本化模式来绕开这一限制，但这增加了整体结构的复杂度，代理合约在使用时需要格外小心，以免存储槽冲突导致数据损坏。另外，管理权限泄露风险也很严峻。

传统游戏的代码升级在技术构造上没这么复杂，唯一可能需要约束的是中心化的升级权限，这可以通过 DAO 等方式实现而非依赖于智能合约。

并且，传统游戏时常会进行数据库的快照或备份。这在平常可能不是很重要，但若遇到升级有重大 bug 时，可以迅速回滚数据，而这在区块链上基本是天方夜谭。即使通过重建合约的方式来对某些游戏的数据进行回滚，如何把旧合约的数据和状态迁移到新合约，仍然很复杂。

6. 生态割裂与用户体验问题

不同的公链和 VM，其智能合约语言、架构、数据结构等是迥异的。在 Web2 中，游戏开发者会选择 Unity 等跨平台的前端引擎，可以做到一套代码稍加适配运行在 iPhone、Android、桌面端等不同环境；后端由于不运行在用户终端上，所以不存在跨平台问题。

而在 Web3 中这基本是奢望，迁移至一个不同的链或 VM，意味着项目整体的重构，要付出巨大成本，更何况初入 Web3 的开发者完全没有经验去选择适合自己的生态，不论是从技术角度还是生态角度。

而在用户体验层面，区块链交互及其复杂，此前盛极一时的账户抽象概念，正是为了解决 web3 用户体验问题而涌现，在此不做过多赘述。

罗列完上述 6 大论点，我们总结一下：web2 to web3 的开发者面临着巨大的适应门槛，如果他们是 web2 中的顶尖开发者，完全没必要抛弃 web2 中的事业不做，去 web3 这么一个陌生的环境里拓展一些不知道能不能成功的业务。

可以说，顶尖的游戏开发者大多没有进入 Web3，某种程度上，这使得 Web3 游戏大多偏向金融投机，而不具备特别高的可玩性和乐趣。

用户侧也存在同样性质的障碍，Web3 游戏一系列阻碍用户转化率的操作步骤，导致 Web2 巨大的用户群体没有意愿体验甚至完全不知道 Web3 游戏的存在。

有没有一种 infra 级别的项目能够解决上述问题呢？Tabi Chain 可能是非常接近 Web3 游戏终极解决方案之一的项目，其核心概念是「全能执行层」（Omni Execution Layer）：开发者无需再关心各种 VM 或运行环境的区别，直接使用自己熟悉的、甚至是可以自定义的运行环境，直接开发或者移植的游戏。

除此以外，Tabi Chain 还拥有模块化的共识、安全层等特性，一切都是模块化和可定制化的，以满足不同游戏和应用的需求。

全能执行层：按照开发者需求来选择执行环境

我们来回忆一下，区块链的本质是什么。有人可能会说是去中心化的不可篡改的账本。但如果更接近技术本质来说，应该说是：状态机在分布式网络中的可验证的永久状态同步。

也即，区块链实际在维护一个全网公认的状态机和其运转的状态：

· 每一次输入都是确定的，被记录在每个区块中；

· 状态转换函数是确定的，具体表现为区块链客户端中的 VM 或运行时；

· 状态的输出也是确定的，也被记录在每个区块中；

因此，一个链的共识体系中，并不一定只能存在一种执行层（如只有 EVM），不论多寡，只要这条链能验证其上多个执行层的状态，让每个游戏都运行在自己的环境中，就可以解决我们上面说的种种问题。

在 Tabi 中，每个游戏或 dApp 可以构建自己独立的一个 Service。所有 Service 将各自产生的区块提交至链的共识系统内；Supervisor Nodes 中包含了所有 Service 中的运行时/VM，来校验 service 区块的状态。在 Tabi 的全能执行层的核心可以看做一个具有多态能力的 VM，因此叫做 Polymorphism VM。

对于已有的区块链 VM 而言，Polymorphism VM 需要将该 VM 囊括入自身的运行环境中，并提供相应的接口调用方法。「囊括」这个概念在这里有两种具体的实现：

共享世界状态：类似 Ethermint，在 Cosmos 上提供了对 EVM 的支持。但 EVM 仅仅是一个表层，专注于用户交互、合约操作等，让所有的用户侧的操作看起来是在 EVM 上实现的。但这些操作最终的结果和数据，还是会存储在其他 Cosmos 模块中。所以这种 EVM 兼容性其本质是最底层数据的映射。

因此这种映射关系，也可以拓展到其他 VM 上，比如 Ethermint 可以再加一层 SVM 的模块，这层 SVM 和 EVM 其实对应的都是一份底层数据。

这就类似于在 PC 上使用 VMWare 来启动一台 Windows 虚拟机，VMWare 不仅可以访问虚拟机内部的虚拟硬盘，也可以访问物理电脑的硬盘。如果此时再启动一台 Mac 的虚拟机，它也可以用同样的方式来挂载物理磁盘中的数据。这样其实就实现了多台虚拟机对同一个世界的资源与状态的共享。

Tabi Chain 的 Main Service 的将采用这种世界状态共享的形式。因此只要有对相应 VM 的适配，基于该 VM 开发的 dApp 可以选择直接部署在 Main Service 上而非另起一个 service。

独立世界状态：由于不同应用和游戏的需求迥异，有些游戏有自定义的运行时，将所有 VM 大一统地通过「共享世界状态」的方式囊括进 Polymorphism VM 中并不适合所有情形。因此独立的世界状态也是需要的，这种实现方式相对简单，对数据完全对立的 Service 而言也是最契合的。

但不论采用何种形式，都必须能被 Supervisor Nodes 进行验证，也即 Polymorphism VM 中包含了所有实现方式的 VM 或 Runtime。

Web2 游戏移植案例

Polymorphism VM 具有高度的可定制性，特别是对于 Web2 开发者来说，他们可以使用自己熟悉的语言和框架，将任何业务逻辑移植到 Polymorphism VM 上。

假设 Minecraft 现在想要移植到 Tabi，大致的流程为：

1.略微修改 Minecraft 服务端代码（Java，其他语言同理），将需要上链的数据移动到一个数据库（或一组）中，并将所有可能导致该 DB 发生变化的函数（也即状态转换函数）也挑选出来。

2.将该数据库和这些函数，打包为一个 JAR 包，可以理解为 Java 的一种可执行程序。最后再加上 JRE 也即 Java 的运行环境。这一整体加载入 Polymorphism VM 中，最终其所有数据都会上链。

3.将其他与上链无关的后端逻辑（如组队、聊天等）将运行在链下服务器中。

4.在 Tabi Chain 中启动一个 Service，并通知 Supervisor Nodes 中的 Polymorphism VM 加载相同的 JRE。

至此所有的流程就结束了。

对开发者而言这些改动是在原有的 Java 语言和框架下完成的。对于任何其他开发方式的游戏也是同样的道理。对用户而言游戏的交互也没有明显的改变。显然，这种移植 Web2 游戏的方式非常迅速和高效，有可能成为 Web3 游戏 mass adoption 的基础范式。

游戏 STR 状态转换函数细节

上述例子是 Web2 游戏移植的大致流程。我们还需要对细节了解更多。这次我们用通用的而非具体某个游戏的例子来展示，全能执行层中的运行时会涉及到的细节。

基本上，定制一个游戏的运行环境可以被视为在区块链上创建某个游戏的状态机，在 Tabi 中叫做 State Transition Runtime。

STR 可以通过以 binary 或 module 的形式集成入 Polymorphism VM。

在类似区块链的系统中，我们需要确保输入的透明度、状态转换的公开可见性以及全局状态的表达能力。为了满足这些需求，我们需要构建具有以下特性的运行时：

1.世界数据库（World DB）包含应用内需要记录在区块链上的所有用户数据。这些数据应该是有价值和重要的，因此需要一种类似区块链的结构来确保其可用性。因此，并非所有数据都需要记录在区块链上。例如，在游戏中，用户的聊天内容一般并不重要是可丢弃的，因此不需要放在区块链上。

2.它能够表达完整的世界状态。在许多场景中，比如在游戏中，这种表达不一定意味着高度的可跟踪性——一个简单的累加器就足够了，这意味着像默克尔树这样的数据结构并不总是必需的。然而，无论使用什么样的数据结构来代表世界状态，至关重要的是世界数据库的世界状态可以以摘要形式表达。

3.任何可以引起世界数据库变化的功能被称为状态转换函数，并应该封装在状态转换运行时中。任何在运行时之外对世界数据库的修改都应该被视为非法并拒绝。

4.输入和输出接口应该符合 Input Interpreter 和 Block Proposer 的设计。这一点相对简单，在这里不做详细说明。

下列组织结构是该 STR 中必不可少的一些内容。Tabi 默认会提供一个 SDK 来方便开发者制作该运行时。

World DB

在实践中，游戏或应用程序很可能会使用不止一个数据库，而这些数据库可能是不同的类型。让我们假设特定的游戏同时使用了关系型数据库和键值型数据库。

以下是一个简单的关系型数据库的例子：

1.UID：代表一个唯一的用户，它可以是公钥或其他标识符。

2.Nonce：用于预防重放攻击。

3.额外数据字段：任意类型的数据。

这是一个简单的键值数据库：

状态转换函数

这是一个简单的状态转换函数。当这个函数接收到用户的输入时，它简单地将其乘以 5 并修改关系型数据库中的数据。

世界状态累加器

我们可以构建一个非常简单的哈希累加器来表示世界状态：

A_s 1 = hash(A_s hash(query))

通过这样的构造，可以确保在对世界数据库进行任何修改之后，总会有一个唯一且确定的状态与那次修改操作对应。

需要注意的是，这意味着每个状态转换函数必须实现这个方法。这个要求可以通过使用修饰符、接口、钩子或者使用的语言特有的其他逻辑来强制实施。由于不同的语言有不同的特点，这里不讨论具体细节。

键值数据库（KVDB）的更新过程也是相同的。

随机数

任何状态转换函数中不应出现随机数，否则会导致不同的验证者验证时产生不同的结果，而导破坏一致性。随机数应该被纳入系统输入参数之中。

总结

通过上面的两个例子我们可以发现，Tabi Chain 的全能执行层，用模块化的方式为游戏开发者提供了极大的灵活性。由于篇幅所限我们无法在此将所有细节展开讨论，但上述核心内容已经足够论证 Tabi Chain 的解决方案是非常实用且新奇的。

在原有的 Web3 体系下，不同链、VM 上开发的作品基本不具备可移植性；Web2 游戏想要进入 Web3 基本等于重写，并且是用开发者非常陌生的语言与环境，并且受到各种难以理解的限制。

在 Tabi 中，开发者使用原有的语言、开发平台、引擎，只需要像调用 SDK 一样做简单的适配与修改，就可以将自己的作品带入区块链世界中。这种效率的提升与复杂度的降低都是指数级别的。

我们期待其能够为 Web3 游戏的 mass adoption 的奇点，吸引到 Web2 优秀的游戏开发者，为 Web3 带来有真正娱乐价值和可玩性的游戏。