How to develop verifiable on-chain games with Zypher?

Since Dojo of the Starknet ecosystem proposed the concept of provable on-chain games, many teams have begun to explore in this field, such as paima using NFT state compression, redux using Merkle tree and state inscriptions, and so on. Zypher Network (@Zypher_Network) has also released a series of developer kits based on zk-SNARKs technology to help make verifiable on-chain games.

What is a verifiable on-chain game

We now know that the combination of the game industry and Blockchain technology will either take the GameFi mode of asset on-chain, or the on-chain game mode of state on-chain. The general definition of an on-chain game is this: all game logic, state (assets and others) are on the on-chain, implemented through smart contracts.

As a smart contracts platform, Ethereum is naturally a distributed state machine that can do slightly simpler on-chain calculations and state verification. So everyone tried to write the game logic into the smart contracts, so that the game became a decentralization game without a server backend, and brought a higher degree of composability in terms of game rules. However, the problem also arises: the computing power of Ethereum Mainnet is too weak, and the cost of use is very high, even if you consider using high-performance layer2 chains or other public chains, it cannot meet the needs of on-chain games

Inspired by the layer2 rollup, since larger-scale transfer operations can be verified off-chain computation on-chain on-chain why not handle the execution of game logic in the same way? Although the game logic is calculated off-chain, each step of the operation can be verified on the on-chain, which also ensures the decentralization and trustlessness of the game, which is where the word “verifiable” comes from, and even we can simply analogize: the TX in the layer2 rollup is an ordinary transfer transaction, and the TX in the verifiable on-chain game is the on-chain transaction of the game.

Depending on the on-chain verification method, rollups are divided into OP-rollups and ZK-rollups. Similarly, verifiable on-chain games using zk-SNARKs have outstanding advantages in terms of finality and performance of state verification, which is why Dojo and Zypher Network chose ZKP to develop verifiable on-chain games.

Zypher Network Developer Kit

Zypher Network’s developer kit consists of 3 parts, namely AW Engine, Secret Engine and Zytron kit.

1. AW Engine: Leverages ZKP’s information compression capabilities to provide scalability. A modular framework that enables the game to be vertically super scalable. Programmable via circuit or zkVM. Its z4 SDK can support real-time in-game longing events (player vs. player).

