Interprétation de la technologie de cumul Dapp : Comment démocratiser l’APP à haut débit ?

Écrit par Mohamed Fouda

Compilé : DeepTide TechFlow

! [Interprétation de la technologie de cumul Dapp : comment démocratiser l’application à haut débit ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b4e642b2e9-dd1a6f-69ad2a.webp)

L’application Rollup est en train de devenir un gagnant clair dans la mise à l’échelle d’un ensemble spécifique d’applications Ethereum. Ces applications bénéficient de garanties de propriété solides et sans autorisation, mais ne nécessitent pas d’interaction simultanée entre tous les utilisateurs de l’application. Les jeux entièrement on-chain en sont le meilleur exemple. Les jeux on-chain bénéficient d’une forte propriété des actifs du jeu, ce qui permet une participation anonyme au jeu et permet une modification anonyme du jeu. Pourtant, la plupart des jeux n’exigent pas que tous les joueurs interagissent en même temps. Parmi les autres applications qui peuvent bénéficier de la stratégie de mise à l’échelle Rollup de l’application, citons les places de marché NFT, les échanges perpétuels et l’inférence d’IA on-chain.

! [Interprétation de la technologie de cumul Dapp : comment démocratiser l’application à haut débit ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-1dce91a53e-dd1a6f-69ad2a.webp)

Le cumul d’applications est déjà l’implémentation préférée pour bon nombre de ces cas d’utilisation. Toutefois, l’implémentation de cumul standard, EVMRollup, présente encore d’importantes limitations d’évolutivité. Ils peuvent atteindre un débit d’environ 100 transactions par seconde. Ce débit peut être suffisant pour certains jeux on-chain, selon le type de jeu. Cependant, la plupart des jeux nécessitent un débit plus élevé pour prendre en charge un grand nombre de joueurs simultanés (plus de 1000). Cet article se concentre sur la façon dont le cumul d’applications évolue pour atteindre des centaines de milliers de participants simultanés. Pour chaque approche, je discute du type d’application/jeu approprié et des défis auxquels il est confronté.

Mise à l’échelle horizontale

L’évolutivité horizontale est le moyen le plus simple de mettre à l’échelle le cumul de vos applications. Cependant, cette simplicité se fait au détriment de la composabilité, ce qui les rend adaptés à un petit sous-ensemble d’applications, telles que les jeux solo.

L’évolutivité horizontale consiste simplement à déployer plusieurs cumuls d’applications (Optimistic ou ZK) et à déployer le même contrat intelligent sur tous les cumuls. Le front-end de l’application dirige de manière transparente l’utilisateur vers l’un des cumuls en fonction de la capacité, de l’emplacement ou des options d’application spécifiques. Alt Layer a récemment démontré ce concept en lançant un jeu évolutif 2048 FOCG. Au début du jeu, les utilisateurs peuvent choisir le Rollup qu’ils souhaitent rejoindre en fonction de leur emplacement géographique. En raison de sa simplicité et de la disponibilité de fournisseurs de rollup-as-a-service comme Caldera, qui gèrent tout le travail d’infrastructure associé à la rotation et à la gestion de ces rollups, cette approche peut être facilement adoptée par les développeurs de jeux.

! [Interprétation de la technologie de cumul Dapp : comment démocratiser l’application à haut débit ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cf4cf9437a-dd1a6f-69ad2a.webp)

Néanmoins, il existe quelques problèmes avec l’approche d’extension multi-rollup. Le premier problème est le commutateur réseau Rollup. Les portefeuilles actuels, tels que Metamask, nécessitent une approbation manuelle pour se connecter à un nouveau réseau, l’instance Rollup. Cela crée une expérience utilisateur difficile et déroutante pour les joueurs, car les joueurs doivent se connecter manuellement à plusieurs « réseaux » pour jouer au même jeu. Heureusement, cette complexité peut être effacée avec une solution d’abstraction de compte (AA). Les exemples incluent EIP 4337 et les portefeuilles intégrés tels que Privy et 0xPass.

