L'équipe Lattice a récemment annoncé Redstone - leur nouvelle L2 construite en utilisant leur nouvelle contribution à OP Stack (la pile qui alimente l'Optimism L2).

La question que tout le monde se pose est donc la suivante : "Les jeux onchain doivent-ils être construits sur cette L2, et comment se situe-t-elle par rapport aux autres solutions ? De nombreuses personnes ont demandé notre avis à l'équipe de Paima Studios, étant donné que nous sommes l'un des principaux constructeurs de jeux onchain avec des jeux en direct sur plusieurs chaînes, et nous ferons donc de notre mieux pour plonger dans les nuances.

NOTE

À l'heure où nous écrivons ces lignes, Redstone n'a été annoncé que récemment. Web3 est un espace qui évolue très rapidement, et nous vous encourageons donc à lire cet article de blog avec un esprit ouvert à Redstone au fur et à mesure qu'ils annoncent inévitablement plus sur leur travail.

Pour comprendre Redstone et sa raison d'être, vous devez d'abord comprendre comment il se compare aux autres solutions activement utilisées sur le marché, ainsi que leurs avantages et inconvénients. Notamment, dans ce billet, nous nous attacherons à vous donner le bon modèle mental afin que vous puissiez comprendre ce que propose Redstone, quelle que soit l'annonce suivante.

Là où tout​a commencé​

Vous voulez donc créer un jeu sur la chaîne de valeur ? Étant donné que Redstone est une L2 Ethereum, nous supposerons que vous avez déjà décidé de tirer parti d'Ethereum.

Pourquoi ne pouvez-vous pas déployer votre jeu sur Ethereum directement ? Vous savez peut-être que c'est parce qu'il coûte trop cher (plus de > 1 $ par coup de jeu au moment de la rédaction), mais savez-vous pourquoi il coûte trop cher ? Il s'avère qu'il y a deux coûts principaux : le coût d'exécution et le coût de stockage des données, qui sont tous deux prohibitifs pour un jeu. Cependant, tout comme les unités centrales sont plus chères que les disques durs, les coûts d'exécution sont nettement plus élevés que les coûts de stockage. Et si nous pouvions trouver un moyen de convertir le coût d'exécution en coût de stockage ? Bonne nouvelle : c'est exactement ce que font les rollups.

Les rollups en tant que​solution de​mise à l'échelle

Les rollups se présentent sous de nombreuses formes, chacune convertissant à sa manière les coûts d'exécution en coûts de stockage :

1. Les rollups optimistes : exécutez le calcul hors chaîne, puis stockez toutes les données nécessaires à l'exécution de la fonction (juste les données, pas d'exécution) avec votre valeur calculée localement pour le résultat. Ne procédez à l'exécution que si quelqu'un pense que le résultat que vous avez affiché est incorrect ("preuve de fraude"). \
   Exemples populaires : Arbitrage, Optimisme
2. ZK rollups : exécutez le calcul hors chaîne, puis stockez toutes les données nécessaires à l'exécution de la fonction (juste les données, pas d'exécution) avec votre preuve ZK du résultat calculée localement. \
   Exemples populaires : ZK Sync, Starknet, Polygon zkEVM
3. Rollup souverain : exécutez le calcul hors chaîne, puis stockez toutes les données nécessaires à l'exécution de la fonction (seulement les données, pas d'exécution). \
   Exemples populaires : Rollkit, Paima Engine

Grâce à ces solutions, le coût d'une transaction pour votre jeu est ramené à environ 0,05 $ (voir l2fees pour des valeurs actualisées), ce qui constitue un grand pas dans la bonne direction.

Réduire le coût des​L2​

Il est clair que la réduction des coûts de ces L2 est essentielle au succès des jeux. Bien que les rollups soient de moins en moins chers (les ordinateurs s'améliorent, la technologie ZK s'améliore, etc.), le coût principal n'est pas l'exécution du calcul hors chaîne, mais plutôt le coût de l'affichage des données sur la L1.

