Les rollups d'applications sont en train de s'imposer comme les grands gagnants de 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 permission, mais ne nécessitent pas d'interactions simultanées entre tous les utilisateurs de l'application. Les jeux à chaîne complète (FOG) sont le meilleur exemple qui corresponde à cette description. Les FOG bénéficient d'une forte propriété des actifs du jeu, d'une participation au jeu sans autorisation et d'une modélisation du jeu sans autorisation. Pourtant, la plupart des jeux n'exigent pas que tous les joueurs interagissent les uns avec les autres au même moment. D'autres applications peuvent bénéficier des stratégies de mise à l'échelle du rollup d'applications, notamment les places de marché NFT, les échanges perpétuels et l'inférence de l'IA sur la chaîne.

Les rollups d'applications sont déjà l'implémentation de référence pour bon nombre de ces cas d'utilisation. Cependant, les implémentations standard des rollups, c'est-à-dire les rollups EVM, présentent encore d'importantes limites d'extensibilité. Ils peuvent probablement atteindre des débits de l'ordre de 100 transactions par seconde. Ce débit peut être suffisant pour certains jeux en chaîne, selon le type de jeu. Cependant, la plupart des jeux ont besoin d'un débit beaucoup plus élevé pour supporter un grand nombre (> 1000) de joueurs simultanés. Cet article se concentre sur les approches de la mise à l'échelle des app-rollups pour atteindre des centaines de milliers de participants simultanés. Pour chaque approche, je discute du type d'applications/de jeux approprié et des défis à relever.

Les constructeurs qui utilisent des app rollups ou ceux qui mettent en place l'infrastructure nécessaire à la mise à l'échelle des app rollups sont encouragés à me contacter et à poser leur candidature à Alliance. Je me réjouis de travailler avec les fondateurs qui construisent dans ces domaines.

Mise à l'échelle horizontale

L'évolutivité horizontale est l'approche la plus simple pour faire évoluer les rollups d'applications. Toutefois, cette simplicité se fait au détriment de la composabilité, ce qui les rend uniquement adaptés à un petit nombre d'applications telles que les jeux à un seul joueur.

L'évolutivité horizontale signifie qu'il suffit de déployer plusieurs rollups d'applications (OP ou ZK) avec le même contrat intelligent déployé dans tous les rollups. L'interface de l'application dirige de manière transparente l'utilisateur vers l'un des rollups 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 FOCG 2048 évolutif. Dans l'interface du jeu, l'utilisateur a la possibilité de sélectionner le groupe auquel il souhaite participer en fonction de sa situation géographique. En raison de la simplicité et de la disponibilité des fournisseurs de rollups en tant que service, tels que Caldera, qui prennent en charge tout le travail d'infrastructure lié à la création et à la gestion de ces rollups, cette approche peut être facilement adoptée par les développeurs de jeux.

Malgré sa simplicité, l'approche de la mise à l'échelle multi-rouleaux pose quelques problèmes. La première est la commutation de réseau par déploiement. Les portefeuilles actuels, par exemple Metamask, nécessitent une approbation manuelle pour se connecter à un nouveau réseau, c'est-à-dire à une instance de rollup. Il en résulte une expérience utilisateur difficile et confuse pour les joueurs qui doivent se connecter manuellement à plusieurs "réseaux" pour jouer au même jeu. Heureusement, il est possible de faire abstraction de cette complexité grâce à des solutions AA. C'est-à-dire l'EIP 4337 et les portefeuilles intégrés tels que Privy et 0xPass.

Un autre défi est la gestion de l'état des joueurs lors d'une transition entre deux rollups. Dans certains cas, par exemple en cas de baisse de capacité, l'application peut avoir besoin de consolider plusieurs instances de rollup en une seule afin d'économiser des ressources. Dans ce cas, tous les états du joueur actif doivent être transférés vers la nouvelle instance. Les solutions de pontage actuelles, en particulier les ponts zk, peuvent jouer un rôle essentiel dans la résolution de ce problème. Grâce à ces solutions, il est possible d'intégrer l'état de jeu du joueur dans une nouvelle instance de rollup tout en conservant une preuve de la validité de cet état. Toutefois, la latence des solutions de pontage existantes peut être moins optimale pour les jeux.

Canaux d'État ZK

Une autre approche de mise à l'échelle du rollup d'applications, plus adaptée aux jeux multijoueurs, par exemple le poker, est celle des canaux d'état zk. Dans ces jeux, les interactions entre les joueurs se font entre un petit nombre de joueurs, par exemple entre 2 et 10. Le jeu de ces joueurs n'est important que lorsque le jeu progresse. Le résultat final du jeu est cependant plus important car il affecte l'équilibre des actifs de chaque joueur. Il est donc important de stocker le résultat dans une couche persistante partagée.

