Author: Maggie Wang (COO of Zypher Network)

“Galaxia,” an upcoming CCG game based on TON (using Zypher's SDK)

Recently, I have been contemplating the essence of on-chain games and the necessity for a new paradigm. I tend to agree with this rather than the recent claim that "Web3 games are dead."

Games Are Also a Common Topic

In Web3, all validated business models are innovations of "asset issuance," such as btc, brc20, defi, and meme; they all revolve around "decentralization," thus being permissionless, decentralized, censorship-resistant, and fair, realized and automated by smart contracts, making them essentially fully on-chain. Blockchain represents a new mode of production.

However, in terms of games, we do not take this FOC (Fully On-Chain) paradigm for granted. In the past cycle, billions of dollars were poured into blockchain games (fantasizing that it could replicate the DeFi revolution for 3 billion gamers again), primarily relying on the paradigm of "asset on-chain," hoping to bring some anticipated benefits from the asset perspective (where assets refer to monetary assets, i.e., anything of economic value to gamers, rather than visual assets in game development), such as:

• Digital ownership ------ seeing and owning game loot in your wallet.
• Asset composability ------ loot from game A can be used in games B/C/D.
• Financialization of achievements ------ achievements earned after spending hundreds of hours in-game can be traded.

However, if these games run on centralized servers, the above advantages are undermined:

• Centralized asset policies ------ for example, drop rates can be changed at any time.
• Centralized operations ------ games can be shut down at any time, just like any Web 2.0 game.

A typical representative of "decentralized asset policies in games" is "Autonomous Worlds" (many excellent statements can be found on aw.network), where many great teams are using smart contract-driven FOCG game engines to move towards the AW endgame (salute to the explorers).

However, we are looking for an alternative, more cost-effective approach to fit today's infrastructure.

"What if we could use the original purpose of blockchain, which is asset accounting, while shifting the more expensive game execution off-chain, but still ensure that asset policies are fair (fair means a way that everyone agrees upon)?"

This would have the same "original intention" as any contract-based fully on-chain approach - decentralization, but more cost-effective.

• It is easier to use.
• It will lower the barrier for more independent developers.
• It supports open, democratic economic forms.
• It opens the door for community-oriented operations.

Watch us

What is Zypher Network?

(What is described above is the modular solution that Zypher is building after we abstract the functionalities we can outsource to partners.)

Zypher Network is a protocol for verifiable in-game assets and data accessibility, consisting of two parts:

1. Circuit Market: for developing verifiable game logic.
2. Proof Market: for incentive proof computation for verifiable games.

Make ZK Great Again?

The hype around ZK has shifted from narrative-driven and VC-driven to adoption and application-driven, thus driving the emergence of consumer-grade products. Our collaboration with a series of modular infrastructure protocols in the ZK space, such as Gevulot and Risc Zero, has significantly enhanced the feasibility of Zypher's products. We see that as the shift from monolithic to modular occurs, the cost of proof computation and the difficulty for new developers to quickly develop "fast-moving" products are decreasing.

Circuit Market:

Circuit-based game logic is executed off-chain and can be verified by on-chain validators. For developers, we provide simpler options for building such game logic, such as using Risc Zero (@nuke_web3's workshop) to implement arbitrary logic, or providing an SDK with logic templates (for example, using COCO as the frontend and our SDK as the backend). Our cryptographers @sunhuachuang have done extensive circuit design to achieve efficient game execution, especially in the PlonK implementation. We support two types of in-game data:

• Valid "random" or "encrypted" in-game data. For example, during shuffling, the card information remains hidden compared to "centralized VRF."
• Validity of "off-chain executed" game states. For better multiplayer responsiveness, we have also designed on-demand 0-gas zk-rollup infrastructure to handle game states. Xn = F(F(F(F(F(…F(x0))))))

Proof Market

Gevulot published an excellent article on "ZK Endgame," which provides profound insights into how ZK computation can become more affordable and approach zero cost. We designed a decentralized proof computation market based on a Cobb-Douglas algorithm hybrid PoS-PoW mechanism for mining reward distribution. We call it true DePin, as proof sizes can range from 100k to 150m, which can be handled by anything from M1 to GPU to more specialized servers (like FPGA/ASIC @cysic_xyz).

Will Telegram Bot Dream of Electric Sheep?

Here are some observations from the past few years:

• In terms of playability, you cannot really beat Web2.0 games. You can only strive to match them.
• The users of games will differ, possibly: 80% web3 native users (assuming half are bounty hunters and half are long-term token holders) + 20% web2 users who are not very familiar with web3.
• Blockchain is a system guarantee of distributed ownership, not a guarantee of decentralization; compared to Half-life or Quake, today's blockchain games are actually less decentralized and creator-economy-oriented.

“Do Androids Dream of Electric Sheep?” Philip K. Dick's novel

Before starting the game demo, you might conduct a whole "from release to production" decision experiment:

Where do our first users come from? > Where to find more users? > Prerequisites for community models? > Game types? > Production budget? > What is on-chain? > What infrastructure? > What tools?

Here is an example of a release strategy using Zypher tools, inferred backward:

1. Step one: Developers build a tap game as a Telegram Mini App. The reason is that developers want to leverage the integrated TON native wallet and the application center of Telegram to target TG's 800 million efficient users for customer acquisition, but deeper user retention is needed.
2. Step two: Use the Zypher game engine to expand from the tap game to a verifiable on-chain casual game. The reason is that the verifiable assets and provably fair game development components provided by Zypher allow the game to not only maintain the web2 gaming experience but also make the game process fairer and more transparent, facilitating community oversight and construction, thus better user retention. However, on-chain casual games require more development resources.
3. Step three: Use the Zypher SDK to build new gameplay. The reason is that Zypher provides development kits for casual games like match-three and card battles, reducing development costs.
4. Step four: When the number of game users exceeds the available block space, seamlessly migrate to a game-specific Layer 2 or Layer 3 using Zypher's Zytron kit. The reason is that zk is used for game verification, far exceeding the limitations of the initial validator deployment, making it more suitable for game development.
5. Step five: Achieve community ownership over time. Transform it into an infinite game. The reason is the community-participatory game model design, with the community operating the game.

Using our development tools has the following benefits to support the aforementioned release strategy:

• Matches Web2.0 UX. Compared to pure smart contract execution methods, the gaming experience is no longer limited by infrastructure performance (including tps), potentially supporting thousands of concurrent players at a low cost.
• Simple development experience. Ready-made development interfaces/simple SDKs support COCOs, Unity, and other toolkits; easily migrate any existing casual game, such as WeChat mini-apps. Developers can combine different gameplay/logics, such as using existing game logic LEGO to build adventures like Farm Escape!
• Easy migration/lightweight. Games execute off-chain and verify on-chain; blockchain is mainly used for verification; the cost of migrating or verifying across different chains is very low since there are no centralized servers. Adding support or switching between different interfaces or chains is very easy.
• Native Web 3.0 gameplay, like AW. Modding has always been a driving force in gaming, and we look forward to seeing more innovative Web3 native gameplay within our framework. In addition to easily migrating proven classic gameplay, new gameplay with unique features can be designed utilizing provable fairness.

We attempted to convert a web browser-based 2048 game into a TON mini-app within 2 days.