The dilemma and way out of Web3 games

Author: Lola, Delphinus Lab

With the phenomenal success of “Black Myth: Wukong”, there has been a wave of voices within the industry criticizing Web3 games. In the current market environment, which has already been very subdued and self-doubting, another layer of debuff has been added.

Do Web3 people not love games? Indeed, in the early bubble stage of the market, a strong speculative atmosphere is inevitable, but many builders still enter this industry with the idea of creating a good game, a game that truly belongs to the players. And for Web3 to achieve true mass adoption, games are also an unavoidable path that can deeply penetrate the market.

But the reality is skinny. When people try to list the top-quality games on the Web3, they find that the number of good games is extremely limited, and most games are mediocre, neither providing players with good user experience, nor meeting the expectations of mass adoption. A large number of game teams with successful practical experience in Web2 have failed in Web3, and the reasons for this, as I currently understand, are mainly twofold:

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

2. Due to different audiences, Web3 games need to consider more game economic issues beyond game mechanics than traditional games.

The Dilemma of Updating Game Content

A game must maintain its vitality for a long time, and updating patches is essential; otherwise, bugs cannot be fixed, and the freshness of the players is also 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 the blockchain adds complexity 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. As the game logic itself is the migration of data states, modifying the game logic often requires an upgrade to the contract.

After the contract is upgraded, it is unable to continue to reuse the data of the contract before the upgrade. In order to complete the upgrade of the game logic, there are only two choices:

1 Migration

2. Separating the Data Layer and the Logic Layer in the initial design of the contract

The second option will increase the gas consumption of contract calls, so frequent game content upgrades are often difficult to achieve on Web3, which hurts the sustained customer acquisition potential of a promising game.

Do not upgrade the logic of data interface

Upgraded the logic of the data interface

To solve this problem, the first step is to address the issues of data reuse and data upgrade. When the logic of the game is modified, we still want the original data to be preserved intact. The best zero-cost solution here is an independent App As A rollup. In the App rollup, the Merkle Root of the original data can be directly reused, while the modifications to the logic only need to be reflected in the code logic.

The logic upgrade running directly in the Virtual Machine

After solving the data reuse and logic upgrade issues, the data structure upgrade problem will still pose certain challenges to the game upgrade. The ordinary on-chain data migration often requires the use of Oracle Machine to modify the data according to a predetermined script before re-entering it on-chain, which will consume a lot of time.

In the App As A Rollup architecture, after data migration auditing, it can be run on zkVM to achieve fully verifiable migration logic. Since data migration often involves data reorganization in many scenarios and has fewer computational logics, if the code involved in reorganizing each leaf Node is about 1000 lines, then the execution trace required for over one million leaf Nodes can be approximately 1000*10 million. Currently, the proof time for one million lines of trace in ordinary zkVM 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 it has brought a new methodology for the iteration of Web3 game content.

And due to the complexity of other on-chain apps and the less urgent need for updates compared to games, zkVM will bring new opportunities to the whole-chain games, or verifiable games.

The Dilemma of Economics and Benefit Distribution

Game project development is a complex and tedious work. If a high-quality game cannot bring tangible economic benefits, the attraction of Web3 to developers will decline compared to the traditional gaming industry.

Currently, the relationship between game projects and public chains is often primarily based on traffic, with revenue as a secondary consideration. Game projects in the middle of the traffic relationship often rely on the platform traffic and initial traffic provided by the public chain, while the public chain, by attracting good game projects, enjoys the incremental public chain user brought by the game after it goes online.

The income relationship will become more complex and hidden deeper issues of interest distribution: on the one hand, user behavior will generate income, including gas income from the chain, and fees for game content consumption; on the other hand, game traffic and consumption have brought about an increase in coin price, and games with volume have generated asset income through the issuance of game tokens, while also bringing prosperity to the chain’s ecological effects, further increasing the expected valuation of the chain’s tokens.

In this complex web of interests, there is no clear definition of how to allocate actual expenses reasonably. The cold start of the game requires a large amount of funds, and the first income of the user is often mainly used to pay the gas fee rate to the chain, which makes the feedback cycle for game creators very long. Sometimes, even the game development team engages in wash trading to reach the DAU baseline of the chain, relying on meager grantrecover losses. This forces the game to rely on token expectations to attract players to pay gas for interaction in the early stage. This part of the gas burden is already significant for a game player, to the extent that guiding users to consume their own tokens in chain games, that is, the process of purchasing game tokens, becomes more difficult compared to traditional games.

As the deposit in the game is the most crucial step for positive feedback in the game, the burden of gas has greatly hindered the game’s ability to acquire customers. However, as blockchain games need to bear the traditional obligation of on-chain, even on layer2, gas still mercilessly takes precedence over the first deposit of the game’s native token. Therefore, Web3 does not truly provide a ‘play first, pay later’ gaming experience.

