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é. Cet isolement est une caractéristique de la conception de sécurité, mais il crée un problème pratique : les utilisateurs détiennent des actifs sur une chaîne et veulent 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. C'est dans la mise en œuvre que des milliards de dollars ont été perdus.

La difficulté centrale est la vérification. Lorsqu'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 piratages de ponts, les défaillances de sécurité des ponts proviennent systématiquement de l'écart entre les hypothèses de confiance qu'un pont prétend avoir et celles qu'il applique réellement.

Ce guide couvre le fonctionnement des principales architectures de ponts, pourquoi chacun des plus grands exploits a réussi, et ce qu'il faut vérifier avant de confier vos fonds à un pont.

Verrouiller et frapper : le mécanisme de pont original

La conception de pont la plus ancienne et la plus courante est le verrouillage et la frappe. Le mécanisme fonctionne en trois étapes :

1. Verrouillage. L'utilisateur envoie des jetons à un contrat intelligent sur la chaîne source. Les jetons sont verrouillés (détenus) dans ce contrat, pas brûlés ni transférés.
2. Vérification. Un ensemble de validateurs, de relayeurs 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. Frappe. Un contrat intelligent sur la chaîne de destination frappe une version synthétique du jeton verrouillé. L'utilisateur reçoit de l'« ETH enveloppé » ou de l'« USDC ponté » qui représente une créance 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 verrouillage et de la frappe 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 que ce n'est pas le cas, il peut frapper des jetons non adossés. C'est exactement ce qui s'est passé dans les plus grands exploits de ponts.

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

Brûler et frapper : jetons natifs inter-chaînes

Le brûlage et la frappe éliminent le problème du jeton enveloppé en détruisant l'original et en créant un nouveau.

1. Brûlage. Le jeton est détruit de manière permanente sur la chaîne source.
2. Vérification. L'événement de brûlage est vérifié sur la chaîne de destination.
3. Frappe. De nouveaux jetons sont frappés nativement sur la chaîne de destination.

Ce modèle ne fonctionne que pour les jetons dont les émetteurs contrôlent la frappe 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 de l'USDC d'Ethereum à Avalanche via CCTP, l'USDC Ethereum est brûlé et de l'USDC natif est frappé sur Avalanche. Il n'y a pas de jetons enveloppés, pas de fragmentation de liquidité et pas de synthétiques non adossés.

La limitation est que le brûlage et la frappe nécessitent 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 à pools de liquidité : la vitesse grâce au capital

Un troisième modèle évite à la fois l'enveloppement et le brûlage 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 variantes 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 natifs réels.

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 activement utilisés. Pendant les périodes de faible volume, les fournisseurs de liquidité gagnent peu pendant que leur capital reste inactif. Les besoins totaux en capital 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 drainé 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 de 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 irréaliste.

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 permission temporaire de signer en son nom pendant une période de volume de transactions élevé et n'avait jamais révoqué la permission.

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

L'exploit n'a pas été découvert pendant six jours. Il n'a été révélé que lorsqu'un utilisateur a tenté de retirer 5 000 ETH et a constaté que le pont n'avait pas assez 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 une majorité de clés, le multisig est 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 (ETH enveloppé) sur Solana sans déposer d'ETH sur Ethereum. L'exploit valait environ 326 millions de dollars.

Le pont de 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, Verified Action Approval), et le contrat côté Solana vérifiait les signatures avant de frapper.

La vulnérabilité résidait 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 un VAA falsifié avec des signatures de cet ensemble factice, et le contrat l'a accepté comme valide.

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

Jump Crypto, qui soutenait Wormhole, a remplacé les 120 000 ETH volés à partir de ses propres réserves. La restauration complète a eu lieu en 24 heures, une réponse sans précédent qui a évité des pertes en cascade dans les protocoles DeFi de Solana détenant 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 validation des signatures peut permettre une frappe non autorisée illimitée.

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

