Analyse du noyau des jeux entièrement sur chaîne : moteur MUD et World Engine
TechFlow SélectionTechFlow Sélection
Analyse du noyau des jeux entièrement sur chaîne : moteur MUD et World Engine
Grâce à l'amélioration des infrastructures, la construction et la réalisation de diverses idées complexes s'effectueront via les MUD et s'intégreront grâce à des schémas Rollup plus sophistiqués. Un nouveau paradigme de la blockchain pourrait ainsi émerger à partir des jeux entièrement sur chaîne.
Dédié à des analyses Web3 approfondiesAuteur : Solaire, YBB Capital
En raison des limitations structurelles de la blockchain basée sur une liste chaînée, construire une application DApp utile directement sur la chaîne n’a jamais été chose aisée. Pourtant, malgré cette contrainte, les pionniers n’ont jamais cessé d’avancer. Avec l’apparition de la célèbre formule du pool de produits constants « x * y = k », Uniswap, codé en quelques centaines de lignes seulement, a révolutionné le secteur DeFi et transformé radicalement le récit de la cryptomonnaie. Si une application aussi simple peut atteindre un tel niveau grâce à la créativité des développeurs, qu’en est-il alors des applications plus complexes ? Par exemple, pourrait-on intégralement construire un jeu vidéo ou un réseau social directement sur la blockchain ? Cela aurait pu sembler fou par le passé, mais aujourd’hui, avec l’ouverture des Rollups vers une meilleure extensibilité, cette possibilité devient subtilement envisageable.
Le DeFi a déjà attiré des milliers de milliards de dollars de TVL (valeur totale verrouillée) dans l’écosystème crypto. Comment les applications DApp à complexité accrue peuvent-elles être réalisées ? Et pourraient-elles propulser une nouvelle fois la cryptomonnaie vers de nouveaux sommets ? Peut-être que les jeux entièrement sur chaîne, encore à leurs débuts, ont la réponse. Cet article se penche sur les jeux entièrement sur chaîne à travers quatre axes : leur histoire, leur définition actuelle, les moyens techniques de création et d’exécution, ainsi que leur signification pour l’avenir de la crypto.
Origines et évolution des jeux entièrement sur chaîne
L’histoire des jeux entièrement sur chaîne remonte à environ dix ans. Mikhail Sindeyev a forké Namecoin pour créer Huntercoin, le premier jeu blockchain au monde. Lancé en 2013 comme prototype expérimental, Huntercoin a rapidement rassemblé une communauté passionnée en ligne, soutenue par de nombreux membres influents du forum bitcointalk.org. Grâce à l’engouement des amateurs de technologie et de jeux vidéo, le fil de discussion le plus populaire consacré à Huntercoin a accumulé plus de 380 000 vues. Malheureusement, Mikhail Sindeyev est décédé d’un AVC en février 2014, ce qui a plongé le développement de Huntercoin dans l’impasse. Son jeton HUC a presque atteint zéro en 2015. Bien que cette première tentative n’ait pas abouti, heureusement, l’histoire des jeux entièrement sur chaîne ne s’est pas arrêtée là.
En 2020, Gubsheep (Brian Gu), Alan Luo et SCOTT SUNARTO, inspirés par le roman Le Problème à trois corps : La Forêt obscure, ont développé un jeu MMORTS spatial homonyme appelé Dark Forest. Construit sur Ethereum, le jeu inscrit toutes ses règles et sa logique dans des contrats intelligents, faisant de chaque action un transfert transactionnel directement sur la chaîne. L’élément central du gameplay repose sur la technologie ZK-SNARKs (preuves à divulgation nulle de connaissance), utilisée pour créer un « brouillard de guerre » simulant la loi de la forêt obscure du roman (dès qu’une civilisation cosmique est découverte, elle est inévitablement attaquée par d’autres).
Par exemple, lorsqu’un joueur souhaite agir, il doit respecter la loi de la forêt obscure : il ne peut pas révéler ses coordonnées tout en se déplaçant de la planète A à la planète B. Il doit soumettre les coordonnées de départ et d’arrivée afin de prouver la validité de son mouvement. Toutefois, les blocs d’Ethereum étant totalement transparents, Dark Forest utilise la méthode suivante pour masquer ces informations. Le joueur choisit sa planète de départ et sa destination, deux données privées. Il calcule ensuite les hachages de ces positions et les soumet sur la blockchain. À ce stade, le joueur effectue un engagement (phase Commit). En raison de la nature unidirectionnelle des fonctions de hachage, ces valeurs ne permettent pas de retrouver les positions réelles des planètes. Puis vient la phase de vérification (phase Reveal), durant laquelle le joueur génère et soumet une preuve à divulgation nulle. Cette preuve peut être vérifiée par n’importe qui sans révéler aucune information sur les positions des planètes du joueur.
Ainsi, le premier jeu entièrement sur chaîne capable de dissimuler des informations dans un environnement transparent comme Ethereum venait de naître. Ce projet audacieux et visionnaire a rapidement fait sensation dans tout l’écosystème crypto. Vitalik (le fondateur d’Ethereum) lui-même a partagé et loué le jeu sur Twitter.
Toutefois, après le lancement de Dark Forest et l’afflux de plus de 10 000 joueurs, des difficultés sont apparues. La performance d’Ethereum s’est avérée insuffisante pour supporter une application aussi complexe. Le jour même du lancement, toute la blockchain a été saturée, entraînant des frais de gaz astronomiques. De plus, étant donné que le jeu reposait sur l’architecture et les bibliothèques utilisées pour les applications DeFi, les optimisations ultérieures n’ont fait qu’atténuer la douleur sans résoudre le problème fondamental.
Fort de cette expérience, inspiré par les perspectives offertes par les ZK-SNARKs et conscient des limites rencontrées, le créateur du jeu Brian Gu a fondé 0xPARC, un institut de recherche dédié aux ZK-SNARKs, afin de promouvoir le développement des preuves à divulgation nulle. Une autre branche de 0xPARC, Lattice, a été chargée de concevoir et maintenir le moteur de jeux entièrement sur chaîne MUD. Quant au cofondateur SCOTT SUNARTO, il a commencé à développer World Engine, un cadre de Rollup fragmenté spécialement conçu pour exécuter des jeux entièrement sur chaîne.
Les preuves à divulgation nulle sont aujourd’hui largement utilisées et bien connues. Nous allons donc nous concentrer principalement sur les deux autres composants : le moteur MUD et World Engine — soit la création et l’exécution. Mais auparavant, il convient de comprendre la définition et la nouvelle conception des jeux entièrement sur chaîne proposées par les promoteurs (0xPARC).
Autonomous Worlds
Selon les travaux publiés par 0xPARC dans sa collection d’articles intitulée Autonomous Worlds, un jeu entièrement sur chaîne doit respecter cinq critères :
-
Données issues de la blockchain : la blockchain n’est pas simplement un stockage auxiliaire ni un miroir des données hébergées sur des serveurs propriétaires. Toutes les données significatives sont accessibles directement sur la blockchain, et pas uniquement celles relatives à la propriété d’actifs. Cela permet au jeu de tirer pleinement parti des avantages de la blockchain programmable : stockage transparent et interopérabilité sans permission.
-
Logique et règles implémentées via des contrats intelligents : par exemple, les combats dans le jeu, et non seulement la propriété des objets, ont lieu sur la chaîne.
-
Le développement du jeu suit les principes d’un écosystème ouvert : les contrats du jeu et les clients accessibles sont tous open source. Les développeurs tiers peuvent créer des plugins, des clients externes ou des contrats interopérables, redéployer complètement le jeu, personnaliser l’expérience ou même forker leur propre version. Cela permet aux développeurs de tirer parti de la créativité collective d’une communauté alignée dans ses incitations.
-
Le jeu existe durablement sur la chaîne : ce point est étroitement lié aux précédents. La question clé pour déterminer si un jeu est nativement crypto est celle-ci : si demain le client fourni par les développeurs principaux disparaît, le jeu reste-t-il jouable ? La réponse est généralement oui, mais uniquement si le stockage des données est sans permission, si la logique du jeu peut s’exécuter sans permission, et si la communauté peut interagir avec les contrats principaux sans dépendre de l’interface fournie par l’équipe centrale.
-
Le jeu peut interagir avec ce que nous considérons comme ayant de la valeur : la blockchain fournit une interface applicative native pour la notion même de valeur. Par défaut, les actifs numériques peuvent interagir avec d'autres actifs qui nous importent. Cela reflète la profondeur et la signification du jeu, contribue à les renforcer, et relie ainsi le monde du jeu au monde « réel ».
Un jeu entièrement sur chaîne construit selon ces critères peut être vu comme un monde fondé sur la blockchain, également appelé Autonomous World (monde autonome).
Mais qu’est-ce qu’un monde ? Un monde ne désigne pas nécessairement le monde réel. Il peut prendre la forme d’un roman, d’un film, d’un jeu, d’un poème ou même d’un système juridique. Dans chacun de ces mondes, un centre (l’auteur, le développeur ou un groupe) fixe le cadre et les règles avant de les transmettre. Le degré d’autonomie varie grandement selon les cas. Par exemple, dans un jeu comme Minecraft (Monde), très ouvert, les joueurs bénéficient d’une grande autonomie : en assemblant différents blocs et en modifiant les règles, ils peuvent créer leur propre univers. À l’inverse, un monde moins autonome serait celui d’un roman comme Harry·Potter, dont l’univers magique découle entièrement des règles et du cadre imaginés par J.K. Rowling.
Si la blockchain constitue la base du monde, elle conserve rigoureusement l’ensemble des entités présentes dans son état. De plus, elle formalise les règles par code informatique. Un monde reposant sur une blockchain permet à ses habitants de participer au consensus. Il fonctionne comme un réseau informatique qui parvient à un accord à chaque ajout d’une nouvelle entité.
Du point de vue du monde, deux concepts liés à la blockchain doivent être définis :
-
Racine d’état de la blockchain : la racine d’état représente une compression de toutes les entités présentes dans le monde. Connaître la racine d’état permet de vérifier si une entité est réelle. Croire en la racine d’état d’un monde équivaut à croire en ce monde lui-même. Par exemple, 0x411842e02a67ab1ab6d3722949263f06bca-20c62e03a99812bcd15dce6daf26e est la racine d’état d’Ethereum à 19h30 UTC le 21 juillet 2022 — un monde reposant sur une blockchain. Lors du calcul de cette racine, toutes les entités du monde Ethereum sont prises en compte. Elle représente l’intégralité du contenu de ce monde à cet instant précis.
-
Fonction de transition d’état de la blockchain : chaque blockchain définit une telle fonction, assimilable à une règle explicite d’introduction. Elle précise comment l’état précédent du « monde » — ensemble d’entités virtuelles — évolue par l’ajout de nouvelles entités, suite aux entrées humaines ou mécaniques. Dans le cas de Bitcoin, cette fonction définit comment les soldes sont dépensés et transférés entre adresses.
Ainsi, en voyant un jeu entièrement sur chaîne comme un monde fondé sur la blockchain, on obtient un monde décentralisé doté d’une autonomie infinie, autrement dit un monde autonome.
Les obstacles à la création
Durant les premières explorations de nouveaux designs de jeux entièrement sur chaîne, les développeurs ont souvent été limités par l’architecture traditionnelle des DApps et les bibliothèques destinées aux applications DeFi. Dark Forest et d’autres premiers jeux entièrement sur chaîne ont dû adopter l’architecture et les bibliothèques utilisées pour les applications DeFi, devenant ainsi le choix par défaut de l’époque.
Les méthodes initiales de création de jeux entièrement sur chaîne pouvaient se résumer en quatre points :
-
Lorsque plusieurs contrats accèdent au même état : plusieurs contrats intelligents peuvent modifier les mêmes données ou état, ce qui risque de provoquer des incohérences ou autres problèmes. Parfois, le pattern Diamond (modèle diamant) était utilisé pour résoudre ce type de conflits (méthode permettant de contourner les problèmes d’héritage multiple dans Solidity).
-
Écriture de multiples structures de données : chaque entité (soldat, planète, etc.) possède sa propre structure de données et son type spécifique.
-
Écriture de fonctions Getters : ces fonctions retournent des lots d’éléments à partir d’une structure de données, permettant de récupérer l’état initial ou les données depuis la chaîne. Par exemple, la fonction getPlanets() pourrait renvoyer la liste complète des planètes.
-
Événements : chaque structure de données inclut un événement, fonctionnalité spécifique des contrats intelligents permettant à l’application de synchroniser ou mettre à jour son état lorsque de nouveaux blocs sont ajoutés à la chaîne. Par exemple, la création d’une nouvelle planète déclenche un événement que l’application écoute pour actualiser sa liste affichée.
Construire un jeu entièrement sur chaîne selon ce modèle s’avère extrêmement fastidieux. Même si des optimisations continuelles peuvent atténuer la difficulté, cette approche reste loin d’un véritable moteur universel.
Le créateur de mondes — le moteur MUD
La création du moteur MUD résulte de la réflexion collective sur les problèmes passés et actuels. MUD est un framework destiné à construire des applications complexes sur Ethereum. Il propose des conventions pour organiser les données et la logique, tout en abstrayant les complexités de bas niveau, permettant aux développeurs de se concentrer sur les fonctionnalités de l’application. Il standardise le stockage des données sur la chaîne. Grâce à ce modèle de données normalisé, MUD fournit automatiquement tout le code réseau nécessaire à la synchronisation entre les contrats et le client.
La dernière version de MUD comporte actuellement cinq composants :
-
Store : une base de données sur la chaîne.
-
World : un framework d’entrée normalisant le contrôle d’accès, les mises à jour et les modules.
-
tools : des outils de développement ultra-rapides basés sur Foundry.
-
Stockage client des données : reflète magiquement l’état de la chaîne.
-
MODE : une base Postgres pouvant exécuter des requêtes SQL.
Compatibilité EVM totale, liberté extrême
La polyvalence de MUD ne se limite pas au réseau principal d’Ethereum : tant que le langage est supporté, MUD fonctionne parfaitement sur toute blockchain compatible EVM, que ce soit Polygon, Arbitrum, Optimism ou Gnosis Chain.
De plus, bien que MUD soit le framework privilégié par la communauté des Autonomous Worlds et des jeux sur chaîne, ses usages vont bien au-delà. MUD offre une liberté exceptionnelle, sans imposer de modèle de données rigide aux développeurs. En résumé, toute fonctionnalité réalisable avec des mappings et tableaux Solidity peut être facilement implémentée dans MUD. Sur le plan de la disponibilité des données, qu’il soit déployé sur le réseau principal ou sur des Rollups, une application MUD peut rivaliser avec des applications classiques comme ENS ou Uniswap.
Idées fondamentales
MUD, conçu comme une suite d’outils et bibliothèques hautement cohérents pour les applications complexes sur chaîne, repose sur trois idées principales :
-
Tous les états sur chaîne sont stockés dans la base de données Store : Store est une base de données intégrée à l’EVM, similaire à SQLite, avec des concepts de tables, colonnes et lignes. Store permet une gestion plus structurée des données, sans dépendre des méthodes de stockage fournies par le compilateur Solidity. Il supporte la création dynamique de tables au moment de l’exécution, et permet d’enregistrer des hooks pour créer automatiquement des vues indexées, offrant ainsi davantage de flexibilité.
-
La logique est sans état et partitionnée entre contrats via des permissions personnalisées : « World » agit comme point d’entrée, orchestrant l’accès des différents contrats intelligents à « Store ». Quand un « World » est déployé, il crée automatiquement un « Store ». Chaque table dans « Store » est enregistrée sous un espace de noms spécifique. Lorsqu’une fonctionnalité (comme la logique de transfert entre adresses) est ajoutée à « World », elle est enregistrée dans un espace de noms et appelée « système ». Ces « systèmes » sont en réalité des contrats intelligents, mais contrairement aux contrats traditionnels, ils sont sans état et ne détiennent pas directement les données. Ils lisent et écrivent via « World Store ». Grâce à cette conception, ces « systèmes » peuvent être réutilisés entre différents « Worlds » sur la même chaîne.
-
Pas besoin d’indexeurs ou de sous-graphes : l’interface reste synchronisée : lorsqu’on utilise Store (et par extension World), les données sur chaîne sont automatiquement introspectées (auto-inspection). Toute modification est diffusée via des événements standards. Grâce au nœud « MODE », l’état de la chaîne est converti en temps réel en base SQL, restant à jour avec une latence de l’ordre du milliseconde. En outre, MUD fournit des outils de requête comme MUD QDSL et GraphQL, simplifiant grandement la synchronisation frontale. Pour les développeurs React, MUD propose des Hooks spécialisés permettant un rattachement et une mise à jour automatiques de l’état des composants.
Rompre les chaînes
Reprenons maintenant les difficultés passées à la lumière des trois idées fondamentales de MUD, et voyons comment MUD brise les chaînes des applications complexes.
-
Lorsque plusieurs contrats accèdent au même état : grâce à la structure « World » et « Store », l’état sur chaîne est géré de manière centralisée. Tous les contrats intelligents (appelés « systèmes » dans MUD) accèdent et modifient les données de « Store » via « World ». Cela garantit que toutes les modifications transitent par un point d’entrée unique, réduisant ainsi les risques d’incohérence ou de conflit. Grâce aux espaces de noms et chemins, MUD permet un contrôle fin de l’accès aux données. Différents « systèmes » disposent de permissions distinctes, assurant que seuls les systèmes autorisés puissent modifier certaines données.
-
Structures de données : contrairement aux méthodes traditionnelles de stockage Solidity, « Store » de MUD offre un modèle tabulaire proche de SQLite, permettant un stockage et une gestion plus structurés. Chaque entité (soldat, planète, etc.) peut avoir sa propre table, avec plusieurs colonnes pour ses attributs.
-
Fonctions Getters : puisque « Store » structure les données, leur récupération devient simple et intuitive. Les développeurs peuvent utiliser un langage de requête similaire à SQL, sans avoir à écrire de fonctions getters spécifiques. Par exemple, obtenir toutes les planètes revient à interroger la table des planètes, sans nécessiter de fonction getPlanets().
-
Événements : MUD dispose d’une fonction d’introspection automatique : toute modification de données est détectée et déclenche automatiquement un événement correspondant. Les applications peuvent écouter ces événements pour synchroniser leur état, sans avoir à définir manuellement des événements pour chaque structure.
Ce qui précède décrit les briques de base de MUD et l’utilisation partielle de ses composants. MUD permet également de construire des scénarios et applications bien plus complexes.
Exécuter un monde : World Engine
L’exécution de jeux entièrement sur chaîne a toujours constitué un défi majeur pour Ethereum. Avec la montée en puissance rapide des Rollups et l’approche de la mise à jour Cancun, les coûts devraient chuter drastiquement tandis que les vitesses augmenteront sensiblement. Les jeux entièrement sur chaîne sont désormais prêts à décoller. Pourtant, les Rollups dominants actuels sont essentiellement conçus pour les transactions, et aucun n’est véritablement adapté aux jeux entièrement sur chaîne.
World Engine, produit phare d’Argus, est justement un Rollup à architecture fragmentée spécialement conçu pour les jeux entièrement sur chaîne. Comme il n’est pas encore en test public, notre analyse se fondera sur les blogs et présentations officiels du projet.
Quel type de Rollup pour les jeux entièrement sur chaîne ?
-
Haute débit et TPS élevé : traitement plus rapide des transactions, latence plus faible, meilleure extensibilité.
-
Lecture et écriture étendues : la plupart des Layer 2 sont conçus pour un haut débit d’écriture, mais les jeux nécessitent aussi des lectures fréquentes (par exemple, pour connaître la position d’un joueur). Lecture et écriture sont donc toutes deux cruciales.
-
Chaîne extensible horizontalement : l’extensibilité horizontale consiste à ajouter des nœuds et ressources pour augmenter la capacité du système face à la demande croissante. Cela évite le problème du « voisin bruyant » (Noisy Neighbor), où une application affecte négativement les autres par une surconsommation de ressources.
-
Flexibilité et personnalisation : permettre de modifier facilement la machine d’état pour l’adapter aux besoins du jeu, notamment en intégrant une boucle de jeu auto-exécutable.
-
Tick rate : les « ticks » sont les unités atomiques du temps dans un jeu. Pour une latence minimale, un tick rate élevé (plus de blocs par seconde) est nécessaire.
Architecture en fragments (sharding)
Pour atteindre ces objectifs, l’équipe s’est inspirée des années 1990 et 2000, période où les jeux en ligne comme les MMO commençaient à émerger. À l’époque, avec des technologies de serveurs et de réseau limitées, il fallait trouver des moyens de permettre l’interaction de milliers de joueurs. Le « sharding » (fragmentation) fut l’une des solutions : répartir les joueurs sur différents serveurs ou « shards », chacun hébergeant indépendamment une partie des joueurs, cartes et données.
Par exemple, Ultima Online, un MMORPG précurseur, a mis en œuvre le concept de sharding. Chaque shard représentait un monde virtuel distinct, pouvant accueillir un nombre limité de joueurs. Les avantages étaient nombreux :
-
Extensibilité : en répartissant les joueurs, le jeu pouvait s’agrandir plus facilement.
-
Réduction de la charge : chaque serveur gérait moins de joueurs et de données, améliorant les performances.
-
Éviter les congestions : les joueurs étaient mieux répartis, offrant une expérience plus fluide.
-
Optimisation géographique : en plaçant les joueurs près de leur shard, la latence réseau diminuait, améliorant la réactivité.
Comment importer ce concept dans World Engine ? Contrairement à de nombreux ordonnanceurs de sharding passés, la conception de « World Engine » répond mieux à des besoins spécifiques. Ses axes d’optimisation sont le débit et le temps d’exécution. Pour assurer un « tick rate » efficace (fréquence de mise à jour par seconde) et un temps de bloc court, il fonctionne par défaut en mode synchrone. L’objectif est de traiter rapidement les transactions afin de maintenir une expérience de jeu ou une performance système optimale. L’
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
@YBBCapital
