Les blockchains disparates doivent avoir un moyen de communiquer afin que les utilisateurs puissent interagir facilement avec les données et les actifs sur plusieurs blockchains, c'est ainsi que le protocole de communication inter-blockchains (IBC) a été établi pour fonctionner comme une couche de transport entre les blockchains. L'écosystème Cosmos a adopté en premier l'IBC, mais comme il s'agit d'un protocole généralisable, l'IBC s'est frayé un chemin dans de nombreux autres écosystèmes.

ICS-02 décrit les exigences en matière de construction de clients légers, y compris la manière dont l'IBC gère les données des clients légers. Les clients sont nécessaires pour que l'IBC fonctionne, ce sont des algorithmes de vérification arbitraires pour prouver les informations on-chain, qui sont généralement encodées au format IBC, d'un endroit à un autre.

Du point de vue de l'IBC, chaque chaîne est normalement identifiée par son client léger. La vérification la plus courante se produit entre deux machines à états communicantes ; en utilisant un client léger, une chaîne source est capable de vérifier les mises à jour d'une chaîne de destination sans télécharger l'intégralité de ses données. Étant donné que les clients légers sont des outils polyvalents, ils peuvent utiliser plusieurs méthodes pour effectuer la vérification de l'état.

Vérification de la preuve de consensus

Une note sur les algorithmes de consensus

Le consensus blockchain garantit que tous les nœuds participant à un réseau sont synchronisés. En utilisant la vérification du consensus, le client léger prouve qu'un nombre suffisant de validateurs ont signé l'en-tête. Ce type de vérification est l'utilisation la plus populaire de l'IBC.

Les algorithmes de consensus varient généralement dans leurs ensembles de règles et dans ce qu'ils priorisent. Cependant, l'hétérogénéité de deux algorithmes de consensus différents peut rendre difficile la communication entre les chaînes via l'IBC. Par exemple, les chaînes Cosmos utilisent l'algorithme de consensus Tendermint, qui possède une finalité en un seul slot, également connue sous le nom de finalité rapide. En revanche, le consensus d'Ethereum n'a pas de finalité en un seul slot et donc une finalité plus lente, car il privilégie la vivacité par rapport à la sécurité, alors que l'IBC est plus compatible avec les algorithmes de consensus qui privilégient la sécurité. En raison de cette différence dans le moment où les blocs sont considérés comme 'définitifs', il est difficile pour les deux chaînes de s'envoyer et de vérifier mutuellement des blocs.

Dans un tel cas, un client léger virtuel peut être mis en œuvre pour avoir une vue sur le client léger à une certaine hauteur de bloc avant d'atteindre la finalité. Initialement, l'IBC s'est concentré sur son adoption au sein des chaînes basées sur Tendermint, ce qui était évident dans la manière dont la spécification du client et sa mise en œuvre ont été définies. Après cette phase initiale, le Client Refactorune flexibilité accrue et une facilité accrue dans le développement de clients légers pour les chaînes avec d'autres algorithmes de consensus et fonctionnalités.

Clients légers: Machines d'état

Un "machine à états" peut être l'ensemble d'une blockchain (registre répliqué) ou un seul processus signant des opérations avec une clé privée (consensus minimal), comme un ordinateur portable ou un téléphone portable.

Communément, nous pensons aux machines d'état comme des blockchains avec des registres distribués, donc lors de l'établissement de l'IBC entre les blockchains, un client léger de la chaîne de destination est hébergé par la chaîne source. La chaîne source maintient également un état de confiance de la chaîne de destination, établi par un handshake de connexion entre les deux chaînes. Le protocole IBC utilise un prédicat de validité, qui est un algorithme vérifiant si les mises à jour d'état d'une chaîne de destination sont valides. Pour fonctionner, un client léger a besoin d'un prédicat de validité et d'un état de confiance pour la chaîne source.

client "type" vs. client "instance"

Les clients légers sont conçus pour être aussi efficaces que possible pour prendre en charge un grand nombre d'instances de client pour de nombreuses chaînes. Pour ce faire, l'algorithme du client léger ne rejoue pas toutes les transitions d'état, ce qui en ferait sinon un nœud complet.

Clients légers: Machines en solo

Une machine solo est un appareil tel qu’un ordinateur portable, une interface Web, un téléphone portable ou un processus hors chaîne. Une machine solitaire peut établir une communicationavec un grand livre répliqué si cette blockchain utilise l'IBC pour le transport.

Par exemple, IBC peut permettre à protocole de transfert de gardequi réduit les coûts d'intégration des nouvelles chaînes. C'est important car les gardiens centralisés sont confrontés à un processus fastidieux et coûteux lors de l'intégration de nouveaux réseaux, ce qui nécessite l'exécution d'un nœud complet et d'une infrastructure RPC pour chaque chaîne intégrée. Au lieu de cela, le gardien peut faire fonctionner un client machine solo qui facilite les transferts inter-chaînes, les émissions / brûlures. La vérification serait effectuée par le client de la machine connectée gérée par le gardien.

Les clients de la machine Solo montrent comment l'IBC ouvre la connectivité en dehors des seuls blockchains. Dans l'exemple ci-dessus, il peut permettre aux institutions d'interagir facilement avec les blockchains publiques via l'IBC. Il s'agit simplement d'un exemple de lignes commerciales qui touchent les blockchains sans avoir à mettre en place une chaîne entière ou à maintenir un matériel lourd pour travailler avec elles.

Vérification au-delà des preuves de consensus

Bien que des travaux soient en cours pour rendre les clients faciles à implémenter et à mettre à jour, il est possible d'effectuer une vérification avec des preuves de validité ou de fraude.

