Qu’est-ce que Cosmos IBC ? Une introduction à l’Inter-Blockchain Communication
Qu’est-ce que Cosmos IBC ?
Cosmos IBC est un protocole qui permet à des blockchains distinctes d’échanger des messages de manière sécurisée. IBC signifie Inter-Blockchain Communication et est né au sein de l’écosystème Cosmos. C’est pourquoi vous entendrez souvent le nom Cosmos IBC, mais sa conception n’est pas destinée uniquement aux blockchains Cosmos SDK.
En termes simples, IBC est un ensemble commun de règles pour les blockchains qui souhaitent communiquer entre elles. Le protocole définit comment un message est envoyé, comment la blockchain destinataire vérifie que le message est authentique et dans quel ordre les messages sont traités. Vous pouvez ainsi considérer IBC comme une sorte de standard de communication pour les blockchains, comparable à la manière dont l’EVM fournit au sein d’Ethereum un environnement standard pour exécuter des smart contracts.
IBC n’est donc ni une blockchain, ni un hub central, ni seulement un bridge pour les tokens. Un transfert de token est certes une application connue, mais IBC peut aussi transmettre d’autres types de messages. Pensez par exemple à des instructions de gestion de compte sur une autre blockchain.
Point important à retenir : le contenu d’un message IBC est déterminé par l’application qui l’envoie et le reçoit. IBC assure surtout le transport et les vérifications associées. Vous pouvez le voir comme un système de livraison fiable, tandis que l’application détermine ce qu’il y a dans le colis et ce qu’il faut en faire.
La conception d’origine s’appelle IBC v1. Dans ce modèle, deux blockchains créent d’abord une connection, puis des channels, avant que les applications puissent échanger des messages. IBC v2 est la version la plus récente de cette conception et vise à simplifier le processus grâce à une communication directe entre clients. Les standards de la v2 sont encore au stade Draft.
À retenir
- IBC signifie Inter-Blockchain Communication et permet à des blockchains distinctes d’échanger des messages.
- Cosmos IBC n’est ni une blockchain ni un hub central, mais un protocole d’interopérabilité.
- IBC peut servir à bien plus que de simples transferts de tokens.
- IBC v1 fonctionne avec des connections et des channels entre deux blockchains.
- IBC v2 est l’itération la plus récente, mais ses spécifications sont encore indiquées comme Draft.
Comment fonctionne Cosmos IBC ?
Cosmos IBC fonctionne parce que les deux blockchains se vérifient mutuellement à l’aide d’un lightclient on-chain propre à chacune. Un lightclient est un petit composant sur une blockchain qui peut suivre des informations provenant d’une autre blockchain et vérifier des preuves cryptographiques.
Cela peut sembler technique, mais l’idée est assez logique. La blockchain A n’a pas à croire aveuglément ce que lui dit la blockchain B ou un relayer. La blockchain A conserve des informations qui lui permettent de vérifier si un message figure bien dans l’état de la blockchain B.
Avec IBC v1, deux blockchains mettent d’abord en place une connection. Il s’agit d’une liaison contrôlée qui permet aux deux blockchains de définir avec quel réseau elles communiquent.
La mise en place d’une telle connection se déroule en quatre étapes. ConnectionOpenInit lance la connexion, ConnectionOpenTry permet à l’autre blockchain de répondre, ConnectionOpenAck confirme que les données sont correctes et ConnectionOpenConfirm finalise la connexion. Ainsi, les deux blockchains vérifient étape par étape qu’elles sont reliées au bon interlocuteur.
Une même connection peut prendre en charge plusieurs channels. Un channel est un canal de communication spécifique entre deux applications sur différentes blockchains. Les applications se rattachent alors à un port unique. Vous pouvez voir un port comme le point de contact fixe d’une application, et un channel comme l’itinéraire convenu vers l’application située de l’autre côté.
Comment un message passe-t-il ensuite de A à B ?
-
L’application crée un packet L’application émettrice crée un packet. Il s’agit, en termes simples, d’un petit paquet de données, comme une instruction pour envoyer des tokens.
-
La blockchain source enregistre un commitment La blockchain sur laquelle le packet part inscrit un packet commitment dans son propre state. Il s’agit d’une preuve cryptographique indiquant que le packet y a été enregistré.
-
Un relayer transporte le packet et la preuve Un relayer lit le packet et la preuve associée, puis les soumet à la blockchain destinataire.
-
La blockchain destinataire vérifie l’ensemble Le lightclient vérifie la preuve cryptographique. Si la preuve est correcte, l’application destinataire peut traiter le packet.
-
Une acknowledgement revient généralement Après le traitement, l’application destinataire écrit souvent une acknowledgement. Il s’agit d’un message de réception ou de résultat. Un relayer peut renvoyer cette preuve vers la blockchain où le packet a commencé.
Les packets ont aussi un time-out. Si un packet n’arrive pas à temps, la blockchain source peut lancer le traitement du time-out, mais uniquement avec une preuve issue du state de la blockchain de destination. Le simple fait de ne pas recevoir de réponse ne suffit donc pas pour annuler un transfert sans autre forme de procédure.
Exemple : Supposons que vous envoyiez des tokens de la blockchain A vers la blockchain B via IBC. La blockchain A enregistre que le message a été envoyé. Ensuite, un relayer transporte le message avec la preuve vers la blockchain B. Dès que la blockchain B a vérifié que la preuve est correcte, le transfert est traité et une confirmation peut être renvoyée vers la blockchain A.
IBC v2 vise à simplifier cette architecture. Au lieu de plusieurs étapes techniques pour relier deux blockchains, la v2 permet d’envoyer les messages plus directement entre les deux réseaux. Cette approche n’est pas encore la norme partout, car les principaux standards d’IBC v2 sont encore en cours de développement.
Quel rôle jouent les relayers dans Cosmos IBC ?
Les relayers sont les livreurs des messages IBC entre blockchains. Ils surveillent les blockchains et transmettent les messages vers l’autre blockchain.
En effet, la blockchain A et la blockchain B ne s’envoient pas directement les messages IBC. Un relayer voit par exemple qu’un nouveau message est prêt sur la blockchain A et le transporte, avec la preuve que le message est authentique, vers la blockchain B.
Le relayer ne décide pas lui-même si un message est valide. C’est la blockchain B qui effectue cette vérification. La blockchain B n’a donc pas besoin de faire confiance au relayer aveuglément.
Les relayers ne se contentent pas de transmettre les nouveaux messages. Ils peuvent aussi renvoyer une confirmation vers la blockchain d’origine. Si un message n’est pas traité à temps, ils peuvent également signaler que le délai est expiré.
En principe, n’importe qui peut agir comme relayer. IBC ne prévoit pas d’acteur central obligé de transmettre tous les messages. Un relayer peut aussi choisir de ne prendre en charge que certains types de messages ou certaines connections.
Il faut toutefois au moins un relayer actif pour continuer à transmettre les messages. Un relayer ne peut normalement pas falsifier un message valide, mais s’il n’y a aucun relayer actif, un message peut rester bloqué.
IBC ne dispose pas d’un système fixe permettant de rémunérer systématiquement les relayers. La manière dont ils sont payés peut donc varier selon la blockchain ou l’application.
Quelles blockchains peuvent utiliser Cosmos IBC ?
En principe, toute blockchain peut utiliser IBC, à condition qu’elle prenne en charge les composants nécessaires pour envoyer et vérifier les messages. Les blockchains n’ont pas besoin d’utiliser la même technologie ni le même mécanisme de consensus.
Pour pouvoir vérifier une autre blockchain, IBC utilise ce que l’on appelle un light client. Le light client nécessaire dépend de la blockchain avec laquelle la connexion est établie. Les blockchains Cosmos utilisent par exemple souvent un light client pour CometBFT, mais il en existe aussi d’autres types pour d’autres usages.
Le fait qu’une blockchain prenne en charge IBC ne signifie pas automatiquement qu’elle peut communiquer directement avec n’importe quelle autre blockchain IBC. Les deux blockchains doivent pouvoir se vérifier techniquement l’une l’autre et il doit exister un relayer pour transmettre les messages entre les deux réseaux. Avec IBC v1, il faut en outre d’abord établir une connection entre les deux blockchains.
La prise en charge d’IBC ne signifie pas non plus que toutes les fonctions sont automatiquement disponibles. Deux blockchains peuvent par exemple être reliées entre elles, alors que les transferts de tokens, les transferts de NFT ou d’autres fonctions IBC ne sont pas encore activés sur cette connection.
La version Go d’IBC est utilisée par de nombreuses blockchains au sein de l’écosystème IBC. Il existe également des solutions pour Solidity/EVM et Solana, entre autres, même si le fonctionnement technique et la sécurité peuvent varier selon l’intégration.
À quoi sert Cosmos IBC ?
Cosmos IBC sert à transmettre toutes sortes de messages cross-chain, pas seulement des tokens. Les applications de chaque côté déterminent elles-mêmes comment elles structurent et traitent les données dans un packet.
L’usage le plus connu est ICS-20, le standard pour les transferts de fungible tokens. Fungible signifie que chaque unité est interchangeable avec une autre, comme un token qui peut être échangé contre un autre token du même type.
Dans un tel transfert, l’itinéraire et l’origine du token restent visibles sous la forme d’une denomination trace. Le logiciel peut ainsi retrouver l’origine d’une représentation IBC d’un token et le chemin qu’elle a emprunté.
IBC peut aussi être utilisé pour les Interchain Accounts via ICS-27. Cela permet à une blockchain contrôleur d’envoyer des instructions de transaction à un compte sur une blockchain hôte. La blockchain hôte vérifie les instructions et n’exécute que ce qui est autorisé.
Il existe également ICS-721 pour les transferts de NFT. Lorsqu’un NFT quitte sa blockchain d’origine, il y est placé en escrow. Sur la blockchain destinataire, un voucher correspondant est ensuite créé. Si le NFT revient, le processus inverse s’applique.
Il existe aussi un standard pour les cross-chain queries, ICS-31. Une blockchain peut alors demander des informations à une autre blockchain, et un relayer renvoie la réponse avec la preuve. Ce standard est encore indiqué comme Draft et n’est donc pas automatiquement disponible partout.
Enfin, il y a Interchain Security. Cela permet aux blockchains Cosmos de se prêter la sécurité proof-of-stake. Il s’agit d’une application IBC distincte et non d’un composant standard de chaque connection IBC.
Quels sont les avantages de Cosmos IBC ?
Le principal avantage de Cosmos IBC est que les blockchains peuvent communiquer entre elles sans renoncer à leurs propres règles ni à leur mécanisme de consensus. Chaque blockchain reste donc autonome, tout en pouvant échanger des messages avec d’autres blockchains.
Un autre point fort est la vérification. La blockchain destinataire contrôle les packet commitments et les acknowledgements à l’aide de preuves cryptographiques via son lightclient. Le relayer fournit les données, mais n’est pas la partie à laquelle vous devez faire confiance pour en garantir la validité.
Par ailleurs, IBC est modulaire. La même couche de base peut être utilisée pour différentes applications, telles que :
- les transferts de fungible tokens ;
- les transferts de NFT ;
- les transactions cross-chain via Interchain Accounts ;
- d’autres applications qui souhaitent transmettre des messages entre blockchains.
IBC ne repose sur aucun hub central obligatoire ni sur un opérateur de relais exclusif. Cela rend possible le permissionless relaying : différentes parties peuvent faire fonctionner des relayers et traiter des packets.
Les channels offrent aussi une certaine souplesse dans le traitement des messages. Un channel peut fonctionner de manière ordonnée, auquel cas les packets doivent arriver dans un ordre précis, ou de manière non ordonnée. Avec les acknowledgements et les time-outs, les applications disposent en outre d’une méthode claire pour traiter un packet reçu, échoué ou expiré.
Une connection peut prendre en charge plusieurs channels. Ainsi, différentes applications entre les mêmes deux blockchains n’ont pas besoin de créer à chaque fois une connection complète.
Quels sont les inconvénients de Cosmos IBC ?
Cosmos IBC présente aussi des inconvénients, surtout en matière de disponibilité, de complexité technique et de sécurité des blockchains connectées. IBC rend la communication cross-chain possible, mais ajoute aussi des étapes supplémentaires par rapport à une transaction locale classique.
La première dépendance concerne les relayers. Sans au moins un relayer correct et actif, les packets, les acknowledgements et les mises à jour des clients peuvent subir des retards ou rester bloqués. Cela ne signifie pas automatiquement que quelqu’un peut voler des tokens, mais votre transfert peut ne pas être finalisé.
La sécurité d’une connection IBC dépend aussi des light clients et de la sécurité du consensus des deux blockchains. Si un groupe de validateurs malveillants dépasse le threshold de confiance d’un light client, la connection peut devenir dangereuse.
Un light client peut également devenir inutilisable. Par exemple lorsque la blockchain suivie cesse ses activités, lorsque les mises à jour tardent trop ou lorsque le client se fige après la détection d’un comportement malveillant. Dans la logique de base d’IBC et d’ICS-20, les actifs d’un channel touché peuvent alors rester bloqués de manière permanente s’il n’existe aucun mécanisme de récupération.
Le traitement cross-chain prend aussi plus de temps et implique souvent davantage de frais de transaction. Un flux normal peut consister à envoyer un packet, le recevoir sur l’autre blockchain, renvoyer une acknowledgement et parfois lancer une procédure de time-out. Cela représente plusieurs actions sur deux blockchains différentes.
L’architecture technique n’est pas simple. Les light clients, les connections, les channels, les modules applicatifs et les relayers doivent fonctionner ensemble correctement. Une erreur de configuration, d’intégration ou de maintenance peut provoquer des problèmes.
Les time-outs sont également plus complexes qu’il n’y paraît. En cas de partition complète du réseau, la blockchain source ne peut pas conclure, sur la seule base de l’absence de réponse, que le packet n’a jamais été exécuté. La blockchain de destination doit être accessible pour fournir la preuve nécessaire.
Dans un environnement de test privé, on a également observé notamment des retards dans les confirmations, des goulots d’étranglement RPC et des problèmes de concurrence chez les relayers. Ces résultats dépendent de l’environnement et de l’implémentation utilisés, mais ils montrent que le relaying peut rencontrer des limites techniques en pratique.
En résumé
Cosmos IBC est un protocole qui permet à des blockchains autonomes d’échanger des messages de manière contrôlée. Il ne s’agit donc pas seulement d’envoyer des tokens : IBC peut aussi servir aux transferts de NFT, aux Interchain Accounts et à d’autres applications cross-chain.
L’idée centrale est que les blockchains peuvent se vérifier mutuellement grâce à des light clients et à des preuves cryptographiques. Les relayers transportent les messages dans les deux sens, mais ne décident pas eux-mêmes si un message est valide. En même temps, des relayers actifs, une bonne configuration et la sécurité des deux blockchains restent essentiels.
Pour la crypto, IBC permet de faire mieux coopérer les applications sur différentes blockchains. Ce n’est pas une solution magique sans risque, mais c’est une brique importante pour un univers blockchain plus connecté.
