Deep Dive into Bat-Channels : New Technology Unlocking Scalability for On-Chain Games
TechFlow SélectionTechFlow Sélection
Deep Dive into Bat-Channels : New Technology Unlocking Scalability for On-Chain Games
Pour un jeu Web3, la blockchain principale est l'endroit où ont lieu les transactions commerciales, les statistiques des personnages et la réputation, tandis que le cycle de jeu principal existe en dehors de la blockchain principale.
Dédié à des analyses Web3 approfondiesRédaction : Will Robinson
Traduction : TechFlow
Dans cet article, je propose un modèle de conception de jeu permettant d’augmenter l’échelle des jeux Web3 en déplaçant le traitement du cycle de jeu hors chaîne, selon une approche sans autorisation et sans confiance. Cela implique d’ancler la logique du jeu dans un circuit zk sur la blockchain. J’appelle ce modèle de conception « Bat-Channel ».
Grâce aux Bat-Channels, nous pouvons atteindre une population durable de joueurs importants en amplifiant le nombre de changements d’état concurrents. Le principal compromis réside dans l’isolement des joueurs compétitifs. Les jeux multijoueurs massifs où des milliers de personnes interagissent simultanément avec l’état du jeu seront impossibles. À la place, la limite théorique se rapprocherait plutôt de 30 participants, favorisant les modes solo et coopératif. Pour justifier ce compromis, je présente une conception de jeu captivante qui exploite la scalabilité des Bat-Channels tout en profitant des avantages liés à l’exécution sur blockchain. Les prochains articles incluront une exploration technique plus approfondie de cette conception.
En 2021, Galcon a été porté sur blockchain et publié sous le nom de Dark Forest. Pendant un an, des centaines de joueurs ont rivalisé sur plusieurs cartes durant environ une semaine chacune. Grâce à la facilité de conception open source des jeux blockchain, les joueurs ont développé par-dessus des interfaces, scripts et contrats intelligents. De nombreux chercheurs et ingénieurs Solidity parmi les meilleurs ont testé et exploré cette nouvelle forme de jeu pour se challenger. Ils ont créé des marchés communautaires où les joueurs échangeaient des ressources, voire des informations, afin d’atteindre leurs objectifs en jeu. D’autres jeux similaires sont apparus au même moment, comme Conquest.eth et Mithraeum.io. Dans ces jeux, tous les joueurs rivalisaient simultanément sur la même carte.
Malheureusement, ces jeux étaient limités par le débit de la blockchain sur laquelle ils reposaient. Par exemple, Dark Forest fonctionnait sur Gnosis Chain, qui n’autorise que 30 transactions par seconde modifiant l’état du jeu.
Pourtant, même dans un jeu utilisant un quart de bloc, où les joueurs bougent prudemment toutes les trois minutes, on ne peut avoir au maximum que 1440 joueurs simultanés (180 secondes/action × 8 actions × 1 joueur par seconde). Les développeurs doivent alors croire soit que la valeur moyenne par joueur sur toute sa durée de vie est 100 fois supérieure à celle d’un utilisateur Web2, soit considérer ce chiffre comme inacceptable — car aujourd’hui, les jeux Web2 réussis comptent plus de 100 000 joueurs simultanés. Même si nous pouvons espérer un gain de facteur 10 dans les années à venir, il nous faudrait un facteur 1000 pour soutenir certains jeux à succès.
Évolutivité via les Bat-Channels
La solution d’évolutivité la plus simple serait peut-être de créer davantage de sidechains, comme Gnosis ou Polygon PoS.
Mais les sidechains n’héritent pas de la sécurité de la chaîne sur laquelle elles s’appuient. Elles reposent généralement sur leur propre ensemble de validateurs, qui misent des actifs pour garantir un comportement honnête et reçoivent en retour des récompenses par bloc. On les appelle sidechains car elles réutilisent souvent la même machine virtuelle, maintiennent un pont entre chaînes, et publient des instantanés de leur état sur la chaîne principale (pour permettre une récupération d’urgence via coordination sociale). S’il existait 1000 telles sidechains, on pourrait accueillir suffisamment de joueurs. Mais cela pose problème en termes de fragmentation des joueurs, de fragmentation de liquidité, de sécurité des ponts et de dilution de la sécurité globale.
Pour mieux correspondre aux hypothèses de sécurité des blockchains principales, de nombreux développeurs choisissent plutôt les Optimistic Rollups et zkRollups. Ces solutions offrent une évolutivité similaire aux sidechains, mais doivent publier chaque transaction sur leur L1. Or, l’espace dans les blocs d’Ethereum n’est pas suffisant pour accueillir 1000 rollups de jeux supplémentaires ainsi que le reste de l’écosystème.
Une troisième option d’évolutivité repose sur les canaux d’état. Le réseau Lightning est une implémentation populaire sur Bitcoin, servant de canal de paiement entre deux parties. Chaque participant verrouille des fonds dans un contrat intelligent, puis échange hors chaîne des messages mettant à jour leur solde respectif.
Par exemple, Alice et Bob verrouillent chacun 0,1 BTC. Toutes les minutes, Alice envoie à Bob un message signé transférant 0,00001 BTC. Parfois, Bob paie aussi Alice en retour. Un an plus tard, le solde final d’Alice est de 0,05 BTC et celui de Bob de 0,15 BTC. Alice quitte alors le canal et publie le dernier état sur la chaîne. Bob dispose d’une fenêtre temporelle pour contester avec un état plus récent, après quoi le contrat libère les fonds à Alice et Bob.
Les canaux d’état (comme Lightning) permettent un volume de transactions bien supérieur, car les états intermédiaires n’ont pas besoin d’être publiés sur chaîne. Pour un jeu à deux joueurs, un canal d’état pourrait être approprié. Quel est le compromis ? Il réduit fortement le nombre total de joueurs pouvant interagir simultanément. Il faut aussi permettre aux joueurs de contester les tricheries ou absences de réponse. J’aborderai ces problèmes dans des articles futurs ; cependant, par souci de concision, cet article se concentre sur une construction coopérative. Dans ce mode, tous les joueurs collaborent, et le jeu est à somme positive.
Preuve de jeu (Proof of Game)
Pour empêcher les comportements frauduleux, le jeu lui-même doit être programmé de manière vérifiable. Les solutions actuelles peuvent inclure Cairo et Cairo VM, ou Solidity combiné à divers zkEVM. On peut construire une structure semblable à un zkRollup, sans séquenceur tiers. Puisque les joueurs ne craignent pas que l’ordre de leurs actions soit manipulé (car ils sont amis, et personne d’autre n’est présent dans le rollup), ils peuvent eux-mêmes convenir de l’ordre. Cette méthode est évolutive, car elle permet un nombre arbitraire d’actions tout en ne nécessitant qu’une seule preuve et une seule différence d’état publiées sur chaîne.
Conception du jeu
Avec l’architecture bat-channel (état blockchain partagé et sessions de jeu parallélisées), examinons quels types de jeux conviennent le mieux à une migration. J’ai choisi le MMORPG World of Warcraft comme cas typique. Bien que la plupart perçoivent WoW comme un jeu compétitif à état partagé, je pense qu’il s’agit surtout d’une expérience coopérative en petits groupes. Du point de vue de la théorie des jeux et des hypothèses de sécurité, c’est un jeu solo. Alors que des millions de joueurs sont connectés simultanément à WoW, ils sont répartis sur des centaines de serveurs. Ces derniers sont divisés en dizaines de régions, elles-mêmes fragmentées en centaines de donjons appelés « instances ». C’est pourquoi des millions de joueurs peuvent combattre le même monstre indépendamment. Deux groupes différents peuvent entrer dans la même grotte sans jamais se croiser. Le métavers plus large, incluant les hôtels des ventes, sert aux échanges, réparations d’équipement et progression des personnages.
Pour un jeu Web3, je recommande d’adopter une architecture similaire comme objectif principal de conception. Autrement dit, la chaîne principale est l’endroit dédié aux transactions commerciales, aux statistiques des personnages et à la réputation, tandis que le cycle principal du jeu existe en dehors de la chaîne.
Les joueurs peuvent lancer leurs propres instances, y amener leurs personnages et équipements, puis en sortir de façon vérifiable en obtenant plus d’équipement et d’expérience. Bien que cela réduise la composable, faute de détails de jeu disponibles publiquement, cela offre une meilleure confidentialité aux joueurs. Personne ne saura comment vaincre un donjon. Et si vous souhaitez restaurer la composable, vous pouvez attribuer un NFT spécial aux joueurs ayant tué cent rats dans un donjon. Les joueurs peuvent consulter leur historique d’actions et générer une preuve attestant qu’ils ont accompli cette tâche. La disponibilité des données peut être pilotée par les joueurs eux-mêmes, car ils ne prennent aucun risque.
Prochaines étapes
Le projet le plus proche de la mise en œuvre des bat-channels est Dojo. Ce moteur de jeu est conçu pour Cairo VM et permet de prouver qu’un jeu a été correctement exécuté. Actuellement, le système n’a pas encore été utilisé pour créer un jeu dont l’économie réside sur la couche 1, tandis que le cycle de jeu fonctionne dans des bat-channels séparés. L’équipe annonce une démonstration en temps réel pour bientôt.
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
Alliance
