Introduction:

Dans l'écosystème Web3, le pont inter-chaînes est une partie très importante. C'est une installation clé pour briser les silos inter-chaînes et réaliser l'interconnexion multi-chaînes. Dans le passé, les gens étaient très actifs dans l'exploration et la pratique de la technologie inter-chaînes. Le nombre de produits de pont inter-chaînes associés a atteint des centaines. Certains s'engagent à construire une couche d'interopérabilité unifiée, tandis que d'autres essaient d'ouvrir la circulation des actifs multi-chaînes. Ils ont des visions et des compromis différents en termes de solutions techniques.

Ce que cet article veut discuter, c'est: Quel est l'avenir des ponts inter-chaînes? Quels types de protocoles inter-chaînes sont plus prometteurs? Quelles applications inter-chaînes sont plus susceptibles de connaître une adoption de masse? Comment les développeurs devraient-ils construire des applications inter-chaînes? Dans ce qui suit, l'auteur discutera de la tendance de développement des ponts inter-chaînes et présentera trois arguments clés:

Une nouvelle génération de ponts inter-chaînes sûrs et performants deviendra la norme

Les applications de chaîne complète deviendront un nouveau paradigme de dApp

· Les ponts officiels des émetteurs d’actifs tels que l’USDC remplaceront les ponts de swap de liquidité

La technologie inter-chaînes peut être comprise comme une extension de l'expansion de capacité. Lorsqu'une chaîne n'est pas suffisante pour traiter toutes les demandes de transaction, laissez plusieurs chaînes les transporter et utilisez des ponts inter-chaînes pour les connecter. Pour comprendre les ponts inter-chaînes, nous devons d'abord clarifier les problèmes que les ponts inter-chaînes doivent résoudre, afin de les diviser en différents niveaux.

Évolution des ponts inter-chaînes au niveau du protocole

Le cœur de la couche de protocole est un mécanisme de sécurité pour la transmission de messages inter-chaînes, c'est-à-dire une méthode de vérification des messages inter-chaînes. Selon les différentes méthodes de vérification et les idées de Vitalik et d'autres, l'industrie a divisé les ponts inter-chaînes en trois types : échange atomique basé sur des verrous temporels de hachage, vérification de témoin et vérification de client léger. Plus tard, le fondateur de Connext, Arjun Bhuptani, a résumé les ponts inter-chaînes en trois paradigmes : vérification locale, vérification externe et vérification native.

Parmi eux, la vérification locale s'applique uniquement aux actifs inter-chaînes, ne peut pas prendre en charge tout message inter-chaînes, et l'expérience utilisateur n'est pas conviviale (nécessite deux actions de l'utilisateur pour terminer une transaction). Certains des premiers ponts inter-chaînes ayant adopté ce schéma ont changé de cap et abandonné cette voie. La vérification native est la plus sûre, mais le coût est trop élevé. D'une part, le coût en gaz pour les utilisateurs est trop élevé, et même dans certains cas, il n'est pas du tout rentable sur le plan économique. D'autre part, le coût de codage pour les développeurs est trop élevé. Pour se connecter à différentes blockchains, ils doivent développer séparément des programmes de vérification de client léger correspondants. Le volume d'ingénierie est extrêmement important, et la portée d'application est extrêmement limitée. Enfin, la plupart des ponts inter-chaînes utilisent encore des solutions de vérification externes. Les coûts en gaz pour l'utilisateur et les coûts de développement et de mise en œuvre sont relativement faibles, et prennent en charge tout message à travers la chaîne. Cependant, ce qui a été le plus critiqué à propos de la vérification externe est la sécurité. Que ce soit Multichian, qui a connu des tempêtes cette année, ou RoninBridge (pont officiel Axie Infinity) et HorizenBridge (pont officiel de Harmony Chain), qui se sont fait voler leurs clés par des pirates informatiques, ils nous disent tous qu'une simple solution de vérification externe ne peut pas être la fin des ponts inter-chaînes!