Le 1er août 2022, le pont Nomad a été drainé d'environ 190 millions de dollars. Contrairement à Ronin et Wormhole, Nomad n'a pas été attaqué par un groupe sophistiqué. Il a été drainé par des centaines d'imitateurs individuels après que l'exploit initial est devenu public.

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

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 le stockage non initialisé dans Solidity, chaque message passait automatiquement la vérification. N'importe quel utilisateur pouvait soumettre n'importe quel message et le contrat l'acceptait 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é drainé par une nuée d'attaquants opportunistes, y compris des hackers white-hat qui ont ensuite rendu 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 piratage 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 les attaquants ont compromis les clés privées de deux des cinq validateurs du multisig du pont. Le pont de Harmony n'exigeait que deux des cinq signataires pour approuver une transaction, un seuil inhabituellement bas pour un pont détenant 100 millions de dollars.

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

La leçon. Le choix du seuil compte autant 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 sur les 17 milliards de dollars de piratages cryptographiques 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és. 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é ne se trouve pas dans le code mais dans la sécurité opérationnelle de l'infrastructure de signature.

Contournement de la 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. La compromission de clés est atténuée en augmentant la diversité des signataires et en utilisant des modules de sécurité matériels. Le contournement de la 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 forkés.

Un quatrième schéma émergent mérite d'être mentionné : les 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 drainer des fonds. Cette attaque est plus lente et plus visible que les autres, mais elle cible les ponts dont la gouvernance est concentrée ou dont le délai de verrouillage des mises à niveau est trop court. Les équipes de ponts utilisent de plus en plus des délais de verrouillage de plusieurs jours (48 à 72 heures) sur les mises à niveau de contrats pour donner aux utilisateurs le temps de retirer leurs fonds avant qu'un changement malveillant ne prenne effet.

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

Une approche plus récente contourne entièrement les contrats de pont en utilisant des transferts inter-chaînes basés sur l'intention. Le mode inter-chaîne d'Across Protocol et d'UniswapX permet aux utilisateurs d'exprimer une intention de pontage : « J'ai 1 000 USDC sur Ethereum et je veux 1 000 USDC sur Arbitrum. » Un solveur (appelé relayer) envoie immédiatement des jetons depuis son propre inventaire sur la chaîne de destination, puis réclame ensuite 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 mutualisés. Le solveur assume le risque de remboursement, et le contrat de règlement garantit que l'utilisateur a 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 à exécuter l'intention à un prix acceptable, le transfert ne s'exécute pas. 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 à client léger et vérification à connaissance nulle

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

Les ponts à client léger 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 à 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. Lorsqu'un utilisateur prétend avoir déposé des jetons sur Ethereum, le contrat de pont vérifie la preuve de 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, et non à un comité externe. Mais elle est coûteuse. Vérifier le consensus d'Ethereum sur une autre chaîne nécessite une puissance de calcul importante, ce qui se traduit par des frais de gaz élevés.

Les preuves à connaissance nulle offrent une solution au problème des coûts. Au lieu de vérifier chaque signature de validateur 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 fort pour la communication inter-chaînes : faire confiance aux mathématiques, pas au comité. Les premières implémentations montrent une baisse des coûts de vérification à 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 grands exploits. Il ne couvre pas :

• Les stratégies de pontage spécifiques aux jetons 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és 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 à client léger et vérifiés par ZK sont les plus forts. Les ponts optimistes se situent entre les deux. Sachez à quoi vous faites confiance.

Examinez 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, la 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 provenant de cabinets réputés. Un pont qui n'a pas été audité, ou qui n'a été audité qu'une seule fois, mérite une prudence supplémentaire. Faites attention à la portée des audits : un audit du contrat de jeton 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 une multisig de 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 gain potentiel justifie l'effort. L'attaquant rationnel calcule si le coût de compromission de suffisamment de clés est inférieur à la valeur qui peut être extraite.

Testez d'abord avec de petits montants. Avant de transférer une valeur importante, envoyez une petite transaction de test. Vérifiez que l'adresse de réception, le jeton 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 L2 d'Ethereum (Arbitrum, Optimism, Base), le pont canonique hérite directement de la sécurité du consensus d'Ethereum. Les ponts tiers peuvent être plus rapides mais introduisent des hypothèses de confiance supplémentaires. Utilisez les ponts canoniques pour les transferts importants où la sécurité prime sur la vitesse.