Messagerie cross-chain

Un actif sur la chaîne A reste sur la chaîne A, et la construction habituelle l'y verrouille ou le brûle et frappe une représentation sur la chaîne B. Le détenteur sur B possède une créance sur celui qui détient l'original, et cette créance vaut exactement ce que vaut le dispositif de garde et de vérification du bridge. Quand la construction est burn and mint, l'émetteur est la même partie des deux côtés, une position différente et en général meilleure pour le détenteur.

En dessous, l'objet transporté est un message: une affirmation qu'un événement a eu lieu sur la chaîne source, que reçoit un contrat de la chaîne de destination pour agir en conséquence. Le mouvement de jetons est une application de cette couche de messages, et un protocole capable de porter des messages arbitraires peut aussi porter une instruction, un prix ou une mise à jour d'état. Une faille dans cette couche de messages peut donc dépasser le vol sur un seul bridge.

Un ensemble de validateurs externes est le plus courant: un groupe de nœuds observe la chaîne source et signe une attestation qu'un événement a eu lieu, le contrat de destination acceptant un seuil de signatures. L'approche par validateurs externes échoue quand assez de clés de signature sont compromises ou que les signataires s'entendent, et toute la sécurité se réduit à la gestion des clés de cet ensemble.

Un light client vérifie le consensus de la chaîne source directement dans un contrat de la chaîne de destination, ce qui supprime la partie de confiance externe et la remplace par la sécurité propre de la chaîne source. L'approche light client échoue sur le coût et les mises à jour, car la vérification du consensus coûte cher onchain et un hard fork de la chaîne source peut casser le client. La vérification optimiste accepte un message après une fenêtre de contestation pendant laquelle chacun peut soumettre une preuve de fraude, ce qui échange de la latence contre une hypothèse de confiance plus faible, et échoue quand personne ne surveille pendant la fenêtre ou quand la fenêtre est trop courte pour qu'une contestation aboutisse. Chaque modèle répond autrement à la même question, et aucun ne supprime la confiance: ils la déplacent.

CCIP achemine les messages par les réseaux d'oracles décentralisés de Chainlink et ajoute un Risk Management Network, couche séparée au code différent qui surveille chaque transfert, un dispositif de défense en profondeur avec un second contrôle indépendant. Par défaut, CCIP attend davantage de confirmations sur la chaîne source et règle donc plus lentement. Chainlink développe d'autres produits en plus de CCIP pour les applications blockchain.

LayerZero sépare l'endpoint, la vérification et l'exécution, et laisse chaque application composer sa sécurité à partir de Decentralized Verifier Networks, plaçant la décision de configuration chez le développeur de l'application. Wormhole utilise un ensemble fixe de 19 nœuds Guardian exploités par des institutions avec un seuil de signature de 13 sur 19, plus simple à analyser et non configurable. Chez Axelar, son propre ensemble de validateurs atteint le consensus sur les messages cross-chain et les signe via General Message Passing, en ré-attestant l'état d'autres chaînes. Hyperlane laisse chaque application choisir une vérification multisig, optimiste ou à divulgation nulle de connaissance via des Interchain Security Modules modulaires. Deux autres systèmes sont le CCTP de Circle, propre à l'USDC et fondé sur le burn and mint par l'émetteur, et IBC dans l'écosystème Cosmos, qui vérifie avec des light clients.

Ronin a perdu environ 625 millions de dollars américains par des clés de validateurs compromises, l'ensemble de validateurs externes a échoué sur la gestion des clés. Wormhole a perdu environ 320 millions par un contournement de la vérification des signatures, un bug du contrôle côté destination. Nomad a perdu environ 190 millions après qu'une initialisation erronée de la racine de Merkle a permis à n'importe qui de rejouer un message. Le bridge Horizon de Harmony a perdu environ 100 millions par un multisig deux sur cinq compromis, dont le seuil était trop bas pour résister à deux compromissions.

Le schéma est que le vol a eu lieu à la frontière de vérification et non dans les chaînes sous-jacentes, qui ont toutes deux continué de fonctionner correctement. Les exploits de bridges ont représenté environ 2,8 milliards de dollars américains de pertes en 2025, soit environ 40 % de tous les incidents de sécurité Web3. En avril 2026, un message cross-chain falsifié a vidé environ 292 millions en rsETH au détriment de KelpDAO, et la cause a été attribuée à une configuration à vérificateur unique et non à un bug du protocole, la responsabilité étant disputée entre l'application et le protocole. Un modèle de sécurité configurable laisse le choix à l'application, y compris celui d'accepter la configuration par défaut.

Un instrument réglementé exige de préciser quand son transfert devient juridiquement définitif et irréversible. Un transfert cross-chain comporte au moins deux événements de finalité, un sur chaque chaîne, et une fenêtre entre les deux pendant laquelle la chaîne source pourrait encore se réorganiser alors que la destination a déjà agi. Un protocole qui agit sur un bloc source non finalisé peut être amené à livrer un actif contre une transaction qui n'existe ensuite plus.

La politique de confirmation affecte donc la finalité juridique ainsi que les performances. Un titre tokenisé qui change de chaîne a besoin d'un moment établi où le transfert est définitif, du registre qui détient l'inscription faisant foi et d'un traitement défini pour une réorganisation qui franchit ce moment. Pour les titres tokenisés, le transfert doit correspondre au registre juridique. Sur les marchés de capitaux onchain, le règlement contre paiement constitue une autre exigence. Ces exigences contribuent à expliquer pourquoi la plupart des tokenisations réglementées restent actuellement sur un seul registre.

Un message cross-chain et un flux de prix sont le même problème avec une charge utile différente. Dans les deux cas, un contrat doit agir sur une information qu'il ne peut pas vérifier lui-même, et un ensemble de parties est réputé la rapporter fidèlement. Les modes de défaillance se ressemblent: un ensemble de rapporteurs compromis, une valeur périmée traitée comme actuelle, une règle d'agrégation qu'un manipulateur peut exploiter.

C'est aussi pourquoi la même infrastructure sert aux deux, et pourquoi une institution qui évalue l'un devrait poser les questions de l'autre. Les mécanismes de vérification des réseaux d'oracles s'appliquent aussi à la messagerie cross-chain. Les attaques et défenses liées à la sécurité des réseaux d'oracles concernent des risques similaires pour les données transmises.

Les protocoles diffèrent par leurs hypothèses de confiance et leurs modes de défaillance, et leur sécurité dépend donc des exigences de chaque application. Un ensemble de validateurs fixe et nommé est facile à évaluer et impossible à renforcer application par application. Un modèle configurable peut être rendu plus solide que n'importe quel modèle fixe, mais aussi laissé sur une valeur par défaut plus faible. Un light client a les meilleures propriétés de confiance et le coût le plus élevé. La question utile pour une institution est de savoir quelle hypothèse elle peut exposer par écrit à un comité des risques puis surveiller.

Un jeton wrappé est une créance émise sur la chaîne de destination, et sa valeur repose sur la garde de l'original par le bridge et sur la justesse de la logique de frappe. Si le bridge est vidé, le jeton wrappé reste sur la chaîne sans rien derrière lui, ce que des détenteurs ont découvert lors de chacune des grandes failles. Quand l'émetteur de l'original brûle et frappe lui-même, comme avec le CCTP de Circle pour l'USDC, la contrepartie du détenteur est l'émetteur et non un bridge, un risque sensiblement différent.