The Dilemma and Solution of Web3 Games

Author: Lola, Delphinus Lab

With the phenomenal popularity of "Black Myth: Wukong", there is another voice in the circle that is pessimistic about Web3 games. In the recent very depressed and self-doubting market environment, another layer of debuff is superimposed.

Do Web3 people not love games? It is true that in the early bubble stage of the market, a strong speculative atmosphere is inevitable, but many builders still rush into this industry with the intention of making a good game, a game that truly belongs to players. If Web3 wants to achieve real mass adoption, games are also an inevitable path that can not be avoided and can penetrate the sinking market the most.

But the reality is bleak. When people want to count the first-line games of Web3, they find that there are very few quality games, and most of the games are mediocre. They neither provide players with a good user experience nor meet the expectations of mass adoption. A large number of game teams with successful practical experience in Web2 failed in Web3. I understand the reasons as follows:

1. Compared with traditional games, Web3 games are difficult to provide continuous game content updates

2. Due to different audiences, Web3 games need to consider more game economics issues other than gameplay than traditional games

Dilemma of updating game content

For a game to maintain long-term vitality, updates and patches are essential; otherwise, bugs cannot be fixed, and players' sense of freshness is difficult to last. In traditional game development, if the data structure does not change but the game logic changes, a simple program logic patch can complete the relevant upgrade.

However, the immutability of blockchain adds difficulty to this seemingly simple implementation. Taking Solidity game development as an example, a game contract that has been launched online often determines the overall data structure of the game. Since the game logic itself is the migration of data status, the modification of game logic often needs to be coordinated with the upgrade of the contract.

After the contract is upgraded, the data of the contract before the upgrade cannot be reused continuously. In order to complete the upgrade of the game logic, there are only two options:

1 Migration

2. Separate the data layer and the logic layer at the beginning of the contract design

The second option will increase the gas consumption of contract calls, so high-frequency game content upgrades are often difficult to achieve in Web3, which hurts the continuous customer acquisition ability of a potential game.

No logical upgrade of the data interface

The logical upgrade of the data interface was done

To solve this problem, we must first solve the data reuse problem and the data upgrade problem. When the logic of the game is modified, we still hope that the original data can be retained intact. The best zero-cost solution here is an independent App As A rollup. Because in App rollup, the Merkle root of the original data can be directly reused, and the modification of the logic only needs to be reflected in the code logic.

Logic upgrade directly running in the virtual machine

After the data reuse and logic upgrade problems are solved, the data structure upgrade problem will still bring certain challenges to the game upgrade. Ordinary on-chain data migration often requires the use of an oracle to modify the data according to a predetermined script and then re-enter it on the chain, which will take a lot of time.

In the App As A rollup architecture, after the data migration audit, it can be run in zkVM, so that the migration logic can be fully verified. Since data migration is data reorganization in many scenarios, with less computing logic, if the code involved in the reorganization of each leaf node is about 1,000 lines, then the execution trace required for more than one million leaf nodes can be about 1,000*1 million. At present, the proof time of ordinary zkVM for one million lines of trace is 9-15 seconds, so the overall zk data migration time is still a controllable number.

It is precisely because of the data independence of Application Rookup that a new methodology has been brought to the iteration of Web3 game content.

And because the complexity of other on-chain apps and the urgency of updating are far less than games, zkVM will bring new opportunities to full-chain games, or verifiable games.

The dilemma of economics and profit distribution

Game project development is a complex, comprehensive and very trivial task. If a high-quality game cannot bring tangible economic benefits, then Web3 will become less attractive to developers than the traditional game field.

At present, the relationship between game projects and public chains is often dominated by traffic relations, supplemented by revenue relations. In the traffic relationship, game projects often rely on the platform traffic and initial traffic provided by the public chain, while the public chain absorbs good game projects and enjoys the increase in public chain users brought by the game in the mid-term of the game launch.

The revenue relationship will be more complicated and hide a deeper problem of profit distribution: on the one hand, user behavior will generate revenue, including gas revenue of the chain and game content consumption charges; on the other hand, game traffic and consumption bring currency price appreciation. Games with trading volume generate asset income by issuing game tokens, which also brings a prosperous ecological effect to the chain, further increasing the valuation expectations of public chain tokens.

Under this complex interest relationship, how to allocate the actual expenditure of users is actually far from a clear definition. The cold start of the game requires a lot of funds, and the first income of users is often based on the gas rate paid to the chain, which makes the cycle of positive feedback for game creators very long. Sometimes there is even a situation where the game development team brushes the volume to reach the DAU base value of the chain by itself, and then relies on meager grants to recover. This forces the game to rely on token expectations in the early stage to attract players to pay gas for interaction. This part of the gas burden can no longer be ignored for a game player, so that it is more difficult for chain games to guide users to consume their own tokens, that is, to purchase game tokens than traditional games.

Since game recharge is the core step of positive feedback in games, the delay of game recharge by gas burden has greatly damaged the ability of game acquisition. However, since blockchain games need to bear the traditional on-chain obligations, even on layer2, gas still mercilessly walks before the first recharge of the game's native token. Therefore, Web3 does not have a real "play first, then pay" game experience.

