Comment les ponts crypto déplacent des milliards et pourquoi les hackers les cassent sans cesse

Les ponts cross-chain ont perdu plus d'argent dans des exploits que presque toute autre catégorie dans la crypto.

Le pont Ronin a perdu 625 millions de dollars en 2022. Wormhole a perdu 320 millions la même année. Nomad a perdu 190 millions quelques mois plus tard.

Pourtant, les ponts sont plus importants que jamais.

TAC, Celo et des dizaines d'autres projets s'appuient sur eux pour relier des écosystèmes blockchain séparés qui, autrement, ne peuvent pas communiquer entre eux.

Comprendre pourquoi les ponts sont à la fois indispensables et dangereux commence par comprendre ce qu'ils font réellement au niveau technique.

TL;DR

Un pont blockchain est un logiciel qui verrouille des actifs sur une chaîne et frappe des représentations équivalentes sur une autre, permettant de déplacer la valeur entre des réseaux isolés.

Les ponts sont des cibles de grande valeur car ils conservent les actifs verrouillés, parfois des milliards de dollars, dans des smart contracts ou des portefeuilles multisig.

Il existe quatre grands types de ponts (verrouillage‑et‑frappe, brûlage‑et‑frappe, pools de liquidité et vérification via light client), chacun avec ses propres compromis de sécurité.

La plupart des gros hacks ont exploité la compromission de clés de validateurs, la manipulation d’oracles ou des bugs logiques dans les smart contracts, et non les blockchains sous‑jacentes elles‑mêmes.

De nouveaux modèles à confiance minimisée utilisant des preuves à connaissance nulle réduisent la surface d’attaque, mais aucun pont n’est sans risque aujourd’hui.

Ce que fait vraiment un pont blockchain

Deux blockchains sont, par défaut, des systèmes totalement isolés.

Bitcoin (BTC) n'a aucune connaissance d’Ethereum (ETH). Ethereum ne peut pas lire nativement une mise à jour d’état de Solana (SOL).

Chaque chaîne traite ses propres transactions, maintient son propre registre et atteint son consensus de manière indépendante. Il n’y a pas de mémoire partagée entre elles.

Un pont est la couche logicielle qui crée l’illusion d’un mouvement cross-chain.

En pratique, les actifs ne « se déplacent » pas littéralement d’une chaîne à une autre. Ce qui se passe réellement est un processus en deux étapes : un actif est verrouillé (ou brûlé) sur la chaîne source, et une représentation correspondante est frappée (ou libérée) sur la chaîne de destination.

Le protocole de pont coordonne ces deux événements et garantit qu’ils sont liés.

Un pont ne téléporte pas vos tokens. Il les verrouille d’un côté et imprime un IOU de l’autre — la question de sécurité est toujours : qui contrôle le verrou, et qui autorise l’impression ?

Cette distinction est cruciale pour la sécurité.

L’actif original est conservé quelque part. Cette conservation est la surface d’attaque.

Qu’il s’agisse d’un smart contract, d’un portefeuille multisig contrôlé par un comité de validateurs, ou d’un système de preuves cryptographiques détermine presque entièrement à quel point le pont est sûr.

Les quatre principaux types de ponts

Tous les ponts ne fonctionnent pas de la même façon. Quatre grands modèles d’architecture dominent aujourd’hui en production, chacun faisant des compromis différents entre sécurité, vitesse, efficacité du capital et décentralisation.

Le modèle verrouillage‑et‑frappe est le plus courant. Un utilisateur envoie des tokens à un smart contract sur la chaîne source, où ils sont verrouillés. L’ensemble de validateurs du pont observe ce dépôt et ordonne à la chaîne de destination de frapper une version « wrappée » de ce token. Le Bitcoin wrappé (WBTC) sur Ethereum fonctionne ainsi. C’est aussi le cas de la plupart des ETH bridgés sur les premiers réseaux Layer 2. Le token wrappé représente une créance sur l’original verrouillé. Quand un utilisateur veut revenir en arrière, il brûle le token wrappé et le verrou sur la chaîne source est libéré.

Le modèle brûlage‑et‑frappe est utilisé quand l’émetteur d’un token contrôle directement l’offre sur plusieurs chaînes. Au lieu de wrapper, le token est brûlé sur la chaîne source (ce qui réduit l’offre totale là‑bas) et frappé à neuf sur la chaîne de destination. Le protocole Cross‑Chain Transfer Protocol (CCTP) de Circle pour USD Coin (USDC) fonctionne ainsi. Comme c’est Circle qui autorise lui‑même la frappe, il n’y a pas de pool de tokens verrouillés à voler pour un attaquant, mais vous faites entièrement confiance à Circle.

