Blade Games 推出 ZK 遊戲引擎：打造去信任化遊戲

作者: Blade Research, Delphinus Lab

ZK去信任化遊戲（Trustless Game）將引導全鏈遊戲的下一波潮流。

太長不看版：

Blade Games 和 Delphinus Lab 合作打造了一個基於 WebAssembly 和 zkWASM 的去信任化zk遊戲引擎（trustless game engine）。

我們的zk遊戲引擎可以支持塔防、RPG 等低速即時遊戲類別，以及放置遊戲、卡牌/自走棋遊戲和互動小說等遊戲類型。簡單來說，我們把遊戲的邏輯放置在zkWASM內運行（一個處理計算的"zk伺服器"），每局的遊戲結果將會生成zkSNARK 證明而發布。這個遊戲引擎還支持 C++、Go、Rust 等語言，並且即將推出 C# 和 Unity 支持。

拿塔防遊戲舉個例子，對於典型的 6 分鐘長、100 波怪物的一局塔防遊戲，總共的zkSNARK證明生成時間約為 3 分鐘。這還只是初步結果，我們正在快速優化證明生成時間。 （100萬條指令的ZKP生成時間為19秒，每個怪物波是8萬條指令，每局遊戲800萬條指令，8個zkSNARK證明在雲化的計算端，生成時間是3分鐘左右）。

在基於 ZKVM 的去信任遊戲中，維護成本主要來自 ZK 證明生成、RPC/調用數據訪問服務以及鏈上驗證和結算費用。 隨著坎昆升級（EIP 4844）在 L2 上生效，運行去信任遊戲的成本已經顯著降低了。

此外，通過未來實施 zkSNARK 證明遞歸（proof recursion）以及 Nebra的證明聚合服務（proof aggregation），我們可以進一步降低 ZKP 的成本。

我們的遊戲合作夥伴包括：

Dune Factory（@BladeGamesHQ）：一款廢土朋克風格的基地建設+塔防策略遊戲

0xPioneer：類似《饑荒》的多人在線模擬生存遊戲

Craftpunk：一款以太空為主題的開放世界RPG遊戲，具有可改裝的宇宙飛船和程序生成的地圖

正文：

本ZK遊戲引擎由Blade Games和Delphinus Lab聯合開發，本篇文章由雙方聯合撰寫，旨在使更多web2遊戲開發者、全鏈遊戲開發者了解ZK遊戲引擎的優勢和開發路徑。

這是一份關於去信任化的Web3瀏覽器遊戲開發的指南。（另有內容在https://www.youtube.com/watch?v=dLZbfTWLGNI上展示，與註釋：https://delphinuslab.com/wp-content/uploads/2023/04/zksummit-presentation-zkwasm-game-1.pdf）

隨著Web3的進一步發展，全鏈遊戲再次進入我們的視野。它們聲稱在去中心化、透明度、無信任和社區治理方面更加優越。然而，全鏈遊戲也繼承了區塊鏈的去中心化、安全性、可擴展性困境------這意味著遊戲開發者在全鏈遊戲的敘事中面臨著遊戲內容、互動頻率、去中心化、無信任和社區公平性管理的難題。

因此，在上個周期，遊戲開發者在架構層面達成了一些妥協，並引入了一種被廣泛稱為Web2.5遊戲架構的實踐中的最佳架構。

更確切地說，Web2.5是一個混合了Web3和傳統遊戲的綜合術語。Web2.5強調遊戲玩法的內容，因為他們相信遊戲的主要受眾仍然根植於Web2。同時，他們在遊戲中添加了Web3的元素（NFT、經濟模型、遊戲賺取）以使他們的遊戲脫穎而出。

標準的Web2.5遊戲架構可能如下所示：

左側圖示展示了遊戲引擎對遊戲的狀態機的控制與對玩家活動做出的反應。右側圖示展示了遊戲狀態的某些部分變化，並揭示了鏈上最有價值的那些數據。

遊戲核心玩法大多在一個集中式的遊戲伺服器上運行，而最有價值的數據（NFT、代幣獎勵、記錄等）則在區塊鏈上被跟蹤。

這種架構的優勢在於，遊戲伺服器可以在處理大量用戶交易的集中模式下運行，而這些交易可以在幾秒鐘內完成。此外，集中式伺服器可以處理複雜且持續的遊戲玩法，通常在原生區塊鏈中處理這些玩法的成本太高了。

