Qu’est-ce que l’IBC (Inter-Blockchain Communication) dans Cosmos ?

Fondamentaux du protocole IBC

1. IBC signifie Inter-Blockchain Communication, un protocole standardisé permettant un échange de données sécurisé et vérifiable entre des blockchains indépendantes.

2. Il fonctionne au niveau du consensus, en s'appuyant sur une vérification légère des clients plutôt que sur des intermédiaires de confiance ou des relais centralisés.

3. Chaque chaîne participante maintient une représentation légère de l'état d'une autre chaîne grâce à des preuves cryptographiques ancrées à ses derniers blocs finalisés.

4. Le protocole définit la messagerie par paquets avec des garanties de commande, des accusés de réception et des mécanismes de délai d'attente stricts pour garantir la fiabilité.

5. IBC ne nécessite pas de modèles de sécurité partagés : les chaînes conservent leur souveraineté tout en assurant l'interopérabilité grâce à des engagements cryptographiques.

Composants de base d'IBC

1. Les clients représentent des instantanés vérifiés des états de la chaîne distante ; Les chaînes Cosmos SDK utilisent généralement des clients légers Tendermint.

2. Les connexions établissent des canaux de communication authentifiés entre deux clients, prouvant que les deux parties sont d'accord sur les paramètres initiaux.

3. Les canaux sont des conduits multiplexés, ordonnés ou non ordonnés construits au-dessus des connexions, permettant à plusieurs protocoles de niveau application de coexister.

4. Les ports servent d'identifiants d'espace de noms pour les applications, garantissant que les paquets sont acheminés vers les modules corrects tels que les interfaces de transfert ou de jalonnement.

5. Les paquets transportent des charges utiles sérialisées avec des numéros de séquence, des identifiants de port/canal source et de destination et des contraintes de délai d'attente .

Transferts de jetons via ICS-20

1. ICS-20 est la norme canonique de transfert de jetons construite sur IBC, définissant la manière dont les actifs fongibles se déplacent à travers les chaînes.

2. Lors du lancement d'un transfert, l'expéditeur verrouille les jetons dans un compte séquestre spécifique au module sur la chaîne source.

3. Un paquet contenant les métadonnées de la dénomination, le montant et l'adresse du destinataire est envoyé via un canal IBC vers la chaîne de destination.

4. Après réception et validation réussies, la chaîne de destination crée des représentations enveloppées ou natives basées sur la configuration.

5. Aucun opérateur de pont central ne contrôle les fonds – la garde reste décentralisée et appliquée par une logique en chaîne et des preuves cryptographiques .

Modèle de sécurité et hypothèses de confiance

1. IBC suppose que chaque chaîne produit des blocs valides, finaux et non réorganisés selon ses propres règles de consensus.

2. Les clients légers doivent être mis à jour régulièrement pour refléter les nouveaux en-têtes de bloc ; les clients obsolètes risquent d’accepter des transitions d’état invalides.

3. Les nœuds relais transmettent les paquets mais ne peuvent pas modifier leur contenu – toutes les validations critiques se produisent en chaîne à l'aide des preuves Merkle.

4. La compromission d’une seule chaîne ne compromet pas automatiquement les autres, bien qu’un comportement malveillant puisse affecter l’intégrité des actifs entre les chaînes.

5. La limite de confiance se situe au niveau du client léger : si un client effectue une vérification incorrecte, l'ensemble de la session IBC devient vulnérable .

Foire aux questions

T1. IBC exige-t-il que toutes les chaînes connectées utilisent le consensus Tendermint ? Bien que les chaînes Cosmos SDK utilisent couramment Tendermint, IBC prend en charge tout algorithme de consensus pour lequel une implémentation client légère correcte existe, y compris les clients compatibles Ethereum en cours de développement actif.

Q2. IBC peut-il prendre en charge les appels de contrats intelligents entre chaînes ? Native IBC n'exécute pas de code arbitraire sur les chaînes. Cependant, les protocoles de couche application tels que ICS-27 (Interchain Accounts) permettent le contrôle à distance des comptes sur les chaînes de destination via l'exécution de paquets signés.

Q3. Comment les frais sont-ils gérés lors des transferts IBC ? Les frais sont payés dans le jeton natif de la chaîne source pour la soumission des paquets et dans le jeton de la chaîne de destination pour le traitement de l'accusé de réception. Les relayeurs peuvent facturer des frais de service supplémentaires libellés dans l’un ou l’autre actif.

Q4. Existe-t-il un registre mondial IBC ou un organe de gouvernance ? Il n'existe pas de registre centralisé. Les chaînes décident indépendamment des connexions à établir. La gouvernance se produit au niveau de la chaîne : chaque réseau configure ses propres modules compatibles IBC et ses propres chemins de mise à niveau.