Un autre défi est la gestion de l’état du joueur pendant les transitions entre les cumuls. Dans certains cas, tels que les baisses de capacité, une application peut avoir besoin de consolider plusieurs instances de cumul en une seule instance pour économiser les ressources. Dans ce cas, l’état de tous les joueurs actifs doit être migré vers la nouvelle instance. Les solutions de pontage actuelles, en particulier les ponts ZK, peuvent jouer un rôle clé dans la résolution de ce problème. À l’aide de ces solutions, vous pouvez faire le pont entre l’état de jeu d’un joueur et une nouvelle instance de cumul tout en conservant la preuve de la validité de cet état. Cependant, la latence des solutions de pontage existantes peut ne pas être optimale pour les cas d’utilisation des jeux.

Canal d’état ZK

Une autre extension de cumul d’applications plus adaptée aux jeux multijoueurs, tels que le poker, est le canal d’état ZK. Dans ces jeux, l’interaction entre les joueurs se produit entre un petit nombre de joueurs, par exemple 2 à 10 personnes. Le gameplay entre ces joueurs n’a d’importance que pendant le jeu. Cependant, le résultat final du jeu est plus important car il affecte l’équilibre des actifs de chaque joueur. Par conséquent, il est important de stocker les résultats dans une couche de persistance partagée.

Dans ce cas, le cumul d’application représente une couche d’informations partagées, où les résultats du jeu sont stockés et où les ressources du jeu existent également. Pour chaque jeu sur Rollup, vous pouvez démarrer un canal d’état ZK pour servir le jeu. Pendant le jeu, chaque joueur génère des transactions et crée des ZKP, prouvant ainsi qu’il a respecté les règles du jeu. Les preuves d’interactions avec d’autres joueurs agrègent la preuve précédente à l’aide de preuves récursives. À la fin du jeu, le ZKP final est soumis au Rollup de l’application pour prouver la validité du gameplay et le résultat final. Le changement d’état produit par le jeu modifie l’état du joueur sur le Rollup de l’application.

! [Interprétation de la technologie de cumul Dapp : comment démocratiser l’application à haut débit ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-f3acfe5e4d-dd1a6f-69ad2a.webp)

Le canal d’état ZK déplace les interactions de jeu hors chaîne. Par conséquent, l’activité et les transactions dans le jeu ne sont pas prises en compte dans le débit du cumul d’applications. En utilisant cette approche, l’application Rollup peut évoluer massivement pour prendre en charge des milliers de joueurs simultanés. La transaction pour le cumul d’application ne validera que les transactions ZKP et de mise à jour d’état générées avec un facteur d’échelle de 100 à 1000x. Plusieurs équipes, dont Ontropy, ont développé cette technologie.

L’un des inconvénients de cette approche est qu’elle oblige les joueurs à exécuter la logique du jeu sur leurs propres appareils et à générer des ZKP. Souvent, ces épreuves sont légères et peuvent être réalisées en quelques secondes avec des systèmes d’épreuves de pointe tels que Halo2. Cependant, cela peut toujours entraîner une réduction de l’expérience de jeu pour les appareils aux ressources limitées.

L’un des moyens d’atténuer ce problème est de désigner l’un des participants au canal d’état zk en tant que séquenceur temporaire. Le séquenceur recevra la transaction de chaque joueur et générera le ZKP correspondant, partageant le ZKP avec tous les participants au canal. Cette modification peut être considérée comme un règlement ZK L3 de courte durée pour le correctif cumulatif de l’application. L’équipe Cartridge a implémenté cette architecture en concevant un séquenceur dédié appelé Katana.

L’approche du canal d’État zk a un grand potentiel. Cependant, il existe plusieurs problèmes ouverts liés à l’environnement d’exécution dans le canal d’état zk et à la façon d’optimiser la preuve récursive. Les environnements zkEVM actuels ne sont pas efficaces et la plupart ne prennent actuellement pas en charge la récursivité de preuve. Les alternatives incluent zkVM léger, ou même utilisent des circuits zk spécialisés pour gérer l’interaction du joueur si le joueur a un nombre limité de mouvements possibles.

