Ce que fait réellement un pont crypto, et pourquoi il doit détenir votre argent
Un pont crypto est une infrastructure qui vous permet de déplacer un jeton d'une blockchain à une autre. Si vous détenez de l'ETH sur le mainnet Ethereum mais souhaitez l'utiliser sur Solana pour trader un jeton qui s'y trouve, vous n'avez pas besoin de vendre vos ETH, de retirer sur une banque et de racheter de l'autre côté. Vous envoyez plutôt vos ETH à un pont, et de l'autre côté vous recevez une version « wrapped » qui représente votre dépôt sur la nouvelle chaîne.
Pour fonctionner sans intermédiaire de confiance, les ponts utilisent quasi systématiquement une forme de modèle lock-mint ou burn-mint. Vos ETH d'origine sont verrouillés dans un smart contract sur la chaîne source (ou brûlés, ce qui revient fonctionnellement au même — l'offre est détruite), et une quantité équivalente d'ETH « wrapped » (souvent appelée WETH, ou pour les variantes inter-chaînes comme celle de Wormhole, un ETH wrapped par Wormhole) est mintée sur la chaîne de destination. Pour revenir, vous brûlez le jeton wrapped, et le contrat libère (ou re-mint) l'original sur la chaîne d'origine.
Cette conception est élégante, mais elle entraîne une conséquence structurelle que les non-initiés au crypto oublient souvent : à tout moment, le pont repose sur l'intégralité des jetons que les utilisateurs y ont jamais déposés. Un pont ayant traité un milliard de dollars de volume peut détenir jusqu'à 300 millions de dollars en garde à son pic. Cette garde vit dans un smart contract — et ce contrat unique constitue toute la surface d'attaque. Volez les clés, compromettez les validateurs, ou trouvez un seul bug, et vous repartez avec le butin. Comparez cela à un DEX (exchange décentralisé) classique comme Uniswap, où la liquidité est répartie sur des milliers de pools indépendants et où un attaquant vidant un pool ne compromet pas les autres. Les ponts concentrent le risque comme presque rien d'autre dans la crypto.
Pourquoi les ponts continuent d'être piratés : les trois faiblesses structurelles
Lorsque vous lisez l'exploit d'un pont — et il y en a eu beaucoup — les autopsies décrivent généralement un bug précis ou une clé précisément compromise. Mais sous chacun d'eux se cache la même triade de faiblesses structurelles. C'est ce qui rend les ponts exceptionnellement attractifs aux yeux des attaquants.
Les ponts détiennent une valeur énorme dans un contrat unique. Le modèle lock-mint signifie que le contrat du pont sur la chaîne source détient les actifs réels, et que les jetons wrapped sur la chaîne de destination sont des créances sur ce pool. Si vous mintez sur la chaîne B sans verrouillage réel sur la chaîne A, vous avez créé des jetons wrapped non adossés qui s'effondreront dès que les utilisateurs tenteront de les rembourser. Tout le modèle de sécurité du pont repose donc sur ce contrat unique,加上 l'autorité de minting de l'autre côté. Un DEX d'un milliard de dollars représente, en termes d'attaquant, mille pots de miel d'un million. Un pont d'un milliard de dollars, c'est un pot de miel d'un milliard de dollars.
Les contrats de pont sont difficiles à mettre à jour une fois qu'ils détiennent de l'argent réel. Vous pourriez penser : « Il suffit de corriger le bug. » En théorie, oui. En pratique, les contrats de pont sont volontairement non upgradables, car tout l'intérêt d'un pont à confiance minimisée est qu'aucune partie ne puisse modifier les règles après votre dépôt. Si le déployeur détenait une clé de mise à jour, il pourrait rug les déposants en une seule transaction. Les contrats sont donc immuables — et des contrats immuables ne peuvent être corrigés lorsqu'une vulnérabilité est découverte. Le bug que vous avez livré en 2021 est le bug qui sera exploité en 2024, car il n'existe aucune partie centrale habilitée à le corriger sans briser la confiance des utilisateurs.
L'ensemble des validateurs qui protège le pont est plus restreint et plus faible que celui des chaînes qu'il relie. C'est le point le plus sous-estimé. Le mainnet Ethereum est sécurisé par des centaines de milliers de validateurs. Solana en compte des milliers. Un pont classique peut être protégé par un multisig 5 sur 9 (un portefeuille exigeant que cinq des neuf signataires pré-approuvés valident toute action), ou par un petit ensemble de validateurs que l'on peut recenser on-chain. Les attaquants étudient ces ensembles comme des braqueurs étudient les plannings de gardiens. Si cinq de ces neuf clés sont détenues par la même équipe, ou si les clés sont stockées sur un serveur chaud quelque part, ou si les membres du multisig ne se connaissent même pas, le pont a en réalité centralisé son modèle de sécurité sur une poignée d'humains — et les humains, comme Ronin l'a démontré, peuvent être victimes de phishing.
Comment le modèle verrouillage-mint est attaqué en pratique
Une fois que l'on comprend le modèle verrouillage-mint, les schémas d'attaque commencent à ressembler à des variations autour d'un même thème. L'attaquant n'a pas besoin de briser la blockchain sous-jacente. Il doit briser l'un des trois éléments suivants : le contrat de la chaîne source qui détient les dépôts, le contrat de la chaîne de destination qui émet les jetons enveloppés, ou l'infrastructure hors chaîne qui signe les messages inter-chaînes.
Des bogues de smart contract dans la logique de verrouillage ou de mint. Le cas classique est celui de Wormhole en février 2022. Wormhole était un pont populaire entre Ethereum et Solana qui permettait aux utilisateurs de déposer des ETH sur Ethereum et de recevoir des ETH enveloppés sur Solana. L'attaquant a trouvé un bogue dans le code côté Solana de Wormhole : une fonction que le pont utilisait pour vérifier qu'un dépôt avait réellement eu lieu sur Ethereum s'appuyait sur un compte « signature set » obsolète que l'attaquant pouvait remplacer par un faux. Avec une fausse signature en place, l'attaquant a convaincu le contrat Solana de minter 120 000 ETH enveloppés — d'une valeur d'environ 320 millions de dollars à l'époque — sans jamais verrouiller le moindre ETH réel sur Ethereum. Une fois la poussière retombée, les utilisateurs détenant le jeton enveloppé sur Solana ont découvert que leur « ETH » n'était adossé à rien, et l'équipe de Wormhole a dû injecter des capitaux depuis sa trésorerie pour indemniser les déposants. Le bogue se trouvait dans le code, pas dans les clés, mais l'effet structurel était identique.
Compromission du set de validateurs. Si un attaquant parvient à collecter suffisamment de clés ou de slots de signataires qui approuvent les messages inter-chaînes, il n'a pas besoin du moindre bogue. Il se contente de signer lui-même un message frauduleux, et le pont libère docilement les fonds. Le hack du pont Ronin en mars 2022 est l'exemple canonique. Ronin était une sidechain Ethereum construite pour le jeu play-to-earn Axie Infinity, et son pont était sécurisé par un multisig 5-sur-9. Cinq de ces neuf signataires étaient gérés par la même équipe (Sky Mavis, le développeur d'Axie). Les attaquants ont compromis quatre signataires de Sky Mavis ainsi qu'un cinquième partenaire, et sont repartis avec environ 625 millions de dollars en USDC et ETH. Ils n'ont brisé aucune primitive cryptographique — ils avaient simplement accès à suffisamment de signataires légitimes.
Conditions de course et bogues de rejeu dans le modèle burn-mint. Dans un modèle burn-mint, où les jetons sont détruits sur une chaîne et réémis sur une autre, un attaquant peut parfois tromper le pont en lui faisant traiter deux fois la même destruction, ou traiter une destruction sans attendre réellement la confirmation inter-chaînes. Le hack du pont Nomad en août 2022 en est une variante : une mise à jour de routine du contrat a marqué par accident chaque message comme valide, si bien que n'importe qui pouvait appeler le pont et retirer des fonds comme s'il avait déposé. Environ 190 millions de dollars ont été drainés par des opportunistes avant que le pont ne soit arrêté.
Les hacks de ponts célèbres, et ce que chacun enseigne
Lire les post-mortems des hacks de ponts célèbres est l'un des moyens les plus rapides d'intérioriser le modèle de menace. Chacun illustre une faiblesse différente d'une même conception générale.
Wormhole, février 2022 — ~320 millions de dollars. Cause : un bogue de vérification de signature côté Solana qui a permis à l'attaquant de minter des ETH enveloppés non adossés. Leçon : même un code bien audité peut présenter des failles logiques dans la façon dont il interprète les messages inter-chaînes. Le fait que le pont ait fonctionné parfaitement pendant des années ne signifiait pas qu'il était sûr.
Ronin, mars 2022 — ~625 millions de dollars. Cause : compromission de cinq des neuf clés du multisig via de l'ingénierie sociale et une infrastructure partenaire compromise. Leçon : la décentralisation des validateurs sur le papier n'est pas la même chose que la décentralisation des validateurs en pratique. Sky Mavis contrôlait la plupart des signataires « juste pour la commodité », et c'est cette concentration qui a été exploitée.
Harmony Horizon, juin 2022 — ~100 millions de dollars. Cause : compromission d'un multisig 2-sur-5 protégeant le pont, via des clés de hot wallet compromises. Leçon : les multisigs à seuil très bas et avec stockage des clés en hot wallet sont à peine meilleurs qu'un signataire unique.
Nomad, août 2022 — ~190 millions de dollars. Cause : une mise à jour de contrat qui a permis par accident des retraits arbitraires. Leçon : les contrats de pont conçus pour être upgradables peuvent aussi être upgradés dans un état vulnérable. L'immuabilité a deux tranchants.
Si l'on additionne ces quatre incidents, on obtient plus de 1,2 milliard de dollars de pertes, en une seule année, pour une seule catégorie de protocole. À titre de comparaison, toutes les autres catégories de hacks crypto combinées — DEX, protocoles de prêt, portefeuilles, particuliers — ne détruisent pas de capital à ce rythme rapporté à la TVL (total value locked, la valeur des actifs déposés dans un protocole).
Compromission du set de validateurs ou bogue de smart contract : lequel est le plus courant ?
Les bogues de smart contract font davantage parler d'eux parce qu'ils se lisent comme des énigmes. Une vérification de zéro oubliée, une Merkle root obsolète, un garde de réentrance qui ne se déclenche pas — voilà ce que mettent en avant les auditeurs, et ce sur quoi travaillent les développeurs. La compromission de validateurs est plus désordonnée. Elle implique des humains, des processus internes, une infrastructure hors chaîne, et parfois des attaquants étatiques. Mais si l'on additionne les pertes en dollars, la compromission de validateurs a historiquement été la catégorie la plus importante, et de loin.
Les vols chez Ronin, Harmony et plusieurs autres plus modestes étaient essentiellement des exploits du type « celui qui contrôle les signataires contrôle le pont ». Les attaquants n'avaient pas besoin de trouver un chemin de code astucieux ; il leur fallait une clé. Cela signifie que s'en défendre requiert une boîte à outils différente de celle employée contre les bogues de smart contract : des modules de sécurité matériels (des dispositifs matériels spécialisés conçus pour conserver les clés privées hors ligne et résistants aux manipulations) au lieu de hot wallets, des signataires géographiquement分散, de la cryptographie à seuil (où une clé privée est répartie en de nombreuses parts de sorte qu'aucun appareil ni aucune personne ne détienne jamais la clé complète) au lieu de multisigs statiques, et une surveillance continue de l'activité des signataires. Aucune de ces mesures n'est purement on-chain, ce qui explique pourquoi de nombreux ponts soucieux de sécurité se sont tournés vers des réseaux d'oracles décentralisés (des services qui amènent des données du monde réel ou inter-chaînes on-chain en utilisant de nombreux nœuds indépendants, comme le réseau de Chainlink alimenté par LINK) et vers des pools de validateurs dédiés pour répartir la confiance plus largement.
Les protocoles de messagerie inter-chaînes comme LayerZero et CCIP (Cross-Chain Interoperability Protocol) de Chainlink sont une tentative pour rendre cela moins pénible. Au lieu que chaque pont gère son propre set de validateurs, ils délèguent la vérification des messages à un réseau plus large et plus éprouvé — dans le cas de CCIP, le réseau d'oracles Chainlink, qui est conçu pour exiger la compromission de nombreux opérateurs de nœuds indépendants afin de falsifier un message. Le compromis, c'est que vous avez échangé une hypothèse de confiance spécifique à un petit pont contre une hypothèse de confiance plus large à l'échelle du réseau, et vous devriez comprendre à quoi ressemblent les modes de défaillance de ce réseau avant de vous y fier.
La sécurité partagée et CCIP comme voie alternative
Le constat honnête sur le problème des ponts, c'est qu'aucune conception ne supprime l'hypothèse de confiance — elle ne fait que la déplacer. Un pont qui utilise un petit set de validateurs fait confiance à ces validateurs. Un pont qui utilise un réseau d'oracles fait confiance au réseau d'oracles. Un pont qui utilise des light clients (des programmes sur une chaîne qui vérifient indépendamment les en-têtes de blocs d'une autre chaîne, supprimant le besoin de relayers externes) fait confiance à la solidité de la cryptographie et de l'implémentation. Un pont qui utilise un verrou basé sur un hash (l'utilisateur verrouille des fonds dans un hashlock sur une chaîne et révèle un secret pour les réclamer sur l'autre, la base des protocoles d'atomic swap) fait confiance au fait que la liquidité existe côté réception.
La sécurité partagée est la dernière tentative pour passer entre les gouttes. L'idée est qu'au lieu que chaque pont maintienne son propre set de validateurs sur mesure, les validateurs d'un grand réseau décentralisé — ou des chaînes sous-jacentes elles-mêmes — sont réutilisés pour la vérification inter-chaînes. Le CCIP de Chainlink est l'exemple le plus prominent en production aujourd'hui : plutôt que de faire tourner un set parallèle de signataires, le pont s'appuie sur l'infrastructure d'oracle existante de Chainlink ainsi que sur un Risk Management Network séparé comme seconde couche de défense. L'argument économique est qu'attaquer CCIP nécessiterait de compromettre à la fois le réseau d'oracles et le réseau de gestion du risque, ce qui est plus coûteux qu'attaquer le multisig d'un pont unique.
C'est une véritable amélioration, mais ce n'est pas une panacée. CCIP hérite des hypothèses de confiance du réseau d'oracles de Chainlink. Si ce réseau est compromis, CCIP est compromis. Si un nouveau modèle de sécurité partagée émerge et que 80 % des ponts l'adoptent, ce modèle devient un point de défaillance unique pour l'ensemble de l'écosystème inter-chaînes. Il y a une raison pour laquelle les utilisateurs DeFi aguerris continuent de répartir les gros transferts sur plusieurs routes et ne confient à aucun pont unique des montants qui changeraient leur vie.
Comment évaluer un pont avant de l'utiliser
Il n'existe pas de « pont sûr ». Quiconque vous dit le contraire cherche à vous vendre quelque chose. Mais certains ponts sont plus ou moins risqués, et quelques questions permettent de modifier sensiblement le risque que vous encourez. Considérez ceci comme une liste de contrôle, pas comme une garantie.
Comment la garde est-elle répartie ? Examinez l'administrateur et l'ensemble des signataires on-chain. Un multisig 2-sur-5 est considérablement plus risqué qu'une configuration 12-sur-20. Vérifiez si les signataires sont des entités indépendantes ou des branches d'une même équipe. Examinez comment les clés sont stockées — des hot wallets sur un serveur cloud sont un signal d'alarme ; des hardware wallets répartis sur différentes zones géographiques sont préférables.
Les contrats sont-ils upgradeables, et par qui ? L'immuabilité est une arme à double tranchant. Un contrat immuable ne peut pas être corrigé, ce qui signifie qu'un bug reste un bug pour toujours. Un contrat upgradeable peut être corrigé, ce qui signifie qu'un détenteur de clé malveillant ou compromis peut aussi changer les règles. Lisez la documentation pour comprendre précisément quels pouvoirs de mise à jour existent et qui les détient.
A-t-il été audité, et par qui ? Un audit n'est pas une garantie. Un unique audit réalisé par un cabinet de second plan n'équivaut pas à plusieurs audits menés par des cabinets de premier plan accompagnés d'un bug bounty public. Recherchez les rapports d'audit, examinez ce qui a été trouvé, et voyez comment l'équipe a répondu aux conclusions.
Depuis combien de temps est-il en production, et quel volume a-t-il traité ? Un pont qui a transféré 20 milliards de dollars sur trois ans et n'a jamais été exploité dispose d'un historique empirique. Un pont lancé la semaine dernière n'a aucun historique, quelle que soit la qualité de son marketing.
Quel est le pire scénario en cas de défaillance ? Lisez les post-mortems d'incidents passés et réfléchissez : si le pont est piraté demain, comment les utilisateurs sont-ils indemnisés ? Existe-t-il un fonds d'assurance ? Le protocole dispose-t-il d'une trésorerie suffisamment importante pour couvrir les pertes ? Si la réponse est « rien », vous devriez considérer votre dépôt comme étant exposé à 100 % dès l'instant où il est effectué.
Comment suivre les exploits de ponts de manière intelligente
Les exploits de ponts vont vite — au moment où un post-mortem est publié sur un blog, le prochain incident est déjà en préparation. Suivre les ponts en cours d'audit, ceux qui se lancent, ceux qui ont connu récemment des incidents de sécurité, et la façon dont l'espace cross-chain évolue est un travail à temps plein si vous le faites manuellement. Zippfeed fait remonter les titres liés aux ponts et à l'interopérabilité avec une notation de sentiment (bullish, neutral ou bearish) et une note d'importance, afin que vous puissiez repérer les signaux pertinents sans avoir à lire chaque thread vous-même. Ainsi, lorsqu'un nouveau pont « audité » est lancé ou qu'un nom familier apparaît dans un avis de sécurité, vous le voyez en contexte — et non dans la panique de la tempête de tweets post-piratage.
