Need for Compute: Building Provable Game with ZKWASM

Toward a more modular, elastic way of building on-chain games

Why build provable games?

Blade Games’ Approach

• Putting tower defense game into zkwasm
• Zinity: the first solution to allow provable games to be built directly from Unity
• arcade games and ERC-6551 application

Our Upcoming Game at ETHdenver

What we are releasing next

Blade Research is the R&D lab of @bladegamesHQ , building the necessary tech stacks of on-chain games

Credit also goes to Sinka, Will Robinson, Mohamed Fouda, LoneSCV, 0xAiko, Simon Chan, Maggie Wu, James Fang, Zee, Dodo Research and others

Core writers:wangyao, 0xbrawler

The TL;DR:

• ZK co-processor approach provides the trust assumption and computing power developers need to build engaging games
• A Unity/Unreal-native solution is (much) needed for experienced game developers, instead of having to unify the core game logic in solidity/cairo and animation/rendering in Unity
• We believe the future of developer experience for building provable games should be highly modular and elastic (plug and play approach — let the developer and users decide how “on-chain” it should be)
• In the future, we believe there will be elastic approach on trading off Trust Assumptions, Proving Cost, Development Cost for building provable games

Why build provable games?

In 2023, we’ve seen a variety of infrastructures built to support Autonomous Worlds / Fully On-chain Games (FOCG). This ranges from Mud.dev to Dojo, to World Engine, Keystone and Paima. Additionally, FOCG builders have also launched games on customizable rollup solutions such as Caldera and Altlayer, as well as Conduit.

Yet with our experience building and launching our first on-chain battle royale game, Loot Royale, at 600–800 DAU for over a month, we’ve discovered an important problem with putting the game logic fully on-chain: the lack of Computing Power.

The lack of computing power limits the types of game you can build (mostly asynchronous games), as well as the user experience.

For example, we’ve received a lot of feedback on “I wish my transaction gets bundled in time to finish that attack”, and “when can the RPC finish hydrating”. This has to change.

After testing and building on various tech stacks, we’ve come to the belief that what can be verified on-chain, is the closest equivalent to what happened on-chain. We address the limited computing power of EVM by adopting the “Execution off chain, verify on chain” principle. This have several advantages:

• Improved user experience and less wait time
• Supporting mid-core games that’s more computation heavy such as Tower Defense
• Potential application of hidden information

We will briefly explain how we use zkWASM to build a basic demo of a tower defense game.

Then we move on to discuss our zkwasm-unity solution, which we believe is the industry’s first mover to allow provable games to be built from Unity directly.

Blade Games’ Approach

1)Putting tower defense game into zkwasm

There will be two sections in our approach, one is a simple PvE and PvP tower defense game written in Rust and proved with zkwasm. The second part is our plan to build a compiler that compiles C# to wasm, and making modification to the existing zkwasm, to build a more elastic, modular framework for provable games. (zkwasm, built by Delphinus Labs, is a zkVM which runs wasm code and generates zkSNARK proof of its execution trace, which then can be verified by smart contract).

Let’s start with the PvE example — we write the game with Rust and Bevy Engine.

Rust can be easily compiled to wasm, and generate a wasm image before processing in the zkwasm VM. We can then choose to post the processed execution trace to a Data Availability layer and prove it later, or have it proved on the spot and sent the zkSNARK proof on-chain (roughly 45 seconds with a RTX4090 GPU for 1 million bytecode — which is quite enough for a tower defense game at slower pace).

The game is then broken down to a few steps.

• The player will confirm the map setup and commit the execution trace on-chain
• The game logic is run in rust code for the single wave of creep battle. The related execution trace can be proved by zkwasm, and players submit the zk proof on-chain
• A new wave of creeps comes and players can choose to maintain the previous setup, or commit again
• Players cannot change tower setup in the middle of each creep waves, if they change the map setup, they can commit the new setup again

(The player will confirm the map setup and commit the zkwasm output on-chain)

(The game logic is run in rust code for the single wave of creep battle. The related execution trace can be proved by zkwasm, and players submit the zk proof on-chain)

2)Zinity: the first solution to allow provable games to be built directly from Unity

For a lot of game developers, building on-chain games means that they’ll need to learn solidity, rust or cairo.They will also need to stop using C# which they are familiar with. Additionally, trying to unify the Unity engine for rendering and animation together with Mud/dojo based solidity/cairo game logic code is a difficult process.

We are going to release the first zk co-processor, Unity native solution for on-chain games, a “zkServer” approach.