Dans ce cas, le rollup d'application représente la couche d'information partagée où les résultats du jeu sont stockés et où les actifs du jeu existent. Pour chaque jeu du rollup, un canal d'État ZK peut être lancé pour servir ce jeu. Au cours du jeu, chaque joueur génère des transactions et crée un ZKP prouvant qu'il a respecté les règles du jeu. Les preuves issues des interactions avec d'autres joueurs regroupent les preuves précédentes à l'aide d'une méthode récursive. À la fin du jeu, le ZKP final est soumis au rollup de l'application pour prouver la validité du jeu et du résultat final. Le changement d'état résultant du jeu modifie les états des joueurs sur le rollup de l'application.

Les canaux d'état ZK déplacent les interactions du jeu hors de la chaîne. Par conséquent, les activités et les transactions dans le jeu ne sont pas prises en compte dans le calcul du débit du rollup de l'application. Grâce à cette approche, les rollups d'applications peuvent évoluer massivement pour prendre en charge des dizaines ou des centaines de milliers de joueurs simultanés. Les transactions de rollup de l'application se limiteront à la vérification des ZKP générés et aux transactions de mise à jour de l'état, ce qui se traduit par un facteur d'échelle de 100 à 1000x. De nombreuses équipes, dont Ontropy, se sont concentrées sur le développement de cette technologie.

L'inconvénient de cette approche est qu'elle oblige les joueurs à exécuter la logique du jeu et à générer les ZKP sur leurs appareils. Souvent, ces preuves sont légères et, grâce à des systèmes de démonstration de pointe comme Halo2, la démonstration peut prendre moins de quelques secondes. Toutefois, cela peut encore entraîner une dégradation de l'expérience utilisateur pour les joueurs disposant d'appareils aux ressources limitées.

Une modification de cette approche qui peut atténuer ce problème consiste à assigner l'un des zk participants au canal d'état en tant que séquenceur temporaire. Ce séquenceur recevra les transactions de chaque joueur, générera les ZKP correspondants et partagera les ZKP avec tous les participants au canal. Cette modification peut être considérée comme des ZK L3 éphémères qui s'installent dans le rollup de l'application. L'équipe de Cartridge a mis en œuvre cette architecture en concevant un séquenceur spécialisé appelé Katana.

L'approche du canal d'état zk présente un grand potentiel. Toutefois, plusieurs questions restent en suspens concernant l'environnement d'exécution à l'intérieur du canal d'état zk et la manière de l'optimiser pour la récursivité de la preuve. Les environnements zkEVM actuels ne sont pas très efficaces et la plupart d'entre eux ne supportent pas la récursivité des preuves. Les alternatives incluent des zkVM légers ou même l'utilisation de circuits zk spécialisés pour les interactions avec le joueur si le nombre d'actions possibles pour le joueur est limité.

Modifier l'environnement d'exécution

Une troisième approche pour l'évolutivité du rollup consiste à modifier l'environnement d'exécution du rollup. Malgré la maturité et l'abondance des outils de développement EVM, ils ne sont pas adaptés aux applications à haute performance telles que les jeux. En outre, le modèle d'exécution et de stockage à un seul fil de l'EVM conduit à un débit réduit qui peut être amélioré.

Le principal avantage de cette approche est que l'amélioration du débit du rollup ne nécessite pas de sacrifier la composabilité ou de restreindre le nombre de cas d'utilisation. Cette approche peut fonctionner pour n'importe quelle application Web 3, à condition que l'environnement d'exécution puisse atteindre le débit requis par l'application. Ils constituent donc la seule solution viable pour les applications qui nécessitent l'accès à un état partagé, comme les AMM, les protocoles de prêt et d'autres applications DeFi.

Extension des fonctionnalités de l'EVM grâce à des précompilations

La première approche consiste à maintenir la compatibilité du rollup avec l'EVM et à remédier à certaines limitations de débit par le biais de précompilations. L'idée est simple. Une précompilation consiste simplement à déplacer les opérations EVM coûteuses en calcul vers le niveau du nœud. Une opération qui nécessiterait des centaines ou des milliers d'OP EVM et consommerait plus de 100 000 euros de gaz peut être simplifiée en une seule opération avec des coûts de gaz 100 fois inférieurs. L'extension de l'environnement du rollup avec des précompilations est souvent appelée EVM+. Les exemples de cette approche comprennent la prise en charge de la confidentialité au sein de la chaîne et la prise en charge de schémas de signature plus efficaces, par exemple les signatures BLS. Par exemple, le jeu de poker zkHoldem utilise un FHE spécialisé et des opérations zk pour distribuer et révéler les cartes de poker en privé. Le développement de ces précompilations spécialisées est souvent un effort partagé entre le développeur de l'app rollup et les fournisseurs Raas qui gèrent le déploiement et la maintenance de l'infrastructure de l'app rollup.

Utilisation d'un environnement d'exécution autre qu'EVM

