Les preuves à connaissance nulle peuvent-elles améliorer l'expérience utilisateur en réduisant le nombre d'interactions entre les jeux entièrement sur chaîne et la blockchain ?
TechFlow SélectionTechFlow Sélection
Les preuves à connaissance nulle peuvent-elles améliorer l'expérience utilisateur en réduisant le nombre d'interactions entre les jeux entièrement sur chaîne et la blockchain ?
Quels usages les preuves à connaissance nulle (ZKP) ont-elles dans le domaine du jeu ?
Dédié à des analyses Web3 approfondiesRédaction : Yooma
Source de l'image : https://unsplash.com/photos/people-inside-library-1mwPOXb_pB8
Problème rencontré
PopCraft est un jeu d'élimination entièrement sur chaîne, avec chaque partie durant 4 minutes. Les joueurs doivent éliminer tous les éléments du plateau dans le temps imparti et reçoivent alors une récompense en jetons.
En raison de son architecture entièrement décentralisée, chaque action du joueur pendant la partie nécessite une interaction avec la blockchain. Le temps de bloc sur les solutions Layer 2 d’Ethereum étant généralement de 2 secondes, chaque opération du joueur prend au minimum 2 secondes pour être confirmée, ce qui dépasse largement les délais de réponse des jeux Web2 similaires, entraînant ainsi une expérience utilisateur médiocre dans PopCraft.
Interface principale du jeu PopCraft
Solution envisagée
Nous avons imaginé intégrer la technologie des preuves à connaissance nulle (ZKP) dans PopCraft afin de réduire le nombre d'interactions entre le joueur et la blockchain pendant la partie.
L'idée serait la suivante : le déroulement du jeu ne serait pas enregistré sur chaîne, mais un mécanisme garantirait l'absence de tricherie. Chaque action du joueur générerait une ZKP, et la preuve de l'action suivante serait basée sur celle précédente, formant ainsi une structure auto-contenue similaire à une chaîne de blocs. À la fin de la partie, seule la dernière ZKP serait envoyée sur la blockchain pour que le contrat intelligent valide le résultat final.
Étude et raisonnement autour de la solution
1. Prévention de la triche dans le déroulement et le résultat du jeu : Générer une ZKP uniquement pour le résultat final ne suffit pas, car il reste un risque de tricher pendant le déroulement du jeu. Il est donc nécessaire non seulement de produire une ZKP pour le résultat, mais aussi de vérifier chaque étape du processus de jeu.
2. Défis techniques liés à la génération progressive des ZKP : Pour éviter toute tricherie, chaque action du joueur devrait générer une ZKP, et seule la dernière preuve serait soumise à la chaîne à la fin. Dans ce scénario, chaque nouvelle ZKP dépendrait de la précédente, jusqu’à la fin de la partie.
Cependant, deux difficultés majeures se posent :
1> La génération d'une nouvelle ZKP dépend de la précédente, ce qui complique considérablement le processus de vérification, sans même garantir sa faisabilité. De plus, comme la vérification des ZKP s’effectue via un contrat intelligent (on-chain), comment peut-on s'assurer, lors de la génération d'une nouvelle preuve, que la preuve précédente a bien été validée ?
2> Lors de la vérification de chaque ZKP par le contrat intelligent, comment assurer la continuité entre chaque preuve et sa prédécesseure ? Il n’existe actuellement aucune solution claire pour garantir cette cohérence séquentielle.
3. Problème lié à la visibilité des données du jeu : Les données de PopCraft sont publiques par nature. Utiliser des ZKP pour masquer ces informations devient alors inutile. Même si les étapes de vérification ci-dessus pouvaient être réalisées, il faudrait ensuite stocker les données du jeu côté contrat. Cependant, les ZKP ne permettent pas de récupérer les données exactes du jeu, et on ne peut pas non plus faire confiance aveuglément aux données transmises par le client au contrat intelligent. Cela signifie que le contrat intelligent ne peut pas directement stocker ou utiliser ces données.
4. Problème lié à la consommation d'objets de jeu (consommation de jetons) : Dans PopCraft, certains objets permettent d’éliminer des éléments isolés, ce qui correspond concrètement à une dépense de jetons transférés depuis le portefeuille du joueur. Intégrer cette étape dans le processus de génération et de vérification des ZKP soulève également des difficultés.
1> Une solution possible serait : Continuer à générer les ZKP selon le flux précédent, vérifier la quantité de jetons dépensés, puis envoyer le tout au contrat intelligent. Mais comme le contrat ne peut pas extraire les données précises du jeu à partir de la ZKP, il ne peut pas déterminer combien de jetons doivent être transférés.
De plus, supposons qu’un joueur possédant 3 jetons A tente d’en dépenser 4 pendant la partie. Cette erreur ne serait détectée qu’à la fin du jeu, et non immédiatement lors de l’action, ce qui nuit gravement à l’intégrité du système.
2> Une autre approche possible serait : Lorsqu’un objet est utilisé pour éliminer un élément isolé, interagir directement avec le contrat intelligent pour effectuer l’élimination et mettre à jour le solde de jetons du joueur. La ZKP générée servirait alors uniquement à prouver l’état du jeu à cet instant précis.
Mais dans ce cas, après le transfert réussi des jetons, il faudrait continuer à générer une nouvelle ZKP comme pour les autres actions. Si on ne le fait pas, alors entre la ZKP générée avant l’interaction avec le contrat et celle générée après, une étape supplémentaire hors-ZKP a eu lieu, ce qui rompt la continuité de l’état du jeu. On ne sait donc pas si la ZKP finale resterait valide.
5. Problème du masquage des données par ZKP : Dans un jeu comme PopCraft où les données n’ont pas besoin d’être cachées, utiliser les ZKP pour masquer l’information est superflu. Cela ajoute inutilement de la complexité à la récupération des données et augmente l’incertitude dans la mise en œuvre technique. PopCraft a seulement besoin de garantir l’absence de tricherie dans le déroulement et le résultat du jeu, pas de dissimuler les données du jeu lui-même.
Conclusion
Dans un jeu comme PopCraft, où les données de jeu sont publiques, l’utilisation de ZKP pour masquer l’information est inutile. Pour améliorer l’expérience utilisateur en réduisant les temps de réponse, on pourrait envisager de ne pas enregistrer le déroulement du jeu sur chaîne, mais uniquement d’y soumettre le résultat final. L’enjeu principal est donc de trouver une méthode permettant de garantir qu’aucune tricherie n’a eu lieu du début à la fin du jeu, pour ensuite valider correctement le résultat final sur chaîne.
Utiliser les ZKP pour masquer des données rendrait en réalité la mise en œuvre technique plus complexe. Par ailleurs, garantir l’absence de tricherie pendant tout le processus de jeu reste un défi. Bien que les ZKP puissent assurer l’intégrité d’une action individuelle, elles ne peuvent pas être soumises à chaque étape (car cela impliquerait trop d’interactions avec la blockchain). Or, assurer une traçabilité fiable et continue de la première à la dernière action du jeu reste aujourd’hui un problème non résolu par les ZKP.
Selon notre analyse, les ZKP trouvent leur utilité dans deux types de jeux :
-
Les jeux de type « information incomplète », où le masquage d’information est nécessaire : par exemple Dark Forest, le poker Texas Hold’em, Loup-Garou, Hearthstone, etc.
-
Les jeux dont le résultat repose sur une seule action, comme les loteries, les jeux de devinettes, pierre-feuille-ciseaux, ou les jeux de dés.
Nos connaissances actuelles en matière de preuves à connaissance nulle étant limitées, cet article peut contenir des erreurs factuelles ou des hypothèses techniques irréalistes. Nous invitons sincèrement les experts expérimentés du domaine à nous faire part de leurs remarques et corrections.
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
