Si vous n’avez pas lu la première partie de la série Comment rendre les jetons inter-chaînes à nouveau fongibles, vous voudrez peut-être vérifiez-letout d'abord, il explique pourquoi les jetons pontés perdent leur fongibilité et les défis que cela crée. Dans la deuxième partie, nous explorons l'ERC-7281, une nouvelle norme qui rationalise les transferts de jetons cross-chain, améliore la fiabilité et donne aux émetteurs un plus grand contrôle.

La nécessité d’une meilleure approche

Jusqu'à présent, nous avons exploré diverses solutions au problème de rendre les jetons pontés fongibles et de résoudre les problèmes de fragmentation de liquidité et de mauvaise UX liés aux représentations non-canoniques d'un jeton natif circulant sur des blockchains non natives :

• Frappez des représentations canoniques d’un jeton sur des chaînes distantes via des ponts canoniques rollup/sidechain
• Mint représentations canoniques d'un jeton sur des chaînes distantes via un service de pont tiers
• Créez des représentations canoniques d'un jeton sur des chaînes distantes via un service de pont canonique exploité par l'émetteur de jetons

Chacune de ces approches présente des compromis, il est donc tout à fait approprié que la proposition de l'ERC-7281 visant à créer des jetons pontés fongibles tente de tirer le meilleur parti de chaque approche pour créer une solution plus holistique, efficace et accessible pour les protocoles qui souhaitent déployer des jetons cross-chain sans compromettre la sécurité, la souveraineté ou l'expérience utilisateur.

ERC-7281: Jetons souverains interconnectés est une proposition visant à permettre la création de représentations canoniques d’un jeton qui sont compatibles et fongibles avec des représentations frappées par de nombreux ponts différents. ERC-7281 fonctionne en étendant l’interface ERC-20 pour inclure :

• Fonctionnalité pour créer et brûler des jetons ERC-20 canoniques;
• Capacité du propriétaire du jeton à

1) attribuer des opérateurs de pont pour la création et la destruction de jetons lorsqu'ils sont transférés entre les chaînes;

2) Limiter la création et la destruction de jetons pour chaque opérateur de pont approuvé, par exemple en définissant de petites limites pour les ponts centralisés et des limites plus élevées pour les protocoles plus sécurisés.

Compte tenu de la légère différence entre les jetons ERC-7281 et ERC-20, les auteurs de l’EIP ont décrit le premier comme « xERC-20 ». Pour les lecteurs qui ont besoin d’une vue d’ensemble des jetons ERC-20, OpenZeppelin dispose d’un excellent guide sur le sujet.

Essentiellement, chaque contrat de jeton ERC-20 implémente l'interface ERC-20 qui définit un approvisionnement mondial en jetons et stocke des informations sur les adresses possédant le jeton et la quantité qu'elles possèdent. ERC-20 inclut également des fonctions utiles pour gérer l'accès aux jetons d'un utilisateur (via des approbations) et récupérer des informations sur un jeton, telles que l'approvisionnement circulant total et le solde d'une adresse particulière.

Une caractéristique supplémentaire que l’ERC-7281 ajoute à la spécification ERC-20 est une boîte postale en option qui fonctionne comme un contrat d’emballage (similaire au contrat WETH (Wrapped Ether)). Le contrat Lockbox encapsule les jetons ERC-20 dans les jetons xERC-20 par le biais de mécanismes familiers de mint-and-burn et rend ERC-7281 compatible avec les contrats de tokens ERC-20 existants qui n’ont pas d’interface burn/mint et ne peuvent pas être mis à niveau.

En utilisant le cadre présenté dans l’article précédent, nous pouvons catégoriser ERC-7281 comme une approche « faire confiance à l’émetteur du jeton + faire confiance au fournisseur de pont (approuvé) » pour la frappe de jetons multichaînes. Un jeton ERC-7281 déployé sur plusieurs chaînes est contrôlé par son émetteur (contrairement aux conceptions alternatives de jetons inter-chaînes qui nécessitent généralement de renoncer à la souveraineté). Bien que l’émetteur soit toujours exposé au risque qu’un pont approuvé subisse un incident de sécurité, l’émetteur gère ce risque en choisissant et en limitant manuellement les fournisseurs de ponts autorisés.

La grande différence, que nous allons explorer dans ce rapport, est que les émetteurs de jetons peuvent calibrer l’exposition aux piratages et aux exploits de pont en imposant des limites dynamiques sur le nombre de jetons qu’un opérateur de pont particulier peut frapper/brûler. L’ERC-7281 permet également à un émetteur de jetons de mettre sur liste blanche plusieurs fournisseurs de ponts pour frapper le même jeton canonique à travers les chaînes, réduisant ainsi la dépendance à l’égard d’un seul fournisseur pour traiter les opérations de pontage inter-chaînes.

Les deux fonctionnalités font de l'ERC-7281 une amélioration significative par rapport aux approches traditionnelles visant à faciliter le pontage inter-chaînes des jetons d'un protocole et ont des effets secondaires positifs pour les utilisateurs, les fournisseurs d'infrastructure d'interopérabilité (en particulier les agrégateurs) et les développeurs d'applications. Après avoir discuté des spécifications dans la section suivante, nous passerons en revue les avantages - et les inconvénients - de la mise en œuvre de l'ERC-7281.

Une vue d’ensemble de ERC-7281 : Tokens pontés souverains

Brûler et frapper des jetons pour les utilisateurs

Dans la spécification, un projet déploie un nouveau contrat de jeton compatible ERC20 qui implémente l'interface IXERC20. Les opérateurs de pont émettent des jetons pour les utilisateurs sur la chaîne de destination après avoir brûlé un dépôt sur la chaîne source. Le processus d'émission vérifie que le montant du jeton ne dépasse pas la limite du pont et met à jour l'offre totale de jetons et la limite d'émission du pont en cas de succès.

Pour les jetons ERC-20 déjà existants, une logique de "coffre-fort" est appliquée : le fournisseur de pont enveloppe les jetons ERC-20 déposés par les utilisateurs dans des jetons xERC-20 en les transférant à un contrat de coffre-fort. Le coffre-fort autorise ensuite le pont à émettre une quantité équivalente de jetons xERC-20.

