Les dilemmes et les perspectives des jeux Web3

Auteur : Lola, Delphinus Lab

Avec le succès phénoménal de “Black Myth: Wukong”, une voix pessimiste envers les jeux Web3 émerge à nouveau. Dans un environnement médiatique récemment déprimé et rempli de doutes, cela ajoute une couche de débuff supplémentaire.

Les personnes de Web3 n’aiment-elles pas les jeux ? Certes, lors de la phase de bulle précoce du marché, il est inévitable qu’il y ait une atmosphère spéculative intense, mais de nombreux constructeurs entrent toujours dans cette industrie avec l’objectif de créer un bon jeu, un jeu véritablement destiné aux joueurs. Et pour que Web3 réalise une adoption massive réelle, les jeux sont également incontournables et représentent la voie la plus profonde vers le marché.

Mais la réalité est maigre. Lorsque les gens essaient de compter les jeux de première ligne de Web3, ils découvrent qu’il y a très peu de jeux de qualité, la plupart des jeux sont médiocres, ne fournissent pas une bonne expérience utilisateur aux joueurs et ne répondent pas aux attentes de l’adoption massive. De nombreux équipes de jeux ayant une expérience de combat réussie dans Web2 ont échoué dans Web3. Pourquoi? D’après ce que je comprends actuellement, il y a principalement deux raisons:

1. Comparé aux jeux traditionnels, les jeux Web3 ont du mal à fournir des mises à jour de contenu de jeu continues

2. En raison de son public différent, les jeux Web3 doivent prendre en compte plus de problèmes d’économie de jeu que les jeux traditionnels, en dehors de la jouabilité.

Les défis de la mise à jour du contenu du jeu

Pour qu’un jeu puisse avoir une longue durée de vie, les mises à jour et les correctifs sont indispensables. Sinon, d’une part, les bugs ne peuvent pas être corrigés, et d’autre part, l’enthousiasme des joueurs ne peut pas être maintenu. Dans le développement traditionnel de jeux, si la structure des données ne change pas mais que la logique du jeu change, un simple correctif de logiciel peut être utilisé pour effectuer la mise à niveau correspondante.

Cependant, l’immutabilité de la blockchain ajoute de la difficulté à cette implémentation apparemment simple. Prenons l’exemple du développement de jeux en Solidity, un contrat de jeu en ligne détermine souvent la structure globale des données du jeu, car la logique du jeu elle-même est une migration d’état de données, la modification de la logique du jeu nécessite souvent une mise à niveau du contrat.

Après la mise à niveau du contrat, il est impossible de réutiliser les données du contrat précédent pour assurer la continuité. Pour mettre à niveau la logique du jeu, il n’y a que deux choix :

1 Migration

2. Séparer dès le départ la couche de données et la couche logique dans la conception du contrat intelligent

Le deuxième choix augmentera la consommation de gaz de l’appel de contrat, donc les mises à niveau fréquentes du contenu du jeu sont souvent difficiles à réaliser avec Web3, ce qui nuit à la capacité d’acquisition continue d’un jeu prometteur.

Ne mettez pas à niveau la logique de l’interface de données

Mise à niveau logique de l’interface de données

Pour résoudre ce problème, il est d’abord nécessaire de résoudre le problème de la réutilisation des données et de la mise à niveau des données. Lorsque la logique du jeu est modifiée, nous espérons toujours que les données d’origine peuvent être conservées telles quelles. La meilleure solution à coût zéro ici est l’App As A rollup indépendant. En effet, dans l’App rollup, le Merkle Root des données d’origine peut être directement réutilisé, et les modifications de la logique ne doivent être reflétées que dans la logique du code.

Mise à niveau logique directement exécutée dans la Machine virtuelle

Une fois que le problème de réutilisation des données et de mise à niveau de la logique est résolu, le problème de mise à niveau de la structure des données continuera à poser un certain défi à la mise à niveau du jeu. La migration classique des données hors chaîne nécessite généralement l’utilisation d’une Oracle Machine pour modifier les données selon un script prédéfini, puis les enregistrer à nouveau hors chaîne, ce qui prend beaucoup de temps.

