Quel est le « moment AMM » des jeux entièrement sur chaîne ?
TechFlow SélectionTechFlow Sélection
Quel est le « moment AMM » des jeux entièrement sur chaîne ?
Dida Chain est le moment AMM des jeux entièrement sur chaîne.
Dédié à des analyses Web3 approfondiesLorsque nous décrivons l'impact révolutionnaire d'un produit, d'une technologie ou d'une innovation dans un secteur donné, nous aimons parler du « moment iPhone » de ce secteur. Cela fait référence à l'influence profonde qu'a eue la sortie de l'iPhone par Apple en 2007 sur l'industrie téléphonique et du calcul mobile.
Dans le domaine DeFi, on parle plutôt du « moment AMM ». Le modèle AMM a joué un rôle clé dans l'écosystème DeFi, notamment en améliorant considérablement la liquidité des marchés, contribuant directement à l'arrivée du marché haussier de 2021. Alors, quel est le « moment AMM » du jeu entièrement sur chaîne (on-chain gaming) ? Explorons cela dans cet article.
I. L’importance cruciale de l’AMM dans DeFi
Le DeFi représente la convergence entre la technologie blockchain et le domaine financier : il s'agit d'intégrer les règles financières dans des contrats intelligents afin d'assurer une automatisation, une décentralisation et une confidentialité. Dans tout système financier, quelle est l'élément le plus critique pour chaque projet ? Bien entendu, c'est la « liquidité ». Par exemple, les trois principaux modèles économiques — prêt/emprunt, échange et paiement (via les stablecoins) — ne peuvent fonctionner durablement sans liquidité.
Prêt/Emprunt : La liquidité est au cœur des activités de crédit. Les banques et autres institutions financières dépendent de dépôts à court terme et d'autres sources de financement pour accorder des prêts à long terme. Si ces institutions ne peuvent garantir une liquidité suffisante, elles risquent de ne pas répondre à la demande de crédits ou de faire face à des difficultés lorsqu’elles doivent rembourser leurs dettes à court terme. Le risque de liquidité est un facteur central dans les crises financières : si une banque ne peut pas lever assez de fonds pour honorer ses engagements, elle peut faire faillite.
Échange : Sur les marchés financiers, la liquidité est essentielle. Une forte liquidité signifie que les actifs peuvent être achetés ou vendus rapidement sans perte significative de valeur. Si un marché ou un actif manque de liquidité, les investisseurs peuvent faire face à des écarts importants entre prix d’achat et de vente, ou avoir du mal à trouver des acheteurs lorsqu'ils souhaitent vendre. Cela peut provoquer des fluctuations brutales des prix et une instabilité du marché.
Paiement (stablecoins) : La liquidité des systèmes de paiement (comme les stablecoins) est cruciale. Quand des particuliers ou entreprises ont besoin de transférer des fonds, ils comptent sur des systèmes de paiement efficaces et fiables. Un manque de liquidité peut entraîner des retards ou des échecs de transaction, perturbant ainsi le fonctionnement de l’économie.
Dans Web3, les échanges sont au centre des services financiers, car le prêt et les paiements existent principalement pour faciliter les transactions (levier et moyen d’échange). Pourquoi alors parle-t-on du « moment AMM » ? Cela découle des limitations intrinsèques des blockchains.
Nous savons que les institutions financières centralisées exécutent leurs règles sur des serveurs haute performance, permettant ainsi une vitesse de matching extrêmement élevée. En revanche, le DeFi implémente ces règles via des contrats intelligents, sacrifiant l'efficacité du matching au profit de la décentralisation et de la confidentialité.
En tant que simulation au niveau de l'« ordinateur mondial », les contrats intelligents offrent des performances relativement faibles. Dans les premiers projets DeFi, que ce soit pour le prêt ou les échanges, le mécanisme de matching était basé sur le modèle traditionnel du carnet d’ordres (order book). Dans ce cadre, le DeFi était largement désavantagé face au CeFi, jusqu’à l’apparition de l’AMM.
Comment maximiser l’efficacité du matching de liquidité sur un « ordinateur mondial » aux performances extrêmement limitées ? Le modèle AMM apporte une solution : utiliser des pools de liquidité et des algorithmes pour assurer un appariement automatique. De nombreux articles ont déjà expliqué son fonctionnement, donc nous n’y reviendrons pas ici. Mais voici ce que nous savons déjà concernant ses avantages :
Aucun market maker traditionnel requis : Dans les marchés financiers classiques, les teneurs de marché proposent des prix d’achat et de vente pour maintenir la liquidité. Avec l’AMM, les fournisseurs de liquidité déposent des fonds dans un contrat intelligent qui ajuste automatiquement les prix selon un algorithme prédéfini et exécute les transactions, rendant inutile l’intervention de market makers traditionnels.
Pools de liquidité : Les pools de liquidité dans le modèle AMM offrent un contrepartie toujours disponible aux traders. Les fournisseurs de liquidité déposent des fonds dans ces pools et reçoivent en retour une part des frais de transaction, incitant davantage de participants à rejoindre et augmentant ainsi la liquidité du marché.
Réduction des frictions de transaction : Grâce à l’automatisation de l’AMM, les utilisateurs peuvent trader à tout moment sans attendre l’appariement d’ordres, réduisant ainsi les délais et les coûts associés.
Stimuler l’innovation DeFi : Le modèle AMM a permis de nombreuses innovations comme le minage de liquidité (liquidity mining) ou les pools à double jeton. Ces nouveautés ont accéléré le développement et l’adoption du DeFi.
L’innovation du mécanisme AMM a permis à l’efficacité de matching du DeFi de rivaliser avec celle du CeFi, déclenchant finalement le « DeFi Summer ».
II. Quel est le conflit fondamental entre jeux et blockchain ?
Aujourd'hui, les jeux entièrement sur chaîne arrivent à un moment similaire à celui du DeFi : comment exécuter un jeu sur un « ordinateur mondial » aux performances extrêmement limitées ? Pour y répondre, analysons le conflit fondamental entre les jeux et la blockchain.
J’ai déjà écrit un article intitulé Quelle est la différence entre les architectures ARC et ECS pour les moteurs de jeux entièrement sur chaîne ?, où j’ai introduit le concept de boucle de jeu (game loop), soulignant que les jeux traditionnels sont basés sur une logique itérative (loop-based).
Les jeux traditionnels reposent sur une architecture itérative (loop-based), car leur mécanisme central est la boucle de jeu. Cette boucle est un processus répétitif qui inclut généralement la gestion des entrées utilisateur, la mise à jour de l’état du jeu et le rendu visuel. Elle s’exécute en continu pendant toute la durée du jeu, typiquement des dizaines à des centaines de fois par seconde, assurant ainsi une fluidité. Dans cette architecture, les systèmes du jeu (moteur physique, IA, etc.) vérifient et traitent les entités et composants concernés à chaque cycle.
En revanche, l’architecture de la blockchain est basée sur le « push » (événementiel). La blockchain est une base de données distribuée où les nœuds partagent et stockent des informations. Lorsqu’un nœud génère une nouvelle transaction (transfert, appel de contrat, etc.), celle-ci est propagée (« poussée ») vers le réseau. Les autres nœuds la reçoivent, la valident puis l’ajoutent à la chaîne. Ce processus est passif : les nœuds n’interrogent pas activement le réseau, mais attendent qu’une transaction leur soit envoyée. D’où le qualificatif « push-based ».
Ces explications répondent déjà à notre question initiale. L’architecture des jeux est généralement « loop-based », tandis que celle de la blockchain est « push-based » : c’est là le conflit fondamental entre jeux et blockchain. Comment résoudre ce conflit ? On peut dire que résoudre ce dilemme marquera le « moment AMM » des jeux entièrement sur chaîne.
Pour approfondir, examinons comment les jeux implémentent la boucle de jeu.
Chaque jeu comprend une série d'étapes : saisie utilisateur, mise à jour de l’état, traitement de l’IA, lecture audio et affichage visuel. Ces étapes sont orchestrées par la boucle de jeu. Sans rentrer dans les détails, concentrons-nous sur la boucle elle-même, en simplifiant les tâches à deux fonctions : mise à jour et affichage. Voici un exemple minimaliste de code de boucle de jeu :
bool game_is_running = true;
while( game_is_running ) { update_game(); display_game(); }
Introduisons trois termes clés :
Tick
Un tick est synonyme de game loop (terme onomatopéique) : 1 tick = 1 game loop.
FPS
FPS signifie « frames per second » (images par seconde). Dans le contexte ci-dessus, c’est le nombre de fois par seconde où la fonction display_game() est appelée.
Vitesse du jeu
La vitesse du jeu correspond au nombre de mises à jour d’état par seconde, autrement dit, au nombre d'appels à update_game() par seconde.
En résumé, le Tick / Game Loop est le cycle fondamental du jeu, déterminant la mise à jour de la logique. Le FPS mesure la fréquence de rendu visuel, influençant la fluidité perçue. La vitesse du jeu définit la progression de la logique, souvent égale au taux de ticks. Idéalement, taux de ticks, FPS et vitesse du jeu devraient être égaux, signifiant qu’un rendu suit chaque mise à jour. En pratique, ces valeurs peuvent différer, notamment sous contraintes techniques ou de performance.
III. Les défis fondamentaux des jeux entièrement sur chaîne
Fort de ces notions, abordons maintenant les principaux défis des jeux entièrement sur chaîne.
-
Incompatibilité entre la boucle de jeu et la blockchain : Les jeux traditionnels reposent sur une boucle de jeu, mettant à jour l’état à chaque tick. Or, la blockchain est pilotée par événements : l’état n’est mis à jour que lorsqu’une transaction ou opération intervient. Cette incompatibilité fondamentale complique l’implémentation d’une boucle de jeu classique dans un jeu entièrement sur chaîne.
-
Latence et temps réel : Le délai de confirmation des transactions blockchain peut introduire un décalage dans la réponse du jeu, problématique pour les jeux nécessitant une réactivité immédiate (jeux d'action, compétitifs). Un mécanisme de ticking efficace doit tenir compte de cette latence et limiter son impact sur l’expérience joueur.
-
Limites de ressources et coût computationnel : Chaque mise à jour d’état sur la blockchain consomme des ressources et génère des frais. Des mises à jour fréquentes dans un jeu sur chaîne peuvent entraîner des coûts prohibitifs. Un mécanisme de ticking efficace doit donc équilibrer fluidité du jeu et coût d’exploitation.
Développer un nouveau mécanisme de ticking adapté aux spécificités de la blockchain constituerait un véritable « moment AMM » pour les jeux sur chaîne. Cela pourrait nécessiter une combinaison innovante de techniques traditionnelles de développement de jeux et des caractéristiques propres à la blockchain, aboutissant à un nouveau cadre de conception.
Tous les types de jeux sont-ils nécessairement basés sur une boucle ? Bien que la majorité le soient, certains jeux relèvent du modèle « push-based » : ils n’ont pas besoin de mises à jour continues ou en temps réel. Par exemple, les jeux de stratégie au tour par tour, les échecs ou certains jeux de cartes. Dans ces cas, l’état n’est mis à jour qu’au moment où un joueur agit, ce qui s’aligne mieux avec le modèle événementiel de la blockchain. Ainsi, pour les jeux entièrement sur chaîne, il serait pertinent de commencer par développer des jeux compatibles avec le modèle « push-based », plus naturellement adaptés à la blockchain.
IV. La chaîne à ticks est le « moment AMM » des jeux entièrement sur chaîne
Scott, fondateur d’Argus, partage ce point de vue :
Les jeux fonctionnent dans un environnement d’exécution piloté par une boucle (loop-driven runtime). Même sans entrée utilisateur, les transitions d’état continuent : le feu brûle, l’eau coule, les cultures poussent, le cycle jour/nuit se poursuit.
Alors, comment concevoir un mécanisme de ticking adapté à la blockchain ? @therealbytes a apporté une réponse. J’ai traduit son article fondateur Comment utiliser OPStack pour construire le cycle horloge des jeux entièrement sur chaîne, qui explique en détail comment utiliser des contrats intelligents et des contrats précompilés pour créer un système de ticking. Malheureusement, en raison de sa technicité, cet article a eu le moins de lectures parmi tous mes articles. Il rappelle l’article historique de Vitalik introduisant l’AMM dans les DEX, Let’s run on-chain decentralized exchanges the way we run prediction markets, où fut formulée pour la première fois la célèbre formule du produit constant « A * B = k ».
(Petite anecdote : à l’époque, on ne parlait pas encore de DeFi, mais d’échanges décentralisés sur chaîne — tout comme aujourd’hui on dit « on-chain game » plutôt que « full-chain gaming »)
Dans cet article, therealbytes a probablement été le premier à proposer d’utiliser les précompilés natifs de la chaîne pour implémenter le ticking : Ticking-Optimism modifie les nœuds rollup pour créer une « transaction tick » (tick transaction), similaire à une « transaction de dépôt », mais au lieu de définir des attributs L1, elle appelle la fonction tick() dans un contrat déployé à l’adresse 0x42000000000000000000000000000000000000A0. Ce contrat peut ensuite appeler un autre contrat en configurant sa variable cible.
Intégrer la fonction de ticking directement au niveau du nœud de la chaîne représente une avancée majeure en termes d’efficacité de la boucle. Cela est comparable à l’amélioration radicale de l’efficacité de matching que l’AMM a apportée au modèle du carnet d’ordres dans le DeFi. À quel point cette amélioration est-elle significative ? Voir les données dans un autre article que j’ai traduit : Chronométrer le « dieu numérique » :
Pour tester pleinement les limites de la chaîne, il a implémenté le jeu de deux manières : une version en contrat intelligent Solidity sur chaîne, et une autre via un moteur précompilé intégré à la chaîne. La version Solidity atteint la limite CPU après 70x70 cellules mises à jour deux fois par bloc (1 bloc/seconde, soit ~10k cellules/seconde). En revanche, la version avec moteur précompilé atteint le même taux avec une grille 256x256, utilisant seulement ~6 % du CPU (~130k cellules/seconde).
V. Conclusion
Si le modèle AMM a permis aux systèmes financiers d’atteindre une grande efficacité de matching et une forte liquidité malgré les limitations de performance de la blockchain, alors la chaîne à ticks (Ticking Chain) permet aux jeux d’obtenir une haute efficacité de boucle et une grande fluidité, même sur une blockchain peu performante.
Ce qui a été décrit ici n’est encore qu’une preuve de concept par therealbytes. Mais en pratique, des moteurs de jeux entièrement sur chaîne commencent déjà à adopter ce modèle de chaîne à ticks. Le premier moteur open source de ce type est @0xcurio, qui utilise OPStack avec une fonction de ticking précompilée pour construire une couche 2. Le deuxième est @ArgusLabs_, qui utilise Polaris pour construire une couche 2 dotée d’une fonction de ticking précompilée. Je suis convaincu que d’autres chaînes à ticks verront bientôt le jour.
Le tableau ci-dessus compare les applications blockchain dans les domaines financier et du jeu. On observe de fortes similitudes. Initialement, le DeFi utilisait le modèle du carnet d’ordres, un système de matching actif. Après le passage à l’AMM, il est devenu un système de matching automatique et passif. De façon analogue, les jeux entièrement sur chaîne utilisaient au départ des méthodes actives comme la « mise à jour paresseuse » (lazy update) ou le « ticking manuel » (manual ticking). En passant à la chaîne à ticks avec fonction précompilée, ils deviennent un système de boucle de jeu automatique et passif. L’AMM améliore la liquidité financière ; la chaîne à ticks améliore la fluidité du jeu.
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
@hiCaptainZ