Changer l’environnement d’exécution

Une troisième façon d’étendre le cumul d’application consiste à modifier l’environnement d’exécution du correctif cumulatif. Malgré leur maturité et l’abondance d’outils de développement EVM, ils ne sont pas adaptés aux applications hautes performances telles que les jeux. En outre, le modèle d’exécution et de stockage monothread de l’EVM entraîne une réduction du débit, qui peut être améliorée par des améliorations.

Le principal avantage de cette approche est que l’augmentation du débit de cumul ne nécessite pas de sacrifier la composabilité ou de limiter le nombre de cas d’utilisation. Cette approche peut être utilisée pour n’importe quelle application Web 3 tant que l’environnement d’exécution peut atteindre le débit requis par l’application. Cela en fait la seule solution viable pour les applications qui ont besoin d’accéder à l’état partagé, telles que les AMM, les protocoles de prêt et d’autres applications DeFi.

Extension de la fonctionnalité EVM avec la précompilation

Tout d’abord, le cumul maintient la conformité EVM et impose certaines limites sur le débit d’adresses précompilées. L’idée ici est simple. La précompilation est le mouvement descendant des opérations EVM à forte intensité de calcul vers le niveau du nœud. Une opération qui nécessite des centaines ou des milliers d’opcodes EVM et consomme 100 000+ gaz peut être simplifiée en une seule opération avec une réduction de 100 fois des coûts de gaz. La précompilation qui étend l’environnement de cumul est souvent appelée EVM+. Des exemples de cette approche incluent la prise en charge de la confidentialité on-chain et la prise en charge de systèmes de signature plus efficaces tels que les signatures BLS. Par exemple, zkHoldem poker utilise des opérations FHE et zk dédiées pour permettre la distribution et la présentation de cartes privées. Le développement de ces précompilations spécialisées est généralement le fruit d’un effort conjoint entre le développeur de cumul d’applications et le fournisseur RaaS qui gère le déploiement et la maintenance de l’infrastructure de cumul d’applications.

Utilisation d’un environnement d’exécution non-EVM

Une autre façon d’améliorer l’environnement d’exécution du cumul consiste à se débarrasser de l’EVM. Cette approche gagne en popularité parmi les nouveaux développeurs de l’écosystème Ethereum, ainsi que parmi les développeurs qui pensent que Solidity n’est pas le meilleur langage pour développer des applications complexes.

Aujourd’hui, nous avons des applications Rollup qui s’exécutent sur des environnements d’exécution WASM, SVM, Cairo et même Linux. La plupart de ces méthodes permettent aux développeurs d’écrire des contrats intelligents à l’aide de langages de haut niveau tels que Rust ou C. L’inconvénient est que l’interopérabilité avec les contrats Solidity existants est souvent perdue. Cependant, la compatibilité avec EVM peut toujours être créée. Par exemple, le stylet d’Aributrum utilise un coprocesseur pour rendre le Stylus contract EVM compatible. Cette conception rapproche le stylet de l’architecture EVM+ que de la non-EVM.

! [Interprétation de la technologie de cumul Dapp : comment démocratiser l’application à haut débit ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-d1e13024e5-dd1a6f-69ad2a.webp)

Environnement d’exécution mixte

La troisième approche, qui est particulièrement populaire auprès des FOG, est la meilleure caractéristique qui combine les deux premières. Cette approche combine la compatibilité EVM avec un environnement d’exécution dédié non-EVM. Les environnements non-EVM se concentrent sur l’exécution haute performance des primitives de jeu de base. La gestion des actifs de jeu, comme les transactions NFT dans le jeu, peut être gérée par des contrats Solidity standard.

L’avantage de cette approche est que la compatibilité EVM garantit l’alignement avec l’écosystème plus large des développeurs et les produits existants. Il permet également une composabilité sans autorisation. Les développeurs peuvent modifier et étendre la logique du jeu en ajoutant des contrats intelligents EVM/Solidity. Dans le même temps, les moteurs de jeu spécialement conçus et non EVM atteignent un débit élevé qu’EVM ne peut pas atteindre.

