[Англоязычный длинный пост] Подробный разбор инцидента с атакой на Balancer V2: механизм уязвимости, этапы атаки и извлечённые уроки

Chainfeeds Введение:

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

Источник статьи:

Автор статьи:

BlockSec

Мнение:

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