Les risques de sécurité liés aux ponts inter-chaînes entravent le développement de dApps inter-chaînes. La couche applicative est très prudente lors de la conception des services correspondants. Premièrement, il est nécessaire d’éviter autant que possible les liens liés à l’interopérabilité inter-chaînes, et deuxièmement, les applications bien connues ont tendance à construire leurs propres ponts inter-chaînes (c’est le cas des principaux projets DeFi tels que AAVE, Maker et Compound). Comme vous pouvez l’imaginer, dans une ville où la sécurité est très faible, les gens choisiraient de ne pas voyager, et les riches amèneraient leurs propres gardes du corps lorsqu’ils voyagent.

Ce qui est encourageant, cependant, c'est qu'une nouvelle génération de ponts inter-chaînes plus sûrs se développe rapidement. Parmi eux se trouvent des ponts à double couche de sécurité tels que LayerZero et Chainlink CCIP ; des ponts ZK (projets représentatifs : Polyhedra, MAP Protocol, Way Network) qui combinent la technologie ZK avec des clients légers ; des ponts de vérification optimistes qui utilisent des mécanismes de jeu économique pour protéger la sécurité inter-chaînes (projets représentatifs : Nomad, cBridge) ; et ceux qui combinent les technologies ZK et TEE (projet représentatif : Bool Network).

[Si vous voulez connaître leur mécanisme spécifique, veuillez vous référer à l'article précédent de l'auteur “Multichain Has Fallen, How to Save the Cross-Chain Bridge?”]

En bref, l'infrastructure de pont inter-chaînes de nouvelle génération assure une sécurité accrue sans sacrifier les performances, offrant une garantie solide pour la couche d'application dans les conceptions liées à l'interopérabilité inter-chaînes.

Le changement de paradigme de l'interaction inter-chaînes au niveau de l'application

Initialement, presque tous les dApps étaient déployés sur Ethereum car il n'y avait pas d'options. Cependant, avec la prospérité de l'écosystème de la couche d'application, Ethereum a été submergé. Cela a donné aux autres chaînes publiques l'occasion de se développer. Divers tueurs d'ETH, ainsi que des sidechains et des Layer 2, sont apparus les uns après les autres.

Du point de vue des dApps, Ethereum est une mégapole comme Shanghai, qui a une grande population mais des ressources limitées et un pouce d'argent. Si mon scénario commercial nécessite un débit élevé mais n'exige pas une interopérabilité élevée, alors je peux le déployer sur une chaîne latérale qui n'est pas trop encombrée. Par exemple, vous n'avez pas besoin d'ouvrir une usine d'impression ou une plantation à Shanghai; vous pouvez choisir un emplacement dans la banlieue. L'histoire de dYdX quittant Ethereum est probablement familière à tout le monde.

En même temps, une dApp peut être déployée sur plusieurs chaînes pour participer à des "opérations de chaîne", servir les utilisateurs de différentes chaînes et étendre l'échelle et les revenus. Par exemple, Sushiswap, le premier cas réussi d'une attaque de vampire, a été déployé frénétiquement sur 28 chaînes. Comme on peut l'imaginer, il y a essentiellement Sushiswap sur la chaîne publique du nom.

Cependant, cet écosystème d'application multi-chaînes a offert aux utilisateurs une expérience très médiocre : pour interagir avec des applications sur différentes chaînes, vous devez également comprendre les différences entre les différentes chaînes, enregistrer des adresses sur plusieurs chaînes, recharger des frais de gaz sur chaque chaîne, et enfin déplacer des actifs d'une chaîne à l'autre - oh la la, c'est tellement fatigant!

Plus important encore, de nombreux protocoles DeFi impliquent l'utilisation de liquidité. Si vous déployez sur plusieurs chaînes, vous devez guider la liquidité sur plusieurs chaînes. Cela entraînera une dispersion de la liquidité sur différentes chaînes et non partagée en profondeur, et les utilisateurs subiront un impact de prix plus important lors des échanges. En réponse, certaines personnes s'inquiètent du développement de l'Ethereum L2, estimant que le L2 pourrait compromettre la liquidité d'Ethereum et faire perdre son avantage concurrentiel. Il y a aussi des chercheurs qui ont proposé une solution de liquidité unifiée comme SLAMM, mais cette solution crée plus de problèmes qu'elle n'en résout. C'est très nul, donc je ne vais pas entrer dans la description ici. Les amis intéressés peuvent consulter les documents pertinents.

