AI-генерация смарт-контрактов на Solidity: безопасность и скорость

AI-генерация смарт-контрактов: где ломается процесс

Модель уверенно выдаёт код, он компилируется, а заглушечные тесты проходят — и именно поэтому сбой выглядит безобидно. AI-генерация смарт-контрактов смещает ошибки из синтаксиса в семантику: опечатку компилятор поймает, а вот порядок проверок и права на вывод средств он не анализирует.

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

Вторая группа — права доступа и внешние вызовы. Функция вывода остаётся публичной без модификатора, инициализация вызывается повторно, внешний контракт получает управление до фиксации состояния. Такая уязвимость контракта сборку не ломает, зато даёт готовый сценарий вывода средств.

Отдельная цена — развёртывание без проверки. Скомпилированный контракт на Solidity неизменяем: неверный порог или адрес получателя не исправить обновлением, нужна миграция состояния и перевыпуск адресов у всех, кто уже взаимодействует с контрактом.

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

Скорость генерации против цены ошибки в логике

Генерация по формализованному описанию сжимает выпуск первой версии контракта и правки к ней. Каркас — роли доступа, события, проверки входных аргументов, разбор состояния — собирается за один проход, а изменение правила приводит к согласованному обновлению связанных мест, а не к ручной правке в пяти функциях.

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

Бюджет времени стоит делить осознанно: генерация закрывает выпуск и правки, а вложения идут в инварианты, тесты на отказ и проверку перед развёртыванием. Прогон на тестовой сети с теми же параметрами, что в основной, обязателен — сэкономленное на генерации нельзя возвращать из проверки.

Режимы создания контрактов: ручной, шаблонный, генеративный

Режим создания контракта определяет не скорость написания кода, а объём внимания, который остаётся на проверку логики. Ручная разработка контракта даёт полный контроль над структурой хранения и порядком вызовов — это обязательно там, где ошибка в одной ветке условия приводит к потере средств. Шаблонные контракты фиксируют уже проверенную схему: выпуск токенов, роли, пауза, ограничения на вывод. Остаётся заполнить параметры и не изобретать модель прав заново.

Генеративный режим ускоряет черновик, но не заменяет проверку. Модель собирает каркас и обвязку под конкретную задачу, а инженер построчно сверяет арифметику, права и внешние вызовы: непроверенный код не попадает в скрипт развёртывания.

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

Этапы работы: от разбора задачи до передачи в эксплуатацию

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

1. Разбор требований и схема состояний. Фиксируем роли, переходы и инварианты: что контракт разрешает, а что запрещает всегда. Схема согласуется до написания кода — позже её правка обходится дороже.
2. Генерация черновика. Модель собирает структуру контракта на Solidity по согласованной схеме: хранилище, функции, события. Ограничения и стиль задаём заранее, чтобы код было легко сопровождать.
3. Проверки безопасности. Статический анализ, тесты на граничные и случайные наборы данных, ручной разбор прав доступа и внешних вызовов. Каждая найденная проблема превращается в тест, который её больше не пропустит.
4. Прогон на тестовой сети. Воспроизводим реальные последовательности операций, включая ошибочные: откат транзакции, повторный вызов, недоступность внешнего сервиса.
5. Приёмка результата. Сверяем покрытие ключевых путей тестами и расхождение с исходными требованиями; отчёт с проверками уходит заказчику.
6. Передача в эксплуатацию. Развёртывание, фиксация параметров окружения, обучение команды заказчика запуску и наблюдению за работой контракта.
7. Регламент правок. Как вносится изменение, кто согласует, какие проверки обязательны перед повторным развёртыванием.

Артефакты проекта: спецификации, модели угроз, регламенты

После сдачи у команды заказчика остаётся комплект документов, по которому контракты можно развивать и сопровождать без нас. Это не папка с файлами, а связанный набор: спецификация задаёт поведение, модель угроз — границы доверия, регламент правок — порядок изменений.

Каждый артефакт сверяется с кодом при сдаче: если описание инвариантов расходится с логикой, работа не принимается. Ниже — что остаётся на руках.

