Introduction

Les maxis modulaires disent que l'avenir de la crypto est un million (ou plus) de domaines interconnectés et d'utilisateurs sautant entre les chaînes comme Alice se promenant dans le pays des merveilles. Pourquoi rester avec une seule chaîne si vous pouvez accéder à une technologie de pointe, à des applications novatrices, à des rendements fous sur la mise en jeu / la fourniture de liquidité, à des performances élevées et à des frais de transaction ultra-faibles sur d'autres blockchains ?

Mais passer d'une blockchain à une autre est beaucoup plus compliqué que le voyage d'Alice au pays des merveilles, principalement en raison des limitations inhérentes aux approches actuelles de l'interopérabilité des blockchains (par exemple, les passerelles inter-chaînes). En particulier, les passerelles inter-chaînes d'aujourd'hui sont soit peu sécurisées (plus de 2,5 milliards de dollars perdus dans des piratages de passerelles), soit lentes, coûteuses, ou limitées en fonctionnalités - ou présentent un mélange de ces caractéristiques de la liste.

D'autres problèmes qui affectent l'industrie de l'interconnexion sont plus subtils mais suffisants pour transformer le rêve d'un écosystème multi-chaînes modulaire en un cauchemar pour les utilisateurs et les développeurs - un exemple en est la manière dont les jetons fongibles (comme les ERC-20) deviennent non fongibles lorsqu'ils sont interconnectés à différentes chaînes via divers protocoles cross-chain, ce qui nuit à leurs caractéristiques en tant qu'actifs transférables. Dans cet article, nous explorerons une solution qui vise à préserver la fongibilité des jetons entre les chaînes, indépendamment de l'endroit où se trouve le contrat d'origine du jeton : ERC-7281 : Jetons interconnectés souverains.

ERC-7281 étend ERC-20 - la norme de facto pour créer des jetons fongibles sur Ethereum - pour permettre l'émission et la suppression de représentations canoniques de jetons ERC-20 sur des domaines distants par plusieurs passerelles approuvées par les émetteurs de jetons. Cela garantit que les utilisateurs qui passent un jeton ERC-20 reçoivent des versions fongibles du jeton à la destination (c'est-à-dire que deux jetons peuvent être échangés 1:1), même lorsque les jetons sont envoyés d'une chaîne à l'autre via des routes/passerelles différentes. Il est important de noter que les protocoles qui adoptent ERC-7281 conservent le contrôle des jetons passerelle (contrairement à la situation actuelle où la passerelle contrôle un jeton passerelle) et peuvent limiter le taux d'émission pour réduire l'exposition en cas de défaillance de la passerelle.

Prenons l'exemple de USDC pour illustrer l'infungibilité des jetons ERC-20 théoriquement identiques sur différentes chaînes.Réseaux Ethereum Layer 2 (L2), comme Arbitrum, Base, Optimism, il est courant d'utiliser le pont canonique pour déplacer les jetons ERC-20 populaires de l'Ethereum L1 vers ces chaînes. Ces versions des jetons L2 d'origine L1 sont couramment appelées simplement « pontés [insérer le nom du jeton] ».

Dans le cas de l'USDC, les symboles courants sont USDC.e, USDC.b, etc. Au fil du temps, Circle étend ses déploiements USDC à d'autres chaînes, y compris les L2s, où l'USDC est déjà actif via le pont canonique. Même si ces deux jetons sont émis par la même entité et ont le même prix, ils sont techniquement différents, des jetons infungibles, donc ils ne sont pas «interopérables» - tandis que l'USDC natif peut être ponté via le pont CCTP de Circle, l'USDC ponté ne peut être ponté de retour vers le L1 que via le pont canonique.

ERC-7281 résout ce problème en introduisant une extension ERC-20 où les déployeurs du jeton peuvent attribuer et paramétrer différentes sources de pontage pour celui-ci. Dans l'exemple ci-dessus, Circle pourrait déployer un jeton USDC universel sur tous les L2, où les ponts canoniques (par exemple, Circle Mint, Circle CCTP et d'autres ponts approuvés) sont tous désignés comme capables de créer les jetons selon leur logique. Pour réduire les risques de piratage des créateurs, le déployeur peut limiter le nombre de jetons que chaque créateur peut créer et brûler sur une période de temps spécifique - les ponts plus fiables, tels que le L2 canonique, ayant des limites plus élevées, et les ponts avec un consensus centralisé ayant des limites plus basses.

Bien que l'ERC-7281 ne soit pas la première tentative de créer des jetons inter-chaînes fongibles, il résout les problèmes associés aux propositions précédentes, tels que le verrouillage du fournisseur, la perte de souveraineté pour les émetteurs de jetons, les coûts élevés de démarrage de la liquidité pour les jetons pontés, les frais généraux de l'infrastructure et l'augmentation de l'exposition aux défaillances du pont.

Ce rapport en deux parties examinera les raisons d'introduire une norme de jeton pontée souveraine et fournira une vue d'ensemble complète de la spécification ERC-7281 (également connue sous le nom de xERC-20). Nous discuterons également des avantages positifs et des inconvénients potentiels de la mise en œuvre de l'ERC-7281 pour les utilisateurs, les développeurs, les fournisseurs d'infrastructure et autres acteurs de l'écosystème Ethereum.

Un rappel sur les ponts de la blockchain

Avant de plonger dans le problème des tokens pontés non fongibles, il est utile de comprendre pourquoi les tokens pontés existent en premier lieu. Cela, à son tour, nécessite de comprendre la motivation et le fonctionnement des ponts blockchain, puisque les opérateurs de ponts sont ceux qui sont responsables de la création des versions de tokens pontés.

Un pont est un mécanisme de transfert d'informations entre les blockchains. En plus des informations purement monétaires, les ponts peuvent transmettre toute information utile, telle que les taux de jetons et l'état des contrats intelligents sur d'autres chaînes. Cependant, le transfert d'actifs (jetons) d'une chaîne à l'autre est le cas d'utilisation le plus courant pour les utilisateurs interagissant avec un pont aujourd'hui.

Les approches pour faciliter les transferts d'actifs inter-chaînes varient, mais les flux de travail de pontage de jetons suivent généralement l'un des trois modèles de haut niveau :

Verrouiller et créer des ponts

• Un utilisateur souhaite relier un jeton de sa chaîne d'origine ou « d'accueil » (où il a été initialement émis) à une autre chaîne. Les deux blockchains ne sont pas interopérables, car chaque chaîne met en œuvre des architectures et des conceptions de protocole différentes, ce qui empêche l'utilisateur de transférer des jetons directement depuis une adresse de portefeuille sur la chaîne A vers une adresse de portefeuille sur la chaîne B.
• L'opérateur de pont bloque les jetons déposés par l'utilisateur sur la chaîne d'origine dans un contrat intelligent et crée une représentation « enveloppée » du jeton natif via un contrat de jeton déployé sur la chaîne cible.
• Lorsque l'utilisateur souhaite faire le pont dans le sens inverse (chaîne de destination → chaîne d'origine), il retourne les jetons emballés au pont sur la chaîne de destination, qui vérifie cela selon la logique du pont (par exemple, les preuves ZK ou un quorum externe) et libère les jetons d'origine de l'entiercement sur la chaîne d'origine.

Brûler et créer des ponts