The game code is decoupled to 1) core logic code (attacks, loot boxes, unit coordinates etc.) and 2) rest of the code. Then both parts of the code is compiled from C# to wasm, with the core game logic run by the zkwasm runtime, and the rest of the code running in normal C# runtime. There will be a communication protocol that handles messaging.

The zkWASM will witness actions in binary code such as “player A placed a turrent at coordinates (x,y) at time X”.As a new game session starts, we fetch the initial game state. As the game proceeds, more player inputs will be witnessed and computed. When a game session ends, a new game state will be generated with hashes.

We can choose to post the entire execution trace on-chain to a DA layer such as Eigenlayer/Celestia/Avail/Greenfield. Or users can choose to put only the hash on the DA layer, with traces stored off-chain in cloud storage. A challenge period will be required to verify the game states.

Additionally, for important game results with heavy stakes on the table, users can also choose to generate a ZK proof for the game results, and directly post it on DA.

Finally all the processes will be streamlined and integrated as a Unity SDK (non animation and rendering) or a CLI tool to direct the entire toolchain.

We can also expand this solution to leading game engines such as Unity/Unreal/Godot. Future plans also include integrating with other zkVM such as RiscZero, also various DA layers.

Through this approach, we can massively expand the builder community of on-chain game/provable games developers to web2 game developers and various game studios.

3)On-chain arcade + tower defense gameplay with ERC-6551

Additionally, we are also exploring the on-chain arcade idea around provable games. For example, a player can also commit a certain setup of towers/turrets/obstacles on-chain, and the other player can commit their selection of creeps to attempt and clear the level. The battle results are computed locally, and only the ZK proof is submitted on-chain to verify the game results. This is to ensure that the method of clearing the level is not broadcasted to other players.

The application of a token-bound account (ERC-6551) will turn these PvP sessions into autonomous arcade machines. Host players can deposit a reward into the smart contract, and the challenger will need to pay a fixed entrance fee that accrues to the prize pot, to clear the level. The top 10 players to clear the level, can take away a certain % of that prize pot.

We are actively exploring this autonomous arcade idea and welcome any type of discussion on twitter at BladeGamesHQ In our upcoming article, we will be going over the PvP example for the tower defense game play.

Our Upcoming Game at ETHdenver

We will be showcasing a provable game demo during ETHdenver. This game will be developed in Rust and React, running on zkwasm. Ping us on twitter at BladegamesHQ and we’ll add you to the list!

Conclusion and what we are releasing next

A few key observations here:

• ZK co-processor approach provides the trust assumption and computing power developers need to make engaging games experiences
• A Unity/Unreal-native solution is (much) needed for experienced game developers, instead of having to unify the core game logic in solidity/cairo and animation/rendering in Unity
• In the future, we believe there will be elastic approach on trading off Trust Assumptions, Proving Cost, Development Cost for building provable games

Our solution provides a smooth onboarding experience for web2 and web3 developers to build provable games. We believe the plug-and-play approach of getting developers to build with various types of game engines, as well as different kinds of DA layers and zkVM, will also provide greater flexibility in experience.

We envision a future where there can be “elastic” support for provable games, and provide options for both crypto developers and web2 game developers to build provable games. For example, you should be able to write the core game logic in Rust, rest of the game in C# and Unity, and post execution traces/hashes of traces on-chain, generate ZKPs later to best optimize cost.

This elastic model can also help developers to quickly test out the early stage game idea in C# and then proceed to iterate how “on-chain” they want the game to be, with game design/performance tradeoffs in-mind.

As we build out our own games and test out various tech stacks, we realize that we have to onboard experienced web2 game developers to build provable games and improve game flow and UIUX. Hence we have come out with our own first-of-its-kind solution proposal, and hope to contribute to the broader onchain game builder community.

We’ve written extensively on a few of the topics around building with zkwasm and provable games, and are working on the rest. Here’s a list of topics:

• Modifying zkwasm for fully on-chain games (work in progress)
• DA cost and prover overhead estimates for this approach (available)
• Modding and on-chain interaction for provable games (work in progress)
• Provable game design spaces (work in progress)

Reach out to us if you are interested in building provable games, discussing zkVM’s application in games, and potentially joining us to work together!

Disclaimer:

Zkwasm is a wasm-based execution and proving engine developed by Delphinus Labs.

Zinity is a tech solution to make games run on zkwasm to be released soon. It is based on zkwasm and the associated intellectual property is owned by a company co-owned by wangyao and Blade Games.

Blade Games is developing the solution together with Wangyao to build Zinity.