作者：Blade Research

核心作者：wangyao、0xbrawler

内容目录

• 为什么要开发可证明游戏（Provable Game）？
• Blade Games的技术架构
• 1) 基于zkwasm开发简单的塔防游戏
• 2) Zinity：首个允许直接从Unity开发可证明游戏的解决方案
• 街机游戏（arcade game）和ERC-6551应用
• 我们即将在ETHdenver展示的游戏
• 未来的发展规划与研究主题

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

太长不看版：

• 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、可互操作性和链上无许可的交互（进行中）
• 相关的可验证游戏设计思路（进行中）

如果你对开发可验证游戏、讨论zkVM在游戏中的应用感兴趣，或者有兴趣加入我们一起工作，请联系我们！