Les ponts à pools de liquidité, comme ceux utilisés par Hop Protocol et Across Protocol, fonctionnent différemment. Au lieu de verrouiller des actifs et de frapper des représentations, ils s’appuient sur des fournisseurs de liquidité qui détiennent le token natif des deux côtés. Un utilisateur dépose sur la chaîne source, et un fournisseur de liquidité sur la chaîne de destination lui envoie immédiatement l’équivalent en token natif. Le LP est ensuite remboursé par le protocole. Cette approche est plus rapide et évite les tokens wrappés, mais elle dépend d’une liquidité suffisante et introduit un risque de contrepartie pour les LP.

La vérification via light client est le modèle le plus à confiance minimisée et le plus difficile à construire. Ici, la chaîne de destination exécute une preuve cryptographique du consensus de la chaîne source directement dans un smart contract ou un circuit ZK. Aucun comité de validateurs externe n’est requis, les mathématiques prouvent que le dépôt a eu lieu. IBC (Inter‑Blockchain Communication), la norme de pont utilisée à travers les chaînes Cosmos (ATOM), se rapproche de ce modèle. Les ponts basés sur les ZK comme SP1 de Succinct et zkBridge de Polyhedra vont plus loin en utilisant des preuves à connaissance nulle pour vérifier les transitions d’état à moindre coût.

Pourquoi les ponts concentrent autant de risques

La surface d’attaque d’un pont est fondamentalement différente de celle d’une blockchain unique. Une chaîne comme Ethereum est sécurisée par des centaines de milliards de dollars en ETH mis en staking et des centaines de milliers de validateurs. La compromettre nécessite de compromettre une grande fraction de cet ensemble de validateurs en même temps, une attaque presque impossible à financer.

L’ensemble de validateurs d’un pont est souvent beaucoup plus petit. Le pont Ronin, qui servait le jeu Axie Infinity sur sa propre sidechain, était sécurisé par seulement neuf nœuds validateurs. Un attaquant devait en contrôler cinq pour autoriser des retraits. Le Lazarus Group, l’organisation de hackers parrainée par l’État nord‑coréen, a compromis cinq clés privées via une combinaison de phishing et de fausse offre d’emploi. Ils ont autorisé 625 millions de dollars de retraits frauduleux. Les blockchains Ethereum et Ronin sous‑jacentes n’ont jamais été touchées.

Le hack de Ronin n’a pas cassé une blockchain. Il a cassé un comité de validateurs neuf‑sur‑neuf où cinq clés étaient conservées de manière peu sûre. Le pont était le maillon le plus faible par conception.

C’est le problème structurel des ponts validés de manière externe. Leur sécurité n’est pas héritée des chaînes qu’ils relient, c’est un système séparé, souvent plus petit et moins éprouvé. Plus un pont détient de valeur, plus il devient une cible attrayante, mais le modèle de sécurité ne se met pas automatiquement à l’échelle avec les actifs sous garde.

L’exploit de Wormhole en février 2022 était différent dans son mécanisme mais similaire dans son résultat. Un attaquant a trouvé un bug dans le smart contract Wormhole sur Solana qui lui a permis de falsifier un événement de « vérification de signature de gardien ». Il a convaincu le contrat que 120 000 ETH avaient été déposés sur Ethereum alors que ce n’était pas le cas, et a frappé 320 millions de dollars d’ETH wrappés sur Solana. Aucun validateur n’a été compromis. La vulnérabilité se trouvait dans la logique même du contrat. Jump Crypto, le souteneur de Wormhole, a remplacé les fonds en moins de 24 heures, ce qui a évité un effondrement du marché mais n’a pas corrigé la faille sous‑jacente.

Le rôle des validateurs et des oracles

La plupart des ponts qui ne sont pas de purs systèmes à light client s’appuient sur une forme d’observateur externe pour confirmer qu’un dépôt a eu lieu et pour autoriser la frappe ou la libération correspondante.

Ces observateurs portent différents noms — validateurs, relayeurs, gardiens, attesteurs — mais ils remplissent la même fonction : surveiller une chaîne et rapporter son état à une autre.

