Технічний аналіз: злам Balancer на $120M, у чому полягала вразливість?

Original Article Title: " Balancer $120M Hack Vulnerability Technical Analysis"
Original Source: ExVul Security

Передмова

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

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

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

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

Використана транзакція:

https://etherscan.io/tx/0x6ed07db1a9fe5c0794d44cd36081d6a6df103fab868cdd75d581e3bd23bc9742

Транзакція переказу активів:

https://etherscan.io/tx/0xd155207261712c35fa3d472ed1e51bfcd816e616dd4f517fa5959836f5b48569

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

Вектор атаки

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

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

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

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

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

Аналіз схеми атаки

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

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

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

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

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

Корінна причина втрати точності

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

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

Деталізація процесу атаки

Фаза 1: Налаштування до межі округлення

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

Фаза 3: Використання заниженої ціни BPT для отримання прибутку

Вище атакуючий використовує Batch Swap для здійснення кількох обмінів в одній транзакції:

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

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

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

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

Відсутність механізму зворотного виклику

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

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

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

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

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

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

Підсумок

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

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

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

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

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

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