链上游戏和可验证游戏的未来开发者体验，将会是高度模块化，可插拔式的。

撰文：wangyao、0xbrawler

太长不看版：

• ZK 协处理器方法提供了可验证游戏所需的信任假设，以及开发引人入胜的游戏体验所需的计算能力
• 对于经验丰富的游戏开发人员来说，【非常】需要 Unity/Unreal 原生解决方案，而不是把在 Solidity/Cairo 的核心游戏逻辑，和 Unity 中的动画 / 渲染二者进行同步
• 链上游戏和可验证游戏的未来开发者体验，将会是高度模块化，可插拔式的（到底有多上链算上链？我们认为应该由开发者和用户决定）
• 未来，我们相信将会有弹性的方法，来 tradeoff 信任假设、证明成本、开发成本，从而开发成本可控的可验证游戏

为什么要开发可证明游戏？

2023 年是链上游戏（FOCG）/ 自主世界（AW）蓬勃发展的一年，出现了大量的基础设施。这包括 Mud.dev、Dojo、World Engine、Keystone、Paima 等等。此外，Altlayer、Caldera、Conduit 等 Rollup 服务供应商也吸引了众多全链游戏开发者进行开发。

然而，通过开发和运营我们的第一个链上大逃杀游戏 Loot Royale，并在一个月内达到了每日活跃用户 600–800 人的过程中，我们发现了一个重要问题：

如果把游戏逻辑全部放在链上，那么 EVM 本身的有限计算能力将会成为游戏开发最大的瓶颈。

计算能力的不足限制了游戏类型（低计算量、单线程、异步游戏为主），以及用户体验（大家要等交易打包、RPC hydration 等）。

简单举几个例子。我们收到了很多反馈，比如「我希望我的交易能及时被打包，这样那次攻击就能命中了」，以及「RPC 数据什么时候才能完成加载」。这必须改变。

玩家们等 RPC hydration 真是急得不行

在尝试在各种技术栈上开发之后，我们相信如果能够在链下证明计算，那么其可信性效果应当极度接近于全链上的交易 / 计算。我们通过采用「链下执行，链上验证」的原则来解决 EVM 的有限计算能力。这有几个优势：

• 改善用户体验，减少等待时间
• 扩展游戏类别，包括像塔防这样需要更多计算的「硬核休闲」（mid-core）游戏
• 支持隐藏信息（hidden information）在游戏中的应用

我们将首先简要介绍我们如何使用 zkWASM 开发可证明的游戏。然后我们将讨论我们的 zkwasm-unity 解决方案，这是行业内首个允许直接从 Unity 开发可证明游戏的方案。

Blade Games 的技术架构

基于 zkwasm 开发简单的塔防游戏

技术架构这里分成两部分，第一部分是用 Rust 编写简单的 PvE、PvP 塔防游戏，并通过 zkwasm 进行验证。

第二部分是我们的路线图，我们计划开发一个将 C#编译成 wasm 的编译器，并对现有 zkwasm 架构进行适当修改，从而实现一个更加模块化、弹性化的可证明游戏开发方案。（zkwasm 由 Delphinus Labs 开发，是一个运行 wasm 代码并生成其执行轨迹的 zkSNARK 证明的 zkVM。）

让我们从 PvE 示例开始 — 我们用 Rust 和 Bevy Engine 编写游戏。

Rust 可以轻松编译成 wasm，并在 zkwasm VM 中处理之前生成一个 wasm 映像（image）。然后我们可以选择将处理后的执行轨迹发布到数据可用性层（Data Availability Layer）并稍后证明它。或者用户也可以选择立刻证明，并将 zkSNARK 证明发送到链上（使用单张 RTX4090 GPU 大约 45 秒就可以处理 100 万字码规模的证明，这对于较慢节奏的塔防游戏来说已经足够了）。

游戏然后被分解为几个步骤。

• 玩家将确认地图设置并将相关信息 commit 到链上
• 游戏逻辑在 rust 代码中运行一波战斗；相关的 execution trace 可以由 zkwasm 证明，玩家提交 zk 证明到链上
• 新一波怪物来临，玩家可以选择保持之前的炮塔设置，或者再次提交新的 commit
• 玩家在每波战斗中间不能更改塔的设置，如果他们更改地图设置，他们可以再次提交新 commit

（玩家将确认地图设置并将 zkwasm 输出提交到链上）

（游戏逻辑在 rust 代码中运行一波战斗。相关的 execution trace 可以由 zkwasm 证明，玩家提交 zk 证明到链上）

Zinity：第一个允许直接从 Unity 开发可验证游戏的解决方案

对于许多游戏开发者来说，在链上开发游戏意味着他们需要学习 solidity、rust 或 cairo。这意味着他们需要停止使用他们熟悉的 C#。此外，尝试将 Unity 引擎的渲染和动画与基于 Mud/dojo 的 solidity/cairo 游戏逻辑代码统一起来，是一个非常耗时费力的过程。

我们将发布第一个使用 zk 协处理器、Unity 原生的解决方案，用于链上游戏的「zkServer」开发框架。我们称之为 Zinity。

游戏代码被解耦为：

1）核心逻辑代码（攻击，战利品箱，单位坐标等）

2）其余代码。然后，这两部分代码都从 C#编译成 wasm，核心游戏逻辑由 zkwasm runtime 运行，其余代码在普通的 C# runtime 运行。将有一个处理消息的通信协议来负责两边的通信。

