Pourquoi devrions-nous rendre les jeux sur chaîne vérifiables ?
TechFlow SélectionTechFlow Sélection
Pourquoi devrions-nous rendre les jeux sur chaîne vérifiables ?
Les grands jeux MMORPG peuvent-ils fonctionner sur une blockchain ?
Dédié à des analyses Web3 approfondiesRédaction : @lordofafew
Traduction : @hicaptainz
Nous aspirons tous à un monde autonome exempt de corruption, de malveillance et de mépris ; un monde durable, éternel et autonome.
Comment pouvons-nous y parvenir ? Comme dans le triangle impossible de la blockchain, ces efforts exigent toujours un certain compromis.
Les mondes autonomes (AWs) sont confrontés au même problème de triangle impossible. Les AWs doivent pouvoir s'étendre à des millions de joueurs concurrents, une difficulté difficile à résoudre.
Les rollups transforment partiellement ce dilemme en un dilemme binaire, grâce à la sécurité héritée du niveau de règlement — tant qu’il existe un actif natif de couche 1 (L1) et un mécanisme de retrait sans autorisation.
Avec les rollups optimistes, vous devez choisir entre évolutivité et sécurité, c’est pourquoi certaines approches de rollup font des compromis sur la sécurité lorsqu’elles atteignent l’évolutivité via une disponibilité de données alternative (alt DA) ou plasma DA. Toutefois, avec les ZK Rollups, vous pouvez prouver l’intégrité de l’état sous des hypothèses minimales de confiance, visant à résoudre les trois défis : évolutivité, sécurité et décentralisation. Le ZK est la solution finale.
Qu'est-ce qu'un jeu vérifiable (Provable Game) ?
Les jeux sur chaîne nous promettent liberté d'expression et souveraineté sur nos informations. Ils possèdent ces attributs car ils fonctionnent sur une blockchain validée par consensus. Les jeux vérifiables utilisant des preuves zk permettent de valider l’état et les calculs du jeu sans avoir besoin d’un grand schéma de consensus. Ces jeux, écrits en Cairo, Noir ou exécutés sur RISC-Zero, peuvent fonctionner indépendamment sur un zkVM isolé similaire à un navigateur, dont la sortie vérifiable garantit une exécution authentique. Cela élargit considérablement les possibilités dans l'industrie des jeux sur chaîne.
Un exemple représentatif est un jeu comme Donkey Kong (similaire à Super Mario). Actuellement, pour certifier votre meilleur score au classement, vous devez jouer sur une machine homologuée afin d'éviter la triche, tout en enregistrant votre partie. En revanche, si Donkey Kong était un jeu vérifiable, les joueurs pourraient concourir dans un environnement isolé. Il suffirait simplement de soumettre une preuve au jeu pour validation après avoir obtenu un haut score. Cette méthode permettrait aux joueurs d’affirmer leur statut de roi de Donkey Kong depuis le confort de leur domicile, sans avoir à enregistrer leur partie !
Exécuter intégralement un jeu dans un zkVM isolé reste aujourd’hui un défi technique. Pour résoudre cela, l’écosystème Dojo travaille à simplifier le processus et réduire la complexité. Des équipes comme Tonk progressent dans le domaine des jeux vérifiables, notamment en réussissant à faire tourner Doom sur un zkVM. À mesure que le coût des preuves diminue et que de nouveaux prouveurs comme Stwo apparaissent, le potentiel de conception de jeux et d'applications vérifiables ne cesse de croître.
Nous n’avons pas besoin d’exécuter nos jeux vérifiables dans un zkVM isolé. Au contraire, nous pouvons exécuter notre jeu sur un mini-réseau StarkNet comportant très peu de participants, tout en conservant la sécurité.
Il est important de noter que cette approche n’est pas exclusive. Par exemple, vous pouvez exécuter un jeu sur chaîne sur une EVM, puis y superposer un jeu basé sur Cairo, renforçant ainsi le jeu principal tout en étendant ses fonctionnalités.
Pourquoi créer des jeux vérifiables ?
Imaginez que le monde de RuneScape (un jeu MMORPG en monde ouvert) disparaisse soudainement, effaçant définitivement toutes les données de jeu de chacun. Cela créerait des joueurs extrêmement frustrés. Ce scénario finira par se produire tôt ou tard, lorsque les développeurs décideront d’éteindre les serveurs. Peut-on faire mieux ? Peut-on créer un monde aussi riche, diversifié et profond que RuneScape, sans que cela puisse jamais arriver ?
Ce défi est précisément ce que l’ensemble du secteur des jeux sur chaîne cherche actuellement à résoudre : créer un monde permanent, immuable et autonome. De nombreuses équipes explorent différentes méthodes, exactement le type d’innovation et d’expérimentation nécessaire.
De nombreuses innovations sont investies dans les jeux sur chaîne, mais notre focus porte sur l’exploration de l’arbre technologique des jeux vérifiables via Cairo et le Starknet VM. Cet article vise à traduire certains concepts de jeux vérifiables en un exemple concret, inspiré du légendaire jeu RuneScape.
(Écrit suite à l’inspiration tirée de la présentation du célèbre joueur Skystrife chad Kooshoba lors de la conférence Ethereum Istanbul)
Le « gobelin » vérifiable
Construisons un monde où vivent des gobelins, et en prenant RuneScape comme référence, concentrons-nous sur la zone initiale de Lumbridge et ses environs pour explorer :
-
Le château de Lumbridge
-
La forêt dense
-
Les gobelins
-
Les objets d’inventaire
Pour un gobelin vérifiable, nous avons besoin de :
-
Simuler les mouvements dynamiques des gobelins et créatures, apportant vie au monde du jeu.
-
Mettre à jour instantanément l’inventaire lorsque le joueur ramasse un objet.
-
Suivre et sauvegarder globalement les progrès des joueurs pour assurer une expérience cohérente.
-
Concevoir des mécanismes anti-exploitation pour garantir l’intégrité du jeu.
-
Une évolutivité capable de supporter des millions de joueurs simultanés.
L’évolutivité des jeux Web2
Le développement traditionnel de jeux repose sur des serveurs centraux pour les fonctions essentielles telles que la gestion des progrès, le comportement des PNJ, la gestion de l’état des joueurs, le contrôle des objets et l’application des règles. Pour s’agrandir, on ajoute davantage de serveurs et on divise l’état du jeu (sharding), permettant ainsi à différents groupes de joueurs d’avoir des instances distinctes de zones de jeu. Bien que ce soit une solution efficace, cette centralisation signifie que les développeurs détiennent le contrôle ultime, y compris la capacité d’éteindre les serveurs. C’est précisément pourquoi l’industrie des jeux sur chaîne a été créée : pour disposer d’un RuneScape fiable…
Approche traditionnelle par blockchain
Tenter de reproduire les fonctions d’un serveur central via une méthode traditionnelle de blockchain est théoriquement possible, mais devient en pratique irréaliste et presque impossible à étendre au-delà de quelques milliers d’utilisateurs simultanés, en raison de plusieurs limitations :
Validation des transactions
Les transactions ou actions des joueurs doivent être validées et traitées par plusieurs nœuds du réseau. Bien que cette méthode assure la sécurité en dupliquant le traitement et en utilisant un consensus rendant le système plus difficile à compromettre, elle crée un goulot d’étranglement majeur en matière de vitesse de traitement des transactions — autrement dit, les TPS. Bien sûr, cela peut être contourné en utilisant un séquenceur central unique (comme le font presque toutes les technologies de couche 2), mais cela implique davantage d’hypothèses de confiance.
Transactions par seconde
La limite de TPS sur la machine virtuelle blockchain affecte la capacité du jeu à traiter les actions des joueurs. Lorsque le nombre de joueurs et leurs actions excèdent la capacité TPS de la blockchain, des files d’attente se forment, entraînant une hausse des frais et une détérioration de l’expérience utilisateur. Cela limite effectivement le nombre de joueurs simultanés qu’un seul séquenceur blockchain peut gérer. Pour surmonter ces limites, Ethereum mise sur une feuille de route centrée sur les rollups, déplaçant l’exécution vers la couche rollup.
Exécuter un monde de jeu sur un rollup améliore considérablement l’évolutivité, mais sans preuves zk, nous restons tributaires d’un grand mécanisme de consensus ou d’hypothèses de confiance larges, potentiellement instables, ce qui introduit des risques. Ainsi, bien que le zk soit considéré comme la solution ultime pour l’évolutivité, il n’est pas encore pleinement réalisé.
(Comparaison des hypothèses de confiance entre couche OP et couche ZK. Les hypothèses ZK restent solides même avec faible participation, permettant l’existence de mini rollups zk)
Une approche vérifiable - Utilisation de preuves récursives et d’une architecture multicouche
L’objectif de toute blockchain est de permettre aux utilisateurs d’avoir une confiance absolue en leurs actions. Ce principe est souvent oublié dans l’industrie ; si notre but n’est pas de créer des systèmes sans confiance, quel est l’intérêt de nos efforts ? Nous pourrions tout aussi bien compter sur des serveurs centralisés, qui excellent dans leurs fonctions.
Dans notre monde RuneScape, nous allons nous concentrer sur l’extension récursive initiée par les STARKs. Tarrence a écrit un article approfondi sur ce sujet, soulignant l’importance des preuves récursives pour maintenir des hypothèses de confiance minimales aux niveaux 2 et 3.
Dans notre monde, nous pouvons utiliser des preuves récursives pour étendre et fragmenter le monde, tout en garantissant que tout gobelin vaincu l’a bien été contre un vrai gobelin.
Une illustration simple :
Analyse de l’architecture
L1 Ethereum
Ici, nous définissons l’état final, permettant à quiconque de reconstruire la L2 s’il le souhaite. C’est ce que fait tout véritable rollup.
L2 Starknet
Ici, nous définissons l’état de la L3, permettant à quiconque de reconstruire la L3 s’il le souhaite. C’est ici que nous conservons l’état global du monde.
L3 Realms World ou autre L3
C’est une couche d’exécution haute performance prenant en charge l’état global des joueurs. Ici, nous conservons l’état final du shard Lumbridge. Cela permet de créer rapidement de nouveaux shards si nécessaire, en restaurant les soldes des joueurs.
Shards temporaires Lumbridge
« Temporaire » signifie éphémère, mettant l’accent sur l’importance d’une gestion efficace et sécurisée de l’état de jeu de chaque joueur — l’élément le plus crucial pour tous les joueurs. En adoptant le sharding de chaîne, en limitant chaque shard à un maximum de 30 joueurs — un chiffre théorique, potentiellement supérieur, mais donné ici comme exemple gérable — nous reproduisons la structure des serveurs traditionnels, avec une amélioration clé : l’utilisation de preuves zk pour garantir l’intégrité des changements d’état. Cela nous permet de nous étendre horizontalement à des milliers de fragments sans sacrifier la performance de quiconque.
Application de cette méthode à RuneScape
Comme le concept d’extension horizontale dans les serveurs de jeux traditionnels, nous adoptons ici une stratégie similaire. En divisant le monde du jeu en nombreux fragments plus petits, nous permettons au système de s’agrandir efficacement et d’accueillir des millions d’utilisateurs simultanés.
La différence clé entre les serveurs traditionnels et cette méthode est que les joueurs ont un contrôle total sur leur propre état de jeu, assurant une autonomie et une sécurité accrues. Chaque élément d’état peut être reconstruit !
Un exemple
Lorsqu’un joueur arrive à Lumbridge, il est affecté à une chaîne temporaire dotée d’une capacité, lui permettant d’interagir avec jusqu’à 29 autres joueurs, tout en assurant des performances élevées grâce à des transactions rapides et peu coûteuses. Plongeons plus profondément :
La forêt, avec des ressources comme le bois
Grâce à cette chaîne temporaire, nous pouvons suivre le déplacement du joueur vers la forêt, appliquer un certain niveau de physique du mouvement, en exploitant la puissance de calcul bon marché fournie par ce shard. Ensuite, il peut continuer à couper du bois, l’ajouter à son solde et faire progresser son état de joueur.
Gobelins et autres monstres de faible niveau
Les gobelins peuvent être efficacement simulés via l’horloge de jeu intégrée au séquenceur. Quand l’horloge avance, le séquenceur met à jour l’état et la position des gobelins jusqu’à ce qu’un utilisateur intervienne pour les tuer. Si nous le souhaitons, nous pouvons consacrer une bande passante importante à cela, car en limitant le nombre de joueurs, nous pouvons maximiser les mouvements des PNJ.
Objets dispersés ou tombant des monstres
Les objets peuvent être ramassés et stockés dans le solde du joueur. Lorsque le joueur termine sa session, ces objets sont sauvegardés dans l’état global. Ces valeurs ne sont pas éphémères, mais conservées dans la L3 pour être utilisées lors de la prochaine session.
Fin de la partie
À la fin de la session de jeu, l’état du joueur est conservé dans un état global en remontant à la L3, préparant ainsi son arrivée dans une nouvelle zone ou session. Puis cet état est validé sur StarkNet L2, suivi d’une validation sur la L1, établissant efficacement un RuneScape prouvablement équitable.
Questions-Réponses
L’ensemble de la pile que nous construisons est open source — rejoignez le discord Dojo ou contribuez directement au projet.
Question 1 : Et les ponts entre ces couches ? N’est-ce pas un cauchemar pour les joueurs ?
Oui, les ponts posent effectivement problème actuellement. Toutefois, une solution claire est déjà utilisée dans l’écosystème Starknet et sera bientôt disponible sur d’autres couches 2. On les appelle des preuves de stockage. Oui, je fais référence à mon tweet. La deuxième partie abordera ce sujet.
Question 2 : Pourquoi choisir les preuves récursives et les chaînes temporaires plutôt qu’une autre méthode ?
Précisons que c’est la méthode adoptée par les écosystèmes Dojo, Cartridge et Realms pour étendre le monde que nous imaginons. Ce n’est pas la seule voie possible, et explorer diverses approches est bénéfique. Certaines des personnes les plus brillantes que je connaisse travaillent également sur les problèmes les plus difficiles de ce domaine, et leurs travaux méritent absolument d’être suivis.
Lattice - OP Plasma combiné à Redstone, offrant des transactions très économiques.
Playmint - Moteur optimiste unique pour des parties rapides.
PoP - Shards EVM spécialisés.
Argus - Shards EVM personnalisés pour jeux.
Curio - Approche modifiée de serveur EVM.
Créer un RuneScape libre et ouvert capable de supporter des millions de joueurs simultanés n’est pas chose aisée. Pourtant, la sagesse collective et la créativité de l’industrie des jeux sur chaîne sont des forces puissantes. Il est donc raisonnable de s’attendre à voir apparaître de tels jeux dans les 12 à 24 mois à venir. Il est temps de revenir à RuneScape, ou plus précisément, d’accueillir l’aube de RealmScape.
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