La vraie question fondamentale est : comment les ressources et les écosystèmes de chaque chaîne peuvent-ils être agrégés de manière à ce que les utilisateurs n'aient pas à être conscients de l'existence d'une “chaîne”? Par exemple, j'ai 1 ETH, puis-je l'utiliser où je veux et masquer le processus d'échange automatique et de paiement des frais de gaz sur différentes chaînes? Je veux utiliser une application, puis-je l'utiliser sur n'importe quelle chaîne sans croiser les actifs? En même temps, la partie projet n'a plus à faire la queue pour sélectionner une chaîne. Au lieu de se déployer à plusieurs reprises sur plusieurs chaînes, il peut être déployé sur la chaîne la plus adaptée, puis les personnes sur différentes chaînes peuvent l'utiliser?

La couche d'application nécessite un nouveau paradigme pour masquer la couche "chaîne". Certaines personnes ont imité le concept d'"abstraction de compte" et ont créé un nouveau terme appelé "abstraction de chaîne", c'est ce que cela signifie. Jetons un coup d'œil à comment fonctionne un projet LSD ?

Par exemple, Bifrost prétend être le pionnier du LSD à chaîne complète, en utilisant une architecture différente de celle des autres produits LSD. Bifrost a sa propre chaîne, Bifrost Parachain, qui est la parachain de Polkadot. Le module de jalonnement de liquidité de Bifrost n’est déployé que sur Bifrost Parachain, et la liquidité de son actif LSD, vToken, est également entièrement sur Bifrost Parachain, mais d’autres chaînes peuvent utiliser le module de jalonnement de liquidité de Bifrost Parachain et la liquidité par le biais d’appels à distance. En conséquence :

• Les utilisateurs peuvent créer des vTokens sur d'autres chaînes;
• Les utilisateurs peuvent échanger des vTokens sur d'autres chaînes;
• Les utilisateurs peuvent échanger des vTokens sur d'autres chaînes, mais ce qui se cache derrière cela, c'est la liquidité de la chaîne Bifrost;
• Les utilisateurs peuvent fournir de la liquidité au pool vToken/Token sur le parachain Bifrost sur d'autres chaînes et obtenir des jetons LP;
• Les utilisateurs peuvent détruire des jetons LP sur d'autres chaînes pour récupérer de la liquidité.

Les utilisateurs ne peuvent pas ressentir du tout le processus de livraison inter-chaînes derrière ces opérations. Tout se passe comme si c'était fait localement. Tout le monde peut l'expérimenter à travers l'application Omni LSD. L'application Omni LSD prend actuellement en charge le minting/redeeming/échange à distance de vTokens sur Ethereum, Moonbeam, Moonriver et AStar.

Sans les fonctionnalités ci-dessus, si les utilisateurs souhaitent caster vDOT sur Moonbeam, ils doivent opérer manuellement trois étapes, ce qui est très ennuyeux !

① Transférer DOT de Moonbeam cross-chain à Bifrost

② Obtenez vDOT en misant DOT sur la chaîne Bifrost

③ Transférer vDOT de manière inter-chaînes vers MoonBeam

Cependant, grâce à la fonction d'appel à distance, les actifs de l'utilisateur semblent pouvoir effectuer les trois étapes ci-dessus sans quitter la chaîne Moonbeam et convertir directement les DOT en vDOT sur la chaîne Moonbeam. En d'autres termes, tout au long du processus, les utilisateurs bénéficient des services sur la chaîne Bifrost comme s'ils utilisaient l'application locale Moonbeam.

Ça semble plutôt cool! Mais comment cela peut-il être réalisé? En fait, ce n'est pas compliqué. Bifrost a déployé un module distant (modulaire à distance) sur d'autres chaînes pour recevoir les demandes des utilisateurs et les transmettre à travers les chaînes jusqu'à Bifrost Parachain. Après le traitement du module de garantie de liquidité est terminé, les résultats sont renvoyés au module distant à travers la chaîne. Les utilisateurs n'ont qu'à faire des demandes sur la chaîne distante, et le processus ultérieur sera déclenché et complété par les relais.

Bifrost se réfère à son architecture comme une "architecture de chaîne complète". La comparaison avec les stratégies de déploiement multi-chaînes d'autres protocoles LSD est présentée ci-dessous :

