Après une faille en novembre sur les pools stables composables, l’équipe de Balancer v3 a utilisé cet incident pour revoir ses défenses et renforcer la sécurité au niveau du protocole.
De l’exploit du 3 novembre à un modèle de sécurité proactive
Le 3 novembre, une faille a touché les pools stables composables sur V2, ce qui a poussé Balancer à agir de manière décisive. V3 est resté totalement indemne, mais l’équipe a vu une opportunité de renforcer son modèle de sécurité et de préparer le protocole contre toute classe d’attaque future.
L’exploit CSP a révélé une voie d’attaque qui existait depuis plus de quatre ans avant que quelqu’un ne la remarque. De plus, des faiblesses similaires ont été exploitées plus tard sur d’autres protocoles, montrant que ce schéma était largement passé inaperçu dans l’industrie et obligeant à repenser en profondeur les hypothèses de défense.
La sécurité traditionnelle tend à être réactive : détecter un bug, le corriger, puis passer à autre chose. Cependant, cette approche laisse des vulnérabilités inconnues intactes, y compris des vecteurs d’attaque qui peuvent rester cachés pendant encore quatre ans avant d’être découverts par des adversaires.
Conception de V3 pour éliminer des classes entières d’exploits
L’équipe a conclu que la meilleure réponse était de supprimer des catégories entières d’exploits potentiels en limitant le protocole aux cas d’usage légitimes et économiquement significatifs. Si une opération n’a pas de raison valable d’exister, elle ne doit pas être possible sur la blockchain.
L’architecture de V3 reflète déjà cette philosophie. Son architecture centrée sur le coffre-fort (vault) centralise les soldes de tokens, la comptabilité des frais et la gestion des BPT dans un système unique, fortement audité. Ces choix permettent également de réduire de nombreux surfaces d’attaque potentielles qui pourraient être exploitées par des acteurs malveillants.
Grâce à cette conception, la vulnérabilité spécifique liée à l’arrondi qui a permis l’exploit du 3 novembre n’existe pas dans V3. Le résultat est clair : aucune pool V3 n’a été impactée par l’incident, malgré la gravité de l’attaque sur l’infrastructure V2.
Renforcement de Balancer V3 par une réévaluation approfondie de la sécurité
Même avec ce bilan sans faille, l’équipe est allée plus loin. En collaboration avec Certora, Balancer a commandé une réévaluation approfondie de nombreux contrats intelligents V3, visant à détecter et éliminer toute voie d’attaque potentielle avant qu’elle ne puisse être utilisée par des acteurs malveillants.
L’audit de sécurité V3 réalisé par Certora n’a révélé aucune vulnérabilité dans les contrats examinés. De plus, les résultats ont montré que l’architecture simplifiée, qui déplace la complexité des pools individuels vers le coffre-fort, produit un protocole plus sécurisé par conception.
Pour les lecteurs intéressés par les nuances techniques et les méthodes formelles, le rapport complet de Certora est disponible dans le rapport intégral sur la réévaluation de la sécurité. Cependant, l’essentiel est clair : les choix architecturaux sont validés par une revue externe rigoureuse.
Nouveaux garde-fous pour les pools pondérés
Au-delà de l’audit réussi, Balancer a mis en place des garde-fous de sécurité supplémentaires pour les pools pondérés et stables. Ces protections limitent davantage le comportement du protocole aux scénarios économiques valides et aident à neutraliser les schémas d’attaque connus au niveau des pools.
Sur V3, deux garde-fous spécifiques pour les pools pondérés ont été introduits pour éliminer les cas d’usage malveillants ou pathologiques. Ensemble, ils renforcent l’objectif central de limiter les opérations à des conditions de trading réalistes et significatives.
Limites minimales de solde de tokens
La première mesure consiste en un système de limites minimales de solde de tokens, appliqué de manière cohérente à travers toutes les configurations de décimales de tokens. Étant donné que des soldes très faibles nécessitent généralement des échanges très importants, ce mécanisme limite indirectement la taille maximale effective des échanges.
En conséquence, l’activité des pools est contrainte à une plage économiquement significative. De plus, les opérations qui auraient autrement poussé les soldes dans des extrêmes irréalistes ne sont plus autorisées, ce qui empêche des scénarios pouvant manipuler les calculs ou déclencher des bugs de cas limites.
Rondage amélioré des soldes dans le coffre-fort
Le deuxième garde-fou concerne le rondage amélioré des soldes dans le coffre-fort et la mathématique des pools. Dans le modèle précédent, certaines opérations de liquidité dans le coffre-fort passaient une direction de rondage requise aux pools lorsque un comportement spécifique était nécessaire.
Dans V3, ce sont toujours les pools qui effectuent le rondage correctement. En particulier, la logique de rondage amountIn pour les swaps ExactOut a été corrigée par rapport à V2. De plus, Balancer arrondit désormais vers le haut le solde tokenIn lors des calculs internes, poussant le rondage déjà correct vers des résultats plus conservateurs et plus sûrs.
Limites des pools stables et le ratio d’imbalance maximal
Les pools stables V3 ont également bénéficié d’une contrainte supplémentaire visant à refléter le comportement attendu de ces marchés en pratique. Ce garde-fou se concentre sur la prévention d’imbalances extrêmes qui ont historiquement caractérisé les tentatives d’exploitation.
Le nouveau ratio d’imbalance maximal impose un plafond dur de 10 000:1 entre le plus grand et le plus petit solde de tokens dans un pool stable. Bien que ces pools soient destinés à rester proches d’un équilibre 1:1, ce plafond généreux bloque néanmoins les états extrêmes observés lors d’attaques connues.
L’idée centrale est de limiter les pools stables à une zone opérationnelle économiquement significative. Il n’y a aucune raison valable de faire fonctionner un pool avec des ratios approchant ces extrêmes, le protocole interdit donc ces configurations, renforçant ainsi les limites raisonnables pour les pools stables.
Réévaluation des swaps flash et scénarios impossibles
Une réalisation clé a façonné ces décisions de conception : les swaps flash sont fondamentalement différents des prêts flash. Bien que les deux mécanismes offrent un accès temporaire aux actifs, les prêts flash restent limités par la liquidité disponible sur la blockchain.
Les swaps flash, en revanche, sont principalement limités par la capacité de stockage, qui peut théoriquement atteindre 1e128 tokens, bien au-delà de toute offre en circulation ou totale d’un actif. De plus, cette différence ouvre la voie à des abus lorsque les protocoles ne reconnaissent pas à quel point ces chiffres sont irréalistes.
Il n’y a aucune justification légitime pour emprunter effectivement plus de tokens que ce qui existe réellement. Une telle opération est soit une erreur utilisateur, soit une attaque pure et simple, et non un cas d’usage valable. Balancer v3 empêche désormais ces scénarios impossibles grâce à ses garde-fous renforcés.
Fixer un standard plus élevé pour la sécurité des AMM
L’exploit du 3 novembre a laissé des leçons difficiles mais précieuses pour l’ensemble de l’écosystème DeFi. La réponse de Balancer montre un engagement à apprendre des incidents, même lorsqu’ils n’impactent pas directement la dernière version du protocole.
En adoptant une posture préventive plutôt que réactive, le projet vise à établir une nouvelle norme pour la sécurité des AMM, en intégrant la robustesse dès la conception pour bloquer les menaces avant qu’elles ne se matérialisent complètement.
La sécurité de Balancer ne se limite pas à la conception des contrats intelligents. En partenariat avec Hypernative, de nouveaux pools intègrent des capacités d’arrêt prolongé supportées par une surveillance 24/7, permettant une réponse rapide face aux menaces sur la blockchain et évoluant vers un modèle de protection active plutôt que d’immuabilité rigide.
Déploiement, documentation et perspectives
Les nouvelles factories de pools pondérés et stables, y compris les pools Stable Surge avec des garde-fous étendus, sont désormais en ligne sur tous les réseaux supportés par V3. De plus, les développeurs peuvent consulter les spécifications techniques et des exemples dans la documentation officielle de balancer v3 et dans les dépôts associés.
La mission de Balancer reste d’accélérer l’innovation DeFi en fournissant une infrastructure sécurisée et prête pour la production pour les applications de liquidité. Les projets choisissent le protocole comme base pour concevoir de nouveaux types de pools et construire des dApps financières avancées sur une infrastructure audité et renforcée.
En résumé, la combinaison de choix architecturaux, d’audits externes, de nouveaux garde-fous et de surveillance en temps réel reflète une mentalité axée sur la sécurité. L’évolution de V3 montre comment un seul incident peut pousser l’écosystème vers des AMM plus solides et plus résilients.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Comment Balancer V3 transforme une vulnérabilité critique en une nouvelle norme pour la sécurité des AMM
Après une faille en novembre sur les pools stables composables, l’équipe de Balancer v3 a utilisé cet incident pour revoir ses défenses et renforcer la sécurité au niveau du protocole.
De l’exploit du 3 novembre à un modèle de sécurité proactive
Le 3 novembre, une faille a touché les pools stables composables sur V2, ce qui a poussé Balancer à agir de manière décisive. V3 est resté totalement indemne, mais l’équipe a vu une opportunité de renforcer son modèle de sécurité et de préparer le protocole contre toute classe d’attaque future.
L’exploit CSP a révélé une voie d’attaque qui existait depuis plus de quatre ans avant que quelqu’un ne la remarque. De plus, des faiblesses similaires ont été exploitées plus tard sur d’autres protocoles, montrant que ce schéma était largement passé inaperçu dans l’industrie et obligeant à repenser en profondeur les hypothèses de défense.
La sécurité traditionnelle tend à être réactive : détecter un bug, le corriger, puis passer à autre chose. Cependant, cette approche laisse des vulnérabilités inconnues intactes, y compris des vecteurs d’attaque qui peuvent rester cachés pendant encore quatre ans avant d’être découverts par des adversaires.
Conception de V3 pour éliminer des classes entières d’exploits
L’équipe a conclu que la meilleure réponse était de supprimer des catégories entières d’exploits potentiels en limitant le protocole aux cas d’usage légitimes et économiquement significatifs. Si une opération n’a pas de raison valable d’exister, elle ne doit pas être possible sur la blockchain.
L’architecture de V3 reflète déjà cette philosophie. Son architecture centrée sur le coffre-fort (vault) centralise les soldes de tokens, la comptabilité des frais et la gestion des BPT dans un système unique, fortement audité. Ces choix permettent également de réduire de nombreux surfaces d’attaque potentielles qui pourraient être exploitées par des acteurs malveillants.
Grâce à cette conception, la vulnérabilité spécifique liée à l’arrondi qui a permis l’exploit du 3 novembre n’existe pas dans V3. Le résultat est clair : aucune pool V3 n’a été impactée par l’incident, malgré la gravité de l’attaque sur l’infrastructure V2.
Renforcement de Balancer V3 par une réévaluation approfondie de la sécurité
Même avec ce bilan sans faille, l’équipe est allée plus loin. En collaboration avec Certora, Balancer a commandé une réévaluation approfondie de nombreux contrats intelligents V3, visant à détecter et éliminer toute voie d’attaque potentielle avant qu’elle ne puisse être utilisée par des acteurs malveillants.
L’audit de sécurité V3 réalisé par Certora n’a révélé aucune vulnérabilité dans les contrats examinés. De plus, les résultats ont montré que l’architecture simplifiée, qui déplace la complexité des pools individuels vers le coffre-fort, produit un protocole plus sécurisé par conception.
Pour les lecteurs intéressés par les nuances techniques et les méthodes formelles, le rapport complet de Certora est disponible dans le rapport intégral sur la réévaluation de la sécurité. Cependant, l’essentiel est clair : les choix architecturaux sont validés par une revue externe rigoureuse.
Nouveaux garde-fous pour les pools pondérés
Au-delà de l’audit réussi, Balancer a mis en place des garde-fous de sécurité supplémentaires pour les pools pondérés et stables. Ces protections limitent davantage le comportement du protocole aux scénarios économiques valides et aident à neutraliser les schémas d’attaque connus au niveau des pools.
Sur V3, deux garde-fous spécifiques pour les pools pondérés ont été introduits pour éliminer les cas d’usage malveillants ou pathologiques. Ensemble, ils renforcent l’objectif central de limiter les opérations à des conditions de trading réalistes et significatives.
Limites minimales de solde de tokens
La première mesure consiste en un système de limites minimales de solde de tokens, appliqué de manière cohérente à travers toutes les configurations de décimales de tokens. Étant donné que des soldes très faibles nécessitent généralement des échanges très importants, ce mécanisme limite indirectement la taille maximale effective des échanges.
En conséquence, l’activité des pools est contrainte à une plage économiquement significative. De plus, les opérations qui auraient autrement poussé les soldes dans des extrêmes irréalistes ne sont plus autorisées, ce qui empêche des scénarios pouvant manipuler les calculs ou déclencher des bugs de cas limites.
Rondage amélioré des soldes dans le coffre-fort
Le deuxième garde-fou concerne le rondage amélioré des soldes dans le coffre-fort et la mathématique des pools. Dans le modèle précédent, certaines opérations de liquidité dans le coffre-fort passaient une direction de rondage requise aux pools lorsque un comportement spécifique était nécessaire.
Dans V3, ce sont toujours les pools qui effectuent le rondage correctement. En particulier, la logique de rondage amountIn pour les swaps ExactOut a été corrigée par rapport à V2. De plus, Balancer arrondit désormais vers le haut le solde tokenIn lors des calculs internes, poussant le rondage déjà correct vers des résultats plus conservateurs et plus sûrs.
Limites des pools stables et le ratio d’imbalance maximal
Les pools stables V3 ont également bénéficié d’une contrainte supplémentaire visant à refléter le comportement attendu de ces marchés en pratique. Ce garde-fou se concentre sur la prévention d’imbalances extrêmes qui ont historiquement caractérisé les tentatives d’exploitation.
Le nouveau ratio d’imbalance maximal impose un plafond dur de 10 000:1 entre le plus grand et le plus petit solde de tokens dans un pool stable. Bien que ces pools soient destinés à rester proches d’un équilibre 1:1, ce plafond généreux bloque néanmoins les états extrêmes observés lors d’attaques connues.
L’idée centrale est de limiter les pools stables à une zone opérationnelle économiquement significative. Il n’y a aucune raison valable de faire fonctionner un pool avec des ratios approchant ces extrêmes, le protocole interdit donc ces configurations, renforçant ainsi les limites raisonnables pour les pools stables.
Réévaluation des swaps flash et scénarios impossibles
Une réalisation clé a façonné ces décisions de conception : les swaps flash sont fondamentalement différents des prêts flash. Bien que les deux mécanismes offrent un accès temporaire aux actifs, les prêts flash restent limités par la liquidité disponible sur la blockchain.
Les swaps flash, en revanche, sont principalement limités par la capacité de stockage, qui peut théoriquement atteindre 1e128 tokens, bien au-delà de toute offre en circulation ou totale d’un actif. De plus, cette différence ouvre la voie à des abus lorsque les protocoles ne reconnaissent pas à quel point ces chiffres sont irréalistes.
Il n’y a aucune justification légitime pour emprunter effectivement plus de tokens que ce qui existe réellement. Une telle opération est soit une erreur utilisateur, soit une attaque pure et simple, et non un cas d’usage valable. Balancer v3 empêche désormais ces scénarios impossibles grâce à ses garde-fous renforcés.
Fixer un standard plus élevé pour la sécurité des AMM
L’exploit du 3 novembre a laissé des leçons difficiles mais précieuses pour l’ensemble de l’écosystème DeFi. La réponse de Balancer montre un engagement à apprendre des incidents, même lorsqu’ils n’impactent pas directement la dernière version du protocole.
En adoptant une posture préventive plutôt que réactive, le projet vise à établir une nouvelle norme pour la sécurité des AMM, en intégrant la robustesse dès la conception pour bloquer les menaces avant qu’elles ne se matérialisent complètement.
La sécurité de Balancer ne se limite pas à la conception des contrats intelligents. En partenariat avec Hypernative, de nouveaux pools intègrent des capacités d’arrêt prolongé supportées par une surveillance 24/7, permettant une réponse rapide face aux menaces sur la blockchain et évoluant vers un modèle de protection active plutôt que d’immuabilité rigide.
Déploiement, documentation et perspectives
Les nouvelles factories de pools pondérés et stables, y compris les pools Stable Surge avec des garde-fous étendus, sont désormais en ligne sur tous les réseaux supportés par V3. De plus, les développeurs peuvent consulter les spécifications techniques et des exemples dans la documentation officielle de balancer v3 et dans les dépôts associés.
La mission de Balancer reste d’accélérer l’innovation DeFi en fournissant une infrastructure sécurisée et prête pour la production pour les applications de liquidité. Les projets choisissent le protocole comme base pour concevoir de nouveaux types de pools et construire des dApps financières avancées sur une infrastructure audité et renforcée.
En résumé, la combinaison de choix architecturaux, d’audits externes, de nouveaux garde-fous et de surveillance en temps réel reflète une mentalité axée sur la sécurité. L’évolution de V3 montre comment un seul incident peut pousser l’écosystème vers des AMM plus solides et plus résilients.