Annonce des comptes et des requêtes Interchain

Depuis le lancement de l'API de messagerie interchain, nous avons travaillé en étroite collaboration avec les développeurs pour soutenir l'écosystème émergent des applications interchain. Notre démarrage rapide permet à chacun d'envoyer son premier message en moins de 5 minutes, à partir d'un navigateur ou d'une ligne de commande. La facilité d'utilisation guide chaque décision de conception de notre plateforme.

Pour utiliser cette API, un contrat sur la chaîne source envoie des messages et un contrat sur la chaîne de destination les reçoit. Malgré un outillage hors chaîne très complet, la gestion des déploiements sur de nombreuses chaînes a été une source constante de frictions. En outre, les anciens systèmes de contrats non conçus pour Hyperlane nécessitent un intergiciel spécifique pour recevoir des messages et bénéficier de la composabilité inter-chaînes.

Pour éliminer ces obstacles, nous avons développé deux nouvelles API qui ne nécessitent pas de déploiement sur plusieurs chaînes : les comptes inter-chaînes et les requêtes inter-chaînes. Ces deux primitives s'appuient sur une idée simple : si les messages sont délivrés dans un format que les destinataires interprètent déjà, les développeurs bénéficieront de la composabilité interchaîne universelle.

Comptes interchaînes

Les contrats ont souvent un flux de contrôle conditionnel sur l'état interne associé à l'expéditeur du message. Par exemple, ERC20.transfer garantit que l'expéditeur msg.a un solde suffisant en stock. Si tous les messages Hyperlane sont relayés en tant que messages EVM à partir du même contrat d'intergiciel, les expéditeurs de messages de la chaîne source ne peuvent pas être distingués. Au lieu de cela, un compte peut être inséré entre le message Hyperlane et le destinataire du message EVM qui identifie de manière unique la chaîne d'origine et l'adresse de l'expéditeur : un compte interchaîne.

Le code d'un compte interchaîne est un hybride de contrôle d'accès propriétaire et de fonctionnalité d'appel multiple. En substance, le compte interchaîne agit comme un proxy pour l'adresse de l'expéditeur de la chaîne d'origine. Les systèmes existants n'ont plus besoin d'intégrer Hyperlane car les comptes interchaînes émulent les interactions des contrats locaux.

Cela permet aux contrats de conserver des actifs et des jetons natifs sur d'autres réseaux sans utiliser de pont d'actifs. La construction d'un système de gestion de portefeuille d'actifs inter-chaînes ne nécessite qu'un déploiement sur une seule chaîne. Les DAO existantes, qui distribuent généralement des appels via la gouvernance, peuvent utiliser des comptes interchaînes pour la gouvernance interchaînes. Un stablecoin multi-collatéral peut utiliser des comptes interchaînes pour rééquilibrer les réserves de n'importe quel collatéral distant sur un réseau Hyperlane. Les possibilités sont nombreuses.

Requêtes interchaînes

Pour d'autres cas d'utilisation, les comptes interchaînes peuvent ne pas être appropriés. Les contrats effectuent aussi fréquemment des recherches d'état externes pour composer avec d'autres applications. Par exemple, la recherche du taux de change du marché entre deux actifs sur Uniswap. La liquidité des paires d'actifs varie considérablement d'un réseau à l'autre, et un développeur peut vouloir s'appuyer sur le taux de change d'un réseau distant. Cela est possible avec l'API de messagerie, mais s'est avéré fastidieux en raison de la gestion des contrats sur plusieurs chaînes.

Pour les conceptions qui nécessitent la lecture d'un état distant, nous présentons l'API de requête inter-chaînes. En utilisant cette primitive, les développeurs peuvent faire des appels à n'importe quel contrat distant sur un réseau Hyperlane. En fait, cela généralise l'opcode EVM CALL pour qu'il soit interchaîne.

Comme cet aller-retour traverse deux blockchains, il est intrinsèquement asynchrone. Pour reprendre le flux de contrôle dans Solidity, les développeurs fournissent une fonction pour traiter la valeur de retour de la requête. Ce modèle est communément appelé callback, mais à l'avenir, il pourrait être exprimé en utilisant une syntaxe asynchrone de type await. Veuillez vous référer à la documentation pour plus de détails sur l'utilisation et les hypothèses de sécurité.

Prédécesseurs logiques

Hyperlane n'a pas inventé les comptes inter-chaînes, ni les requêtes. En fait, ils sont nés dans la communauté Cosmos et il y a des progrès vers l'intégration au protocole IBC (ici et ici). Notre objectif est d'apporter l'interopérabilité à tous les développeurs et à tous les écosystèmes. À cette fin, nous continuerons à rendre les meilleures fonctionnalités de protocoles tels qu'IBC accessibles via Hyperlane.

Aujourd'hui, les développeurs peuvent utiliser Hyperlane pour interchaîner des comptes et des requêtes entre une liste de réseaux supportés qui ne cesse de s'allonger. Nous sommes ravis de continuer à itérer sur les primitives des développeurs avec le reste de l'écosystème pour faire avancer ce qui est possible au niveau de la couche d'application.