Game item trading is considered to be the most attractive part of blockchain games in the middle and late stages. High-value game items obtained through krypton gold or long-term interactive efforts continue to appreciate after circulation and collection, which is an exciting experience for both game players and designers. However, as game derivatives, the premiums brought by the circulation of game items are mostly divided up by other on-chain products: the transaction fees of game NFTs may be divided up by NFT exchanges, and the transactions of game tokens are divided up by DeFi. The value created by good games cannot effectively flow back into the game to support the game team.

The value fluctuation of tokens will lead to dynamically amplified in-game output. When the value of game tokens is underestimated, the game fee rate is low, and the game output and the actual game token investment are often positively correlated, resulting in low token prices. The cost of consuming the same game token is low, and the output is higher. When the game currency is high, the excessively high value of game tokens hinders the impulse to consume in the game. Such an amplification effect makes the value fluctuations of game tokens subject to the dual influence of off-site and on-site output, increasing the challenges related to token economics design.

App As A rollup + zkVM: A possible way out

When listing this series of challenges, we unexpectedly discovered that the architecture of Application As Rollup can appropriately and effectively alleviate related problems.

First, the real gas of the own rollup will be significantly reduced to 1/20 or even less than that of the full-chain game. This allows the project party to completely avoid gas fee interference in the early stage of the game, provide a truly free to play game experience, and create a better environment for the initial cold start of the game.

Secondly, Application As Rollup can provide a one-click lending platform, which encourages users to try paid functions in the game by using USDC to borrow game internal tokens in the early stage of the game. Since the positive expected output of the game is often greater than consumption, users can completely redeem the USDC collateral used for borrowing after the output exceeds consumption.

In the circulation link, Application As a Rollup can effectively serve as a cross-chain bridge for game assets. When we need to transfer assets on different chains, we only need to Deposit them into the game, and then Withdraw them on another chain. This native cross-chain function allows part of the value of game derivative transactions to be captured by the game itself.

Even more radically, the game can provide a deposit stablecoin function for lending, so that the TVL value that could only be captured by the chain before can now be captured by the game itself. Finally, Application Rollup can provide a mechanism similar to gas fees for krypton gold players in the game, and ultimately capture the traditional chain gas fees. A more likely design of this mechanism is that the gas fee is lower when the token value is higher, and the gas fee is higher when the token value is lower: its essence is to benefit from the independence of layer3 to bind the gas value and token value to alleviate the volatility of token value.

Of course, all this will not happen overnight. As an early player in pushing zkVM into gaming applications, Delphinus Lab zkWASM recently released zkWASM Mini Rollup. This is a toolkit for rapid development and deployment of ZK Rollup applications. It allows developers to write Rust code, compile it to WebAssembly, and then run it in a Node.js environment. This SDK processes transactions, generates zero-knowledge proofs, and interacts with the blockchain.

The core process is: receiving transactions, processing transactions in the WASM virtual machine, generating proofs using the zkWASM cloud service, and finally submitting the proofs to the blockchain for verification and settlement. The whole process ensures the privacy and security of transactions, while greatly improving the scalability of the blockchain. Developers only need to focus on the application logic without having to deeply understand the complex technical details of zero-knowledge proofs. It also includes a Rollup monitoring system that can use proofs and transaction data to trigger on-chain settlements, and verify proofs by storing Merkle roots and verify APIs to ensure settlements are made in the order of the Merkle roots on the chain. In addition, the SDK simplifies the construction of the local development environment. You only need to start MongoDB and Redis, run dbservice, and then execute npm run server in the ts directory to start the complete local service.

The emergence of zkWASM Mini Rollup SDK provides a highly potential solution to the dual challenges faced by Web3 games. Through the architecture of Application As A Rollup, it not only simplifies the update process of game content, but also provides new possibilities for the optimization of game economic models.

This innovative approach firstly takes advantage of the compatibility of WASM, allowing a large number of traditional developers to use their most familiar programming languages, such as Rust, to write game codes; secondly, it allows game developers to more easily reuse data and upgrade logic, greatly reducing gas fees, and may even achieve a true "0 gas free play" and "play first and then pay" experience. At the same time, it provides game projects with more opportunities to capture value, including cross-chain asset transfers, lending functions, etc., which helps to build a more sustainable game economy system.

Using zkWASM to issue rollups with one click means that we can take a solid step forward in mass adoption on both the developer side and the user side. Although this technology is still in its early stages, Web3 games are also facing dual distrust from both inside and outside the circle in this cycle, and are struggling to move forward amid doubts, but it points out a way to solve the core problems currently facing Web3 games.

As more game developers adopt this technology, more and more game operators and lending protocols are willing to participate in the economic model proposed in the previous article. We have reason to believe that Web3 games will gradually overcome the current difficulties. We do not expect to have our own Black Myth Wukong or Call of Duty, but by doing the difficult and right things, working hard towards the ultimate goal instead of taking shortcuts, Web3 games will eventually usher in their own moment of "facing destiny" and leading the entire industry to spend the long eve of large-scale applications.