然而，在這種架構中，遊戲引擎和鏈上協議之間的通信渠道通常由簽名進行保護，因此並不是去信任的。此外，遊戲內容可能會在沒有與社區達成共識的情況下進行更改，這有時可能會損害現有玩家的既得利益（例如遊戲經濟更新、內容更新甚至獎勵制度更新）。

此外，鏈上數據很難檢查傳遞到區塊鏈的數據是否是遊戲玩法的有效結果。伺服器可以利用職務之便對玩家行為進行區別化處理（例如有傾向性地對待遊戲開發商的私人帳戶）。

由於Web2遊戲通常在其內容和遊戲玩法上表現出色，因此將平衡和公平交給遊戲提供商是可以接受的。然而，當Web2遊戲決定進入Web3生態系統時，它可能需要吸引更多關心經濟、所有權和在遊戲過程中捕獲價值的加密原生玩家。這些玩家們不僅享受通過遊戲獲得豐富結果的過程，而且希望他們在遊戲中取得的結果能夠具有一定的意義（例如"可持續性）"，甚至是增值的屬性。相對的，這種對具有"可持續性"的增值效應的期待使玩家更加認真地對待他們在遊戲中的選擇------這意味著玩家在遊戲中的思考和決策成本更高，進一步加深了他們對遊戲規則公平性和可預測性的期望。

最終，玩家將要求他們能以某種方式控制遊戲的"Web3特性"------公平和去信任化的特性不應該由運營商/遊戲開發者而是由一套寫定的代碼來執行，從而達成一個更加去中心化的、完全構建於鏈上的遊戲。

有關於此，一個簡單的措施是將上面圖示中左側的所有內容都移到右側圖示（區塊鏈）上，使架構如下所示：

顯然，這個舉措會導致遊戲玩法的許多"退化"：

1. 玩家每個行動都必須通過鏈上簽名的方式來表示他們的授權
2. 在區塊鏈上運行的遊戲引擎的規模受到限制
3. 需要支付大量gas費
4. 玩家與遊戲的交互頻率必須減少以適應區塊鏈的TPS（Transaction per Second，每秒交易數）限制

這是否意味著我們必須放棄複雜但豐富的內容以追求"全鏈哲學"呢？

在零知識虛擬機技術出現之前，答案可能是"是"。然而，基於零知識虛擬機技術現在已經被廣泛研究和應用的事實，我們有了"第三種方法"，即將完全鏈上的遊戲與去信任化計算相結合。這是如何實現的呢？

ZKVM，即零知識虛擬機，是一種將零知識證明與虛擬機技術相結合的概念。要理解它，讓我們拆解以下兩個模塊：

1. 零知識證明（ZKP）：這些是一種加密方法，允許在一方向另一方證明他們知道一個值（例如一個密鑰），同時卻不洩露關於該值的任何信息。零知識證明能夠在交易或交互中同時保護隱私和安全，因為它們可以驗證一個陳述的真實性，而不必分享實際數據。
2. 虛擬機（VM）：虛擬機是物理意義上的計算機的軟件仿真。它運行操作系統和應用程序------就像現實中的計算機，只不過完全基於軟件實現。虛擬機被廣泛使用於雲計算與在單個計算機上運行多個操作系統。

將這兩點結合起來看：零知識虛擬機（ZKVM）首先是一個虛擬機，它可以執行程序或合約，並提供零知識證明的隱私和安全優勢。這意味著我們可以在zkVM內運行遊戲引擎（或遊戲伺服器），並使用zkVM生成ZK證明，向區塊鏈證明狀態不同數據的執行結果是由遊戲邏輯強制執行的。因此，遊戲伺服器沒有辦法調整發送到底層區塊鏈的數據。

有鑑於此，全鏈遊戲的綜合架構可能如下所示：

我們這樣稱呼此類去信任化的全鏈遊戲：Trustless Game。

2. 研發Trustless Game時需要考量的因素

2.1 新手須知

遊戲開發通常被認為是一件困難的事，因為它涉及到複雜的技術、珍貴的創意和項目管理等問題。當我們將ZKVM技術應用於Trustless Game時，可能涉及到的因素如下：