La raison de parler si fortement de l'architecture de Bifrost est que tout le monde puisse comprendre pleinement ce que Bifrost appelle une "architecture de chaîne complète". Ce que représente réellement l'architecture de Bifrost, c'est un nouveau paradigme général.

Dans son article de blog intitulé « Contrat intelligent inter-chaîne », Chainlink a décrit une fois cette architecture comme un modèle « magasin principal + succursale ». La logique principale de l'application est placée sur une chaîne, comme un « magasin principal », puis les autres chaînes fournissent un module d'accès à distance pour permettre l'interaction avec les utilisateurs finaux (obtenir l'entrée de l'utilisateur et produire les résultats désirés), comme des « magasins » un par un.

Après que le magasin obtient l'entrée de l'utilisateur, l'entrée est transmise à travers la chaîne vers le magasin principal, le magasin principal saisit les résultats après traitement, puis transmet les résultats à travers la chaîne au magasin pour les sortir à l'utilisateur. Dans certains cas, les différents modules du magasin principal peuvent être répartis dans différentes chaînes, et ensemble ils forment un magasin principal virtuel. Sous cette architecture, la logique principale du programme est dans le magasin principal, l'application a un enregistrement d'état unifié, et les problèmes de liquidité fragmentée et d'expérience utilisateur ont tous été résolus. De plus, l'application de cette architecture offre également une meilleure interopérabilité entre chaînes, et les applications sur d'autres chaînes peuvent également accéder à distance à la fonction du magasin principal comme les utilisateurs sur d'autres chaînes.

Bien que Bifrost se réfère à cette structure comme une « architecture de chaîne complète », l’auteur n’aime pas vraiment le terme « chaîne complète » ou Omni-Chain, car c’est un terme dont la signification n’est pas claire. Initialement, LayerZero a inventé le terme pour mettre en évidence son évolutivité inégalée, mais LayerZero n’a jamais complètement expliqué ce qu’est réellement la « chaîne complète ». S’agit-il de « l’ensemble de la chaîne » ? Certainement pas ; Aucune application ne fonctionne sur toutes les chaînes. L’auteur a un projet de jeu qui dit qu’ils font un jeu à chaîne complète. J’ai seulement appris que « chaîne complète » signifie « tout le code est sur la chaîne », ce qui ne distingue que certains jeux Web3 avec des données d’actifs sur la chaîne, ce qui n’est pas compatible avec le style « chaîne complète » décrit par LayerZero.

Je pense que l'expression la plus appropriée est "abstraction de chaîne", abstraction de chaîne, ou agnostique de chaîne (sans lien avec la chaîne); les deux peuvent exprimer un état où "les utilisateurs n'ont pas besoin de se soucier de la chaîne".

Le déclin inévitable du pont d'échange de liquidité

Enfin, nous voulons parler d'une autre proposition importante dans le secteur de l'interopérabilité - la liquidité. Tout d'abord, essayons de comprendre le niveau de problème que cela pose. La liquidité n'appartient pas à la couche de protocole car elle n'est pas liée à la transmission sûre et ordonnée des messages inter-chaînes. Elle appartient à la couche d'application, et c'est un type spécial d'application - SwapBridge.

La plus grande catégorie d'applications inter-chaînes doit être les ponts d'actifs. Les ponts d'actifs sont également divisés en WrapBridge et SwapBridge. Le premier aide les utilisateurs à réaliser des transferts d'actifs grâce à la logique de verrouillage-création de jetons-incinération-déverrouillage, également connu sous le nom de « pont de transfert d'actifs », tandis que SwapBridge aide les utilisateurs à réaliser un échange direct d'actifs natifs en réservant de la liquidité sur plusieurs chaînes, également connu sous le nom de « ponts d'échange de liquidité ».

Parmi eux, SwapBridge a la gamme d'applications la plus large et de nombreux projets. Les différents projets SwapBridge sont essentiellement en concurrence pour l'efficacité de la liquidité. Qui peut fournir aux utilisateurs une profondeur maximale avec des dépenses de liquidité minimales. En d'autres termes, la liquidité est au cœur du service fourni par SwaqBridge. Tout le monde se bat pour savoir qui a le meilleur avantage en termes de coûts. C'est la même logique que la concurrence commerciale en général. Ce que tout le monde doit comprendre ici, c'est que l'avantage concurrentiel créé par la stratégie de subvention est insoutenable; vous devez avoir un avantage en termes de conception de mécanisme de liquidité.

