Associé de Volt Capital : Pourquoi les canaux d'état ZK sont-ils la meilleure solution de montée en charge pour les jeux multijoueurs sur chaîne ?
TechFlow SélectionTechFlow Sélection
Associé de Volt Capital : Pourquoi les canaux d'état ZK sont-ils la meilleure solution de montée en charge pour les jeux multijoueurs sur chaîne ?
Pour les jeux multijoueurs, les canaux d'état zk sont une meilleure option de mise à l'échelle.
Dédié à des analyses Web3 approfondiesRédaction : Mohamed Fouda
Traduction : TechFlow
Pour les jeux sur chaîne, le scaling horizontal via Rollup convient bien aux jeux individuels. Mais pour les jeux multijoueurs, les canaux d'état basés sur zk sont une meilleure option de mise à l'échelle. Alors, qu'est-ce qu'un canal d'état zk ?
Les canaux d'état ne sont pas une nouveauté. En réalité, ils font partie des premières solutions de scaling proposées pour Ethereum. Un canal d'état consiste essentiellement à :
-
extraire une portion de l'état sur chaîne ;
-
modifier continuellement cet état en dehors de la chaîne ;
-
soumettre l'état final à la chaîne lorsque nécessaire.
Ce concept s'inspire clairement du réseau Lightning de Bitcoin, qui est fondamentalement un canal de paiement.
Cependant, sans preuves à connaissance nulle (zero-knowledge proofs), les canaux d'état perdent tout leur intérêt. Sans zk, toutes les signatures autorisant les modifications d'état (hors chaîne) devraient ensuite être vérifiées sur chaîne, ce qui n'apporte pas de réduction significative des frais par rapport aux transactions classiques sur chaîne.
Les preuves à connaissance nulle résolvent facilement ce problème. Les participants au canal génèrent simplement une preuve hors chaîne attestant que toutes leurs interactions et signatures sont valides. Cette preuve peut être vérifiée très économiquement sur chaîne, entraînant une forte réduction des coûts.
Mais quel est le lien avec le scaling des jeux multijoueurs sur chaîne ?
De nombreux jeux multijoueurs, comme le poker, sont basés sur des parties : un groupe de joueurs crée une partie, y compétit, et leurs actifs respectifs sont modifiés selon le résultat final.
Pour ce type de jeu, vous avez besoin d'une couche partagée pour stocker les actifs de chaque joueur.
Les détails intermédiaires du jeu sont moins importants que le résultat final (la modification des soldes). De plus, un joueur ne peut pas participer simultanément à plusieurs parties.
Ces caractéristiques rendent ces jeux idéaux pour les canaux d'état zk. Dès le début d'une partie, l'état des joueurs participants est verrouillé sur un Rollup. Pendant la partie, les joueurs génèrent des ZKP prouvant la validité de leurs actions. Ces ZKP sont construits récursivement à partir des précédents, et ainsi de suite.
À la fin de la partie, seul le ZKP final et les modifications d'état associées sont soumis au Rollup pour règlement. Comme les transactions intermédiaires ne sont pas traitées sur le Rollup, cela permet un facteur de scaling allant jusqu'à 100 fois.
Cette approche fonctionne aussi pour les jeux non tour par tour, comme « Among Us ». Dans ce cas, il faut cependant une entité qui agit comme un ordonnanceur « temporaire », chargé de séquencer les transactions du canal et de générer les ZKP intermédiaires récursifs. J'appelle ce scénario un « L3 éphémère ».
Le principal défi de cette méthode repose sur la nécessité d'activité des participants au canal. Un joueur déconnecté pourrait forcer les autres à poursuivre l'exécution sur le Rollup, ce qui obligerait les autres joueurs à supporter des coûts supplémentaires.
Malgré cela, le potentiel de cette approche est immense, et de nombreuses équipes travaillent déjà dans cette direction, notamment Ontropy, Paima Studios et Cartridge.
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
@MohamedFFouda