• Au lieu de verrouiller les jetons en séquestre, cette approche brûle (détruit) les jetons sur la chaîne source;
• Le pont crée ensuite une quantité équivalente sur la chaîne de destination;
• Pour le voyage de retour, les jetons pontés sont brûlés sur la chaîne de destination avant que de nouveaux jetons ne soient frappés sur la chaîne source;
• Cela maintient l'approvisionnement total de jetons tout en permettant des transferts inter-chaînes.

Échanges atomiques

• Cette approche échange directement des actifs sur la chaîne source contre des actifs sur la chaîne de destination avec une autre partie.
• Les échanges atomiques fonctionnent en verrouillant mutuellement des fonds avec la même valeur secrète pour les déverrouiller, ce qui signifie que si le secret est révélé d'un côté, il peut également être révélé de l'autre. Cela confère aux échanges la propriété d'atomicité.
• L'atomicité signifie que l'échange est soit entièrement réalisé (des deux côtés), soit pas du tout, ce qui empêche les fraudes ou les transferts partiels/échoués.

La première approche (verrouillage et création) est actuellement la plus courante. L'équivalence de valeur entre un jeton natif et sa représentation enveloppée correspondante, créée par un pont, permet aux utilisateurs de "transférer" des actifs inter-chaînes et d'utiliser un jeton sur une chaîne distincte de celle où il a été initialement émis.

Cependant, de nouveaux designs, tels que le pontage basé sur l'intention, sont devenus très populaires. Les "intentions" permettent aux utilisateurs d'exprimer les résultats souhaités pour les transactions ("échanger 100 USDC contre 100 DAI") au lieu de détailler des étapes spécifiques pour atteindre les résultats. Les intentions se sont révélées être un puissant déverrouillage de l'UX car elles simplifient considérablement l'expérience onchain pour les gens et rendent l'utilisation de la cryptomonnaie plus facile, en particulier lorsqu'elles sont associées à solutions d'abstraction de chaîne.

Intentions de cross-chainpermet aux utilisateurs de transférer des jetons entre les chaînes sans se soucier de la complexité sous-jacente du pontage. Dans les ponts basés sur l'intention, les utilisateurs déposent des fonds sur la chaîne source et spécifient leur résultat souhaité sur la chaîne de destination (leur « intention »). Des opérateurs spécialisés appelés « fillers » ou « solvers » peuvent remplir cette intention en envoyant les jetons demandés à l'utilisateur sur la chaîne de destination à l'avance. Les opérateurs prouvent ensuite que le transfert a eu lieu pour réclamer les fonds verrouillés sur la chaîne source en guise de remboursement.

Certains ponts basés sur l'intention utilisent des mécanismes de verrouillage et d'émission sous-jacents. Dans ce cas, le pont émet des jetons enveloppés qui sont envoyés soit au remplisseur qui a satisfait l'intention de l'utilisateur, soit directement à l'utilisateur si aucun remplisseur n'est intervenu. Bien que les ponts basés sur l'intention ajoutent une couche supplémentaire d'efficacité grâce à leur réseau de résolveurs, ils reposent toujours fondamentalement sur les mêmes principes que les ponts traditionnels de verrouillage et d'émission.

Nous pouvons considérer chaque jeton enveloppé, qu'il soit créé par le biais d'un pont traditionnel ou basé sur l'intention, comme un IOU de l'opérateur du pont promettant de libérer une quantité du jeton sous-jacent du contrat d'entiercement. La valeur de ces actifs enveloppés est directement liée à la capacité (perçue) de l'opérateur du pont à traiter les demandes des détenteurs pour retirer les jetons natifs mis en gage sur la chaîne d'origine du jeton.

Le pont autorisé à verrouiller les tokens sous-jacents sur la chaîne source et à frapper leurs représentations enveloppées sur la chaîne de destination garantit que l’offre totale du token reste constante. Pour une unité du jeton sous-jacent, exactement une unité du jeton enveloppé correspondant est frappée, et vice versa. Si une application accepte un jeton encapsulé comme moyen d’échange ou utilise des ressources encapsulées comme monnaie, les développeurs et les utilisateurs de l’application font confiance au fournisseur de pont pour sécuriser les actifs « réels » qui reposent sur le jeton encapsulé.

Pourquoi avons-nous besoin de ponts?

La capacité de traiter avec une version synthétique d'un actif sur une chaîne distante—permise par des ponts créant des représentations de l'actif—est une fonctionnalité puissante et permet aux développeurs et aux utilisateurs de profiter des avantages de l'interopérabilité cross-chain. Certains de ces avantages incluent l'accès à plus de liquidité, l'exposition à de nouveaux utilisateurs et la flexibilité pour les utilisateurs (qui peuvent interagir avec des applications préférées de différentes chaînes sans friction).

Pour mieux comprendre comment cela fonctionne en pratique et pourquoi cela est important à la fois pour les développeurs et les utilisateurs, examinons un exemple concret à l'aide d'un échange décentralisé fictif appelé BobDEX. Cet exemple démontrera comment les jetons enveloppés permettent une expansion cross-chain tout en mettant en évidence les avantages et les complications potentielles qui peuvent survenir:

BobDEX est un échangeur automatisé de Market Maker (AMM) que Bob a créé sur Ethereum pour permettre des échanges sans confiance entre différents actifs. BobDEX a un jeton natif, $BOB, qui sert à la fois de jeton de gouvernance et de jeton de récompense LP. Dans ce dernier cas, BobDEX émet des jetons BOB aux fournisseurs de liquidité (LP), permettant aux utilisateurs fournissant de la liquidité à un pool d'obtenir un pourcentage des frais payés par les utilisateurs de DEX échangeant des actifs déposés dans le pool.

La part de marché de BobDEX a considérablement augmenté, mais les limitations d'Ethereum L1 entravent une croissance ultérieure. Par exemple, certains utilisateurs ne veulent pas utiliser BobDEX sur Ethereum en raison de frais de gaz élevés et de retards de transaction ; de même, d'autres utilisateurs souhaitent une exposition au prix des jetons $BOB sans avoir à détenir des jetons natifs $BOB sur Ethereum.

Pour résoudre le problème, Bob déploie une version de BobDEX sur Arbitrum (un rollup Layer 2 (L2) à faible frais et haut débit) et déploie une version enveloppée du jeton BOB (wBOB) sur L2 via le pont Arbitrum-Ethereum. BobDEX sur Arbitrum est identique à BobDEX sur Ethereum, sauf qu'il utilise wBOB - et non les jetons BOB natifs - pour les récompenses en LP et la gouvernance.

La différence entre les jetons d'application (wrapped BOB vs. native BOB) n'a pas d'importance du point de vue des utilisateurs (par exemple, les fournisseurs de liquidités) interagissant avec BobDEX sur Arbitrum. Étant donné que les jetons wBOB sont garantis par des jetons BOB réels détenus dans le pont Arbitrum-Ethereum, les détenteurs de jetons wBOB peuvent facilement échanger des jetons BOB natifs ERC-20 sur Ethereum en interagissant avec le contrat de pont.

La situation est gagnant-gagnant pour Bob et les utilisateurs:

1. Bob peut attirer plus d'utilisateurs, en particulier ceux qui recherchent des frais de gaz réduits et des confirmations de transaction rapides lorsqu'ils tradent sur BobDEX
2. Les fournisseurs de liquidité peuvent gagner des récompenses en fournissant de la liquidité à BobDEX sans avoir à faire face aux frais de gaz élevés d'Ethereum et aux longs délais de confirmation
3. Les Hodlers peuvent acheter des jetons wBOB sur le marché pour profiter des variations du prix des jetons BOB sans interagir avec le contrat BOB ERC-20 sur Ethereum

