Автор: Dmitry Volkov | Smart Contract Security Auditor | Партнёр в CertiK

На прошлой неделе разработчик попросил меня аудитировать DeFi-протокол. Основные контракты были написаны Claude. Не с помощью Claude — Claude'ом, с минимальным человеческим ревью. Разработчик гордился, что зашипил за две недели вместо двух месяцев.

Я нашёл 7 критических уязвимостей. Одна позволила бы слить весь протокол. Разработчик просил AI написать безопасный код. AI уверенно произвёл код, который выглядел безопасным, но не был таковым.

Это становится моей ежедневной реальностью. AI-генерируемые смарт-контракты повсюду. И мы не готовы к последствиям.

Привлекательность очевидна

Позвольте быть справедливым к разработчикам. Рост производительности реален.

Написание смарт-контрактов нудное. Шаблонный код, стандартные паттерны, повторяющиеся структуры. LLM может сгенерировать базовый ERC-20 токен за секунды. Скелет лендинг-протокола за минуты. То, что занимало недели кодинга, теперь занимает часы промптинга.

Код часто выглядит хорошо. Современные LLM поглотили миллионы примеров на Solidity. Они знают паттерны, конвенции, лучшие практики. Сгенерированный код компилируется, проходит базовые тесты и следует читаемому стилю.

Для прототипирования и обучения это реально ценно. Исследуй идеи быстро. Понимай паттерны. Итерируй быстро. AI-ассистенты для кодинга — легитимные инструменты.

Проблема начинается, когда прототипы становятся продакшном.

Что AI делает неправильно

После аудита десятков AI-генерируемых контрактов я каталогизировал паттерны отказов.

Reentrancy остаётся убийцей. LLM знают о reentrancy — они даже добавляют комментарии, предупреждающие об этом. Но они часто размещают обновления состояния после внешних вызовов всё равно. Код выглядит так, будто следует паттерну checks-effects-interactions. На самом деле не следует.

Контроль доступа несогласованный. AI может правильно защитить одну админ-функцию и забыть другую. Или имплементировать модификаторы, которые выглядят правильно, но имеют тонкие логические ошибки. Случайность — вот что делает это опасным — нельзя предсказать, какие функции уязвимы.

Обработка целых чисел предательская. Проблемы overflow до Solidity 0.8, потеря точности в вычислениях, ошибки округления, которые накапливаются — LLM делают эти ошибки уверенно. Они видели и правильные, и неправильные паттерны в обучающих данных; они не могут надёжно различить, какой есть какой.

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

Проблема уверенности

Вот что пугает меня больше всего: AI-генерируемый код — это уверенный код.

Когда джуниор-разработчик пишет небезопасный код, он часто выглядит небезопасным. Неряшливый, неуверенный, очевидно требует ревью. Ты знаешь, что нужно проверить его внимательно.

AI-генерируемый код выглядит профессионально. Чистое форматирование, правильные комментарии, стандартные паттерны. Он проецирует компетентность. Ревьюеры снижают бдительность. "Это выглядит так, будто написано опытным разработчиком."

Но AI не имеет реального понимания безопасности. Это pattern-matching, не рассуждение. Он не знает, почему определённые паттерны опасны. Он не может продумать векторы атак. Он производит код, который поверхностно напоминает безопасный код без лежащей в основе безопасности.

Результат: уязвимости, скрытые за лоском профессионализма.

Реальные примеры из моих аудитов

Позвольте поделиться обезличенными примерами из недавней работы.

Yield-агрегатор попросил Claude имплементировать защиту от flash loans. AI добавил модификатор, который проверял, пришла ли транзакция от контракта. Выглядит разумно — flash loans приходят от контрактов. Но это блокировало легитимных пользователей смарт-кошельков и ничего не делало против flash loans, которые маршрутизируются через EOA. Защита была бесполезна, но разработчик думал, что проблема решена.

