La naissance de Bitcoin a conduit à une explosion cambrienne de blockchains avec différentes décisions de conception et cas d'utilisation. Bien que ces registres distribués aient des objectifs différents, ils existaient (et existent toujours dans une certaine mesure) en tant que silos avec une interaction significative limitée.

Semblable à Internet qui permet à différents types d'ordinateurs dans différentes parties du monde de communiquer entre eux, une technologie similaire qui agit comme le tissu conjonctif entre les chaînes de blocs est nécessaire pour une véritable accumulation de valeur. Le protocole Inter-Blockchain Communication (IBC) vise à servir cet objectif.

IBC est un protocole d'interopérabilité universel qui permet à deux chaînes de blocs différentes de communiquer entre elles. IBC garantit une communication fiable , ordonnée et authentifiée .

L'une des propriétés les plus importantes de l'IBC est peut-être la minimisation de la confiance. Dans les blockchains, la propriété de minimisation de la confiance est intrinsèquement liée à la sécurité. Aucun système distribué n'est entièrement « sans confiance ». Par conséquent, la question de la sécurité se résume à qui ou quoi est digne de confiance, et comment cette confiance peut-elle être violée, c'est-à-dire, que faut-il pour que l'entité de confiance soit corrompue ?

En ce sens, et contrairement à la plupart des solutions de pontage, IBC ne fait appel à aucun tiers de confiance. Cela signifie que si vous faites confiance à deux chaînes particulières pour utiliser les fonctions qu'elles fournissent (et par défaut leurs mécanismes de consensus), aucune hypothèse de confiance supplémentaire n'est requise lors de l'utilisation d'IBC pour interagir entre lesdites chaînes.

IBC est également plus qu'un simple pont qui facilite les transferts de jetons. Il s'agit d'un protocole de transmission de messages à usage général . Cela signifie que toute forme de données peut être communiquée via IBC.

Comment fonctionne l'IBC ?

Afin de comprendre le fonctionnement d'IBC, il est important de séparer les deux couches différentes d'IBC - 1) la couche de transport et 2) la couche d'application.

Couche Transport

Les messages communiqués sur IBC sont transportés dans des paquets de données . Et la couche de transport est responsable du transport , de l' authentification et de la commande de ces paquets de données.

La couche de transport ne spécifie rien sur ce que doivent être les données dans les paquets ni sur la manière dont elles doivent être interprétées par une chaîne de réception. Du point de vue de la couche transport, les informations contenues dans les paquets de données ne sont que des octets aléatoires.

Les composants clés de la couche de transport sont les clients légers, les relais, les connexions et les canaux.

Un client léger est une représentation légère d'une blockchain. Contrairement à un nœud complet , les clients légers ne stockent pas l'intégralité de l'historique de tous les messages contenus dans une blockchain. Ils n'exécutent pas non plus de transactions. Les clients légers sont plutôt conçus pour se connecter à un nœud complet et vérifier les en-têtes de bloc (un résumé des données contenues dans un bloc). Cela permet aux clients légers d'être efficaces en termes de stockage et de calcul.

Deux blockchains indépendantes A et B interagissant sur IBC ont des clients légers de la chaîne de contrepartie. Cela signifie que A a un client léger sur sa blockchain qui agit comme une représentation légère de la blockchain de B. Lorsque A veut communiquer un certain message 'X' avec B , il envoie l'en-tête du bloc dans lequel ce message existe, ainsi qu'une preuve d'engagement de ce message à B . La preuve d'engagement sert à vérifier la présence ou l'absence d'un message particulier sur A . En utilisant l'en-tête de bloc et la preuve, B vérifie cryptographiquement queA a bien exécuté X . C'est cette utilisation de clients légers dans IBC qui permet aux blockchains d'échanger des messages entre elles sans avoir besoin d'un tiers de confiance.

Mais A et B n'envoient pas directement ces messages/paquets de données entre eux. Au lieu de cela, lorsque A souhaite envoyer un message à B , il valide ou stocke un hachage d'un paquet de données contenant le message dans sa machine d'état . Les relais , qui sont des processus hors chaîne, surveillent constamment ces messages. Lorsqu'ils voient que A a validé un message destiné à B dans sa machine d'état, ils récupèrent simplement ce message et le transmettent à B . Notez que les relais sont sans autorisation et peuvent donc être exécutés par n'importe qui.

Les connexions sont chargées de connecter les clients légers sur deux chaînes différentes. Et les canaux sont des conduits de transfert de paquets entre modules sur ces différentes chaînes. Par conséquent, alors que les connexions sont spécifiques à la chaîne, les canaux sont spécifiques au module. Chaque extrémité de canal a un ID de canal unique (et un ID de port) qui est utilisé pour acheminer avec précision les paquets entre deux modules.

Couche d'application

La couche d'application est ce avec quoi les utilisateurs finaux interagissent. Il se compose de diverses applications qui utilisent la couche de transport pour s'appuyer sur le dessus. La couche transport ne spécifie pas comment les paquets de données doivent être interprétés. Ce rôle est joué par la couche application.

IBC prend en charge une variété d'applications telles que les transferts de jetons fongibles/non fongibles, les flux oracle inter-chaînes, les comptes interchaînes, les requêtes interchaînes, le middleware payant (pour inciter les relayeurs), etc.