Les jetons xERC-20 frappés par un pont sur la chaîne de destination sont gravés sur la chaîne source à l’aide de la fonction burn(). Ce processus garantit que la quantité de jetons ne dépasse pas la limite de combustion du pont, l’augmente et diminue l’offre totale du jeton xERC-20. La couche de transport du pont relaie le message de gravure vers la destination. Le contrat de pont du côté de la destination vérifie le message et frappe un nombre égal de jetons xERC-20 à l’adresse de l’utilisateur sur cette chaîne. Cette frappe diminue l’offre totale du jeton et la limite de frappe du pont.

Pour relier les jetons à la chaîne d'origine, l'opérateur du pont brûle des jetons xERC-20 sur la chaîne distante, fournissant l'adresse de l'utilisateur et le montant du jeton. Le reçu de la destruction est relayé à la chaîne d'origine par la couche de transport. Si le message de destruction est vérifié, l'opérateur du pont émet et brûle de nouveaux jetons xERC-20 sur la chaîne d'origine pour l'utilisateur. Après validation du reçu de destruction par le contrat de jeton, l'opérateur du pont libère les jetons ERC-20 déposés à l'utilisateur. Brûler des jetons xERC-20 sur la chaîne d'origine réduit l'offre totale de jetons et la limite de brûlure du pont.

Un point important : le contrat xERC-20 peut techniquement frapper des jetons sans que le pont ne vérifie les preuves. Nous avons décrit l’approche standard (lire : attendue), mais les ponts qui n’implémentent aucun type de vérification de message (ou qui mettent en œuvre de nouveaux mécanismes de vérification des messages inter-chaînes) peuvent être mis sur liste blanche pour frapper et graver des jetons xERC-20. Tout dépend de ce que l’émetteur du jeton peut accepter.

Limites de taux pour l'émission et la combustion de jetons

La fonction setBridgeLimits est une fonction protégée qui ne peut être appelée que par le propriétaire du contrat de jetons. Cette fonction permet de définir l'adresse du contrat de pont et de spécifier le montant maximum de jetons que le pont peut créer (mintingLimit) et brûler (burningLimit) pour les utilisateurs. Le propriétaire peut mettre à jour ces limites, ce qui permet d'ajuster les capacités du pont selon les besoins. Par exemple, si des problèmes de sécurité sont découverts dans l'infrastructure d'un fournisseur de pont, le mintingLimit peut être réduit pour minimiser les risques. À l'inverse, des améliorations de sécurité peuvent entraîner une augmentation de la limite de création de jetons.

La spécification xERC-20 comprend également des fonctions pour vérifier les limites de brûlage et de création monétaire des ponts approuvés pour gérer le jeton. « mintingMaxLimitOf » renvoie la quantité maximale de jetons qu'un pont peut créer, et respectivement, « burningMaxLimit » renvoie la quantité maximale de jetons qu'un pont peut brûler pendant une période spécifiée. De plus, ces fonctions montrent les jetons restants qu'un pont peut brûler et créer avant d'atteindre les limites prédéfinies.

Ces fonctions de visualisation sont utiles pour les agrégateurs de passerelles qui ont besoin de connaître les limites disponibles pour différents fournisseurs de passerelles avant de router les transactions. Si une passerelle atteint sa limite de gravure ou de création sur la chaîne source ou de destination, cela peut affecter les transactions en cours et l'expérience utilisateur. Par conséquent, les agrégateurs préfèrent router les demandes vers les passerelles qui n'ont pas atteint leurs limites de création et de gravure et peuvent effectuer l'échange d'un montant donné.

Paramètres de limite de débit

La spécification de l’interface de jeton xERC-20 comprend une structure « Bridge » contenant « burningParams » et « mintingParams » (les paramètres de la fonction de limite de débit d’un jeton xERC-20 contrôlent le nombre de jetons qu’un pont peut brûler et frapper sur une période prédéfinie). « maxLimit » définit la limite maximale de minting et de burning de tokens et augmente chaque seconde à un taux prédéfini (« ratePerSecond). »

C’est là que nous abordons un point de confusion possible : « maxLimit » (défini pour la limite de gravure et de minting) sonne comme une limite pour les opérations de minting et de burning sur une échelle de temps particulière, et non comme une limite de débit qui limite la minting et la gravure selon des seuils prédéfinis pendant la fenêtre de temps prédéfinie. « currentLimit » définit la quantité qu’un pont peut frapper ou brûler et augmente à un rythme prédéfini. En revanche, « maxLimit » définit la quantité qu’un pont peut mentir ou brûler quotidiennement.

Les paramètres de combustion et de création de jetons sont principalement pertinents pour les propriétaires de jetons (et dans une moindre mesure pour les opérateurs de ponts). Cependant, les paramètres de limite maximale et actuelle sont des considérations importantes pour les utilisateurs et les opérateurs de ponts. Par exemple, la limite actuelle pourrait affecter la quantité qu'un utilisateur peut transmettre en toute confiance avec un protocole de cross-chain sans rencontrer de retards dans la réception des jetons xERC-20 à la destination.

Coffre-fort xERC-20