Les avantages de la création de ponts s'étendent également à l'amélioration de l'innovation composable et au déblocage de nouveaux cas d'utilisation qui tirent parti de la liquidité d'un jeton ponté. Par exemple, Alice peut créer un protocole de prêt appelé AliceLend sur Arbitrum qui accepte wBOB comme garantie de la part des emprunteurs pour étendre l'utilité de wBOB et créer un nouveau marché pour...prêt et emprunt.

Les prêteurs fournissant de la liquidité à AliceLend sont certains de recevoir des dépôts : si un utilisateur fait défaut sur un prêt, AliceLend met automatiquement aux enchères les jetons wBOB déposés en garantie pour rembourser les prêteurs. Dans ce cas, les acheteurs de la garantie wBOB liquidée assument le rôle de LP sur BobDEX et ont la même garantie que les jetons wBOB peuvent être échangés 1:1 contre les jetons BOB originaux.

Le pontage inter-chaînes dans sa forme actuelle a fourni une solution pratique pour assurer interopérabilité entre (précédemment cloisonnés) Ethereum L2set faciliter de nouvelles applications (par exemple, le prêt inter-chaînes et les DEX inter-chaînes). Mais l'écosystème de pontage est actuellement confronté à des limites qui entravent une croissance supplémentaire, telles que la non-fongibilité des jetons inter-chaînes - nous explorerons ce problème en détail par la suite.

Pourquoi les jetons pontés deviennent-ils non fongibles ?

Le flux de travail de verrouillage et d'exploitation minière décrit précédemment semble simple sur papier, mais en réalité, il nécessite beaucoup d'efforts d'ingénierie et de conception de mécanismes pour fonctionner correctement.

Le premier défi consiste à s’assurer que les versions encapsulées d’un jeton ponté sont toujours soutenues par des jetons natifs verrouillés sur la chaîne source. Si un attaquant frappe des représentations d’un token sur une chaîne distante sans déposer de tokens natifs sur la chaîne source, il peut rendre le bridge insolvable en échangeant (frauduleusement miné) des tokens wrappés avec des tokens natifs sur la chaîne d’origine et en empêchant les utilisateurs légitimes – qui ont déposé dans le contrat bridge avant de frapper des tokens wrappés – de retirer des dépôts.

Le deuxième défi est plus nuancé et découle de la nature des jetons pontés : deux représentations d'un jeton émis par des fournisseurs de pont sur la même chaîne distante ne peuvent pas être échangées 1:1 pour une autre. Nous pouvons utiliser un autre exemple de deux utilisateurs essayant d'échanger des jetons pontés par des routes différentes pour illustrer cet aspect du problème associé au déplacement de jetons entre les chaînes :

• Alice fait le pont entre l’USDC d’Ethereum et Arbitrum via le pont canonique Arbitrum et reçoit 200 USDC.e sur Arbitrum, tandis que Bob fait le pont entre l’USDC et Arbitrum via Axelar et reçoit 200 axlUSDC sur Arbitrum. Alice et Bob concluent un accord pour qu’Alice envoie 200 USDC à Bob (en échange de 200 USDT) afin que Bob puisse retirer 400 USDC à Ethereum.
• Bob essaie de retirer 400 USDC via axlUSDC et ne reçoit que 200 USDC, accompagné d'un message expliquant que le pont n'a que 200 USDC à donner à Bob. Bob est confus car les jetons ERC-20 enveloppés sont censés être « fongibles » et ne devraient pas présenter de disparités empêchant quiconque d'échanger des jetons ERC-20 1:1 sur n'importe quelle application.
• Bob apprend une leçon difficile sur le pontage entre chaînes : « token ERC-20 fongible » ne signifie pas toujours « vous pouvez échanger ce token 1:1 avec d'autres tokens ERC-20 entre différentes applications ». La tentative de Bob de faire des affaires risquées avec Alice - risquée car Alice pourrait ne pas rendre les tokens - tourne spectaculairement mal.

Bob après s'être fait arnaquer sur un swap

Pourquoi Bob ne peut-il pas retirer 400 USDC s'il et Alice ont reçu des versions enveloppées du même actif sous-jacent sur la chaîne de destination ? Vous vous souviendrez que nous avons mentionné que les jetons émis sur différentes chaînes sont incompatibles, donc la représentation d'un jeton natif émis sur une chaîne non native est un IOU du pont promettant de rembourser une quantité des jetons natifs (selon ce qui reste) lorsque l'utilisateur souhaite revenir au pont vers la chaîne native du jeton.

La valeur de chaque jeton transféré est donc liée au fournisseur de pont responsable de la détention des dépôts sur la chaîne d'origine et de l'émission de représentations sur la chaîne de destination; Le fournisseur de pont de Bob ne peut payer que 200 USDC à Bob car c'est le montant qu'il a les fonds pour couvrir de son dépôt; Les 200 USDC d'Alice ne peuvent pas être retirés via le fournisseur de pont de Bob car il n'a jamais reçu le dépôt ni émis un IOU à Alice. Alice doit retirer ses USDC verrouillés de l'Arbitrum sur Ethereum et les transférer via le fournisseur de pont de Bob avant que Bob puisse accéder aux jetons restants.

Le dilemme de Bob et Alice souligne un problème de pont entre des domaines où plusieurs représentations non fongibles d'un actif sous-jacent sont créées par des fournisseurs de pont concurrents. L'autre problème avec les différentes représentations ERC-20 du même actif est qu'elles ne peuvent pas être échangées dans un seul pool de liquidité.

En utilisant l'exemple précédent, si nous avons axlUSDC et USDC.e sur la chaîne et que nous voulons les échanger contre de l'ETH et vice versa, nous devons déployer deux pools de liquidités : ETH/axlUSDC et ETH/USDC.e. Cela conduit à un problème de "fragmentation de liquidité" - une situation où les pools de trading ont une liquidité plus faible qu'ils pourraient en avoir autrement parce qu'il y a plusieurs pools qui conviennent essentiellement à la même paire de trading.

La solution consiste à avoir une seule version “canonique” d'un jeton circulant sur la chaîne de destination afin que Bob et Alice puissent échanger des jetons sans que chaque personne ne retire du pont de la chaîne source. Avoir un jeton canonique par chaîne bénéficie également aux développeurs, car les utilisateurs peuvent rapidement passer d'un écosystème à un autre sans avoir à gérer des problèmes de liquidité des jetons.

Alors, comment procédons-nous pour mettre en œuvre des versions canoniques d'un jeton sur chaque chaîne sur laquelle il est censé être utilisé et transféré entre elles ? La prochaine section explique certaines des approches populaires pour créer des jetons canoniques sur plusieurs chaînes.

Mise en œuvre de jetons canoniques sur différentes chaînes

Créer un jeton canonique par chaîne n'est pas simple, et plusieurs options existent avec des compromis et des avantages variables. Lors de la création d'un jeton canonique par chaîne, nous devons généralement réfléchir à qui faire confiance quant à l'existence des IOUs soutenant la valeur d'un jeton particulier. Supposons que vous soyez le créateur d'un jeton et que vous souhaitez qu'il puisse être utilisé et transféré sur différentes chaînes sans rencontrer de problèmes de fongibilité ; vous avez quatre options :

