Comment fonctionnent les ponts inter-chaînes et pourquoi 4 milliards de dollars ont été volés

Introduction

Les blockchains ne communiquent pas entre elles. Ethereum ne peut pas lire l'état de Solana. Arbitrum ne peut pas vérifier une transaction sur Avalanche. Chaque chaîne maintient son propre registre, son propre consensus et ses propres règles de finalité. Cette isolation est une caractéristique de la conception de la sécurité, mais elle crée un problème pratique : les utilisateurs détiennent des actifs sur une chaîne et souhaitent les utiliser sur une autre.

Les ponts existent pour résoudre ce problème. Un pont est un système qui permet à un utilisateur de déposer des actifs sur la chaîne A et de recevoir des actifs correspondants sur la chaîne B. Le concept semble simple. L'implémentation est là où des milliards de dollars ont été perdus.

La difficulté principale est la vérification. Lorsque qu'un utilisateur prétend avoir déposé 100 ETH sur Ethereum et demande 100 ETH sur Arbitrum, quelqu'un ou quelque chose doit vérifier que le dépôt a réellement eu lieu. Le mécanisme choisi pour cette vérification détermine le modèle de sécurité du pont, sa vitesse, son coût et sa surface d'attaque. Comme l'a noté une analyse de Coinbase sur les hacks de ponts, les échecs de sécurité des ponts proviennent systématiquement de l'écart entre les hypothèses de confiance qu'un pont revendique et celles qu'il applique réellement.

Ce guide couvre comment fonctionnent les principales architectures de ponts, pourquoi chacune des plus grandes exploitations a réussi et ce qu'il faut vérifier avant de faire confiance à un pont avec vos fonds.

Lock-and-mint : le mécanisme de pont original

Le design de pont le plus ancien et le plus courant est le lock-and-mint. Le mécanisme fonctionne en trois étapes :

1. Lock. L'utilisateur envoie des jetons à un contrat intelligent sur la chaîne source. Les jetons sont verrouillés (retenus) dans ce contrat, non brûlés ou transférés.
2. Verify. Un ensemble de validateurs, de relais ou un oracle observe le dépôt sur la chaîne source et atteste de sa validité sur la chaîne de destination.
3. Mint. Un contrat intelligent sur la chaîne de destination crée une version synthétique du jeton verrouillé. L'utilisateur reçoit "wrapped ETH" ou "bridged USDC" qui représente une revendication sur l'original verrouillé.

Pour revenir en arrière, le processus s'inverse : l'utilisateur brûle le jeton synthétique sur la chaîne de destination, les validateurs attestent de la brûlure, et les jetons originaux sont déverrouillés sur la chaîne source.

La sécurité du lock-and-mint dépend entièrement de l'étape de vérification. Si un attaquant peut convaincre la chaîne de destination qu'un dépôt a eu lieu alors qu'il ne l'a pas été, il peut créer des jetons non garantis. C'est exactement ce qui s'est passé dans les plus grandes exploitations de ponts.

Le problème arithmétique. Les ponts lock-and-mint doivent maintenir un ratio de 1:1 entre les originaux verrouillés et les synthétiques créés. Si 10 000 ETH sont verrouillés sur Ethereum, exactement 10 000 bridged ETH devraient exister sur la chaîne de destination. Toute divergence signifie que certains jetons bridgés ne sont pas garantis. Lorsque des exploitations créent des synthétiques non garantis, les derniers utilisateurs à échanger trouvent le coffre vide. Cela crée une dynamique de ruée bancaire : une fois que la nouvelle d'une exploitation se propage, chaque détenteur du jeton enveloppé se précipite pour échanger, sachant que seuls les premiers arrivés recevront des actifs réels.

Burn-and-mint : jetons natifs inter-chaînes

Burn-and-mint élimine le problème des jetons enveloppés en détruisant l'original et en en créant un nouveau.

1. Burn. Le jeton est définitivement détruit sur la chaîne source.
2. Verify. L'événement de brûlure est vérifié sur la chaîne de destination.
3. Mint. De nouveaux jetons sont créés nativement sur la chaîne de destination.

