Risques et opportunités des chaînes d'applications : une équipe doit-elle créer une chaîne dédiée pour son application ?
TechFlow SélectionTechFlow Sélection
Risques et opportunités des chaînes d'applications : une équipe doit-elle créer une chaîne dédiée pour son application ?
Pour certains projets à forte croissance, la transition vers une chaîne d'application est prévisible.
Dédié à des analyses Web3 approfondies
Rédaction : Mohamed Fouda
Traduction : TechFlow
Au cours de l'année écoulée, plusieurs applications très médiatisées ont lancé leur propre chaîne dédiée à une application spécifique ou ont annoncé leurs projets futurs en ce sens.
Pour certains projets en forte croissance, le passage vers une chaîne d’application est prévisible.
Un article sur les appchains prédit que chaque application populaire de Web3 finira par avoir sa propre blockchain.
Cette tendance pousse certains fondateurs à penser qu’il serait préférable d’architecturer dès le départ leur produit comme une chaîne d’application.
À mon avis, cette approche peut convenir à certaines applications, mais pour d'autres, investir précocement dans une chaîne d’application pourrait s'avérer suicidaire.
Pourquoi choisir une chaîne d’application ?
Une chaîne d’application est conçue principalement pour exécuter une seule fonction ou application.
Par exemple, un jeu ou une application DeFi. Cela signifie que l’application peut utiliser toutes les ressources de la chaîne – débit, état, etc. – sans concurrence avec d’autres applications. En outre, ce choix architectural permet d’optimiser la structure technique, les paramètres de sécurité, le débit, etc., selon les besoins spécifiques de l’application.
Comme il est généralement impossible de déployer d'autres applications sur la chaîne, les chaînes d’applications ne sont pas nécessairement sans permission pour les développeurs ; elles sont uniquement sans permission pour les utilisateurs.
Ce concept contraste avec celui des blockchains standards, où la chaîne est ouverte aux utilisateurs et aux développeurs.
Les chaînes d’applications comparées à des villes rurales
L’analogie « les chaînes à contrats intelligents sont comme des villes » aide à comprendre les compromis pris par les fondateurs lorsqu'ils choisissent de lancer une application sous forme de chaîne dédiée.
Les chaînes de calcul généralistes comme Ethereum et Solana ressemblent à de grandes métropoles. Elles disposent d’une infrastructure diversifiée pouvant supporter différents types d’entreprises (applications). Cela rend ces chaînes plus populaires, plus congestionnées, souvent plus coûteuses, et parfois tendues.
Mais cet afflux crée d’énormes flux et opportunités pour les projets au sein de l’écosystème.
Il est facile de passer d’un projet à un autre, et on peut combiner différentes activités commerciales pour créer de nouveaux modèles innovants.
En revanche, les chaînes d’applications ressemblent à des petites villes rurales centrées sur une seule activité économique.
Cette ville peut fixer ses propres règles et politiques. Elle est moins fréquentée et moins chère, mais peut être peu connectée au monde extérieur. Tous les habitants utilisent l’unique entreprise locale, et si celle-ci est suffisamment populaire ou unique, des clients viendront même spécialement pour elle.
Cette analogie s’étend également aux différences de sécurité entre les deux types de chaînes :
- Les grandes villes ont plus d’habitants, sont plus riches et plus puissantes.
- Toutes les entreprises de la ville ont un intérêt commun : vivre dans une ville sûre et sécurisée. Ces facteurs rendent les grandes villes plus difficiles à attaquer, donc plus sûres.
- La sécurité d’une petite ville rurale, en revanche, dépend étroitement de la notoriété et du succès de son unique entreprise.
- Si l’entreprise prospère, la population augmente et la ville devient plus forte ; si elle connaît des difficultés, les gens partent, affaiblissant la ville et la rendant plus vulnérable aux attaques.
Entre ces deux modèles se situent les chaînes sectorielles, qui soutiennent certains types d’activités (ex. : DeFi ou jeux) mais pas tous. Elles sont comparables à des banlieues : plus populaires et plus sûres que les villages ruraux, mais moins animées que les métropoles.
Les chaînes de calcul général, les chaînes d’applications et les chaînes sectorielles offrent une diversité nécessaire, pouvant coexister pour répondre à différents besoins. L’essentiel est d’identifier les cas d’usage nécessitant une chaîne d’application plutôt que de construire un contrat intelligent sur une chaîne de calcul généraliste ou sectorielle.
Quand opter pour une chaîne d’application ?
Comme nous l’avons vu ces dernières années, les chaînes d’applications peuvent être lancées pour diverses raisons. Dans cette section, nous examinerons les scénarios les plus courants où construire une chaîne d’application constitue le meilleur choix.
Exigences de l’écosystème
Dans des écosystèmes comme Cosmos et Polkadot, les développeurs doivent fondamentalement construire leurs applications sous forme de chaînes dédiées. Ces deux protocoles visent à créer un écosystème composé de multiples chaînes interconnectées, et leurs chaînes principales n’intègrent aucun moteur d’exécution pour les contrats intelligents. Ainsi, pour développer une application, l’une des options consiste à créer une chaîne d’application ou à utiliser une chaîne implémentant un moteur d’exécution généraliste.
Dans l’écosystème Cosmos, des chaînes comme Evmos (compatible EVM) et Juno (contrats CosmWasm) implémentent un moteur de contrats intelligents. Ces zones Cosmos généralistes hébergent déjà plusieurs applications DeFi et NFT. D'autres applications choisissent de bâtir leurs propres chaînes optimisées. Par exemple : Osmosis (DEX AMM), Mars Hub (crédit) et Secret (confidentialité).
Dans l’écosystème Polkadot, les parachains à calcul général incluent Moonbeam (compatible EVM) et Astar (contrats WASM). Des exemples de chaînes d’applications sur Polkadot sont Polkadex (DEX à livres d’ordres), Phala (confidentialité) et Nodle (réseau IoT).
Exigences de l’application
Un autre cas où une chaîne d’application est la meilleure solution survient lorsque les exigences de débit ou de frais de l’application ne peuvent être satisfaites par une chaîne de calcul généraliste. Les applications nécessitant des performances Web2 dans un environnement Web3 sans permission devraient envisager une chaîne d’application comme première option. Les jeux sont un excellent exemple de cette catégorie.
La plupart des jeux interactifs requièrent un débit extrêmement élevé pour gérer les interactions des joueurs. En outre, ces transactions doivent être gratuites ou presque. Ces exigences ne peuvent être remplies par des chaînes généralistes, ce qui justifie le lancement d'une chaîne spécialisée. Voici quelques exemples :
- Le jeu Axie Infinity – lancé sur la sidechain Ronin ;
- Sorare – un jeu de football fantastique lancé sur StarkEx L2 ;
Hors du domaine des jeux, les protocoles DeFi tels que les bourses à livres d’ordres ont souvent besoin d’un haut débit pour offrir une excellente expérience aux traders professionnels. Un exemple célèbre est dYdX, une bourse de produits dérivés DeFi. Le protocole dYdX traite actuellement environ 1 000 ordres par seconde. La chaîne doit donc supporter un débit supérieur à 1 000 TPS. Pour cette raison, sa version V3 a été lancée comme un rollup Ethereum spécialisé basé sur StarkEx. Comme le protocole prévoit une expansion future nécessitant un débit encore plus élevé, il s’oriente vers une autre implémentation de chaîne d’application. Il a annoncé qu’il utiliserait une chaîne Cosmos dédiée pour sa version V4.
Ajout de fonctionnalités techniques
Si une application nécessite une technologie spécifique absente des chaînes L1, une autre solution consiste à créer une chaîne d’application intégrant cette technologie. Le meilleur exemple est celui des preuves à divulgation nulle (zk-SNARKs ou zk-STARKs).
Les applications axées sur la confidentialité, comme les paiements privés ou les échanges confidentiels, ont besoin des preuves ZK comme briques de base. Toutefois, les calculs ZK sont trop intensifs pour être effectués directement sur la chaîne, car ils seraient trop coûteux. Dans ce cas, la meilleure approche est d’implémenter la technologie souhaitée sur une chaîne d’application. Par exemple, Aztec, une application de paiements et d’échanges privés sur Ethereum, a lancé son propre L2 sur Ethereum. Un exemple similaire est la chaîne d’application Secret dans l’écosystème Cosmos.
Amélioration de l’économie de l’application
Lorsqu’une équipe construit son application sous forme de contrat intelligent sur une blockchain L1, les utilisateurs paient deux types de frais : les frais natifs de l’application et les frais de gaz.
- Les frais natifs de l’application — par exemple, les frais de transaction sur une bourse ou la marge d’un protocole de prêt — constituent la source de revenus de l’application.
- Ces revenus servent généralement à inciter les participants et à accélérer l’adoption.
- Les frais de gaz, quant à eux, sont payés par les utilisateurs aux validateurs de la L1 pour garantir l’inclusion de leurs transactions.
- Ils représentent une charge pour les utilisateurs, nuisent à l’expérience utilisateur, et ne contribuent pas à l’économie de l’application. Bien que nécessaires pour assurer la sécurité, il serait idéal que cette valeur économique reste dans l’écosystème de l’application pour récompenser ses participants.
Les chaînes d’applications rendent cette vision possible : les frais de gaz et leur distribution peuvent être contrôlés pour récompenser les participants à l’application.
L’effort de Yuga Labs pour scinder l’écosystème Bored Ape Yacht Club (BAYC) vers une chaîne indépendante illustre parfaitement ce scénario. La communauté BAYC a payé d’importantes sommes en frais Ethereum lors du minting des NFT. Le transfert vers leur ApeChain permettra de garder ces frais au sein de l’économie BAYC.
Pourquoi ne pas créer une chaîne d’application ?
Malgré leurs avantages, les chaînes d’applications comportent aussi des risques.
Le principal risque est que construire une chaîne d’application est beaucoup plus complexe que de développer un contrat intelligent.
Cela implique de développer des infrastructures non liées au cœur métier de l’application.
De plus, les risques liés à la sécurité et à la composable sont accrus.
Sécurité
Les applications à base de contrats intelligents tirent leur sécurité de la couche L1 sous-jacente.
Comme discuté précédemment avec l’analogie de la métropole, la L1, en supportant de nombreuses applications, bénéficie d’un consensus large parmi ses participants. Cela la rend plus sûre et plus difficile à attaquer. De plus, la sécurité de la L1 ne dépend pas de l’adoption d’une application spécifique.
Dans une chaîne d’application, la sécurité dépend principalement de l’adoption de l’application et du prix de son jeton natif.
Selon l’implémentation, la chaîne d’application peut choisir un ordonnanceur L2 ou des validateurs PoS indépendants. Dans les deux cas, les récompenses des validateurs sont généralement exprimées en jeton natif de l’application. Les validateurs doivent staker ce jeton et exploiter une infrastructure complexe avec un temps de disponibilité élevé. Les récompenses doivent compenser les coûts opérationnels et le risque sur le jeton. Ce modèle présente plusieurs problèmes :
- Le risque de mise en jeu peut décourager les validateurs professionnels et attirer des amateurs, compromettant ainsi la sécurité et la disponibilité du réseau.
- La dépendance des récompenses au prix du jeton met la pression sur les développeurs, qui doivent soit provoquer une forte inflation du jeton, soit adopter une économie de jeton non durable.
- Si l’adoption de l’application est faible et que le prix du jeton chute, la sécurité du réseau devient fragile, permettant à un attaquant d’acquérir une part critique à moindre coût.
Coût et temps d’équipe
Lancer une chaîne d’application implique de construire une longue liste d’infrastructures supplémentaires et de coordonner des activités avec les validateurs.
Du côté infrastructure, des nœuds RPC publics sont nécessaires pour permettre aux portefeuilles et utilisateurs d’interagir avec la chaîne. Des outils d’analyse comme des explorateurs de blocs, des nœuds d’archive, des systèmes de surveillance du réseau et des services d’information sur les validateurs sont également requis.
La liste est longue, coûteuse et consommatrice de temps ingénierie. Une partie importante de l’équipe technique sera occupée par des tâches non liées à la logique applicative. En outre, la maintenance d’une chaîne demande une planification rigoureuse et une communication constante avec les validateurs pour organiser les mises à jour ou réagir aux erreurs et aux interruptions. La gouvernance et la gestion communautaire absorbent également beaucoup de ressources.
En général, construire une chaîne d’application requiert une équipe plus grande et des coûts plus élevés, inaccessibles aux startups, surtout en phase initiale. Cela peut nuire à la capacité de l’application à s’adapter rapidement et à atteindre un ajustement produit-marché.
Absence de composable
L’un des principaux avantages du développement d’applications sous forme de contrats intelligents est la composable atomique. Les applications peuvent s’appuyer les unes sur les autres, et les utilisateurs peuvent interagir avec plusieurs protocoles dans une même transaction. Par exemple, les routeurs intelligents de DEX peuvent router une transaction via différents AMM pour obtenir le meilleur prix. Un autre exemple est le prêt flash : une transaction peut emprunter des fonds sur un protocole, réaliser un échange ou un arbitrage sur un AMM, puis rembourser le prêt – tout dans une seule transaction.
La composable atomique est une fonctionnalité unique du Web3 qui permet des comportements et des opportunités commerciales intéressants. Les chaînes d’applications manquent de cette composable, car chaque application est isolée. Les interactions entre applications nécessitent des ponts inter-chaînes ou des messages, qui prennent plusieurs blocs et ne peuvent pas être exécutés de manière atomique. Toutefois, cette absence peut inspirer de nouvelles startups pour y remédier.
Risques inter-chaînes
Un autre problème des chaînes d’applications est l’augmentation du risque lié au pontage d’actifs. En particulier, les applications DeFi doivent pontifier plusieurs actifs comme BTC, ETH et stablecoins. Le transfert inter-chaînes dégrade l’expérience utilisateur et augmente les risques. Les ponts inter-chaînes sont des cibles fréquentes d’attaques. Si un pont est compromis, les applications DeFi utilisant ces actifs se retrouvent avec des créances irrécouvrables. Ce risque est encore plus grand pour les chaînes d’applications qui peinent à attirer des validateurs réputés et bien capitalisés. Dans ces cas, elles peuvent recourir à des ponts centralisés (comme les exchanges centralisés) ou développer leurs propres ponts.
Opportunités pour les startups spécialisées dans les chaînes d’applications
Les défis de l’écosystème des chaînes d’applications ouvrent la voie à de nombreuses opportunités pour les startups. Voici quelques-unes de ces opportunités.
1. Protocoles DeFi haute performance
Les protocoles DeFi cherchant à rivaliser avec les performances Web2 doivent être implémentés comme des chaînes d’application. Les bourses à livres d’ordres centralisés (CLOB) sont les candidates idéales. dYdX a initié cette tendance, et nous anticipons que les bourses au comptant et les marchés de matières premières seront construits comme des chaînes d’application pour bénéficier de frais réduits et de faibles latences. L’élément clé ici est l’utilisation d’une pile technologique personnalisable adaptée aux besoins du protocole DeFi.
2. Moteurs de jeu pour chaînes d’applications
Dans ce domaine, StarkEx est une solution populaire. Nous espérons voir des startups développer de nouvelles architectures efficaces pour les jeux sur chaîne, capables de supporter plus de 100 000 TPS.
3. Outils de développement pour personnaliser, déployer et maintenir des sidechains et L2
Lancer une sidechain ou un rollup avec une architecture adaptée à une application donnée est une tâche complexe. Une plateforme facilitant cette tâche peut devenir un service très rentable — imaginez un Alchemy pour les chaînes d’applications.
4. Chaînes d’applications alimentées par l’IA
À l’instar des preuves ZK, l’intelligence artificielle est une technologie transformatrice et gourmande en calcul. Ainsi, les applications IA ne peuvent pas être construites directement sur chaîne. De nombreux produits Web2 réussis en IA exigent des abonnements coûteux. L’utilisation de chaînes d’applications permettrait d’ouvrir l’accès à ces applications au grand public.
5. Solutions de composable pour la communication inter-chaînes
L’absence de composable atomique dans les chaînes d’applications crée des opportunités pour des startups capables de fournir des solutions de messagerie inter-chaînes et de créer une illusion de composable. Idées possibles :
- Interfaces utilisateur exécutant en arrière-plan des fonctions inter-chaînes (transferts IBC ou messages LayerZero) pour donner l’impression que plusieurs applications fonctionnent ensemble de manière composable. Pensez à un Zapper inter-chaînes.
- Portefeuilles avec compte multi-chaînes sécurisé via le calcul multipartite (MPC), traitant naturellement les activités inter-chaînes en exécutant simultanément des transactions sur plusieurs chaînes. Exemple : arbitrage inter-chaînes.
6. Protocoles DeFi inter-chaînes
Bien que les chaînes d’applications offrent plusieurs avantages en termes de débit, elles fragmentent la liquidité, augmentent le glissement et dégradent l’expérience utilisateur. Les protocoles DeFi inter-chaînes, qui divisent automatiquement les transactions entre différentes chaînes pour un meilleur prix, offriront une meilleure UX et attireront plus d’utilisateurs.
7. Transmission sans confiance d’informations entre chaînes EVM et non-EVM
Une façon d’améliorer la composable est de créer un protocole universel de transmission sans confiance entre chaînes, capable de relier les L2 EVM, Cosmos, parachains Polkadot, etc. Un tel produit pourrait remplacer les ponts actuels et faciliter des milliards de dollars de transactions chaque année.
8. Partage de sécurité inter-chaînes
Les défis de sécurité des chaînes d’applications peuvent être atténués par des produits permettant le partage de sécurité inter-chaînes. À l’image du minage fusionné sur les chaînes PoW, nous imaginons des méthodes permettant à des chaînes PoS non liées de partager leur sécurité — par exemple, des validateurs sécurisant une chaîne d’application avec du ETH au lieu du jeton natif. Les protocoles de mise en gage liquide pourraient jouer un rôle clé dans ce système.
Implémentations des chaînes d’applications
Les chaînes d’applications peuvent être mises en œuvre de diverses façons, variant en complexité et niveau de sécurité.
Cosmos
Cosmos a été le premier écosystème à imaginer un monde de blockchains interconnectées. Sur cette base, Cosmos s’est concentré sur la standardisation et la simplification du processus de création de chaînes d’applications interconnectables. Ce travail a abouti au Cosmos SDK, un cadre modulaire pour personnaliser et développer des blockchains.
Le Cosmos SDK est conçu par défaut pour prendre en charge le mécanisme de consensus Tendermint, mais autorise aussi d’autres consensus. Plus tard, il a été enrichi par le module IBC, permettant une communication sans confiance entre chaînes basées sur Tendermint, appelées zones. L’écosystème Cosmos compte désormais plus de 45 zones, reliées par plus de 700 relais IBC. Nombre de ces zones sont des chaînes d’applications à usage unique. Osmosis, l’une des plus grandes zones Cosmos, est une chaîne d’application dédiée à un DEX AMM.
Cosmos a d’abord adopté l’idée d’une sécurité isolée : chaque zone est responsable de sa propre sécurité, avec un groupe de validateurs rémunérés en jeton natif de la zone. Cette flexibilité augmente le seuil d’entrée pour les créateurs d’applications. Cosmos met donc en œuvre un changement permettant aux petites zones de bénéficier de la sécurité du hub Cosmos via un module de sécurité inter-chaînes.
Parachains Polkadot
Comme Cosmos, Polkadot dispose d’un écosystème multi-chaînes. Les chaînes de Polkadot, appelées parachains, peuvent être lancées via le SDK Substrate.
La principale différence entre Polkadot et Cosmos est que Polkadot prend en charge dès le départ une sécurité partagée : toutes les parachains partagent la sécurité de la chaîne principale, appelée chaîne-relais.
La fonction principale de la chaîne-relais est de fournir consensus et sécurité aux parachains. Elle n’implémente donc pas de fonctionnalités de contrats intelligents.
Grâce à cette sécurité partagée, Polkadot ne peut pas autoriser le lancement libre de parachains.
À la place, les slots de parachain sont mis aux enchères auprès des développeurs souhaitant créer une chaîne personnalisée. Les candidats doivent verrouiller des DOT. À ce jour, 27 parachains ont été attribuées.
Les différentes parachains de Polkadot peuvent communiquer via le format XCM (Cross-Consensus Messaging). La mise en œuvre de XCM est en cours : elle fonctionne déjà, mais nécessite de stocker les données de message sur la chaîne-relais.
Sous-réseaux Avalanche
Les sous-réseaux Avalanche sont très similaires à ceux de Cosmos. Les développeurs peuvent lancer leur propre sous-réseau, qui peut supporter plusieurs chaînes, chacun nécessitant ses propres validateurs.
Cependant, ces validateurs doivent valider non seulement le sous-réseau dédié, mais aussi le réseau principal d’Avalanche.
Bien que cela renforce la sécurité du réseau principal, cela augmente le seuil d’entrée pour les sous-réseaux dédiés par rapport à Cosmos.
Actuellement, l’écosystème des sous-réseaux ne prend pas en charge la communication native entre sous-réseaux, qui doivent développer leurs propres ponts. L’équipe Avalanche travaille toutefois à ajouter cette fonctionnalité pour stimuler l’adoption.
L2 Ethereum
Dans Ethereum, le terme « chaîne d’application » ne décrit pas exactement les applications nécessitant un environnement dédié.
Sur Ethereum, une telle application peut être implémentée soit comme un L2 spécialisé, soit comme une sidechain. Un L2 ne peut pas être qualifié de chaîne d’application car il n’implémente pas toute la pile technique.
- Les L2 sont soit des rollups, soit des validiums, qui ne gèrent que l’exécution et l’ordonnancement des transactions.
- Pour les rollups, le consensus et la disponibilité des données sont fournis par la L1 Ethereum. Pour les validiums, la L1 assure uniquement le consensus, les données étant stockées hors chaîne. Des exemples incluent Sorare et Immutable X.
- L’autre approche, la sidechain, consiste à lancer une blockchain indépendante validée par un petit groupe de validateurs pour atteindre un haut débit.
- Un pont inter-chaînes relie la sidechain à Ethereum, généralement validé par le même groupe de validateurs. Par exemple, la sidechain Ronin d’Axie Infinity.
Comparé aux autres approches, les L2 offrent un avantage majeur : une sécurité supérieure.
Les L2 héritent de la sécurité de la L1 Ethereum via des preuves zk ou des preuves de fraude. Malgré cela, ils peuvent atteindre un très haut débit et des frais négligeables. Ces caractéristiques conviennent parfaitement aux applications de jeux.
L’inconvénient principal des L2 est une composable plus faible entre eux ou avec la L1.
Transférer rapidement des actifs entre différents rollups nécessite souvent des fournisseurs tiers comme LayerZero. Bien que certaines technologies permettent des transferts sans passer par la L1, elles imposent des délais importants, inacceptables pour les applications DeFi. C’est pourquoi les protocoles DeFi préfèrent des L2 généralistes comme Optimism et Arbitrum comme solutions d’évolutivité, plutôt que des L2 dédiés.
Un autre défi des L2 est leur complexité d’implémentation. Comparé à la simplicité relative de lancer une chaîne d’application Cosmos via le SDK, il n’existe pas encore de méthode standard pour lancer un L2 dédié sur Ethereum. Cependant, cette situation pourrait évoluer à mesure qu’Ethereum poursuit sa feuille de route centrée sur les rollups.
Conclusion
Les chaînes d’applications gagnent en popularité, mais leur évolution diffère quelque peu de la vision initiale. Les implémentations sur Cosmos, Polkadot, Avalanche et Ethereum convergent vers des modèles de sécurité partagée, avec des nuances. Avec une sécurité partagée, une chaîne d’application n’a plus vraiment besoin d’un mécanisme de consensus.
À la place, l’application peut simplement utiliser un environnement d’exécution dédié, servi par la L1 pour le consensus et la disponibilité des données. Cet environnement peut être un rollup ou une couche d’exécution indépendante suivant une approche modulaire.
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