技術複雜性： 在Trustless Game中，遊戲的邏輯需要與遊戲的可視化分開，並且邏輯需要是確定性的，以便ZKVM生成一個證明。此外，由於證明是在需要被執行的語言段上生成的，遊戲開發者需要將遊戲玩法分成執行段，並定期與鏈上合約同步執行。

藝術和設計： 一般而言，藝術家和設計師們的工作在Trustless Game與其他遊戲中並無不同，因為他們的工作內容不屬於需要被證明的邏輯。在Trustless Game中，可視化開發需要基於遊戲的全局狀態，而UI/UX也被用作收集玩家活動的工具。

整體的遊戲體驗： 與一般意義上的全鏈遊戲不同，玩家不必在每次移動時簽署鏈上行為，這增強了創建"頻繁互動型遊戲"的可能性------它們指那些需要或鼓勵玩家頻繁地進行互動的遊戲。

然而，受到ZKVM證明生成時間的限制，高頻率互動對於在ZKVM中運行的Trustless Game遊戲仍然是不可行的，例如RTS（即時戰略遊戲）和MOBA（例如DOTA）、在這些遊戲裡，玩家必須持續對單位和資源進行操作並調整策略以擊敗對手，這種類型的遊戲很難基於ZKVM被開發。

相對的，在模擬類遊戲和放置/農場類遊戲中，玩家需要定期 調配資源、參與市場行為或操作角色以實現在遊戲中的成長------此類遊戲體裁就非常適合Trustless Game。

此外，互動式故事遊戲和視覺小說也是個不錯的選擇。此類遊戲可能不需要持續的互動，但它們通過不斷出現的決策點來吸引玩家、塑造故事並鼓勵頻繁互動以查看玩家們的選擇所導致的結果。

下面，讓我們來聊聊貨幣化和可持續性。

一般而言，遊戲的內容會隨著時間的推移而發展，以此吸引新玩家並留住老玩家。這使得遊戲玩法的邏輯變得動態，從而影響了在ZKVM中運行的程序------由此帶來的一個結果是驗證合約可能會更改並需要更新。

有以下兩種方法可以避免頻繁更改需要ZK驗證的合約：

• 遊戲玩法的變更：為遊戲玩法抽象出一個協議層，並將遊戲的這些動態特性定義為規則。如此，開發者們就可以將這些規則集存儲在鏈上，並將這些規則提交到一個鏈上哈希中。同時，當遊戲引擎運行遊戲邏輯時，它可以首先檢查當前規則集的哈希是否與承諾匹配，然後相應地行事。
• 結算的變更：獎勵系統可以作為遊戲玩法本身的獨立層。我們可以將所有的獎勵算法視為遊戲玩法中生成的某些事件的回調。通過這樣做，我們可以將獎勵回調放在鏈上，並根據遊戲事件調用這些回調。

例如，我們有以下遊戲循環：

zkgame {

// Game logic

output(events)

}

它生成的事件將成為執行的證明實例。因此，我們可以將callbacks添加到合約中：

function verify(

bytes calldata events_data,

uint256[] calldata proof,

uint256[] calldata verify_instance,

uint256[] calldata aux,

uint256[][] calldata instances,

RidInfo calldata ridInfo

) public {

…

// Check the events_data pins to a has in the instances

require(instances.eventshash = hash(eventsdata))

// Performs the zk verification

verifier.verify(proof, verify_instance, aux, instances);

// Call the callbacks to handle the rewarding logic for events

uint256 sideEffectCalled = performtxs(eventsdata, ridInfo.batch_size);

…

}

2.2 遊戲運行邏輯應該放在哪裡？

遊戲邏輯主要在兩個地方運行：前端或伺服器端。

將遊戲邏輯放在前端相對於客戶端-伺服器（Client-Server）結構簡化了遊戲的架構。這種方法允許前端模擬遊戲並在執行軌跡建立後生成零知識證明（zk-proof）。隨後，它使用本地zk-prover或遠程證明服務為零知識虛擬機（ZKVM）生成ZK證明。然後，將該證明上傳到底層區塊鏈以觸發結算合約。

相對的，將遊戲邏輯放在伺服器端意味著把遊戲模擬和用戶之間的交互轉移到一個更專用的組件（遊戲伺服器）中。這可以在以下方面改善整體遊戲體驗：