Ce modèle ne fonctionne que pour les jetons dont les émetteurs contrôlent la création sur plusieurs chaînes. Le protocole de transfert inter-chaînes (CCTP) de Circle pour l'USDC est la plus grande mise en œuvre. Lorsqu'un utilisateur transfère l'USDC d'Ethereum à Avalanche via le CCTP, l'USDC d'Ethereum est brûlé et l'USDC natif est créé sur Avalanche. Il n'y a pas de jetons enveloppés, pas de fragmentation de liquidité et pas de synthétiques non garantis.

La limitation est que le mécanisme de brûlage et de frappe nécessite que l'émetteur du jeton déploie et exploite une infrastructure sur chaque chaîne prise en charge. Ce n'est pas un mécanisme à usage général. Les jetons ERC-20 arbitraires ne peuvent pas utiliser le brûlage et la frappe à moins que leurs développeurs ne construisent l'infrastructure de frappe inter-chaînes. CCTP prend actuellement en charge plus d'une douzaine de chaînes, mais chaque intégration nécessite l'implication directe de Circle.

Ponts de liquidité : vitesse grâce au capital

Un troisième modèle évite à la fois l'emballage et la combustion en utilisant des pools de liquidité préfinancés sur chaque chaîne.

Le mécanisme :

1. Dépôt. L'utilisateur dépose des jetons dans un pool sur la chaîne source.
2. Retrait. L'utilisateur (ou un relais agissant en son nom) retire des jetons équivalents d'un pool sur la chaîne de destination.
3. Rééquilibrage. Le protocole rééquilibre périodiquement les pools entre les chaînes pour maintenir une liquidité adéquate.

Stargate (construit sur LayerZero) et Across Protocol utilisent des variations de ce modèle. L'avantage est la rapidité : comme les jetons existent déjà sur la chaîne de destination, il n'y a pas de délai de frappe. L'utilisateur reçoit immédiatement des jetons réels et natifs.

Le compromis est l'efficacité du capital. La liquidité doit être pré-positionnée sur chaque chaîne prise en charge, et ce capital ne génère un rendement que lorsque les ponts sont utilisés activement. Pendant les périodes de faible volume, les fournisseurs de liquidité gagnent peu pendant que leur capital reste inactif. Les exigences de capital agrégées sur toutes les chaînes prises en charge peuvent atteindre des centaines de millions de dollars, créant une barrière à l'entrée et un risque de concentration si un seul fournisseur de liquidité domine.

Le piratage du pont Ronin : 624 millions de dollars provenant de clés compromises

Le 23 mars 2022, des attaquants ont siphonné 624 millions de dollars en ETH et USDC du pont Ronin, qui reliait Ethereum à la sidechain Ronin utilisée par le jeu Axie Infinity.

Le pont Ronin utilisait un schéma de validation multisig. Neuf nœuds validateurs vérifiaient les transactions du pont, et cinq d'entre eux pouvaient autoriser un retrait. L'hypothèse de sécurité était que compromettre cinq des neuf validateurs indépendants serait impraticable.

L'hypothèse était fausse. Sky Mavis, la société derrière Axie Infinity, contrôlait quatre des neuf nœuds validateurs. Un cinquième validateur avait accordé à Sky Mavis une autorisation temporaire de signer en son nom pendant une période de volume de transactions élevé et n'avait jamais révoqué cette autorisation.

Les attaquants (plus tard attribués au groupe Lazarus de la Corée du Nord par le FBI) ont compromis les systèmes de Sky Mavis et obtenu les clés privées de tous les cinq validateurs. Avec cinq des neuf signatures, ils ont autorisé deux retraits frauduleux : 173 600 ETH et 25,5 millions d'USDC.

L'exploitation n'a pas été découverte pendant six jours. Elle n'est devenue connue que lorsqu'un utilisateur a essayé de retirer 5 000 ETH et a constaté que le pont n'avait pas suffisamment de fonds.

La leçon. La sécurité multisig n'est aussi forte que l'indépendance de ses signataires. Lorsqu'une seule organisation contrôle la majorité des clés, le multisig devient un point de défaillance unique avec des étapes supplémentaires.

Le piratage de Wormhole : 326 millions de dollars provenant d'un contournement de vérification

