Pourquoi la messagerie cross-chain est plus difficile qu’il n’y paraît
Déplacer un token de Ethereum vers Solana, ou d’une app-chain Cosmos vers un rollup, ressemble en surface à un simple transfert. En coulisses, la chaîne de destination doit croire un système étranger lorsqu’il affirme qu’un dépôt, une destruction ou un vote a réellement eu lieu. Cette affirmation est un message, et la manière dont il est vérifié constitue tout le modèle de sécurité du bridge.
L’approche naïve consiste à confier la tâche à un wallet multisig. Un groupe de validateurs connus signe le message, et la chaîne de destination l’accepte dès qu’un seuil de signatures apparaît. C’est rapide, flexible, et c’est aussi le modèle de conception derrière la plupart des plus grands exploits de bridges de l’histoire de la crypto. Lorsqu’un multisig est la racine de confiance, le bridge n’est sûr qu’à hauteur du plus petit nombre de clés compromises qu’il peut tolérer.
L’approche plus profonde consiste à faire vérifier directement la chaîne source par la chaîne de destination, comme une personne vérifie un passeport en lisant le tampon du pays émetteur plutôt qu’en faisant confiance à la parole d’un tiers. C’est ce que fait un light client. C’est aussi coûteux, lent à déployer, et limité aux chaînes capables d’exécuter la logique de vérification les unes des autres. Les trois piles de cet article se situent sur un spectre entre ces deux extrêmes, et les différences comptent davantage que ne le suggèrent les pages marketing.
Les risques que tout utilisateur cross-chain doit d’abord accepter
Avant de comparer les fonctionnalités, le cadrage honnête est que chaque message cross-chain comporte un risque que les chaînes sous-jacentes n’ont pas. Un token transféré par bridge depuis Ethereum vers un autre réseau n’est, au sens strict, plus le token Ethereum. C’est une reconnaissance de dette enveloppée ou mintée que la chaîne de destination ne peut honorer que si le modèle de sécurité du bridge tient. Les bridges sont la plus grande source de pertes crypto par catégorie depuis trois années consécutives.
Le bilan historique donne à réfléchir. Le bridge Ronin a perdu environ 625 millions de dollars en 2022 après la compromission de cinq clés de validateurs sur neuf. Le bridge Wormhole a perdu environ 320 millions de dollars en 2022 lorsqu’un attaquant a contourné la vérification des signatures sur Solana. Le bridge Harmony Horizon a perdu environ 100 millions de dollars en 2022. Le bridge Nomad a perdu près de 190 millions de dollars début 2023. Au total, les bridges cross-chain ont représenté plus de deux milliards de dollars de pertes documentées, et ce chiffre sous-estime la réalité, car certains incidents sont absorbés discrètement.
Pour les utilisateurs, les risques pratiques se répartissent en quelques catégories. Le risque de smart contract sur la chaîne de destination peut permettre à un attaquant de minter des actifs non garantis. La compromission de validateurs côté source peut permettre à un voleur d’approuver un faux dépôt. Les problèmes de rejeu ou de finalité peuvent permettre à un message d’être accepté avant que la chaîne source ne soit réellement finalisée. La capture de la gouvernance peut modifier les règles après coup. Rien de tout cela n’est théorique. Tous ces scénarios se sont déjà produits, et c’est pourquoi une comparaison des modèles de confiance est plus utile qu’une liste de fonctionnalités.
Cosmos IBC et le modèle de confiance des clients légers
IBC, le protocole Inter-Blockchain Communication, est ce qui se rapproche le plus, dans le secteur, d’un standard cross-chain cryptographiquement natif. Il a été spécifié par l’Interchain Foundation et intégré au Cosmos SDK, et il fonctionne en production depuis 2021 pour transporter de vrais actifs et messages entre des app-chains indépendantes. ATOM, le token natif du Cosmos Hub, joue un rôle de coordination dans cet écosystème, même si de nombreuses chaînes compatibles IBC ont peu ou pas d’exposition directe à ATOM.
L’idée centrale d’IBC est que la chaîne de destination exécute un client léger de la chaîne source, et que la chaîne source exécute un client léger de la chaîne de destination. Un client léger est un petit morceau de code qui vérifie les en-têtes de blocs d’une autre chaîne en utilisant uniquement les règles de consensus de cette chaîne. Quand la chaîne A veut envoyer un paquet à la chaîne B, elle inscrit ce paquet dans son propre arbre de Merkle, puis la chaîne B vérifie cet engagement en contrôlant l’en-tête envoyé par la chaîne A, signé par l’ensemble de validateurs de A. Il n’y a pas de multisig externe, pas d’oracle, ni de relais tiers ayant le pouvoir de falsifier un message. La sécurité du pont est la sécurité des deux chaînes concernées.
Ce modèle a des conséquences réelles. Une app-chain Cosmos et une autre app-chain Cosmos qui utilisent toutes deux un consensus de type Tendermint peuvent se connecter avec quelques lignes de configuration et hériter de garanties très solides. Se connecter à une chaîne dotée d’un algorithme de consensus différent, comme Ethereum, nécessite d’écrire un client léger personnalisé en Solidity ainsi qu’un relais capable de payer le gas des deux côtés. Ce travail a été réalisé pour Ethereum, et les connexions qui en résultent, de type ICS-27 Neutron, sont utilisables, mais l’effort est plus lourd que pour les autres stacks présentées dans cet article.
La portée limitée est le compromis. IBC ne sécurise pas magiquement des rollups et des alt-L1 arbitraires. Chaque connexion est conçue sur mesure, et chaque chaîne connectée devient une partie de la surface de confiance. C’est un atout du point de vue de la sécurité, car cela maintient le modèle de confiance local, et une limite du point de vue de l’écosystème, car cela ne se met pas à l’échelle aussi facilement qu’un bus de messages permissionné.
Sécurité partagée et angle des app-chains
La thèse des app-chains derrière Cosmos est que les applications sérieuses méritent leur propre blockchain, avec leur propre ensemble de validateurs et leur propre token de frais. IBC est le tissu connectif qui rend cette thèse praticable, car il permet à de nombreuses chaînes souveraines d’interopérer sans renoncer à leur souveraineté. La sécurité répliquée, puis son successeur, l’interchain security, permettent à de plus petites app-chains de louer l’ensemble de validateurs du Cosmos Hub, ce qui améliore leur sécurité tout en conservant IBC comme couche cross-chain. Il en résulte un modèle où les hypothèses de confiance d’un message cross-chain sont explicites, locales et auditables, mais au prix d’une fragmentation entre de nombreuses chaînes présentant des niveaux variables de qualité des validateurs.
LayerZero et la stack DVN configurable
LayerZero suit une voie de conception différente. Au lieu d’exécuter des clients légers complets sur chaque chaîne, il exécute un Ultra Light Node, un endpoint minimaliste qui stocke les en-têtes de blocs seulement lorsque c’est nécessaire et s’appuie autrement sur un relais off-chain ainsi que sur une stack distincte de Decentralized Verifier Networks, appelés DVN, pour attester un message. La chaîne de destination accepte un message lorsque les DVN configurés conviennent que la transaction de la chaîne source est valide.
C’est une architecture à confiance minimisée, dans le sens où aucune partie unique ne contrôle la livraison des messages, mais elle est aussi configurable. L’application qui déploie un endpoint LayerZero peut choisir quels DVN vérifient ses messages. La configuration par défaut utilise un ensemble spécifique, mais un développeur peut le remplacer par une autre stack DVN afin de modifier le profil de sécurité d’un pont particulier. Certaines équipes ont lancé des systèmes avec un seul DVN, ce qui se rapproche en pratique d’un multisig, tandis que d’autres utilisent plusieurs DVN provenant d’opérateurs indépendants.
Les critiques de LayerZero ont soutenu que cette flexibilité constitue elle-même un risque. Si une application est déployée avec des DVN faibles pour réduire les coûts ou la latence, la sécurité de ce pont est faible par construction. L’équipe de LayerZero a répondu en élargissant la place de marché des DVN et en poussant vers des configurations par défaut qui utilisent des vérificateurs indépendants, et la refonte V2 du protocole insiste davantage sur une composition explicite des DVN. Malgré cela, la responsabilité du choix de la stack de vérification revient en dernier ressort à l’équipe de l’application, ce qui signifie qu’un utilisateur qui effectue une transaction via un pont LayerZero doit faire confiance à la fois au protocole et aux choix effectués par cette équipe.
La portée de LayerZero est vaste. Il est actif sur la plupart des grandes chaînes EVM, sur Solana et sur plusieurs réseaux non-EVM, et il a été utilisé par de grandes applications, notamment Stargate, un routeur de liquidité cross-chain, ainsi que par plusieurs émetteurs de stablecoins. Cette portée est un véritable avantage, mais elle s’accompagne d’un modèle mental plus complexe : la sécurité d’un pont spécifique dépend des DVN sélectionnés, du contrat applicatif qui impose la vérification et de la version de l’endpoint on-chain utilisée.
Comment les DVN changent le calcul de la confiance
La façon la plus simple de penser une stack DVN est de la voir comme un schéma de signature interchangeable. Chaque DVN peut être un système de zk-proof, un vérificateur fondé sur le restaking, un service d’attestation centralisé ou un multisig opéré par un acteur connu. Empiler des DVN indépendants avec des racines de confiance différentes est une défense raisonnable, car un attaquant devrait compromettre plus d’un vérificateur à la fois. Empiler des DVN corrélés qui partagent une infrastructure ou une gouvernance revient davantage à avoir un point de défaillance unique déguisé en plusieurs. Les équipes d’application qui lancent leurs produits avec des DVN bon marché et corrélés obtiennent le marketing de la décentralisation et le profil de risque d’un multisig.
Wormhole et le multisig des guardians
Wormhole, initialement développé par Certus One et désormais supervisé par la Wormhole Foundation, est la troisième grande stack. Il connecte Ethereum, Solana, BNB Chain, Aptos, Sui et une longue liste d’autres réseaux, et il a historiquement été l’un des modèles de pont avec le plus haut TVL du secteur. Sa conception est aussi la plus simple à décrire, et la plus controversée du point de vue de la sécurité.
Les messages sur Wormhole sont attestés par un ensemble permissionné de 19 guardians, chacun exploitant un nœud qui observe la chaîne source et signe les événements observés. Lorsque 13 des 19 guardians signent le même message, celui-ci est accepté sur la chaîne de destination. Les guardians sont des opérateurs bien connus issus de l’ensemble du secteur, et l’ensemble est contrôlé par la gouvernance, ce qui signifie que de nouveaux guardians peuvent être ajoutés ou retirés par la Wormhole DAO.
Le modèle de confiance est un multisig à seuil élevé. Si 7 des 19 guardians s’entendent, ou si les clés de 7 guardians sont compromises, le pont est entièrement compromis. C’est un point de centralisation important, et l’exploit de 2022 en a rendu les conséquences concrètes. Un attaquant a trouvé un moyen de falsifier une vérification de signature du côté Solana de Wormhole, ce qui lui a permis de minter 120 000 ETH wrapped qui n’étaient pas adossés à des dépôts sur Ethereum. La perte s’élevait à environ 320 millions de dollars à l’époque, et elle a été couverte par Jump Crypto, qui était opérateur guardian et est intervenu pour recapitaliser le pont.
Depuis, Wormhole a ajouté un pare-feu guardian, renforcé sa logique de vérification on-chain et encouragé des revues de sécurité supplémentaires. Rien de tout cela ne change l’hypothèse de confiance sous-jacente, selon laquelle un multisig permissionné avec un seuil de 13 sur 19 constitue la racine de la sécurité cross-chain. Pour les utilisateurs, la question pratique est de savoir si l’ensemble des guardians est suffisamment décentralisé, si les incitations des guardians sont alignées avec un fonctionnement honnête, et si l’application sur la chaîne de destination applique correctement le chemin de vérification.
Pourquoi le classement par TVL est trompeur
Le TVL de Wormhole a souvent été utilisé comme indicateur indirect de sa sécurité, selon la logique implicite voulant que plus il y a d’argent faisant confiance à un pont, plus ce pont est digne de confiance. L’historique suggère l’inverse. Les ponts avec le TVL le plus élevé sont les cibles les plus attrayantes, et la position de Wormhole près du sommet de cette liste explique pourquoi ses exploits ont été si importants. Un utilisateur qui regarde le total des dépôts ne voit pas le modèle de sécurité, seulement la récompense disponible pour un attaquant.
Comment IBC, LayerZero et Wormhole se comparent sur les dimensions qui comptent
Le modèle de confiance est la dimension principale, et sur cet axe IBC est le plus sûr par conception, car chaque chaîne vérifie l’autre par le consensus. LayerZero arrive en deuxième position, car la stack DVN peut être configurée pour être cryptographiquement robuste, mais seulement si l’application choisit des vérificateurs qui le sont réellement. Wormhole arrive en troisième position, car la racine de confiance est un multisig de guardians permissionné qui a déjà été compromis une fois et qui ne s’améliore qu’au rythme de la décentralisation et de la rotation de l’ensemble des guardians.
La portée et la connectivité favorisent Wormhole et LayerZero. Tous deux sont disponibles dès le départ sur des dizaines de chaînes, et un développeur peut déployer une application cross-chain sur l’un ou l’autre sans écrire de client léger personnalisé. IBC, à l’inverse, nécessite une configuration pour chaque connexion, et une connexion à une chaîne dotée d’un consensus peu familier constitue un projet d’ingénierie sérieux. Pour une application qui doit toucher rapidement tous les grands réseaux, c’est un coût réel.
L’expérience développeur est aujourd’hui à peu près équivalente entre LayerZero et Wormhole, chacun offrant un endpoint relativement simple et des parcours de déploiement bien balisés. L’outillage IBC s’est beaucoup amélioré, avec des bibliothèques comme ibc-go et les relais Hermes, mais l’empreinte on-chain côté Ethereum est plus lourde et l’outillage EVM est moins mature que les alternatives.
La latence et le coût sont difficiles à généraliser. Les connexions IBC entre chaînes Tendermint sont rapides et peu coûteuses parce que le relais ne fait que soumettre des en-têtes existants. La latence de LayerZero dépend de la configuration des DVN et de la fréquence à laquelle l’Ultra Light Node doit rafraîchir l’état. La latence de Wormhole dépend de l’agrégation des signatures des guardians. Pour des transferts de taille retail, les trois sont compétitifs ; pour l’arbitrage cross-chain à haute fréquence, les différences de finalité et de gas peuvent compter.
La gouvernance et les chemins de mise à niveau sont une surface de risque sous-estimée. Les mises à niveau d’IBC se font au niveau du protocole et nécessitent une coordination entre les chaînes connectées. LayerZero a fait l’objet d’itérations actives, avec une V2 qui remodèle le modèle de confiance vers une composition plus explicite des DVN. La gouvernance de Wormhole repose sur la Wormhole Foundation et l’ensemble des guardians, l’incident de 2022 ayant déclenché une feuille de route de sécurité plus visible. Aucun de ces chemins de gouvernance n’est totalement trustless, et un utilisateur doit savoir qui peut changer les règles.
Implications pratiques pour les builders et les utilisateurs DeFi
Pour les builders, la conclusion honnête est que le choix d’une pile cross-chain revient à choisir une racine de confiance, et que cette décision doit être prise avant d’écrire la moindre ligne de logique métier. Une application qui a besoin des garanties les plus fortes possible et accepte d’évoluer dans un environnement de type Cosmos aura du mal à trouver mieux que IBC. Une application qui a besoin d’une large portée et qui est prête à gérer soigneusement la composition des DVN trouvera LayerZero flexible. Une application qui privilégie la rapidité de mise sur le marché et qui est à l’aise avec un ensemble de gardiens permissionné trouvera Wormhole rapide à déployer, en comprenant que le modèle de confiance est celui que la page marketing a tendance à passer sous silence.
Pour les utilisateurs DeFi, la liste de vérification pratique est courte. Déterminez quel bridge un token utilise pour passer entre les chaînes qui vous intéressent. Lisez comment ce bridge vérifie les messages. Si la réponse est un multisig, demandez combien de signataires sont requis, qui ils sont et comment ils sont gouvernés. Si la réponse est un client léger, demandez si la chaîne de destination exécute réellement ce client et à quelle fréquence il est mis à jour. Si la réponse est une pile DVN, demandez quels DVN font partie de la pile et s’ils sont indépendants. Un actif wrapped ou bridgé n’est sûr qu’à hauteur de la partie la plus faible de cette réponse, et le token bridgé présente rarement le même profil de risque que l’actif sous-jacent sur sa chaîne d’origine.
Il faut aussi se rappeler que le risque cross-chain n’est pas statique. L’ensemble de gardiens d’un bridge aujourd’hui peut ne plus être le même demain. La composition des DVN d’une application LayerZero aujourd’hui peut être reconfigurée demain. Les clients légers d’une connexion IBC aujourd’hui dépendent d’ensembles de validateurs qui peuvent changer par gouvernance. Les hypothèses de confiance sont des éléments vivants, et une comparaison honnête est celle qui le dit clairement.
Comment suivre intelligemment le risque cross-chain
L’infrastructure cross-chain évolue vite, tout comme l’actualité autour de sa sécurité. Suivre manuellement les audits de bridges, les rotations de gardiens, les changements de DVN et les divulgations d’exploits est une bataille perdue. Zippfeed fait remonter les gros titres cross-chain avec une notation du sentiment, bullish, neutral ou bearish, et une note d’importance, afin que vous puissiez voir quels événements liés aux bridges ont réellement fait bouger les marchés et lesquels n’étaient que du bruit. Ajoutez à cela l’habitude de vous demander, à chaque fois, à quel ensemble de validateurs vous confiez le message, et vous aurez une longueur d’avance sur la plupart des utilisateurs particuliers qui traitent encore les bridges comme une infrastructure de routine.
Crypto Rank News