Dans l’architecture App As A rollup, après l’audit de migration des données, il peut s’exécuter dans zkVM, permettant ainsi une vérification complète de la logique de migration. Comme la migration des données est souvent une recombinaison des données dans de nombreux scénarios, avec relativement peu de logique de calcul, si le code impliqué dans la recombinaison de chaque nœud feuille implique environ 1000 lignes, alors l’exécution des traces nécessaires pour plus de 1,1 million de nœuds feuilles peut être d’environ 1000*10^6. Actuellement, le temps de preuve de trace pour chaque million de lignes dans un zkVM ordinaire est de 9 à 15 secondes, donc le temps total de migration des données zk reste un nombre contrôlable.

C’est précisément en raison de l’indépendance des données de l’application Rookup que de nouvelles méthodologies ont été apportées à l’itération du contenu des jeux Web3.

En raison de la complexité des autres applications sur chaîne et de leur urgence de mise à jour bien moindre que celle des jeux, zkVM apporte de nouvelles opportunités aux jeux sur chaîne complète, ou jeux vérifiables.

Le dilemme de l’économie et de la répartition des bénéfices

Le développement de projets de jeux est un travail complexe et très fastidieux. Si un jeu de haute qualité ne peut pas apporter des bénéfices économiques concrets, alors l’attrait de Web3 pour les développeurs diminuera par rapport au domaine traditionnel des jeux.

Actuellement, la relation entre les projets de jeux et les chaînes publiques est souvent dominée par la relation de trafic, avec la relation de revenus en second plan. Les projets de jeux au milieu de la relation de trafic dépendent souvent du trafic de la plateforme fourni par la chaîne publique et du trafic initial, tandis que la chaîne publique, en absorbant de bons projets de jeux, bénéficie de l’augmentation des utilisateurs de la chaîne publique une fois que le jeu est lancé.

Les relations de revenus seront plus complexes et cachent des problèmes de répartition des intérêts plus profonds : d’une part, les actions des utilisateurs génèrent des revenus, y compris les revenus du gaz de la chaîne, les frais de consommation de contenu de jeu ; d’autre part, le trafic et la consommation de jeu ont entraîné une augmentation de la valeur des jetons, les jeux avec un volume élevé ont généré des revenus d’actifs grâce à l’émission de jetons de jeu, tout en apportant une prospérité écologique à la chaîne, augmentant ainsi les attentes de valorisation des jetons de la chaîne.

Dans cette relation complexe d’intérêts, il n’y a en fait aucune définition claire de la répartition raisonnable des dépenses réelles des utilisateurs. Le démarrage à froid du jeu nécessite des fonds considérables, et les premiers revenus des utilisateurs sont souvent principalement destinés à payer les frais de gas de la chaîne, ce qui rend le cycle de rétroaction positive pour les créateurs de jeux très long, et parfois même la situation où l’équipe de développement du jeu fait du wash trading pour atteindre la valeur de base de l’audience quotidienne active de la chaîne, en comptant sur de maigres subventions pour récupérer les pertes. Cela oblige les jeux à compter sur les attentes de token pour attirer les joueurs à payer du gas pour interagir à un stade précoce. Ce fardeau en gaz ne peut plus être négligé pour un joueur, au point que les jeux sur chaîne ont plus de difficulté que les jeux traditionnels à inciter les utilisateurs à dépenser leur token, c’est-à-dire à acheter des tokens de jeu.

Étant donné que le dépôt de jeu est l’étape la plus cruciale de la rétroaction positive du jeu, le fardeau du gas a grandement nui à la capacité d’acquisition de clients du jeu. Cependant, en raison de l’obligation traditionnelle pour les jeux de chaîne de porter la charge, même sur layer2, le gas continue de précéder impitoyablement le premier dépôt de jeton natif du jeu. Ainsi, Web3 n’offre pas vraiment une expérience de jeu “jouer d’abord, dépenser ensuite”.