Une autre approche pour améliorer l'environnement d'exécution du rollup consiste à s'affranchir de l'EVM. Cette approche est de plus en plus populaire parmi les développeurs qui sont nouveaux dans l'écosystème Ethereum et les développeurs qui croient que Solidity n'est pas le meilleur langage pour développer des applications complexes.

Aujourd'hui, nous avons des applications de rollup qui fonctionnent sur WASM, SVM, Cairo et même Linux. La plupart de ces approches permettent aux développeurs d'écrire leur contrat intelligent dans des 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, il est toujours possible de créer une compatibilité avec le MVE. Par exemple, le stylet d'Aributrum utilise un coprocesseur pour rendre les contrats Stylus compatibles avec l'EVM. Cette conception rapproche Stylus d'une architecture EVM+ plutôt que d'une architecture non EVM.

Environnements d'exécution hybrides

Une troisième approche, particulièrement populaire au sein des FOG, consiste à combiner les meilleures caractéristiques des deux approches précédentes. Cette approche combine la compatibilité EVM avec l'environnement d'exécution spécialisé non EVM. Les environnements non-EVM se concentrent sur l'exécution haute performance des primitives du jeu. La gestion des actifs dans le jeu, par exemple l'échange des 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 sur un écosystème plus large de développeurs et de produits existants. Il permet également la composabilité sans autorisation. Les développeurs peuvent modifier et étendre la logique du jeu en ajoutant des contrats intelligents EVM/solidity. Parallèlement, le moteur de jeu spécialisé sans EVM permet d'atteindre un débit élevé qui ne peut pas être atteint par l'EVM.

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

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

Dans la discussion précédente, l'accent a été mis sur l'aspect principal de la mise à l'échelle des rollups d'applications, à savoir l'augmentation du débit des transactions du rollup. Il existe d'autres sujets liés à cette augmentation du débit, tels que la disponibilité des données (DA), la décentralisation du séquenceur et la vitesse de règlement. La disponibilité des données est le problème le plus urgent pour les rollups d'applications à haut débit.

Un seul rollup d'application peut potentiellement atteindre des débits supérieurs à 10k tps. Il n'est pas possible d'utiliser Ethereum comme couche DA pour ces transactions. Tout d'abord, le coût moyen de la publication des données d'un simple transfert d'ETH L2 sur L1 peut dépasser 0,10 $. Ces coûts sont trop élevés pour la plupart des regroupements d'applications. Plus important encore, la L1 d'Ethereum ne peut actuellement pas supporter plus d'environ 8k TPS [1] pour les rollups qui utilisent la L1 pour le DA.

Les déploiements d'applications dépendront principalement de solutions DA externes. Celestia et EigenDA sont actuellement considérés comme l'option la plus viable pour les rollups d'applications. Par exemple, Eclipse prévoit d'utiliser Celestia pour son rollup à haut débit basé sur les SVM. Argus et les moteurs de jeu à haut débit prévoient également d'utiliser Celestia dans un premier temps. De même, EigenDA, qui promet un débit de données allant jusqu'à 10 Mo/s, peut être une solution viable pour les applications multiples.

L'intégration de Celestia ou d'EigneDA présente toutefois l'inconvénient majeur d'une fuite de valeur économique. Le rollup d'applications doit payer des frais pour la couche DA en plus des frais de règlement sur l'Ethereum L1. Les frais de règlement sont essentiels pour le rollup d'applications car ils alignent la sécurité du rollup sur celle d'Ethereum. Les garanties DA sont moins importantes, en particulier dans le contexte des FOG où les valeurs de transaction sont beaucoup plus faibles. En outre, Celestia et EigenDA promettent des redevances peu élevées car ces réseaux sont nouveaux et seront peu utilisés dans un premier temps. Lorsque ces réseaux DA sont fortement utilisés, les frais DA peuvent également devenir excessifs. À mon avis, les rollups d'applications devraient plutôt utiliser un simple comité de disponibilité des données (DAC) pour attester de la disponibilité des données du rollup[3] .

En conclusion, je pense que les app rollups sont la meilleure solution existante pour mettre à l'échelle les applications à haut débit en général et les jeux entièrement sur la chaîne en particulier. La mise à l'échelle de ces applications est la clé de l'adoption par le grand public, au-delà des utilisateurs natifs de crypto-monnaies. Chez Alliance, nous voulons faire de cette vision une réalité en soutenant les fondateurs qui construisent ce projet.

Je tiens à remercier Matt Katz, Kevin Zhang, Tarrence van As et Larry Liu pour leurs précieux commentaires sur cet article.

[1] Suppose que 50 % de la limite de gaz de bloc d'Ethereum sera uniquement utilisée pour stocker des données à l'aide de calldata, 10 octets de taille moyenne tx. Temps de bloc de 12 secondes

Clause de non-responsabilité：

1. Cet article est repris de[Alliance]. Tous les droits d'auteur appartiennent à l'auteur original[Mohamed Fouda]. 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.