• Спецификация контракта — роли, состояния и переходы, внешние вызовы и события: что контракт обязан делать и что запрещено.
• Описание инвариантов — условия, которые выполняются при любом сценарии, с привязкой к участкам кода и автотестам.
• Модель угроз — векторы атаки на конкретный контракт, оценка последствий и заложенные ограничения: лимиты, задержки вывода, пауза.
• Регламент правок — кто и как вносит изменения, какие проверки обязательны перед обновлением, как откатиться на предыдущую версию.
• Права доступа — карта ролей и ключей: у кого какие полномочия, где хранятся, как передаются и отзываются.
• Документация сопровождения — развёртывание, миграции состояния, отслеживание событий, типовые сбои и порядок действий.
• Отчёт по проверкам — что нашли при статическом анализе и ручном разборе, что закрыли, что осознанно оставили.

Комплект живёт вместе с кодом: правка тянет за собой обновление спецификации и модели угроз, иначе документация расходится с контрактом за пару недель.

Кейс: доля отказов в логике переводов снизилась втрое

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

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

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

Что изменилось

Доля инцидентов в логике переводов упала втрое: с девяти обращений за квартал до трёх, и все три — ошибки во входных данных, а не в коде. Выпуск нового контракта занимает часы вместо нескольких дней, а доля автоматически проверяемых путей выросла с 40 до 90%.

Лимиты заданы и на одну операцию, и на сутки, поэтому одна ошибка больше не выносит всю казну. Разбор идёт по журналу: видно, какая роль инициировала операцию, кто подтвердил и на каком шаге сработало ограничение; откат — пауза и повторный перевод, без правки и повторного развёртывания контракта.

Чем формальная проверка отличается от аудита кода?

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

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

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

Отсюда главный риск — ложное чувство безопасности. Отметка «формально верифицировано» не говорит, что спецификация верна, а пройденный аудит не гарантирует отсутствия ошибки в редком пути, который вручную не проигрывали.

Поэтому контур делим: инварианты ядра — учёт, права, лимиты — уходят в формальные модели, интеграции и админ-контуры закрываем аудитом с ручными сценариями. В отчёте отдельно перечисляем, что осталось недоказанным.

Частые технические сомнения перед стартом

Сомнения перед стартом почти всегда одни и те же: кто отвечает за ошибку в логике, что делать с уже развёрнутым контрактом, кому принадлежат права на результат и можно ли проверить код, не выкладывая его в открытый доступ. Ниже — прямые ответы, без оговорок в духе «зависит от задачи».

У нас уже развёрнут контракт — его можно доработать?

Да. Снимаем текущее состояние в сети, сверяем логику с фактическим поведением и предлагаем план: точечная правка, расширение через прокси или переразвёртывание с переносом накопленных записей и прав доступа.

Кому принадлежат права на код?

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

Можно ли проверить результат, не публикуя исходники?

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

Что входит в сопровождение после запуска?

Наблюдение за событиями контракта, реакция на инциденты, обновление зависимостей и правки по изменению требований. Отдельно фиксируем порядок дежурства и время реакции на обращение.

Обсудим задачу и вернёмся с оценкой и планом

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

• Роль контрактов в продукте: токен и распределение, эскроу, голосование, платный доступ — от этого зависит объём логики и глубина проверок.
• Целевая сеть и требования совместимости: нужны ли стандарты ERC-20, ERC-721 или ERC-1155, внешние вызовы к оракулам и мостам.
• Существующий код: текущие контракты, шаблоны и наработки — разберём и скажем, что переиспользуем, а что переписываем.
• Модель прав: кто выпускает, замораживает и обновляет контракт; нужны ли роли, пауза, мультиподпись и механизм обновления логики.
• Интеграции: кошельки, бэкенд, индексаторы и внешние сервисы, с которыми контракт обменивается данными.
• Ожидаемая нагрузка и чувствительность к стоимости транзакций — влияет на структуры данных и хранение состояния.
• Формат работы и сроки: разовая генерация с проверкой или сопровождение с доработками после запуска.

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

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