Since the Dojo of the Starknet ecosystem proposed the concept of provable onchain games, many teams have begun to explore in this field, such as using NFT state compression like Paima, using Merkle trees and state inscriptions like Redux, and so on. Zypher Network (@Zypher_Network) has also released a series of developer kits based on zero-knowledge proof technology to help create provable onchain games.

What is a Provable Onchain Game

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

As Ethereum, as a smart contract platform, is naturally a distributed state machine, it can perform slightly simpler onchain calculations and state verification. Therefore, everyone tried to write game logic into smart contracts, making games a type of decentralized game without the need for a server backend, and bringing a higher degree of composability in terms of game rules. However, problems followed: Ethereum's mainnet computing power is too weak, and the usage cost is also very high. Even considering the use of high-performance layer2 chains or other public chains, it still cannot meet the needs of onchain games.

Inspired by layer2 rollup, since larger-scale transfer operations can be performed through off-chain computation and on-chain verification, why not also handle the execution of game logic in the same way? Thus, the technical route of provable onchain games was born. Although the game logic is computed off-chain, each step can be verified on-chain, ensuring the decentralization and trustlessness of the game, hence the origin of the term "provable." We can even make a simple comparison: the TX in layer2 rollup is a normal transfer transaction, while the TX in provable onchain games is the onchain transaction of the game.

According to the different onchain verification methods, rollup is divided into OP-rollup and ZK-rollup. Similarly, using zero-knowledge proof technology for provable onchain games has outstanding advantages in both finality of state verification and performance, which is why Dojo and Zypher Network chose ZKP to develop provable onchain games.

Zypher Network Developer Kits

Zypher Network's developer kits consist of three parts: AW Engine, Secret Engine, and Zytron kit.

1. AW Engine: It provides scalability using ZKP's information compression capability. It is a modular framework that enables games to be vertically super-scalable. It can be programmed through circuits or zkVM. Its z4 SDK can support real-time in-game multiplayer events (player battles).

2. Secret Engine: It provides asymmetric information warfare using ZKP's information hiding capability. It is a software development toolkit for zero-knowledge proof as a service (zk-as-a-service), providing information asymmetry for games that require strategic mechanisms. Zero-knowledge proof (ZKP) can fully implement privacy computation and randomness on-chain and can prove its fairness.

3. Zytron kit: Layer3 stack. It is a sovereign rollup L3 chain stack that provides convenient deployment of game infrastructure, including point-to-point layer optimization, server sharding, etc. It is designed for large-scale multiplayer games and AW construction.

Modular Framework of Zero-Knowledge Proof - AW Engine

AW Engine is responsible for building ZKP circuits, proof generation, and verification, so it occupies a core position in the suite. It includes the following parts:

1. Gadgets: It supports various small tools used in game circuit development, including basic functions such as hash, ECC, masking, shuffling, etc.
2. Application-specific circuits: It uses application-specific plonk as the basic solution for zk proof, writing specific game circuits using various small tools provided by the SDK. It supports direct compilation of circuits into wasm and can run in a browser or application. It also provides verification contracts running on different virtual machines (EVM/WASM/…) that can run in different blockchain systems, achieving off-chain proof generation and on-chain verification.
3. Onchain verifiers: Optimized wasm for provers and verifiers, support for common solidity verifiers for 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 extends the capability of handling multiplayer events by outsourcing player battle events (PvP) to dedicated zk-rollup nodes.

The above diagram describes the working principle and architecture of the 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 according to their needs.

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

3. Zypher gadgets & circuits: These tools and circuits are the basic modules for building ZKP. In zero-knowledge proofs, gadgets are pre-defined functions or logical segments, and circuits are larger computational processes connected by these gadgets.

4. Game Proof Circuit: The game proof circuit is the zero-knowledge proof version of the entire game logic. A circuit will be created here to verify the 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 the game, this means proving that players' actions are in accordance with the game rules.

6. Onchain Verifier API: The onchain verifier API is another interface used to verify the proofs provided above. 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, further making onchain games hardware-independent.

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

9. Onchain Game: After submitting proofs to the blockchain, the game becomes a decentralized and trustless onchain game. It can be compared to the DA Proof in layer2 for onchain operations.

In summary, AW Engine uses zero-knowledge proofs 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 on the blockchain.

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

1. Development Phase:

• First, developers choose the 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 that can prove 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 in the backend through the "Prover API." This proof is tamper-proof and does not reveal any critical game data.

• This proof represents that the player's game actions or game state comply with the game rules.

3. Onchain Verification (Onchain Verifier API):

• The generated proof is then submitted to the blockchain through the "Onchain Verifier API."

• This onchain verifier validates the proof's validity, confirming the legitimacy of game actions or states, ensuring the fairness and correctness of the game.

The above process does not include the Z4 multiplayer battle system. In fact, in addition to making the game logic "provable," ZKP can also make the "multiplayer battle system" "provable."

The above image shows the workflow of the Z4 engine. It can be seen that the Z4 engine supports real-time multiplayer games by creating stateless rooms for player matching and gaming, supported by zk-rollup nodes that do not store data. When the game logic runs on the nodes, all operations are ordered and summarized, and verified through zero-knowledge proofs. After the game ends, proofs of operations and conclusions are uploaded to the chain for verification. Z4 nodes can run game logic directly without using a virtual machine, avoiding transaction and gas costs. 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 real-time and high-concurrency game performance.

Asymmetric Information Module - Secret Engine

