Les bridges cross-chain ont perdu plus d'argent en exploits que toute autre catégorie de protocole DeFi. Ronin, Wormhole, Nomad, Harmony, Multichain, Poly Network, la liste est longue, les montants sont énormes, et les causes sous-jacentes se répètent.
Ce qui suit, c'est l'explication qu'on donne aux équipes qui conçoivent ou opèrent un bridge, et aux équipes dont le protocole en dépend. Comprendre l'architecture est le premier pas pour ne pas figurer sur la prochaine liste.
Le problème fondamental
Les blockchains ne peuvent pas lire nativement l'état l'une de l'autre. Ethereum n'a aucune idée de ce qui vient de se passer sur Polygon ; Arbitrum n'a aucune idée du Bitcoin. Donc un « bridge » entre deux chaînes est, par nécessité, un système qui atteste qu'un événement a eu lieu sur la chaîne A et débloque la valeur correspondante sur la chaîne B.
L'attestation, c'est le modèle de sécurité. Chaque bridge, indépendamment du marketing, se ramène à : qui ou quoi atteste, et qu'est-ce qui empêche de mentir ?
Quatre architectures courantes :
1. Multi-sig de validateurs
Un ensemble d'opérateurs (5, 9 ou 21 clés, typiquement) signent des messages confirmant les événements de la chaîne A. La chaîne B fait confiance aux signatures.
C'est le design le plus simple et le plus exploité. Ronin (625 M$) a perdu cinq clés de validateur sur neuf à une attaque de phishing. Multichain (130 M$+) était effectivement à un seul signataire, contredisant son marketing. Modèle de menace : voler le seuil de clés, drainer le bridge.
2. Light client de la chaîne source
La chaîne B fait tourner un light client de la chaîne A en smart contract, et vérifie son consensus directement. Pas d'intermédiaire de confiance ; le bridge hérite de la sécurité de la chaîne A.
C'est en principe le modèle le plus solide, mais opérationnellement lourd. Les light clients doivent suivre les headers de la chaîne A, ce qui peut être coûteux et complexe (surtout pour des chaînes à reorgs ou logique de slashing PoS). Les implémentations sont subtiles et ont déjà livré des bugs.
3. Optimiste avec fraud proofs
La chaîne B accepte les attestations d'un ensemble de relayers, mais n'importe qui peut soumettre un fraud proof pendant une fenêtre de challenge (typiquement plusieurs jours). Sans challenge, l'attestation est finalisée.
La perte de 190 M$ de Nomad venait de cette catégorie, mais pas de la logique optimiste elle-même ; d'un upgrade bâclé qui a permis à n'importe quel input de passer la vérification. L'architecture est saine ; l'implémentation doit être exacte.
4. Preuves zero-knowledge
La chaîne B vérifie une ZK proof qu'un événement spécifique s'est produit sur la chaîne A. La cryptographie remplace la confiance. C'est la classe de bridges la plus récente et la plus chère ; le modèle de confiance est excellent mais la surface de bug est large et la maturité opérationnelle encore en construction.
Pourquoi les bugs de bridge sont catastrophiques
Un bridge réussi détient le supply locké de chaque actif qui est passé par lui. Un petit bug n'importe où dans le pipeline de confiance draine le tout, pas juste la transaction du prochain utilisateur, mais chaque dépôt d'utilisateur depuis le lancement.
C'est ce qui rend les bridges différents des autres protocoles. Une reentrancy dans un protocole de prêt draine une position. Une reentrancy dans un bridge draine le bridge. Les enjeux économiques ne sont pas comparables.
La répétition dans les rapports d'incident
À lire des post-mortems de bridge sur un an, les mêmes causes racines reviennent :
Compromission opérationnelle des clés de validateur. Les validateurs multi-sig sont opérés par des humains sur des machines. Phishing, compromission de la supply chain, ingénierie sociale, les mêmes vecteurs qui touchent toute organisation, appliqués à des clés qui détiennent neuf ou dix chiffres. Le correctif n'est pas « plus de validateurs », c'est la discipline de la gestion des clés et de l'hygiène de wallet, appliquée à l'environnement le plus adversarial qui soit.
Logique de vérification qui accepte des inputs invalides. Le bug de Nomad était une seule ligne dans un upgrade qui initialisait la racine de vérification à zéro, ce qui rendait valide tout message avec une preuve nulle. Le bug était subtil, l'audit l'a raté, et une fois qu'une adresse a remarqué et a commencé à exploiter, des copy-paste exploiters ont drainé le reste en quelques heures.
Chemins d'upgrade contrôlés par un petit groupe. Même quand la logique de contrat est correcte, le chemin d'upgrade ne l'est souvent pas. Un bridge dont les clés admin peuvent changer le contrat est seulement aussi sûr que ces clés admin.
Couverture incomplète. Un bridge entre cinq chaînes n'a pas cinq surfaces d'attaque, il a le produit cartésien des chaînes plus la logique de relai. Les audits qui couvrent une chaîne, pas l'intégration, ratent les fissures.
À quoi ressemble une bonne sécurité de bridge
Si vous opérez un bridge, ou que votre protocole en dépend, voici ce qu'il faut vérifier :
Plafonner le flux par epoch
Un bridge qui peut bouger 100 % de son TVL en un bloc n'a construit aucune défense en profondeur. Les vrais bridges plafonnent les sorties par epoch, par chaîne, par actif, parfois par adresse. Le cap, c'est la différence entre 10 M$ et 500 M$ de perte.
Time-lock le chemin d'upgrade
Les upgrades aux contrats de bridge doivent demander un timelock de plusieurs jours avec visibilité publique. La communauté a besoin de temps pour voir et réagir. Un chemin d'upgrade à exécution immédiate, c'est là où Nomad est mort.
Diversité du set de validateurs
Si vous opérez un bridge multi-sig, les validateurs doivent être opérationnellement indépendants : organisations différentes, fournisseurs d'infra différents, géographies différentes, devices de signature différents. Cinq validateurs sur le même cluster Kubernetes, c'est un seul validateur.
Monitoring continu des invariants cross-chain
Le total locké sur la chaîne A doit égaler le total minté sur la chaîne B, à chaque bloc, pour chaque actif. Une divergence est le premier signal d'attaque, parfois le premier signal d'un bug, et ça doit pager quelqu'un immédiatement. Wallet Surveillance sur les contrats de bridge et les adresses opérationnelles des validateurs fait partie de la livraison.
Bug bounty proportionnel au TVL
Un bounty d'1 M$ sur un bridge à 1 G$ n'est pas une incitation, c'est un nombre dont l'attaquant rit. Les bridges sérieux ont des bounties qui scalent avec la valeur en jeu : 5 à 10 % de la valeur récupérable, plafonné raisonnablement. Immunefi héberge des programmes de bridge avec des caps à huit chiffres, et ils ont payé.
Un plan de réponse à incident documenté
Si le pire arrive, qui met en pause le bridge ? Qui notifie les chaînes ? Qui notifie les protocoles dépendants ? Qui mène le traçage on-chain ? Le plan existe, par écrit, avant l'incident. On aide les équipes à écrire le leur dans la mission Réponse à incident.
Pour les utilisateurs
Si vous bougez des fonds entre chaînes, trois règles :
- Traitez le bridge comme une contrepartie. Vous acceptez le risque bridge pour la durée de la position bridgée. Comprenez l'architecture et acceptez-la délibérément.
- Ne parquez pas vos fonds dans les représentations bridgées. USDC.e n'est pas USDC ; ETH bridgé n'est pas ETH. Utilisez l'actif canonique sur la chaîne où vous opérez, et bridgez seulement quand vous comptez utiliser les fonds tout de suite.
- Diversifiez les bridges. Si vous bougez de gros montants à répétition, étalez la route. Une compromission de bridge unique, c'est mauvais. Concentrer toute votre exposition cross-chain sur un seul bridge, c'est pire.
Où ça va
L'espace converge vers de meilleures architectures. Les ZK bridges mûrissent. Les bridges light-client se déploient davantage. Les caps de flux par epoch deviennent standard. Des contrats de bridge immuables (sans chemin d'upgrade) sont déployés pour les routes de haute valeur.
Mais la couche opérationnelle, clés, validateurs, monitoring, réponse, reste une discipline qu'on doit pratiquer. Le prochain incident de bridge ne sera pas d'une catégorie nouvelle ; il sera d'une catégorie familière, dans un nouveau projet. Ne soyez pas le nouveau projet.