3.2 AW Engine

AW Engine 是針對遊戲的實時性和連貫性，而設計的區塊鏈縱向的擴容方案。

3.2.1 AW 運行方式

近年來，遊戲行業正在迅速變化，基於區塊鏈的 Web3 遊戲有望帶來新的商業模式，但傳統遊戲完全擁抱web3仍然面臨很多挑戰：

1. 吞吐量：很多的遊戲需要的快速操作，並且連貫無干擾，這與區塊鏈形成了強烈的衝突。一些快節奏的射擊遊戲，其動作以毫秒為單位，然後目前最快的區塊鏈也需要2s一個區塊，這就意味著遊戲中的每一步，都需要至少等待 2s。因此，在鏈上構建快節奏的遊戲是不可行的。

2. 可擴展性：遊戲可以支持多少玩家，而不會使區塊鏈擁堵並導致 Gas 價格飛漲。如果玩家的每一個動作都要上鏈，那麼區塊鏈將非常擁堵。

為了解決這個問題，我們開發了一套 AW Engine，其通過零知識證明將遊戲中的操作進行打包，一次性上傳到鏈上並進行驗證，這意味著玩家可以在與區塊鏈互動之前進行更多的動作並玩更長的時間，從而減少主區塊鏈上的交易成本和擁塞。例如，在回合制遊戲中，玩家可以進行多次動作，允許多次動作生成證明。正式來說，我們有：

驗證此類迭代計算的最直接方法是將 n 個動作放入單獨的電路中，然後使用 SNARK 來完成證明，從而顯著增加可放置在單個事務中的動作數量。這為更多類型的遊戲開發為完全鏈上遊戲提供了可能性。這裡，我們以單人遊戲和多人遊戲為例。

單人遊戲：以2048、淘汰賽等遊戲為例，如果將玩家的詳細動作和淘汰邏輯全部上傳到鏈上，將會消耗大量的gas和鏈的資源。通過使用 ZKP 壓縮這些流程，我們只將必要的信息和證明傳輸到鏈上。這種方式可以將gas成本和交易數量降低100倍以上。

我們會提供這類回合壓縮的電路和必要的智能合約，讓開發者能夠在不撰寫電路的情形下，只需完成必要的遊戲經濟邏輯和前端包裝，就可以打造遊戲。

多人遊戲：以下是一個 Trading Card Game (TCG) 遊戲全部都用到的範例。

要參加 TCG（集換式卡牌遊戲），玩家需要使用matchmaking來尋找對手。遊戲開始後，雙方的牌都使用ZK Shuffle進行洗牌。然後，每一輪都會利用 ZK Shuffle 的翻牌功能。此外，我們使用Data Rollup將每輪的詳細信息壓縮到一個交易內。這種方法實現了一個完全鏈上的TCG，交互和交易費用都很低。

3.2.2 Slow-paced ZK 遊戲

對於像上面討論的2048遊戲這樣的Slow-paced遊戲，我們提供了兩種基於零知識證明的方案。

2. SNARK：眾所周知為 ZKP 設計約束系統是一項艱巨的任務，只能由熟練的開發人員完成，並且很難確保約束系統沒有錯誤，這是限制零知識證明的開發和使用的因素之一，但是我們提供遊戲電路開發中使用的各種小工具，包括基本算術電路、哈希，ecc, zkshuffle, zkmatchmaking等，大大降低了開發全鏈遊戲的入門門檻。

3. ZKVM： 我們提供通用的zkvm去編寫遊戲邏輯，例如RISC Zero，RISC Zero是一種專為RISC-V架構設計的通用零知識證明系統，允許開發人員使用 Rust 和 C++ 等成熟語言構建 ZK 應用程序。這意味著RISC Zero 能夠支持使用現有的 Web2 編程語言編寫的應用程序，無需構建plonk相關電路，也無需使用DSL語言進行編寫。

目前，Bonsai 允許用戶為其 zkVM 應用程序遠程生成證明，而無需使用自己的硬件來生成證明。然而，使用 Bonsai 並不能保護用戶隱私。同樣，對於 zkSNARK，我們還需要一個遠程證明者，將客戶端證明計算委託給一組不可信的伺服器，以更快地生成證明並保護用戶隱私。現有的解決方案結合 MPC 協議來構建具有多伺服器協作的 zkSNARK 證明。根據【28】，椭圓曲線和域上的點可以直接加密共享，並且MPC技術可以應用於這些共享。當前使用的主要方法是打包加密共享。

