CaptainZ

Since the concept of provable on-chain games was proposed by the Dojo of the Starknet ecosystem, many teams have begun exploring this field, such as paima, which utilizes NFT state compression, and redux, which employs Merkle trees and state inscriptions, among others. Zypher Network (@Zypher_Network) has also released a series of developer kits based on zero-knowledge proof technology to assist in creating provable on-chain games.

What is a Provable On-Chain Game#

We now know that the combination of the gaming industry and blockchain technology can either follow the GameFi model of asset on-chain or the on-chain gaming model of state on-chain. The general definition of on-chain games is as follows: all game logic and state (assets and others) are on-chain, implemented through smart contracts.

As a smart contract platform, Ethereum is inherently a distributed state machine that can perform relatively simple on-chain computations and state validations. Thus, everyone tries to write game logic into smart contracts, making games a decentralized form of gaming that does not require a server backend, bringing a higher degree of composability in terms of game rules. However, problems arise: the computational power of the Ethereum mainnet is too weak, and the costs are very high. Even considering the use of high-performance layer 2 chains or other public chains, it cannot meet the demands of on-chain games.

Inspired by layer 2 rollups, since larger-scale transfer operations can be computed off-chain and verified on-chain, why not handle the execution of game logic in the same way? Thus, the technical route for provable on-chain games was born. Although the game logic is computed off-chain, every operation can be verified on-chain, ensuring the decentralization and trustlessness of the game. This is the origin of the term "provable," and we can even make a simple analogy: TX in layer 2 rollups is an ordinary transfer transaction, while TX in provable on-chain games is a game on-chain transaction.

Depending on the method of on-chain verification, rollups are divided into OP-rollups and ZK-rollups. Similarly, provable on-chain games using zero-knowledge proof technology have prominent advantages in both the finality of state verification and performance, which is why Dojo and Zypher Network chose ZKP to develop provable on-chain games.

Zypher Network Developer Kit#

The Zypher Network developer kit consists of three parts: AW Engine, Secret Engine, and Zytron kit.

1. AW Engine: Utilizes the information compression capabilities of ZKP to provide scalability. A modular framework that allows games to vertically super-scale. It can be programmed through circuits or zkVM. Its z4 SDK supports real-time in-game multiplayer events (player battles).
2. Secret Engine: Utilizes the information hiding capabilities of ZKP to provide asymmetric information games. A zero-knowledge proof as a service (zk-as-a-service) software development kit that provides information asymmetry for games requiring strategic mechanisms. Zero-knowledge proofs (ZKP) can fully implement privacy computing and randomness on-chain and can prove their fairness.
3. Zytron kit: Layer 3 stack. A sovereign rollup L3 chain stack that provides convenient game infrastructure deployment, including peer-to-peer layer optimization, server sharding, etc. It is specifically designed for large-scale multiplayer games and AW construction.

Modular Framework of Zero-Knowledge Proofs: AW Engine#

AW Engine is responsible for building ZKP circuits, generating and verifying proofs, thus occupying a core position in the kit. It includes the following parts:

1. Gadgets: Various small tools used in game circuit development, including basic hashing, ecc, masking, shuffling, etc.
2. Application-specific circuits: Using application-specific plonk as the basic scheme for zk proofs, specific game circuits are written using various small tools provided by the SDK. It supports directly compiling circuits into wasm and can run in browsers or applications. It also provides verification contracts that run on different virtual machines (EVM/WASM/…) that can operate across different blockchain systems, enabling off-chain proof generation and on-chain verification.
3. On-chain verifier: Optimized wasm for provers and verifiers, support for common solidity verifiers across all EVM chains, and Move-lang verifiers for Move-based chains.
4. Z4 Multiplayer PVP Engine: Z4 is a system for real-time multiplayer games. It expands the capacity for handling multiplayer events by outsourcing player-versus-player (PvP) events to dedicated zk-rollup nodes.

The above image describes the working principle and architecture of AW Engine. This game engine is divided into several main parts, and I will explain the function of each part step by step:

1. Zypher Plonk / Bulletproofs / Groth16 / STARKs: These are different zero-knowledge proof schemes. This indicates that the game engine supports multiple types of ZKP schemes, allowing game developers to choose the appropriate proof system based on their needs.