Le 2 février 2022, un attaquant a exploité le pont Wormhole pour frapper 120 000 wETH (wrapped ETH) sur Solana sans déposer d'ETH sur Ethereum. L'exploitation valait environ 326 millions de dollars.

Le pont Wormhole s'appuyait sur un ensemble de 19 gardiens pour vérifier les messages inter-chaînes. Les gardiens observaient un dépôt sur Ethereum, produisaient une attestation signée (appelée VAA, Vérification d'Action Approuvée), et le contrat côté Solana vérifiait les signatures avant de frapper.

La vulnérabilité se trouvait dans la vérification des signatures côté Solana. Le contrat Solana de Wormhole utilisait une instruction système obsolète (verify_signatures) qui ne validait pas correctement les comptes qui lui étaient passés. L'attaquant a fabriqué un faux ensemble de gardiens, soumis une VAA falsifiée avec des signatures de cet ensemble fictif, et le contrat l'a acceptée comme valide.

En effet, l'attaquant a dit au contrat Solana "ces gardiens ont approuvé ce mint" et le contrat n'a pas vérifié si les gardiens étaient réels.

Jump Crypto, qui a soutenu Wormhole, a remplacé les 120 000 ETH volés à partir de ses propres réserves. La restauration complète a eu lieu dans les 24 heures, une réponse sans précédent qui a empêché des pertes en cascade à travers les protocoles DeFi de Solana qui détenaient du wETH.

La leçon. Le code de vérification des ponts est une surface d'attaque de grande valeur. Une seule erreur logique dans la façon dont les signatures sont validées peut permettre un minting non autorisé illimité.

Le hack de Nomad : 190 millions de dollars à cause d'une mise à jour défectueuse

Le 1er août 2022, le pont Nomad a été vidé d'environ 190 millions de dollars. Contrairement à Ronin et Wormhole, Nomad n'a pas été attaqué par un groupe sophistiqué. Il a été vidé par des centaines de copieurs individuels après que l'exploitation initiale soit devenue publique.
Vous pourriez également aimer : Le hack du protocole Cetus et l'exploitation de Sui : l'histoire complète derrière l'attaque de 260 millions de dollars.

Nomad utilisait un modèle de vérification optimiste. Les messages inter-chaînes étaient soumis et supposés valides à moins d'être contestés dans une fenêtre de 30 minutes. Une mise à jour de contrat de routine a introduit un bug : le contrat a été initialisé avec une racine de confiance de 0x00, la valeur bytes32 nulle.

Dans la logique de vérification de Nomad, chaque message était vérifié par rapport à la racine de confiance. Parce que 0x00 est la valeur par défaut pour un stockage non initialisé dans Solidity, chaque message passait automatiquement la vérification. Tout utilisateur pouvait soumettre n'importe quel message et le contrat l'accepterait comme prouvé.

Une fois que le premier attaquant a démontré que des messages arbitraires étaient acceptés, d'autres ont copié la transaction, changé l'adresse du destinataire et l'ont rejouée. Le pont a été vidé par une nuée d'attaquants opportunistes, y compris des hackers éthiques qui ont ensuite retourné environ 36 millions de dollars de fonds récupérés.

La leçon. Les bugs d'initialisation dans les contrats de pont peuvent être catastrophiques. Un seul paramètre mal configuré a transformé le modèle de sécurité de Nomad de "vérification optimiste avec preuves de fraude" à "aucune vérification du tout."

Le hack de Harmony Horizon : 100 millions de dollars à cause d'un multisig deux sur cinq

En juin 2022, le pont Harmony Horizon a perdu 100 millions de dollars lorsque des attaquants ont compromis les clés privées de deux des cinq validateurs dans le multisig du pont. Le pont de Harmony nécessitait seulement deux des cinq signataires pour approuver une transaction, un seuil exceptionnellement bas pour un pont détenant 100 millions de dollars.

L'attaque a renforcé la leçon de Ronin : les ponts multisig ne sont sécurisés que par leur ensemble de signataires le plus faible. Lorsque le seuil est bas par rapport au nombre de signataires, une seule compromission de l'infrastructure peut être suffisante. Les chercheurs en sécurité avaient publiquement critiqué le seuil de deux sur cinq de Harmony avant que l'attaque ne se produise.