• 同步效果更好的遊戲玩法：伺服器端模擬確保所有玩家以盡可能同步的方式體驗遊戲。對於多人遊戲來說，連接的所有客戶端上的一致遊戲狀態對於一致和有競爭性的遊戲體驗至關重要。
• 更好的資源管理：前端可以專注於內容渲染和UI/UX，而伺服器可以充當集中式的順序控制器和默克爾樹存儲的提供者。

對於不需要歷史數據並且具有較簡單順序邏輯的單人PVE遊戲（或多人PVP遊戲），將所有內容放在前端是一個不錯的選擇。對於像多人SLG（模擬遊戲）或AW（自治世界）遊戲這樣複雜的遊戲，伺服器端遊戲的表現更好。

2.3 選擇遊戲開發架構

由於我們將傳統遊戲開發與ZKVM相結合，我們需要仔細考慮工具選擇。

1. 開發語言

首先我們需要決定是使用傳統編程語言如C＃、Rust、C、C ++、Go來開發遊戲，還是要使用特定於ZKVM的語言。

傳統編程語言的後端字節碼通常是MIPS、WASM、RISC-V、x86。由於沒有多少ZKVM支持這些字節碼，如果你的程序可以編譯成RISC-V字節碼，則可以選擇Risc0作為底層ZKVM，如果它可以編譯為WASM，則可以選擇zkWASM作為底層ZKVM。

WebAssembly（WASM）是一種低級字節碼格式，用作高級語言（如C、C ++、Rust等）的編譯目標。它旨在使使用這些語言編寫的代碼在網絡上以接近本機的速度運行。WebAssembly提供了一種在Web瀏覽器中運行性能關鍵代碼的方式，而不會犧牲Web應用程序的安全性或速度。它是現代Web技術堆棧的關鍵部分，通過允許開發人員利用除JavaScript之外的其他語言進行Web開發，從而補充了JavaScript。

1. 遊戲引擎

一旦選擇了編程語言，我們可以根據選擇的語言選擇基於該語言的遊戲引擎。如果選擇了特定於ZKVM的語言，則可能需要創建自己的遊戲開發框架，因為可能不存在成熟的框架用於該語言。如果使用的是rust、C、typescript等語言，則有很多框架可供選擇，其中我們推薦Unity和Cocos2D。

1. 證明生成成本

通常，證明成本是以100萬條指令的證明時間來衡量的。因此，它取決於遊戲玩法的執行軌跡（每個遊戲玩法交互的指令數量）、後端字節碼的字長以及ZKVM的證明性能。對於簡單的指令集，有一些ZKVM可以在幾秒鐘內生成100萬條指令的證明（Miden：https://0xpolygonmiden.github.io/miden-base/）。對於複雜的指令集（RISCV 32位、WASM 64位），ZKVM可以在GPU中在12秒內生成100萬條指令的證明（Risc0 https://www.risczero.com/）到大約30秒（zkWASM https://github.com/DelphinusLab/zkWasm）的證明。

3. 在ZKWASM中為全鏈遊戲使用MVC（模型-視圖-控制器）模式

3.1 MVC（模型-視圖-控制器）模式簡介

模型-視圖-控制器（MVC）模式雖然一般與Web/企業應用程序開發相關聯，也可以應用於遊戲開發------儘管需要一些調整。以下是MVC組件在遊戲開發環境中的運行方式：

模型（Model）：

在遊戲開發中，模型代表遊戲的數據和邏輯。這包括遊戲狀態（如分數、級別和玩家統計）、遊戲對象以及管理遊戲世界的規則。模型負責管理遊戲的數據和狀態，通常它不知道這些數據將如何呈現或顯示。

視圖（View）：

在遊戲開發中，視圖負責向玩家展示遊戲狀態。這涉及到渲染遊戲圖形、播放聲音以及顯示諸如分數、生命條和菜單等UI元素。視圖觀察模型並更新遊戲世界的視覺和聽覺表示以向玩家展示。在許多遊戲引擎中，視圖可能被封裝在渲染引擎和UI系統中。

控制器（Controller）：

控制器解釋來自鍵盤、鼠標、遊戲手柄或其他輸入設備的用戶輸入，並將其轉換為遊戲內的動作。例如，當玩家按下按鈕使角色跳躍時，控制器會處理此輸入並將動作傳達給模型。遊戲中的控制器充當輸入設備和遊戲邏輯之間的中介。

