Смарт-контракты пишутся быстрее, чем их успевают нормально проверять. Ошибки при этом каждый раз разные – от простых просчетов в логике до сложных сценариев с оракулами и внешними протоколами. Разбор каждого инцидента занимает время, а их становится все больше и больше. В какой-то момент проблема сводится уже не к сложности, а к объему: ручной аудит не успевает покрывать все, что появляется.
Автор: Александр Подобных, руководитель отдела аналитики и крипторасследований VeroTrace, руководитель комитета по безопасности цифровых активов и противодействию мошенничеству АРСИБ, судебный эксперт (компьютерно-техническая и экономическая экспертиза), член СРО АСЭ “Центр судебной экспертизы”
По данным аналитической платформы DeFiLlama, которая отслеживает крупные инциденты в Web3, с 2018 г. совокупные потери превысили $15,8 млрд. Из них более $7,1 млрд пришлось на взломы DeFi-протоколов и около $2,9 млрд – на атаки на кроссчейн-мосты. При этом инциденты отличаются не только масштабом, но и природой уязвимостей – от ошибок в расчетах внутри контракта до некорректных параметров внешних зависимостей.
Март 2026 г. подарил нам несколько характерных примеров. dTRINITY dLEND потерял $257 тыс. в результате атаки на инфляцию депозита (манипуляция коэффициентом начисления долей при внесении средств, позволившая увеличить баланс без эквивалентного ввода ликвидности). Venus Core Pool – минус $3,7 млн, уязвимость в механике пожертвований (некорректная обработка донатов в пул, влияющая на расчет долей участников). Goose Finance – $8,4 тыс., ошибка в учете акций (расхождение между внутренним учетом долей и фактическим балансом активов).
Есть и более сложные кейсы. Aave V3 потерял $27,78 млн из-за параметров оракулов CAPO (некорректная настройка источника цен, позволившая использовать искаженные данные для расчета залога и заимствований). SolvBTC – $2,7 млн, ошибка в логике резерва минта (некорректная проверка обеспеченности при выпуске токенов). Molt EVM – $127 тыс., уязвимость в модификаторе владельца (ошибка в проверке прав доступа, позволившая выполнить привилегированную функцию).
Полагаю, примеров достаточно. Обратите внимание, что уязвимости в них затрагивают разные уровни – от арифметики внутри контракта до зависимости от внешних данных. Часть ошибок локальна, часть проявляется только при определенных сценариях взаимодействия с другими компонентами.
Очевидно, что смарт-контакты надо изучать и проверять перед запуском.
Ручной аудит смарт-контрактов
Ручной аудит смарт-контрактов – это последовательная проверка кода и логики протокола перед его развертыванием. Основная задача – найти уязвимости, которые могут привести к потере средств, нарушению логики работы или получению несанкционированного доступа. Аудит выполняется разработчиками или специалистами по безопасности и опирается на разбор кода, сценариев его использования и возможных атак.
Работа обычно начинается не с кода, а с документации. Аудитору важно понять, как именно должен работать контракт: какие роли предусмотрены, как рассчитываются балансы, при каких условиях возможны изменения состояния. Без этого дальнейший анализ теряет смысл – ошибки часто возникают не в синтаксисе, а в расхождении между задуманной и реализованной логикой.
Далее идет статический анализ. Проверяется структура кода, типы переменных, корректность проверок входных данных, обработка исключений. На этом этапе находят типовые проблемы: отсутствие require-проверок (базовых условий, ограничивающих выполнение функции, например проверок баланса или прав доступа), небезопасные внешние вызовы, ошибки в арифметике, потенциальные переполнения или некорректные условия перехода состояния.
После этого контракт прогоняется вручную по типовым и граничным сценариям использования. Проверяются функции: как меняются балансы, корректно ли учитываются доли, что происходит при граничных значениях. Отдельно смотрят последовательности вызовов – многие ошибки проявляются не в одной функции, а в их комбинации.
Параллельно разбираются возможные векторы атак. Проверяется устойчивость к Reentrancy (повторный вход в функцию до завершения предыдущего вызова), Race Condition (зависимость результата от порядка транзакций), манипуляции с ценами через оракулы, переполнения и другие типовые сценарии. Особое внимание к операциям с токенами и управлению правами: именно здесь чаще всего возникают критические последствия.
Далее проверка эффективности. Анализируется расход газа: лишние записи в Storage, избыточные вычисления, неэффективные циклы. Это не всегда напрямую влияет на безопасность, но критично для эксплуатации протокола.
Результат аудита оформляется в отчет: перечень найденных уязвимостей, уровень критичности, описание сценария эксплуатации и рекомендации по исправлению. В хороших отчетах отдельно указывается, какие допущения сделаны при анализе и какие части системы не покрыты проверкой.
Чем сложнее протокол и чем больше внешних зависимостей, тем сильнее растет объем ручной работы. В какой-то момент основной проблемой становится именно масштаб, а не сложность отдельных уязвимостей.
Аудит смарт-контрактов с помощью ИИ
Аудит с использованием ИИ – это не отдельный класс инструментов, а продолжение того же процесса, что и ручная проверка. Меняется не цель, а способ работы с объемом. Когда контрактов и их связей становится слишком много, часть задач проще автоматизировать, чем разбирать вручную. Речь прежде всего о первичном анализе и поиске повторяющихся паттернов.
В основе таких систем – обучающие выборки. Используются как уязвимые контракты, уже приведшие к инцидентам, так и проверенный код из библиотек вроде OpenZeppelin. К ним добавляются базы известных уязвимостей и результаты исследований. За счет этого модель видит не только ошибки, но и нормальные реализации, с которыми можно сравнивать.
Сам анализ начинается со статического разбора кода, но дальше появляются отличия. Вместо набора фиксированных правил система сопоставляет фрагменты кода с уже известными сценариями и ищет комбинации условий, которые могут привести к уязвимости.
Следующий уровень – перебор состояний. За счет символьного выполнения проверяются разные варианты поведения контракта без подстановки конкретных значений. Это позволяет дойти до тех веток логики, которые обычными тестами не покрываются. В результате появляются сценарии, которые вручную пришлось бы специально моделировать.
Поверх этого добавляется слой машинного обучения, который анализирует уже найденные результаты. Он не столько ищет уязвимости, сколько помогает отделить реальные проблемы от шумовых срабатываний и расставить приоритеты. В некоторых случаях система может предложить и сам сценарий эксплуатации – не просто указать на ошибку, а показать, как она используется на практике.
Иногда на этом не останавливаются. Отдельные инструменты пытаются воспроизвести атаку и сгенерировать PoC-эксплойт – минимальный сценарий, подтверждающий уязвимость. Это сразу переводит результат из категории "подозрение" в категорию "доказанный риск".
Дальше результаты проходят дополнительную проверку через симуляции или формальную верификацию. И уже после этого формируется отчет: список проблем, их критичность, описание сценариев и рекомендации.
Но на этом работа не заканчивается. Часть находок требует ручной проверки – особенно там, где затронута бизнес-логика или сложные зависимости. ИИ может указать на проблему, но не всегда корректно оценивает ее последствия в реальной модели протокола.
Но все же новые типы атак, экономические сценарии, взаимодействие с внешними протоколами по-прежнему требуют ручного разбора. Поэтому ИИ встраивается в процесс как инструмент раннего обнаружения и приоритизации, но не как замена эксперта.
Эксперимент с ИИ-агентами
Компания Anthropic провела серию тестов, в которых ИИ-агенты искали и эксплуатировали уязвимости в смарт-контрактах. Речь шла не о теоретическом анализе, а о попытке воспроизвести атаку в среде, имитирующей блокчейн. Реальные средства не использовались, но сценарии были максимально приближены к рабочим.
В эксперименте участвовало 10 моделей, включая Opus, Sonnet, GPT-5 и DeepSeek. Их проверяли на контрактах с уже известными уязвимостями – всего 405 экземпляров, развернутых в 2020–2025 гг. в сетях Ethereum, BNB Smart Chain и Base. В 207 случаях модели смогли довести атаку до результата (это 51,11%). В пересчете на деньги потенциальный ущерб составил бы около $550 млн.
Отдельно проверили более свежие контракты – 34 проекта, запущенные после 1 марта 2025 г., уже после обновления моделей. Здесь доля успешных атак оказалась выше: 19 из 34, то есть 55,8%. Оценка ущерба – $4,6 млн. В отчете эти значения прямо рассматриваются как нижняя граница: речь идет только о том, что модели смогли воспроизвести в рамках теста.
Есть и обратный пример. Две модели проанализировали 2849 контрактов, в которых на момент проверки ранее не выявлялись уязвимости. Были найдены две уязвимости с потенциальным ущербом около $3,7 тыс. Хорошая иллюстрация тезиса, что ИИ пока лучше работает по известным или близким по структуре сценариям, чем по полностью новым.
Разброс результатов между моделями тоже заметен. В одном и том же сценарии GPT-5 смог бы вывести до $1,12 млн из протокола, тогда как Opus – до $3,5 млн. Речь идет о потенциальном объеме средств, доступных через найденную уязвимость. Разница не только в нахождении уязвимости, но и в том, как именно строится эксплуатация.
При этом динамика достаточно быстрая. По оценкам исследователей, доходность тестовых атак за последний год удваивалась примерно каждые 1,3 месяца. Речь не про качество модели в целом, а про конкретную способность находить и реализовывать уязвимости.
Практический вывод здесь не в том, что ИИ может взламывать (это само собой разумеется). Важнее другое – стоимость такого поиска снижается. Проверка контрактов становится задачей, которую можно масштабировать, а не разбирать вручную по одному кейсу. А значит по мере удешевления таких инструментов злоумышленники будут использовать их для перебора любых контрактов, где есть доступ к ликвидности. Сложность кода перестает быть барьером.
При этом сами исследователи делают зеркальный вывод. Те же агенты, которые находят и эксплуатируют уязвимости, могут использоваться и для их устранения. Вопрос не в инструменте, а в том, на какой стороне он применяется.
Ограничения и вызовы
При всех возможностях ИИ у него остаются вполне практические ограничения. Одно из них – объем контекста. Даже при работе с длинными входными данными модель не всегда может охватить весь проект целиком: часть логики оказывается за пределами анализа. В случае сложных протоколов с десятками взаимосвязанных контрактов это начинает влиять на результат – уязвимость может находиться не в одном файле, а в их комбинации.
Вторая проблема – зависимость от обучающих данных. Модели хорошо находят то, что уже встречалось: известные паттерны, типовые ошибки, повторяющиеся конструкции. Но при попытке выйти за пределы этих сценариев точность падает.
Есть и вопрос прозрачности. В ряде случаев сложно понять, почему модель посчитала тот или иной участок кода уязвимым или, наоборот, безопасным. Это затрудняет валидацию результатов и делает аудит менее воспроизводимым – особенно если речь идет о критичных решениях.
Есть и концептуальное ограничение – бизнес-логика. ИИ может разобрать код, но не всегда корректно интерпретирует, что именно хотел реализовать разработчик и как это должно работать в реальной экономике протокола. Ошибки в механике начисления, управлении ликвидностью или взаимодействии с другими сервисами часто лежат вне чисто технического анализа.
Поэтому на практике ИИ не заменяет аудитора, а, как и в большинстве других сфер, только меняет распределение работы. Он берет на себя перебор, поиск и первичную фильтрацию, а человеку остается проверка логики, оценка рисков и разбор нетиповых сценариев.
Нагрузка на аудит будет только расти. Количество смарт-контрактов увеличивается, появляются новые сервисы, усиливается связность между протоколами. В ближайшие годы к этому добавятся и регулируемые инфраструктуры – в том числе локальные биржи и обменники.
Увы, разрыв между возможностями атаки и защиты будет увеличиваться. ИИ позволяет быстрее находить и проверять уязвимости, и этот инструмент используется с обеих сторон. И вопрос уже не в том, использовать ли ИИ в аудите, а в том, кто успеет встроить его в процесс раньше.