Des exemples de cette approche sont le moteur mondial d’Argus et le moteur Keystone de Curio. World Engine sépare l’exécution de la logique du jeu en une couche distincte, appelée Game Shard, qui s’exécute au-dessus de la couche compatible EVM. Game Shard est également conçu pour permettre une mise à l’échelle horizontale afin d’ajuster le débit total de cumul en fonction de la demande. De même, l’architecture Keystone de Curio regroupe un moteur de jeu à haut débit avec un EVM en tant qu’environnement d’exécution Rollup. Le défi ici est d’atteindre une interopérabilité transparente entre les moteurs EVM et les moteurs de jeu.

! [Interprétation de la technologie de cumul Dapp : comment démocratiser l’application à haut débit ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-df306665b5-dd1a6f-69ad2a.webp)

Considérations relatives à la disponibilité des données

Dans la discussion précédente, l’accent a été mis sur l’augmentation du débit des transactions de cumul, qui est l’aspect principal de la mise à l’échelle du cumul d’applications. Parmi les autres sujets liés à cette augmentation du débit, citons la disponibilité des données (DA), la décentralisation des donneurs d’ordre et la vitesse de règlement. Pour les cumuls d’applications à haut débit, la disponibilité des données est le plus urgent de ces problèmes.

Un seul correctif cumulatif d’application peut avoir un débit de plus de 10 000 transactions par seconde. Il est impossible d’utiliser Ethereum comme couche de disponibilité des données pour ces transactions. Tout d’abord, le coût moyen de publication de données de transfert d’ETH L2 simples sur L2 peut dépasser 0,1 $. Ces coûts sont trop élevés pour la plupart des cumuls d’applications. De plus, la L1 d’Ethereum ne peut actuellement pas prendre en charge les cumuls qui tirent parti de la L1 pour la disponibilité des données avec environ 8 000 transactions par seconde.

Les cumuls d’applications s’appuieront principalement sur des solutions DA externes. Celestia et EigenDA sont actuellement positionnés comme les options les plus viables pour l’application Rollup. Par exemple, Eclipse prévoit d’utiliser Celestia comme couche de disponibilité des données pour son cumul de base SVM à haut débit. Argus et les moteurs de jeu à haut débit sont également prévus pour utiliser Celestia dans un premier temps. De même, EigenDA promet un débit de données allant jusqu’à 10 Mo par seconde et peut également fournir une solution viable pour les cumuls d’applications multiples.

Cependant, le principal inconvénient de l’intégration de Celestia ou d’EigneDA est la perte de valeur économique. Les cumuls d’applications doivent payer des frais pour la couche DA, ainsi que des frais de règlement sur Ethereum L1. Les frais de règlement sont essentiels au cumul de l’application, car ils lient la sécurité du cumul à la sécurité d’Ethereum. Les garanties DA sont moins importantes dans le contexte du FOG où la valeur de transaction est beaucoup plus faible que celle de ces réseaux. De plus, Celestia et EigenDA promettent des frais peu élevés, car ces réseaux sont tout juste opérationnels et leur utilisation sera faible au départ. Lorsque ces réseaux DA atteignent un taux d’utilisation élevé, les frais DA peuvent également devenir prohibitifs. À mon avis, le correctif cumulatif de l’application devrait utiliser un simple tableau de disponibilité des données (DAC) pour prouver la disponibilité des données de cumul.

En conclusion, je pense que les cumuls d’applications sont la meilleure solution existante pour la mise à l’échelle d’applications à haut débit, en particulier les jeux entièrement sur la chaîne. L’extension de ces applications avec Rollup est essentielle pour parvenir à une adoption généralisée au-delà des utilisateurs natifs de cryptomonnaies.

Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
  • Récompense
  • Commentaire
  • Partager
Commentaire
0/400
Aucun commentaire
Trader les cryptos partout et à tout moment
qrCode
Scan pour télécharger Gate app
Communauté
Français (Afrique)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)