De nombreux projets sur le circuit SwapBridge, y compris Stargate, Hashflow, Orbiter, Symbiosis, Synapse, Thorswap, etc., peuvent être appelés les Huit Immortels ont montré leurs capacités à améliorer l'efficacité de la liquidité, et ont également produit de nombreuses innovations remarquables. L'auteur a précédemment écrit un article pour faire le point là-dessus : « Ten Thousand Words Report : Inventaire de 25 Liquidity Interchange Cross-Chain Bridges et de leurs mécanismes de liquidité »

Cependant, CCTP, lancé par l'émetteur de l'USDC Circle, a rendu beaucoup d'efforts de SwapBridge inutiles ; en d'autres termes, CCTP a détruit SwapBridge. On a l'impression que la civilisation du Troisième Corps a mis des centaines de millions d'années et plus de 200 cycles de civilisation pour résoudre le Problème du Troisième Corps, mais finalement Circle vous dit : Le Problème du Troisième Corps n'est pas résolu ! Par exemple, dans l'échange inter-chaînes d'actifs, l'USDC est l'actif intermédiaire le plus largement utilisé. En d'autres termes, lorsque vous devez échanger des actifs A sur la chaîne X contre des actifs B sur la chaîne Y, vous devez souvent échanger A contre de l'USDC sur la chaîne X, puis remplacer l'USDC sur la chaîne X par de l'USDC sur la chaîne Y, et ensuite échanger de l'USDC contre l'actif B sur la chaîne Y.

Par conséquent, la principale forme de liquidité que SwapBridge réserve sur différentes chaînes est USDC. CCTP peut ensuite prendre en charge USDC sur la chaîne X pour être directement échangé contre USDC natif sur la chaîne Y grâce à la logique de burn-mint sans nécessiter de réserves de liquidité. En d'autres termes, CCTP n'a aucun coût de liquidité, et les frais de pont supportés par le côté utilisateur peuvent être extrêmement faibles.

Peut-être diriez-vous qu'en plus de l'USDC, il y a aussi l'USDT en tant qu'actif médiatique couramment utilisé? Sans oublier que dans le secteur des DEX, le taux d'utilisation de l'USDT est bien inférieur à celui de l'USDC, donc vous n'avez pas peur d'en apprendre davantage sur Tether et Circle. Pouvez-vous en venir à cela? Donc, ce que je veux vous dire, c'est que SwapBridge est mort, et le pont officiel de l'émetteur d'actifs aura un avantage de coût incontestable en termes de liquidité inter-chaînes. En ce qui concerne certains SwapBridges intégrant plutôt le CCTP, il s'agit de la logique de l'agrégateur.

Résumé

La couche de protocole de pont inter-chaînes devient de plus en plus sécurisée et fiable, et l'ère des ponts multi-signatures touche à sa fin. Dans le passé, l’impression que le cross-chain était dangereux disparaîtra avec la popularisation de l'infrastructure cross-chain de nouvelle génération;

Les applications inter-chaînes améliorent considérablement l'expérience utilisateur grâce à l'itération de paradigme. L'« abstraction de chaîne » est tout aussi significative que l'« abstraction de compte », et crée des conditions pour la manipulation de masse de Web3;

CCTP lancé par Circle a mis fin à l'ère Sengoku de la concurrence de liquidité SwapBridge, et nous a montré la fin de l'échange d'actifs cross-chain.

En bref, le secteur inter-chaînes subit des changements drastiques ! Ce n'est qu'en comprenant la voie à suivre que nous pourrons avancer avec plus de confiance.

En termes simples, un pont inter-chaînes peut être divisé en une couche de protocole et une couche d'application. La couche de protocole est responsable de fournir une plateforme sécurisée et ordonnée pour les messages inter-chaînes, tandis que la couche d'application construit des dApps basées sur cette plateforme pour cibler les utilisateurs et répondre à divers besoins dans différents scénarios.

Avis de non-responsabilité：

1. Cet article est repris de [ Web3 Geek]. Tous les droits d'auteur appartiennent à l'auteur original [0xmiddle, Web3 geek]. Si des objections sont soulevées à cette réimpression, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité en matière de 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 Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.