全链游戏新篇章:用 ZKWASM 开发可证明游戏

Recommended Reading
2024-01-29 22:41:47
Collection
走向一个更加弹性、模块化开发全链游戏的未来。

作者:Blade Research

 

内容目录

为什么要开发可证明游戏(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等人对本文的贡献

核心作者: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、可互操作性和链上无许可的交互(进行中)
相关的可验证游戏设计思路(进行中)
如果你对开发可验证游戏、讨论zkVM在游戏中的应用感兴趣,或者有兴趣加入我们一起工作,请联系我们!

ChainCatcher reminds readers to view blockchain rationally, enhance risk awareness, and be cautious of various virtual token issuances and speculations. All content on this site is solely market information or related party opinions, and does not constitute any form of investment advice. If you find sensitive information in the content, please click "Report", and we will handle it promptly.
ChainCatcher Building the Web3 world with innovators