The trading of in-game items is considered the most attractive part of the later stage of the blockchain game. High-value in-game items obtained through spending money or long-term interaction continue to appreciate after circulation and collection, providing an exciting experience for both players and designers. However, as game items are derivative products, most of the premium brought by their circulation on exchanges is divided among other on-chain products: the transaction fees of game NFTs may be shared by NFT exchanges, while the transaction of game tokens may be shared by DeFi. The value created by good games does not effectively flow back to support the game team.

The fluctuation of Token’s value can lead to dynamically amplified in-game output. When the value of the game token is underestimated, the game fee rate is low, and the game output is often positively correlated with the actual input of game tokens, resulting in a low token price. The cost of consuming the same game token is lower, and the output is higher. However, when the game coin is in a high position, the excessively high value of the game token hinders the consumption impulse in the game. This amplification effect allows the fluctuation of the value of the game token to be influenced by both off-chain and on-chain output, increasing the challenges related to the design of Tokenomics.

App As A rollup + zkVM: A Possible Way Out

When listing this series of challenges, we unexpectedly found that the Application As Rollup architecture can effectively mitigate the related issues.

First of all, the real gas of our own rollup will drop significantly to 1/20 or even less compared to the whole-chain games. This can completely eliminate the gas fee interference for the project party in the early stage of the game, providing a true free-to-play gaming experience and creating a better environment for the initial launch of the game.

Secondly, Application As Rollup can provide a one-click lending platform, encouraging users to try out paid features in the game by borrowing game internal Tokens with USDC in the early stage of the game. Since the expected output of the game is often greater than the consumption, after the output exceeds the consumption, users can completely redeem the USDCCollateral used for borrowing.

In the circulation process, Application As a Rollup can effectively serve as a Cross-Chain Interaction bridge for game assets. When we need to transfer assets on different on-chain platforms, we only need to Deposit them into the game and then Withdraw them on the other on-chain platform. This native Cross-Chain Interaction feature allows the game itself to capture part of the value of derivative transactions.

More aggressive is that the game can provide deposit Stable Coin function for lending, allowing the TVL value that was previously only captured by the chain to be captured by the game itself. Finally, Application Rollup can provide a mechanism similar to gas fees for Krypton gold players in the game, ultimately capturing traditional chain gas fees. A more likely design of this mechanism is that when the token value is high, the gas fee is low, and when the token value is low, the gas fee is high: essentially benefiting from binding the gas value and token value through the independence of layer3 to relieve token value Fluctuation.

Of course, none of this will happen overnight, Delphinus Lab zkWASM, as an early player pushing zkVM towards gaming applications, recently released zkWASM Mini Rollup. This is a toolkit for rapidly developing and deploying 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 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 service to generate proofs, and finally submitting the proofs to the blockchain for validation and Settlement. The entire process ensures the privacy and security of transactions, while greatly improving the scalability of the blockchain. Developers only need to follow the application logic without delving into the complex details of Zero-Knowledge Proof technology. It also includes a Rollup monitoring system, which can trigger on-chain Settlement using proofs and transaction data, ensuring Settlement in the order of on-chain Merkle roots through storage of Merkle roots and verify API for proof of validation. In addition, the SDK simplifies the setup of the local development environment, requiring only the startup of MongoDB and Redis, running the dbservice, and then executing 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 for the dual challenges faced by Web3 games. With the architecture of Application As A Rollup, it not only simplifies the update process of game content, but also provides new possibilities for optimizing the game economy model.

This innovative approach first utilizes the compatibility of WASM to allow a large number of traditional developers to use their familiar programming languages such as Rust to write game code; second, it allows game developers to more easily achieve data reuse and logic upgrades, greatly reducing gas costs, and even achieving a true “0 gas play” and “play first, spend later” experience. At the same time, it provides more opportunities for game projects to capture value, including Cross-Chain Interaction asset transfers, lending functions, etc., which helps establish a more sustainable game economy.

Using zkWASM to launch rollup with one click means that we can take a solid step forward in both developer-side and user-side mass adoption. Although this technology is still in its early stages, Web3 games also face double distrust from within and outside the circle during this cycle, and they are struggling to move forward amidst doubts. However, it points out a way to solve the core problems faced by current Web3 games.

As more game developers adopt this technology, more game operators and lending protocols are willing to participate in the economic model recommended earlier. We have reason to believe that Web3 games will gradually overcome existing difficulties. We do not expect to have our own black mythology Wukong or Call of Duty, but by doing difficult and right things, persistently striving towards the ultimate goal rather than seeking quick success, Web3 games will also usher in their own “facing God’s will” moment, and lead the entire industry through the long night before widespread application.