Le commerce d’objets de jeu est considéré comme l’un des aspects les plus attrayants du bloc-chaîne dans les jeux. Les objets de jeu de grande valeur obtenus par l’achat d’objets virtuels ou par des efforts d’interaction à long terme, et qui continuent à prendre de la valeur après avoir été échangés et collectionnés, offrent une expérience passionnante aussi bien pour les joueurs que pour les concepteurs. Cependant, étant des dérivés de jeux, une grande partie de la prime apportée par la circulation des objets de jeu est récupérée par d’autres produits hors chaîne : les frais de transaction des NFT de jeu peuvent être récupérés par les plateformes d’échange de NFT, et les transactions de jetons de jeu peuvent être récupérées par les plateformes de financement décentralisé (DeFi). La valeur créée par de bons jeux ne parvient pas à revenir efficacement dans le jeu pour soutenir l’équipe de développement.

La fluctuation de la valeur du Token peut entraîner une augmentation dynamique de la production interne du jeu. Lorsque la valeur du jeton de jeu est sous-estimée, le taux de jeu est bas, ce qui entraîne généralement une corrélation positive entre la production de jeu et l’investissement réel en jetons de jeu, ce qui entraîne une baisse du prix des jetons. Le coût de consommation des mêmes jetons de jeu est donc plus faible, mais la production est plus élevée. Cependant, lorsque la valeur de la devise de jeu est élevée, une valeur excessive du jeton de jeu entrave le désir de consommation interne du jeu. Ce genre d’effet d’amplification augmente l’influence du double impact de la production interne et externe sur la fluctuation de la valeur du jeton de jeu, ce qui accroît les défis liés à la conception de l’économie des jetons.

Application en tant que rollup + zkVM : une issue possible

Lors de l’énumération de cette série de défis, nous avons découvert par accident que l’architecture Application As Rollup peut atténuer efficacement les problèmes connexes.

Tout d’abord, le vrai gaz rollup propre sera considérablement réduit de 1/20 à même moins que les jeux complets de chaînes. Cela permettra aux projets de fête d’éviter complètement les interférences de frais de gaz au début du jeu, offrant une véritable expérience de jeu gratuit pour jouer et créant un meilleur environnement pour le lancement à froid.

De plus, Application As Rollup peut fournir une plateforme de prêt clé en main, permettant aux utilisateurs d’emprunter des jetons internes au jeu en utilisant USDC au début du jeu, encourageant ainsi les utilisateurs à essayer les fonctionnalités payantes du jeu. Étant donné que le rendement attendu du jeu est souvent supérieur à la consommation, les utilisateurs peuvent entièrement racheter USDCCollateral utilisé pour l’emprunt une fois le rendement supérieur à la consommation atteint.

Dans le processus de circulation, Application As a Rollup peut agir efficacement en tant que pont de cross-chain d’interaction pour les actifs de jeu. Lorsque nous avons besoin de transférer des actifs de différentes chaînes hors chaîne, il suffit de les déposer dans le jeu, puis de les retirer sur une autre chaîne hors chaîne. Cette fonctionnalité native de cross-chain d’interaction permet à une partie de la valeur des transactions dérivées de jeux d’être capturée par le jeu lui-même.

Plus radical encore, les jeux peuvent offrir la fonctionnalité de dépôt de Stable Coin pour effectuer des prêts, permettant ainsi à la valeur TVL précédemment capturée uniquement par la chaîne d’être capturée par le jeu lui-même. Enfin, Application Rollup peut fournir un mécanisme similaire aux frais de gaz pour les joueurs payants en introduisant dans le jeu, capturant ainsi les frais de gaz traditionnels de la chaîne. Un design possible de ce mécanisme est que les frais de gaz sont plus bas lorsque la valeur du jeton est élevée, et les frais de gaz sont plus élevés lorsque la valeur du jeton est faible : cela permet de lier la valeur du gaz à la valeur du jeton pour atténuer les fluctuations de la valeur du jeton.

