Как эксплойт Notional Finance V1 обнулил долг на 2^128

Предполагаемый инцидент в Notional Finance не похож на обычную ситуацию, когда залог просто перестаёт покрывать долг. Согласно публичной реконструкции, проблема заключалась в ошибке учёта: огромный долг в fCash был создан на границе 2^128, а затем при расчёте свободного обеспечения оказался равен нулю из-за сужающего преобразования к uint128. Если обязательство в ключевой точке проверки учитывается как нулевое, кошелёк может выглядеть платёжеспособным и получить доступ к активам, которые не должен был иметь возможности вывести. 416

Важно: эта картина основана на ончейн-наблюдениях и сообщениях исследователей безопасности, а не на опубликованном техническом отчёте Notional. Перемещения средств видны в блокчейне, но окончательная последовательность вызовов, полный масштаб ущерба и сведения об устранении проблемы на момент публикаций подтверждены не были. 34

Как огромный долг исчез в расчёте

В Notional V1 будущие денежные обязательства представлялись токенами fCash. По данным публичного оповещения CertiK, атакующий выполнил два вызова mintfCashPair(), чтобы сформировать обязательство -2^128. В процессе оценки свободного обеспечения это значение, как утверждается, небезопасно преобразовывалось к uint128 и в результате усекалось до 0. 16

Описанный исследователями сценарий выглядел так:

1. Создание экстремальной отрицательной позиции fCash. Было сформировано обязательство именно такого размера, при котором сужение типа до 128-битного беззнакового целого могло отбросить представление долга. 416
2. Запуск оценки обеспечения. В учёте эскроу-контракта обязательство, по сообщениям, проходило через небезопасное понижающее преобразование к uint128.
3. Обнуление долга при проверке. Вместо гигантского отрицательного обязательства расчёт видел нулевое значение. 46
4. Прохождение условия на вывод. Поскольку долг не учитывался в расчёте свободного обеспечения, аккаунт мог выглядеть соответствующим условиям для вывода ликвидных стейблкоинов из эскроу. 46

Поэтому корректнее говорить не просто об «целочисленном переполнении», а о сбое инвариантов учёта из-за сужающего преобразования типов. Ключевой эффект, о котором сообщили исследователи, состоял в том, что отрицательное обязательство стало нулём именно в расчёте, призванном не допустить вывод средств при недостаточном обеспечении. 416

Какие средства, предположительно, вывели

Ончейн-отчёты оценивали вывод примерно в 69 257 DAI и 1 650 824 USDC, или около 1,728 млн долларов. Далее эти активы, как сообщалось, обменяли примерно на 689,2 ETH и внесли в Tornado Cash. 215

В публикациях фигурировал эскроу-контракт Notional Finance по адресу 0x9abd0b8868546105F6F48298eaDC1D9c82f7f683. По данным одного из отчётов, транзакция подготовки с адреса, оканчивающегося на Ce38, была отправлена 3 сентября 2026 года в 23:58:47 UTC; примерно через три минуты, уже 4 сентября, последовала транзакция вывода. 1723

Исследователи публично связали с перемещением активов два Ethereum-адреса:

• 0xC954…De69;
• 0xDaCC…Ce38.

Это ончейн-атрибуция исследователей, а не установленная личность человека, организации или конечного владельца адресов. 11

Почему маршрут через ETH усложнил возврат

Обмен DAI и USDC на ETH изменил ситуацию с потенциальным отслеживанием и возвратом. Переводы стейблкоинов изначально прослеживались в сети Ethereum, но после конвертации средства оказались в ETH. Последующие депозиты в Tornado Cash добавили уровень приватности, предназначенный для запутывания связи между источником, получателем и контрагентами транзакций. 229

Это не означает, что блокчейн-анализ становится невозможным, и не доказывает, кто контролировал возможный последующий вывод. Однако после попадания средств в миксер прямую связь между скомпрометированным эскроу-контрактом и последующим получателем установить заметно сложнее. 29

Что оставалось неизвестным

На момент публикаций Notional не выпускал публичного ответа об инциденте. Поэтому оставались открытыми существенные вопросы:

• окончательная техническая первопричина и полная последовательность вызовов при атаке;
• охватывали ли выявленные транзакции все затронутые контракты, аккаунты и активы;
• окончательный размер ущерба с учётом обменов, комиссий и дальнейших переводов;
• были ли доступны механизмы паузы, обновления, компенсации или возврата активов;
• личность атакующего и находились ли оба помеченных адреса под единым контролем. 3411

Таким образом, заявленную причину следует рассматривать как убедительную предварительную реконструкцию, но не как замену аудированному постмортему или официальному отчёту проекта.

Урок для старых DeFi-контрактов

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

Для команд протоколов этот случай подчёркивает необходимость проверять сразу несколько защитных мер:

• применять проверяемые сужающие преобразования и явно отклонять значения, которые нельзя безопасно представить в целевом типе;
• тестировать расчёты знакового долга, расчётов по обязательствам и обеспечения на числовых границах, включая 2^128;
• формализовать правила платёжеспособности и сохранения баланса как инварианты и проверять их на последовательностях из нескольких вызовов;
• анализировать, могут ли необычные или привилегированные маршруты вызовов сочетать выпуск, расчёт и вывод в непредусмотренном порядке;
• ограничивать круг вызывающих сторон и сценарии вызовов там, где функция опасна вне ожидаемого контекста.

Для DeFi это знакомая схема: небольшой дефект в представлении данных или авторизации превращается в полный вывод ликвидности, когда достигает маршрута вывода средств. Защита требует не только аудита отдельных функций, но и доказательства того, что инварианты учёта сохраняются при любой достижимой последовательности вызовов.