La leçon. Le choix du seuil est aussi important que le nombre de validateurs. Un multisig cinq sur neuf offre une sécurité significativement différente d'un multisig deux sur cinq, même si les deux utilisent le même mécanisme sous-jacent.

Pertes cumulées et schémas d'attaque

L'ampleur des pertes de ponts est sans précédent dans la sécurité des contrats intelligents. Les exploits de ponts représentent environ 3 milliards de dollars des 17 milliards de dollars de hacks de crypto au cours de la dernière décennie, faisant des ponts la catégorie de contrats intelligents la plus attaquée.

Les schémas d'attaque se regroupent en trois catégories :

Compromission de clé. L'attaquant obtient suffisamment de clés de validateurs ou de signataires pour forger des messages de pont. Ronin et Harmony ont suivi ce schéma. La vulnérabilité n'est pas dans le code mais dans la sécurité opérationnelle de l'infrastructure des signataires.

Contournement de vérification. L'attaquant trouve un bug dans la logique de vérification qui permet à des messages forgés de passer. Wormhole a suivi ce schéma. La vulnérabilité est une erreur au niveau du code dans la fonction la plus critique du contrat de pont.

Erreurs d'initialisation ou de mise à niveau. L'attaquant exploite une mauvaise configuration introduite lors du déploiement ou de la mise à niveau. Nomad a suivi ce schéma. La vulnérabilité est procédurale : l'équipe a commis une erreur lors d'une opération de routine.

Chaque schéma nécessite une défense différente. Le compromis de clé est atténué en augmentant la diversité des signataires et en utilisant des modules de sécurité matériels. Le contournement de vérification est atténué par des audits et une vérification formelle. Les erreurs d'initialisation sont atténuées par des procédures de mise à niveau qui incluent des tests obligatoires sur des réseaux bifurqués.

Un quatrième schéma émergent mérite d'être mentionné : attaques de gouvernance. Un attaquant qui accumule suffisamment de jetons de gouvernance pour contrôler le mécanisme de mise à niveau d'un pont peut modifier le contrat du pont pour siphonner des fonds. Cette attaque est plus lente et plus visible que les autres, mais elle cible des ponts dont la gouvernance est concentrée ou dont le verrouillage temporel sur les mises à niveau est trop court. Les équipes de ponts utilisent de plus en plus des verrouillages temporels de plusieurs jours (48 à 72 heures) sur les mises à niveau de contrat pour donner aux utilisateurs le temps de retirer avant qu'un changement malveillant ne prenne effet.

L'alternative basée sur l'intention aux ponts traditionnels

Une approche plus récente contourne complètement les contrats de pont en utilisant des transferts inter-chaînes basés sur l'intention. Across Protocol et le mode inter-chaînes de UniswapX permettent aux utilisateurs d'exprimer une intention de pont : "J'ai 1 000 USDC sur Ethereum et je veux 1 000 USDC sur Arbitrum." Un solveur (appelé un relayer) envoie immédiatement des jetons de son propre inventaire sur la chaîne de destination, puis réclame plus tard un remboursement.

Ce modèle réduit la surface de confiance. L'utilisateur ne dépose jamais de jetons dans un contrat de pont qui détient des fonds regroupés. Le solveur assume le risque de remboursement, et le contrat de règlement impose que l'utilisateur ait reçu la sortie promise. Il n'y a pas de grand pool d'actifs verrouillés qu'un attaquant pourrait cibler.

Le compromis est la dépendance au solveur : si aucun solveur n'est prêt à remplir l'intention à un prix acceptable, le transfert n'est pas exécuté. Pour les routes à fort trafic (Ethereum vers Arbitrum, Ethereum vers Base), la concurrence entre solveurs est forte. Pour les routes à faible volume, les solveurs peuvent ne pas être actifs.

Ponts de clients légers et vérification à connaissance nulle

Les exploits ci-dessus partagent une faiblesse commune : ils dépendent de validateurs externes ou de multisigs pour attester que quelque chose s'est produit sur une autre chaîne. Si ces attestateurs sont compromis, le pont échoue.

Les ponts de clients légers adoptent une approche différente. Au lieu de faire confiance à un ensemble de validateurs, la chaîne de destination exécute un client léger qui vérifie directement le consensus de la chaîne source.

