Analyse préliminaire de l'incident d'attaque de Balancer V2

Le 3 novembre, le protocole Balancer V2 et ses projets fork ont été attaqués sur plusieurs chaînes, entraînant des pertes graves de plus de 120 millions de dollars. BlockSec a donné une alerte en temps réel [1] et a fourni une analyse préliminaire concluant [2]. Il s'agit d'un événement d'attaque hautement complexe. Notre analyse préliminaire indique que la cause fondamentale réside dans la manipulation des invariants par les attaquants, ce qui a déformé le calcul du prix du BPT (Balancer Pool Token ) – c'est-à-dire le LP token de la pool – permettant ainsi de réaliser des profits grâce à une opération batchSwap dans un certain pool stable.

Connaissances de base

1. Mise à l'échelle (scaling) et arrondi (rounding)

Pour unifier les décimales de différents jetons, le contrat Balancer va :

• upscale : agrandir le solde et le montant à une précision interne uniforme avant de faire le calcul ;
• downscale : ramener le résultat à la précision native et effectuer un arrondi directionnel (par exemple, l'entrée est généralement arrondie à l'entier supérieur pour s'assurer que le pool n'est pas sous-collecté ; le chemin de sortie est souvent tronqué à l'entier inférieur).

Conclusion : Dans une même transaction, la direction d'arrondi utilisée à différentes étapes n'est pas symétrique, ce qui peut entraîner un biais systématique minime lors d'exécutions répétées à très petites étapes.

2. D et le prix de BPT

L'attaque a affecté le protocole Composable Stable Pool [3] de Balancer V2 ainsi que le protocole forké. Le Stable Pool est destiné à ceux qui s'attendent à maintenir un ratio d'échange proche de 1:1 (ou à échanger des actifs à un taux connu), permettant des échanges importants sans provoquer de chocs de prix significatifs, augmentant ainsi considérablement l'efficacité d'utilisation des fonds entre des actifs similaires ou connexes.

• Ce pool utilise Stable Math (modèle StableSwap basé sur Curve), l'invariant D représentant la “valeur totale virtuelle” du pool.
• BPT (Pool du Token LP ) prix approximatif :

D'après la formule ci-dessus, si D peut être réduit sur le bilan (même si les fonds n'ont pas réellement disparu), cela peut rendre le prix du BPT moins cher. Le BTP représente la part du Pool, utilisée pour calculer combien de réserves du Pool peuvent être obtenues lors du retrait de liquidités. Par conséquent, si un attaquant peut obtenir plus de BPT, il pourra réaliser un profit lors du retrait de liquidités.

Analyse des attaques

Prenons l'exemple d'une transaction d'attaque sur Arbitrum, l'opération batchSwap peut être divisée en trois phases :

Première étape : l'attaquant échange le BPT contre des actifs sous-jacents pour ajuster précisément le solde d'un des jetons (cbETH) au point critique de la limite d'arrondi (quantité = 9). Cette étape crée les conditions pour la perte de précision de la phase suivante.

Deuxième étape : L'attaquant utilise un montant soigneusement construit (= 8) pour échanger entre un autre actif sous-jacent (wstETH) et cbETH. En raison d'un arrondi à la baisse lors de la mise à l'échelle du nombre de jetons, le Δx calculé est légèrement inférieur (passe de 8.918 à 8), ce qui entraîne une sous-estimation de Δy et réduit l'invariant D (provenant du modèle StableSwap de Curve). Puisque le prix du BPT = D / totalSupply, le prix du BPT est artificiellement abaissé.

Troisième étape : L'attaquant échange les actifs sous-jacents contre des BPT, tout en rétablissant l'équilibre dans le pool, et profite du prix du BPT, qui a été abaissé - obtenant ainsi plus de jetons BPT.

Enfin, l'attaquant a utilisé une autre transaction profitable pour retirer de la liquidité, exploitant ainsi le BPT supplémentaire pour obtenir d'autres actifs sous-jacents dans le Pool, à savoir (cbETH et wstETH), réalisant ainsi un profit.

Transaction d'attaque :

Transactions rentables :

Référence :

[1]

[2]

[3]