Токен-контракту нужен был механизм паузы. GPT-4 имплементировал его идеально для трансферов. Но функция burn не была защищена. Во время аудита я продемонстрировал, что атакующий мог сжигать токены даже когда на паузе, манипулируя supply во время чрезвычайных ситуаций.

Governance-контракт требовал time-locked исполнения. AI имплементировал таймлок корректно, затем добавил функцию "fast-track для экстренных случаев" — без контроля доступа. Любой мог обойти таймлок, назвав это экстренным случаем.

В каждом случае разработчик явно просил безопасность. AI явно признавал требования. Код всё равно провалился.

Проблема аудита

Профессиональные аудиты должны ловить эти проблемы. Но AI-генерируемый код меняет ландшафт аудита тоже.

Объём взрывается. Больше разработчиков шипят больше кода быстрее. Аудиторские фирмы в бэклоге. Давление одобрить быстро увеличивается.

AI-генерируемый код сложнее аудитировать. У него нет человеческого следа рассуждений. Почему был выбран этот дизайн? Какие edge cases рассматривались? С human-written кодом часто можно вывести намерение из структуры. AI-код — чёрный ящик.

Некоторые аудиторы используют AI для аудита AI-кода. Это ужасает. Если AI не мог написать безопасный код, почему он надёжно идентифицирует небезопасный код? Те же ограничения pattern-matching применимы.

Наша фирма была вынуждена расширить таймлайны для AI-генерируемых контрактов. Мы ничего не предполагаем. Верифицируем всё. Это занимает дольше, не короче, чем аудит человеческого кода.

Что реально помогает

Я не говорю никогда не использовать AI для смарт-контрактов. Я говорю использовать правильно.

Используй AI для scaffolding, не для security-critical логики. Генерируй шаблонный код. Пиши ядро логики сам. Пусть AI обрабатывает скучные части, пока люди обрабатывают опасные части.

Ревьюй AI-код как untrusted код — потому что это untrusted код. Не позволяй профессиональному виду снижать твои стандарты. Предполагай, что каждая функция имеет баги, пока не докажешь обратное.

Формальная верификация становится важнее, не менее. Математические доказательства корректности не заботятся, был ли код человеческим или AI-генерируемым. Инвестируй в инструменты и техники верификации.

Тестируй adversarially. Не просто тестируй happy paths. Активно пытайся сломать код. Предполагай, что атакующие найдут всё, что ты пропустишь. Fuzz-тестирование, invariant-тестирование, симуляция сценариев атак.

Профессиональные аудиты остаются эссенциальными. Не AI-аудиты — человеческие аудиты опытными security-исследователями, которые понимают и технологию, и ландшафт угроз. Бюджетируй это. Не пропускай, потому что "AI написал безопасный код."

Куда это движется

AI-кодинг улучшится. Модели станут лучше в паттернах безопасности. Fine-tuning на аудитированных кодовых базах поможет. Появятся лучшие техники промптинга.

Но фундаментальная проблема остаётся: AI генерирует код без понимания последствий. Пока у нас нет AI, который может рассуждать о безопасности — не просто pattern-match к безопасно-выглядящему коду — человеческий oversight остаётся эссенциальным.

Мой прогноз на 2025: как минимум один крупный эксплойт — $50 миллионов+ — будет прослежен напрямую к AI-генерируемому коду, который прошёл человеческое ревью. Инцидент заставит индустрию отнестись к этому серьёзно.

Надеюсь, я ошибаюсь. Но я продолжаю находить критические уязвимости в AI-генерируемых контрактах, и эти контракты продолжают идти в продакшн. Математика не в нашу пользу.

Dmitry Volkov возглавляет аудиты безопасности смарт-контрактов в CertiK. Он идентифицировал уязвимости в протоколах с комбинированным TVL, превышающим $2 миллиарда, и ранее работал над безопасностью компиляторов в Google.