zkWASM 将以二进制代码形式，见证诸如「玩家 A 在时间 X 在坐标（x,y）放置了一个炮塔」的动作。随着新的一局游戏开始，我们开始获取初始游戏状态。随着游戏的进行，zkwasm 将见证并计算更多玩家输入。当本局游戏结束时，将会生成附带哈希值的新游戏状态和相关的执行轨迹（execution trace）。

我们可以选择将整个执行轨迹（execution trace）发布到诸如 Eigenlayer/Celestia/Avail/Greenfield 之类的数据可用性层（DA layer）上。或者用户可以选择只将哈希值放在数据可用性层上，将轨迹（trace）存储在云存储中。此外，我们还会设计一个挑战期，以 fault proof 的方式，来验证游戏状态。

此外，对于重要的、玩家参与经济单位较大的游戏结果，用户还可以选择为全部游戏过程生成 zk 证明，并直接发布在 DA 层上。

最后，所有流程将被整合并作为 Unity SDK（非动画和渲染）或 CLI 工具来指导整个工具链。

我们还可以将此解决方案扩展到其他游戏引擎，如 Unity/Unreal/Godot。未来计划还包括与其他 zkVM（如 RiscZero）以及各种 DA 层（Eigenlayer/Celestia）集成。

通过这种方法，我们可以大大扩展链上游戏 / 可验证游戏开发者社区，吸引 web2 游戏开发者和各种游戏工作室。

带有 ERC-6551 的链上街机 + 塔防游戏玩法

此外，我们还在探索围绕可验证游戏的链上街机概念。例如，玩家也可以在链上提交某种塔 / 炮塔 / 障碍物的设置，另一个玩家可以提交他们选择的怪物和小兵，以尝试完成关卡。战斗结果在本地计算，只有 zk-snark 证明提交到链上，以验证游戏结果。这是为了确保通过关卡的方法，不会被广播到链上被大众可见。

ERC-6551（代币绑定账户）将使这些 PvP 对局，变成自主街机（autonomous arcade）。开设房间的玩家可以向智能合约存入奖励，而挑战者需要支付固定入场费，该费用累积到奖金池中，以奖励完成关卡的玩家。前 10 名完成关卡的玩家，可以拿走一定比例的奖金池奖励。

我们正在积极探索这个自主街机的想法，并欢迎在 twitter 上（@BladeGamesHQ）进行任何类型的讨论。在我们即将发布的文章中，我们会讨论塔防游戏的 PvP 示例。

我们即将在 ETHdenver 上展示的游戏

我们将在 ETHdenver 展示一个可验证的游戏演示。这款游戏将使用 Rust 和 React 开发，在 zkwasm 上运行。在twitter上联系我们，我们会把你加入早期试玩人员名单！

结论，和我们接下来要发布的内容

• ZK 协处理器方法提供了所需的信任假设，以及开发人员打造引人入胜的游戏体验所需的计算能力
• 对于经验丰富的游戏开发人员来说，（非常）需要 Unity/Unreal 原生解决方案，而不是必须在 Unity 中统一 Solidity/Cairo 中的核心游戏逻辑和 Unity 中的动画 / 渲染
• 链上游戏和可验证游戏的未来开发者体验，将会是高度模块化，可插拔式的（到底有多上链算上链？我们认为应该由开发者和用户决定）
• 未来，我们相信将会有弹性的方法来权衡信任假设、证明成本、开发成本来开发可验证游戏

我们的 Zinity 解决方案为 web2 和 web3 开发者，提供了开发可验证游戏的顺畅上手体验。我们相信，让开发者使用各种类型的游戏引擎，以及不同的 DA 层和 zkVM 进行开发的即插即用方法，也将提供更大的开发体验灵活性。

我们设想未来的开发者体验是这样的：Zinity 可以为可证明游戏提供「弹性」支持，并为 crypto 开发者、 Web2 游戏开发者提供可证明游戏的可插拔开发选项。

比如开发者可以用 Rust 编写核心游戏逻辑，用 C# 和 Unity 编写游戏的其余部分，并在链上 commit 执行轨迹 / 轨迹的哈希，延后生成 ZKP，这样开发成本、证明成本都会好很多。

这种弹性模型还可以帮助开发人员，在 C#和 unity 引擎内部快速测试早期游戏创意，然后继续迭代他们所希望的游戏「上链程度」（到底有多上链算上链？我们认为应该由开发者和用户决定）。同时也提前压力测试游戏设计 vs. 区块链性能的 tradeoff。

当我们开发自己的游戏，并测试各种技术栈时，我们意识到我们仍然需要经验丰富的 web2 游戏开发者尝试开发可验证游戏，以获得更好的游戏心流和 UIUX。因此，我们提出了自己的首创解决方案，并希望为更广泛的链上游戏开发者社区做出贡献。

我们已经就使用 zkwasm 和可验证游戏开发的一些话题写了很多内容，并正在进行剩余的工作。这里是一些话题：

• 修改 zkwasm 以实现可验证游戏（进行中）
• 这种方法的 DA 成本和证明成本估算（已完成）
• 可验证游戏的 modding、可互操作性和链上无许可的交互（进行中）
• 相关的可验证游戏设计思路（进行中）

感谢 Sinka、Wangyao、Will Robinson、Mohamed Fouda、LoneSCV、0xAiko、Simon Chan、Maggie Wu、James Fang、Zee 等人对本文的贡献