1. Mintez des jetons canoniques via des ponts de rollup/sidechain canoniques
2. Créer des jetons canoniques via un fournisseur de pont tiers
3. Mintez des jetons canoniques via un pont d'émetteur de jetons
4. Émission directe multi-chaînes avec échanges atomiques

Les trois premières options reposent sur divers mécanismes de pont pour faciliter le mouvement cross-chain des jetons. Cependant, en tant que créateur de jetons, vous pouvez également choisir de contourner complètement les ponts en émettant le jeton de manière native sur chaque chaîne prise en charge. Selon cette approche, au lieu de s'appuyer sur des jetons enveloppés ou une infrastructure de pont, vous maintenez des déploiements de jetons séparés mais coordonnés à travers les chaînes, les swaps atomiques permettant un échange sans confiance entre les chaînes.

Cette approche nécessite une infrastructure sophistiquée pour maintenir la liquidité entre les chaînes et faciliter les échanges atomiques. Cependant, la complexité de la gestion de déploiements natifs multiples a historiquement limité cette approche aux protocoles plus importants disposant de ressources techniques substantielles.

1. Créer des jetons canoniques via des ponts de rollup/sidechain canoniques

Si une chaîne dispose d'un pont canonique (consacré), vous pouvez attribuer le droit de créer des représentations du jeton de votre protocole aux utilisateurs qui souhaitent passer par le pont natif. Les transactions routées par le pont canonique de la chaîne (dépôts et retraits) sont généralement validées par l'ensemble des validateurs de la chaîne, ce qui garantit que les dépôts sur la chaîne d'origine soutiennent de manière crédible toutes les représentations créées.

Bien que le pont canonique émette la représentation canonique d'un jeton, d'autres représentations existeront toujours. Cela se produit simplement parce que les ponts canoniques ont souvent des limitations qui les empêchent d'offrir aux utilisateurs la meilleure expérience. Par exemple, le pont entre Arbitrum/Optimism et Ethereum via le pont canonique du rollup entraîne un retard de sept jours car les transactions doivent être validées par des vérificateurs, et éventuellement contestées par unpreuve de fraude, si invalide - avant la couche de règlement du rollup (Ethereum - règle un lot de transactions.

Les utilisateurs de Rollup qui souhaitent des sorties plus rapides doivent utiliser d'autres fournisseurs de ponts qui peuvent assumer la propriété des sorties de Rollup en attente et fournir une liquidité initiale sur la chaîne cible souhaitée de l'utilisateur. Lorsque de tels ponts utilisent le modèle traditionnel de verrouillage et d'émission, nous nous retrouvons avec de multiples représentations enveloppées d'un jeton émises par différents protocoles et rencontrons les mêmes problèmes décrits précédemment.

Les sidechains avec des ensembles de validateurs indépendants ont une latence plus faible car les retraits sont exécutés une fois que le protocole de consensus de la sidechain confirme un bloc contenant une transaction de retrait. Le pont Polygon PoS est un exemple de pont canonique connectant une sidechain à différents domaines (y compris les rollups Ethereum et Ethereum mainnet).

Note: Nous faisons référence à la chaîne Polygon PoS d'origine, pas à la chaîne validium planifiéequi utilisera Ethereum pour le règlement. Polygon deviendra un L2 une fois que le passage d'une sidechain sécurisée par des validateurs externes à un validium sécurisé par le consensus d'Ethereum sera complet.

Cependant, les ponts de sidechain partagent également une faiblesse avec les ponts canoniques de type rollup: les utilisateurs ne peuvent pontifier qu'entre une paire de chaînes connectées. Ils ne peuvent pas pontifier vers d'autres blockchains en utilisant le pont canonique. Par exemple, vous ne pouvez pas pontifier d'Arbitrum à Optimism aujourd'hui en utilisant le pont Arbitrum ou de Polygon à Avalanche via le pont Polygon PoS.

1.1. Créer des jetons canoniques en utilisant des ponts de liquidité

S'appuyer sur un pont natif de rollup pour déplacer des jetons canoniques présente plusieurs problèmes, tels qu'une liquidité médiocre et des retards dans le mouvement des actifs. Les protocoles contournent ce problème en travaillant avec des ponts de liquidité pour faciliter les retraits rapides et le pontage à faible latence*.

Dans le cadre de cet arrangement, les passerelles de liquidité approuvées (a) émettent des représentations enveloppées d'un jeton de protocole sur la chaîne source (b) échangent des jetons enveloppés contre la représentation canonique à la destination via un pool de liquidité détenu par le protocole.

La représentation canonique du jeton sur la chaîne de destination est généralement la version émise par le pont de la sidechain/rollup canonique, bien que des exceptions existent (comme nous le verrons plus tard). Par exemple, la version canonique de l'USDT sur Optimism est l'opUSDT émis par le pont Optimism.

Chaque pont de liquidité fonctionne comme un DEX avec un Automated Market Maker (AMM) pour exécuter des échanges entre des paires d'actifs déposés dans différents pools de liquidité. Pour encourager la fourniture de liquidité, les pools AMM partagent une partie des frais d'échange avec les détenteurs qui bloquent des jetons canoniques dans les contrats de pool.

Cela est similaire au modèle d'Uniswap ; la seule différence notable est que les paires d'actifs sont généralement la représentation de pont de liquidité d'un jeton par rapport à la représentation canonique. Par exemple, un utilisateur qui relie des USDT à l'Optimisme via Hop devra échanger des hUSDT sur l'Optimisme via le pool huSDT:opUSDT.

Le flux de travail pour le pontage via un pont de liquidité ressemblera à ceci :

• Verrouillez les jetons natifs sur la chaîne source
• Représentation du pont de la création d'un jeton natif sur la chaîne cible
• Échanger la représentation pontée avec la représentation canonique sur la chaîne cible via le pool AMM
• Envoyer des jetons canoniques à l'utilisateur

Ce processus est similaire pour toutes les passerelles de liquidité (Across, Celer, Hop, Stargate, etc.). Cependant, il est généralement abstrait pour l'utilisateur final, en particulier par les solveurs/remplisseurs, et semblera être une seule transaction malgré l'implication de nombreux éléments en mouvement.

Lorsque vous revenez au chaîne source, l'utilisateur brûle la représentation canonique ou échange le jeton canonique avec la représentation du pont via l'AMM avant de brûler cette représentation et de fournir le reçu de preuve de combustion. Une fois confirmé, l'utilisateur peut retirer les jetons natifs verrouillés au départ. (Tout comme l'opération précédente, les détails techniques du transfert des jetons à la chaîne d'origine sont cachés à l'utilisateur et gérés par les solveurs).

La mise en place de la liquidité est excellente, principalement parce qu'elle résout le problème de latence dans la mise en place de rollup; par exemple, Hop permet à des parties spécialisées appelées « assignataires » de confirmer la validité d'une transaction de retrait d'un utilisateur sur L2 et de prendre en charge les frais de retrait de la passerelle L1 du rollup. Chaque assignataire exécute un nœud complet pour la chaîne L2 et peut déterminer si une transaction de sortie d'un utilisateur sera finalement confirmée sur L1, réduisant ainsi le risque qu'un utilisateur initie un retrait frauduleux et entraîne des pertes pour l'assignataire.