2. General VM/DSL: This refers to a general virtual machine or domain-specific language (DSL) used to write and execute game logic. Zypher Network has officially announced a strategic partnership with Risc Zero, expecting to integrate their general zkVM.

3. Zypher gadgets & circuits: These gadgets and circuits are the foundational modules for building ZKP. In zero-knowledge proofs, gadgets are predefined functions or logic snippets, while circuits are larger computational processes that connect these gadgets.

4. Game Proof Circuit: The game proof circuit is the zero-knowledge proof version of the entire game logic. A circuit is created here to verify game rules without revealing specific actions or strategies of the players.

5. Prover API: The prover API is an interface through which developers generate proofs. In the context of games, this means proving that player actions are conducted according to the game rules.

6. On-chain Verifier API: The on-chain verifier API is another interface used to verify the previously provided proofs. This is done on the blockchain to ensure that every step of the game is fair and transparent.

7. ZK Proof Market: For players on mobile devices, there is a decentralized proof computation market where players can outsource proof computation; this further makes on-chain games hardware-independent.

8. Game: The off-chain computation part of the game contains the actual game logic and user interface, allowing players to play.

9. On-chain Game: After submitting the proof to the blockchain, the game becomes a decentralized and trustless on-chain game. This can be compared to the DA Proof in layer 2 for on-chain operations.

Overall, AW Engine utilizes zero-knowledge proofs to ensure the security and fairness of games. It allows game logic to be verified without exposing any key information, providing a new way to develop and run games on the blockchain.

Finally, let's look at the entire engine's workflow from the developer's perspective:

1. Development Phase:

   - First, developers choose an appropriate zero-knowledge proof scheme (such as Plonk, Bulletproofs, Groth16, or STARKs).

   - Then, they use one of these schemes to create "Zypher gadgets & circuits," which are the building blocks of game logic.

   - These building blocks are combined into a complete "Game Proof Circuit," which is a zero-knowledge circuit capable of proving the validity of the game state without revealing specific information.

2. Proof Generation (Prover API):

   - Each action or state change in the game is converted into a proof in the backend through the "Prover API." This proof is unforgeable and does not disclose any key game data.

   - This proof represents that the player's game action or game state complies with the game rules.

3. On-chain Verification (Onchain Verifier API):

   - The generated proof is then submitted to the blockchain via the "Onchain Verifier API."

   - This on-chain verifier will validate the proof's validity, confirming the legality of the game action or state, ensuring the fairness and correctness of the game.

The above process does not include the Z4 multiplayer battle system. In fact, ZKP can not only make game logic "provable" but also make the "multiplayer battle system" undergo "provable" operations.

The above image is a workflow diagram of the Z4 engine. It can be seen that the Z4 engine supports real-time multiplayer gaming by creating stateless rooms for player matching and games, which are supported by zk-rollup nodes that do not store data. When game logic runs on the nodes, all operations will be sorted and summarized, and verified through zero-knowledge proofs. After the game ends, the proof of operations and conclusions is uploaded to the chain for verification. Z4 nodes can run game logic directly without using a virtual machine, thus avoiding transaction and gas fees. If needed, a virtual machine (such as WASM/EVM) can also be used on the nodes to run game logic. The entire process aims to support millions or even billions of transactions per second across the network to ensure the real-time and high-concurrency performance of the game.

Asymmetric Information Module: Secret Engine#

"Fog of War" is a common mechanism in games, with typical examples including StarCraft and Warcraft 3. This design hides information by covering certain areas of the game map, which only become visible when players explore these areas. This mechanism increases the unpredictability of the game environment and is a typical feature of so-called asymmetric information games. Most popular MMO games adopt asymmetric information game mechanics, providing players with more space for exploration and strategy formulation.

However, in blockchain technology, data is usually completely public and transparent, making it difficult to implement asymmetric information mechanisms. However, the Dark Forest game successfully created an incomplete information game environment on the blockchain by adopting zero-knowledge proof technology zkSNARKs, allowing players to publicly submit verifiable valid actions while maintaining their privacy. In this way, Dark Forest creates an incomplete information game environment on the blockchain. However, this complex information hiding method requires customized ZK circuit programming, making widespread information hiding impractical in on-chain games.

