Blade Games Launches ZK Game Engine: Building Trustless Gaming
TechFlow Selected TechFlow Selected
Blade Games Launches ZK Game Engine: Building Trustless Gaming
ZK trustless games will drive the next wave of on-chain gaming.
Navigating Web3 tides with focused insightsAuthors: Blade Research, Delphinus Lab
TL;DR:
Blade Games and Delphinus Lab have co-developed a trustless game engine based on WebAssembly and zkWASM.
Our zk game engine supports slow real-time game genres such as tower defense and RPG, as well as idle games, card/auto-chess games, and interactive fiction. In short, we run the game logic inside zkWASM (a "zk server" for computation), and each game session generates a zkSNARK proof before being published. The engine supports languages like C++, Go, and Rust, with upcoming support for C# and Unity.
Take tower defense as an example: for a typical 6-minute session with 100 monster waves, the total zkSNARK proof generation time is about 3 minutes. This is just an initial result—we are rapidly optimizing proof generation speed. (ZKP generation for 1 million instructions takes 19 seconds; each wave involves 80,000 instructions, so a full game has 8 million instructions. With 8 zkSNARK proofs generated in a cloud-based setup, total time is around 3 minutes.)
In ZKVM-based trustless games, maintenance costs mainly come from ZK proof generation, RPC/call data access services, and on-chain verification and settlement fees. With the activation of the Cancun upgrade (EIP-4844) on L2s, the cost of running trustless games has significantly decreased.
Furthermore, by implementing zkSNARK proof recursion and leveraging Nebra's proof aggregation service in the future, we can further reduce ZKP costs.
Our game partners include:
Dune Factory (@BladeGamesHQ): A wasteland-punk themed base-building + tower defense strategy game
0xPioneer: A multiplayer online survival simulation game similar to Don't Starve
Craftpunk: A space-themed open-world RPG featuring customizable spaceships and procedurally generated maps
Main Text:
This ZK game engine was jointly developed by Blade Games and Delphinus Lab. This article is co-authored by both parties, aiming to help more Web2 game developers and on-chain game builders understand the advantages and development paths of ZK game engines.
This is a guide to developing trustless Web3 browser games. (Additional content is available on YouTube, and related materials at this link.)
As Web3 continues to evolve, fully on-chain games are once again gaining attention. They claim superiority in decentralization, transparency, trustlessness, and community governance. However, fully on-chain games inherit blockchain's trilemma of decentralization, security, and scalability—meaning developers face challenges balancing gameplay richness, interaction frequency, decentralization, trustlessness, and fairness in community management.
Therefore, in the last cycle, game developers made architectural compromises, leading to what is widely known as the Web2.5 game architecture—the current best practice.
More precisely, Web2.5 is a hybrid term combining Web3 and traditional gaming. Web2.5 emphasizes gameplay quality because its primary audience remains rooted in Web2. At the same time, it incorporates Web3 elements (NFTs, economic models, play-to-earn) to differentiate itself.
A standard Web2.5 game architecture might look like this:
The left diagram shows the game engine controlling the state machine and responding to player actions. The right illustrates how certain parts of the game state change and reveal the most valuable data on-chain.
Core gameplay mostly runs on a centralized game server, while high-value data (NFTs, token rewards, records, etc.) is tracked on the blockchain.
The advantage of this architecture is that the game server can process large volumes of user transactions in a centralized mode, completing them within seconds. Additionally, centralized servers can handle complex, continuous gameplay that would be too costly to process natively on a blockchain.
However, communication between the game engine and on-chain protocols is typically secured only via signatures, making it not truly trustless. Moreover, game content may be changed without community consensus, potentially harming existing players' vested interests (e.g., updates to game economy, content, or reward systems).
Additionally, it's hard to verify on-chain whether the data submitted reflects valid gameplay outcomes. Servers could abuse their position to treat player behaviors unfairly (e.g., favoring developer-owned accounts).
Since Web2 games typically excel in content and gameplay, entrusting balance and fairness to the provider is acceptable. But when entering the Web3 ecosystem, they must attract crypto-native players who care about economics, ownership, and value capture during gameplay. These players not only enjoy achieving rich outcomes but also expect their results to carry meaning (e.g., "sustainability") and even appreciation potential. This expectation makes players take their in-game decisions more seriously—raising their cognitive and decision-making investment, and deepening their demand for fair and predictable game rules.
Ultimately, players will demand control over the "Web3 features" of the game—the fairness and trustlessness should be enforced not by operators or developers, but by immutable code, enabling a more decentralized, fully on-chain game experience.
To achieve this, one straightforward approach is to move everything from the left side of the previous diagram onto the blockchain (right side), resulting in the following architecture:
Clearly, this leads to several "degradations" in gameplay:
- Each player action must be represented via an on-chain signed transaction to prove authorization
- The scale of the game engine running on-chain is limited
- High gas fees are required
- Player interaction frequency must be reduced to fit blockchain TPS (transactions per second) limits
Does this mean we must abandon rich, complex content in pursuit of "fully on-chain philosophy"?
Before zero-knowledge virtual machines (ZKVMs), the answer might have been "yes." But now that ZKVM technology is widely researched and applied, we have a "third way": combining fully on-chain games with trustless computation. How does this work?
ZKVM, or Zero-Knowledge Virtual Machine, combines zero-knowledge proofs with virtual machine technology. To understand it, let’s break it into two components:
- Zero-Knowledge Proofs (ZKP): A cryptographic method allowing one party to prove knowledge of a value (e.g., a key) without revealing any information about it. ZKPs protect privacy and security in transactions or interactions by verifying truthfulness without exposing actual data.
- Virtual Machine (VM): A software emulation of a physical computer. It runs operating systems and applications just like real hardware, but entirely in software. VMs are widely used in cloud computing and running multiple OSes on a single machine.
Combining these: A ZKVM is first a VM capable of executing programs or contracts, enhanced with the privacy and security benefits of zero-knowledge proofs. This means we can run a game engine (or server) inside a zkVM and use it to generate ZK proofs, proving to the blockchain that state transitions were enforced by game logic. Thus, the game server cannot alter data sent to the underlying blockchain.
Given this, the integrated architecture for fully on-chain games could look like this:
We refer to such trustless fully on-chain games as: Trustless Games.
2. Factors to Consider When Developing Trustless Games
2.1 Beginner’s Guide
Game development is generally considered difficult due to complex tech, creative demands, and project management. When applying ZKVM to Trustless Games, consider the following factors:
Technical Complexity: In Trustless Games, game logic must be separated from visualization and must be deterministic so ZKVM can generate proofs. Also, since proofs are generated per execution segment, developers need to split gameplay into segments and periodically sync execution with on-chain contracts.
Art and Design: Artists and designers work similarly in Trustless Games as in others, since their output doesn’t require proving. Visualization development depends on global game state, and UI/UX serves as tools to collect player actions.
Overall Gameplay Experience: Unlike typical on-chain games, players don’t need to sign every move on-chain, enabling “frequent-interaction” games—those requiring or encouraging regular player input.
However, due to ZKVM proof generation latency, high-frequency interactions remain impractical for ZKVM-based Trustless Games—such as RTS (real-time strategy) or MOBA (e.g., DOTA), where players continuously control units/resources and adapt strategies. These genres are difficult to develop on ZKVM.
Conversely, simulation and idle/farm games, where players periodically allocate resources, engage in markets, or operate characters to progress, are ideal for Trustless Games.
Interactive story games and visual novels are also excellent fits. Though not requiring constant input, they engage players through decision points that shape narratives and encourage repeated interaction to see consequences.
Next, let’s discuss monetization and sustainability.
Typically, game content evolves over time to attract new and retain existing players. This makes game logic dynamic, affecting programs running in ZKVM—and potentially requiring updates to validation contracts.
Two approaches can avoid frequent changes to ZK-verified contracts:
- Gameplay Changes: Abstract a protocol layer for gameplay and define dynamic aspects as rules. Developers can store rule sets on-chain and commit them to a hash. When the game engine runs, it checks if the current rule set hash matches the committed one before acting accordingly.
- Settlement Changes: Reward systems can be a separate layer from core gameplay. We can treat reward algorithms as callbacks triggered by certain in-game events. This way, reward callbacks live on-chain and are invoked based on game events.
For example, consider this game loop:
zkgame {
// Game logic
output(events)
}
The generated events become instances of provable execution. So we can add callbacks to the contract:
2.2 Where Should Game Logic Run?
Game logic primarily runs in two places: frontend or backend/server.
Running game logic on the frontend simplifies architecture compared to client-server models. This allows the frontend to simulate gameplay and generate a zk-proof after establishing an execution trace. It then uses a local zk-prover or remote proving service to generate a ZK proof for the ZKVM, which is uploaded to the underlying blockchain to trigger settlement contracts.
Alternatively, running logic on the server moves game simulation and user interaction to a dedicated component (the game server), improving overall gameplay experience in the following ways:
- Better synchronized gameplay: Server-side simulation ensures all players experience the game as synchronously as possible. Consistent game states across all connected clients are crucial for competitive multiplayer experiences.
- Improved resource management: The frontend can focus on rendering and UI/UX, while the server acts as a centralized sequencer and provider of Merkle tree storage.
For single-player PVE games (or simple PVP games) that don’t require historical data and have straightforward sequential logic, putting everything on the frontend is a good choice. For complex games like multiplayer SLG (simulation games) or AW (autonomous world) games, server-side execution performs better.
2.3 Choosing a Game Development Architecture
Since we're combining traditional game development with ZKVM, tool selection requires careful consideration.
1. Programming Language
First, decide whether to use traditional languages like C#, Rust, C, C++, or Go, or a language specific to ZKVM.
Traditional languages usually compile to bytecodes like MIPS, WASM, RISC-V, or x86. Since few ZKVMs support these, if your program compiles to RISC-V bytecode, you can choose Risc0 as the underlying ZKVM; if it compiles to WASM, choose zkWASM.
WebAssembly (WASM) is a low-level bytecode format designed as a compilation target for high-level languages (C, C++, Rust, etc.). It enables near-native-speed execution of such code on the web. WASM provides a way to run performance-critical code in web browsers without sacrificing security or speed. As a key part of modern web stacks, it complements JavaScript by allowing developers to use languages beyond JavaScript for web development.
2. Game Engine
Once a programming language is chosen, select a game engine based on that language. If using a ZKVM-specific language, you may need to build your own framework, as mature ones may not exist. For Rust, C, TypeScript, etc., many frameworks are available—we recommend Unity and Cocos2D.
3. Proof Generation Cost
Proof cost is typically measured by the time to generate a proof for 1 million instructions. It depends on the execution trace of gameplay (number of instructions per interaction), bytecode word length, and ZKVM proof performance. Some ZKVMs generate proofs for 1 million simple instructions in seconds (Miden). For complex instruction sets (RISC-V 32-bit, WASM 64-bit), ZKVMs can generate such proofs in about 12 seconds on GPU (Risc0) to around 30 seconds (zkWASM).
3. Applying MVC (Model-View-Controller) Pattern in ZKWASM for On-Chain Games
3.1 Introduction to MVC Pattern
Though typically associated with web/enterprise apps, the Model-View-Controller (MVC) pattern can also apply to game development—with some adaptation. Here’s how MVC components function in game development:
Model:
In game development, the model represents game data and logic. This includes game state (score, level, player stats), game objects, and rules governing the game world. The model manages game data and state, typically unaware of how the data will be presented.
View:
The view handles displaying game state to the player. This involves rendering graphics, playing sounds, and showing UI elements like score, health bars, and menus. The view observes the model and updates the visual and auditory representation accordingly. In many engines, the view is encapsulated within rendering and UI systems.
Controller:
The controller interprets user inputs from keyboard, mouse, gamepad, or other devices and translates them into in-game actions. For example, when a player presses a button to make a character jump, the controller processes the input and communicates the action to the model. In games, the controller acts as an intermediary between input devices and game logic.
Applying MVC in game development offers clear advantages:
- Separation of Concerns: MVC helps organize code and decouple game logic from UI, making development more manageable and code easier to maintain.
- Flexibility: MVC allows different views for the same model—useful for multiple perspectives or supporting various display modes.
- ZK-Friendly: By separating logic from presentation, only the model needs to be trustlessly executed. Placing the model in ZKWASM naturally proves core game mechanics during runtime.
3.2 Setting Up the Game Engine in ZKWASM
Assume the controller connects to the model with a set of handlers. Then, we can add a command encoding/decoding layer to the controller and handlers as follows:
3.3 Generating a Gameplay Proof
We can treat a portion of gameplay as a sequence of controller calls to handlers. Therefore, the trustless ZK proof of gameplay is the following code:
fn execution(cs: Vec<command>) {
for command in cs {
global_state = handler(command);
}
}
During gameplay, it's difficult to determine the final command sent by the controller, and challenging to put all command processing into a single ZK proof. Therefore, the best practice is to split commands into multiple segments, prove them separately, then batch them into a single proof for on-chain verification.
Note: The above method lacks two components:
- Ensuring state continuity between execution segments
- Handling multi-user scenarios where controllers from different game clients interfere with each other
We briefly introduce multi-player sequencing and data availability (DA) in the following sections. Given each topic's depth, we plan detailed discussions in separate future notes.
4. Sequencing User Interactions in Multiplayer Games
In modular blockchain contexts, a sequencer is a component or node responsible for ordering interactions before final confirmation. Modular blockchain architectures separate blockchain functions (execution, consensus, data availability) into distinct layers, aiming to improve scalability, security, and efficiency through independent optimization.
When developing multiplayer games, we also need a component to order interactions among users. Hence, we repurpose the term "sequencer" from modular blockchains.
Since games require low latency, a centralized sequencer producing fast ordering results is preferable. The game engine can closely integrate with the sequencer to fetch ordered transactions.
Single Player Interaction Protocol
Here (see figure below), we describe an interaction protocol from the player's perspective. In a user transaction, the user describes their input and proves identity via public and witness inputs, structured as follows:
Public Input and Witness Input:
Interaction Processing Logic:
pub fn zkmain() -> i64 {
let mut hasher = Sha256::new();
// get the command length
let commands_len = unsafe {wasm_input(0)};
// processing all commands and
// hash the commands for future signature verification
for _ in 0..commands_len {
let command = unsafe {wasm_input(0)};
hasher.update(command.to_le_bytes());
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),
]),
}};
zkwasm_rust_sdk::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::from_be_bytes(msghash[24..32].try_into().unwrap()),
u64::from_be_bytes(msghash[16..24].try_into().unwrap()),
u64::from_be_bytes(msghash[8..16].try_into().unwrap()),
u64::from_be_bytes(msghash[0..8].try_into().unwrap()),
];
sig.verify(&pk, &msghash_u64);
5. Cost Analysis
5.1 Cost Overview
In ZKVM-based trustless on-chain games, main maintenance costs stem from ZK proof generation, fast data RPC services, call data access services, and on-chain verification and settlement fees. With the activation of the Cancun upgrade (EIP-4844) on L2s, the cost of running trustless games has significantly decreased. Furthermore, by implementing zkSNARK proof recursion and Nebra's proof aggregation service in the future, we can further reduce ZKP costs.
5.2 ZK Proof Generation Cost
First, the ZKVM runs the application and generates an execution trace. This trace is fundamental because the ZKVM must prove:
- The trace enforces the semantics of the bytecode supported by the ZKVM
- Typically, ZKVMs are stateless. To support stateful storage for games, they use the concept of converting data gets/sets into Merkle proofs
- ZKVMs usually split the execution trace into segments and generate separate proofs for each. These are then batched into a single verifiable proof
Assuming the ZKVM uses precompiled instructions as system calls (or host APIs in zkWASM) to handle Merkle proofs, the overall ZK proof cost is:
Proof Cost = ZKVMGuest Proof Cost + Merkle Proof Cost + Batch Proof Cost
Typically, the first and third terms on the right do not incur extra costs beyond pure ZK proving. However, the second term has nuances, as it requires support from data storage services.
Let’s review the components of a Merkle proof:
1. Merkle Tree Setup
We abstract global data into blocks, hash them individually, and use these hashes as leaf nodes of the target tree. Then, pairs of leaves are hashed to form the next level, repeating until only one hash remains—the Merkle root. The Merkle root uniquely represents all data blocks in the tree.
2. Data Inclusion Proof
This proof consists of the specific data block in question, its hash, and a small number of additional hashes from the Merkle tree. These extra hashes are the minimal set needed for the verifier to independently recompute the dataset’s Merkle root.
3. Proof Verification
The verifier knows the dataset’s Merkle root but not necessarily all its contents. Using the provided data block and extra hashes, they reconstruct the hash path to the Merkle root. If the computed root matches the known one, the proof is valid, confirming the data block is part of the dataset and unaltered.
To maintain a stateful ZK game, a Merkle database is needed to track leaf nodes and provide fast query services. This is unlikely to be fully hosted on-chain due to high data modification frequency and heavy read/write demands.
Once a transaction completes, call data and final state (represented by a new Merkle root) must be accessible—typically achieved via DA layers or on-chain txdata storage.
5.3 Data Costs
Based on Blade Games’ analysis and references to ZKWASM, Eth Storage, BNB Greenfield DA storage calculator, and Google Cloud storage calculator, we conclude: Running an on-chain game with 5,000 players (assuming non-stop play—actual DAU would likely be much higher) using the zk coprocessor approach would cost approximately $90,000 monthly—comparable to running a high-defense, anti-DDoS MMORPG server.
Blade Games' estimation method: They convert Unity-generated user events into binary code and run it within ZKWASM (a ZKVM supporting WASM bytecode developed by DelphinusLab). ZKWASM generates an execution trace, compresses it, and publishes it to the DA layer. Simultaneously, they publish the trace hash on-chain, verified immutably via digital signatures.
According to ETHstorage and zkwasm test runs, 1 second of WASM binary execution generates 1 million trace rows, each 40 bytes in size.
We can choose to prove all traces or only store them, generating proofs only if users challenge results.
1. ZK Method: Proving All Traces
If we choose to prove all traces, generating a ZK proof for ~1 million bytecode instructions takes about 25 seconds on a single RTX4090 GPU, costing roughly $0.005 (at $0.01 per 2 billion instructions). In this solution, costs mainly come from proving capacity, on-chain verification, and DA call data storage. Supporting a multiplayer game generating 100 billion trace entries per hour would cost about $50/hour (~$36,000/month) in proving costs.
2. Fraud Proof Method
Assume 5,000 players, each averaging 2 hours of continuous play, generating 86.4 trillion trace entries per hour. Daily storage consumption: 60 sec × 60 min × 2 hrs × 5,000 players × 1 million instructions = 36 trillion trace entries. According to ETHstorage and zkw
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
