La bataille finale de l'interopérabilité : analyse comparative entre Polkadot, Cosmos, LayerZero et autres
TechFlow SélectionTechFlow Sélection
La bataille finale de l'interopérabilité : analyse comparative entre Polkadot, Cosmos, LayerZero et autres
Puisque l'écosystème de la concurrence multichaîne, compatible et coexistante, est désormais une réalité, les conflits futurs pourraient bien devenir encore plus chaotiques. Dans ce contexte, la communication interchaînes est-elle le prochain secteur sur le point d'exploser ?
Dédié à des analyses Web3 approfondiesRédaction : Jackson
Préambule :
Avant d'aborder le sujet de cet article, nous devons préciser que celui-ci ne reflète que l'opinion personnelle de l'auteur. L'analyse adopte une approche centrée sur les produits et la conception technique, sans tenir compte des aspects tels que les opérations financières ou le marketing. Cet article ne constitue donc ni une recommandation d'investissement ni un rapport à court terme. Le sujet principal traité ici concerne principalement les infrastructures, un segment souvent atomique : soit il répond parfaitement aux besoins et connaît une croissance rapide, soit il s'avère erroné et reste ignoré. Par conséquent, les projets mentionnés dans cet article ne doivent en aucun cas être considérés comme des références d'investissement fournies par l'auteur.
01. La compatibilité des données entre L1 et L2 chez Synthetix et la réflexion qu'elle suscite sur l'interopérabilité inter-chaînes
L'origine de ce rapport provient des propositions SIP156 et SIP165 publiées respectivement en juillet et décembre par la communauté Synthetix. Liens ci-dessous :
https://sips.synthetix.io/sips/sip-156/
https://sips.synthetix.io/sips/sip-165/
Ces deux propositions sont actuellement encore au stade « faisabilité », ce qui signifie qu’elles n’ont pas encore été mises en œuvre mais ont déjà obtenu un certain niveau d’acceptation quant à leur viabilité. Leur objectif principal est de résoudre le problème de compatibilité des données entre Layer 2 et Layer 1 chez Synthetix. Ceux qui ont lu mon rapport sur les actifs synthétiques publié en octobre comprendront aisément ce point. Synthetix, l'un des projets DeFi les plus complexes de l'écosystème Ethereum, a officiellement déployé sa solution sur Optimism, une solution Layer 2. Toutefois, avec l’émergence progressive d’un paysage concurrentiel multi-chaînes, bien que les communications inter-chaînes entre Layer 2 et Layer 1 soient possibles à un certain degré, elles ne peuvent pas encore s’étendre à d’autres sidechains ou même à des chaînes hétérogènes comme Solana. Cela empêche la synchronisation de la dette globale utilisée par Synthetix, entraînant ainsi un énorme « gaspillage de liquidité ».
Ce « gaspillage de liquidité » représente l’un des plus grands défis auxquels sont confrontées aujourd’hui les DApps dans cette ère de compétition féroce entre blockchains – une véritable période des États combattants. En particulier pour des projets comme Synthetix, dont le modèle repose sur une dette globale (des projets similaires basés sur un partage du risque via un pool vers utilisateur rencontrent tous ce problème), le déploiement sur plusieurs chaînes force une fragmentation des liquidités. Chaque chaîne doit alors redémarrer à zéro pour inciter et accumuler de nouvelles liquidités.
Prenons l'exemple du fonds souvent moqué « DeFi For All ». Grâce à ce programme, Polygon a attiré Aave, Curve, Sushi et récemment Uniswap. Pourtant, ces projets leaders doivent malgré tout relancer activement les liquidités sur Polygon.
On pourrait penser que plus les incitations économiques sont nombreuses, mieux c’est pour les mineurs. Mais pour les utilisateurs ayant de véritables besoins, cela crée de grandes difficultés. Par exemple, le nombre de types de collatéraux et d’actifs supportés par Aave sur d'autres chaînes est nettement inférieur à celui d’Ethereum. Sur d'autres chaînes, même les actifs les plus liquides sur Sushiswap restent très en dessous du niveau d’Ethereum.
Du point de vue d’un développeur, si je souhaite déployer mon propre protocole de prêt-collatéral sur une blockchain hétérogène performante ou sur une sidechain EVM comme Polygon, je serai confronté à un grave problème : le manque de variété des collatéraux disponibles, car peu d’actifs sur cette chaîne disposent de suffisamment de liquidité pour supporter des liquidations à grande échelle.
De plus, de nombreux AMM sur différentes chaînes hébergent des paires de jetons populaires. Prenons ETH comme exemple. Au moment de la rédaction, la TVL totale d’ETH sur Uniswap V3 atteint 1,41 milliard de dollars, contre environ 300 millions sur Pancake V2. Lors d’une transaction identique d’ETH, Pancake subit une pression de glissement presque cinq fois supérieure à celle d’Uniswap V3 sur Ethereum. Plus le montant est élevé, plus l’écart de glissement s’élargit. C’est pourquoi l’utilisation des agrégateurs de trading augmente fortement, y compris celle des agrégateurs inter-chaînes.
Autre exemple : les taux d’intérêt auxquels les utilisateurs sont soumis lorsqu’ils empruntent sur différentes versions d’Aave varient selon les chaînes. Cela s’explique par l’impossibilité d’interconnexion des données entre chaînes ; les contrats intelligents calculent les taux uniquement à partir des données natives de chaque chaîne. Bien que la différence semble minime, imaginons plutôt ceci : vous placez votre argent dans une banque locale à un taux de 4 %, mais découvrez qu’il est de 6 % dans une grande ville. Même banque, même devise — une situation impensable dans la finance traditionnelle. Mais en raison des îlots de données propres aux blockchains, ce genre de disparité est fréquent.
Cela nous amène à une réflexion :
Puisque l’ère multi-chaînes est désormais incontournable et que la bataille pourrait encore s’intensifier, la communication inter-chaînes va-t-elle devenir le prochain grand secteur en pleine expansion ?
À cette fin, moi-même et mes développeurs avons mené une étude approfondie sur diverses solutions existantes (en sélectionnant quelques cas représentatifs, les solutions trop homogènes n’étant pas incluses ici). Nous souhaitons analyser les forces et faiblesses de chaque approche sous différents angles.
Les sections suivantes abordent plusieurs primitives techniques. Nous ferons notre possible pour utiliser un langage accessible. Bien que le domaine des infrastructures paraisse très « technique », les solutions blockchain reposent essentiellement sur des questions philosophiques concernant les formes d’organisation et les rapports de production. Comprendre les processus et la logique de base permet de saisir le sens de ces infrastructures, même sans connaître le code.
02. Quelques infrastructures actuelles de communication inter-chaînes
(I) Protocoles légers et modulaires — LayerZero
LayerZero est une infrastructure de communication inter-chaînes découverte par SeerLabs en août. Elle a immédiatement retenu mon attention, mais j’ai raté l’opportunité d’y investir (regrettable). Peu après, j’ai vu que le protocole avait levé des fonds auprès de Binance, Multicoin et Delphi Digital. Quand j’ai voulu renouer contact… plus aucune réponse.
1. Résumé de la solution
LayerZero propose une solution légère basée sur la couche de communication, destinée principalement aux DApps existantes sur chaque chaîne, afin de résoudre leurs problèmes d’interopérabilité.
Voici comment le livre blanc décrit cette solution :
Le schéma ci-dessus illustre les étapes nécessaires au transfert efficace d’un message LayerZero. Chaque chiffre noir indique une étape.
Étape 1 : Une application utilisateur AppA sur la chaîne A exécute une série d’actions dans le cadre d’une transaction t. Nous identifions de manière unique cette transaction par son identifiant t, dont le format peut varier selon le type de chaîne A. L’une des étapes consiste à transmettre efficacement un payload via LayerZero. À titre explicatif, supposons que AppA utilise le relais modèle fourni par LayerZero. AppA envoie au communicateur LayerZero une requête contenant :
t : identifiant unique de l’événement
dst : identifiant global pointant vers un contrat intelligent sur une autre chaîne
payload : données du message que l’application de la chaîne A souhaite envoyer à celle de la chaîne B
relayer_args : paramètres de paiement lorsque l’application sur la chaîne A choisit d’utiliser le relais modèle (un relais personnalisable fourni par LayerZero)
Étape 2 : Le communicateur construit un paquet LayerZero contenant dst et payload, appelé (dst, payload), puis l’envoie avec t et relayer_args au validateur.
Étape 3 : Le validateur envoie t et dst au réseau. Cette étape informe le réseau qu’il doit transférer l’en-tête du bloc courant de la chaîne A vers la chaîne B.
Étape 4 : Le validateur transfère le paquet (dst, payload), t et relayer_args au relais, l’informant qu’il doit précharger la preuve de transaction T et finalement l’envoyer à la chaîne B. Cette étape se produit simultanément à l’étape 3.
Étape 5 : Le réseau envoie l’identifiant du bloc courant (cur_blk_id) à l’oracle. Cela notifie l’oracle de récupérer l’en-tête du bloc courant sur la chaîne A et de l’envoyer à la chaîne B. Si plusieurs transactions LayerZero ont lieu dans le même bloc, cette étape n’est exécutée qu’une seule fois.
Étape 6 : L’oracle lit l’en-tête du bloc (blk_hdr) depuis la chaîne A.
Étape 7 : Le relais lit depuis la chaîne A la preuve de transaction associée à T (preuve(t)) et la stocke hors chaîne. Les étapes 6 et 7 se produisent de manière asynchrone.
Étape 8 : L’oracle confirme que le bloc correspondant à blk_hdr est solidement validé sur la chaîne A, puis envoie blk_hdr au réseau sur la chaîne B. Le mécanisme de confirmation varie selon les chaînes, mais implique généralement d’attendre un certain nombre de confirmations de blocs.
Étape 9 : Le réseau envoie le hash du bloc, noté blkJhdrJhash, au validateur.
Étape 10 : Le validateur transfère blkJhdrJhash au relais.
Étape 11 : Après réception de blk_hdr_hash, le relais envoie une liste de tous les tuples (paquet(dst, payload), t, preuve(t)) correspondant au bloc courant. Si plusieurs utilisateurs envoient simultanément des messages entre les mêmes points, plusieurs paquets et preuves peuvent exister dans un même bloc.
Étape 12 : Le validateur utilise la preuve de transaction reçue conjointement avec l’en-tête de bloc stocké par le réseau pour vérifier que la transaction T associée est valide et bien confirmée. Si l’en-tête et la preuve ne correspondent pas, le message est rejeté. Sinon, le paquet (dst, payload) est envoyé au communicateur.
Étape 13 : Le communicateur transmet le paquet (dst, payload) à AppB.
2. Avantages clés de cette solution :
(1) Légèreté et faible coût
Cette solution ne nécessite pas de nœuds situés au-dessus des chaînes A et B comme d'autres solutions. Elle peut être librement déployée par les projets, qui peuvent utiliser les modèles proposés par LayerZero. Même le relais peut être conçu par l’utilisateur. Le livre blanc mentionne aussi les ULN (Ultra-Light Nodes), encore plus légers que les nœuds légers, dont la mise en œuvre détaillée reste floue. Néanmoins, cela illustre bien l’approche extrêmement légère du déploiement.
(2) Solution basée sur la couche de communication
C’est un argument commercial mis en avant par l’équipe : LayerZero affirme offrir un nouveau protocole de communication au niveau Layer 0. Nous ne sommes pas d’accord. Il ne s’agit pas d’un protocole de communication comparable au TCP, mais simplement d’un protocole de transfert de données inter-chaînes. Dans la hiérarchie des couches, nous le placerions plutôt au niveau applicatif, entre Layer 2 et Layer 3.
(3) Pas de dépendance à une tierce partie de confiance
Le livre blanc cite Anyswap et THORChain comme exemples de protocoles reposant sur un mécanisme de notaire — c’est-à-dire une couche consensus intermédiaire à laquelle l’utilisateur doit faire confiance. LayerZero, lui, serait un primitif de communication point à point, ne nécessitant pas une telle couche intermédiaire.
(4) Conclusion
La mécanique inter-chaînes décrite par LayerZero paraît séduisante, capable de résoudre de nombreux problèmes pratiques avec une grande légèreté. Mais derrière ces apparences « techniques », on observe certains biais induits typiques de ce genre de solutions.
3. Problèmes
(1) Ce n’est pas une solution basée sur la couche de communication
Ce projet n’est pas un protocole de communication au niveau Layer 0. Ses outils principaux sont les endpoints et les relais : les premiers valident la communication, les seconds transmettent les messages. Il s’agit simplement d’un protocole de transfert de données inter-chaînes, que nous plaçons plutôt au niveau applicatif, entre Layer 2 et Layer 3.
(2) LayerZero dépend également d’une couche consensus intermédiaire
La sécurité repose sur la validation croisée entre le relais et l’oracle. Pourtant, le livre blanc mentionne un scénario extrême : collusion entre relais et oracle. Bien que l’indépendance relative puisse réduire ce risque, les relais sont généralement déployés par les projets eux-mêmes. Quant à l’oracle, LayerZero recommande Chainlink. Sans même parler du coût, cela revient à faire confiance à Chainlink pour ne pas conspirer avec les projets. Or, Chainlink est bel et bien une couche consensus intermédiaire.
4. Analyse prospective subjective
(1) La plupart des utilisateurs ne perçoivent pas les nuances techniques
Ainsi, de petites manipulations narratives passent inaperçues. Certains projets « techniques » vont encore plus loin. Pour nous, les fondateurs « auteurs » sont trop nombreux.
(2) Un déploiement léger favorise l’adoption
Comparé à Anyswap, THORChain, Polkadot, Cosmos ou Axelar, LayerZero demande beaucoup moins d’efforts techniques, écologiques et opérationnels. Pas besoin de créer ses propres nœuds, d’attirer des validateurs ou de construire une couche consensus. Coûter moins cher que fournir une simple boîte à outils est inévitable.
Avec des ressources égales, LayerZero a de meilleures chances de s’imposer dans l’écosystème inter-chaînes.
(3) Faible potentiel narratif et d’expansion écologique
Comme Anyswap ou Chainlink, LayerZero joue un rôle crucial, mais sa nature d’outil limite son pouvoir narratif et son expansion écologique.
Par exemple, l’écosystème de consensus intermédiaire de Chainlink est déjà solide, mais son image d’« oracle » est si forte qu’elle éclipse son potentiel narratif comparé à des Layer 1 comme Solana. Avec ses capacités, Chainlink pourrait légitimement prétendre au statut de Layer 3 universel.
LayerZero suit le même schéma. Son positionnement utilitaire affaiblit sa narration. Deux articles récents sur Medium trahissent cette limite : l’équipe pense immédiatement à une collaboration avec IBC de Cosmos pour étendre LayerZero.
En somme, se placer au même niveau narratif qu’un composant de Cosmos.
(II) Protocole de communication inter-chaînes hétérogènes — Axelar
Ce projet est fascinant. Son titre général et sa vision rejoignent exactement notre sujet : permettre aux développeurs et aux écosystèmes blockchain de surmonter l’incompatibilité actuelle entre chaînes hétérogènes.
1. Vision officielle annoncée
(1) Pour les développeurs de base
Connectez votre blockchain à toutes les autres.
(2) Pour les développeurs de DApp
Déployez votre DApp où vous voulez, et utilisez Axelar pour transférer actifs et informations entre n’importe quelles chaînes.
(3) Pour les utilisateurs
Interagissez directement depuis votre portefeuille avec toutes les DApps de tous les écosystèmes blockchain.
2. Principe de base du projet
Ce schéma provient du document officiel, mais est trop complexe. Voici une version simplifiée en texte.
3. Flux du protocole Axelar
Supposons deux chaînes S et D, reliées par le service inter-chaînes d’Axelar.
Transfert d’information d’état
Axelar récupère et synchronise les informations d’état (ex : hash de bloc, hauteur actuelle) des différentes blockchains via des validateurs exécutant des nœuds pour chaque chaîne. Le flux principal est le suivant :
(1) Un utilisateur de la chaîne D envoie via l’API d’Axelar une requête Q pour obtenir les données d’état de la chaîne S, soit vers un compte pont, soit directement sur la blockchain Axelar.
(2) Chaque validateur Axelar doit exécuter les logiciels de nœud des chaînes S et D. Ils interrogent leur nœud S via l’API pour obtenir la réponse A, puis l’envoient à la chaîne Axelar.
(3) Dès qu’un seuil de poids est atteint parmi les validateurs rapportant la même réponse au bloc R, une signature de seuil est publiée au bloc R+11.
(4) N’importe qui peut extraire du bloc R+11 la réponse signée S et la publier sur le réseau D. Les utilisateurs peuvent ensuite consulter cette réponse via l’API d’Axelar.
Transfert d’actifs
Supposons qu’un utilisateur veuille échanger x jetons sur la chaîne source S contre x jetons adossés S’ sur la chaîne cible D, crédités à son adresse WD. Le flux est le suivant :
(1) L’utilisateur envoie une requête de transfert inter-chaînes (x, WD) à un compte pont, capturée par un écouteur et routée vers le réseau Axelar.
(2) Le groupe actuel de validateurs Axelar utilise une signature de seuil pour créer collectivement une nouvelle adresse de dépôt DS sur S, puis la diffuse sur le réseau Axelar.
(3) L’utilisateur surveille la blockchain Axelar, obtient DS, puis envoie x jetons S à cette adresse.
(4) Les validateurs vérifient le succès du transfert. Si, au bloc R, un seuil de poids confirme le succès, ils signent une transaction txD envoyant x jetons S’ à WD, et diffusent la signature au bloc R+11.
(5) N’importe qui peut extraire txD signée du bloc R+11 et la publier sur la chaîne D, achevant ainsi le transfert inter-chaînes.
Cette solution est plus complexe que LayerZero, avec davantage d’étapes et de logique de validation. La principale différence : LayerZero délègue une partie de la vérification à un oracle externe, agissant comme couche consensus intermédiaire. Axelar, lui, construit une troisième chaîne basée sur un consensus BFT. Via CTP, il synchronise les données des autres chaînes vers Axelar, puis utilise des signatures de seuil pour transmettre les informations.
Fondamentalement, cette approche ne diffère guère de celles d’Anyswap ou THORChain, regroupées sous le terme de « mécanisme de notaire ». C’est d’ailleurs l’une des principales familles de solutions inter-chaînes.
4. Avantages de cette solution
(1) Une chaîne tierce indépendante offre plus de potentiel
Le réseau Axelar est lui-même une blockchain. Bien qu’il permette à une DApp sur chainA d’atteindre chainB via Axelar, la meilleure stratégie pour les développeurs reste de déployer directement sur Axelar. Ainsi, tous les déploiements futurs deviennent des extensions descendantes, non des intégrations ascendantes.
Si Axelar réussit à développer un écosystème solide, il pourrait prétendre au statut de Layer 3. Un peu comme la chaîne-relais dans l’écosystème Polkadot. Un jour, ETH, BTC pourraient même être qualifiés de parachains d’Axelar.
(2) Indépendance vis-à-vis des oracles tiers, potentiellement plus efficace et moins coûteux
Bien que LayerZero ait un faible coût de déploiement grâce à ses endpoints et relais légers, le coût et l’efficacité des oracles deviennent critiques pour les développeurs.
Exemple : un projet A veut transférer via LayerZero et Chainlink les données de dette de son contrat principal sur chainA vers chainB. Mais appeler Chainlink a un coût. De plus, Chainlink ne surveille pas directement les blocs comme Axelar, mais pousse les données selon un calendrier ou des règles (ex : toutes les minutes, ou seulement si la dette varie de plus de 1 %).
Chaque appel à Chainlink coûte des frais. Sur le marché Chainlink, les fournisseurs de données proposent des contrats spécifiques. Vous payez en LINK pour accéder aux données, qui sont ensuite récupérées hors chaîne et injectées dans votre contrat (donc avec un délai asynchrone, d’au moins un bloc). Le prix inclut les frais de gaz plus une petite marge : ~1–3 LINK sur Ethereum, ~0,1 LINK sur BSC.
La fréquence des communications inter-chaînes hétérogènes étant élevée, le coût cumulé devient important. Globalement, la solution générique d’Axelar pourrait s’avérer bien moins chère.
5. Analyse prospective subjective
(1) Du point de vue de la conception produit, Axelar ressemble davantage à Anyswap. La plupart des utilisateurs tolèrent un haut degré de centralisation de la couche consensus intermédiaire. Peu importe que 99 % des utilisateurs ignorent complètement les fournisseurs de services ou l’écosystème des chaînes supportant Chainlink ou Anyswap. Ce qui compte, c’est quelle solution inter-chaînes est la plus adoptée sur leur chaîne. Ainsi, le succès d’une solution inter-chaînes générique dépend surtout de la capacité du projet à convaincre les Layer 1. Pour l’instant, Axelar n’a pas fait grand bruit. Techniquement, nous ne voyons pas d’avantage suffisant pour un effet viral.
Toutefois, par rapport à Polkadot, le développement de l’écosystème Axelar semble bien plus facile. On peut le voir comme une couche outil, non comme une création d’écosystème complète.
(2) En termes de narration, Axelar est actuellement bien en dessous de Cosmos ou Polkadot. Même s’il est potentiellement plus pratique, ces deux derniers ont proposé des protocoles standardisés, ce qui leur donne un avantage narratif énorme.
(III) Polkadot et Cosmos
1. Informations de base
Polkadot et Cosmos sont les projets les plus bruyants, les plus riches en écosystème et les plus valorisés du marché. Globalement, leur vision et leur ambition dépassent largement celles de LayerZero ou Axelar.
Nous ne discuterons pas ici des détails techniques de Polkadot et Cosmos — les documents sont innombrables. Nous nous concentrons sur l’approche globale.
Les deux projets proposent des solutions inter-chaînes hétérogènes — par exemple, entre chaînes Substrate/Tendermint et ETH/BTC. Le principe de base ne diffère guère de ceux d’Axelar ou LayerZero : une couche consensus intermédiaire utilisant un mécanisme de notaire.
Mais Polkadot et Cosmos racontent une histoire encore plus attrayante : celle de la standardisation des blockchains et des solutions inter-chaînes homogènes. Autrement dit : reconnecter tous les écosystèmes en créant de nouveaux mondes interconnectés.
2. Comparaison avec LayerZero & Axelar
Le schéma ci-dessus, fortement simplifié (les flux ne sont pas précis — par exemple, l’interconnexion hétérogène de Polkadot nécessite une chaîne-pont, non une interaction directe avec la chaîne-relais), montre que les trois types de solutions ne diffèrent pas fondamentalement sur l’interconnexion hétérogène. Mais leurs visions globales divergent clairement.
Polkadot et Cosmos jugent que l’interopérabilité homogène est la plus sûre et stable, avec moins de dette technique. Bien qu’ils supportent l’interconnexion hétérogène, leur priorité va aux chaînes Substrate et Tendermint.
Axelar estime qu’un standard unifié est la méthode la plus efficace et sûre pour connecter des chaînes hétérogènes. Il crée donc le réseau Axelar, intégrant communication inter-chaînes, service de relais et une couche consensus intermédiaire.
LayerZero, lui, considère qu’un protocole de communication inter-chaînes léger est un besoin essentiel. Il fournit donc uniquement des relais et un protocole, en confiant le rôle de couche consensus à un oracle externe.
Quelle solution attirera le plus d’attention et aura le plus d’avenir sur le marché de 2022 ?
(IV) Analyse prospective globale
1. Paysage concurrentiel actuel
a. Compétition intense entre chaînes hétérogènes, coexistence multi-chaînes désormais acquise
b. Les gros poissons restent sur ETH, les utilisateurs massifs migrent vers des Layer 1 à moindre coût et meilleure expérience — BSC, AVAX, Solana
c. L’innovation par composition domine désormais
d. Part de marché énorme de l’écosystème EVM
2. Modèle comparatif
Du point de vue du développement écologique, ces trois solutions diffèrent fortement en narration et stratégie. Voici un tableau comparatif multidimensionnel :
Polkadot et Cosmos, plus ambitieux, font face à des défis plus grands. Le tableau révèle clairement les obstacles majeurs, les perspectives futures et les groupes cibles à conquérir.
On peut affirmer avec certitude que, sauf si leurs outils sont suffisamment complets et leur écosystème assez dynamique pour former une entité autonome, il leur sera difficile d’accomplir les visions décrites dans leurs livres blancs.
Dans la course multi-chaînes actuelle, les solutions homogènes centrales de Polkadot et Cosmos semblent déconnectées de la tendance dominante.
Toutefois, Cosmos et Polkadot présentent des différences subtiles. Par exemple, Cosmos propose un système utilisant IBC et des ancres (pegs) pour l’interconnexion hétérogène.
En résumé, Cosmos dispose déjà des outils pour créer rapidement un réseau similaire à Axelar, avec en plus la possibilité future d’interagir avec d’autres chaînes homogènes.
L’avantage ? Même si l’interconnexion homogène n’est pas encore réalisée, une adoption efficace de l’interconnexion hétérogène peut déjà être considérée comme un succès pour l’écosystème Cosmos.
En revanche, XCMP de Polkadot (encore incomplet) est fortement couplé au consensus de la chaîne-relais, difficilement dissociable. Les développeurs doivent créer eux-mêmes des systèmes pour interconnecter des chaînes hétérogènes comme BTC ou ETH. Bien que cela réduise les coûts de développement de la couche consensus, cela s’éloigne de la vision annoncée.
En conclusion, la conception de Polkadot rencontre probablement de graves difficultés. Après les enchères de slots, Polkadot devra massivement inciter les DApps natives Substrate pour sortir du chaos concurrentiel. Le défi est immense, probablement le plus grand parmi tous les projets observés.
Naturellement, les capacités de Parity et de Web3 Foundation sont indéniables. Cet article analyse uniquement la difficulté technique et produit, sans valeur de conseil d’investissement.
03. Point de vue Seer
(1) La solution LayerZero pourrait être la plus rapide à arriver sur le marché
Car elle répond plus directement aux besoins actuels des développeurs de DApp. Reprenons l’exemple initial de Synthetix : ce dernier pourrait utiliser LayerZero + Chainlink pour intégrer rapidement ses pools de dette entre Layer 1 et Layer 2.
(2) Axelar fait face à la concurrence la plus homogène
Comparé à l’approche légère et rapide de LayerZero, la solution d’Axelar est plus homogène. Elle fait face à Polkadot & Cosmos au-dessus, et à Anyswap & THORChain sur le même niveau. Le taux d’adoption par les Layer 1 sera son principal obstacle. Je ne crois pas qu’Axelar puisse surpasser Anyswap, qui, bien que spécialisé actuellement dans le transfert d’actifs, peut évoluer vers les messages avec peu d’effort, et bénéficie déjà d’un fort taux d’adoption. En bas, Axelar refuse de se limiter à un simple composant de communication légère, car cela affaiblirait sa narration et sa capture de valeur.
(3) Le taux d’adoption prévu de Cosmos dépassera celui de Polkadot
L’architecture plus flexible de Cosmos réduit la difficulté technique. Son orientation appliquée a permis à l’écosystème Tendermint de produire de nombreux excellents produits, dont le récent phénomène LUNA (Terra).
(4) L’écosystème Polkadot fait face à un défi colossal
Parmi toutes les solutions citées, Polkadot subit la plus forte pression médiatique. Des retards répétés dus à sa complexité technique érodent progressivement la confiance des utilisateurs. Seul un « produit phare exploitant pleinement la composition inter-chaînes » pourrait vraiment prouver ses promesses. Bien sûr, avec tant d’acteurs impliqués, un avantage du tard venu pourrait aider Polkadot à réussir.
TechFlow est une plateforme communautaire axée sur des contenus approfondis, engagée à
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
