Nouveau piratage dans le secteur du pont cross-chain : analyse approfondie de la logique de conception du secteur des ponts cross-chain depuis une perspective produit
TechFlow SélectionTechFlow Sélection
Nouveau piratage dans le secteur du pont cross-chain : analyse approfondie de la logique de conception du secteur des ponts cross-chain depuis une perspective produit
Les problèmes récents de sécurité dans les projets de ponts entre chaînes ont attiré une attention croissante du marché. Cet article souhaite expliquer, d’un point de vue conception produit, pourquoi ce secteur connaît autant d’incidents de sécurité.
Dédié à des analyses Web3 approfondiesAuteur : 0xOar
Production : Seer Labs
Préambule :
Les récents problèmes de sécurité liés au ponting multi-chaînes ont attiré une grande attention du marché. Cet article souhaite expliquer, d’un point de vue conception produit, pourquoi ce secteur connaît autant d’incidents de sécurité. Il est important de préciser que les problèmes mentionnés ici ne concernent pas tous les projets : la plupart ont déjà mis en place des stratégies préventives lors de leur conception. L’objectif principal est surtout de permettre à davantage de personnes de comprendre le niveau élevé de complexité inhérent à ce domaine.
Nous allons d’abord vous présenter comment sont conçus les ponts multi-chaînes standards, puis aborder les risques de sécurité auxquels ils peuvent être exposés.
01 Schémas multi-chaînes : toujours les mêmes principes fondamentaux
Des rapports précédents ont déjà présenté plusieurs types de solutions pour transférer des informations entre chaînes. Quelle que soit leur forme finale, d’un point de vue conception produit, il n’existe que trois mécanismes fondamentaux : les sidechains (au sens large — incluant ici les rollups), le verrouillage temporel par hachage (HTLC) et le système de notaires (« notary-based »).
(I) Sidechain
Parmi ces trois schémas, la solution basée sur les sidechains est la plus sécurisée, comme c’est le cas par exemple pour les différents rollups ou les parachains de Polkadot.
La chaîne principale et la sidechain partagent la même sécurité. Toutefois, cette approche exige généralement que la chaîne source et la chaîne cible soient homogènes (de même nature), ce qui limite fortement son champ d’application. C’est précisément pourquoi Vitalik Buterin soutient l’idée du multichain mais rejette celle du cross-chain : selon lui, les solutions cross-chain incapables de partager la sécurité posent bien trop de problèmes.
(II) Verrouillage temporel par hachage (Hashed TimeLock Contract - HTLC)
Cette solution est souvent présentée comme la méthode la plus décentralisée pour connecter des chaînes hétérogènes via un échange point à point. Toutefois, elle s’avère coûteuse et implique des délais d’attente longs pour les utilisateurs, ce qui explique son faible taux d’adoption actuel. De plus, si nous devons encore faire appel à un tiers comme intermédiaire de change, il nous faut aussi une couche consensus intermédiaire hypothétique pour garantir sécurité et décentralisation.
(III) Mécanisme de notaires
Il s’agit de la solution la plus couramment utilisée aujourd’hui pour les ponts entre chaînes hétérogènes. La majorité des produits disponibles sur le marché proviennent essentiellement de la même base technique, et du point de vue conception produit, leurs différences sont quasi inexistantes. Les variations portent principalement sur la méthode de vérification des informations, l’algorithme de consensus des notaires ou l’algorithme de signature des wallets de garde. En termes d’expérience utilisateur et de sécurité, les écarts restent minimes. Ainsi, du point de vue de la sécurité, les risques encourus présentent de nombreuses similitudes.
Cet article se concentrera donc sur l’analyse et la synthèse des risques de sécurité communs aux ponts multi-chaînes fonctionnant selon le mécanisme de notaires.
02 Logique produit du mécanisme de notaires
Avant d’aborder les divers risques liés au mécanisme de notaires, il convient d’en comprendre la logique de conception produit.
(I) Présentation succincte
Du point de vue philosophique, cette solution est très simple. Face à la nécessité de transférer des actifs entre chaînes hétérogènes, l’approche la plus intuitive est celle du « mappage ». Le mappage signifie que lorsque l’utilisateur A transfère ses ETH depuis Ethereum vers Fantom, on n’a pas besoin de déplacer physiquement l’actif ni de le réémettre sur Fantom (ce qui est impossible). On bloque simplement les ETH de l’utilisateur A dans une adresse inaccessible, puis on émet sur Fantom un actif mappé correspondant, avec un ratio 1:1. Cet actif mappé représente alors le droit d’utilisation des ETH bloqués sur la chaîne d’origine. Grâce à cet ancrage 1:1, les utilisateurs de Fantom reconnaissent la valeur de cet actif.
Flux simplifié d’un transfert cross-chain :
(II) Difficultés de conception
De nombreux problèmes apparaissent ici, le principal étant la gestion du wallet multisignature. En effet, lorsque l’utilisateur A transfère ses ETH d’Ethereum vers Fantom, il s’agit d’un dépôt (« deposit »), mais s’il souhaite revenir en arrière, cela implique une opération de retrait (« withdrawal »).
La décentralisation et la sécurité autour des opérations de dépôt et de retrait deviennent alors les points critiques.
1. Qui gère les fonds ? 2. Qui initie la transaction ? 3. Qui surveille les transactions ? 4. Comment confirmer qu’un utilisateur a bien envoyé des fonds ? 5. Comment vérifier que le retrait est bien demandé par l’utilisateur légitime ? 6. Comment éviter les attaques par rejeu (replay attacks) ? 7. Que faire si une transaction échoue ? Comment la relancer ? 8. Que faire si les gestionnaires multisignatures deviennent malveillants ? 9. Comment réagir en cas de panne (downtime) ?
On n’ose même pas y penser : plus on creuse, plus cela semble compliqué. La technologie des ponts multi-chaînes ne concerne pas seulement les wallets multisignatures, mais aussi l’émission d’actifs, la surveillance des transactions entre chaînes, la validation asynchrone, voire même la création d’une couche consensus intermédiaire indépendante (une nouvelle blockchain).
Afin de simplifier la compréhension pour l’utilisateur, je vais diviser tout le processus de ponting en deux parties distinctes : dépôt et retrait. Cela permettra une meilleure compréhension.
(III) Détail du processus
1. Dépôt (Deposit)
Précision importante : le processus illustré ci-dessous est une proposition théorique issue de mes propres analyses. Il n’a pas été rigoureusement validé. Son objectif est uniquement d’explorer les problèmes de sécurité potentiels dans la logique de conception, et non d’être utilisé comme solution finale. Tout ceci relève donc de la spéculation.
Comme illustré ci-dessus, une transaction de dépôt depuis la chaîne d’origine vers la chaîne cible suit en principe les étapes suivantes :
(1) L'utilisateur dépose ses fonds sur une adresse de garde
(2) Un écouteur détecte cette transaction, puis un BP (nœud de consensus, également administrateur multisignature) lance la transaction
(3) Le contrat vérifie la validité de la signature du BP
(4) Le mécanisme de tolérance aux pannes des nœuds est-il respecté ?
(5) Si non, remboursement ; sinon, crédite l'adresse cible selon la relation de mappage
(6) Le BP confirme cette transaction de dépôt
(7) Après consensus byzantin, le jeton mappé est transféré à l’adresse de l’utilisateur sur la chaîne cible
Attention : ce processus vise à traiter les cas généraux de ponting entre chaînes hétérogènes. Comparé à des solutions comme Anyswap, il ajoute une étape où l’utilisateur lie les adresses sur une couche consensus intermédiaire. Ceci est nécessaire car les méthodes d’inclusion des données transactionnelles varient selon les chaînes hétérogènes. Pour uniformiser le traitement, mieux vaut lier les adresses dès le départ. Pour les chaînes EVM, cette étape est inutile : l’adresse cible peut être directement incluse dans la transaction initiale.
Revenons au sujet principal. À partir de la deuxième étape, divers problèmes de vérification logique et de gestion de cas particuliers apparaissent.
Les principales logiques de vérification comprennent :
(1) Vérification de la demande de mappage d’actifs après détection de la transaction, puis de la transaction vers l’adresse cible
(2) Vérification de l’initiation de la transaction sur la chaîne cible et du résultat final
Outre ces vérifications incluses dans mon schéma, il convient aussi de valider contre les faux dépôts, ainsi que de gérer correctement les particularités liées à chaque type de token.
Pour mieux identifier les risques de sécurité possibles par la suite, examinons maintenant le processus de retrait.
2. Retrait (Withdrawal)
Le processus de retrait illustre la logique par laquelle un actif mappé sur la chaîne cible est échangé contre l’actif d’origine. Notons que de nombreux tokens existent désormais sur plusieurs chaînes, ayant des versions natives sur chacune. Certains projets de pont créent donc des pools de liquidités. Lorsque ces pools sont suffisamment approvisionnés, l’utilisateur ne perçoit pas la différence entre un actif mappé (comme anyDAI) et le token natif de la chaîne cible, car il obtient directement ce dernier. Cependant, cela ne change pas la logique globale. Analysons donc la suite.
Comme illustré, le flux d’une transaction de retrait de la chaîne cible vers la chaîne d’origine est le suivant : (1) L’utilisateur lance une transaction (envoie un montant équivalent de jetons mappés vers le wallet de garde sur la chaîne cible) (2) Vérification de l’identité du BP, un BP lance la demande de retrait (3) Confirmation des droits et de la signature de retrait (4) Une fois le consensus byzantin atteint, la demande est exécutée sur la chaîne d’origine : les fonds sont retirés du wallet de garde et transférés à l’utilisateur A (5) En cas d’erreur de validation ou de panne, rollback et relance de la demande. Comme visible, les principales logiques de vérification impliquées sont : (1) Vérification des droits et de la signature d’initiation (2) Mécanisme de tolérance aux pannes en cas de problème.
(IV) Risques de sécurité
1. Problèmes de sécurité liés à la logique de conception
Après une analyse détaillée de la conception des ponts multi-chaînes, on constate que ceux-ci font face à de nombreux défis. Trois grandes catégories de problèmes peuvent être identifiées (des exemples de piratages associés sont indiqués à la fin de chaque point).
(1) Dépôt (Deposit)
a) Vulnérabilité dans les permissions du contrat de dépôt, permettant de transférer immédiatement les fonds déposés. Ce problème stupide touche presque tous les projets contractuels.
b) Problème de faux dépôts : certains projets ne valident pas l’authenticité du token cross-chain, permettant à un fakeTOKEN d’être échangé contre un realTOKEN (Anyswap). Honnêtement, c’est assez naïf.
d) Problème similaire avec les actifs natifs comme l’ETH : contrairement aux tokens ERC20, de nombreuses attaques surviennent en raison d’un traitement inadéquat de l’ETH, permettant à un fakeETH d’être échangé contre un realETH. C’est d’ailleurs pourquoi les actifs enveloppés (wrapped) comme WETH sont devenus populaires (Thorchain).
c) Bien que conformes à la norme ERC20, différents tokens peuvent avoir des implémentations variées ou des logiques supplémentaires (rebase, fallback, etc.). Si les développeurs ne font pas les bons tests d’adaptation, cela complique la gestion du pont. Par exemple, certains tokens (WETH, PERI, OMT, WBNB, MATIC, AVAX) appellent après transfert une fonction fallback personnalisée du sender, augmentant la complexité du pont (Anyswap, 18 janvier 2022).
(2) Transfert de messages cross-chain
Entre le moment où un dépôt est confirmé sur la chaîne A et celui où l’actif est crédité sur la chaîne B, le pont agit comme un système blockchain indépendant, nécessitant un mécanisme de consensus (généralement DPoS). Voici quelques problèmes à considérer sous l’hypothèse d’un consensus DPoS (je soupçonne que tous les nœuds sont contrôlés par l’équipe projet, ce qui pose un risque centralisé) :
a) Écoute des messages de dépôt : qui lance la première proposition de traitement cross-chain ? Aléatoirement ? À tour de rôle ? Selon l’ordre de blocs de la couche consensus intermédiaire ?
b) Comment les notaires vérifient-ils la validité du dépôt ? Si toutes les sources de données proviennent d’un fournisseur comme Infura, cela crée un point de défaillance unique. La solution la plus robuste serait que chaque nœud maintienne son propre nœud, mais cela implique un coût élevé.
c) Comment confirmer que le traitement cross-chain est terminé (crédit effectué sur B) ? En cas d’échec, plusieurs scénarios possibles :
i. Le pont n’a pas lancé le traitement
ii. Le pont a lancé le traitement, mais la validation ou le consensus a échoué
iii. Le pont a validé, mais n’a pas initié la transaction sur B
iv. Une transaction existe sur B, mais a échoué (fonds insuffisants ou autre cause)
(3) Problèmes de vérification multisignature
Zone à risque élevée, majoritairement due à des erreurs logicielles :
a) Signature 3/5 : j’ajoute arbitrairement une signature non incluse dans la liste multisignature, comptabilisée comme +1 (ChainSwap).
b) Centralisation : bien que nominalement multisignature, les clés sont en réalité détenues par l’équipe projet, créant un risque énorme.
c) Méthode de vérification des signatures : les modèles de développement varient selon les chaînes, ce qui peut amener des oublis. Exemple Wormhole : sur Solana, la fonction de vérification des signatures est une fonction du contrat système. Normalement, il faut appeler ce contrat système, dont l’adresse doit être codée en dur. Ici, l’adresse du contrat système est passée en paramètre. Le pirate, lors du retrait, fournit une fausse adresse de contrat système, contournant ainsi la vérification et réussissant à retirer les fonds.
(4) Remboursements
a) Comme discuté dans (2)-c, l’état cross-chain peut prendre plusieurs formes. Dans tous les cas, il faut offrir aux utilisateurs un moyen de remboursement. Par exemple, Anyswap envoie d’abord un anyToken sur la chaîne source, puis sur la chaîne cible, et brûle ensuite l’anyToken source. Ainsi, peu importe où se situe le problème, l’utilisateur peut prouver sa propriété via l’anyToken. Ce processus implique 3 chaînes (source, cible, pont) et 4 actifs (token natif et anyToken sur chaque chaîne), rendant très probable une erreur logicielle.
b) Thorchain, le 23 juillet 2021 : un pirate exploite une faille logicielle pour simuler un dépôt massif fictif. Le pont ne pouvant traiter cette situation, le mécanisme de remboursement est déclenché, permettant au pirate d’obtenir un remboursement colossal.
2. Autres risques de sécurité
Les problèmes visibles à travers les flux logiques ne représentent que les failles liées à la logique métier, et non l’intégralité des risques. Du point de vue sécurité, trois autres catégories doivent être prises en compte :
(1) Risques systémiques
Par exemple, un dépôt réussi sur la chaîne d’origine peut être annulé par un rollback ultérieur — un problème majeur. Vitalik Buterin a évoqué ce cas : si un actif passe de Solana à Ethereum, puis que Solana fait un rollback, l’utilisateur double ses actifs. Aucune solution n’existe. En revanche, les layer 2 comme les rollups, qui partagent la sécurité d’Ethereum, n’ont pas ce problème.
(2) Risques front-end
a) Sites falsifiés : oxdao.fi, 0xdao.fi, oxdai.fi, etc.
b) Attaques XSS (cross-site scripting) : injection de code. Exemple : www.xxxx.finance/?params=hackerscode12345. Même si l’URL est officielle, elle contient du code malveillant. Si le front-end n’est pas protégé contre le XSS, ce code s’exécute, autorisant le pirate à signer une transaction de transfert au nom de l’utilisateur. Ne cliquez jamais sur des liens suspects.
c) Attaques CORS (Cross-Origin Resource Sharing) : bien que la politique de même origine (same-origin policy) impose que les contenus affichés par www.xxxx.finance proviennent exclusivement du domaine xxxx.finance, la plupart des projets autorisent aujourd’hui les appels croisés (ex : le front-end xxxx appelle l’API de Quickswap). Cela facilite le développement, mais introduit des risques. Si vous visitez xxxx.finance, des données sensibles sont stockées en cache. Si vous accédez ensuite à un site malveillant et que xxxx.finance n’a pas restreint strictement sa politique CORS, ce site malveillant pourra lire ces données en cache.
(3) Risques liés aux fonctionnalités supplémentaires
Certains ponts multi-chaînes offrent non seulement le transfert d’actifs, mais aussi l’appel de contrats cross-chain. Cela ajoute une complexité dangereuse. Un attaquant lance sur la chaîne A un appel vers un contrat X sur la chaîne B. Le pont exécute cet appel sans vérifier la nature de X. Or, X est justement le contrat multisignature du pont sur B. L’appel modifie l’adresse du wallet multisignature pour la remplacer par celle de l’attaquant. Une fois exécuté, le pirate contrôle entièrement les fonds du pont sur la chaîne B (Poly Network).
03 Conclusion
1. L’objectif de ce rapport est d’aider les utilisateurs à comprendre clairement les risques de sécurité des ponts multi-chaînes, sans chercher à dramatiser ou diaboliser ces outils.
2. La solution basée sur les notaires reste, à ce jour, celle qui offre la meilleure expérience utilisateur, la plus grande compatibilité et le coût le plus faible. Tous les produits passent par une phase difficile avant de mûrir. Les attaques subies par les produits blockchain sont souvent dues à des « problèmes logiques ». Avec le temps et l’accumulation d’expérience, ces problèmes ne feront que s’améliorer.
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