在遊戲開發中應用MVC具有以下的顯著優點：

• 關注點分離：MVC可以幫助組織代碼，並將遊戲邏輯與用戶界面分離，這可以使開發過程更易管理，代碼更易維護。
• 靈活性：MVC允許為相同的模型創建不同的視圖。這對於提供多個視角或需要支持各種顯示模式的遊戲非常有用。
• ZK友好：通過將遊戲邏輯與表示分離，模型是唯一無法去信任化地執行的部分。通過將模型放入ZKWASM中，核心遊戲機制在遊戲運行時自然會得到證明。

3.2 在ZKWASM中設置遊戲引擎

假設控制器與模型連接，並具有一組模型處理程序。接下來，我們可以為控制器和處理程序添加一個命令編碼/解碼層，如下所示：

struct GlobalState {

… // Define your game state here

}

enum ControllerTag {

A,

B,

C

}

/// The controller in MVC

fn controller_A (c) {

let handler_cmd = encode(A, c);

model.handle(handler_cmd)

}

fn controller_B (c) {

let handler_cmd = encode(B, c);

model.handle(handler_cmd)

}

fn controller_C (c) {

let handler_cmd = encode(C, c);

model.handle(handler_cmd)

}

/// The model in MVC

fn handler(command) {

match command {

A => {},

B => {},

C => {},

}

}

/// View

fn render(global_state: GlobalState) {

// display your game UI based on global state

}

3.3 生成一份遊戲玩法證明

我們可以將遊戲玩法的一部分視為對處理程序的一系列控制器的調用。因此，遊戲玩法的去信任化ZK證明是以下代碼：

fn execution(cs: Vec\<command>) {

for command in cs {

global_state = handler(command);

}

}

在遊戲過程中，我們很難確定控制器發送的最後一個命令，並且很難將所有命令處理放入單個ZK證明中。因此，最佳做法是將命令拆分為多個部分並對它們進行證明，然後將它們批處理在一起生成單個證明，以便在鏈上進行進一步驗證。

註：請注意，上述方法中存在兩個缺失的部分：

1. 如何確保每個執行段之間的狀態連續
2. 當來自不同遊戲客戶端的控制器相互干擾時，如何處理多玩家同時出現的場景

在接下來的章節中，我們會簡要介紹多玩家序列化和數據可訪問性。由於每個主題都可以深入探討，我們計劃在其他單獨的筆記中提供更詳細的內容。

4. 在多人遊戲中序列化用戶交互行為

在模塊化區塊鏈的語境中，序列化器是負責在交互最終確認之前對其進行排序的組件或節點。模塊化區塊鏈架構將區塊鏈功能的不同層次（例如執行、共識和數據可用性）分離為不同的組件。這種方法旨在通過允許每個層獨立優化來提高可擴展性、安全性和效率。

在開發多玩家遊戲時，我們也需要一個組件來幫助對不同用戶之間的交互進行排序。因此，我們二次使用了模塊化區塊鏈中的序列化術語。

由於遊戲需要較低的延遲，最好選擇一個產生快速排序結果的集中式序列化器。遊戲引擎也可以與序列化器緊密配合，同時獲取排序後的交易。

單個玩家交互協議

在這裡（見下圖），我們從玩家角度描述了一個交互協議。在用戶交易中，用戶描述了他的輸入，並通過公共輸入和見證輸入證明了自己的身份，這些輸入可以具有以下佈局：

公共輸入與見證輸入：

交互處理邏輯：

