The Dilemma and Solutions of Web3 Games
Is it that Web3 games are failing, or have we not found the right path?Author: Lola, Delphinus Lab
With the phenomenal success of "Black Myth: Wukong," there has emerged a wave of pessimism regarding Web3 games within the industry. In an already sluggish and self-doubting market sentiment, this has added another layer of debuff.
Is it that people in Web3 do not love games? Indeed, during the early bubble phase of the market, a strong speculative atmosphere was inevitable, but many builders still entered this industry with the intention of creating a good game, a game that truly belongs to the players. For Web3 to achieve true mass adoption, games are an unavoidable path that can deeply penetrate the market.
However, the reality is harsh. When people try to count the leading Web3 games, they find that the number of quality games is extremely limited, and most games are unremarkable, failing to provide players with a good user experience and falling far short of the expectations for mass adoption. Many successful Web2 game teams have stumbled in Web3, and the reasons, as I currently understand, mainly boil down to two points:
Compared to traditional games, Web3 games struggle to provide continuous content updates.
Due to a different audience, Web3 games need to consider more economic issues beyond gameplay compared to traditional games.
The Dilemma of Game Content Updates
For a game to maintain long-term vitality, updates and patches are essential; otherwise, bugs cannot be fixed, and players' novelty will be hard to sustain. In traditional game development, if the data structure remains unchanged but the game logic changes, a simple program logic patch can complete the relevant upgrades.
However, the immutability of blockchain adds difficulty to this seemingly simple implementation. Taking Solidity game development as an example, a deployed game contract often determines the overall data structure of the game. Since game logic itself is a migration of data states, modifying game logic often requires coordinating with contract upgrades.
After a contract upgrade, it cannot continue to reuse the data from the previous contract. To complete the upgrade of game logic, there are only two choices:
Migration
Separating the data layer and logic layer from the initial contract design.
The second choice increases the gas consumption of contract calls, so frequent content updates in Web3 are often difficult to achieve, which harms the customer acquisition ability of a potentially good game.
Logic upgrade without data interface
Logic upgrade with data interface
To solve this problem, the first step is to address the issues of data reuse and data upgrades. When the game logic is modified, we still hope that the original data can be preserved intact. The best zero-cost solution here is an independent App As A Rollup. Because in an App Rollup, the original data's Merkle root can be reused directly, and modifications to the logic only need to be reflected in the code logic.
Logic upgrade running directly in the virtual machine
Once the issues of data reuse and logic upgrades are resolved, the problem of upgrading the data structure will still pose certain challenges to game upgrades. Ordinary on-chain data migration often requires using oracles to modify the data according to a predetermined script and then re-enter it onto the chain, which can be time-consuming.
In the App As A Rollup architecture, after auditing data migration, it can run in zkVM, allowing for fully verifiable migration logic. Since data migration often involves data restructuring with minimal computation logic, if the code involved in reorganizing each leaf node is around 1000 lines, then the execution trace required for over a million leaf nodes can be approximately 1000 * 100w. Currently, the proof time for ordinary zkVM for every million lines of trace is 9-15 seconds, so the overall zk data migration time remains a controllable figure.
It is precisely because of the data independence of Application Rollup that it brings a new methodology to the iterative content of Web3 games.
Moreover, due to the complexity of other on-chain apps and their urgency for updates being far less than that of games, zkVM will provide new opportunities for full-chain games, or verifiable games.
The Dilemma of Economics and Profit Distribution
Game project development is a complex, comprehensive, and very tedious task. If a high-quality game cannot bring tangible economic benefits, then compared to the traditional gaming field, Web3's attractiveness to developers will gradually decline.
Currently, the relationship between game projects and public chains often revolves around traffic relationships, with revenue relationships as a secondary concern. In terms of traffic relationships, game projects often rely on the platform traffic and initial traffic provided by public chains, while public chains enjoy the user growth brought by good game projects during the mid-stage of the game's launch.
The revenue relationship is more complex and hides deeper issues of profit distribution: on one hand, user behavior generates revenue, including gas revenue from the chain and consumption fees for game content; on the other hand, game traffic and consumption lead to currency appreciation, and games with trading volume generate asset revenue through issuing game tokens, while also bringing a prosperous ecological effect to the chain, further increasing the token valuation expectations of the public chain.
In this complex web of interests, how to reasonably distribute users' actual expenditures lacks a clear definition. The cold start of a game requires substantial funding, while the first income for users often primarily comes from paying gas fees to the chain, which makes the feedback cycle for game creators very long. Sometimes, game development teams even resort to inflating numbers to reach the chain's DAU baseline, relying on meager grants to recover. This forces games to depend on token expectations to attract players to pay gas for interaction in the early stages. This gas burden has become significant for game players, making it more challenging for blockchain games to guide users to consume their own tokens, i.e., purchasing game tokens compared to traditional games.
Since game top-ups are the core step for positive feedback in games, the gas burden significantly hampers the game's customer acquisition ability. However, since blockchain games must bear the on-chain obligations in the traditional sense, even on layer 2, gas fees still unrelentingly precede the first top-up of the game's native token. Therefore, there is no true "play first, pay later" gaming experience in Web3.
The trading of game items is considered one of the most attractive aspects of blockchain games in the later stages. High-value game items earned through spending or long-term interaction continuously appreciate after circulation and collection, providing an exciting experience for both game players and designers. However, as game derivatives, the premiums brought by the circulation and trading of game items are largely divided among other on-chain products: trading fees for game NFTs may be shared with NFT exchanges, while trading of game tokens is divided among DeFi. The value created by good games cannot effectively flow back into the game to support the game team.
The volatility of token values can lead to dynamically amplified in-game outputs. When the value of game tokens is underestimated, the game fees are low, and the output of the game is often positively correlated with the actual investment in game tokens, leading to lower token prices and higher outputs. Conversely, when game tokens are highly valued, the excessive value of game tokens hinders the impulse to consume within the game. This amplification effect causes the value fluctuations of game tokens to be influenced by both external and internal outputs, increasing the challenges related to token economics design.
App As A Rollup + zkVM: A Possible Way Out
In listing this series of challenges, we unexpectedly found that the Application As Rollup architecture can effectively alleviate related issues.
First, the real gas of a self-owned rollup can significantly reduce to 1/20 or even less compared to full-chain games. This allows project parties to completely eliminate gas fee interference in the early stages of the game, creating a better environment for cold starts and gathering players.
Secondly, Application As Rollup can provide a one-click lending platform, encouraging users to try paid features in the game by borrowing internal tokens with USDC in the early stages of the game. Since the expected positive output of the game often exceeds consumption, users can fully redeem the USDC collateral used for borrowing after their output exceeds their consumption.
In the circulation phase, Application As a Rollup can effectively act as a cross-chain bridge for game assets. When we need to transfer assets across different chains, we only need to deposit them into the game and then withdraw them on another chain. This native cross-chain functionality allows a portion of the value from trading game derivatives to be captured by the game itself.
More aggressively, games can offer deposit stablecoin functions for lending, allowing the TVL value that could only be captured by chains to now be captured by the game itself. Finally, Application Rollup can introduce a mechanism similar to gas fees for paying players within the game, ultimately capturing traditional chain gas costs. A possible design for this mechanism is to have lower gas fees when token values are high and higher gas fees when token values are low: essentially benefiting from the independence of layer 3 to bind gas value and token value, alleviating token value fluctuations.
Of course, none of this will happen overnight. Delphinus Lab zkWASM, as an early player pushing zkVM towards game applications, recently released zkWASM Mini Rollup. This is a toolkit for quickly developing and deploying ZK Rollup applications. It allows developers to write Rust code, compile it into WebAssembly, and then run it in a Node.js environment. This SDK handles transactions, generates zero-knowledge proofs, and interacts with the blockchain.
Its core process is: receiving transactions, processing transactions in the WASM virtual machine, using zkWASM cloud services to generate proofs, and finally submitting the proofs to the blockchain for verification and settlement. The entire process ensures the privacy and security of transactions while significantly improving the scalability of the blockchain. Developers only need to focus on application logic without needing to deeply understand the complex details of zero-knowledge proof technology. It also includes a Rollup monitoring system that can trigger on-chain settlements using proofs and transaction data, verify proofs by storing Merkle roots and using verify APIs, ensuring settlements are conducted in accordance with the order of the on-chain Merkle roots. Additionally, this SDK simplifies the setup of local development environments, requiring only the startup of MongoDB and Redis, running dbservice, and executing npm run server in the ts directory to start a complete local service.
The emergence of the zkWASM Mini Rollup SDK provides a highly promising solution to the dual challenges faced by Web3 games. Through the Application As A Rollup architecture, it not only simplifies the game content update process but also offers new possibilities for optimizing game economic models.
This innovative approach first leverages the compatibility of WASM, allowing a large number of traditional developers to use their most familiar programming languages like Rust to write game code; secondly, it allows game developers to more easily implement data reuse and logic upgrades, significantly reducing gas costs, and even potentially achieving a true "0 gas play" and "play first, pay later" experience. At the same time, it provides game projects with more opportunities to capture value, including cross-chain asset transfers, lending functions, etc., helping to establish a more sustainable game economic system.
Using zkWASM to roll up with one click means we can take a solid step towards mass adoption on both the developer and user sides. Although this technology is still in its early stages, and Web3 games face dual distrust from both within and outside the industry during this cycle, struggling forward amidst skepticism, it points to a path for solving the core issues currently faced by Web3 games.
As more game developers adopt this technology, and more game operators and lending protocols are willing to participate in the economic model suggested earlier, we have reason to believe that Web3 games will gradually overcome existing challenges. We do not expect to have our own "Black Myth: Wukong" or "Call of Duty," but by doing the difficult yet correct things and striving towards the ultimate goal rather than taking shortcuts, Web3 games will eventually welcome their moment of "facing destiny" and lead the entire industry through the long night of large-scale applications.
