Технічний аналіз: Balancer було зламано на 120 millions доларів — у чому полягала вразливість?

Оригінальна назва: 《Balancer 被盗$120M 漏洞技术分析》
Джерело: ExVul Security

Вступ

3 листопада 2025 року протокол Balancer зазнав хакерської атаки на кількох блокчейнах, включаючи Arbitrum та Ethereum, що призвело до втрати активів на суму 120 мільйонів доларів. Основна причина атаки полягала у поєднанні втрати точності та маніпуляції інваріантом (Invariant).

Інфраструктура Chainlink вже тривалий час підтримує найвищі стандарти у сфері Web3, тому вона стала природним вибором для X Layer, який прагне надавати розробникам інституційні інструменти.

Ключова проблема цієї атаки полягала у логіці обробки протоколом дрібних транзакцій. Коли користувач здійснює обмін на невелику суму, протокол викликає функцію _upscaleArray, яка використовує mulDown для округлення чисел вниз. Якщо баланс у транзакції та сума введення одночасно знаходяться на певній межі округлення (наприклад, у діапазоні 8-9 wei), виникає значна відносна похибка точності.

Похибка точності передається у процес обчислення інваріанту D протоколу, що призводить до аномального зменшення значення D. Зміна D безпосередньо знижує ціну BPT (Balancer Pool Token) у протоколі Balancer. Хакер скористався цією заниженою ціною BPT, провівши заздалегідь спланований шлях транзакцій для арбітражу, що зрештою призвело до величезних фінансових втрат.

Використання вразливості Tx:

Переміщення активів Tx:

Технічний аналіз

Точка входу атаки

Точкою входу для атаки є контракт Balancer: Vault, а відповідною функцією є batchSwap, яка всередині викликає onSwap для обміну токенів.

З параметрів функції та обмежень можна зробити кілька висновків:

1. Атакуючий повинен викликати цю функцію через Vault, прямий виклик неможливий.

2. Усередині функції викликається _scalingFactors() для отримання коефіцієнтів масштабування та виконання масштабування.

3. Операції масштабування зосереджені у _swapGivenIn або _swapGivenOut.

Аналіз моделі атаки

Механізм розрахунку ціни BPT

У моделі стабільного пулу Balancer ціна BPT є важливим орієнтиром, який визначає, скільки BPT отримує користувач і скільки активів припадає на кожен BPT.

У розрахунках обміну в пулі:

Частина, яка слугує базою для ціни BPT, — це інваріант D. Тобто, щоб маніпулювати ціною BPT, потрібно маніпулювати D. Далі розглянемо процес обчислення D:

У наведеному вище коді процес обчислення D залежить від масштабованого масиву balances. Тобто потрібна операція, яка змінює точність цих balances, що призводить до помилки у розрахунку D.

Джерело втрати точності

Операція масштабування:

Як показано вище, при використанні _upscaleArray, якщо баланс дуже малий (наприклад, 8-9 wei), округлення вниз через mulDown призводить до значної втрати точності.

Детальний опис процесу атаки

Етап 1: Налаштування на межу округлення

Етап 2: Виклик втрати точності (основна вразливість)

Етап 3: Отримання прибутку за рахунок заниженої ціни BPT

Як показано вище, атакуючий за допомогою Batch Swap виконує кілька обмінів в одній транзакції:

1. Перший обмін: BPT → cbETH (налаштування балансу)

2. Другий обмін: wstETH (8) → cbETH (виклик втрати точності)

3. Третій обмін: базовий актив → BPT (отримання прибутку)

Усі ці обміни відбуваються в межах однієї batch swap транзакції, спільно використовуючи один і той самий стан балансу, але кожен обмін викликає _upscaleArray для зміни масиву balances.

Відсутність механізму Callback

Основний процес ініціюється Vault. Як це призводить до накопичення втрати точності? Відповідь — у механізмі передачі масиву balances.

Аналізуючи наведений вище код, хоча при кожному виклику onSwap Vault створює новий масив currentBalances, у Batch Swap:

1. Після першого обміну баланс оновлюється (але через втрату точності оновлене значення може бути неточним)

2. Другий обмін розраховується на основі результату першого

3. Втрата точності накопичується, що зрештою призводить до значного зменшення інваріанту D

Ключова проблема:

Висновок

Атаку на Balancer можна підсумувати наступними причинами:

1. Функція масштабування використовує округлення вниз: _upscaleArray використовує mulDown для масштабування, і коли баланс дуже малий (наприклад, 8-9 wei), виникає значна відносна втрата точності.

2. Розрахунок інваріанту чутливий до точності: Розрахунок інваріанту D залежить від масштабованого масиву balances, і втрата точності безпосередньо впливає на розрахунок D, зменшуючи його.

3. Відсутність перевірки зміни інваріанту: Під час обміну не перевіряється, чи зміна інваріанту D знаходиться у розумних межах, що дозволяє атакуючому неодноразово використовувати втрату точності для заниження ціни BPT.

4. Накопичення втрати точності у Batch Swap: У межах однієї batch swap транзакції втрата точності від кількох обмінів накопичується, що зрештою призводить до величезних фінансових втрат.

Ці дві проблеми — втрата точності + відсутність перевірки — у поєднанні з ретельно спланованими граничними умовами з боку атакуючого призвели до цієї втрати.