[Довгий тред англійською] Глибокий аналіз атаки на Balancer V2: механізм вразливості, кроки атаки та уроки

Chainfeeds Огляд:

Зловмисник навмисно налаштував параметри, включаючи кількість ітерацій та суму введення, щоб максимізувати ефект втрати точності.

Джерело статті:

Автор статті:

BlockSec

Думка:

BlockSec: 3 листопада 2025 року Composable Stable Pool Balancer V2, а також кілька проєктів на різних блокчейнах, заснованих на його Fork, зазнали координованої міжланцюгової атаки, що призвела до загальних втрат понад 125 мільйонів доларів. BlockSec оперативно випустив попередження та згодом опублікував попередній аналіз. Це була надзвичайно складна атака. Наше розслідування показало, що основна причина полягала у втраті точності при обчисленні інваріанти, що дозволило маніпулювати ціною через цю втрату точності, вплинувши на ціну BPT (Balancer Pool Token). Зловмисник отримав прибуток із певного стейбл-пулу за допомогою одноразової операції batchSwap. Ураженим компонентом був Composable Stable Pool Balancer V2. Такі пули спеціально розроблені для активів, які мають підтримувати співвідношення обміну близьке до 1:1, дозволяючи здійснювати великі угоди з мінімальним сліппеджем і значно підвищуючи капітальну ефективність для подібних або пов’язаних активів. Кожен пул має власний BPT, ціна якого приблизно виражається так: ціна BPT = D / totalSupply, де D — інваріанта у стейбл-математиці, що представляє віртуальну загальну вартість пулу. З формули видно, що якщо D математично зменшується (навіть якщо реальні кошти не втрачені), ціна BPT виглядатиме нижчою. Balancer V2 надає функцію batchSwap (), яка дозволяє здійснювати багатоступеневий Swap у Vault, а в SwapRequest є два режими: GIVEN_IN і GIVEN_OUT. У режимі GIVEN_OUT викликаюча сторона вказує бажану суму виводу, а пул розраховує необхідну суму введення. У стейбл-пулі при розрахунку необхідної суми введення amountIn потрібно розв’язати багаточленове рівняння згідно з інваріантною формулою, і ці обчислення уніфіковано виконуються через Upscaling і Downscaling. Теоретично це протилежні операції, але на практиці реалізовано різні напрямки округлення: при підвищенні масштабу використовується лише округлення вниз (mulDown), а при зниженні масштабу — як округлення вгору, так і вниз (divUp / divDown). Саме ця неузгодженість відкрила можливість для атаки. Корінь вразливості полягає у використанні округлення вниз для swapRequest.amount під час Upscaling у BaseGeneralPool._swapGivenOut (). Значення після округлення вниз використовується як amountOut для _onSwapGivenOut (), що призводить до того, що остаточно обчислений amountIn менший за реальну потребу, порушуючи принцип, за яким округлення має бути на користь протоколу. Для пулів типу (wstETH / rETH / cbETH) зловмисник може обміняти меншу кількість одного активу на більшу кількість іншого, зменшуючи інваріанту D і, відповідно, знижуючи ціну BPT. Атаку було здійснено у два етапи. На першому етапі основна логіка атаки виконується в одній транзакції, але прибуток не виводиться одразу; на другому етапі прибуток виводиться окремою транзакцією. Перший етап складається з розрахунку параметрів і batch swap. Наприклад, у транзакції на ланцюгу Arbitrum (TX: 0x7da32e…55773) зловмисник спочатку отримує параметри пулу, включаючи scaling factors, A (коефіцієнт підсилення), курс BPT, swap fee тощо, потім розраховує trickAmt і моделює ситуацію через допоміжний смарт-контракт. Зловмисник точно налаштовує параметри наступного swap, поєднуючи офлайн-розрахунки та ончейн-симуляції, включаючи кількість ітерацій і значення введення/виводу для кожної ітерації. В ітераціях виконуються три swap: на першому кроці кількість цільового токена доводиться до trickAmt + 1; на другому кроці продовжується swap цільового токена, що активує округлення вниз у _upscale (); на третьому кроці виконується зворотний swap, при якому баланс пулу округлюється вниз до "відкидання двох старших десяткових знаків" (наприклад, 324,816 → 320,000), а потім обмінюється назад. У деяких випадках, через використання методу Ньютона–Рафсона для розв’язання рівнянь у StableSwap, обчислення може не вдатися, тому зловмисник підготував два fallback-варіанти, повторюючи спробу з 9/10 від початкового значення. Після атаки, через те, що деякі механізми Balancer не можна було призупинити, вплив атаки посилився, і на багатьох ланцюгах з’явилися наслідувачі та копіювальні атаки, що призвело до загальних втрат понад 125 мільйонів доларів. Ця подія виявила чотири ключові проблеми децентралізованих протоколів: неузгодженість механізмів округлення, постійна еволюція методів атак, неможливість призупинення, що збільшує втрати, та відсутність реального моніторингу стану ініціалізації й експлуатації. Підвищення масштабу дозволяє лише округлення вниз, а зниження масштабу — обидва напрямки, і ця асиметрія при екстремальних параметрах накопичується у втрату точності, яку можна використати. Округлення, яке мало б завжди бути на користь протоколу, у цьому випадку шкодить його інтересам. Зловмисник використав двоетапний підхід: на першому етапі здійснюється атака без фіксації прибутку, на другому — окреме виведення, щоб обійти ончейн-моделі моніторингу. Кожен крок атаки поєднував офчейн- та ончейн-симуляції, допоміжний контракт навіть повторно використовував реалізацію StableMath від Balancer, зберігаючи ідентичні повідомлення про помилки. Після атаки відбулася хвиля наслідувань на різних ланцюгах, багато Fork-проєктів також постраждали, що свідчить: якщо стейбл-математика та логіка округлення однакові, вразливість може поширюватися між екосистемами. Подія показала, що DeFi-протоколи потребують більш точних математичних обчислень, суворішої перевірки округлення та механізмів моделювання підозрілих шляхів, а також можливості екстреної зупинки у випадку аномалій. [Оригінал англійською]