Détails techniques sur la technologie Rollup pour les applications : la clé vers l'adoption généralisée des applications à haut débit
TechFlow SélectionTechFlow Sélection
Détails techniques sur la technologie Rollup pour les applications : la clé vers l'adoption généralisée des applications à haut débit
Rollup est la meilleure solution existante pour étendre les applications à débit élevé, en particulier les jeux entièrement sur chaîne.
Dédié à des analyses Web3 approfondiesRédaction : Mohamed Fouda
Traduction : TechFlow
Les rollups dédiés aux applications deviennent clairement la solution gagnante pour étendre un ensemble spécifique d'applications Ethereum. Ces applications bénéficient de garanties sans autorisation et d'une propriété solide, mais n'ont pas besoin d'interactions simultanées entre tous les utilisateurs. Les jeux entièrement sur chaîne en sont le meilleur exemple. Les jeux sur chaîne profitent d'une forte assurance sur la propriété des actifs, permettent une participation anonyme et autorisent des modifications anonymes du jeu. Néanmoins, la plupart des jeux ne nécessitent pas que tous les joueurs interagissent en même temps. D'autres applications pouvant bénéficier de cette stratégie d'évolutivité incluent les marchés NFT, les échanges perpétuels et l'inférence d'IA sur chaîne.
Les rollups applicatifs sont déjà la solution privilégiée pour bon nombre de ces cas d'utilisation. Toutefois, les implémentations standard de rollups, comme EVMRollup, présentent encore des limites importantes en matière d'évolutivité. Ils peuvent atteindre un débit d’environ 100 transactions par seconde. Pour certains jeux sur chaîne, ce débit peut suffire selon le type de jeu. Cependant, la majorité des jeux nécessitent un débit plus élevé afin de prendre en charge un grand nombre de joueurs concurrents (plus de 1 000). Cet article met l’accent sur les méthodes permettant d’étendre les rollups applicatifs pour couvrir des dizaines de milliers de participants simultanés. Pour chaque méthode, je discuterai du type d’applications ou de jeux concernés ainsi que des défis associés.
Évolutivité horizontale
L’évolutivité horizontale est la méthode la plus simple pour étendre les rollups applicatifs. Cette simplicité s’accompagne toutefois d’un compromis au niveau de la composition, ce qui limite leur usage à un petit nombre d’applications, telles que les jeux solo.
L’évolutivité horizontale consiste simplement à déployer plusieurs rollups applicatifs (Optimistic ou ZK) et à y déployer les mêmes contrats intelligents. Le frontend de l’application redirige alors transparentement les utilisateurs vers l’un des rollups selon la capacité disponible, la localisation ou des options spécifiques à l’application. Alt Layer a récemment illustré ce concept en lançant une version extensible du jeu 2048 FOCG. Depuis l’interface du jeu, les utilisateurs peuvent choisir à quel rollup ils souhaitent se connecter en fonction de leur géolocalisation. Grâce à sa simplicité et à la disponibilité de fournisseurs de type « Rollup as a Service » tels que Caldera — qui prennent en charge toute l’infrastructure liée au déploiement et à la gestion de ces rollups — cette approche peut être facilement adoptée par les développeurs de jeux.
Néanmoins, cette méthode multi-rollup présente plusieurs problèmes. Le premier concerne le changement de réseau entre rollups. Les portefeuilles actuels, comme MetaMask, exigent une validation manuelle pour se connecter à un nouveau réseau, c’est-à-dire à une instance de rollup. Cela crée une expérience utilisateur difficile et confuse, car les joueurs doivent se connecter manuellement à plusieurs « réseaux » pour jouer au même jeu. Heureusement, cette complexité peut être atténuée grâce à des solutions d’abstraction des comptes (AA), telles que l’EIP-4337 ou des portefeuilles intégrés comme Privy et 0xPass.
Un autre défi réside dans la gestion de l’état des joueurs lors de la transition entre les rollups. Dans certains cas, notamment lorsque la charge diminue, l’application pourrait avoir besoin de fusionner plusieurs instances de rollups en une seule, afin d’économiser des ressources. Dans cette situation, l’état de tous les joueurs actifs doit être migré vers la nouvelle instance. Les solutions de pont actuelles, en particulier les ponts zk, peuvent jouer un rôle clé ici. Grâce à ces solutions, l’état de jeu des joueurs peut être transféré vers une nouvelle instance de rollup tout en conservant une preuve de validité de cet état. Toutefois, la latence des ponts existants peut ne pas être optimale pour les cas d’utilisation liés aux jeux.
Canaux d’état ZK
Une autre méthode d’évolutivité adaptée aux jeux multijoueurs (comme le poker) consiste à utiliser des canaux d’état ZK. Dans ces jeux, les interactions ont lieu entre un petit groupe de joueurs (par exemple 2 à 10). Ces interactions ne sont critiques que pendant la partie. En revanche, le résultat final du jeu est plus important, car il affecte les soldes d’actifs de chaque joueur. Il est donc essentiel de stocker ce résultat dans une couche partagée et persistante.
Dans ce contexte, le rollup applicatif représente cette couche d’information partagée où sont stockés les résultats des parties et les actifs du jeu. Pour chaque partie sur le rollup, un canal d’état ZK peut être lancé. Pendant la partie, chaque joueur génère des transactions et produit des ZKP prouvant qu’il respecte les règles du jeu. Les preuves des interactions avec les autres joueurs sont agrégées récursivement à partir de la preuve précédente. À la fin du jeu, le ZKP final est soumis au rollup applicatif afin de valider la légitimité du déroulement du jeu et du résultat final. Les modifications d’état résultantes sont alors appliquées à l’état des joueurs sur le rollup.
Les canaux d’état ZK déplacent les interactions du jeu hors chaîne. Par conséquent, les activités et transactions du jeu ne contribuent pas au débit du rollup applicatif. Avec cette méthode, le rollup peut s’adapter à grande échelle, supportant des milliers de joueurs simultanés. Les transactions sur le rollup applicatif se limitent alors à la vérification des ZKP générés et aux mises à jour d’état, offrant un facteur d’évolutivité allant de 100 à 1 000 fois. Plusieurs équipes, dont Ontropy, travaillent activement sur cette technologie.
Un inconvénient de cette méthode est que les joueurs doivent exécuter la logique du jeu sur leurs propres appareils et générer les ZKP. Bien que ces preuves soient généralement légères et que des systèmes avancés comme Halo2 permettent de les produire en quelques secondes, cela peut nuire à l’expérience des joueurs disposant d’appareils peu puissants.
Une variante pour atténuer ce problème consiste à désigner l’un des participants du canal ZK comme ordonnanceur temporaire. Ce dernier reçoit les transactions de chaque joueur, génère les ZKP correspondants et les partage avec tous les participants du canal. Cette modification peut être vue comme un ZK L3 éphémère qui se règle sur le rollup applicatif. L’équipe Cartridge a mis en œuvre cette architecture en concevant un ordonnanceur dédié appelé Katana.
La méthode des canaux d’état ZK possède un potentiel considérable. Toutefois, plusieurs questions restent ouvertes, notamment concernant l’environnement d’exécution dans les canaux ZK et l’optimisation des preuves récursives. Les environnements zkEVM actuels sont inefficaces, et la plupart ne supportent pas encore la récursion de preuves. Des alternatives incluent des zkVM légers, voire des circuits ZK spécialisés si le nombre d’actions possibles pour les joueurs est limité.
Changement de l’environnement d’exécution
Une troisième méthode pour étendre les rollups applicatifs consiste à modifier leur environnement d’exécution. Malgré la maturité des outils de développement EVM, ceux-ci ne conviennent pas aux applications hautes performances comme les jeux. De plus, l’exécution monofilaire de l’EVM et son modèle de stockage entraînent une baisse du débit, qui pourrait être améliorée.
Le principal avantage de cette approche est qu’elle permet d’augmenter le débit du rollup sans sacrifier la composition ni limiter le nombre de cas d’utilisation. Tant que l’environnement d’exécution atteint le débit requis par l’application, cette méthode peut être utilisée pour n’importe quelle application Web3. Elle constitue ainsi la seule solution viable pour les applications nécessitant un accès à un état partagé, comme les AMM, les protocoles de prêt et autres applications DeFi.
Extension des fonctionnalités EVM via des pré-compilations
Premièrement, le rollup conserve la compatibilité EVM et contourne certaines limitations de débit grâce à des adresses pré-compilées. L’idée est simple : les opérations EVM intensives en calcul sont déplacées au niveau du nœud. Une opération nécessitant des centaines ou milliers d’opcodes EVM et consommant plus de 100 000 gas peut être réduite à une seule opération, avec un coût en gas divisé par 100. Ces pré-compilations destinées à étendre l’environnement du rollup sont souvent appelées EVM+. Des exemples incluent le support de la confidentialité sur chaîne ou des schémas de signature plus efficaces, comme les signatures BLS. Par exemple, le jeu de poker zkHoldem utilise des pré-compilations spécialisées basées sur le chiffrement homomorphe entièrement homomorphe (FHE) et des opérations ZK pour distribuer et révéler les cartes de manière privée. Le développement de ces pré-compilations spécialisées résulte souvent d’une collaboration entre les développeurs du rollup applicatif et les fournisseurs Raas responsables du déploiement et de la maintenance de l’infrastructure.
Utilisation d’environnements d’exécution non-EVM
Une autre façon d’améliorer l’environnement d’exécution du rollup est de s’affranchir complètement de l’EVM. Cette approche gagne en popularité auprès des nouveaux développeurs dans l’écosystème Ethereum, ainsi que chez ceux qui considèrent que Solidity n’est pas le meilleur langage pour développer des applications complexes.
Aujourd’hui, nous disposons de rollups applicatifs fonctionnant sur WASM, SVM, Cairo, voire même sur des environnements Linux. La plupart de ces approches permettent aux développeurs d’écrire des contrats intelligents en langages évolués comme Rust ou C. L’inconvénient est souvent la perte d’interopérabilité avec les contrats Solidity existants. Toutefois, il reste possible de créer une compatibilité avec l’EVM. Par exemple, Stylus d’Arbitrum utilise un coprocesseur pour assurer la compatibilité entre les contrats Stylus et l’EVM. Cette conception rapproche Stylus d’une architecture EVM+ plutôt que d’un environnement purement non-EVM.
Environnements d’exécution hybrides
Une troisième approche, particulièrement prisée dans le domaine des jeux FOG, consiste à combiner le meilleur des deux mondes. Cette méthode associe compatibilité EVM et environnement d’exécution non-EVM spécialisé. Ce dernier se concentre sur une exécution haute performance des primitives du jeu. La gestion des actifs du jeu, comme les transactions NFT en jeu, peut quant à elle être prise en charge par des contrats Solidity standards.
L’avantage de cette approche est que la compatibilité EVM assure une intégration fluide avec l’écosystème plus large des développeurs et des produits existants. Elle permet également une composable sans autorisation : les développeurs peuvent étendre ou modifier la logique du jeu en ajoutant des contrats intelligents EVM/Solidity. Parallèlement, le moteur de jeu non-EVM spécialisé atteint des débits élevés impossibles à réaliser avec l’EVM.
Des exemples de cette approche incluent le World Engine d’Argus et l’architecture Keystone de Curio. World Engine sépare l’exécution de la logique du jeu dans une couche distincte appelée Game Shard, qui fonctionne au-dessus de la couche compatible EVM. Le Game Shard est également conçu pour permettre une évolutivité horizontale, ajustant ainsi le débit total du rollup selon la demande. De manière similaire, Keystone de Curio associe un moteur de jeu à haut débit à un environnement EVM dans le cadre de l’exécution du rollup. Le défi ici réside dans la mise en œuvre d’une interopérabilité transparente entre le moteur EVM et le moteur de jeu.
Considérations sur la disponibilité des données
Dans la discussion précédente, l’accent a été mis sur l’augmentation du débit transactionnel du rollup, aspect principal de l’évolutivité des rollups applicatifs. D’autres sujets liés à cet accroissement incluent la disponibilité des données (DA), la décentralisation des ordonnanceurs et la vitesse de règlement. Pour les rollups applicatifs à haut débit, la disponibilité des données est la question la plus urgente parmi celles-ci.
Le débit d’un seul rollup applicatif peut dépasser 10 000 transactions par seconde. Utiliser Ethereum comme couche de disponibilité des données pour ces transactions est impossible. Premièrement, le coût moyen de publication des données d’une simple transaction ETH L2 sur la L1 peut dépasser 0,1 dollar. Ces coûts sont trop élevés pour la plupart des rollups applicatifs. Pire encore, la L1 Ethereum ne peut actuellement supporter plus d’environ 8 000 transactions par seconde pour les rollups utilisant la L1 comme couche DA.
Les rollups applicatifs devront principalement s’appuyer sur des solutions DA externes. Celestia et EigenDA se positionnent actuellement comme les choix les plus viables pour les rollups applicatifs. Par exemple, Eclipse prévoit d’utiliser Celestia comme couche de disponibilité des données pour ses rollups SVM à haut débit. Argus et les moteurs de jeu à haut débit prévoient également d’utiliser initialement Celestia. De même, EigenDA promet un débit de données allant jusqu’à 10 Mo/s, ce qui peut constituer une solution viable pour plusieurs rollups applicatifs.
Toutefois, l’intégration de Celestia ou d’EigenDA présente un inconvénient majeur : la fuite de valeur économique. Les rollups applicatifs doivent payer des frais à la couche DA, ainsi que des frais de règlement sur la L1 Ethereum. Les frais de règlement sont cruciaux pour les rollups applicatifs, car ils lient la sécurité du rollup à celle d’Ethereum. La garantie de disponibilité des données est moins critique dans le contexte des jeux FOG, où la valeur des transactions est bien inférieure à celle de ces réseaux. De plus, Celestia et EigenDA promettent des frais bas, car ces réseaux sont récents et leur utilisation initiale sera faible. Lorsque ces réseaux DA atteindront une forte utilisation, les frais DA pourraient devenir excessifs. À mon avis, les rollups applicatifs devraient utiliser un simple comité de disponibilité des données (DAC) pour attester de la disponibilité des données du rollup.
En conclusion, je pense que les rollups applicatifs constituent la meilleure solution existante pour étendre les applications à haut débit, en particulier les jeux entièrement sur chaîne. L’évolutivité de ces rollups est la clé pour atteindre une adoption massive au-delà des seuls utilisateurs natifs de la cryptographie.
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