2. Secret Engine: ZKP’s information hiding ability is used to provide asymmetric information games. A software development kit for zk-SNARKs as a service that provides information asymmetry for games that require strategy mechanics. ZK-SNARKs (ZKPs are able to fully implement privacy computation and randomness on the on-chain and can prove their fairness.

3. Zytron kit: Layer 3 stack. A sovereign rollupL3 chain stack that provides convenient deployment of game infrastructure, including peer-to-peer layer optimization, server sharding, and more. Designed for massive longing games and AW construction.

AW Engine, a modular framework for zk-SNARKs

AW Engine is responsible for the construction of the ZKP circuit, the generation of proofs and the verification of proofs, so it is at the heart of the suite. It consists of the following sections:

1. Gadgets (gadgets): Support various gadgets used in game circuit development, including basic hashes, ecc, masks, shuffling, etc.
2. Application-specific circuits: Use application-specific plonk as the basic scheme for zk proofs, and write specific game circuits through various gadgets provided by the SDK. It supports compiling circuits directly into wasm and can run them in a browser or application. At the same time, it also provides the ability to operate in different Virtual Machine (EVM/WASM/… These contracts can run in different Blockchain systems to achieve off-chain proof-generation and on-chain verification.
3. On-chain validators: wasm optimized for provers and validators, as well as support for common solidity validators for all EVM chains, and Move-lang validators for Move-based chains.
4. Z4 longing PVP engine: Z4 is a system for real-time longing games. It scales longing event processing capabilities by outsourcing player versus player events (PvP) to dedicated zk-rollup nodes.

The diagram above depicts 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 section step by step:

1. Zypher Plonk / Bulletproofs / Groth16 / STARKs: These are all different zk-SNARKs schemes. This shows that the game engine supports longest types of ZKP schemes, allowing game developers to choose the appropriate proof system according to their needs.

2. General VM/DSL: This refers to a general-purpose 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, which is expected to integrate his family’s generic zkVM.

3. Zypher gadgets & circuits: These gadgets and circuits are the basic building blocks for building ZKPs. In zk-SNARKs, gadgets are predefined functions or pieces of logic, and circuits are the larger computational processes that connect these gadgets.

4. Game Proof Circuit: The Game Proof Circuit is a zk-SNARKs version of the entire game logic. Here, a circuit is created that validates the rules of the game without revealing the player’s specific actions or strategies.

5. Prover API: The Prover API is an interface through which developers generate proofs. In the context of the game, this means proving that the player’s actions were carried out in accordance with the rules of the game.

6. Onchain Verifier API: The on-chain validators API is another interface for verifying the aforementioned provided attestations. 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 Decentralization Proof Computation Marketplace where players can outsource Proof Computation; this further makes on-chain gaming hardware-agnostic.

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

9. Onchain Game: After submitting the proof to the Blockchain, the game becomes a Decentralization and Trustless on-chain game. It can be compared to DA Proof in layer2 for on-chain operation.

Overall, AW Engine leverages zk-SNARKs to ensure the security and fairness of the game. It allows game logic to be verified without exposing any critical information, providing a new way to develop and run games built on the Blockchain.

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

1. Development Stage:

• First, developers choose the appropriate zk-SNARKs scheme (such as Plonk, Bulletproofs, Groth16, or STARKs).

• They then use one of these scenarios to create “Zypher gadgets & circuits”, which are the building blocks of the game’s logic.

• These building blocks are combined into a complete “Game Proof Circuit”, which is a zero-knowledge circuit that proves the validity of the game state without revealing specific information.

2. Proof Generation (Prover API) :

• Every action or state change in the game is converted into a proof on the backend via the “Prover API”, which is unforgeable and does not reveal any critical game data.

• This proof means that the player’s game action or game state is in accordance with the rules of the game.

3. on-chain Authentication (Onchain Verifier API) :

• The generated proof is then submitted to the Blockchain via the “Onchain Verifier API”.

• This on-chain validator will verify the validity of the proof of validation, confirm the legitimacy of the game action or state, and ensure the fairness and correctness of the game.

The above process does not include the Z4 longing battle system, in fact, ZKP can not only “verify” the game logic, but also “verify” the “longing battle system”.

The image above is a workflow diagram of the Z4 engine, and it can be seen that the way the Z4 engine supports real-time long player games is to create stateless rooms for player matchmaking and gameplay, which are Node support by zk-rollup, Node do not save data. When the game logic runs on the Node, all operations are sorted and summarized, and are confirmed by zk-SNARKs. After the game ends, the proof of the operation and conclusion is uploaded to the on-chain for verification. Z4 Node can run game logic directly without using a virtual machine, avoiding transaction and gas fees. Virtual Machine (such as WASM/EVM) can also be used on the Node to run game logic if needed. The entire process is designed to support network-wide volumes of millions or even billions per second to ensure real-time and high concurrency performance of the game.

Asymmetric information module Secret Engine

Fog of War is a mechanic commonly found in games, with typical examples including StarCraft and Warcraft 3. This design hides information by covering certain areas of the game map, which are only revealed when the player explores those areas. This mechanic increases the unpredictability of the game environment and is typical of so-called asymmetric information games. Most of long popular MMO games feature asymmetrical information game mechanics, which provide players with a more long short to explore and strategize.

However, in Blockchain technology, data is usually completely open and transparent, which makes it difficult to implement asymmetric information mechanisms. However, by employing zkSNARKs, a zk-SNARKs technology, Dark Forest games succeed in maintaining their privacy status while players need to publicly submit verifiably valid actions. In this way, Dark Forest creates a game environment with incomplete information on the Blockchain. However, this complex information hiding method requires custom ZK circuit programming, so extensive information hiding cannot be implemented in on-chain games.

Secret Engine partially solves this problem with optimized WASM and precompiled contracts, and implements a high-performance, low-cost Decentralization shuffle process through Shuffle SDK. Shuffling circuits and protocol guarantee the secure execution of verifiable encryption computations, ensuring that policy elements remain confidential in on-chain. In addition to poker, Monopoly, and trading card games, the SDK can be applied to other SLG use cases that require trustless and randomness, such as:

Social Deception: A social deception game that protects the player’s secret identity or strategy. Secret Placing**:** Secret placement actions in the game, such as hiding units or resource locations, can be safely implemented. Fog of War:* is the Fog of War, which can be used to ensure that certain parts of the map are kept secret from certain players until certain conditions are met.

There are two SDKs that are commonly used:

zk-Shuffle-as-a-service:* Players take turns encryption and shuffling the cards to produce a “sealed” and randomly sorted deck of cards, which provides a solution that traditional random number generators such as Verifiable Random Functions (VRFs) cannot provide. zk-Matchmaking-as-a-service:* Players submit a “proof seed” to generate a random number and match it on-chain, the whole process can be proven through zkp.

This image depicts the workflow of the Shuffle SDK:

1. Zypher PlonK:

• Basic PlonK: This is a general-purpose zk-SNARK proof scheme that allows proofs to be generated to verify the correctness of complex calculations without revealing additional information.

• Shuffle selectors: These are logic or configurations specific to the shuffling process that allow the PlonK proof system to correctly perform the shuffling of the cards.

2. Shuffle Circuit:

• Chaum Pedersen: This sub-component is used to ensure the privacy of the shuffling process. It is usually related to digital signatures or encryption, where the encryption of each card is secure.

• Reveal: This step involves securely revealing the identity of a card when needed, without revealing information about other cards.

• Permutation: This refers to the actual process of shuffling the cards, i.e. the rearrangement of the cards.

• Card Model: This defines the data model of the card, which is essential in creating the encryption version of the card and later verifying the shuffle.

3. Shuffle SDK:

• Prover SDK (Rust/WASM): This software development kit allows game developers to generate zk-SNARKs 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 validators and verify the correctness of shuffle proofs.

The above introduction may still be too abstract, let’s use an on-chain Texas Hold’em as an example to illustrate the principle of the Shuffle SDK.

In the game, we need to store the results of the “shuffled pile” on the on-chain. This serves not only as a result of the current shuffle, but also as a common input for subsequent ‘shuffles’, as demonstrated in the Set Up Pile operation. Initially, set the deck to store the initialized deck by default. However, on-chain storage is notoriously expensive, especially for large data volumes. A deck of 52 cards consists of a total of 208 uint256 types of data, making storage costs an important consideration.

Zypher’s solution is to store only part of the data on the on-chain after shuffling, specifically, only need to store 2n+5 cards, where n is the number of players. Given that long 6 players are currently supported, 17 cards are long at most. This means that in the end only those 17 cards need to be stored on the on-chain. But as mentioned earlier, another purpose of on-chain storage is that these cards will also serve as a common input for subsequent shufflings. Therefore, if only 17 cards are stored, it is impossible to verify the correctness of the shuffle.

To solve this problem, Zypher’s zk-shuffle circuit additionally outputs the hash of the full deck as a common input, which is also stored on-chain. When verifying zk-shuffle, the user uploads the pre-shuffle stack as a common input, and the circuit calculates the hash of the card uploaded by the user and compares it to the hash stored on the on-chain. Finally, since only part of the data is held on-chain, users may need to acquire the full 52 cards. For this, contract events can be used. Events are an extremely low-cost method of communication that allows users to listen to events for complete game data.

In summary, the core of the whole process is the use of zk-SNARKs to guarantee the privacy and correctness of the shuffle. In this way, players’ decisions and strategies remain private, even if all actions are publicly recorded on the Blockchain.

Sovereign L3 stack Zytron kit

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

Existing Dapp infrastructure, primarily EVMs, did not have the long wick candle to optimize for highly responsive use cases such as on-chain games, and failed to provide the required cost efficiency and scalability. MMOs and other high-performance games require dedicated, customized infrastructure with efficient and predictable computing resources. Zytron’s first alpha network, featuring 0 gas, 0.2S block time, precompiled contracts designed specifically for games, will be launched in the near future, with 10 games planned as pioneer testers.

The kit offers 4 plug-and-play core components:

Sovereign Rollup: The most important thing in the 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: Distribute the game’s world map across different nodes to increase the carrying capacity of a single node. 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 critical to storage abstraction, the protocol integrates more user-friendly relational and caching databases to speed up game data processing. This feature addresses the need for efficient data management and fast access, which is essential for maintaining a smooth gaming experience. Custom Networking: Given the game’s high networking needs, the framework optimizes the underlying peer-to-peer (P2P) Network Layer to support gaming scenarios. This includes optimizations for intra-group messaging, using NAT traversal and hole-punching techniques for fast and efficient connections. In addition, the network has long wick candle designed a special UDP protocol for the game, which is designed to keep the latency below 10 milliseconds. This ensures fast and reliable data transfer, which is essential for real-time gaming experiences.

Sovereign rollups are a newer concept that adds a higher level of autonomy and flexibility to normal rollups, allowing independent Blockchain networks with full autonomy to be built on top of them. This means that each sovereign rollup can have its own Consensus Mechanism, state machine, and governance model, while still maintaining compatibility with mainchain.

From the above frame diagram, we can understand the functions of each component of the Zytron suite:

**1. The core components provide the infrastructure of the game chain, allowing for a high degree of customization and optimization. **

• Sovereign Rollup guarantees the playability and high availability of the game, supporting rapid upgrades and automatic deployment of the system.

• Server Sharding increases the load capacity of a single Node by distributing the game world across long Node.

• Data compatibility ensures fast processing of game data by integrating a user-friendly database system.

• Custom network optimizes the underlying P2P Network Layer to meet the game’s high network demands, including optimized messaging between groups and reduced latency.

**2. On-chain components contain the basic parts running on the on-chain to ensure the correctness of game logic and the security of assets. **

• On-chain validators ensure that all transactions and game operations are valid and legitimate.

• Smart contracts serve as the coding carrier of game rules and logic, handling the interaction between players and the change of game state.

**3. Module components provide the implementation of specific game features and services. **

• The ZK system provides support for privacy protections, such as privacy-preserving computation and verification.

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

• Monitoring systems are used to monitor network conditions and game health.

• Room systems, financial systems, and AI systems provide in-game room management, financial transactions, and AI support.

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

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

• Transactions are first generated on Layer 3 and are ordered by Sequencer.
• Runner Node listens to Layer 1/2 events and Sequencer output, and they communicate with each other to execute transactions and reach consensus to implement service Sharding functionality.
• Data is submitted to Celestia on a regular basis to ensure the availability and security of the data.
• Clients interact with Layer 3 through lightweight synchronization and can invoke services provided by Layer 3.

More interestingly, the first two engine suites, including AW Engine and Secret Engine, can be integrated with the Zytron kit in a precompiled form to provide an efficient, responsive, feature-rich infrastructure for on-chain games in a more minimalist form. Developers can also choose the appropriate components according to their needs to create a chain environment that matches their game design. Zypher not only supports the ETH ecosystem, but is also actively exploring the possibility of on-chain games and L3 in the BTC ecosystem, Zypher and BTC’s Layer2 B² Network officially announced that it will deploy on-chain game-exclusive Layer 3 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 the first on-chain game development engine to support the BTC ecosystem.