Par exemple, l'application de niveau IBC pour les transferts de jetons - appelée Interchain Standard 20 (ICS 20) - spécifie comment les paquets de données doivent être structurés et comment ils doivent être interprétés par les chaînes de réception. Dans le cas des transferts de jetons fongibles, les paquets de données contiennent des informations concernant l'expéditeur, le destinataire, le montant et la dénomination (denom IBC). Le champ denom trace le chemin parcouru par un jeton particulier pour atteindre une certaine chaîne. La logique concernant la façon dont les paquets doivent être traités est également spécifiée par ICS 20.

Une analogie simple qui peut être utile pour comprendre IBC est celle du système de distribution du courrier. Lorsque vous envoyez une lettre à quelqu'un, vous l'expédiez par l'intermédiaire d'un service postal qui récupère auprès de vous l'enveloppe contenant la lettre et la dépose dans la boîte aux lettres du destinataire. Le destinataire ouvre alors ladite enveloppe et lit votre lettre. La couche de transport d'IBC peut être considérée comme le service postal. Le service postal ne vous dit pas quel doit être le contenu de la lettre, ni comment le destinataire doit interpréter votre message.

Ils ne savent pas non plus quel est le contenu de l'enveloppe. Il effectue uniquement l'action de collecter l'enveloppe du point A et de l'envoyer au point B. L'enveloppe elle-même peut être considérée comme des paquets IBC qui sont envoyés d'une chaîne à une autre. Et sur cette enveloppe, vous préciseriez l'adresse du destinataire. Ceci est similaire à la façon dont les paquets IBC contiennent des informations concernant qui a envoyé le paquet (spécifié par l'ID de canal) et à qui il est destiné (spécifié par l'ID de canal de contrepartie). En fin de compte, c'est le destinataire (application) qui est responsable de l'ouverture de l'enveloppe (paquet de données) et de l'interprétation du contenu de la lettre.

A quoi peut servir IBC ?

Outre les transferts de jetons fongibles, deux autres applications de niveau IBC incluent Interchain Accounts et Interchain Security .

Les comptes interchaînes facilitent l'interaction chaîne à chaîne tout en restant sur une seule interface. Cela signifie effectivement que toute action telle que les transferts, le jalonnement ou le vote sur des propositions de gouvernance qui peuvent être effectuées sur B (appelée la « chaîne hôte ») peut être effectuée à partir de A (appelée la « chaîne de contrôleur »). Les comptes Interchain augmentent considérablement la composabilité au sein de l'Interchain en améliorant l'expérience utilisateur.

Interchain Security est la version de la sécurité partagée de Cosmos Ecosystem. Il permet à une blockchain de louer la sécurité d'une autre chaîne de manière totalement opt-in. Ceci est particulièrement utile pour les nouvelles chaînes qui peuvent choisir d'exploiter la sécurité offerte par un réseau déjà établi tel que Cosmos Hub. Interchain Security supprime le besoin pour les chaînes d'amorcer leur propre ensemble de validateurs.

La portée des applications qui peuvent être exécutées en utilisant IBC comme primitive de base ne cesse de croître. Les transferts NFT entre chaînes et les requêtes interchaînes (où une chaîne peut lire l'état d'une autre chaîne) sont actuellement en cours de développement et seront bientôt prêts pour la production.

Quel problème IBC résout-il ?

En une phrase, IBC résout le problème des blockchains existant sous forme de silos avec une interaction limitée. L'interopérabilité entre les blockchains est nécessaire pour une accumulation de valeur maximale.

Chaque blockchain répond à un ou plusieurs cas d'utilisation spécialisés. Si ces cas d'utilisation ne peuvent pas être exploités sur plusieurs chaînes de blocs, cela handicape gravement leur utilité. La percée qu'Internet a apportée est que l'information peut facilement circuler facilement dans différentes parties du monde. De même, l'utilité de différentes chaînes de blocs doit être librement accessible sur plusieurs plates-formes.

Par exemple, les utilisateurs peuvent vouloir utiliser des stablecoins d'une blockchain, pour générer un rendement via un pool de liquidités (LP) sur un échange décentralisé (DEX) qui existe sur une autre blockchain. Ou ils peuvent vouloir tirer parti des propriétés de préservation de la vie privée fournies par une autre blockchain. L'interopérabilité entre les chaînes est nécessaire pour réaliser ces cas d'utilisation et plus encore.

IBC résout non seulement le problème de l'interopérabilité, mais il le fait de manière à minimiser la confiance, sécurisée, extensible et à usage général.

Comment puis-je, en tant que développeur d'applications, utiliser IBC ?

La nature modulaire du SDK Cosmos évite aux développeurs d'avoir à se préoccuper de certaines des couches d'abstractions telles que les clients légers, les connexions, la vérification de preuve, etc. Pour les développeurs, les exigences et les fonctions les plus pertinentes à familiariser sont les canaux et les ports . Pour des informations plus détaillées sur IBC, vous pouvez vous référer à notre portail développeur .

Si vous construisez votre blockchain à l'aide du SDK Cosmos, les étapes nécessaires pour activer IBC pour un module SDK sont détaillées ici . Vous pouvez également postuler au programme Interchain Builders, une initiative de l'ICF, pour obtenir de l'aide pour la construction dans Cosmos.

À propos de l'auteur : cet article a été rédigé par Adi Ravi Raj , analyste du protocole IBC chez Interchain GmbH.