Pour remédier à ce problème, Ethereum va introduire une nouvelle méthode de stockage des données beaucoup moins coûteuse (appelée EIP4844), dans laquelle les données ne sont stockées que temporairement (en pratique, environ 2 semaines, ce qui laisse suffisamment de temps pour que les preuves de fraude soient publiées et que les données soient répliquées par des nœuds dans le monde entier).

L'EIP4844 présente cependant quelques inconvénients :

• Les données ne sont que temporaires (vous devrez trouver une autre solution de stockage pour les héberger par la suite).
• Les données sont limitées, plafonnant à environ 2 MiB par bloc (partagées entre tous les rollups sur Ethereum).

Comme vous pouvez le constater, bien que des efforts soient faits pour réduire les coûts, ils ne seront pas suffisants pour rendre les jeux onchain réalisables sur la L2, étant donné la croissance continue de l'intérêt pour l'espace blockchain (la vitesse d'adoption est plus rapide que la vitesse de l'innovation technique).

Alternative #1 : Stocker les données sur un serveur centralisé (ou un ensemble de serveurs)

Une solution pour maintenir le coût à un niveau peu élevé consiste à stocker les données dans un serveur centralisé que les gens vous confient, et à ne publier qu'un hachage des données sur la chaîne. Une variante de cette idée consiste à utiliser un groupe de machines exploitées de manière indépendante et regroupées sous la forme d'un multisig. Un tel système est appelé "comité de disponibilité des données" (DAC) et c'est ce qui est utilisé par Arbitrum Nova, Arbitrum Orbit et Polygon CDK.