Secret Engine addresses this issue through optimized WASM and precompiled contract components, achieving a high-performance, low-cost decentralized shuffling process via the Shuffle SDK. The shuffling circuits and protocols ensure the secure execution of verifiable encrypted computations, keeping strategic elements confidential on-chain. Besides poker, Monopoly, and trading card games, this SDK can also be applied to other SLG use cases that require trustlessness and randomness, such as:

• Social Deception: In social deception games, players' secret identities or strategies can be protected.
• Secret Placing: Secret placement actions in games, such as hiding units or resource locations, can be securely implemented.
• Fog of War: This can be used to ensure that certain parts of the map remain confidential to certain players until certain conditions are met.

Two commonly used SDKs are:

• zk-Shuffle-as-a-service: Players take turns encrypting and shuffling to generate a "sealed" and randomly ordered deck, providing a solution that traditional random number generators (such as verifiable random functions, VRF) cannot offer.
• zk-Matchmaking-as-a-service: Players submit a "proof seed" to generate a random number and match on-chain, with the entire process being provable through zkp.

This image describes the workflow of the Shuffle SDK:

1. Zypher PlonK:

   - Basic PlonK: This is a general zero-knowledge proof scheme that allows generating proofs to verify the correctness of complex computations without revealing other information.

   - Shuffle selectors: This is logic or configuration specific to the shuffling process, allowing the PlonK proof system to correctly execute the shuffling operation of cards.

2. Shuffle Circuit:

   - Chaum Pedersen: This subcomponent ensures the privacy of the shuffling process. It is usually related to digital signatures or encryption, ensuring that the encryption of each card is secure.

   - Reveal: This step involves securely revealing the identity of the cards when needed without disclosing other card information.

   - Permutation: This refers to the actual process of shuffling, i.e., rearranging the cards.

   - Card Model: This defines the data model of the cards, which is crucial for creating the encrypted versions of the cards and subsequently verifying the shuffling process.

3. Shuffle SDK:

   - Prover SDK (Rust/WASM): This software development kit allows game developers to generate zero-knowledge proofs to prove that the shuffling process is correct without revealing the actual order of the cards.

   - Onchain Verifier SDK (Solidity/WASM/Move): This SDK is used to create on-chain verifiers that validate the correctness of shuffling proofs.

The above introduction may still be too abstract, so let's take an on-chain Texas Hold'em poker as an example to illustrate the principles of the Shuffle SDK.

In the game, we need to store the result of the "shuffled deck" on-chain. This serves not only as the result of the current shuffle but also as public input for subsequent 'shuffles,' as demonstrated in the deck setup operation. Initially, the deck setup defaults to storing the initialized deck. However, it is well known that on-chain storage is costly, especially for large data volumes. A deck of 52 cards consists of a total of 208 uint256 type data, making storage costs a significant consideration.

Zypher's solution is to store only part of the data on-chain after shuffling, specifically, only 2n+5 cards need to be stored, where n is the number of players. Given that currently up to 6 players are supported, a maximum of 17 cards will be used. This means that ultimately only these 17 cards need to be stored on-chain. However, as mentioned earlier, another purpose of on-chain storage is that these cards will also serve as public input for subsequent shuffles. Therefore, if only 17 cards are stored, it will not be possible to verify the correctness of the shuffle.

To address this issue, Zypher's zk-shuffle circuit will output the hash of the complete deck as public input, which is also stored on-chain. When verifying zk-shuffle, users will upload the pre-shuffle deck as public input, and the circuit will compute the hash of the uploaded cards and compare it with the hash stored on-chain. Finally, since only part of the data is stored on-chain, users may need to obtain the complete 52 cards. For this, contract events can be used. Events are a very low-cost communication method that allows users to obtain complete game data by listening to events.

In summary, the core of the entire process is to use zero-knowledge proofs to ensure the privacy and correctness of shuffling. In this way, even when all operations are publicly recorded on the blockchain, players' decisions and strategies can remain private.

Sovereign L3 Stack: Zytron Kit#

Zytron Kit is a highly customizable Layer 3 sovereign rollup stack that supports Zypher's game engine as precompiled contracts.

