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

推荐阅读
2024-01-29 22:41:47
收藏
走向一个更加弹性、模块化开发全链游戏的未来。

作者: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提醒,请广大读者理性看待区块链,切实提高风险意识,警惕各类虚拟代币发行与炒作, 站内所有内容仅系市场信息或相关方观点,不构成任何形式投资建议。如发现站内内容含敏感信息,可点击“举报”,我们会及时处理。
banner
ChainCatcher 与创新者共建Web3世界