Un nouveau chapitre pour les jeux blockchain : développer des jeux prouvables avec ZKWASM
TechFlow SélectionTechFlow Sélection
Un nouveau chapitre pour les jeux blockchain : développer des jeux prouvables avec ZKWASM
Si l'on place toute la logique du jeu sur la chaîne, la capacité de calcul limitée de la machine virtuelle Ethereum (EVM) deviendra le principal goulot d'étranglement pour le développement du jeu.
Dédié à des analyses Web3 approfondiesAuteur : Blade Research
Auteurs principaux : wangyao, 0xbrawler
Sommaire
- Pourquoi développer des jeux prouvables (Provable Games) ?
- Architecture technique de Blade Games
- 1) Développement d’un jeu de défense tour simple basé sur zkwasm
- 2) Zinity : la première solution permettant de développer directement des jeux prouvables depuis Unity
- Jeux d’arcade et application ERC-6551
- Le jeu que nous présenterons à ETHdenver
- Plans futurs et sujets de recherche
Remerciements à Sinka, Wangyao, Will Robinson, Mohamed Fouda, LoneSCV, 0xAiko, Simon Chan, Maggie Wu, James Fang, Zee et d'autres pour leurs contributions à cet article.
Version courte :
- L'approche du coprocesseur ZK fournit les hypothèses de confiance nécessaires aux jeux vérifiables, ainsi que la puissance de calcul requise pour créer des expériences de jeu engageantes.
- Pour les développeurs de jeux expérimentés, une solution native Unity/Unreal est absolument nécessaire, plutôt que de synchroniser un noyau logique en Solidity/Cairo avec l'animation et le rendu dans Unity.
- L'expérience future des développeurs de jeux sur chaîne et de jeux vérifiables sera hautement modulaire et interchangeables (jusqu'où aller sur chaîne ? Nous pensons que cela devrait être décidé par les développeurs et les utilisateurs).
- À l'avenir, nous croyons qu'il existera des méthodes flexibles pour équilibrer les hypothèses de confiance, le coût des preuves et le coût de développement, afin de concevoir des jeux vérifiables à coût maîtrisé.
Pourquoi développer des jeux prouvables ?
L'année 2023 a vu prospérer les jeux sur chaîne (FOCG) et les mondes autonomes (AW), avec l'émergence de nombreuses infrastructures comme MUD.dev, Dojo, World Engine, Keystone, Paima, etc. En outre, des fournisseurs de services Rollup tels qu'Altlayer, Caldera et Conduit ont attiré de nombreux développeurs de jeux entièrement décentralisés.
Cependant, après avoir développé et exploité notre premier jeu battle royale sur chaîne, Loot Royale, atteignant entre 600 et 800 utilisateurs actifs quotidiens en un mois, nous avons identifié un problème majeur :
Si toute la logique du jeu est placée sur chaîne, la capacité limitée de calcul de la machine virtuelle Ethereum (EVM) devient le principal goulot d’étranglement du développement de jeux.
Cette limitation en puissance de calcul restreint les types de jeux possibles (jeux peu gourmands en calcul, monothread, asynchrones principalement) ainsi que l’expérience utilisateur (attente du minage des transactions, chargement RPC, etc.).
Voici quelques exemples concrets. Nous avons reçu des retours comme « J’espère que ma transaction sera incluse à temps, pour que mon attaque réussisse » ou encore « Quand les données RPC seront-elles enfin chargées ? ». Cette situation doit changer.
Les joueurs sont vraiment frustrés par l’attente du chargement RPC
Après avoir expérimenté diverses piles technologiques, nous sommes convaincus que si les calculs peuvent être prouvés hors chaîne, leur niveau de fiabilité peut être extrêmement proche de celui des transactions/calculs entièrement sur chaîne. Nous adoptons donc le principe « exécution hors chaîne, vérification sur chaîne » pour contourner les limitations de calcul de l’EVM. Cette approche présente plusieurs avantages :
- Amélioration de l’expérience utilisateur et réduction des temps d’attente
- Élargissement des catégories de jeux, notamment vers des jeux « mid-core » plus exigeants comme les jeux de défense tour
- Possibilité d’utiliser des informations cachées dans les jeux
Nous allons d’abord brièvement expliquer comment nous utilisons zkWASM pour développer des jeux prouvables. Ensuite, nous présenterons notre solution zkwasm-unity, la première du secteur permettant de développer directement des jeux prouvables à partir de Unity.
Architecture technique de Blade Games
Développement d’un jeu de défense tour simple via zkwasm
L’architecture technique se divise en deux parties. La première consiste à écrire un jeu simple de type PvE ou PvP en Rust, puis à le valider via zkwasm.
La deuxième partie concerne notre feuille de route : nous prévoyons de développer un compilateur qui transformera le C# en wasm, tout en adaptant légèrement l’architecture existante de zkwasm, afin d’obtenir une solution plus modulaire et flexible pour le développement de jeux prouvables. (zkwasm, développé par Delphinus Labs, est une machine virtuelle ZK capable d’exécuter du code wasm et de générer une preuve zkSNARK de son exécution.)
Commençons par un exemple PvE – nous développons le jeu en Rust avec le moteur Bevy.
Rust peut facilement être compilé en wasm, générant une image wasm avant traitement par la machine virtuelle zkwasm. Ensuite, nous pouvons choisir de publier la trace d’exécution sur une couche de disponibilité des données (Data Availability Layer) et de la prouver ultérieurement. Ou bien, l’utilisateur peut choisir de générer immédiatement la preuve et de l’envoyer sur chaîne (avec une seule GPU RTX 4090, environ 45 secondes suffisent pour produire une preuve de taille 1 million d’opcodes, ce qui est suffisant pour un jeu de défense tour au rythme lent).
Le jeu est ensuite divisé en plusieurs étapes :
- Le joueur valide la configuration de la carte et soumet les informations associées en tant que commit sur chaîne
- La logique du jeu s’exécute en Rust pour une vague de combat ; la trace d’exécution peut être prouvée par zkwasm, et le joueur soumet la preuve zk sur chaîne
- Une nouvelle vague de monstres arrive ; le joueur peut garder ses tours ou soumettre une nouvelle configuration
- Le joueur ne peut pas modifier la position des tours pendant une vague ; s’il change la configuration, il peut soumettre un nouveau commit
(Le joueur valide la configuration de la carte et soumet la sortie de zkwasm sur chaîne)
(La logique du jeu exécute une vague de combat en code Rust. La trace d’exécution associée peut être prouvée par zkwasm, et le joueur soumet la preuve zk sur chaîne)
Zinity : la première solution permettant de développer directement des jeux vérifiables depuis Unity
Pour beaucoup de développeurs de jeux, développer sur chaîne signifie devoir apprendre Solidity, Rust ou Cairo, et donc abandonner le C#, leur langage habituel. De plus, intégrer le rendu et l’animation d’Unity avec une logique de jeu écrite en Solidity/Cairo (basée sur MUD/Dojo) est un processus long et fastidieux.
Nous allons publier la première solution native Unity utilisant un coprocesseur ZK, un framework de développement appelé « zkServer » pour les jeux sur chaîne. Nous l’appelons Zinity.
Le code du jeu est dissocié en deux parties :
1) Le code logique central (attaques, coffres au trésor, coordonnées des unités, etc.)
2) Le reste du code. Ces deux parties sont ensuite compilées depuis C# en wasm. La logique centrale est exécutée par le runtime zkwasm, tandis que le reste tourne sur un runtime C# classique. Un protocole de communication gère les échanges entre les deux parties.
zkWASM observera sous forme de code binaire des actions telles que « le joueur A a placé une tour aux coordonnées (x,y) au temps X ». Au début d’une nouvelle partie, on récupère l’état initial du jeu. Pendant la partie, zkwasm observe et calcule davantage d’entrées joueurs. À la fin de la partie, un nouvel état du jeu accompagné de son hachage et de sa trace d’exécution est généré.
On peut choisir de publier toute la trace d’exécution sur une couche DA (Eigenlayer, Celestia, Avail, Greenfield, etc.), ou bien uniquement le hachage, en stockant la trace elle-même dans un stockage cloud. De plus, nous intégrerons une période de contestation, utilisant des preuves de faute (fault proofs), pour valider l’état du jeu.
En outre, pour les résultats de jeu importants impliquant de fortes incitations économiques, l’utilisateur peut choisir de générer une preuve zk complète de toute la partie et de la publier directement sur la couche DA.
Tout ce processus sera finalement intégré sous forme de SDK Unity (sans animation ni rendu) ou d’outil CLI, guidant toute la chaîne d’outils.
Cette solution pourra aussi être étendue à d’autres moteurs de jeu comme Unreal ou Godot. Notre feuille de route inclut également l’intégration avec d’autres zkVM (comme RiscZero) et différentes couches DA (Eigenlayer, Celestia, etc.).
Grâce à cette méthode, nous pouvons considérablement élargir la communauté des développeurs de jeux sur chaîne / jeux vérifiables, en attirant des développeurs web2 et des studios de jeux traditionnels.
Jeu d’arcade sur chaîne + défense tour avec ERC-6551
Nous explorons également le concept d’arcade sur chaîne autour des jeux vérifiables. Par exemple, un joueur pourrait soumettre une configuration de tours/obstacles sur chaîne, et un autre joueur pourrait alors proposer ses propres monstres et unités pour tenter de terminer le niveau. Le résultat du combat est calculé localement, seule la preuve zk-snark est envoyée sur chaîne pour valider le résultat. Cela garantit que la méthode pour réussir le niveau n’est pas diffusée publiquement sur la blockchain.
ERC-6551 (comptes liés aux jetons) permettra de transformer ces affrontements PvP en arcades autonomes. Le joueur créant la salle peut déposer une récompense dans un contrat intelligent, tandis que les challengers paient des frais d’entrée fixes, ajoutés au pool de récompenses. Les 10 premiers à terminer le niveau remportent une part du pool.
Nous explorons activement cette idée d’arcade autonome et invitons à toute discussion sur Twitter (@BladeGamesHQ). Dans un prochain article, nous aborderons un exemple de mode PvP dans un jeu de défense tour.
Le jeu que nous présenterons à ETHdenver
Nous présenterons à ETHdenver une démonstration d’un jeu vérifiable. Ce jeu sera développé en Rust et React, fonctionnant sur zkwasm. Contactez-nous sur Twitter, et nous vous ajouterons à la liste des testeurs précoces !
Conclusion et prochains contenus
- L’approche du coprocesseur ZK fournit les hypothèses de confiance nécessaires ainsi que la puissance de calcul requise pour créer des expériences de jeu captivantes.
- Pour les développeurs expérimentés, une solution native Unity/Unreal est (très) nécessaire, plutôt que de devoir synchroniser la logique centrale en Solidity/Cairo avec l’animation et le rendu dans Unity.
- L’expérience future des développeurs de jeux sur chaîne et de jeux vérifiables sera hautement modulaire et interchangeable (jusqu’où aller sur chaîne ? Nous pensons que cela devrait être décidé par les développeurs et les utilisateurs).
- À l’avenir, nous croyons qu’il existera des méthodes flexibles pour équilibrer hypothèses de confiance, coût des preuves et coût de développement afin de créer des jeux vérifiables.
Notre solution Zinity offre une prise en main fluide pour les développeurs web2 et web3 souhaitant créer des jeux vérifiables. Nous pensons que cette approche « plug-and-play », compatible avec divers moteurs de jeu, couches DA et zkVM, offrira une grande flexibilité d’expérience de développement.
Nous imaginons une expérience future où Zinity apporte un soutien « élastique » aux jeux prouvables, offrant aux développeurs crypto et web2 des options modulaires pour le développement de jeux vérifiables.
Par exemple, un développeur pourrait écrire la logique centrale en Rust, le reste du jeu en C# avec Unity, et envoyer sur chaîne le commit de la trace d’exécution ou de son hachage, en générant plus tard la preuve ZKP, réduisant ainsi significativement les coûts de développement et de preuve.
Ce modèle élastique permet aussi aux développeurs de tester rapidement leurs idées initiales dans Unity avec C#, puis d’itérer librement sur le degré de décentralisation souhaité (« jusqu’où aller sur chaîne ? »). Ils peuvent ainsi tester en amont les compromis entre design du jeu et performance blockchain.
En développant nos propres jeux et en testant diverses technologies, nous avons réalisé que nous avions besoin de développeurs web2 expérimentés pour créer des jeux vérifiables, afin d’améliorer le flux de jeu et l’expérience UI/UX. C’est pourquoi nous proposons cette solution innovante, dans l’espoir de contribuer à la communauté élargie des développeurs de jeux sur chaîne.
Nous avons déjà rédigé de nombreux contenus sur l’utilisation de zkwasm et le développement de jeux vérifiables, et continuons nos travaux. Voici quelques sujets en cours :
- Adaptation de zkwasm pour les jeux vérifiables (en cours)
- Estimation des coûts DA et des coûts de preuve (terminé)
- Modding, interopérabilité et interactions sans permission sur chaîne pour les jeux vérifiables (en cours)
- Réflexions sur la conception de jeux vérifiables (en cours)
Si vous êtes intéressé(e) par le développement de jeux vérifiables, par la discussion sur l’application des zkVM dans les jeux, ou par une collaboration avec nous, contactez-nous !
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
Blade Research