IBC optimiste : Les clients peuvent accepter de manière optimiste les en-têtes entrants via un relais hors chaîne qui exécute un programme sur une machine virtuelle. Dans ce scénario, il y a une fenêtre de défi où une preuve de fraude peut être soumise. Le positif est qu'IBC optimiste réduit le coût de l'ensemble du système. Les inconvénients incluent la longue période de défi de fraude et, en fonction du réseau, il pourrait y avoir des coûts de base élevés pour le transfert d'actifs - pour Ethereum, il s'agit de 21 000 unités de gaz.

ZK-IBC：les calculs clients ont lieu hors chaîne et sont vérifiés sur chaîne via ZKPs. Il n'y a pas de latence minimale et le coût est inférieur à une vérification naïve. Cependant, la vérification ZK peut être coûteuse sur chaîne et il n'y a pas de latence maximale, ce qui signifie qu'un utilisateur pourrait attendre un certain temps pour obtenir une confirmation. Il pourrait également y avoir des problèmes d'incompatibilité si le schéma de signature n'est pas SNARK-friendly.

Parce que les systèmes séparés ci-dessus peuvent avoir certains inconvénients prohibitifs, Optimistic ZK est proposé pour emprunter des avantages des deux. Les avantages de l'utilisation des deux réduisent le coût de maintenance de la connexion et introduisent une limite de latence maximale en incitant les relayers.

ZK optimiste : la chaîne source accepte de manière optimiste les en-têtes on-chain (il existe peut-être un mécanisme de mise en jeu pour la sécurité). Ensuite, les preuves de connaissance nulle sont utilisées comme preuves de fraude en cas de comportement incorrect ou comme preuves de validité pour réduire dynamiquement la latence de la connexion.

Sécurité et Mauvaise conduite

IBC ne nécessite aucune hypothèse de confiance envers un tiers, que prennent souvent les protocoles d'interopérabilité vérifiés de manière externe. Il s'agit simplement d'un protocole de transport et ses propriétés de sécurité dépendent des types de clients et de connexions sous-jacents et non de la chaîne elle-même. Cela dépend également de l'utilisation des preuves de fraude par la connexion, des hypothèses de majorité honnête, de la sécurité partagée via la disponibilité des données communes, etc. Le protocole IBC n'a pas besoin de connaître les identités des chaînes de chaque côté d'une connexion, tant que les clients IBC restent synchronisés avec des mises à jour valides.

Dans le cas où il y a un comportement répréhensible, c'est-à-dire que les règles de consensus établies par la chaîne de destination sont enfreintes par le client sur une chaîne source, le client sur la chaîne hôte serait gelé si la preuve du comportement répréhensible est vérifiée sur la chaîne source. La partie qui a vu cela, comme le relais, peut envoyer un message avec des preuves de ce comportement répréhensible. Le prédicat de comportement répréhensible est un algorithme qui est appelé dans des situations comme celle-ci : si le comportement répréhensible est prouvé, le client est gelé et espérons qu'il y a un système de gouvernance en place pour agir. Les répercussions du comportement répréhensible sont décidées par les chaînes participantes.

Construction Avec Clients Légers

Bien que l'IBC puisse nécessiter une certaine compétence technique dans le consensus et les détails internes de la chaîne sous-jacente, toutes les subtilités ne sont pas cruciales pour construire en utilisant l'IBC - un autre objectif que nous avons avec cette série d'articles. L'essentiel ici est que l'IBC est un outil puissant compte tenu des différentes mises en œuvre de vérification que les clients peuvent adopter.

L'écosystème Gate.io travaille activement pour faire de Gate une solution facile à adopter pour les constructeurs. Certaines des initiatives que nous avons discutées incluent le refactoring du client et les clients virtuels. Par exemple, si une chaîne souhaite mettre à niveau le consensus, elle devra mettre à niveau chaque chaîne à laquelle elle est connectée ainsi que leurs clients légers pour rester connectée, ce qui est un processus coûteux de gouvernance on-chain. Des clients WASM sont en cours de développement pour rendre le développement et la mise à niveau des clients légers simples via des instances de client déployées en tant que contrats intelligents. Cela rend plus facile la mise à niveau des clients légers sans arrêter la chaîne et de créer des clients dans des langages comme Rust, qui est un choix populaire parmi plusieurs machines d'état.

La conclusion à retenir est que les clients IBC peuvent être utilisés par n'importe qui et n'importe quelle machine pour vérifier l'état sur n'importe quelle blockchain, ce qui en fait un puissant catalyseur pour de nouvelles entreprises et services dans le domaine de la crypto.

Cet article a été sponsorisé par Polymer pour soutenir l'éducation communautaire autour de l'IBC et de l'interopérabilité vraiment décentralisée.

Polymer Labs, composé d'ingénieurs qualifiés en systèmes distribués et en infrastructure, de pionniers de la cryptographie et d'opérateurs commerciaux accomplis, est à l'avant-garde de la promotion de l'interopérabilité d'Ethereum avec l'IBC. Avec des valeurs techniques basées sur TCP/IP, la mission de Polymer est d'établir la prochaine génération d'Internet en veillant à ce que la couche d'interopérabilité du web décentralisé soit neutre, ouverte, sans permission et uniforme dans tous les écosystèmes. En tant que créateurs du Hub d'Interopérabilité d'Ethereum, le premier Layer 2 axé sur l'interopérabilité IBC, Polymer établit une nouvelle norme dans la technologie blockchain.

Avertissement：

1. Cet article est repris de [Gateeshitanandini]. Tous les droits d'auteur appartiennent à l'auteur original [ESHITA]. If there are objections to this reprint, please contact the Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas des conseils en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.