Bien sûr, tout cela ne se produira pas du jour au lendemain, Delphinus Lab zkWASM, l’un des premiers acteurs à pousser zkVM vers les applications de jeu, a récemment lancé zkWASM Mini Rollup. Il s’agit d’un ensemble d’outils pour le développement et le déploiement rapides d’applications ZK Rollup. Il permet aux développeurs d’écrire du code Rust, de le compiler en WebAssembly, puis de l’exécuter dans un environnement Node.js. Ce SDK gère les transactions, génère des preuves de connaissance zéro et interagit avec la chaîne de Blocs.

Son processus principal est le suivant : recevoir des transactions, traiter les transactions dans une Machine virtuelle WASM, utiliser des services cloud zkWASM pour générer des preuves, puis soumettre ces preuves à la blockchain pour vérification et règlement. Tout ce processus garantit la confidentialité et la sécurité des transactions, tout en améliorant considérablement l’évolutivité de la blockchain. Les développeurs n’ont qu’à suivre la logique de l’application, sans avoir à comprendre en détail les complexités de la technologie Zéro Knowledge Proof. Il comprend également un système de surveillance Rollup qui peut déclencher un règlement off-chain en utilisant des preuves et des données de transaction, en utilisant la racine de Merkle pour la validation des preuves, afin de garantir un règlement dans l’ordre de la racine off-chain. De plus, ce SDK simplifie la configuration de l’environnement de développement local en lançant simplement MongoDB et Redis, en exécutant le service de base de données, puis en exécutant npm run server dans le répertoire ts pour démarrer un service local complet.

L’émergence du SDK zkWASM Mini Rollup offre une solution extrêmement prometteuse aux défis doubles auxquels les jeux Web3 sont confrontés. Avec son architecture Application As A Rollup, il simplifie non seulement le processus de mise à jour du contenu du jeu, mais ouvre également de nouvelles possibilités pour l’optimisation du modèle économique du jeu.

Cette méthode innovante utilise d’abord la compatibilité de WASM pour permettre à de nombreux développeurs traditionnels d’utiliser leur langage de programmation préféré, comme Rust, pour écrire du code de jeu. Ensuite, elle permet aux développeurs de jeux de faciliter la réutilisation des données et les mises à niveau logiques, réduisant considérablement les frais de Goutte, voire permettant une véritable expérience de jeu “sans gaz” et “jouer d’abord, payer après”. En même temps, elle offre aux projets de jeux davantage d’opportunités de capturer de la valeur, notamment la transfert d’actifs en cross-chain, les fonctionnalités de prêt, etc., contribuant ainsi à l’établissement d’un système économique de jeu plus durable.

En utilisant zkWASM pour déployer rollup en un clic, cela signifie que nous pouvons franchir une étape solide vers l’adoption massive du côté des développeurs et des utilisateurs. Bien que cette technologie en soit encore à ses débuts, les jeux Web3 font également face à une double méfiance interne et externe à ce stade, avançant difficilement dans le doute, mais elle indique une voie pour résoudre les problèmes fondamentaux auxquels sont confrontés les jeux Web3 actuels.

Avec de plus en plus de développeurs de jeux adoptant cette technologie, de plus en plus d’opérateurs de jeux et de protocoles de prêt sont prêts à participer à ce modèle économique recommandé précédemment. Nous avons toutes les raisons de croire que les jeux Web3 surmonteront progressivement les difficultés actuelles. Nous ne nous attendons pas à avoir notre propre mythologie noire de Sun Wukong ou Call of Duty, mais en faisant ce qui est difficile et juste, en travaillant inlassablement vers un objectif final plutôt que de chercher des raccourcis, les jeux Web3 finiront par affronter leur propre “volonté de Dieu” et entraîneront toute l’industrie à passer ensemble la longue nuit précédant l’adoption à grande échelle.