La question de confiance est toujours : que faut‑il pour faire mentir ces observateurs ?

Dans un modèle multisig, la réponse est « compromettre suffisamment de clés ». Dans un modèle basé sur des oracles, la réponse peut être « manipuler le flux de prix ou les données de blocs que l’oracle rapporte ». Dans un modèle de validateurs en preuve d’enjeu, la réponse est « acquérir assez de mise pour contrôler une supermajorité ».

LayerZero utilise un modèle où chaque application configure son propre ensemble d’oracles et de relayeurs, créant une sécurité spécifique à l’application plutôt qu’un ensemble partagé de validateurs de pont. Cela déplace le risque de « un pont échoue, tout échoue » vers « chaque application supporte son propre risque », ce qui est une amélioration significative en termes d’isolation, mais met davantage de responsabilité sur les développeurs pour configurer correctement la sécurité.

Axelar utilise un réseau de validateurs en preuve d’enjeu qui lui est propre pour observer les événements cross‑chain. La sécurité du pont est donc liée à la valeur du token natif d’Axelar mis en staking par les validateurs, un modèle similaire à celui d’une blockchain de couche 1, mais dédié à la messagerie inter‑chaînes.

Le défi fondamental est que vous ne pouvez pas vérifier nativement l’état d’une chaîne étrangère sans exécuter le nœud complet de cette chaîne, ce qui est coûteux. Les approches via light client et ZK résolvent ce problème cryptographiquement. Tout le reste implique de faire confiance à un intermédiaire pour rapporter honnêtement.

Comment les preuves ZK changent la sécurité des ponts

Les preuves à connaissance nulle sont la solution la plus prometteuse à long terme au problème de confiance des ponts. Une preuve ZK permet à une partie de prouver à une autre qu’une affirmation est vraie, comme « cette transaction a été incluse dans un bloc finalisé sur Ethereum », sans que le vérificateur ait à rejouer lui‑même tout le calcul.

Appliqué aux ponts, cela signifie qu’une chaîne de destination peut vérifier un événement sur la chaîne source cryptographiquement, sans avoir à faire confiance à un validateur externe. La preuve elle-même est l’attestation. Un validateur compromis ne peut pas forger une preuve ZK valide. Il n’y a pas de clés privées à voler. La sécurité découle des mathématiques.

Le défi pratique réside dans le coût de calcul. Générer des preuves ZK pour un consensus de chaîne complet (comme l’agrégation de signatures BLS du Proof of Stake d’Ethereum sur des milliers de validateurs) nécessite un travail computationnel considérable, même si ce coût a chuté de façon spectaculaire à mesure que la technologie de preuve ZK a mûri. Des équipes comme Succinct Labs, =nil; Foundation et Polyhedra construisent des systèmes de preuve spécifiquement optimisés pour la vérification de l’état des blockchains.

TAC, la couche 1 actuellement tendance sur CoinGecko, adopte une approche spécifique de ce problème : elle relie l’écosystème développeur EVM d’Ethereum au réseau TON (The Open Network) et à la base d’utilisateurs de Telegram, en utilisant un modèle hybride de validateurs et de preuves. Des projets comme TAC illustrent la demande pratique pour les bridges : Telegram compte environ 950 millions d’utilisateurs actifs mensuels, et connecter ce public aux applications compatibles Ethereum nécessite précisément le type d’infrastructure inter-chaînes que fournissent les bridges.

Le compromis des bridges ZK aujourd’hui est la latence. Générer une preuve pour un bloc Ethereum finalisé peut prendre plusieurs minutes. Pour les applications nécessitant une finalité rapide, les bridges optimistes avec fenêtres de preuves de fraude sont encore souvent préférés, en acceptant un délai de retrait plus long (généralement 7 jours sur les principaux rollups optimistes) en échange de la simplicité.

Bridges natifs contre bridges tiers

Lorsque vous déplacez des actifs entre une couche 1 et son rollup de couche 2, vous utilisez généralement un « bridge natif », un bridge construit et maintenu par l’équipe du rollup elle-même, profondément intégré au modèle de sécurité propre au rollup. Le bridge natif d’Arbitrum (ARB), le bridge natif d’Optimism (OP) et le bridge natif de zkSync entrent tous dans cette catégorie.

