Author: Blade Research

Core authors: wangyao, 0xbrawler

Table of Contents

• Why develop a Provable Game?
• Blade Games' technical architecture
• 1) Develop a simple tower defense game based on zkwasm
• 2) Zinity: The first solution that allows provable game development directly from Unity
• Arcade games and ERC-6551 applications
• Our upcoming games at ETHdenver
• Future development plans and research topics

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.

Too long to read version:

• ZK AssociationXiaobai NavigationProcessor approach provides the trust assumptions needed to verify games, as well as the compute power needed to develop engaging gaming experiences
• For experienced game developers, it is [very] necessary to have a Unity/Unreal native solution, rather than synchronizing the core game logic in Solidity/Cairo with the animation/rendering in Unity.
• The future developer experience for on-chain games and verifiable games will be highly modular and pluggable (how much on-chain is considered on-chain? We think it should be decided by developers and users)
• In the future, we believe there will be flexible ways to tradeoff trust assumptions, proof costs, and development costs, so as to develop verifiable games with controllable costs.

Why develop provable games?

2023 is a year of booming on-chain games (FOCG)/autonomous worlds (AW), and a large number of infrastructures have emerged. This includes Mud.dev, Dojo, World Engine, Keystone, Paima, etc. In addition, Rollup service providers such as Altlayer, Caldera, and Conduit have also attracted many full-chain game developers to develop.

However, through the process of developing and operating our first on-chain battle royale game, Loot Royale, and reaching 600–800 daily active users within a month, we discovered an important problem:

If all game logic is placed on the chain, the limited computing power of EVM itself will become the biggest bottleneck for game development.

The lack of computing power limits the types of games (mainly low-computation, single-threaded, asynchronous games) and user experience (everyone has to wait for transaction packaging, RPC hydration, etc.).

Just to name a few. We got a lot of feedback like “I want my transaction to be mined in time so that attack can hit” and “When will the RPC data finish loading?” This has to change.

Players are really anxious waiting for RPC hydration

After trying to develop on various technology stacks, we believe that if we can prove the calculation off-chain, then its credibility should be extremely close to the transaction/computation on the whole chain. We solve the limited computing power of EVM by adopting the principle of "off-chain execution, on-chain verification". This has several advantages:

• Improve user experience and reduce waiting time
• Expanding the game categories to include more computationally demanding “mid-core” games like tower defense
• Support the use of hidden information in games

We will first briefly describe how we use zkWASM to develop provable games. Then we will discuss our zkwasm-unity solution.This is the industry's first solution that allows certifiable game development directly from Unity.

Blade Games' technical architecture

Develop a simple tower defense game based on zkwasm

The technical architecture here is divided into two parts. The first part is to write a simple PvE and PvP tower defense game in Rust and verify it through 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 to achieve a more modular and flexible provable game development solution. (zkwasm is developed by Delphinus Labs and is a zkVM that runs wasm code and generates zkSNARK proofs of its execution traces.)

Let's start with the PvE example — a game written in Rust and the Bevy Engine.

Rust can be easily compiled into wasm and generate a wasm image before processing in the zkwasm VM. We can then choose to publish the processed execution trace to the Data Availability Layer and prove it later. Or the user can choose to prove it immediately and send the zkSNARK proof to the chain (using a single RTX4090 GPU to process a proof of 1 million words in about 45 seconds, which is enough for a slower-paced tower defense game).

The game is then broken down into several steps.

• The player will confirm the map settings and commit the relevant information to the chain
• The game logic runs a battle in the rust code; the related execution trace can be proved by zkwasm, and the player submits the zk proof to the chain
• When a new wave of monsters arrives, players can choose to keep the previous turret settings, or submit a new commit again.
• Players cannot change tower settings in the middle of each wave. If they change the map settings, they can submit a new commit again.

(Player will confirm the map settings and submit the zkwasm output to the chain)

(The game logic runs a battle in the rust code. The relevant execution trace can be proved by zkwasm, and the player submits the zk proof to the chain)

Zinity: The first solution that allows developing verifiable games directly from Unity

For many game developers, developing games on the chain means that they need to learn solidity, rust or cairo. This means that they need to stop using the C# they are familiar with. In addition, trying to unify the rendering and animation of the Unity engine with the solidity/cairo game logic code based on Mud/dojo is a very time-consuming and laborious process.

We will release the first Unity-native solution using the zk coprocessor, a "zkServer" development framework for on-chain games. We call it Zinity.

The game code is decoupled into:

1) Core logic code (attacks, loot boxes, unit coordinates, etc.)

