A New Chapter for On-Chain Gaming: Building Provable Games with zkWASM
TechFlow Selected TechFlow Selected
A New Chapter for On-Chain Gaming: Building Provable Games with zkWASM
If all game logic is placed on-chain, the limited computational capacity of the EVM itself will become the biggest bottleneck for game development.
Navigating Web3 tides with focused insightsAuthor: Blade Research
Core Authors: wangyao, 0xbrawler
Table of Contents
- Why develop provable games?
- Blade Games' technical architecture
- 1) Building a simple tower defense game using zkwasm
- 2) Zinity: The first solution enabling direct development of provable games from Unity
- Arcade games and ERC-6551 applications
- The game we'll showcase at ETHDenver
- Future roadmap and research topics
Special thanks to Sinka, Wangyao, Will Robinson, Mohamed Fouda, LoneSCV, 0xAiko, Simon Chan, Maggie Wu, James Fang, Zee, and others for their contributions to this article.
TL;DR:
- ZK coprocessor approach provides both the trust assumptions required for verifiable games and the computational power needed to create engaging gameplay experiences
- Experienced game developers critically need native Unity/Unreal solutions rather than having to synchronize core game logic in Solidity/Cairo with animations/rendering in Unity
- The future developer experience for on-chain and verifiable games will be highly modular and pluggable (How much should actually be on-chain? We believe this should be decided by developers and users)
- We believe there will be flexible methods to trade off trust assumptions, proof costs, and development costs, enabling cost-effective development of verifiable games
Why Develop Provable Games?
2023 was a year of flourishing growth for fully on-chain games (FOCG) and autonomous worlds (AW), with numerous infrastructure projects emerging. These include MUD.dev, Dojo, World Engine, Keystone, Paima, among others. Additionally, rollup service providers such as AltLayer, Caldera, and Conduit have attracted many full-chain game developers.
However, through developing and operating our first on-chain battle royale game Loot Royale—achieving 600–800 daily active users within a month—we identified a critical issue:
If all game logic is placed entirely on-chain, the limited computational capacity of the EVM becomes the biggest bottleneck for game development.
Limited computation restricts game genres (primarily low-computation, single-threaded, asynchronous games) and degrades user experience (users must wait for transaction confirmation, RPC hydration, etc.).
Here are some real examples. We received frequent feedback like "I wish my transaction could be packed in time so that attack would've landed" and "When will the RPC data finish loading?" This needs to change.
Players are really anxious waiting for RPC hydration
After experimenting with various tech stacks, we believe that if computations can be proven off-chain, their credibility can approach that of fully on-chain transactions/computations. We address the EVM's computational limitations by adopting the principle of "off-chain execution, on-chain verification." This approach offers several advantages:
- Improved user experience with reduced waiting times
- Expanded game categories, including more computationally intensive "mid-core" games like tower defense
- Support for hidden information mechanics in games
We'll first briefly introduce how we use zkWASM to develop provable games. Then we'll discuss our zkwasm-unity solution—the industry's first solution enabling direct development of provable games from Unity.
Blade Games' Technical Architecture
Building Simple Tower Defense Games with zkWASM
Our technical architecture consists of two parts. The first part involves writing simple PvE and PvP tower defense games in Rust and verifying them via zkWASM.
The second part is our roadmap: we plan to develop a compiler that compiles C# into WASM and make appropriate modifications to the existing zkWASM architecture, creating a more modular and flexible framework for developing provable games. (zkWASM, developed by Delphinus Labs, is a zkVM that runs WASM code and generates zkSNARK proofs of its execution trace.)
Let's start with the PvE example—we write the game using Rust and the Bevy Engine.
Rust can easily compile to WASM, generating a WASM image before processing within the zkWASM VM. We can then choose to publish the processed execution trace to a Data Availability Layer (DA Layer) and prove it later, or users can opt to generate the proof immediately and send the zkSNARK proof on-chain (a single RTX 4090 GPU takes about 45 seconds to generate a proof for 1 million opcodes, which is sufficient for slower-paced tower defense games).
The game is broken down into several steps:
- Players confirm map settings and commit relevant information on-chain
- Game logic runs one wave of combat in Rust code; the corresponding execution trace can be proven by zkWASM, and players submit zk proofs on-chain
- A new wave of monsters arrives; players can keep previous turret configurations or submit new commits
- Players cannot change tower setups during combat waves; if they modify map settings, they can submit a new commit
(Players confirm map settings and submit zkWASM output on-chain)
(Game logic runs one wave of combat in Rust code. The corresponding execution trace can be proven by zkWASM, and players submit zk proofs on-chain)
Zinity: The First Solution Enabling Direct Development of Verifiable Games from Unity
For many game developers, building on-chain games means learning Solidity, Rust, or Cairo—forcing them to abandon their familiar C#. Moreover, attempting to unify Unity engine rendering and animations with game logic written in Solidity/Cairo based on frameworks like MUD/Dojo is an extremely time-consuming and labor-intensive process.
We are releasing the first Unity-native solution using a zk coprocessor for developing "zkServer" frameworks for on-chain games. We call it Zinity.
Game code is decoupled into:
1) Core logic code (attacks, loot boxes, unit coordinates, etc.)
2) All other code. Both parts are compiled from C# into WASM. The core game logic runs in the zkWASM runtime, while the rest runs in a standard C# runtime. A messaging protocol handles communication between both sides.
zkWASM will witness actions in binary form, such as "Player A placed a turret at coordinates (x,y) at time X." At the beginning of a new game, we obtain the initial game state. As the game progresses, zkWASM witnesses and computes additional player inputs. When the game ends, a new game state with its hash and corresponding execution trace is generated.
We can choose to publish the entire execution trace to a data availability layer (DA layer) such as Eigenlayer, Celestia, Avail, or Greenfield. Alternatively, users may choose to store only the hash on the DA layer and keep the trace in cloud storage. Additionally, we'll design a challenge period using fault proofs to validate game states.
Furthermore, for high-stakes games involving significant economic participation, users can choose to generate full zk proofs for the entire gameplay and publish them directly on the DA layer.
Finally, all processes will be integrated into a Unity SDK (excluding animation and rendering) or CLI tool to guide the entire toolchain.
We can extend this solution to other game engines such as Unity, Unreal, and Godot. Future plans also include integration with other zkVMs (e.g., RiscZero) and various DA layers (Eigenlayer, Celestia).
With this approach, we can significantly expand the on-chain/verifiable game developer community, attracting Web2 game developers and studios.
On-Chain Arcade + Tower Defense Gameplay with ERC-6551
Additionally, we're exploring the concept of on-chain arcades around verifiable games. For instance, players can submit specific tower/turret/obstacle configurations on-chain, while another player submits their chosen monsters and minions to attempt completing the level. Battle results are computed locally, and only zk-SNARK proofs are submitted on-chain to verify outcomes—ensuring that successful strategies aren't broadcast publicly.
ERC-6551 (token-bound accounts) will transform these PvP matches into autonomous arcades. The room creator deposits rewards into a smart contract, challengers pay a fixed entry fee that accumulates into a prize pool, and players who complete the level receive portions of the reward. The first 10 players to complete the level can claim a share of the prize pool.
We're actively exploring this autonomous arcade concept and welcome any discussions on Twitter (@BladeGamesHQ). In our upcoming articles, we'll dive deeper into PvP tower defense examples.
The Game We'll Showcase at ETHDenver
We'll demonstrate a verifiable game at ETHDenver. This game will be built using Rust and React and run on zkWASM. Contact us on Twitter, and we'll add you to our early access list!
Conclusion and What's Coming Next
- The ZK coprocessor approach delivers the necessary trust assumptions and computational power developers need to build compelling gaming experiences
- For experienced game developers, native Unity/Unreal solutions are (critically) needed instead of having to synchronize core game logic in Solidity/Cairo with animations/rendering in Unity
- The future of on-chain and verifiable games will feature highly modular, plug-and-play developer experiences (How much should be on-chain? We believe this should be determined by developers and users)
- We believe flexible methods will emerge to balance trust assumptions, proof costs, and development costs in building verifiable games
Our Zinity solution provides a smooth onboarding experience for both Web2 and Web3 developers building verifiable games. We believe a plug-and-play approach allowing developers to use various game engines with different DA layers and zkVMs will greatly enhance development flexibility.
We envision the future developer experience as follows: Zinity provides "elastic" support for provable games, offering plug-and-play development options for both crypto developers and Web2 game creators.
For example, developers could write core game logic in Rust, implement the rest in C# with Unity, and commit execution traces/hashes on-chain while deferring ZKP generation—significantly reducing both development and proof costs.
This elastic model also helps developers quickly prototype game ideas within C# and Unity, then iteratively decide how much of their game should be "on-chain" (How much on-chain is enough? We believe this should be up to developers and users). It also allows early stress-testing of game design versus blockchain performance tradeoffs.
While developing our own games and testing various tech stacks, we realized we still need experienced Web2 game developers to experiment with verifiable games to achieve better gameplay flow and UI/UX. That's why we've created our pioneering solution and hope to contribute to the broader on-chain gaming community.
We've already written extensively about using zkWASM and developing verifiable games and are continuing our remaining work. Here are some upcoming topics:
- Modifying zkWASM for verifiable games (in progress)
- Estimating DA and proof costs for this approach (completed)
- Modding, interoperability, and permissionless on-chain interactions for verifiable games (in progress)
- Related verifiable game design concepts (in progress)
If you're interested in developing verifiable games, discussing zkVM applications in gaming, or potentially collaborating with us, please reach out!
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Blade Research