Les passerelles de liquidité permettent également aux utilisateurs de passer entre plusieurs chaînes, contrairement aux passerelles canoniques; par exemple, Hop permet aux utilisateurs de passer entre Arbitrum et Optimism sans avoir à retirer d'abord vers Ethereum. Tout comme le pontage rapide de L2→L1, le pontage rapide de L2→L2 nécessite que les Bonders exécutent un nœud complet pour la chaîne source L2 afin de confirmer les retraits avant de prendre en charge le coût de l'émission de jetons pour un utilisateur sur la chaîne de destination L2. Cela permet une plus grande composition entre les rollups et améliore considérablement l'expérience utilisateur, car les utilisateurs peuvent déplacer des jetons entre les rollups sans problème.

Mais la création de liquidités a aussi des inconvénients qui affectent l'utilité d'utiliser le pont consacré d'une chaîne pour créer la représentation canonique d'un jeton sur une chaîne L2/L1.

Inconvénients des passerelles de liquidité

1. Glissement

Le glissement est une différence dans la quantité de jetons attendue et reçue lors de l'interaction avec un AMM. Le glissement se produit en raison du fait que les AMM fixent les prix des échanges en fonction de la liquidité actuelle dans un pool - les prix sont tels que l'équilibre est maintenu entre l'équilibre de chaque actif dans une paire après qu'un échange est complet, ce qui peut changer entre le moment où un utilisateur lance un échange et l'exécution de l'échange.

Une faible liquidité des actifs pontés peut également augmenter le glissement ; si le pool n'a pas assez de liquidité pour rééquilibrer un côté du pool, un gros échange peut faire varier le prix de manière importante et amener les utilisateurs à effectuer des swaps à des prix plus élevés. Les arbitragistes sont censés aider à corriger les disparités entre les pools qui échangent le même actif, mais peuvent être dissuadés des opérations d'arbitrage impliquant des jetons à faible activité/valeur de trading.

Cela a également un impact sur les développeurs qui construisent des applications cross-chain, car ils doivent tenir compte des cas particuliers où des écarts se produisent ; l'utilisateur ne peut pas effectuer une opération cross-chain car il reçoit des montants inférieurs d'un jeton sur une ou plusieurs chaînes de destination.

Les applications telles que les agrégateurs de ponts (qui ne peuvent pas savoir si un pont de liquidité aura suffisamment de liquidité pour couvrir un échange sur la chaîne de destination sans glissement) contournent le problème en spécifiant une tolérance maximale au glissement et en utilisant celle-ci pour informer les devis fournis aux utilisateurs. Bien que cela empêche les annulations de transaction, les utilisateurs perdent toujours un certain pourcentage du jeton ponté, quelle que soit la liquidité dans les pools AMM d'un pont.

2. Contraintes de liquidité

Un défi fondamental avec les passerelles de liquidités est l'exigence absolue d'une liquidité suffisante sur la chaîne de destination. Contrairement aux passerelles de verrouillage et de création de jetons traditionnelles où la création de jetons est garantie directement par des actifs verrouillés, les passerelles de liquidités dépendent des jetons disponibles dans les pools AMM pour effectuer des transferts inter-chaînes. Lorsque la liquidité tombe en dessous des seuils critiques, l'ensemble du mécanisme de pontage peut cesser de fonctionner efficacement.

• Les opérations de pont peuvent être complètement interrompues si la liquidité devient trop faible, empêchant les utilisateurs de mener à bien leurs transferts prévus;
• Les utilisateurs peuvent être obligés de diviser de gros transferts en de plus petites transactions pour éviter d'épuiser la liquidité de la pool;
• Pendant les périodes de forte volatilité ou de stress sur le marché, les fournisseurs de liquidités peuvent se retirer des pools, précisément lorsque la fonctionnalité de pont est la plus nécessaire;
• L’amorçage de nouvelles paires de tokens devient particulièrement difficile, car une liquidité initiale importante est nécessaire pour rendre le pont opérationnel.

L'exigence de liquidité crée une dépendance circulaire : les ponts ont besoin d'une liquidité substantielle pour fonctionner de manière fiable, mais attirer les fournisseurs de liquidité nécessite de démontrer une utilisation constante des ponts et la génération de frais. Ce problème d'œuf et de poule est particulièrement aigu pour les jetons nouveaux ou moins fréquemment échangés, qui peuvent avoir du mal à maintenir une liquidité suffisante sur plusieurs chaînes.

3. Incitations désalignées

Un pont de liquidité est utile dans la mesure où il peut couvrir les échanges de la représentation pontée vers le jeton canonique sur la chaîne de destination sans que les utilisateurs subissent un glissement excessif ; les frais de gaz liés à l'interaction avec le pont déterminent également la valeur d'un pont de liquidité du point de vue de l'utilisateur. Ainsi, les agrégateurs de ponts et les équipes de projet, émettant un jeton, accordent la priorité aux ponts en fonction du montant de liquidité et des coûts de transaction.

Bien que cela garantisse aux utilisateurs qui relient les jetons d'un projet ou utilisent un agrégateur de ponts pour envoyer des jetons d'une chaîne à l'autre une meilleure expérience utilisateur, la sélection des ponts en fonction de la liquidité place les ponts dans l'incapacité de dépenser des incitations fournies par les fournisseurs de liquidité (LP) à un désavantage. De plus, la sélection des ponts en fonction des frais de transaction purs favorise la concurrence en faveur des ponts adoptant une approche centralisée pour réduire les coûts opérationnels et pouvant facturer des frais de transaction de pont inférieurs. Dans les deux cas, les ponts ne sont pas en concurrence sur ce qui est sans doute la métrique la plus importante : la sécurité.

