L'impasse et les perspectives des jeux Web3
TechFlow SélectionTechFlow Sélection
L'impasse et les perspectives des jeux Web3
Est-ce que les jeux Web3 sont en échec, ou n'avons-nous pas encore trouvé la bonne voie ?
Dédié à des analyses Web3 approfondiesAuteur : Lola, Delphinus Lab
Avec le succès phénoménal de « Black Myth: Wukong », une nouvelle vague de critiques pessimistes sur les jeux Web3 est apparue dans la communauté. Dans un contexte déjà morose et marqué par l’autodoute au sein du marché, cela ajoute un débuff supplémentaire.
Les acteurs de la Web3 n’aiment-ils pas les jeux ? Certes, durant les premières phases spéculatives du marché, l’atmosphère était inévitablement imprégnée de spéculation. Pourtant, nombreux sont les développeurs à avoir rejoint ce secteur avec la volonté sincère de créer un bon jeu, un jeu véritablement appartenant aux joueurs. Si la Web3 souhaite atteindre une adoption massive (mass adoption), les jeux constituent un passage obligé, la voie la plus efficace pour toucher un large public.
Mais la réalité est sévère. Lorsqu’on tente de dresser la liste des principaux jeux Web3, on constate que leur nombre de qualité reste extrêmement limité. La majorité d’entre eux sont médiocres, offrant une mauvaise expérience utilisateur et restant bien loin des attentes en matière d’adoption massive. De nombreuses équipes ayant fait leurs preuves dans le Web2 ont échoué en tentant de s’implanter dans le Web3. D’après mon analyse, deux raisons principales expliquent cet échec :
1. Comparés aux jeux traditionnels, les jeux Web3 peinent à fournir des mises à jour régulières de contenu
2. En raison d’un public différent, les jeux Web3 doivent intégrer davantage d’enjeux économiques, allant au-delà de la seule gameplay
La difficulté des mises à jour de contenu
Pour qu’un jeu conserve sa longévité, les mises à jour et correctifs sont indispensables : sans elles, les bugs persistent et la nouveauté s’épuise rapidement. Dans le développement traditionnel, si la structure des données ne change pas mais que la logique du jeu évolue, un simple correctif logiciel suffit à réaliser la mise à jour.
Cependant, l’immutabilité de la blockchain complique considérablement cette opération apparemment simple. Prenons l’exemple du développement de jeux en Solidity : un contrat de jeu déployé détermine souvent entièrement la structure des données du jeu. Comme la logique du jeu correspond à une transition d’états de données, toute modification de cette logique nécessite généralement une mise à jour du contrat.
Or, après une mise à jour de contrat, il devient impossible de réutiliser directement les données du contrat précédent. Pour mettre à jour la logique du jeu, deux options seulement s’offrent alors :
1. Migration
2. Séparer dès la conception les couches de données et de logique au sein du contrat
La deuxième option augmente la consommation de gaz lors des appels au contrat. Ainsi, les mises à jour fréquentes du contenu sont difficilement réalisables en Web3, ce qui nuit à la capacité d’acquisition continue d’un jeu potentiellement prometteur.
Mise à jour logique sans interface de données
Mise à jour logique avec interface de données
Pour résoudre ce problème, il faut d’abord permettre la réutilisation et la mise à jour des données. Lorsque la logique du jeu change, nous souhaitons conserver intactes les données existantes. La meilleure solution sans coût ici consiste à utiliser une application indépendante en tant que rollup (App As A Rollup). En effet, dans une architecture App Rollup, la racine Merkle des données initiales peut être directement réutilisée, tandis que la modification de la logique se limite à une mise à jour du code.
Mise à jour logique directement exécutée dans la machine virtuelle
Une fois résolus les problèmes de réutilisation des données et de mise à jour logique, la mise à jour de la structure des données reste un défi pour l’évolution du jeu. Une migration classique de données sur chaîne nécessite souvent l’utilisation d’oracles, modifiant les données selon un script prédéfini avant de les réinscrire sur la blockchain — un processus très long.
Dans une architecture App As A Rollup, après vérification de la migration des données, celle-ci peut s’exécuter dans une zkVM, rendant ainsi la logique de migration entièrement vérifiable. Étant donné que, dans de nombreux cas, la migration implique surtout un réarrangement des données avec peu de calculs, si le code nécessaire à la réorganisation de chaque nœud feuille est d’environ 1 000 lignes, la trace d’exécution totale pour plus d’un million de nœuds serait d’environ 1 000 × 1 million. Actuellement, une zkVM standard met entre 9 et 15 secondes pour produire une preuve par million de lignes de trace ; le temps total de migration zk reste donc maîtrisable.
C’est précisément grâce à l’indépendance des données dans Application Rollup que de nouvelles méthodologies d’itération du contenu des jeux Web3 deviennent possibles.
Étant donné que les autres applications blockchain sont moins complexes et moins dépendantes de mises à jour fréquentes que les jeux, la zkVM ouvre de nouvelles opportunités aux jeux fully on-chain, ou jeux vérifiables.
La difficulté économique et de redistribution des intérêts
Le développement de jeux est une tâche complexe, globale et minutieuse. Si un jeu de haute qualité ne génère pas de retour économique tangible, l’attractivité de la Web3 pour les développeurs diminuera progressivement par rapport au secteur traditionnel.
Actuellement, la relation entre les projets de jeux et les blockchains publiques repose principalement sur le trafic, le revenu étant secondaire. Les projets de jeux dépendent souvent du trafic initial fourni par la blockchain via ses plateformes, tandis que la blockchain bénéficie, en phase intermédiaire, d’une augmentation de ses utilisateurs grâce au jeu.
La dimension économique est plus complexe, car elle recèle des enjeux profonds de redistribution des bénéfices : d’un côté, les comportements des utilisateurs génèrent des revenus, notamment via les frais de gaz sur la chaîne et les paiements liés à la consommation de contenu ; de l’autre, le trafic et la consommation augmentent la valeur du jeton de la blockchain, tandis que les jeux à fort volume transactionnel créent des actifs via leurs propres jetons, renforçant ainsi l’écosystème et faisant grimper la valorisation anticipée de la blockchain.
Dans ces relations d’intérêt complexes, il n’existe aucune norme claire pour déterminer comment les dépenses réelles des utilisateurs devraient être réparties. Le démarrage d’un jeu nécessite d’importants investissements, or la première dépense de l’utilisateur va souvent aux frais de gaz de la chaîne. Cela prolonge considérablement le délai avant que les créateurs du jeu ne perçoivent un retour positif. Parfois, les équipes de développement doivent même simuler artificiellement des volumes pour atteindre le seuil minimal de DAU exigé par la chaîne, puis survivre grâce à de maigres subventions. Ces contraintes poussent les jeux à compter sur les attentes spéculatives autour du token pour inciter les joueurs à payer des frais de gaz afin d’interagir. Ce fardeau en termes de gaz devient alors trop important pour être ignoré par les joueurs, rendant particulièrement difficile l’étape cruciale où l’on pousse l’utilisateur à consommer son jeton natif — c’est-à-dire acheter le jeton du jeu — comparé aux jeux traditionnels.
Le rechargement (top-up) étant l’étape centrale du cercle vertueux du jeu, le poids des frais de gaz ralentit fortement cette dynamique et affaiblit gravement la capacité d’acquisition du jeu. Or, même sur une couche 2, les jeux blockchain doivent assumer l’obligation d’envoyer des transactions sur chaîne, ce qui place inévitablement les frais de gaz avant même le premier achat du jeton natif du jeu. En conséquence, la Web3 ne permet pas véritablement une expérience « jouer d’abord, payer plus tard ».
L’échange d’objets de jeu est considéré comme l’un des aspects les plus attrayants des jeux blockchain à moyen et long terme. Voir des objets précieux acquis par dépense ou effort prolongé prendre de la valeur grâce à la circulation et à la collection est une expérience passionnante, tant pour les joueurs que pour les concepteurs. Toutefois, en tant que produits dérivés du jeu, la majeure partie de la plus-value générée par leurs échanges est capturée par d’autres produits blockchain : les frais de transaction des NFT de jeu vont aux marchés NFT, ceux des jetons de jeu aux protocoles DeFi. Ainsi, la valeur créée par un bon jeu ne revient pas efficacement au jeu lui-même pour soutenir son équipe de développement.
Les fluctuations de la valeur du jeton amplifient de manière dynamique la production en jeu. Quand la valeur du jeton est sous-estimée, les coûts du jeu sont bas, la production en jeu est positivement corrélée à l’investissement en jetons, ce qui maintient les prix bas tout en rendant la consommation de jetons moins coûteuse, donc la production encore plus élevée. À l’inverse, lorsque le jeton est cher, sa forte valeur freine les impulsions d’achat en jeu. Cet effet d’amplification expose la valeur du jeton à des influences internes et externes, rendant la conception de l’économie du jeton particulièrement ardue.
App As A Rollup + zkVM : une sortie possible
Après avoir listé ces défis, nous découvrons que l’architecture Application As Rollup peut efficacement atténuer bon nombre de ces problèmes.
Premièrement, le vrai coût en gaz d’un rollup propre est nettement inférieur à celui d’un jeu full on-chain, divisé par 20 voire plus. Cela permet aux projets de supprimer complètement la barrière des frais de gaz en phase initiale, offrant une véritable expérience « free to play » et créant un environnement plus favorable au démarrage massif du jeu.
Deuxièmement, Application As Rollup peut intégrer une plateforme de prêt instantanée, encourageant les utilisateurs à tester les fonctionnalités payantes via un prêt en jeton interne contre une garantie en USDC. Étant donné que le gain attendu du jeu dépasse généralement la dépense, l’utilisateur peut ensuite récupérer pleinement son collatéral en USDC.
Au niveau de la circulation, Application As a Rollup peut servir de pont natif pour les actifs du jeu. Pour transférer des actifs entre différentes blockchains, il suffit de déposer les actifs dans le jeu, puis de les retirer sur une autre chaîne. Cette fonctionnalité native de cross-chain permet au jeu de capter une part de la valeur générée par les échanges d’actifs dérivés.
Encore plus ambitieux : le jeu peut proposer un dépôt de stablecoins pour des prêts, permettant désormais au jeu lui-même de capter la valeur de TVL (Total Value Locked) auparavant réservée à la chaîne. Enfin, via Application Rollup, le jeu peut introduire un mécanisme similaire aux frais de gaz pour les joueurs payants, capturant ainsi les frais traditionnels de la chaîne. Un tel mécanisme pourrait prévoir des frais bas lorsque la valeur du jeton est élevée, et élevés quand la valeur du jeton est faible — en lien avec l’indépendance de la couche 3, liant intelligemment la valeur du gaz à celle du jeton pour atténuer la volatilité.
Bien sûr, tout cela ne se produira pas du jour au lendemain. Delphinus Lab, précurseur avec son zkWASM visant à appliquer la zkVM aux jeux, vient de publier zkWASM Mini Rollup : un kit permettant de développer et déployer rapidement des 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 les preuves à connaissance nulle (zero-knowledge proofs) et interagit avec la blockchain.
Le flux central est le suivant : recevoir les transactions, les traiter dans une machine virtuelle WASM, utiliser un service cloud zkWASM pour générer la preuve, puis envoyer cette preuve à la blockchain pour validation et règlement. Ce processus garantit confidentialité et sécurité des transactions, tout en améliorant considérablement l’extensibilité de la blockchain. Les développeurs peuvent se concentrer sur la logique applicative sans avoir à maîtriser les détails techniques complexes des preuves à connaissance nulle. Le SDK inclut également un système de surveillance du Rollup capable de déclencher le règlement sur chaîne à partir des preuves et des données de transaction, en stockant la racine Merkle et en utilisant une API de vérification pour s’assurer que le règlement suit bien l’ordre des racines Merkle sur chaîne. En outre, il simplifie la configuration de l’environnement de développement local : il suffit de lancer MongoDB et Redis, d’exécuter dbservice, puis de lancer npm run server dans le répertoire ts pour activer un service local complet.
L’apparition du SDK zkWASM Mini Rollup offre une solution très prometteuse aux deux grands défis des jeux Web3. Grâce à l’architecture Application As A Rollup, il simplifie non seulement la mise à jour du contenu du jeu, mais ouvre aussi de nouvelles possibilités pour optimiser le modèle économique.
Cette approche innovante exploite d’abord la compatibilité de WASM, permettant à de nombreux développeurs traditionnels d’utiliser leur langage préféré, comme Rust, pour coder leurs jeux. Ensuite, elle facilite la réutilisation des données et la mise à jour logique, réduit drastiquement les frais de gaz, et pourrait même permettre une expérience réellement « 0 gas » et « jouer d’abord, payer plus tard ». Elle offre également aux projets de jeux davantage d’opportunités pour capter de la valeur — transfert d’actifs cross-chain, fonctions de prêt, etc. — contribuant ainsi à construire un écosystème économique plus durable.
Utiliser zkWASM pour créer un rollup en un clic signifie faire un pas décisif vers l’adoption massive, tant du côté des développeurs que des utilisateurs. Bien que cette technologie en soit encore à ses débuts, et que les jeux Web3 traversent actuellement une période de double défiance — interne et externe — avançant péniblement malgré les critiques, elle trace une voie concrète pour résoudre les problèmes fondamentaux actuels.
A mesure que de plus en plus de développeurs adopteront cette technologie, et que davantage d’opérateurs de jeux et de protocoles de prêt rejoindront ce modèle économique proposé, nous avons de bonnes raisons d’espérer que les jeux Web3 surmonteront progressivement leurs difficultés actuelles. Nous ne rêvons pas d’avoir notre propre « Black Myth: Wukong » ou « Call of Duty », mais en choisissant de faire des choses difficiles mais justes, en poursuivant notre objectif final avec persévérance plutôt que par des raccourcis, les jeux Web3 connaîtront un jour leur propre moment de « confrontation au destin », entraînant toute l’industrie avec eux à travers la longue nuit précédant l’adoption massive.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@DelphinusLab