2) The rest of the code. Then, both parts of the code are compiled from C# into wasm, the core game logic is run by the zkwasm runtime, and the rest of the code is run on the normal C# runtime. There will be a communication protocol for handling messages to be responsible for the communication between the two sides.

zkWASM will witness actions such as "Player A placed a turret at coordinates (x, y) at time X" in binary code. As a new game begins, we start to get the initial game state. As the game progresses, zkwasm will witness and calculate more player inputs. When the game ends, a new game state with a hash value and the associated execution trace will be generated.

We can choose to publish the entire execution trace to a data availability layer (DA layer) such as Eigenlayer/Celestia/Avail/Greenfield. Or users can choose to only put the hash value on the data availability layer and store the trace in cloud storage. In addition, we will also design a challenge period to verify the game state in the form of fault proof.

In addition, for important game results with large player participation economic units, users can also choose to generate zk proofs for the entire game process and publish them directly on the DA layer.

Finally, all pipelines will be integrated and available as Unity SDK (non-animation and rendering) or CLI tools to guide the entire toolchain.

We can also extend this solution to other game engines like Unity/Unreal/Godot. Future plans also include integration with other zkVMs like RiscZero and various DA layers like Eigenlayer/Celestia.

With this approach we can greatly expand the number of on-chain game/verifiable game developersCommunity, attracting web2 game developers and various game studios.

On-chain Arcade + Tower Defense Gameplay with ERC-6551

Additionally, we are exploring on-chain arcade concepts around verifiable games. For example, a player could submit a setup of some kind of tower/turret/obstacle on-chain, and another player could submit their choice of monsters and minions to try to complete the level. The battle results are calculated locally, and only the zk-snark proof is submitted on-chain to verify the game results. This is to ensure that the method of passing the level is not broadcast to the chain for public viewing.

ERC-6551（TokenBinding accounts) will turn these PvP games into autonomous arcades. Players who open rooms cancontractDeposit rewards, and challengers need to pay a fixed entry fee, which is accumulated into the bonus pool to reward players who complete the level. The first 10 players who complete the level can take away a certain proportion of the bonus pool reward.

We are actively exploring this autonomous arcade idea and welcome any type of discussion on twitter (@BladeGamesHQ). In one of our upcoming posts we will discuss a PvP example for a tower defense game.

Our upcoming games at ETHdenver

We will be showing a verifiable game demo at ETHdenver. The game will be developed in Rust and React and will run on zkwasm.twitterContact us and we'll add you to the early access list!

Conclusion, and what we will publish next

• The ZK coprocessor approach provides the required trust assumptions and the computational power developers need to create engaging gaming experiences
• For experienced game developers, a Unity/Unreal native solution is (very) desirable, rather than having to unify core game logic in Solidity/Cairo and animation/rendering in Unity
• The future developer experience for on-chain games and verifiable games will be highly modular and pluggable (how much on-chain is considered on-chain? We think it should be decided by developers and users)
• In the future, we believe there will be flexible ways to balance trust assumptions, proof costs, and development costs to develop verifiable games.

Our Zinity solution provides web2 andweb3Developers, providing a smooth onboarding experience for developing verifiable games. We believe that a plug-and-play approach that allows developers to use various types of game engines, as well as different DA layers and zkVM for development, will also provide greater flexibility in the development experience.

We envision a future developer experience where Zinity can provide “elastic support” for provable games andcryptoDevelopers, Web2 game developers provide pluggable development options for provable games.

For example, developers can use Rust to write the core game logic, use C# and Unity to write the rest of the game, and commit the execution trajectory/trajectory hash on the chain to delay the generation of ZKP, which will greatly reduce the development cost and proof cost.

This elastic model can also help developers quickly test early game ideas within C# and the Unity engine, and then continue to iterate on the "on-chain degree" of the game they want (how much on-chain is considered on-chain? We believe that it should be determined by developers and users). It also helps stress test game design vs. BlockchainPerformance tradeoff.

As we developed our own games and tested various technology stacks, we realized that we still needed experienced web2 game developers to try to develop verifiable games to get better game flow and UIUX. Therefore, we proposed our own pioneering solution and hope to provide a wider range of on-chain game developersCommunityMake a contribution.

We’ve written a lot about a number of topics around using zkwasm and verifiable game development, and are working on more. Here are some of the topics:

• Modifying zkwasm to enable verifiable gaming (in progress)
• DA cost and justification cost estimates for this approach (completed)
• Verifiable game modding, interoperability, and permissionless interaction on-chain (in progress)
• Related Verifiable Game Design Ideas (in progress)

If you’re interested in developing verifiable games, discussing the use of zkVM in games, or just joining us to work together, please get in touch!

The article comes from the Internet:A new chapter in full-chain gaming: developing provable games with ZKWASM