Les ponts basés sur la liquidité défavorisent également les actifs à longue traîne ayant une activité de trading plus faible (ce qui les rend moins susceptibles d'attirer des LP). Les émetteurs de jetons à longue traîne (ou de nouveaux jetons avec de faibles volumes de pontage) devront soit mettre en place des pools AMM et amorcer la liquidité pour couvrir les échanges de jetons natifs (pontés via un pont de liquidité) contre la représentation canonique du jeton de l'émetteur, soit travailler avec les opérateurs de ponts pour augmenter les incitations financières pour que les LP fournissent de la liquidité pour cet actif.

4. Mauvaise expérience utilisateur de pontage

Les ponts de liquidité sont une amélioration par rapport aux ponts canoniques, mais ils ne sont pas sans problèmes d'expérience utilisateur. En plus de subir un glissement sur les échanges cross-chain, les utilisateurs peuvent être incapables de finaliser une transaction de pont immédiatement sur la chaîne de destination car le pont n'a pas assez de liquidité de pool pour couvrir le commerce avec le jeton canonique sur la chaîne de destination. Les ponts ne peuvent pas savoir quelle quantité de liquidité pour une paire d'actifs existera au moment où le message d'un utilisateur pour échanger des jetons atteint la chaîne de destination, donc ce cas limite est en grande partie inévitable.

Les utilisateurs ont deux choix dans cette situation (tous deux sous-optimaux):

• Attendre que le pont ait suffisamment de liquidité pour effectuer l'échange et retirer les jetons canoniques. Cela est suboptimal en raison du retard subi dans les transactions de pont et parce qu'un utilisateur ne peut pas savoir s'il recevra le même montant de jetons cité initialement, car la liquidité du pool peut changer arbitrairement en très peu de temps.
• Recevez la représentation du jeton propriétaire du pont (par exemple, hUSDT pour Hop Bridge). Il s’agit d’un aspect sous-optimal, car la plupart des applications préféreront s’intégrer à la représentation canonique d’un jeton natif (par exemple, opUSDT émis par Optimism Bridge) et n’accepteront peut-être pas l’actif encapsulé de l’utilisateur.

2. Émettre des jetons canoniques via un pont tiers canonique

Une dapp multi-chaîne peut contourner le problème des jetons non fongibles relayés en sélectionnant un pont unique pour émettre des représentations canoniques du jeton de la dapp sur chaque chaîne où la dapp est déployée. Tout comme les ponts canoniques qui émettent des représentations approuvées du jeton d'un projet, cette approche nécessite de mapper les jetons émis sur des chaînes distantes vers le contrat de jeton déployé sur la chaîne d'origine du projet, en veillant à ce que l'offre de jetons reste la même à l'échelle mondiale. Le fournisseur de pont doit suivre l'émission et la destruction d'un jeton et s'assurer que les opérations d'émission et de destruction restent synchronisées avec l'offre de jetons sur la chaîne d'origine.

Utiliser un seul fournisseur de pont offre plus de flexibilité aux équipes de projet, surtout que les ponts tiers sont incités à prendre en charge le pontage entre un plus large éventail d'écosystèmes par rapport aux ponts canoniques qui ne se connectent qu'à au plus une chaîne. Si un pont existe sur toutes les chaînes où une application est déployée, les utilisateurs peuvent rapidement passer d'une chaîne à l'autre sans avoir besoin de retirer des fonds vers la chaîne d'origine ; un fournisseur de pont n'a qu'à s'assurer que les jetons émis sur la chaîne de destination A sont brûlés avant qu'un utilisateur émette des jetons sur la chaîne de destination B et que les jetons canoniques sur la chaîne B sont (re)mappés au jeton sur la chaîne d'origine.

Le problème des jetons pontés non fongibles est également éliminé ; si les utilisateurs passent par le fournisseur de ponts approuvé, ils peuvent toujours les échanger 1:1 avec d'autres jetons pontés. Cette approche résout également les problèmes de pontage basé sur la liquidité dans le modèle de pont canonique :

• Les utilisateurs ne subissent pas de glissement lors des transactions de pont, car le fournisseur de pont n'a pas à convertir sa représentation par rapport à une représentation canonique via un AMM - le jeton du fournisseur de pont est la représentation canonique du jeton ponté sur chaque domaine. La valeur de ces représentations est liée à la valeur des jetons verrouillés par le fournisseur de pont sur la chaîne native du jeton.
• Les utilisateurs ne subissent que peu ou pas de retards lors du pontage, car le fournisseur du pont peut créer immédiatement des représentations enveloppées sur la chaîne de destination juste après l'arrivée du message mint() à destination.
• Les développeurs peuvent externaliser la gestion des déploiements de jetons multi-chaînes aux opérateurs de ponts sans se soucier de l'amorçage de la liquidité AMM ou des programmes d'incitation à la fourniture de liquidité.

Certains exemples de jetons fournis par un seul pont dans la nature incluent le jeton fongible Omnichain (OFT) de LayerZero, le service de jeton inter-chaîne (ITS) d'Axelar, xAsset de Celer et anyAsset de Multichain. Tous les exemples sont essentiellement des jetons propriétaires et sont incompatibles avec les représentations du même jeton envoyé via un fournisseur de pont différent. Ce détail subtil met en évidence certains problèmes liés à cette approche de gestion des jetons pontés, à savoir les suivants:

• Emprisonnement du fournisseur
• Perte de souveraineté
• Exposition élevée aux défaillances des ponts
• Perte des fonctionnalités personnalisées du jeton sur les chaînes cibles
• Être limité aux chaînes prises en charge par le fournisseur
• Incapacité de maintenir la même adresse de jeton sur toutes les chaînes souhaitées, ce qui peut nuire à la sécurité des utilisateurs ou les rendre vulnérables aux attaques de phishing

Inconvénients de l'utilisation de ponts tiers canoniques

1. Verrouillage du fournisseur

Sélectionner un seul fournisseur de pont pour créer des représentations canoniques sur une ou plusieurs chaînes expose les développeurs au risque de verrouillage du fournisseur. Chaque fournisseur de pont crée une représentation propriétaire compatible uniquement avec son infrastructure (et les projets de l'écosystème intégré). Le modèle du fournisseur de pont unique verrouille efficacement un émetteur de jeton à un service de pontage spécifique sans possibilité de passer à un autre pont à l'avenir.

Il est possible de changer de fournisseurs de ponts, mais les coûts de changement sont suffisamment élevés pour décourager la plupart des projets d'emprunter cette voie. Pour donner une idée approximative, supposons qu'un développeur (que nous appellerons Bob) a émis un jeton (BobToken) sur Ethereum et choisit LayerZero OFT pour émettre des versions canoniques de BobToken sur Optimism, Arbitrum et Base. BobToken a un approvisionnement fixe de 1 000 000 de jetons, et les jetons bridgés émis via LayerZero représentent 50 % du stock total de BobTokens en circulation.

La transaction commerciale se déroule sans encombre jusqu'à ce que Bob décide que les utilisateurs seraient mieux lotis en reliant les BobTokens via un service de pont concurrent (par exemple, Axelar). Cependant, Bob ne peut pas simplement dire : « Je passe à Axelar ITS pour émettre des représentations canoniques de BobToken sur Optimism, Base et Arbitrum » ; étant donné que les jetons OFT et les jetons ITS sont incompatibles, Bob risque de créer des maux de tête tant pour les anciens utilisateurs que pour les nouveaux, car deux BobTokens ne sont potentiellement pas fongibles (ce qui réintroduit le problème que nous avons décrit précédemment). De plus, les applications intégrées à la version de BobToken de LayerZero ne peuvent pas accepter la version de BobToken d'Axelar comme substitut, ce qui fragmente la liquidité pour BobToken sur diverses chaînes où coexistent des représentations concurrentes de BobToken.

Pour rendre la transition possible, Bob doit convaincre les utilisateurs de déballer les représentations enveloppées de BobToken émises via LayerZero en envoyant une transaction qui brûle les jetons OFT mis en pont et déverrouille les BobTokens sur Ethereum. Les utilisateurs peuvent maintenant passer à la nouvelle représentation canonique de BobToken en verrouillant des jetons avec Axelar sur Ethereum et en recevant des BobTokens canoniques (associés à l'offre de contrat de jetons sur Ethereum) sur la chaîne de destination. Cela est à la fois coûteux et entraîne une coordination massive et des frais généraux opérationnels pour les équipes de gestion de projet DAO, il est donc généralement plus sûr de rester fidèle au fournisseur choisi.

Cependant, cela laisse les développeurs comme Bob dans une position problématique, car l'enfermement du fournisseur rend impossible le changement si un fournisseur de pont ne parvient pas à respecter les termes de l'accord, dispose d'une suite de fonctionnalités limitée, manque d'intégrations dans l'écosystème, offre une mauvaise UX, etc. Cela donne également aux ponts un levier quasi infini : le fournisseur de pont peut faire des choses arbitraires comme limiter le débit des utilisateurs qui transfèrent des BobTokens sans raison claire, augmenter les frais de transfert ou même censurer les opérations de transfert. Les mains de Bob sont liées dans ce cas, car rompre proprement avec un pont tiers canonique défectueux est aussi complexe que de rester dans la relation commerciale.

2. Perte de souveraineté pour les protocoles

La partie concluante de la section précédente sur le verrouillage du fournisseur met en évidence un autre problème lié à l'utilisation d'un pont tiers canonique : les émetteurs de jetons échangent le contrôle des jetons pontés canoniques contre une plus grande commodité et des améliorations de l'expérience utilisateur. Pour reprendre l'exemple précédent : BobToken sur Ethereum est entièrement sous le contrôle de Bob car il contrôle le contrat de jeton ERC-20 sous-jacent, mais BobToken sur Optimism, Arbitrum et Base est contrôlé par LayerZero, qui possède le contrat OFT émettant les représentations canoniques de BobToken sur ces blockchains.

Bien que Bob puisse s’attendre à ce que LayerZero aligne les représentations canoniques sur la conception originale du jeton natif, ce n’est pas toujours le cas. Dans le pire des cas, le comportement de BobToken sur Ethereum peut diverger considérablement de celui de BobToken sur Optimism, car le fournisseur de pont met en œuvre une version radicalement différente du contrat de jeton, ce qui crée des problèmes pour les utilisateurs du protocole. Ce problème peut également être exacerbé par la dynamique principal-agent où les objectifs et les intérêts d’un protocole et du fournisseur de passerelle divergent.

3. Haute exposition aux défaillances des ponts

Dans la première approche, où les jetons sont transférés de manière croisée à travers le pont canonique de chaque chaîne, le risque pour l'émetteur de jetons provenant d'une exploitation affectant un pont est contenu à ce pont. Par exemple, supposons qu'un pirate informatique parvienne à compromettre un pont de liquidité et à créer des quantités infinies d'un jeton enveloppé sans déposer de garantie. Dans ce cas, il ne peut retirer qu'un montant maximum de liquidité disponible pour l'actif enveloppé dans les pools de liquidité (par exemple, création de cUSDT sur Optimism → échange de cUSDT pour opUSDT canonique → retrait d'opUSDT vers Ethereum via un pont rapide → échange contre des USDT natifs sur Ethereum).

Dans le modèle de pont canonique tiers, le risque pour un émetteur de jetons résultant d'une exploitation affectant le pont partenaire est équivalent au montant total de jetons qu'un attaquant crée sur des chaînes distantes où le pont affecté est déployé. Cela est possible car chaque représentation canonique sur toutes les chaînes peut être échangée 1:1 contre des jetons canoniques émis sur d'autres chaînes :

Supposons qu'un attaquant compromette un pont tiers sur la chaîne B et émette 1000 jetons (où le jeton est initialement émis sur la chaîne A) sans déposer de garantie. Les jetons de l'attaquant sur la chaîne B ne sont pas associés au contrat de la chaîne d'origine, il ne peut donc pas les retirer de la chaîne A. Cependant, il peut les transférer vers la chaîne C et échanger 1000 jetons de la chaîne B contre 1000 jetons de la chaîne C, car chaque jeton inter-chaînes est compatible et fongible, car ils proviennent du même service de pont. Les jetons de la chaîne C sont associés au contrat de la chaîne d'origine car ils ont été émis légitimement par des utilisateurs qui ont verrouillé des jetons sur la chaîne A (la chaîne d'origine du jeton), permettant ainsi à l'attaquant de brûler des jetons sur la chaîne C et de retirer des jetons natifs sur la chaîne A, et éventuellement de compléter l'itinéraire en échangeant les jetons via une plateforme d'échange centralisée (CEX) ou une sortie fiat.

(Source)

Perte des fonctionnalités du jeton personnalisé

Lors de l'utilisation d'un pont tiers canonique, les émetteurs de jetons perdent souvent la possibilité de mettre en œuvre des fonctionnalités personnalisées ou des comportements de jetons qui existent dans leur déploiement d'origine. Cela se produit car les fournisseurs de pont ont tendance à utiliser des contrats d'implémentation ERC-20 standardisés qui peuvent ne pas prendre en charge les fonctionnalités spécialisées présentes dans l'implémentation originale du jeton.

Des fonctionnalités communes aux jetons telles que la délégation de vote (ZK), les mécanismes de rééquilibrage (stETH, USDM), les capacités de frais de transfert (memecoins), les fonctions de liste noire et de liste blanche (USDT, USDC), les transferts suspendus et les règles ou autorisations de création spéciales sont souvent supprimées lorsque les jetons sont interconnectés via un fournisseur tiers, car la version interconnectée utilisera généralement une implémentation ERC-20 de base. Cette perte de fonctionnalité crée des incohérences dans le fonctionnement du jeton sur différentes chaînes et peut potentiellement rompre les intégrations qui dépendent de ces fonctionnalités personnalisées.

La normalisation des jetons pontés, bien que plus simple du point de vue du fournisseur de pont, réduit efficacement les capacités du jeton et peut entraver la capacité de l'émetteur à maintenir un comportement de jeton cohérent dans l'ensemble de l'écosystème multi-chaînes de leur application. De telles questions peuvent rendre les expansions cross-chain un cauchemar pour les développeurs et représenter un obstacle à la réalisation du rêve des applications vivant sur plusieurs chaînes.

Chains supportées limitées

Les émetteurs de jetons deviennent dépendants de la couverture réseau et des plans d'expansion de leur fournisseur de pont choisi. Si le fournisseur de pont ne prend pas en charge un réseau blockchain particulier vers lequel l'émetteur de jetons souhaite s'étendre, il est confronté à deux choix suboptimaux :

• Attendez que le fournisseur de pont ajoute la prise en charge de la chaîne souhaitée, ce qui peut prendre beaucoup de temps ou ne jamais se produire en raison des coûts élevés d'intégration (par exemple, l'incompatibilité de l'EVM de l'ère ZKsync qui a conduit de nombreuses dapps à ne jamais être déployées dessus)
• Utilisez un fournisseur de pont différent pour cette chaîne spécifique, ce qui réintroduit le problème des jetons non fongibles et de la fragmentation de la liquidité

Cette limitation peut avoir un impact significatif sur la stratégie de croissance d'un protocole et sa capacité à atteindre de nouveaux utilisateurs sur les chaînes émergentes. Les fournisseurs de ponts peuvent donner la priorité au soutien des chaînes populaires tout en négligeant les réseaux plus petits ou plus récents qui pourraient être stratégiquement importants pour l'émetteur de jetons.

Adresses de jeton croisé incohérentes

Les fournisseurs de ponts tiers peuvent déployer des jetons pontés avec des adresses différentes sur chaque chaîne en raison des particularités de leur pile technologique - par exemple, l'absence de support pourCREATE2. Le manque de cohérence des adresses crée à son tour de nombreux problèmes d'UX :

• Risques de sécurité : les utilisateurs doivent vérifier les différentes adresses de jetons sur chaque chaîne, ce qui augmente le risque d'interagir avec des jetons frauduleux;
• Complexité d'intégration: les développeurs doivent maintenir des listes d'adresses de jetons valides pour chaque réseau;
• Risque accru de phishing : Les mauvais acteurs peuvent plus facilement tromper les utilisateurs avec de faux jetons puisqu'il n'y a pas d'adresse cohérente à vérifier.

Ces inconvénients, combinés aux problèmes précédemment évoqués de verrouillage du fournisseur, de perte de souveraineté et d'exposition élevée aux échecs des ponts, mettent en évidence les limitations importantes liées à la dépendance aux ponts tiers canoniques pour les déploiements de jetons inter-chaînes. Cette compréhension contribue à expliquer pourquoi des solutions alternatives telles que ERC-7281 sont nécessaires pour relever ces défis de manière plus complète.

3. Frapper des jetons canoniques via un pont jeton-émetteur

Si un développeur souhaite maintenir un contrôle maximal des déploiements cross-chain du jeton d'un projet, il peut gérer l'émission de représentations canoniques du jeton sur des chaînes distantes. Cela est décrit comme « faire confiance à l'émetteur du jeton », car la valeur de chaque représentation pontée du jeton est liée aux jetons verrouillés sur la chaîne d'origine du jeton par le protocole responsable de l'émission de la version originale du jeton sur la chaîne source.

Pour que cette approche fonctionne, l’émetteur de tokens doit mettre en place une infrastructure pour gérer la frappe et la combustion des tokens pontés sur l’ensemble de la chaîne (tout en veillant à ce que l’offre mondiale reste synchronisée via une cartographie canonique).

Des exemples notables de représentations canoniques d'un jeton émis par le créateur du jeton sontTeleport de MakerDAOet Circle’sProtocole de transfert interchaîne (CCTP). Teleport permet aux utilisateurs de déplacer le DAI canonique entre Ethereum et divers rollups Ethereum via des opérations à trajet rapide et à trajet lent. Le DAI est brûlé sur une chaîne et émis sur la chaîne cible. CCTP fonctionne de manière similaire et permet des transferts inter-chaînes de USDC natifs (émis par Circle) via un mécanisme de brûler-et-émettre. Dans les deux cas, l'émetteur du jeton contrôle l'émission et la destruction des représentations canoniques d'un jeton.

Cette approche offre un contrôle complet des jetons pontés pour les protocoles. Et cela résout le problème des représentations non fongibles du même jeton de la manière la plus efficace possible - il n'existe qu'une seule version canonique du jeton (émise par l'émetteur sur la chaîne de destination), ce qui garantit aux utilisateurs la même expérience en utilisant un jeton sur chaque écosystème pris en charge par l'émetteur de jetons.

Avec cette approche, les applications bénéficient également de l'élimination de la fragmentation de la liquidité causée par des représentations non officielles et interconnectées d'un jeton de protocole flottant dans le même écosystème. Les développeurs peuvent également construire des applications inter-chaînes plus robustes (par exemple, des échanges inter-chaînes et des prêts inter-chaînes), car les ponts émetteurs de jetons canoniques permettent un mouvement de jetons efficace en capital, sans couture et sécurisé entre les chaînes.

L’inconvénient des ponts canoniques entre les émetteurs de tokens, cependant, est que ce modèle n’est réalisable que pour les projets disposant d’un capital suffisant pour couvrir les frais généraux liés au déploiement d’un token cross-chain et à la maintenance de l’infrastructure (oracles, keepers, etc.) nécessaire pour effectuer le minting et le burning cross-chain. Cela a également l’effet quelque peu indésirable de coupler étroitement la sécurité des actifs pontés avec le modèle de sécurité du protocole.

Cette relation (entre les versions pontées des jetons d'un protocole et la sécurité de ce dernier) est amicale puisque la sécurité des jetons natifs soutenant des représentations canoniques dépend déjà de la sécurité du protocole, de sorte que les utilisateurs et les développeurs externes ne prennent pas de nouveaux engagements de confiance. Cela est particulièrement vrai pour ponts de stablecoinsexploité par des émetteurs tels que Circle et Maker (maintenant Sky) - les utilisateurs font déjà confiance aux émetteurs de stablecoins pour posséder suffisamment d'actifs pour couvrir le rachat des stablecoins contre des devises fiduciaires, il n'est donc pas difficile de faire confiance à la sécurité d'un pont de stablecoin.

Mais cela représente également un point central de défaillance - si l'infrastructure de pont de l'émetteur de jetons est compromise, la valeur de toutes les représentations canoniques circulant dans l'écosystème multi-chaînes est en danger. Cela implique également que seuls les gardiens centralisés (par exemple, Circle dans le cas de l'USDC) peuvent mettre en œuvre ce modèle d'émission de jetons pontés canoniques.

Réflexions finales

Comme le montre ce rapport, la fongibilité des actifs cross-chain est une partie importante de l'interopérabilité rollup avec des implications pour l'expérience de déplacement entre différentes chaînes. La capacité des jetons à rester fongibles lorsqu'ils sont reliés à des chaînes distantes a également un impact sur l'expérience des développeurs car certains cas d'utilisation dépendent de cette fonctionnalité.

Différentes solutions ont été proposées pour résoudre le problème des jetons cross-chain non fongibles - dont beaucoup ont été couverts dans ce rapport. Cela comprend la création de jetons canoniques via des passerelles natives (consacrées), l'utilisation d'une passerelle tierce dédiée pour créer des jetons canoniques sur plusieurs chaînes, et l'utilisation d'une passerelle détenue par le protocole pour faciliter le mouvement des jetons et préserver la fongibilité.

Bien que ces approches résolvent des problèmes spécifiques, elles ne parviennent pas à résoudre toutes les questions et les utiliser pour permettre la fongibilité des actifs inter-chaînes nécessite certains compromis indésirables. Pouvons-nous trouver une meilleure approche ? La réponse est oui.

ERC-7281 est une nouvelle approche de la fongibilité des actifs cross-chain qui atténue les compromis associés aux approches existantes. Aussi connu sous le nom de xERC-20, ERC-7281 permet aux protocoles de déployer efficacement des jetons canoniques sur plusieurs chaînes sans compromettre la sécurité, la souveraineté ou l'expérience utilisateur.

La conception unique de l'ERC-7281 permet à plusieurs ponts (sur liste blanche) de créer des versions canoniques des jetons d'un protocole sur chaque chaîne prise en charge, tout en permettant aux développeurs du protocole d'ajuster dynamiquement les limites de création sur la base de chaque pont. Cette fonctionnalité résout de nombreux problèmes liés aux propositions historiques de jetons canoniques multi-chaînes, notamment la fragmentation de la liquidité, l'alignement des incitations, les préoccupations UX, les risques de sécurité des ponts, la personnalisation (des jetons inter-chaînes), et plus encore.

La prochaine - et dernière - partie de notre rapport en deux parties sur la fongibilité des actifs interchaînes couvrira en détail ERC-7281 et explorera comment la norme de jeton xERC-20 peut bénéficier aux développeurs et aux utilisateurs. Nous comparerons ERC-7281 à d'autres conceptions de jetons canoniques multichaînes, explorerons l'approche de xERC-20 pour les jetons canoniques multichaînes et mettrons en évidence les considérations pour les protocoles et les développeurs souhaitant s'appuyer sur la norme.

Restez à l'écoute!

Avertissement :

1. Cet article est repris de [2077 Recherche]. Tous les droits d'auteur appartiennent à l'auteur original [Alex HooketEmmanuel Awosika]. S'il y a des objections à cette reproduction, veuillez contacter le Gate Apprendre é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 un conseil en investissement.
3. Les traductions de l’article dans d’autres langues sont effectuées par l’équipe de gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.