Un pont de client léger vers Ethereum, par exemple, suivrait l'ensemble des validateurs d'Ethereum et vérifierait les en-têtes de blocs et les preuves d'état sur la chaîne. Lorsque l'utilisateur prétend avoir déposé des jetons sur Ethereum, le contrat de pont vérifie la preuve Merkle par rapport à l'en-tête de bloc Ethereum qu'il a déjà validé.

Cette approche minimise la confiance : le pont fait confiance au consensus de la chaîne source, pas à un comité externe. Mais elle est coûteuse. Vérifier le consensus d'Ethereum sur une autre chaîne nécessite des calculs significatifs, ce qui se traduit par des coûts de gaz élevés.

Les preuves à connaissance nulle offrent une solution au problème de coût. Au lieu de vérifier chaque signature de validateurs sur la chaîne, une preuve ZK peut compresser la vérification en une seule preuve succincte. La chaîne de destination vérifie une preuve au lieu de centaines de signatures.

Des projets comme Succinct Labs, Polymer et Lagrange construisent des ponts vérifiés par ZK. Ceux-ci sont encore en maturation, mais ils représentent le modèle de sécurité le plus solide pour la communication inter-chaînes : faites confiance aux mathématiques, pas au comité. Les premières mises en œuvre montrent que les coûts de vérification diminuent à mesure que les systèmes de preuve ZK deviennent plus efficaces, certains ponts fonctionnant déjà sur le mainnet avec des temps de preuve inférieurs à 30 secondes.

Ce que cela ne couvre pas

Ce guide explique les mécanismes des ponts et les plus grandes exploitations. Il ne couvre pas :

• Les stratégies de pontage spécifiques aux tokens ou quel pont utiliser pour un actif donné
• La comparaison détaillée des agrégateurs de ponts (Li.Fi, Socket, Bungee)
• L'économie de la fourniture de liquidité pour les pools de ponts
• Les protocoles de messagerie inter-chaînes au-delà de leur fonction de pontage (LayerZero, Axelar, Chainlink CCIP en tant que couches de messagerie générales)

Vérifications pratiques avant d'utiliser un pont

Vérifiez le mécanisme de vérification. Les ponts multisig sont le modèle le plus faible. Les ponts vérifiés par client léger et ZK sont les plus forts. Les ponts optimistes se situent entre les deux. Sachez ce à quoi vous faites confiance.

Regardez l'ensemble des validateurs ou des gardiens. Pour les ponts multisig, vérifiez combien de signataires existent, qui les opère et s'ils sont réellement indépendants. Si la majorité des signataires appartiennent à la même organisation ou juridiction géographique, le multisig offre une sécurité limitée.

Examinez l'historique des audits. Les contrats de pont sont des cibles de grande valeur. Recherchez plusieurs audits indépendants de sociétés réputées. Un pont qui n'a pas été audité, ou qui n'a été audité qu'une seule fois, nécessite une prudence supplémentaire. Faites attention à la portée des audits : un audit du contrat de token ne couvre pas la logique de vérification.

Considérez la valeur totale verrouillée par rapport au budget de sécurité. Un pont détenant 500 millions de dollars avec un multisig cinq sur neuf présente un profil de risque très différent d'un pont détenant 5 millions de dollars. Les attaquants ciblent les ponts où le paiement potentiel justifie l'effort. L'attaquant rationnel calcule si le coût de la compromission d'assez de clés est inférieur à la valeur qui peut être extraite.

Testez d'abord avec de petites sommes. Avant de transférer une valeur significative, envoyez une petite transaction de test. Vérifiez que l'adresse de réception, le token et le montant sont corrects. Les transactions de pont sont généralement irréversibles.

Préférez les ponts natifs pour les rollups. Pour les rollups Ethereum L2 (Arbitrum, Optimism, Base), le pont canonique hérite de la sécurité directement du consensus d'Ethereum. Les ponts tiers peuvent être plus rapides mais introduisent des hypothèses de confiance supplémentaires. Utilisez des ponts canoniques pour les grands transferts où la sécurité compte plus que la vitesse. Lisez la suite : Qu'est-ce que les ponts inter-chaînes ? Pourquoi continuent-ils à être piratés