因此，使用打包加密共享及其屬性很容易為相應的 zkSNARK 證明者實現高效的 MPC 協議。

3.2.3 Z4 引擎

AW 引擎, 既可以用來解決單人的鏈下遊戲，也可以推進到支持快節奏的多人在線實時遊戲。為了管理多人在線環境的複雜性，我們設計了一套 Z4 引擎。簡單概括就是遊戲會在第三方的節點上進行，遊戲結束後，第三方節點提供遊戲過程的 zk 證明，用於驗證遊戲的結果。第三方節點需要 staking，才可以在公開的 room market 上進行 accept game，類似於賞金獵人。

Z4 引擎配備了幾個模塊:鏈交互模塊、鏈上事件監聽模塊、HTTP和P2P網絡啟動模塊、具有零知識證明模塊的證明器、遊戲邏輯接口。 基於對模塊的整合，開發者只需要定義遊戲邏輯，就可以運行完整的專屬自己遊戲的 z4 節點。

Z4 引擎架構圖

在Z4引擎工作流中, 玩家在鏈上進行遊戲房間的創建，一旦其他玩家看到這個房間，他們可以選擇加入，當房間滿員或者房主主動點擊開始後，房間會處於 ready 狀態，房間也會出現在賞金獵人的 acceptable 列表中，促使他們搶奪該房間。，第一個搶奪成功的 z4 節點，成為這局遊戲的 provider。該房間內的玩家通過監聽鏈上動態，觀測到房間的 provider，並根據合約中 provider 的地址進行本地網絡連接，這種連接包括 HTTP 與 P2P 的雙重連接，以確保網絡的穩定性和兼容性。。當網絡中不存在任何 Z4 節點的時候，任意玩家都可以充當 provider，而且無需提供對外的可訪問的HTTP地址，可以通過P2P來實現快速啟動和點對點連接。遊戲結束後，provider 會將遊戲的過程進行 zk 證明，將遊戲結果和 zkp 一起提交上鏈，驗證通過後，房間狀態更新為 over。

遊戲的 zk 證明電路同樣可以採取PLONK進行定制，或者使用ZKVM或DSL進行編寫，形成自己遊戲特定的 z4 節點。鑑於 zk 的學習曲線和電路的編寫難度，我們提供了一套將 Z4 和 Risc Zero 深度整合的通用遊戲運行平台。這個通用的 Z4-RISC0 節點運行 RISC-VM 沙盒環境，遊戲開發者只需定義遊戲邏輯並將其作為 Z4-RISC0 節點提交到鏈上。該通用節點可以運行任意基於RISC-VM框架下開發的遊戲，在遊戲結束後，自動進行遊戲的 zk 證明。並且通過整合 bonsai proof market，達到快速證明的目標，提高了鏈上遊戲驗證的效率和可靠性。

涉及大規模的操作的遊戲，會導致證明時間過長，為了進一步提高遊戲的證明效率，我們同時提供了一套基於Thresh-old ECDSA的證明解決方案。玩家在遊戲結束後，對遊戲結果進行簽名，一旦達到 n-m 簽名的閾值，就可以判斷遊戲結果的有效性。該方案有效緩解了 zkp 生成和驗證時間過長的問題，同時它還為一些無法進行 zk 證明的環節，提供了一套可行的證明方式，比如射擊類遊戲中，誰的操作率先被 Z4 節點處理，誰的擊殺可能性更高，而時間是無法被寫在ZK 電路中，因此，需要借助這種社會化共識，作為遊戲可驗證的途徑。以下是 ZK 證明和 Threshold ECDSA 簽名之間的比較：

上表表明，雖然zk證明為更簡單，確定性的遊戲事件提供了高水平的安全性和不可否認性，但Threshold ECDSA為複雜和實時場景提供了更快，更具可擴展性的解決方案，依靠社區共識來解決zk證明無法有效處理的方面。

參考文獻 ：

【28】Ozdemir A, Boneh D. Experimenting with collaborative zk-SNARKs:ZeroKnowledge proofs for distributed secrets[C]//31st USENIX Security Symposium (USENIX Security 22). 2022: 4291-4308.