Existing Dapp infrastructure, primarily EVM, has not been optimized for on-chain games that require high responsiveness and has failed to provide the necessary cost efficiency and scalability. MMOs and other high-performance games require dedicated, customized infrastructure equipped with efficient and predictable computing resources. Zytron's first alpha network, featuring 0 gas, 0.2S block time, and precompiled contracts designed for games, will be launched soon, with 10 games planned as pioneer testers.

The kit provides four plug-and-play core components:

• Sovereign Rollup: The most important aspect of a game is playability, which requires the highest availability (CAP) in a distributed system, and the entire system can be quickly upgraded and automatically deployed.
• Server Sharding: Distributes the game world map across different nodes to improve the capacity of individual nodes. At the same time, it provides a set of efficient retrieval algorithms to quickly move between different nodes on the global map, switch between different node services, and synchronize information.
• Data Compatibility: A component crucial for storage abstraction, this protocol integrates more user-friendly relational and caching databases to accelerate game data processing. This feature addresses the need for efficient data management and quick access, which is vital for maintaining a smooth gaming experience.
• Custom Network: Given the high network demands of games, this framework optimizes the underlying peer-to-peer (P2P) network layer to support gaming scenarios. This includes optimizing message transmission within groups, using NAT traversal and hole-punching techniques to achieve fast and efficient connections. Additionally, the network has designed a special UDP protocol for games, aimed at keeping latency below 10 milliseconds. This ensures fast and reliable data transmission, which is crucial for real-time gaming experiences.

Sovereign Rollup is a relatively new concept that adds a higher level of autonomy and flexibility on top of ordinary Rollups, allowing independent blockchain networks with full autonomy features to be built on it. This means that each sovereign Rollup can have its own consensus mechanism, state machine, and governance model while still maintaining compatibility with the main chain.

Through the above framework diagram, we can understand the functions of various components of the Zytron stack:

1. Core components provide the infrastructure for the game chain, allowing for high customization and optimization.

   - The sovereign Rollup ensures the playability and high availability of the game, supporting rapid upgrades and automatic deployments of the system.

   - Server sharding improves the load capacity of individual nodes by distributing the game world across multiple nodes.

   - Data compatibility ensures the rapid processing of game data by integrating user-friendly database systems.

   - The custom network optimizes the underlying P2P network layer to meet the high network demands of games, including optimizing message passing between groups and reducing latency.

2. On-chain components include the foundational parts running on-chain to ensure the correctness of game logic and the security of assets.

   - On-chain verifiers ensure that all transactions and game operations are valid and legal.

   - Smart contracts serve as the encoded carriers of game rules and logic, handling interactions between players and changes in game state.

3. Modular components provide implementations of specific game functions and services.

   - The ZK system supports privacy protection, such as privacy computing and verification.

   - The account system and instant messaging system provide user management and real-time communication functions.

   - The monitoring system is used to monitor network conditions and game operation status.

   - The room system, financial system, and AI system provide in-game room management, financial transactions, and AI support.

   - The logging system records all operations and events for analysis and debugging.

The above image shows the workflow of the Zytron kit stack:

• Transactions are first generated on Layer 3, sorted by the Sequencer.
• Runner nodes listen to events from Layer 1/2 and outputs from the Sequencer, communicating between them to execute transactions and achieve consensus for service sharding.
• Data is periodically submitted to Celestia to ensure data availability and security.
• Clients interact with Layer 3 through lightweight synchronization and can call services provided by Layer 3.

Interestingly, the previous two engine kits, including AW Engine and Secret Engine, can be integrated with the Zytron kit in a precompiled form, providing efficient, responsive, and feature-rich infrastructure for on-chain games in a more streamlined manner. Developers can also choose the corresponding components according to their needs to create a chain environment that fits their game design. Zypher not only supports the ETH ecosystem but is also actively exploring the possibilities of on-chain games and L3 in the BTC ecosystem. Zypher and BTC's Layer 2 B² Network have announced a partnership to deploy a dedicated Layer 3 for on-chain games based on B² Network and its DA Layer B² Hub, which will be the first Layer 3 in the BTC ecosystem to support on-chain games. Zypher has become one of the first engines supporting on-chain game development in the BTC ecosystem.