pub fn zkmain() -> i64 {

let mut hasher = Sha256::new();

// get the command length

let commandslen = unsafe {wasminput(0)};

// processing all commands and

// hash the commands for furture signature verification

for _ in 0..commands_len {

let command = unsafe {wasm_input(0)};

hasher.update(command.tolebytes());

step(command);

}

let msghash = hasher.finalize();

let pk = unsafe {BabyJubjubPoint {

x: U256([

wasm_input(0),

wasm_input(0),

wasm_input(0),

wasm_input(0),

]),

y: U256([

wasm_input(0),

wasm_input(0),

wasm_input(0),

wasm_input(0),

]),

}};

zkwasmrustsdk::dbg!("process sig\n");

let sig = unsafe {JubjubSignature {

sig_r: BabyJubjubPoint {

x: U256([

wasm_input(0),

wasm_input(0),

wasm_input(0),

wasm_input(0),

]),

y: U256([

wasm_input(0),

wasm_input(0),

wasm_input(0),

wasm_input(0),

]),

},

sig_s: [

wasm_input(0),

wasm_input(0),

wasm_input(0),

wasm_input(0),

]

}};

let msghash_u64 = [

u64::frombebytes(msghash[24..32].try_into().unwrap()),

u64::frombebytes(msghash[16..24].try_into().unwrap()),

u64::frombebytes(msghash[8..16].try_into().unwrap()),

u64::frombebytes(msghash[0..8].try_into().unwrap()),

];

sig.verify(\&pk, \&msghash_u64);

5. 成本分析

5.1 成本概覽

在基於ZKVM的去信任化全鏈遊戲中，主要的維護成本來自於ZK證明生成、快速數據RPC服務、調用數據訪問服務以及鏈上驗證和結算費用。隨著坎昆升級（EIP 4844）在 L2 上生效，運行去信任遊戲的成本已經顯著降低了。此外，通過未來實施 zkSNARK 證明遞歸（proof recursion）以及 Nebra 的證明聚合服務（proof aggregation），我們可以進一步降低 ZKP 的成本。

5.2 ZK證明生成成本

首先，ZKVM運行應用程序並生成執行軌跡（execution trace）。這個軌跡是較為基礎的，因為ZKVM需要證明：

1. 該軌跡強制執行了由ZKVM支持的字節碼的語義
2. 通常，ZKVM本身是無狀態（stateless）的。為了支持遊戲的有狀態存儲（stateful storage），它們利用了將數據設置和獲取轉換為Merkle證明的想法
3. ZKVM通常將執行軌跡分成多個段，並為它們分別生成證明。這些證明將被批處理在一起，最終生成一個可驗證的單一證明

假設我們使用的ZKVM使用預編譯指令作為系統調用（或ZKWASM中的主機API）來處理Merkle證明。生成ZK證明的整體成本如下：

證明成本 = ZKVMGuest證明成本 + Merkle證明成本 + 批處理證明成本（ BatchProofCost ）

通常，等式右邊的第一和第三項不會引入額外的成本，除了純ZK證明。然而，第二項的成本有一些微妙，因為它需要一些數據存儲服務的支持。

讓我們回顧一下Merkle證明的組成部分：

• Merkle樹的設置

我們將全局數據抽象成塊，並單獨對它們進行哈希處理。這些哈希成為目標樹的葉節點。然後，將葉節點的對進行哈希處理以形成下一级節點，並重複此過程直到頂部只有一個哈希為止，稱為Merkle根。Merkle根是樹中所有數據塊的唯一表示。

• 數據包含證明

該證明由問題中的特定數據塊、其哈希以及來自Merkle樹的少量額外哈希組成。這些額外的哈希是使驗證器能夠獨立計算數據集的Merkle根所必需的最小值。

• 驗證證明：

驗證者知道數據集的Merkle根但不一定知道其中所有數據的驗證器，他使用提供的數據塊和額外的哈希來重建到Merkle根的哈希路徑。如果計算出的Merkle根與已知的Merkle根匹配，則證明有效，確認該數據塊確實是數據集的一部分，且未被篡改。

要維護一個具有狀態的ZK遊戲，需要一個Merkle數據數據庫來跟蹤Merkle樹的樹葉，並提供快速的數據查詢服務。這種服務不太可能完全托管在鏈上，因為數據的修改頻率非常高，訪問（讀取/寫入）需求也很高。

一旦交易完成，調用數據和最終狀態（由新的Merkle樹根表示）需要是可訪問的。這通常通過DA層或鏈上txdata存儲來實現。

5.3 數據成本

根據Blade Games的分析並參考ZKWASM、Eth Storage、BNB Greenfield DA存儲成本計算器（https://dcellar.io/pricing-calculator）和谷歌雲存儲計算器（https://cloud.google.com/products/calculator），我們可以得出以下結論：使用zk協處理器方法運行一個擁有5,000個玩家（假設他們一刻不停的玩，這樣的日活用戶其實要比5000高很多）的鏈上遊戲，預計每月成本約為90,000美元，這個成本類似與運行一個高防，反DDOS的MMORPG遊戲伺服器成本類似。

Blade Games的估算方法如下：他們將Unity中發布的用戶事件轉換為二進制代碼，並在ZKWASM內運行（ZKWASM是由Delphinuslab開發的支持WASM字節碼的ZKVM）。然後，ZKWASM將生成執行軌跡，並將壓縮的軌跡發布到DA層，與此同時，他們將在鏈上發布軌跡哈希，並用數字簽名進行不可變性驗證。

根據ETHstorage和zkwasm的測試運行，運行1秒鐘的wasm二進制文件將生成100萬行軌跡，每行大小為40字節。

我們可以選擇在鏈上證明所有的軌跡，或者只保存軌跡，如果用戶選擇挑戰結果，則進行證明。

• 證明所有軌跡的ZK方法

如果我們選擇證明所有的軌跡，那麼100萬字節碼大約需要在單個RTX4090圖形卡上花費25秒，成本可能是0.5美分（成本為每美元的2000M指令）。在這種解決方案中，成本主要來自證明能力費用、鏈上驗證費用以及DA的調用數據存儲費用。使用這種方法來支持一個每小時有1000億條軌跡的多人遊戲，將每小時花費約50美元（每月36,000美元）作為證明成本。

• 欺詐證明方法

假設一共有5000名玩家，他們平均每人連續遊戲2小時，且每個玩家每小時產生86.4萬億條軌跡。因此，每天消耗的存儲量為60秒 * 60分鐘 * 2小時 * 5000名玩家 * 100萬字節碼 = 36,000,000,000,000條軌跡。根據ETHstorage和zkwasm的測試，每條軌跡消耗的存儲空間為40字節。因此，對於一個有5,000名玩家的遊戲（平均在線時間為2小時），它每天將消耗1,440TB的存儲空間。

如果以合理的比率10倍壓縮軌跡，那麼每天我們將消耗144TB的谷歌雲存儲空間，這相當於一個月的4,320TB，成本估計為90,120美元/月（在歸檔存儲層，標準存儲層允許更高的數據訪問頻率，成本將為每月185,000美元）。此外，每GB在BNB Greenfield上存儲簽名數據的月成本為0.0001 BNB，約合0.03美元。在這種方法中，觀察節點可以檢查軌跡的一致性，並觸發ZKFraud證明來報告不誠實的交易。

基於上述討論，我們可以得出結論：運行一款大玩家量級遊戲的總成本，與運行一個高防反DDOS的MMORPG遊戲伺服器成本類似。

6. 內容升級和模塊協議

一個成功的遊戲通常具有動態的遊戲內容，因此需要定期更新其引擎。這似乎與加密原生社區中流行的"代碼即法律"的理念相矛盾。

然而，這個挑戰有潛在的解決方案。

通過採用一種設計模式，將可維護的規則放在區塊鏈上，可以確保對遊戲玩法的升級或修改符合這些基本規則。鑑於在遊戲架構語境下這個主題的複雜性，我們使用以下圖表進行簡明的解釋：

7. 結論

隨著zkVM和相關基礎設施的出現，全鏈遊戲開發者可以兼顧複雜但豐富的內容，以及"全鏈哲學"。我們認為此類"去信任化遊戲"，將會有廣闊的市場前景和空間。

結合zkVM和模塊化的執行層概念，遊戲的市場策略（GTM）也會變得異常靈活，想像一下遊戲玩家同時可以與Eigenlayer, zkWASM, Berachain等熱門項目互動，獲得空投，同時還可以獲得遊戲內本身的收益，這將會給遊戲的早期冷啟動帶來巨大的幫助。

對於讀者"開發成本是不是依然很高"的疑問：我們認為在基於 ZKVM 的去信任遊戲中，隨著坎昆升級（EIP 4844）在 L2 上生效，遞歸證明、證明聚合的應用，以及本身的zkVM的優化，運行去信任遊戲的成本已經顯著降低了。如果你感興趣開發Trustless Game，請在twitter（bladegamesHQ）上dm我們，我們會提供相應的遊戲開發、代碼、GTM的幫助。

如果你感興趣開發Trustless Game，請在twitter（bladegamesHQ）上dm我們，我們會提供相應的遊戲開發、代碼、GTM的幫助。