Qu'est-ce qu'un pont inter-chaînes ? {#faq-question-4160687517}

Un pont inter-chaînes est un système qui transfère des actifs ou des données entre deux blockchains qui ne peuvent pas communiquer nativement. Le pont verrouille, brûle ou regroupe des tokens sur une chaîne et émet des tokens correspondants sur une autre, en utilisant un mécanisme de vérification pour garantir que le transfert est légitime.

Pourquoi les ponts ont-ils été piratés si souvent ? {#faq-question-1765570890}

Les ponts sont des cibles de grande valeur car ils détiennent de grands pools d'actifs verrouillés. Ils introduisent également des hypothèses de confiance complexes à la frontière entre deux modèles de sécurité différents. Une vulnérabilité dans le mécanisme de vérification (clés compromises, vérifications de signature défectueuses, bugs d'initialisation) peut permettre à un attaquant de vider l'ensemble du pool en une seule transaction.

Quelle est la différence entre lock-and-mint et burn-and-mint ? {#faq-question-0293370535}

Lock-and-mint conserve le token original sur la chaîne source et crée une version synthétique (emballée) sur la chaîne de destination. Burn-and-mint détruit l'original et crée un nouveau token natif sur la destination. Burn-and-mint produit des tokens natifs plutôt que des synthétiques mais nécessite que l'émetteur du token contrôle la création sur les deux chaînes.

Les tokens emballés sont-ils sûrs ? {#faq-question-3820965888}

Les tokens emballés ne sont aussi sûrs que le pont qui les a émis. Si le pont est exploité et que les actifs de soutien sont drainés, les tokens emballés deviennent non soutenus et perdent leur parité. Les utilisateurs détenant des tokens emballés supportent le risque de sécurité du pont, pas seulement le risque de l'actif sous-jacent.

Combien de temps prend le pontage ? {#faq-question-8084085272}

Cela varie selon le mécanisme. Les ponts de pools de liquidités et les ponts basés sur l'intention (Across) peuvent se compléter en quelques secondes. Les ponts de verrouillage et de frappe avec vérification multisig prennent généralement de 10 à 30 minutes. Les ponts optimistes avec fenêtres de preuve de fraude peuvent prendre jusqu'à 7 jours pour les retraits des rollups optimistes vers Ethereum, bien que des ponts rapides puissent avancer la liquidité pour réduire ce délai.

Qu'est-ce qu'un pont de client léger ? {#faq-question-5264913434}

Un pont de client léger vérifie le consensus de la chaîne source directement sur la chaîne de destination, plutôt que de s'appuyer sur un ensemble de validateurs externes. Il vérifie les en-têtes de blocs et les preuves d'état, faisant confiance à la sécurité de la chaîne source elle-même. Cela minimise davantage la confiance par rapport à la vérification multisig ou optimiste, mais coûte plus de gaz à faire fonctionner.

Puis-je perdre de l'argent en utilisant un pont ? {#faq-question-7660039976}

Oui. Si le pont est exploité après que vous ayez déposé mais avant que vous ayez retiré, vos jetons verrouillés peuvent être volés. Si vous détenez des jetons enveloppés et que le pont est piraté, vos jetons enveloppés peuvent devenir sans valeur. De plus, des adresses de destination incorrectes ou des types de jetons non pris en charge peuvent entraîner une perte permanente.

Quel pont devrais-je utiliser ? {#faq-question-1819675312}

Aucun pont unique n'est le meilleur pour toutes les situations. Pour l'USDC, le CCTP de Circle est l'option la plus sécurisée car il utilise la méthode de brûlage et de frappe sans jetons enveloppés. Pour les transferts généraux d'ERC-20, comparez les mécanismes de vérification des ponts disponibles. Préférez les ponts avec vérification de client léger ou ZK, plusieurs audits indépendants, et un historique d'opérations sécurisées. Les agrégateurs de ponts comme Li.Fi peuvent aider à comparer les routes.

*Avertissement : Cet article est à des fins d'information uniquement et ne constitue pas un conseil financier, d'investissement ou juridique. La crypto-monnaie implique des risques importants, et vous devriez effectuer vos propres recherches avant de prendre des décisions. Les informations sont exactes à partir d'août 2026.*