"Fog of War" is a common mechanism in games, typical examples include "StarCraft" and "Warcraft III." This design hides information by covering certain areas of the game map, which are only revealed when players explore those areas. This mechanism increases the unpredictability of the game environment and is a typical feature of asymmetric information games. Most popular MMO games adopt asymmetric information game mechanisms, providing players with more space for exploration and strategic planning.

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 maintains its privacy status while requiring players to publicly submit verifiable valid actions by adopting zero-knowledge proof technology zkSNARKs. 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 impossible in onchain games.

The Secret Engine solves this problem through optimized WASM and precompiled contract parts, implementing a high-performance, low-cost decentralized shuffling process through the Shuffle SDK. The shuffling circuit and protocol ensure the secure execution of verifiable encrypted computations, ensuring that strategic elements remain confidential on-chain. In addition to 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: Protecting players' secret identities or strategies in social deception games.
• Secret Placing: Securely implementing secret placement actions in games, such as hiding unit or resource locations.
• Fog of War: Ensuring that certain parts of the map are kept secret from certain players until certain conditions are met.

The frequently used SDKs are:

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

The image above describes the workflow of the Shuffle SDK:

1. Zypher PlonK:

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

• Shuffle selectors: These are specific to the shuffling process, allowing the PlonK proof system to correctly execute the shuffling operations.

2. Shuffle Circuit:

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

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

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

• Card Model: This defines the data model of the cards, crucial in creating the encrypted versions of the cards and verifying the shuffling process.

3. Shuffle SDK:

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

• Onchain Verifier SDK (Solidity/WASM/Move): This SDK is used to create onchain verifiers to verify the correctness of the shuffling proofs.

The above introduction may still be too abstract. Let's take the example of onchain Texas Hold'em to explain the principles of the Shuffle SDK.

In the game, we need to store the "shuffled deck" result on-chain. This not only serves as the current result of shuffling but also as the public input for subsequent "shuffling," 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 costs are high, 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 a portion 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, support for up to 6 players is available, a maximum of 17 cards are used. This means that only these 17 cards need to be stored on-chain in the end. However, as mentioned earlier, another purpose of on-chain storage is that these cards will also serve as the public input for subsequent shuffling. Therefore, if only 17 cards are stored, the correctness of the shuffling cannot be verified.

To address this issue, Zypher's zk-shuffle circuit will output the hash value of the complete deck as additional public input, which is also stored on-chain. When verifying zk-shuffle, users will upload the deck before shuffling as public input, and the circuit will calculate the hash value of the cards uploaded by the user and compare it with the hash value stored on-chain. Finally, since only partial data is saved on-chain, users may need to obtain the complete 52 cards. For this, contract events can be used. Events are a 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 though 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 a precompiled contract.

Existing Dapp infrastructure, mainly EVM, is not optimized for use cases requiring high responsiveness, and fails to provide the required cost efficiency and scalability. MMO and other high-performance games require dedicated, customized infrastructure with efficient and predictable computing resources. The first alpha network of Zytron, 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 4 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's world map to different nodes to increase the load capacity of individual nodes. It also provides an efficient retrieval algorithm to quickly move between different nodes on the global map, switch between different node services, and synchronize information.
• Data Compatibility: An essential component for abstract storage, this protocol integrates more user-friendly relational and cache databases to speed up game data processing. This feature addresses the need for efficient data management and fast access, crucial for maintaining a smooth gaming experience.
• Customized Network: Optimizes the underlying peer-to-peer (P2P) network layer to support game scenarios. This includes optimizing message transmission within groups, achieving fast and efficient connections using NAT traversal and hole punching techniques. Additionally, the network has a special UDP protocol designed for games to keep latency below 10 milliseconds. This ensures fast and reliable data transmission, crucial for real-time gaming experiences.

Sovereign Rollup is a relatively new concept that adds a higher level of autonomy and flexibility to the basic Rollup, allowing for the construction of independent blockchain networks with full autonomous functionality. This means that each Sovereign Rollup can have its own consensus mechanism, state machine, and governance model, while still remaining compatible with the main chain.

From the framework diagram above, we can understand the functions of the various components of the Zytron kit:

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

• Sovereign Rollup ensures the playability and high availability of the game, supporting rapid system upgrades and automatic deployment.
• Server sharding increases the load capacity of individual nodes by distributing the game world across multiple nodes.
• Data compatibility ensures fast processing of game data by integrating user-friendly database systems.

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

• Onchain verifiers ensure that all transactions and game operations are valid and legal.
• Smart contracts serve as the encoding carrier for game rules and logic, handling player interactions and changes in game state.

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

• The ZK system supports privacy protection, such as privacy computation 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 operations.
• The room system, financial system, and AI system provide game room management, financial transactions, and AI support within the game.
• The log system records all operations and events for analysis and debugging.

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

• Transactions are first generated on Layer 3 and sorted by the Sequencer.
• Runner nodes listen to events on Layer 1/2 and the output of the Sequencer, communicating between them to execute transactions and achieve consensus to implement service sharding.
• Data is regularly 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.

What's more interesting is that the previous two engine suites, including the AW Engine and Secret Engine, can be integrated with the Zytron kit in precompiled form to provide efficient, responsive, and feature-rich infrastructure for onchain games in a more concise form. Developers can also choose the appropriate 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 onchain games and L3 in the BTC ecosystem. Zypher has announced a collaboration with the BTC Layer2 B² Network, stating that it will deploy a dedicated Layer 3 for onchain games based on the B² Network and its DA Layer B² Hub, making it the first Layer 3 to support onchain games in the BTC ecosystem. Zypher has become one of the first onchain game development engines to support the BTC ecosystem.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。