Технический анализ: взлом 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 потеря точности от нескольких обменов накапливается и в конечном итоге приводит к значительным финансовым потерям.

Эти две проблемы — потеря точности и отсутствие проверки — в сочетании с тщательным подбором граничных условий злоумышленником привели к этим потерям.