Pourquoi Cosmos L1 peut-il créer la prochaine application phare ?
TechFlow SélectionTechFlow Sélection
Pourquoi Cosmos L1 peut-il créer la prochaine application phare ?
La théorie derrière l'essor des chaînes dédiées à des applications spécifiques.
Dédié à des analyses Web3 approfondiesRédaction : RainandCoffee
Traduction : TechFlow intern
Ces dernières semaines, l'écosystème Cosmos a connu un renouveau, les applications et fondateurs décidant soit de construire leur propre blockchain dédiée (une couche 1 sur Cosmos), soit exprimant un intérêt pour ce faire. Ce phénomène intervient après la disparition de l'écosystème Terra, qui a également affecté l'ensemble de l'écosystème IBC.
Toutefois, il convient de noter que le système global s'est techniquement très bien maintenu, malgré une volatilité importante des volumes de transactions. Il est capable de traiter via IBC des transferts d'actifs et de messages entre chaînes, qu'ils soient internes ou externes, ainsi que, au sein des chaînes elles-mêmes, grâce au Cosmos SDK, à Tendermint, à ABCI et à une machine virtuelle (par exemple EVM).
Dans cet article, nous souhaitons expliquer la théorie sous-jacente à l’essor des blockchains dédiées, et pourquoi la souveraineté, la composable et l’interopérabilité qu’elles offrent sont cruciales pour développer la prochaine « application tueur » et écosystème dans le prochain cycle.
Avant d’approfondir l’analyse du document lui-même, nous allons brièvement présenter de manière accessible certaines technologies uniques de l’écosystème Cosmos. L’architecture globale se présente comme suit :
Cosmos SDK
Le Cosmos SDK est un ensemble d'outils modulaires permettant aux développeurs de blockchains de concevoir leur logique applicative indépendamment de toute machine virtuelle. Conçu pour se connecter à Tendermint via ABCI, le Cosmos SDK agit non seulement comme un cadre pour créer des blockchains spécifiques à une application, mais offre aussi diverses options de personnalisation telles que des mécanismes de gouvernance, de transaction et de mise en jeu indépendants du protocole. Le SDK prend en charge la majorité des tâches nécessaires au niveau de la logique applicative, ce qui signifie que les développeurs n'ont pas besoin de tout reconstruire depuis zéro. Il utilise un routeur pour traiter les transactions reçues du moteur de consensus Tendermint, transmettant les messages accompagnés des modifications d'état aux modules de traitement appropriés.
ABCI
L’ABCI (Application Blockchain Interface) est l’interface reliant la partie applicative de la blockchain au moteur de réplication d’état de Tendermint, qui assure les fonctions de consensus et de réseau. L’ABCI permet une séparation claire de la pile blockchain, rendant la partie applicative indépendante de toute machine virtuelle — par conséquent, n’importe quelle machine virtuelle ou environnement d’exécution peut être utilisé pour la couche applicative. Des exemples incluent Junowasm, Cosmwasm, le JavaScript durci d’Agoric, voire une version de Cosmwasm utilisant des TEE (environnements d'exécution sécurisés) comme sur Secret. Tendermint crée trois connexions ABCI vers la partie applicative : validation des transactions lors de la diffusion dans le mempool, liaison entre l’application et le moteur de consensus, et capacité à proposer des blocs ainsi qu’à interroger l’état de l’application.
Tendermint
Tendermint Core gère les couches de consensus et de réseau des chaînes dans l’écosystème Cosmos. La couche de consensus garantit la validité et l’ordre des transactions par un processus algorithmique de consensus entre participants au réseau, tandis que la couche réseau facilite la communication point à point entre les nœuds du système, permettant aux applications tierces et aux nœuds de communiquer avec la couche de consensus.
Tendermint utilise un modèle de consensus BFT (Byzantine Fault Tolerant) et implémente une finalité instantanée. Le processus BFT traverse trois étapes avant la validation finale d’un bloc proposé :
-
Phase de proposition, où un bloc est désigné à une hauteur spécifique ;
-
Phase de pré-vote, où 2/3 des validateurs effectuent un pré-vote pour le bloc proposé ;
-
Phase de pré-validation, où 2/3 des validateurs pré-valident le bloc proposé.
IBC
IBC (Inter-Blockchain Communication) est un protocole de transmission d'informations entre blockchains homogènes. Cela signifie qu’il connecte des chaînes partageant des fonctionnalités similaires — ici, celles bénéficiant de la finalité instantanée fournie par l’algorithme de consensus Tendermint et disposant de capacités de client léger.Le fonctionnement d’IBC repose sur une proposition de gouvernance lancée sur la chaîne de destination par deux chaînes souhaitant se connecter. Cette connexion s’effectue généralement d’abord via le Cosmos Hub ou Osmosis (Osmosis pouvant actuellement connecter 45 chaînes, contre 40 pour Cosmos). Un protocole existe donc au niveau du protocole lui-même, éliminant le besoin de ponts inter-chaînes tiers externes.
Les deux chaînes doivent ensuite déployer un client léger sur l’autre chaîne afin de vérifier cryptographiquement l’état du consensus mutuel, et utiliser un relais pour transmettre les informations entre ces clients légers. Le relais constitue une exigence d’efficacité — la capacité d’échanger des informations entre nœuds et de parvenir à un consensus réussi. Examinons comment cela fonctionne en pratique :
Cela implique que l’hypothèse de confiance repose uniquement sur les validateurs des deux chaînes connectées, ce qui réduit considérablement les hypothèses de confiance comparé à d'autres types de ponts ou protocoles de messagerie. Par exemple, dans l’écosystème Polkadot avec XCMP, l’hypothèse de confiance porte uniquement sur la chaîne-relais (Polkadot).
Pour illustrer la compatibilité, l’étendue et le nombre de chaînes connectées par IBC dans l’écosystème Cosmos, examinons l’échelle actuelle des connexions en temps réel :
ICS
ICS signifie Interchain Standard, et définit les paramètres des transactions entre chaînes utilisant IBC. Les ICS constituent essentiellement des spécifications modulaires pour les transactions IBC : deux chaînes utilisant IBC doivent partager la même norme ICS.
L’un des ICS les plus intéressants et uniques est l’ICS-27, également appelé comptes inter-chaînes.
ICS-27
Les comptes inter-chaînes permettent la composable, c’est-à-dire l’interopérabilité. Ils autorisent non seulement l’échange de données, mais aussi l’écriture d’états depuis un contrat intelligent sur une chaîne vers une autre chaîne. Cela signifie que, tant que le point de terminaison de la transaction est spécifié, les utilisateurs pourront exploiter une seule interface sur la chaîne source, sans avoir à naviguer entre plusieurs interfaces lors de transferts d’actifs ou de messages. Une chaîne prenant en charge l’ICS-27 peut créer des comptes sur d’autres chaînes compatibles ICS-27 et les contrôler via des transactions IBC. Ces comptes inter-chaînes conservent toutes les fonctionnalités d’un compte standard, mais sont opérés par une chaîne distincte ou un utilisateur final via IBC, permettant ainsi au propriétaire sur la chaîne source de garder un contrôle total sur tout compte inter-chaîne enregistré sur la chaîne cible.
Les procédures post-transaction IBC suivent les spécifications ICS que chaque chaîne doit respecter. Cela permet de transformer des transactions initialement liées à une application spécifique en transactions indépendantes de toute application — autrement dit, cela réalise une véritable composable à travers un ensemble de réseaux différents.
Sécurité inter-chaînes
La sécurité inter-chaînes permet à une chaîne ou hub de produire des blocs pour d'autres chaînes. Les validateurs exécutent deux (ou plus) nœuds, un sur chaque chaîne, mais n'ont besoin de staker leurs jetons natifs que sur la chaîne principale. Cela est rendu possible par la validation inter-chaînes, un protocole au niveau IBC. Les chaînes filles communiquent avec la chaîne principale via IBC pour suivre quels validateurs participent à la sécurité inter-chaînes. De cette manière, la sécurité issue de la valeur verrouillée sur la chaîne principale est partagée avec les chaînes filles. Ainsi, les chaînes consommatrices/filles bénéficient de la protection de sécurité de la chaîne principale sans avoir à constituer leur propre ensemble de validateurs. Cela permet aux applications à faible intensité de capital de lancer facilement leur propre chaîne tout en profitant du haut niveau de sécurité assuré par les validateurs existants.
La chaîne principale est responsable de la génération de blocs pour un groupe de chaînes filles, et les validateurs reçoivent des récompenses de mise en jeu provenant des chaînes qu’ils valident. Le slashing contribue à dissuader les comportements malveillants des validateurs.
Conclusion
Les blockchains dédiées à une application réalisent ce que nous appelons un « stockage » de l’espace-bloc. Si vous voyez la pile blockchain comme une chaîne logistique, alors l’espace-bloc des différentes parties de la pile est techniquement « acheté » par les applications hébergées sur la chaîne/couche respective. Cela signifie qu’il doit partager cet espace-bloc avec d’innombrables autres applications, toutes payant des frais de gaz, ce qui entraîne une forte congestion et une concurrence accrue, poussant ainsi les frais à la hausse.
Cette flambée des frais due à la surcharge d’une chaîne monolithique fortement congestionnée par des milliers d’applications finit par être reportée sur les utilisateurs, qui doivent supporter des coûts élevés. Sur une blockchain dédiée à une application, celle-ci peut mieux contrôler les frais payés par les utilisateurs finaux et les maintenir à un niveau constant — un bon exemple en est Osmosis.
Comme une telle application ne dépend pas d'une chaîne X ou Y comme entrepôt, elle évite le risque de payer des frais moyens élevés, similaire au risque de stock pour un magasin. Cela signifie que l’application elle-même, ainsi que sa communauté, peuvent participer activement à la gestion du risque de stock. Cela conduit à une meilleure efficacité dans la tarification des ressources, puis, en retour, à un meilleur modèle économique pour l’application.
Étant donné que l’application est propriétaire de la chaîne sur laquelle elle réside, elle peut autogérer sa structure tarifaire : vous n’êtes plus soumis aux conditions de la chaîne hôte, vous décidez vous-même du coût de chaque ressource sur votre propre chaîne.
En outre, la flexibilité permise par la pile technique sous-jacente permet d’optimiser la couche applicative, tout en maintenant une composable entre chaînes au sein de l’écosystème plus large, grâce à son système natif de messagerie inter-chaînes — une composable qui n’exige aucune confiance envers un tiers.
Avant l’avènement de Cosmos, un fossé net existait entre les applications et l’infrastructure (la chaîne). Les blockchains dédiées avec IBC brisent cette barrière, permettant aux applications de devenir une infrastructure connectée et composable.
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
