作者：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在遊戲中的應用感興趣，或者有興趣加入我們一起工作，請聯繫我們！