Le jeton ERC-20 d'origine ne spécifie pas les fonctions d'augmentation et de diminution de l'offre d'un jeton (à l'époque où "tokenomics" signifiait générer un nombre fixe de jetons et dire aux utilisateurs que le jeton avait de la valeur parce qu'il serait rare dans quelques années*). Ainsi, tous les jetons ERC-20 n'ont pas une fonction de frappe et de destruction. Étant donné que l'ERC-7281 utilise le mécanisme de frappe et de destruction privilégié par la plupart (si ce n'est tous) des passerelles aujourd'hui, les jetons ERC-20 hérités ou non-mis à niveau ne peuvent pas fonctionner directement avec l'ERC-7281.

Le contrat Lockbox fournit une solution de contournement et permet la rétrocompatibilité avec les jetons existants. Dans la spécification d’origine (c’est-à-dire qu’un projet déploie un nouveau contrat de jeton qui implémente l’interface IXERC20), les opérateurs de pont n’ont qu’à appeler mint() pour frapper des jetons pour un utilisateur de la chaîne de destination (après avoir verrouillé un dépôt sur la chaîne source).

Le contrat Lockbox s'inspire largement de la conception du contrat wrapper WETH. Il implémente une fonction deposit() pour déposer le jeton ERC-20 correspondant dans le Lockbox et une fonction withdraw() pour que les opérateurs de pont débloquent les jetons ERC-20 après avoir brûlé des jetons enveloppés sur un domaine distant.

Les deux premiers types d'erreurs mis en évidence dans la spécification ("IXERC-20Lockbox_NotNative" et "IXERC-20Lockbox_Native") se produisent lorsque l'utilisateur tente de déposer des jetons dans le mauvais contrat Lockbox. Un Lockbox peut être natif ou non natif, selon les types de jetons qu'il prend en charge.

Les Native Lockboxes conservent les jetons natifs, c’est-à-dire les jetons utilisés pour payer les frais de gaz aux validateurs. Un exemple de jeton qui aurait une Lockbox native pour l’encapsuler dans un jeton xERC-20 est ETH : pour encapsuler de l’ETH dans un jeton xERC-20, il faudrait appeler la fonction depositNative() de la Lockbox et déposer de l’ETH pour recevoir la représentation compatible ERC7281 de l’ETH.

Les Lockboxes réguliers (non natifs) conservent des jetons ERC-20 tels que USDC, DAI, WETH, USDT, etc. Pour frapper USDC en tant que jeton xERC-20, par exemple, l’utilisateur doit appeler deposit() sur le contrat Lockbox après avoir verrouillé USDC.

Appeler deposit() avec ETH entraînerait le verrouillage permanent de ces fonds, car le contrat Lockbox régulier ne peut emballer et déballer que des jetons ERC-20. Appeler depositNative() avec un jeton ERC-20 produirait des résultats similaires car les contrats Lockbox natifs sont destinés à fonctionner avec des jetons natifs, et non des jetons ERC-20.

De cette façon, en encapsulant les jetons ERC-20 canoniques dans des jetons xERC-20 avec prise en charge de la frappe/gravure, la Lockbox fournit une couche de compatibilité importante pour la norme. Cependant, dans certains cas, tels que l’intégration d’autres solutions de pontage dans xERC-20, l’utilisation uniquement du coffre-fort et le retour du jeton enveloppé ne sont pas une option. Pour cette raison, les projets peuvent mettre en œuvre des contrats d’adaptateurs.

Contrats d'adaptateur

Dans les cas où les protocoles de pontage ne sont pas conçus pour reconnaître les opérations inhérentes aux jetons xERC-20 (mint/burn, journalisation correspondante, etc.), les applications peuvent créer des contrats d’adaptateur. Ces contrats fonctionnent comme des wrappers et des déwrappers automatisés, traduisant efficacement le comportement standard ERC-20 approve + call en un schéma de frappe/gravure plus nuancé requis par xERC-20.

Cela est nécessaire car de nombreux protocoles de ponts (par exemple, le CCIP de Chainlink) restent optimisés pour le comportement ERC-20 conventionnel. Le contrat d'adaptateur peut combler cet écart de compatibilité en consacrant une telle logique : il dépose des jetons dans le Lockbox pour générer la représentation xERC-20 sur la chaîne source, et plus tard, lors de la réception du message sur la chaîne de destination, il déclenche le mécanisme de retrait pour revenir à l'actif canonique.

Ce flux garantit que l'utilisateur reçoit finalement un jeton canonique et cohérent, non affecté par les mécanismes d'emballage alimentés par xERC-20 sous le capot. De cette façon, les adaptateurs peuvent permettre aux protocoles de s'intégrer parfaitement avec des ponts non conformes à xERC-20 et augmenter le spectre des solutions interopérables qu'ils prennent en charge.

Pourquoi ERC-7281 ? Le cas d'une norme de jeton ponté souveraine

À un niveau élevé, l'ERC-7281 a quatre objectifs principaux :

1. Fongibilité : Les utilisateurs qui font le pont entre les jetons de la chaîne native du jeton et une autre chaîne (L1/L2) devraient toujours recevoir des représentations canoniques du jeton ponté à la destination. Plusieurs versions non fongibles du même jeton circulant sur une chaîne non native posent problème pour les raisons expliquées précédemment (par exemple, fragmentation de la liquidité et faible composabilité du jeton).

La vision originale de la création de la spécification ERC-20 était de garantir la fongibilité et l'interopérabilité transparente entre les jetons sur Ethereum à travers les applications et l'infrastructure Ethereum. Cependant, après avoir adopté une feuille de route de mise à l'échelle centrée sur le rollup, le problème du manque de composabilité atomique est apparu, et la création de nombreux domaines différents a dégradé ces propriétés de fongibilité. xERC-20 permet d'agréger la liquidité de divers ponts cross-chain en unifiant les jetons multi-rollup, restaurant la vision initiale d'Ethereum.

1. Sécurité : Pour réduire le risque de contrepartie, les émetteurs de jetons devraient avoir la possibilité de choisir parmi différents fournisseurs de ponts en fonction de l'évaluation de l'infrastructure de sécurité. De plus, les émetteurs de jetons devraient bénéficier d'une protection significative contre les conséquences des incidents de sécurité affectant les fournisseurs de ponts partenaires - des attaques isolées sur un ou deux services de pont ne devraient pas anéantir l'ensemble des TVL.

2. Démarrage sans liquidité pour les jetons cross-chain : les DAO de protocole ne devraient pas être contraints de dépenser des ressources significatives (financières) pour démarrer la liquidité des jetons reliés dans le cadre des plans d'expansion multi-chaînes. Non seulement le pontage basé sur la liquidité est mauvais pour l'expérience utilisateur, mais les dépenses en incitations à la fourniture de liquidité peuvent devenir inabordables pour les équipes de projet à mesure que le nombre de blockchains augmente rapidement.

3. Souveraineté pour les émetteurs de jetons: L'émetteur de jetons devrait rester maître de la représentation canonique des jetons de protocole émis sur des chaînes non natives. Résoudre le problème des jetons pontés non fongibles ne devrait pas nécessiter de céder le contrôle d'un jeton ponté d'un projet, en particulier des aspects administratifs tels que le contrôle de l'offre totale et la configuration des mécanismes de création et de destruction, à un pont tiers.

Nous pouvons approfondir ces objectifs pour voir quels avantages ERC-7281 offre aux protocoles et aux communautés.

Analyse des avantages de l’ERC-7281

Améliorer l'expérience utilisateur et éliminer la fragmentation de la liquidité

ERC-7281 résout diverses versions du problème de dépendance au chemin décrit dans l'introduction.

La dépendance au chemin peut être spécifique à la chaîne (par exemple, l'ETH ponté depuis Ethereum → Arbitrum → Optimism est différent de l'ETH ponté depuis Ethereum → Optimism → Arbitrum) ou spécifique au pont (par exemple, l'ETH ponté depuis Ethereum vers Optimism via Celer est différent de l'ETH ponté depuis Ethereum vers Optimism via Connext).

La dépendance au chemin est une fonctionnalité de sécurité précieuse, mais elle peut également être préjudiciable pour l'expérience utilisateur de pont et la composabilité cross-chain. Par exemple, un utilisateur ne peut pas fournir de manière programmable de la liquidité à un DEX cross-chain fonctionnant sur Optimism et Arbitrum car l'application doit accepter opETH ou arbETH.

ERC-7281 élimine le problème en introduisant des jetons xERC-20 qui restent fongibles, quel que soit le nombre de fois qu’un utilisateur ponte des chaînes ou les fournisseurs de ponts habitués à ponter les jetons. Supposons qu’un utilisateur souhaite transférer des USDT enveloppés d’Arbitrum à Optimism sans se retirer d’abord vers Ethereum ; un fournisseur de pont peut brûler des jetons xERC-20 sur Arbitrum et frapper des xERC-20 sur Optimism - la valeur des jetons frappés sur Optimism est toujours rattachée aux jetons déposés dans la Lockbox et sont remappés pour maintenir leur support 1:1.

Importamment, l'ERC-7281 offre les avantages de déployer un jeton ponté canonique comme le CCTP (Cross-Chain Transfer Protocol) de Circle sans exiger que le protocole ait la garde centralisée des jetons pontés. Par exemple, la liquidité est consolidée autour de la représentation canonique du jeton d'un projet, ce qui améliore l'utilité du jeton pour les applications DeFi et réduit les frais généraux liés à la création de différents marchés pour différentes versions du même actif.

Renforcer la souveraineté des émetteurs de jetons

Les xERC-20 sont décrits comme des jetons "pont souverain" car les émetteurs de jetons ne sont pas obligés d'utiliser une option particulière pour créer des représentations canoniques d'un jeton et conservent le contrôle de la conception et de l'administration des jetons pontés à travers les déploiements. L'ERC-7281 est un hybride entre "la création de jetons canoniques via un pont tiers" et "la création de jetons canoniques via un pont contrôlé par l'émetteur de jetons" qui combine la souveraineté, l'expérience utilisateur et la décentralisation dans le même package.

Les projets qui déploient des jetons cross-chain avec ERC-7281 peuvent créer des représentations canoniques de jetons natifs via plusieurs ponts sans rencontrer le problème de versions emballées non fongibles du même actif natif, ce qui compromet l'expérience utilisateur pour les utilisateurs espérant tirer parti de la composabilité et de la fongibilité des jetons ERC-20. De tels projets conservent également un niveau de contrôle similaire sur les déploiements cross-chain d'un jeton, comme un émetteur de jeton exécutant une infrastructure interne pour gérer les transferts de jetons canoniques entre les domaines, étant donné que les contrats de jetons xERC-20 et Lockbox - que les ponts utilisent pour verrouiller, créer et brûler des jetons pour les utilisateurs - sont déployés et contrôlés par le projet.

Cette fonctionnalité discrète peut être pratique dans les cas où un projet de grande envergure a un jeton natif émis sur la chaîne domestique. Les utilisateurs d’autres écosystèmes souhaitent s’exposer au jeton sans le conserver sur sa chaîne native pour différentes raisons.

Pourtant, le projet n’a pas la capacité ou la volonté d’exécuter une infrastructure de pontage interne pour chaque chaîne afin d’assurer une compatibilité 1:1 entre les jetons pontés, et il ne veut pas non plus céder le contrôle de son jeton à un tiers qui n’est pas nécessairement aligné avec le protocole et sa communauté. Un tel cas devient une prise en compte lors de la mise en œuvre d’une gouvernance inter-chaînes qui permet de voter avec des jetons pontés pendant que les votes sont comptés sur la chaîne native ; Un fournisseur de pont non aligné avec le contrôle des jetons pontés devient un point d’étranglement pour la gouvernance du protocole.

Beefy, un protocole de yield farming, a également adopté xERC-20 pour cette raison. Comme le décrit la documentation du pont du projet, ERC-7281 a fourni au projet plus d’options pour les jetons de pontage – ce qui était devenu nécessaire après qu’un partenaire majeur du pont ait subi un piratage (un thème qui devient rapidement familier aux crypto-natifs) – et a fourni un contrôle plus précis de la conception des mécanismes de pontage. Dans le cas de Beefy, la fonction de liste d’autorisation de l’ERC-7281 a permis au protocole de sélectionner divers partenaires de pontage et d’offrir aux utilisateurs différentes options entre l’optimisation de la vitesse, la décentralisation, les coûts et la sécurité lors du pontage des jetons mooBIFI.

La réalignement des incitations améliore la concurrence ouverte et la sécurité

Le pontage basé sur la liquidité favorise souvent les projets ayant la capacité financière de dépenser pour des incitations à la liquidité - puisque les émetteurs de jetons veulent dépenser peu en incitations LP et offrir une expérience utilisateur de transition supérieure, la liquidité devient le facteur le plus crucial pour les protocoles utilisant des ponts canoniques L1/L2. Cela s’étend également à la sélection des fournisseurs de ponts par les agrégateurs de ponts, ce qui rend sans doute plus difficile pour les nouveaux services de pontage (même ceux dotés d’une infrastructure sécurisée) de concurrencer les protocoles de pontage plus établis.

ERC-7281 remédie au problème en éliminant le besoin de ponts basés sur la liquidité. Sans avoir besoin de créer et d'échanger des jetons non canoniques contre des jetons canoniques, des ponts de toute taille peuvent être approuvés pour créer le jeton d'un projet sur un domaine distant. Comme les émetteurs de jetons veulent minimiser l'exposition aux défaillances des ponts, il est probable que davantage de protocoles commenceront à accorder plus d'attention aux conceptions de sécurité des ponts inter-chaînes au lieu de se concentrer d'abord sur la liquidité.

Cela encourage la concurrence ouverte, car il s’agit de « laisser le pont le plus sûr gagner » et non de « laisser le pont le plus liquide gagner » ; cette concurrence ouverte peut prendre la forme de ponts concurrents sur d’autres fonctionnalités que la liquidité et la sécurité (par exemple, les frais, les API/SDK, les intégrations d’applications, etc.). Ces fonctionnalités sont sans doute plus faciles à intégrer dans une application dès le départ, car elles dépendent principalement de l’expertise de l’équipe de développement ; En revanche, les liquidités et les volumes de transition sont plus complexes à amorcer et nécessitent un mélange de développement commercial, de financement, de relations avec l’industrie, de marketing, etc.

Meilleure gestion des risques pour les émetteurs de jetons

ERC-7281 introduit une limite de taux configurable sur le mintage et la combustion de jetons qui améliore considérablement le profil de risque pour les protocoles travaillant avec des ponts tiers pour minter des jetons canoniques sur des chaînes non natives. Si un fournisseur de pont partenaire est piraté ou compromis, les dommages les plus importants qu'un attaquant peut causer sont équivalents à la limite attribuée au pont compromis. Si un émetteur de jetons choisit soigneusement les paramètres de limitation de taux, les attaques isolées sur un pont devraient avoir un impact minimal sur la solvabilité du protocole.

La configuration de limites de débit par pont peut également améliorer le processus d’évaluation des risques pour les DAO de protocole. À l’heure actuelle, l’évaluation des risques liés aux ponts peut prendre des mois en raison de l’ampleur de l’impact du piratage d’un pont tiers canonique. Les protocoles veulent s’assurer de prendre des décisions défendables, où la sécurité du pont choisi est examinée de manière approfondie pour donner à la communauté des garanties de sécurité plus solides. En plus d’être une perte inutile d’efforts et de temps, les analyses marathon de la sécurité des ponts ne garantissent toujours pas qu’un pont choisi est à l’abri des exploits zero-day.

L'adoption de l'ERC-7281 rend l'évaluation des risques plus dynamique. Les projets doivent toujours mener des diligences préalables sur les fournisseurs de ponts pour choisir les propriétés de limitation de taux appropriées; cependant, les délais d'évaluation des risques peuvent être réduits pour refléter le fait que les protocoles ne sont plus dans une position tout ou rien. Au lieu de passer des mois à analyser plusieurs ponts pour en choisir un, un projet peut passer la moitié du temps à choisir initialement plusieurs fournisseurs de ponts et à définir des limites de création variables en fonction d'une évaluation de la sécurité. L'émetteur de jetons peut ensuite procéder à des examens de sécurité pour déterminer s'il doit augmenter ou diminuer les limites de création pour certains partenaires de pont ou retirer les droits de création d'un pont (par exemple, en réponse à un piratage ou à une divulgation de vulnérabilité).

L’ERC-7281 réduit également l’obstacle pour les projets qui souhaitent opter pour des avancées de pointe en matière de sécurité des ponts, mais qui hésitent à adopter une technologie particulière dans son intégralité jusqu’à ce que la technologie ait été testée et rigoureusement approuvée par la communauté (c’est-à-dire le dilemme de l’innovateur). Supposons qu’un fournisseur de ponts propose une nouvelle infrastructure qui améliorerait considérablement les garanties de sécurité. Dans ce cas, un protocole peut « tâter le terrain » en attribuant des droits de frappe limités au pont et en augmentant progressivement la limite de frappe du pont à mesure que la confiance dans la conception du système proposé augmente.

Tout comme la suppression des problèmes liés à la liquidité, la suppression de la nécessité pour un protocole de faire confiance à 100 % à la pile technologique d’un pont avant d’attribuer des droits de frappe crée une concurrence égale entre les nouveaux entrants et les anciens acteurs – les anciens acteurs sont incités à itérer sur de meilleures approches de la sécurité, car les émetteurs de jetons ont désormais la possibilité de retirer les droits de frappe et de les réaffecter à un projet plus petit simplement parce que ce dernier a démontré un engagement plus élevé en faveur de la sécurité et de la décentralisation. Cela élimine également un autre facteur de risque pour les protocoles fonctionnant avec des ponts tiers : le risque qu’un fournisseur de ponts sélectionné cesse d’innover en matière de sécurité malgré le rythme rapide auquel les défauts et les problèmes de sécurité des ponts sont divulgués et découverts, car il sait que l’émetteur de jetons ne peut pas appliquer d’actions punitives (par exemple, migrer vers un autre fournisseur de ponts) en raison de la difficulté d’exécuter de telles activités.

Améliorer la composabilité entre les écosystèmes

Il est aujourd’hui difficile de créer des flux de travail d’application complexes qui nécessitent de router les jetons à travers n’importe quel nombre de chaînes en raison de la tarification imprévisible des ponts basés sur la liquidité. Par exemple, un agrégateur de ponts reliant Ethereum → Linea → Base a deux options :

1. Définissez un paramètre de tolérance de glissement et d'exécution des prix de routage inter-chaînes basé sur le montant minimum de jetons qu'un utilisateur recevra sur chaque chaîne (en fonction du montant de liquidité disponible lorsque le message de pontage arrive à chaque couche).
2. Ne définissez pas de paramètre de tolérance de glissement ; au lieu de cela, créez une logique pour sourcer la liquidité on-chain (par exemple, via des DEX) si le montant de jetons reçus sur une ou plusieurs chaînes est inférieur au montant attendu.

En comparaison, les agrégateurs de ponts peuvent savoir à l’avance combien de jetons ils doivent attendre sur chaque domaine impliqué dans une transaction inter-chaînes en vérifiant mintingLimit et burningLimit pour les ponts autorisés à frapper un jeton particulier. Certes, un pont peut atteindre maxLimit entre le moment de la diffusion de la transaction et l’arrivée de la transaction dans un domaine, ce qui signifie que l’utilisateur ne peut pas recevoir de jetons canoniques à la destination.

Cependant, ERC-7281 est toujours une amélioration à cet égard pour les raisons suivantes :

1. Si un opérateur de pont atteint mintingLimit alors qu’une transaction est en cours, la transaction de transition est suspendue et réessayée ultérieurement lorsque les paramètres de limite de débit sont ajustés. Les utilisateurs ne reçoivent pas de représentation enveloppée propriétaire du jeton canonique, contrairement aux ponts de liquidité actuels.
2. Les agrégateurs de ponts ont plus de prévisibilité quant au moment où une transaction de pontage sera exécutée et au nombre de jetons à prévoir. Étant donné que mintingLimit et burningLimit sont configurés pour utiliser des blocs comme mesure de temps (comme indiqué dans la section sur les paramètres de limitation de taux), il est facile de calculer quand un pont recommencera à frapper et à brûler des jetons ; en revanche, prédire quand la liquidité augmentera dans un bridge équivaut à jouer à la roulette russe.

Les variations imprévisibles de la liquidité signifient également une imprévisibilité dans la tarification des opérations de relais. Supposons qu’un agrégateur de pont (ou une autre application) place une cotation pour un swap inter-chaînes en fonction du prix actuel d’une paire de jetons dans le pool de liquidité d’un pont (ce prix est basé sur la liquidité totale du pool). Néanmoins, la transaction ne peut pas être exécutée en raison d’une forte diminution de la liquidité du pool. Supposons que l’échange soit suspendu et retenté plus tard. Dans ce cas, le développeur de l’application ne peut pas savoir si la cotation précédente reste exacte ou si la liquidité atteindra les mêmes niveaux que lorsque l’utilisateur a soumis la transaction pour la première fois.

Étant donné que le pontage des jetons xERC-20 n'est pas soumis aux mouvements de liquidité, les utilisateurs peuvent être certains que les transactions cross-chain ne subiront pas de glissement, même si elles ne sont pas exécutées immédiatement.

Les agrégateurs de pontage ne sont pas les seuls à bénéficier de cette amélioration de la composabilité ; toute application inter-chaînes peut exploiter la fongibilité des jetons xERC-20 pour créer des applications plus intéressantes. C’est plus difficile aujourd’hui en raison de problèmes liés à la dépendance au chemin : supposons qu’un développeur souhaite faire le pont entre l’ETH et l’Ethereum, ouvrir une position de prêt sur un DEX Arbitrum et utiliser les bénéfices pour acheter un NFT sur Optimism avant de revenir à l’Ethereum. Ici, le développeur doit s’assurer de s’intégrer avec les fournisseurs de ponts sur ces chaînes, car vous ne pouvez pas facilement échanger des versions propriétaires, ce qui n’est pas le cas une fois que les jetons pontés d’un projet sont fongibles après l’adoption de xERC-20.

Ce flux de travail est similaire aux ponts jeton-émetteur décrits précédemment. Prenons l’exemple de Circle CCTP :

Le protocole de transfert inter-chaînes de Circle permet aux utilisateurs d’avoir une version unifiée et canonique de son jeton USDC sans être piégés dans l’écosystème de leurs chaînes. Tous les transferts inter-chaînes sont traités par son protocole en utilisant le schéma burn-and-mint.

Cependant, alors que le CCTP est un protocole centralisé, les opérateurs de Circle sont les seules entités autorisées à brûler et à émettre ses jetons USDC, xERC-20 liquide le risque de confiance en permettant à plusieurs entités avec divers mécanismes de sécurité d'opérer des transferts cross-chain.

Soutenir la vision d'Ethereum d'un avenir centré sur le rollup et multichaîne

L’ERC-7281 peut accélérer la feuille de route d’Ethereum centrée sur le rollup en donnant aux projets la confiance nécessaire pour déployer des jetons sur de nouveaux EVM L2 qui peuvent ne pas avoir les profils de sécurité solides des chaînes L2 établies. Par exemple, le pont canonique d’un rollup de niveau 0 est moins sécurisé car Ethereum L1 ne garantit pas la sécurité du pont. Un projet de jeton peut lentement se déployer dans une telle chaîne en accordant des droits de frappe limités au pont canonique et en augmentant la limite de frappe une fois que le rollup passe à l’étape 1.

Ce processus peut se poursuivre jusqu’à ce que le technicien L2 atteigne l’étape 2 (l’étape la plus élevée de la décentralisation et de la sécurité pour un cumul). Un mécanisme par lequel les protocoles peuvent être déployés sur des chaînes nouvellement lancées de manière à minimiser les risques profite à l’écosystème Ethereum en facilitant l’amorçage de la liquidité et des applications des jetons par les nouveaux L2, tout en encourageant davantage d’innovation dans l’espace de conception du rollup.

Inconvénients potentiels de la mise en œuvre de l’ERC-7281

Augmentation des frais généraux pour les équipes de gestion de projet DAO

Bien que l'ERC-7281 soit très attrayant pour les protocoles, les DAO peuvent hésiter à adopter des jetons xERC-20 en raison des frais opérationnels importants que les équipes de projet DAO doivent supporter pour gérer les jetons xERC-20 sur divers déploiements.

L’œuvre de Gérard Persoon Gérer les tokens pontés sur un grand nombre de chaînes comprend une liste non exhaustive de tâches ponctuelles et récurrentes que le protocole doit effectuer après la migration de ERC-20 vers xERC-20 :

C'est une très longue liste de tâches

Une solution proposée consiste à externaliser certaines de ces tâches administratives liées à la gestion des jetons xERC-20 inter-chaînes des DAO auprès de services tiers, mais il s'agit simplement d'échanger un compromis (coûts des ressources humaines) avec un autre (coûts de services embauchés).

Suppose a protocol previously managed cross-chain tokens with in-house infrastructure (e.g., deploying a separate token contract per chain and controlling minting and burning). In that case, ERC-7281 doesn’t seem like a radical change. However, projects used to outsource the management of core bridging infrastructure to bridge development teams will find the additional workload concerning.

Par exemple, a décrit un membre de l’équipe principale du Lido(en réponse à une proposition de Lido pour déployer wstETH en tant que jeton xERC-20 sur tous les déploiements) les responsabilités actuelles de l'équipe PM concernée par l'infrastructure d'interopérabilité et a contrasté l'ensemble avec l'ensemble des responsabilités que les mêmes membres de l'équipe devraient assumer si le DAO de Lido votait pour que tous les domaines migrés de wstETH à une version xERC-20.

Comme le montre la conversation ci-dessus, la gestion des tokens xERC-20 impose une augmentation non négligeable de la surcharge administrative pour les protocoles et les membres de la communauté. Par exemple, les limites de pont nécessitent une surveillance et une évaluation actives de la sécurité du pont pour éclairer les ajustements des limites de frappe, et les décisions concernant les limites de pont (ou le retrait/l’attribution des droits de frappe) peuvent être soumises à un vote DAO (si de tels choix doivent être faits fréquemment, les membres de la DAO peuvent souffrir de fatigue des électeurs).

Cela ne doit cependant pas être interprété comme un jugement de valeur sur l'ERC-7281. Chaque projet aura des profils de risque différents, des objectifs à long terme et des ressources, et ces facteurs déterminent collectivement si les avantages à long terme de l'adoption de l'ERC-7281 l'emportent sur les coûts à court terme et continus qui en découlent.

Par exemple, les petits projets peuvent avoir plus de mal à gérer les frais généraux liés à l’émission de jetons xERC-20 et choisir d’opter pour un service de pontage de jetons multichaînes géré comme l’ITS (Interchain Token Service) d’Axelar ou le NTT (Native Token Transfers) de Wormhole. Les projets plus établis peuvent avoir les ressources nécessaires pour gérer les coûts administratifs et opérationnels de l’émission d’un jeton xERC-20 et peuvent considérer que le contrôle offert par ERC-7281 vaut la peine de payer les frais généraux supplémentaires liés à la gestion des jetons inter-chaînes.

Difficultés autour de la migration des jetons existants vers la norme xERC-20

Pour les projets qui ne disposent pas d’une interface mint/burn, ou qui ne peuvent pas mettre à niveau les contrats de tokens pour utiliser IERC20 via l’héritage, et qui ont déjà des représentations canoniques de tokens natifs circulant sur des chaînes non natives, la migration vers les tokens xERC-20 est un processus long qui nécessite beaucoup de coordination et implique un réseau complexe de participants, allant des détenteurs de tokens, les échanges (DEX et CEX), les ponts partenaires et les applications intégrées avec l’ancien jeton ERC-20. Même avec cette partie gérée, les protocoles supportent toujours le coût de l’emballage des ERC-20 en xERC-20 pour terminer le processus de migration.

Comme expliqué dans la discussion de la spécification ERC-7281, les jetons existants devront être verrouillés dans le Lockbox pour émettre des xERC-20 enveloppés pour les utilisateurs. La mise au coucher du jeton ERC-20 hérité se produit peu de temps après et implique un autre processus prolongé de communication avec la communauté sur le calendrier de gel de l'émission de nouveaux jetons ERC-20 (hérités). Encore une fois, cela peut valoir le coût d'un point de vue protocolaire, bien que les avantages puissent également être insuffisants pour justifier les coûts de coordination d'une migration à l'échelle de l'écosystème vers la représentation compatible xERC20 du jeton d'un protocole.

Surface de risque plus grande pour la gouvernance DAO

La gestion des jetons xERC-20 sur plusieurs domaines avec ERC-7281 nécessite une gouvernance active de la part du DAO supervisant le protocole. Cela implique de définir des paramètres tels que les limites de création, la mise à niveau du contrat Lockbox, et la suspension de la création ou de la destruction de jetons. Ces décisions sont sensibles à la sécurité et doivent être régies par le DAO pour éviter la responsabilité des décisions prises en huis clos.

L’ERC-7281 vise à donner aux protocoles le contrôle de ces décisions plutôt que des ponts tiers. C’est logique, car les DAO gèrent déjà des tokens sur leurs chaînes natives, il est donc raisonnable d’étendre leur gouvernance aux tokens d’autres chaînes pour les protocoles et les communautés qui recherchent ce contrôle. Cependant, certains protocoles peuvent ne pas vouloir ce contrôle supplémentaire de la DAO en raison de préoccupations concernant la gouvernance et la stabilité.

Par exemple, des projets de haut niveau comme Lido font l'objet d'un examen minutieux en ce qui concerne les problèmes de gouvernance. Le fait d'ajouter un contrôle sur la gestion des jetons accroît le risque d'une prise de contrôle de la gouvernance. Une attaque contre la gouvernance pourrait avoir des effets généralisés si un projet consolide tous les jetons ERC-20 dans un coffre-fort et que le DAO le gouverne. Un attaquant pourrait prendre le contrôle du coffre-fort et introduire un fournisseur de pont malveillant sans limites de création, rendant ainsi les jetons xERC-20 sur d'autres chaînes sans valeur.

Ce scénario a des parallèles avec l'exploit Multichain, où une vulnérabilité dans l'infrastructure de signature de calcul multipartite (MPC) a permis aux pirates informatiques de compromettre les adresses Multichain principales qui étaient en garde des jetons natifs sur Ethereum et Dogecoin - ces jetons soutenaient des jetons émis sur des chaînes non natives comme Fantom et Moonriver, ce qui a créé un effet domino qui a entraîné des pertes pour des projets ailleurs en raison de l'attaque sur les contrats intelligents de Multichain sur Ethereum et Dogecoin.

Incompatibilité avec les protocoles maximale décentralisés

ERC-7281 répond à l’objectif lorsque le jeton est émis par un protocole avec gouvernance de jeton ou une entité centralisée (par exemple, l’USDC de Circle ou le Stablecoin CZKC). Cependant, il n’est pas aussi précieux si le protocole est décentralisé au maximum et manque de gouvernance formelle - le stablecoin LUSD de Liquity est un exemple de jeton qui serait difficile à rendre compatible avec la norme xERC-20.

Le jeton xERC-20 exige qu’une entité décide de paramètres spécifiques tels que les limites de minting et de burn, et qu’elle prenne des décisions telles que l’ajout ou non de certains fournisseurs de ponts sur liste blanche. Cela implique la nécessité d’une gouvernance continue pour l’existence du jeton xERC-20. Pour les projets qui souhaitent décentraliser des composants critiques du protocole, tels que le contrat de jeton de la DAO, au fil du temps, cela peut poser des problèmes et compliquer les plans de décentralisation.

Risque accru d’exploits affectant les composants clés (fournisseurs de contrats Lockbox et de ponts)

Nous avons déjà mentionné comment fonctionne la dépendance de chemin et pourquoi elle permet de garantir qu’un exploit affectant la chaîne A n’affectera pas la chaîne B, ou qu’un exploit impliquant le pont A sur la chaîne A n’affectera pas le pont B sur la chaîne B. ERC-7281 supprime la dépendance du chemin, ce qui présente des avantages, mais introduit également un compromis autour de la sécurité :

La liquidité maximale disponible dans un pont ne représente plus une limite supérieure sur l'impact potentiel d'une exploitation d'un pont sur l'émetteur de jetons, car les jetons émis par différents fournisseurs de ponts sont fongibles entre les domaines. Les auteurs de l'ERC-7281 proposent de choisir une limite de taux pour les fournisseurs de ponts en fonction du montant qu'un émetteur de jetons peut dépenser pour compenser les pertes liées à l'émission frauduleuse ; néanmoins, une limite de taux sélectionnée aurait peut-être été trop conservatrice rétrospectivement.

Si un pont avec une limite élevée est compromis, les effets peuvent être prononcés, même pour les utilisateurs d’autres ponts qui frappent le même jeton. Les protocoles peuvent réduire le risque en répartissant les droits de minting sur un grand nombre de ponts (de sorte qu’un fournisseur de ponts n’a pas un nombre démesuré de jetons qu’il peut frapper par rapport à d’autres ponts), mais essayer de couvrir le risque de cette manière peut augmenter l’inefficacité car chaque pont nécessitera une évaluation indépendante de la part de l’équipe DAO et la coordination avec plus de ponts augmente la surcharge administrative que nous avons mentionnée précédemment.

Le contrat Lockbox régi par une DAO pourrait introduire des effets de contagion négatifs en cas d’attaque de gouvernance. Mais même avec une gouvernance DAO sécurisée, un bug dans les contrats Lockbox natifs/non natifs sur la chaîne domestique du jeton peut causer tout autant de problèmes (Sifu est maintenant le propriétaire du contrat Lockbox pour un projet, et les fonds ne sont plus SAFU). En comparaison, ce problème est réduit dans le statu quo car les contrats de coffre-fort (l’équivalent du contrat Lockbox du fournisseur de pont) ne contiennent que des jetons pontés via le service de pont correspondant. Ainsi, un bogue dans le contrat de coffre-fort d’un fournisseur n’affecte que les utilisateurs qui ont déposé des jetons avec ce pont.

Surcharge pour les intégrations d’écosystème

Le travail administratif supplémentaire avec ERC-7281 affecte également les développeurs d’applications et les fournisseurs de services utilisant le jeton xERC-20 d’un projet. Les agrégateurs de ponts doivent suivre les mappages entre les jetons xERC-20 et leurs contrats Lockbox correspondants afin d’éviter des problèmes tels que les jetons de spam et les attaques par usurpation d’identité. Bien qu’un registre de ces mappages puisse être utile, la mise en place d’un tel registre est difficile sans risquer la centralisation ou exposer les utilisateurs de xERC-20 à des menaces.

Le risque provient des attaquants potentiellement ajoutant des contrats malveillants au registre de jetons et trompant les utilisateurs et les développeurs en envoyant des jetons à la mauvaise adresse. Cela pourrait entraîner un vol de jetons sur les réseaux L2 et L1. Les échanges sont confrontés à des défis similaires, car des jetons contrefaits pourraient causer de graves problèmes, tels que des comportements de jetons inattendus, différents des jetons canoniques approuvés.

Conclusion

ERC-7281 présente une solution convaincante aux problèmes des jetons pontés non fongibles et offre des fonctionnalités qui améliorent l’expérience utilisateur, la décentralisation, la sécurité et la flexibilité dans les conceptions de pontage de jetons. Certains de ces problèmes ont un impact direct sur la viabilité de la feuille de route centrée sur le rollup, ce qui fait de la norme xERC-20 une infrastructure essentielle pour l’écosystème Ethereum L2.

Plusieurs acteurs clés dans l'espace de pontage, y compris Hyperlane, Omni, Sygma, Router Protocol et Everclear, se sont engagés à adopter l'ERC-7281, ce qui indique une traction significative pour la proposition. Même les émetteurs de jetons établis (qui disposent de mécanismes de travail pour le pontage de jetons), tels que Circle, ont montré un intérêt pour l'ERC-7281 afin de relever les défis posés par les jetons non approuvés affectant les utilisateurs et les développeurs.

ERC-7281 résout ces problèmes tout en atténuant de nombreux compromis associés aux approches précédentes de création de jetons canoniques sur des domaines distants. Il fournit un amorçage sans liquidité, contrairement aux ponts enchâssés, ne nécessite pas d’infrastructure personnalisée comme les ponts jetons-émetteurs et évite la dépendance vis-à-vis d’un fournisseur en autorisant la frappe de jetons canoniques multi-ponts par des fournisseurs de ponts approuvés.

Pour ceux qui souhaitent suivre la discussion autour de l'ERC-7281 ou les développeurs souhaitant intégrer xERC-20, la Confrérie des Magiciens d'Ethereum et le site web du xERC-20 sont d’excellentes ressources. La communauté a également bâti un lanceur xERC-20 pour agréger les outils de création, de surveillance et de gestion des jetons xERC-20, un outil précieux pour les constructeurs qui cherchent à déployer un jeton xERC-20 pour la première fois ou à migrer un jeton existant vers la norme de jeton xERC-20.

Démenti:

1. Cet article est reproduit de [Recherche 2077]. Tous les droits d’auteur appartiennent à l’auteur original [Recherche 2077]. Si vous avez des objections à cette réimpression, 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 des conseils en investissement.
3. L'équipe de Gate Learn traduit l'article dans d'autres langues. Copier, distribuer ou plagier les articles traduits est interdit sauf mention contraire.