Les bridges natifs héritent d’une grande partie des garanties de sécurité propres au rollup. Sur un rollup optimiste, un retrait frauduleux peut être contesté pendant la fenêtre de 7 jours de preuve de fraude. Sur un rollup ZK, un retrait n’est finalisé qu’une fois qu’une preuve ZK valide du lot de transactions est publiée sur Ethereum. Ce sont des garanties sensiblement plus fortes que celles de la plupart des bridges tiers.

Le compromis est que les bridges natifs ne vont que dans une direction : de L1 vers L2 et retour. Ils ne peuvent pas transférer des actifs Ethereum vers Solana, ni déplacer directement des actifs entre deux L2 distincts. Pour les mouvements entre écosystèmes différents, d’Ethereum vers Solana, ou d’Arbitrum vers Polygon (POL), les utilisateurs doivent recourir à des bridges tiers, qui comportent les risques de validateurs et de contrats intelligents décrits plus haut.

Cela crée une taxonomie pratique : utiliser les bridges natifs pour les mouvements L1-vers-L2 lorsque la sécurité est prioritaire, et utiliser des bridges tiers audités avec antécédents pour les mouvements inter‑écosystèmes lorsque vous acceptez le risque supplémentaire. Vérifier si un bridge a été audité par une société de sécurité réputée (Trail of Bits, OpenZeppelin, Certik, Spearbit) et examiner tout historique d’exploitation antérieur constitue le minimum de diligence raisonnable avant d’utiliser un service de transfert inter‑chaînes.

Qui a réellement besoin d’utiliser un bridge

Les bridges ne sont pas nécessaires pour la plupart des utilisateurs occasionnels de crypto. Si vous détenez du Bitcoin (BTC) ou de l’Ethereum (ETH) sur un exchange centralisé et que vous voulez simplement une exposition aux mouvements de prix, vous n’utiliserez jamais de bridge.

Vous avez besoin d’un bridge lorsque vous voulez utiliser une application qui vit sur une chaîne différente de celle où se trouvent vos actifs. Si votre ETH est sur le mainnet Ethereum mais que vous voulez utiliser un protocole DeFi sur Arbitrum, vous passez par le bridge natif d’Arbitrum. Si vous voulez utiliser une application native Solana avec de l’USDC qui provient d’Ethereum, vous utilisez un bridge tiers.

Les développeurs qui construisent des applications inter‑chaînes sont les plus gros utilisateurs de bridges. Tout protocole qui veut agréger de la liquidité à travers plusieurs chaînes, ou tout jeu qui veut permettre aux joueurs d’utiliser des actifs sur différents réseaux, a besoin d’une infrastructure de bridging intégrée au produit. C’est pourquoi des projets comme LayerZero, Axelar, Wormhole et Hyperlane se présentent comme des « protocoles de messagerie omnichaîne » plutôt que comme de simples bridges : ce sont des infrastructures pour développeurs, pas seulement pour des utilisateurs finaux qui déplacent des tokens.

Pour les utilisateurs réguliers, les recommandations pratiques sont simples. Utilisez les bridges natifs canoniques pour les déplacements entre L1 et un L2 majeur. Pour les bridges tiers, limitez votre exposition à ce que vous êtes prêt à perdre, vérifiez l’historique des audits et privilégiez les bridges qui fonctionnent sans incident depuis au moins un an avec une TVL significative. L’approche « bridger lentement, bridger petit » n’est pas de la timidité, elle reflète le profil de risque réel de la technologie telle qu’elle existe aujourd’hui.

Réflexions finales

Les bridges inter‑chaînes résolvent un problème réel et incontournable.

Les blockchains sont des systèmes souverains. Sans bridges, la crypto ne serait qu’un ensemble de silos isolés où les actifs et les applications n’interagissent jamais.

L’interopérabilité rendue possible par les bridges sous‑tend la majeure partie de la DeFi, du gaming et de l’écosystème multi‑chaîne que des projets comme TAC s’emploient activement à construire.

Les hacks ne prouvent pas que les bridges sont intrinsèquement défaillants.

Ils montrent que les premiers modèles de bridge ont fait des compromis de sécurité agressifs — petits comités de validateurs, logique de contrats intelligents non auditée, dépendances à des oracles — qui n’étaient pas proportionnés à la valeur qu’ils ont fini par détenir.

Chaque exploit majeur a poussé l’industrie vers de meilleures conceptions : ensembles de validateurs plus larges, vérification formelle, systèmes de preuve basés sur les ZK, et bridges natifs de rollups qui héritent directement de la sécurité de L1.