Votre message a été envoyé.
Nous traiterons votre demande et vous contacterons dès que possible.
Le formulaire a été soumis avec succès.
Vous trouverez de plus amples informations dans votre boîte aux lettres.

Sélection de la langue

29 avril 2026
Dans cette conversation, Andrew examine de plus près ce que signifie la connexion d'une chaîne EVM personnalisée à la liquidité de Tron. Il aborde la sécurité des ponts, les vulnérabilités des cas limites, les limites des audits et les compromis derrière les modèles LP, lock-and-mint, basés sur l'intention et hybrides, en mettant l'accent sur ce qui se brise réellement en production et pourquoi.
Si vous travaillez avec des chaînes personnalisées, l'interopérabilité ou l'acheminement des liquidités, vous trouverez ici une analyse pratique des décisions qui sous-tendent l'infrastructure inter-chaînes.

Je pense que c'est une très bonne question car nous sommes en partenariat avec CrossCurve et nous utilisons leur solution pour certains de nos clients. Lorsque l'accident s'est produit, nous avons vraiment essayé d'évaluer l'impact sur nos clients et nos partenariats. Et après une vérification interne, nous avons reconnu que la bonne nouvelle est qu'il n'y a pas d'impact sur nos clients spécifiques.
Que s'est-il passé en réalité ? CrossCurve a donc utilisé des messagers externes pour envoyer un message de la chaîne source à la chaîne de destination. En réalité, CrossCurve a déclaré qu'elle disposait, et elle dispose effectivement, d'une solution appelée "consensus bridge" (pont de consensus). Cela signifie qu'ils utilisent différents messagers à la fois pour protéger la transaction spécifique, le processus de verrouillage et de frappe de la monnaie ou le processus de transfert de liquidités entre les chaînes. Mais dans ce cas précis, ils ont dû emballer ces deux chaînes différentes, et n'ont donc utilisé que la solution Axelar.
Et le problème n'est pas dans CrossCurve mais dans le mécanisme de messagerie Axelar. Qu'est-ce que cela signifie en pratique ? Lorsque quelqu'un envoie une transaction de la chaîne de destination à la chaîne source, la chaîne source se contente de vérifier l'identifiant de la transaction sur la chaîne de destination et de comparer les chiffres, sans réellement vérifier le message de la chaîne source. Malheureusement, de nombreux auditeurs et chercheurs n'ont pas mentionné cette vulnérabilité. De ce fait, CrossCurve s'est contenté d'utiliser la même solution et les méthodes approuvées par les auditeurs externes.
Fondamentalement, cela nous montre que parfois, nous ne pouvons même pas faire entièrement confiance aux auditeurs et qu'il est nécessaire de procéder à une double vérification à chaque fois. Peut-être appliquer des contrôles supplémentaires de l'IA ou autre. Mais la bonne nouvelle, c'est que CrossCurve est toujours dans la course. Il y a certes de mauvaises nouvelles, mais cela ne signifie pas qu'il y a des problèmes du point de vue de l'architecture. Nous pouvons penser qu'il s'agit d'un rappel de la façon dont quelqu'un peut abuser et attaquer les ponts. Mais cela signifie simplement que nous devons procéder à des doubles vérifications, garder à l'esprit que de telles attaques peuvent se produire, et construire les prochaines solutions et passerelles de la chaîne croisée de manière plus sûre.
Vous savez, cela dépend des cas. Je peux dire que les problèmes architecturaux les plus courants ont été résolus lors du précédent marché haussier, entre la mi-2020 et 2021. Les cas les plus courants ont donc déjà été résolus. Mais certains cas sont vraiment des cas limites. Par exemple, le cas de CrossCurve. Je pense qu'il s'agit d'un véritable cas limite car même après toutes les vérifications, même avec une bonne architecture et une idée absolument géniale, de tels points faibles subsistent.
Je pense qu'à l'heure actuelle, nous disposons déjà de la solution architecturale la plus commune qui soit. Nous l'appelons l'étalon-or pour l'industrie, et en général, c'est un étalon commun, je pense. On ne peut donc pas dire qu'il y ait des problèmes d'architecture. Nous pouvons dire que de petits bogues ou de petits cas inhabituels, et ce que nous appelons en fait un cas limite, peuvent se produire.
Je pense que notre principal objectif à l'heure actuelle est de prévenir et de protéger ces cas limites au niveau de l'architecture. Il est possible, par exemple, d'utiliser une solution hybride, une double vérification, un audit supplémentaire ou peut-être un refroidissement dans certains cas. Dans notre entreprise, nous essayons vraiment de mettre en œuvre de plus en plus de contrôles et de protections de sécurité, et nous préférons même parfois réutiliser des solutions existantes plutôt que de créer des ponts à partir de zéro.
Et dans ce cas, il vaut mieux appliquer la norme majeure plutôt que d'essayer de réinventer la roue.
Je pense que c'est la question que nous posent tous nos clients, ou même tous ceux qui décident de créer leur propre chaîne personnalisée. Dans la plupart des cas, il s'agira de chaînes compatibles avec l'EVM, parfois de Layer 2 ZK-rollup ou Optimistic rollup. Et tout le monde veut avoir une partie de la liquidité de la chaîne Tron parce qu'elle joue encore un rôle important dans les transferts de stablecoins : quelqu'un est payé, reçoit un salaire ou paie des factures en utilisant des stablecoins sur Tron.
Quiconque souhaite accéder à cette liquidité et l'utiliser sur sa propre chaîne personnalisée. Les chaînes compatibles avec Tron et EVM ont différents types d'adresses, différents types de contrats intelligents et différents langages pour les contrats intelligents. C'est pourquoi c'est si difficile. Si nous connectons la chaîne EVM à la chaîne EVM, l'adresse de la chaîne de destination et de la chaîne source sera la même, et nous pourrons utiliser le même contrat intelligent pour le lock-and-mint, même du point de vue des paiements pour les frais de transaction.
Ainsi, sur une chaîne EVM, nous disposons du même mécanisme pour estimer les redevances gazières et les coûts de transaction. Dans Tron, c'est absolument différent, avec un concept d'énergie, avec un paiement en TRX, etc. C'est la raison pour laquelle il est si différent et plus complexe, plutôt que de simplement connecter deux chaînes différentes compatibles avec les EVM.
Vous savez, honnêtement, je pense que les ponts LP constituent l'approche la plus classique pour de nombreuses chaînes. Cela signifie que vous, en tant que personne souhaitant coupler votre chaîne avec une chaîne externe, ou en tant que propriétaire du pont, n'avez pas besoin de fournir vos propres liquidités. Vous pouvez demander à la communauté de fournir ces liquidités et, dans la plupart des cas, elle acceptera de les partager avec vous.
Mais vous devez leur fournir un certain profit. Et vous serez en concurrence avec les protocoles DeFi existants ou d'autres cas d'utilisation de la liquidité. Cela signifie que votre pont doit avoir un grand nombre de TVL verrouillés et qu'il doit être traversé par un grand nombre de transactions. Si le volume de transactions est très élevé et que vous percevez beaucoup de frais, vous pourrez partager ces frais avec les fournisseurs de liquidités.
Dans le cas contraire, si vous avez moins de transactions, le fournisseur de LP a moins de raisons de fournir des liquidités car il percevra moins de frais. C'est pourquoi il peut décider de retirer les liquidités de votre pont et de les utiliser pour un protocole DeFi externe. Dans ce cas, le glissement dans cette transaction LP, avec ce pont utilisant LP, sera plus élevé.
C'est pourquoi quelqu'un peut décider : “D'accord, je ne veux pas faire la transaction sur cette chaîne avec ce pont, et je préfère une autre option.” Il faut donc jouer avec les liquidités et fournir de plus en plus de raisons de soutenir sa solution de transition avec les liquidités.
Certainement pas d'un point de vue social. Vous savez, le meilleur aspect de l'approche "lock-and-mint" est que vous n'avez pas de liquidités du tout. Dans le cas des ponts LP, vous devez demander à quelqu'un de fournir des liquidités aux LP. Dans ce cas, il n'est même pas nécessaire de disposer de ses propres liquidités.
Dans le cas de l'approche "verrouiller et frapper la monnaie", si quelqu'un veut utiliser des stablecoins ou utiliser votre chaîne, il pourra verrouiller un certain nombre de stablecoins, ou n'importe quelle pièce, sur la chaîne source, puis frapper la monnaie d'un nombre égal sur votre chaîne personnalisée ou, en général, sur la chaîne de destination.
Mais quel est le problème ? Le plus gros problème de cette approche est qu'elle peut créer un type de jeton différent sur la chaîne de destination. Il s'agit donc de la fragmentation de la liquidité. Par exemple, vous aurez une version du jeton d'Ethereum et une autre d'Arbitrum, ou différents types de jetons émis par différents ponts avec une approche "lock-and-mint". Il s'agit donc de fragmentation.
Mais cela pose également des problèmes d'un point de vue technique, car si quelqu'un attaque le messager et envoie un message erroné indiquant qu'il faut débloquer un certain nombre de jetons sur la chaîne source ou émettre un nombre supplémentaire de jetons sur la chaîne de destination, il pourra alors obtenir les liquidités supplémentaires qui ne sont pas garanties par les jetons réels sur la chaîne source.
Il s'agit donc d'un problème important et, dans la plupart des cas, si quelqu'un tente d'attaquer ces ponts, il combine une attaque économique et une attaque technique, mais pas une attaque sociale.
Je suis d'accord pour dire qu'une approche basée sur l'intention peut être la meilleure approche du point de vue de l'expérience de l'utilisateur. Mais si vous créez votre propre chaîne, cela signifie que vous devez fournir une motivation supplémentaire à certains robots, algorithmes ou même personnes pour être le résolveur, car les résolveurs sont un élément clé de l'approche basée sur l'intention.
Pour beaucoup de nos clients, nous utilisons 1inch Fusion+. Il s'agit exactement d'une approche basée sur l'intention. Mais si vous voulez utiliser la même chose pour vos propres chaînes personnalisées, vous devez motiver quelqu'un pour résoudre ce problème. Par exemple, s'ils constatent que le volume de transactions sur votre chaîne est de moins en moins important et que de moins en moins de personnes souhaitent effectuer ce transfert, ils peuvent essayer de vous dicter leurs attentes du point de vue des revenus, et l'expérience de l'utilisateur devient alors de plus en plus mauvaise.
Et ce faible coût peut être de plus en plus élevé, et la vitesse de transaction peut être plus lente. Vous serez peut-être le seul solveur ou résolveur à opérer avec une telle approche. Je pense donc que c'est le pire aspect de l'approche fondée sur l'intention.
En ce qui concerne les ponts en général, si vous créez votre propre chaîne personnalisée, vous voulez la connecter à l'écosystème externe. Dans la plupart des cas, je suis presque sûr que vous ne voulez pas vraiment connecter une seule chaîne à une seule chaîne externe.
Mais si nous utilisons l'approche LP ou l'approche "lock-and-mint", cela signifie que vous devez connecter votre chaîne unique à de nombreuses chaînes, ce qui est vraiment coûteux et nécessite beaucoup de liquidités. Dans la plupart des cas, il est normal de choisir une chaîne comme chaîne source et de la connecter à votre chaîne. Et dans ce cas, avec votre chaîne de destination, il peut s'agir d'une approche de type "lock-and-mint".
Mais cette chaîne externe peut être reliée à de très nombreuses autres chaînes externes de différentes manières. Par exemple, avec l'approche LP ou avec une approche basée sur l'intention. Si vous créez votre propre L2 ZK-rollup et que vous souhaitez accéder aux liquidités de l'écosystème externe, vous pouvez utiliser Arbitrum comme chaîne source.
Arbitrum peut être connecté à Tron via une approche basée sur l'intention et à Ethereum via une approche LP. Et ce dernier kilomètre ne sera qu'une approche de verrouillage et de menthe pour votre chaîne. La solution hybride vous permet donc d'accéder à toutes les liquidités externes sur des chaînes externes, mais avec une chaîne intermédiaire que vous utiliserez comme source pour votre propre chaîne personnalisée.
Je pense que la question la plus embarrassante est la suivante : combien êtes-vous prêt à dépenser pour cette solution de transition ? Et combien d'argent êtes-vous prêt à allouer à une solution ? Si nous parlons d'une approche basée sur l'intention, cela signifie que dès le début, vous devrez fournir des parrainages ou une autre raison pour que les solutionneurs restent des solutionneurs sur votre chaîne. Si le trafic dans votre chaîne n'est pas le plus important dès le premier jour, vous devrez vraiment sponsoriser leur solution. Si vous cessez de le faire, dans la plupart des cas, ils peuvent décider de désactiver leur solution.
Dans le cas contraire, si nous parlons d'une approche "lock-and-mint", vous devrez payer de l'argent aux messagers existants bien connus pour connecter votre chaîne à leur réseau de messagers. Et c'est beaucoup. Je veux dire que vous paierez des centaines de milliers de dollars américains juste pour être connecté, et c'est un paiement unique.
Si nous parlons de l'approche LP, vous pouvez essentiellement fournir vos propres liquidités. Cela signifie toujours que vous pouvez être le seul fournisseur de LP pour cette approche, mais que cette liquidité sera bloquée. Soit vous payez quelqu'un pour bloquer la liquidité, ce qui signifie également que vous devrez dépenser une partie de vos propres jetons ou, dans le meilleur des cas, un parrainage supplémentaire pour la liquidité bloquée.
Pour moi, la première et la plus importante question est donc de savoir combien vous êtes réellement prêt à y consacrer, et combien d'argent et de jetons vous êtes prêt à allouer à de telles solutions.

Andrew traduit les concepts décentralisés en outils financiers sécurisés et fonctionnels. Il navigue dans le paysage volatile de DeFi pour construire des infrastructures blockchain évolutives qui répondent à l'utilité du monde réel, dépassant les mots à la mode pour offrir une valeur technique.
Votre message a été envoyé.
Nous traiterons votre demande et vous contacterons dès que possible.