# 3.2 AW Engine

AW Engine is a blockchain vertical scaling solution designed for the real-time and coherence needs of games.

## 3.2.1 AW Operation Mode

In recent years, the gaming industry has been rapidly changing, and blockchain-based Web3 games are expected to bring new business models. However, traditional games still face many challenges in fully embracing Web3:

1. Throughput: Many games require fast operations that are coherent and uninterrupted, which strongly conflicts with blockchain. Some fast-paced shooting games have actions measured in milliseconds, while the fastest blockchains currently require 2 seconds per block, meaning that every step in the game must wait at least 2 seconds. Therefore, building fast-paced games on-chain is not feasible.

2. Scalability: How many players can a game support without congesting the blockchain and causing gas prices to skyrocket? If every action of a player needs to be recorded on-chain, the blockchain will become extremely congested.

To address this issue, we developed a set of AW Engine, which packages operations in the game using zero-knowledge proofs, uploading and verifying them on-chain all at once. This means players can perform more actions and play longer before interacting with the blockchain, thereby reducing transaction costs and congestion on the main blockchain. For example, in turn-based games, players can perform multiple actions, allowing multiple actions to generate proofs. Formally, we have:

The most direct way to verify such iterative computations is to place n actions into a separate circuit and then use SNARK to complete the proof, significantly increasing the number of actions that can be placed in a single transaction. This opens up possibilities for developing more types of games for fully on-chain gaming. Here, we take single-player and multiplayer games as examples.

Single-player games: Taking games like 2048 and elimination tournaments as examples, if all the detailed actions of the player and elimination logic are uploaded to the chain, it will consume a lot of gas and chain resources. By using ZKP to compress these processes, we only transmit the necessary information and proofs to the chain. This method can reduce gas costs and transaction numbers by more than 100 times.

We will provide circuits for this type of turn compression and the necessary smart contracts, allowing developers to create games without writing circuits, simply by completing the necessary game economic logic and front-end packaging.

Multiplayer games: Below is an example used entirely in a Trading Card Game (TCG).

To participate in TCG (Trading Card Game), players need to use matchmaking to find opponents. Once the game starts, both players' cards are shuffled using ZK Shuffle. Then, each round utilizes the ZK Shuffle's card flipping feature. Additionally, we use Data Rollup to compress the details of each round into a single transaction. This method achieves a fully on-chain TCG with low interaction and transaction costs.

## 3.2.2 Slow-paced ZK Games

For slow-paced games like the 2048 game discussed above, we provide two zero-knowledge proof-based solutions.

2. SNARK: It is well known that designing constraint systems for ZKP is a daunting task that can only be accomplished by skilled developers, and it is difficult to ensure that the constraint system is error-free. This is one of the factors limiting the development and use of zero-knowledge proofs. However, we provide various tools used in game circuit development, including basic arithmetic circuits, hashes, ecc, zkshuffle, zkmatchmaking, etc., significantly lowering the entry barrier for developing fully on-chain games.

3. ZKVM: We provide a general zkvm to write game logic, such as RISC Zero, which is a general zero-knowledge proof system designed specifically for the RISC-V architecture, allowing developers to build ZK applications using mature languages like Rust and C++. This means RISC Zero can support applications written in existing Web2 programming languages without the need to build plonk-related circuits or use DSL languages for writing.

Currently, Bonsai allows users to remotely generate proofs for their zkVM applications without using their own hardware to generate proofs. However, using Bonsai does not protect user privacy. Similarly, for zkSNARK, we also need a remote prover to delegate the client proof computation to a set of untrusted servers to generate proofs faster and protect user privacy. Existing solutions combine MPC protocols to build zkSNARK proofs with multi-server collaboration. According to 【28】, points on elliptic curves and fields can be directly encrypted and shared, and MPC technology can be applied to these shares. The main method currently used is to package encrypted shares.

Therefore, using packaged encrypted shares and their properties makes it easy to implement efficient MPC protocols for the corresponding zkSNARK provers.

## 3.2.3 Z4 Engine

The AW Engine can be used to solve single-player off-chain games and can also advance to support fast-paced multiplayer online real-time games. To manage the complexity of multiplayer online environments, we designed a Z4 Engine. In simple terms, the game will be conducted on third-party nodes, and after the game ends, the third-party node provides zk proofs of the game process to verify the game results. Third-party nodes need to stake to accept games in the public room market, similar to bounty hunters.

The Z4 Engine is equipped with several modules: a chain interaction module, an on-chain event listening module, an HTTP and P2P network startup module, a prover with zero-knowledge proof modules, and a game logic interface. Based on the integration of these modules, developers only need to define game logic to run a complete Z4 node dedicated to their game.

Z4 Engine Architecture Diagram

In the Z4 engine workflow, players create game rooms on-chain. Once other players see this room, they can choose to join. When the room is full or the host actively clicks to start, the room enters a ready state, and it also appears on the bounty hunters' acceptable list, prompting them to seize the room. The first successfully seized Z4 node becomes the provider for this game. Players in the room monitor on-chain dynamics to observe the room's provider and connect to the local network based on the provider's address in the contract. This connection includes both HTTP and P2P connections to ensure network stability and compatibility. When there are no Z4 nodes in the network, any player can act as a provider without needing to provide an externally accessible HTTP address, enabling quick startup and peer-to-peer connections through P2P. After the game ends, the provider will generate zk proofs of the game process, submitting the game results and zk proofs on-chain. Once verified, the room status is updated to over.

The zk proof circuit for the game can also be customized using PLONK or written using ZKVM or DSL to form a specific Z4 node for the game. Given the learning curve of zk and the difficulty of writing circuits, we provide a general game running platform that deeply integrates Z4 and Risc Zero. This general Z4-RISC0 node runs in a RISC-VM sandbox environment, allowing game developers to define game logic and submit it as a Z4-RISC0 node to the chain. This general node can run any game developed under the RISC-VM framework, automatically generating zk proofs after the game ends. By integrating the Bonsai proof market, it achieves the goal of rapid proof generation, improving the efficiency and reliability of on-chain game verification.

Games involving large-scale operations can lead to excessively long proof times. To further improve the proof efficiency of games, we also provide a proof solution based on Threshold ECDSA. After the game ends, players sign the game results, and once the threshold of n-m signatures is reached, the validity of the game results can be determined. This solution effectively alleviates the problem of long zk proof generation and verification times, while also providing a feasible proof method for some segments that cannot perform zk proofs. For example, in shooting games, the player whose actions are processed first by the Z4 node has a higher chance of getting a kill, and time cannot be written into the zk circuit. Therefore, this social consensus is needed as a verifiable approach for the game. Below is a comparison between zk proofs and Threshold ECDSA signatures:

The table above shows that while zk proofs provide a high level of security and non-repudiation for simpler, deterministic game events, Threshold ECDSA offers a faster and more scalable solution for complex and real-time scenarios, relying on community consensus to address aspects that zk proofs cannot effectively handle.

References:

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