Ces systèmes sont beaucoup moins chers (0,001 $ / tx pour Arbitrum Nova si vous ne tenez pas compte du marché des frais) en échange d'une plus grande centralisation du réseau. Le principal risque est que si le CED cesse d'héberger les données (par exemple, s'il publie un hachage et ne partage plus les données relatives à ce hachage), le réseau s'arrête.

Une note spéciale sur​Arbitrum​

Vous vous demandez peut-être pourquoi Arbitrum apparaît deux fois sur la liste. Arbitrum propose actuellement 3 offres principales :

• Arbitrum One (le réseau principal d'Arbitrum qui est un rollup complet avec des données sur Ethereum)
• Arbitrum Nova (une L2 qui utilise un DAC)
• Arbitrum Orbit (une pile pour créer des L3 pour Arbitrum One)

Comme vous pouvez le voir, le problème avec Nova est qu'il n'y a pas de bon moyen d'exploiter le DeFi pour votre jeu (les utilisateurs devraient aller à (Nova -> ETH L1 -> One) et dépenser beaucoup de gaz juste pour faire le pont), alors que la nouvelle pile Orbit vous permet d'aller facilement à (Orbit -> One). De plus, comme Orbit est une pile pour créer des L3, vous pouvez utiliser un L3 existant comme Xai Games qui alimente son propre DAC, ou créer votre propre L3 (bien que si vous avez un L3 spécifique à un jeu dont la seule connexion à Ethereum est de poster occasionnellement des hashs, vous pourriez sans doute être mieux loti avec web2.5).

Alternative #2 : Stocker les données dans un autre​réseau​décentralisé

Au lieu d'attendre que l'EIP4844 soit mis en œuvre avec une bande passante limitée dans le réseau principal, d'autres projets comme Celestia, Avail et EigenDA ont décidé de mettre en œuvre un concept similaire dans une chaîne séparée (appelée couche de disponibilité des données ("DA")), et en se concentrant uniquement sur ce cas d'utilisation, ils offrent des limites de données plus élevées que celles que le réseau principal d'Ethereum prévoit de prendre en charge également. Ces plateformes ne prennent pas en charge les contrats intelligents et sont plutôt destinées à être purement utilisées comme couche de données pour les L2.

Notamment, il est possible de créer une pile OP avec des données sur Celestia ainsi qu'une orbite Arbitrum avec des données sur Celestia. Cela s'accompagne de certains compromis :

1. La confiance. Votre rollup dépend maintenant de la couche DA pour la sécurité au-dessus d'Ethereum (mais sans doute mieux qu'un DAC).
2. Coût. Votre rollup doit maintenant payer le réseau DA pour sa sécurité (que vous devez payer en jetons natifs de la couche DA).
3. La vitesse. Les temps de blocage de Celestia sont de 15 secondes et ceux d'Avail de 20 secondes. Par exemple, les données doivent s'installer dans Celestia avant de pouvoir être transférées dans EVM avec le contrat blobstream de Celestia. Prenez ce point avec un grain de sel cependant, car toutes les L2 émulent généralement des temps de bloc plus rapides que ce qu'Ethereum peut réellement fournir (étant donné que les temps de bloc d'Ethereum ne sont que de 15 secondes malgré le fait qu'Arbitrum utilise un temps de bloc plus rapide que cela).

Ce type de configuration est notamment utilisé par Mantle (OP Stack + EigenLayer DA) et Manta Pacific (OP Stack + Celestia). Le coût de ces derniers reste à déterminer, mais l'équipe de Celestia annonce environ 0,001 $, ce qui signifie que le coût du stockage sur une couche DA (par rapport au coût d'exécution d'un marché de frais du côté EVM) est minime.

Alternative #3 : Stocker les données dans un CAD qui peut être​contesté​

Enfin, nous pouvons parler de l'offre de Redstone. Si vous n'aimez pas les compromis liés au stockage des données sur une couche DA, mais que vous n'aimez pas la centralisation d'un CED, vous pouvez construire un CED dans lequel vous pouvez punir financièrement le comité s'il ne met pas les données à disposition.

Pour mieux comprendre ce que cela signifie, examinons le fonctionnement du protocole DAC :

Comment écrire des​données​

1. Sequencer for Redstone reçoit votre transaction
2. Le séquenceur envoie les données au CNA pour qu'elles soient stockées.
3. Le CED renvoie un accusé de réception indiquant que les données sont stockées.
4. Le séquenceur envoie le hachage des données au serveur L1.

Comment lire les​données​

1. Synchroniser une chaîne Ethereum à la recherche des hachages qui ont été soumis au contrat de rollup.
2. Interroger les données du hachage à partir du DAC
3. Calculer l'état de la L2 sur la base de ces données

Quels sont donc les​changements apportés​par Redstone ?

Lorsque vous lisez des données, si elles ne sont pas disponibles, vous pouvez contester le CED en affirmant qu'il n'a pas mis les données à disposition (c'est-à-dire que les données ne peuvent pas être téléchargées à partir de son serveur).

Pour inciter tout le monde à être honnête, nous avons mis en place les règles suivantes :

1. Si un contestataire est malhonnête (les données étaient réellement disponibles), il est éliminé (sinon, vous pourriez attaquer financièrement le réseau en contestant chaque bloc).
2. Si le DCA est malhonnête (les données ne sont pas disponibles), ils sont réduits.

Cette solution semble simple, mais la difficulté consiste à déterminer qui est responsable en cas de problème. Imaginez le scénario suivant :

1. Le séquenceur publie un hachage sans partager les données réelles.
2. Quelqu'un défie le séquenceur
3. Le séquenceur, conscient du défi, met les données à disposition.

Si vous êtes un observateur extérieur qui n'a pas suivi la chaîne en temps réel, les données semblent disponibles (si vous interrogez le CED après coup, vous obtenez les données comme prévu), ce qui donne l'impression que le challenger a menti, même si ce n'est pas le cas.

Si votre solution à ce problème est de supposer que le séquenceur ne mentira jamais pour un simple jeu, alors pourquoi ne pas utiliser un DAC standard à la place. En outre, le fait de supposer que le séquenceur est honnête n'est pas compatible avec le concept de "superchaîne" de séquenceur partagé, ce qui signifie que les actifs ne peuvent pas utiliser le séquenceur partagé pour être transférés entre les chaînes OP Stack (vous rencontrez donc le même problème qu'Arbitrum Nova, à moins que Redstone ne soit déployé en tant que L3).

La façon dont l'équipe de Lattice prévoit de gérer cette situation sera le point clé à surveiller au fur et à mesure que la documentation et les informations de la feuille de route seront mises à disposition.

Alternative n°4 : Utiliser​ZK​

Notez que le problème de non partage des données (attaques par rétention de données) qui affecte Redstone n'est pas exclusif aux rollups optimistes. Les rollups ZK dont les données sont stockées hors chaîne (appelés "Validiums") souffrent du même problème, c'est pourquoi les gens sont généralement plus intéressés par les rollups (qui postent toutes les données sur une chaîne).

Par conséquent, les rollups ZK, en général, ne vous aideront pas à réduire le coût des données de votre jeu en toute sécurité. Ils peuvent certainement aider à faire évoluer votre jeu de bien d'autres façons (déplacer plus de calculs vers la machine locale de l'utilisateur, utiliser des preuves récursives pour regrouper de nombreuses interactions, soit dans le style rollup, soit dans le style canal d'état, etc.

Comment puis-je réduire les coûts de mon jeu si Solidity est le problème?

Tout au long de ce billet, nous avons parlé de la manière de gérer les coûts de stockage. Cependant, certains jeux peuvent être limités par le CPU (même s'ils fonctionnent dans une chaîne EVM centralisée). Si c'est votre cas, vous pourriez être intéressé par l'utilisation d'un rollup souverain pour vous permettre de faire évoluer votre jeu au-delà des limites de l'EVM en utilisant Paima Engine.

Paima Engine permet de créer des machines d'état spécifiques à une application en Javascript que vous pouvez déployer sur n'importe quelle chaîne EVM de votre choix (y compris Redstone !). Ces rollups souverains peuvent accéder aux informations de l'EVM (y compris les données du moteur du MUD) et peuvent donc constituer un excellent moyen de faire fonctionner n'importe quelle partie de votre jeu beaucoup plus rapidement et à moindre coût.

​Conclusion​

En conclusion, la réduction du coût des données est l'étape la plus cruciale pour réduire les coûts des jeux en chaîne. Il existe aujourd'hui de nombreuses solutions différentes avec différents compromis, et Redstone se présente comme plus sûr que le DAC standard, mais il reste à voir s'il est significativement plus sûr, et si la différence est suffisamment importante pour constituer une alternative viable aux solutions soutenues par la couche DA. Pour les projets qui ont besoin de faire évoluer les calculs au-dessus des données, des solutions comme Paima Engine existent pour résoudre le problème.

Enfin, n'oubliez pas que les détails de Redstone n'ont pas encore été annoncés. Cet article de blog devrait vous donner le bon modèle mental pour comprendre leurs futures annonces, alors gardons l'esprit ouvert et voyons ce qu'ils proposent à l'avenir.

​Studios​Paima

Paima Studios, fondé en avril 2022, est le noyau des développeurs du Paima Engine : un moteur Web3 construit à l'aide d'une nouvelle technologie de couche 2 qui permet de construire des jeux onchain, de la gamification et des mondes autonomes. Paima Engine est un moyen sûr et facile d'entrer dans le Web3 car il peut être utilisé avec des compétences Web2 et n'expose pas les utilisateurs ou les développeurs aux risques et aux piratages courants du Web3.

• Base de code du moteur Paima : https://github.com/PaimaStudios/paima-engine
• Documentation Paima : https://docs.paimastudios.com/
• Modèle Paima : https://github.com/PaimaStudios/paima-game-templates
• Paima NPM package : <a href="https://www.npmjs.com/package/@paima/sdk"" > https://www.npmjs.com/package/@paima/sdk

Vous pouvez également en savoir plus sur nos médias sociaux :

• Youtube : <a href="https://www.youtube.com/@paimastudios"" > https://www.youtube.com/@paimastudios
• Discord : http://discord.gg/jZ59ArVaxv
• Reddit : https://reddit.com/r/paima
• Twitter : https://twitter.com/PaimaStudios

Vous souhaitez collaborer ? N'hésitez pas à nous contacter via notre page de contact : https://paimastudios.com/contact/

Clause de non-responsabilité：

1. Cet article est repris de[blog.paimastudios]. Tous les droits d'auteur appartiennent à l'auteur original[paimastudios]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.