Сгенерированные ИИ смарт-контракты: в чём их польза, в чём недостатки и как безопасно их использовать.

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

Это различие важно, поскольку смарт-контракты могут хранить активы и обеспечивать необратимые изменения состояния. В рекомендациях по безопасности Ethereum, последнее обновление которых было 26 февраля 2026 года, подчеркивается, что развернутый код контракта сложно или невозможно напрямую модифицировать, и рекомендуется независимая проверка, тестирование, статический анализ, предупреждения компилятора, документирование и тщательный контроль доступа. Таким образом, текущие рекомендации по безопасности смарт-контрактов Ethereum остаются полезной базой даже при использовании искусственного интеллекта для создания кода.

Что изменилось с появлением разработки смарт-контрактов с использованием искусственного интеллекта?

Главное изменение — скорость. Теперь разработчик может описать систему депонирования, график распределения средств, правила создания NFT, систему ролей, контракт стейкинга или тестовый пример простым языком и получить правдоподобную реализацию за считанные секунды. Модели также могут объяснять незнакомый код, предлагать граничные случаи, генерировать модульные тесты, переводить между шаблонами фреймворков и помогать документировать интерфейсы.

Неизменным остается вопрос безопасности. В собственной документации Solidity по безопасности по-прежнему указывается, что контракты взаимодействуют с враждебными вызывающими механизмами, публичным состоянием, внешними контрактами, поведением компилятора и средами выполнения, что может привести к неожиданным результатам. В документах Solidity по вопросам безопасности по-прежнему подчеркиваются реентерабельность, риски внешних вызовов, публичная видимость состояния и важность таких шаблонов, как Checks-Effects-Interactions.

В препринте 2026 года под названием «Оценка уязвимостей смарт-контрактов, генерируемых LLM-системами» сообщается о повторяющихся серьезных недостатках в контрактах, созданных несколькими современными языковыми моделями. Поскольку это препринт, а не окончательный отраслевой стандарт, его точные выводы не следует рассматривать как универсальные показатели дефектов. Тем не менее, это полезное доказательство для практического вывода: синтаксически корректный и функционально полный результат работы ИИ не эквивалентен безопасности, готовой к внедрению в производство.

В каких областях ИИ приносит наибольшую пользу?

1. Быстрое прототипирование

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

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

2. Стандартные и общепризнанные нормы.

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

Здесь важен выбор библиотеки. OpenZeppelin описывает свой текущий пакет Contracts как библиотеку компонентов, проверенных сообществом, для стандартов, разрешений и многократно используемых строительных блоков смарт-контрактов. В документации также различаются проверенные стабильные релизы и релизы для разработки. См. документацию OpenZeppelin Contracts . Для многих производственных проектов попросить ИИ составить проверенные компоненты библиотеки безопаснее, чем просить его изобрести эквивалентные примитивы с нуля.

3. Помощь в создании и проверке тестов.

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

Ограничение заключается в том, что анализ на основе ИИ может пропустить именно те ошибки бизнес-логики, которые имеют наибольшее значение. Модель может распознать типичную реентрантность, но не понять, что экономическое предположение протокола, источник ценообразования, последовательность учета или переход управления неверны. Исследование, опубликованное в 2025 году, также показало, что обнаружение уязвимостей на основе LLM может страдать как от ложных срабатываний, так и от низкой полноты для некоторых современных классов уязвимостей Solidity. Это причина для объединения анализа на основе ИИ с тестами на основе выполнения, статическим анализом, фаззингом, инвариантами и экспертной оценкой, а не для их замены.

Какие риски безопасности являются наиболее важными?

В списке OWASP Smart Contract Top 10 за 2025 год перечислены уязвимости контроля доступа, манипуляции с ценовыми оракулами, логические ошибки, отсутствие проверки входных данных, реентрантность, непроверенные внешние вызовы, атаки с использованием мгновенных займов, арифметические проблемы, небезопасная случайность и отказ в обслуживании среди основных классов уязвимостей смарт-контрактов. Полный список доступен в проекте OWASP Smart Contract Security . Код, сгенерированный ИИ, может столкнуться с любой из этих категорий; отдельного исключения по безопасности нет, поскольку исходный код был создан моделью.

Действительно ли ИИ безопаснее, если он использует проверенные библиотеки?

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

Рассмотрим контроль доступа. OpenZeppelin отмечает, что контроль доступа определяет, кто может создавать, голосовать, замораживать переводы или выполнять другие конфиденциальные действия, и предоставляет как простые механизмы владения, так и более детализированные механизмы на основе ролей. В документации по контролю доступа четко указано, что выбор механизма должен соответствовать приложению. Искусственный интеллект может Ownableбыстро внедрить контракт, но протоколу с несколькими администраторами, отложенными операциями, чрезвычайными ролями и обязанностями управления может потребоваться более структурированная модель полномочий.

А что насчет контрактов с возможностью обновления?

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

В текущей документации по обновлению OpenZeppelin поясняется, что обновления на основе прокси сохраняют адрес и состояние прокси при переключении реализаций, и предупреждается, что структуру хранилища нельзя произвольно изменять. Это слабая сторона для генерации кода вслепую, поскольку код, который выглядит разумным сам по себе, может привести к повреждению состояния при использовании в качестве обновления. Если требуется возможность обновления, используйте инструменты, проверяющие совместимость хранилища, и привлеките рецензента, понимающего модель прокси.

Какой подход к разработке соответствует каким потребностям?

Как командам следует проверять контракты, сгенерированные искусственным интеллектом?

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

Далее, обработайте результат как код от нового участника, чья работа еще не прошла проверку. Скомпилируйте с помощью подходящего стабильного компилятора, устраните предупреждения, запустите модульные тесты, проведите фаззинг входных данных, проверьте инварианты, запустите инструменты статического анализа, проверьте внешние вызовы, проверьте права доступа и версии зависимостей. Текущие рекомендации Ethereum по безопасности прямо рекомендуют использовать систему контроля версий, проверять запросы на слияние (pull-request), проводить статический анализ, создавать сборки без предупреждений, документировать и проводить независимую проверку перед развертыванием.

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

В каких случаях сгенерированный ИИ код следует отклонять, а не исправлять?

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

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

Как вы понимаете, что ИИ улучшает процесс разработки?

Измеряйте результаты, которые имеют значение. Полезные показатели включают сокращение времени на создание проверенного кода, более широкое тестовое покрытие, выявление большего количества граничных случаев до развертывания, сокращение циклов проверки рутинной работы и улучшение документации. Не используйте «количество сгенерированных строк кода» или «время первой компиляции» в качестве основного показателя успеха; оба показателя могут улучшиться, в то время как качество безопасности ухудшится.

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

Итог

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

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