Прибыль:
- Способность использовать искусственный интеллект для создания фреймворков, тестов и проверки проектов на основе проверенных библиотек (например, OpenZeppelin) и понимать, что люди гарантируют безопасность производства.
- Возможность проверки версии кода, шаблона и контроля доступа, созданного искусственным интеллектом, посредством компиляции, тестирования и тестовой сети.
- Умение понять, что компиляция не означает безопасность и что тестовая сеть и аудит необходимы.
Написание смарт-контракта отличается от обычного программного обеспечения: код, который вы пишете, является общедоступным, неизменяемым и представляет собой программу, которая напрямую перемещает деньги. В этом модуле вы узнаете, как использовать ИИ в качестве помощника по разработке смарт-контрактов; Мы будем учиться от чернового варианта до написания тестов, от отзыва шаблонов до оптимизации газа (комиссии за транзакцию). Но давайте с самого начала проясним: ИИ создает чертежи; Люди обеспечивают безопасность кода, поступающего в производство.
Основа прежде всего: язык и окружающая среда
Самый распространенный язык смарт-контрактов — Solidity (язык Ethereum и EVM — Ethereum Virtual Machine, виртуальная машина, на которой выполняются контракты — совместимые цепочки). Альтернативой является Vyper (язык, похожий на Python, который призван быть более ограниченным и читабельным). Ваш код потребляет газ (стоимость каждой транзакции в блокчейне); Неэффективный код стоит дорого. Четкое соблюдение этих терминов в контексте, который вы передаете ИИ, является ключом к получению точных результатов.
Наибольшую ценность ИИ представляет не в том, чтобы «писать с нуля», а в создании основы + хорошей формы: соответствующего стандартам старта, плана, к которому можно добавить свой опыт.
Уровни использования ИИ в кодировании
1. Генерация скелетов. ИИ быстро добывает скелет стандартного токена (ERC-20) или NFT (ERC-721 — уникальный стандарт цифровых активов). Но обязательно заставьте ИИ использовать проверенную библиотеку: например, OpenZeppelin (доверенная, проверенная сообществом стандартная библиотека контрактов). Правило состоит в том, чтобы использовать проверенный блок, а не писать защиту с нуля.
2. Описание и обзор функций. Объяснение существующей функции ИИ позволяет заранее обнаружить логические ошибки.
3. Генерация тестов. ИИ хорошо генерирует тестовые примеры для крайних случаев: нулевой ввод, очень большое число, неавторизованный абонент, повторный вызов. Это напоминает один из сценариев, которые можно пропустить.
4. Газ и читаемость. ИИ отмечает дорогостоящие шаблоны, такие как ненужная запись в хранилище, и предлагает альтернативы.
Подсказка: поручите ИИ «опираясь на проверенные контракты OpenZeppelin, переписать безопасность с нуля». Для ИИ гораздо более рискованно писать оригинальный код безопасности, чем использовать протестированную библиотеку.
Слабая подсказка / Сильная подсказка
Слабая подсказка:
Напишите мне токен-контракт.
Эта подсказка опасна: непонятно, какой стандарт, какая цепочка, какая библиотека, какое требование безопасности. ИИ генерирует случайный, возможно, устаревший или небезопасный код.
Мощная подсказка:
Ваша роль: старший разработчик Solidity. Создайте черновик токена ERC-20 для цепочки, совместимой с EVM. Правила: - На основе проверенных OpenZeppelin контрактов ERC20 и Ownable. - Явно укажите версию и лицензию Solidity (SPDX). - Только владелец имеет разрешение на выпуск; добавьте колпачок против бесконечного нажатия. - Добавьте комментарий NatSpec к каждой функции. - Написание безопасности с нуля; Используйте стандартный блок. - Добавьте предупреждение в конце: «Это черновик; требуется аудит и тестирование». Отметьте области, в которых вы не уверены, с помощью // TODO.
Разница: строгая подсказка дает четкую информацию о роли, стандарте, библиотеке, границах безопасности, документации и ожиданиях проверки.
Четыре копируемых шаблона
1) Скелет на основе стандартов:
Ваша роль: Разработчик Solidity. Создайте структуру контрактов [ERC-20 / ERC-721 / стейкинг] на основе проверенной библиотеки OpenZeppelin. Напишите лицензию SPDX и версию прагмы. Добавьте контроль доступа (кто может звонить) к каждой внешней функции. Новое изобретение безопасности; Используйте стандартные блоки. Это черновик.
2) Обзор функций:
Изучите следующую функцию как старший разработчик: что она делает, какие состояния меняет, кто может ее вызывать? Отметьте возможные логические ошибки и риски безопасности как ГИПОТЕЗУ, связав каждую из них со строкой кода. Не говорите прямо «безопасно»; просто перечислите моменты, на которые стоит обратить внимание.
3) Проект сценария тестирования:
Предложите тестовые примеры для этого контракта (может быть черновик для Foundry/Hardhat). В частности, охватить предельные случаи: нулевой ввод, очень большое количество, несанкционированный вызов, повторный вызов, недостаточно средств. Напишите, ЧТО подтверждает каждый тест.
4) Проверка газа и читаемости:
В этом контракте отметьте закономерности, которые могут снизить стоимость газа: ненужная запись в хранилище, внешний вызов в цикле, повторяющиеся вычисления. Объясните разницу до и после в каждом предложении. Рекомендовать оптимизации, нарушающие безопасность; Если неясно, скажите «спросите одитора».
Три мини-кейса (в цифрах)
Случай 1 — Скелет сэкономил 4 часа. Одна команда разработала скелет проверенного библиотечного контракта с ИИ за 30 минут; Вручную это заняло ~4 часа. Команда посвятила время безопасности и тестированию. Выигрыш произошел не от переноса безопасности, а от ускорения утомительной структуры.
Случай 2 — ловушка устаревшей версии. ИИ создал шаблон, который отправляет необработанный эфир путем передачи, что больше не рекомендуется, поскольку данные обучения устарели. Разработчик заметил это и изменил его на текущий шаблон на основе вызовов и с защитой от повторного входа. Урок: всегда подтверждается актуальность библиотеки/шаблона ИИ; ИИ ничего не знает после даты окончания обучения.
Случай 3. В тестовом проекте обнаружена скрытая ошибка. Тест «несанкционированного звонящего», проведенный ИИ, показал, что разработчик забыл контроль доступа в функции. onlyOwner отсутствует 1 строка, обнаружена за 5 минут в тестовой сети; В основной сети могла произойти потеря средств. Урок: ИИ закрывает слепое пятно человека при тестировании.
Запоминание шаблонов безопасности с помощью ИИ
ИИ хорошо напоминает вам об известных шаблонах уязвимостей, например, в виде контрольного списка. Наиболее распространенные узоры:
- Повторный вход: выполнение внешнего вызова без обновления статуса. Решение: порядок проверок-эффектов-взаимодействий, защита повторного входа.
- Отсутствие контроля доступа: любой может вызвать критически важную функцию.
- Целочисленное переполнение/недополнение: Modern Solidity улавливает большинство из них, но все же остается риск в низкоуровневом коде.
- Неадекватная проверка ввода: нулевой адрес, нулевой контроль количества.
- Зависимость от Oracle: слепое доверие к внешним данным (например, цене).
Внимание: ИИ может вспомнить этот список, но не может гарантировать, находится ли элемент в списке в вашем конкретном коде. Контрольный список — это начало; Это не замена контролю контейнеров.
Правильный контекст: секрет хорошего кода с помощью ИИ
Качество кода, который создает ИИ, напрямую зависит от качества контекста, который вы ему предоставляете. В Web3 это особенно важно, поскольку одна маленькая деталь (какая цепочка, какая версия Solidity, какой стандарт токена) меняет весь вывод. Хороший контекст включает в себя:
- Целевая цепочка и среда: основная сеть Ethereum или уровень 2 (более дешевый сайдчейн, работающий поверх основной цепи)? Стоимость газа и некоторые функции различаются в зависимости от сети.
- Версия и библиотека: какая версия Solidity, какая версия OpenZeppelin? Если версия не указана, ИИ может создавать устаревшие, нерекомендуемые шаблоны.
- Требования безопасности: есть ли ограничение, можно ли его приостановить, можно ли увеличить? Об этом следует сказать с самого начала.
- Ограничения: четкие ограничения, такие как «не использовать ассемблер», «избегать внешнего вызова», «оптимизировать газ, но сохранять читаемость».
Еще один мощный метод — сначала запросить у ИИ план, а затем код: «Сначала перечислите функции этого контракта и то, что каждая из них будет делать; напишите код, как только я его одобрю». Это заранее улавливает движение ИИ в неправильном направлении и позволяет сохранить архитектурное решение.
Подсказка: спросите ИИ «почему вы так написали этот код?» просить. Объяснение обоснования не только ускорит ваше обучение, но и выявит любые логические ошибки (например, ложное предположение о безопасности). Не доверяйте выводам ИИ, который не может защитить свой собственный код.
Распространенные ошибки
- Внедрение безопасности в ИИ с нуля. Используйте проверенную библиотеку.
- Не подтверждение версии/шаблона, созданного ИИ. Данные обучения могут быть устаревшими.
- Обход тестнета. Прежде чем выйти в свет, каждый черновик должен быть запущен в тестовой сети.
- Не добавляя NatSpec/документацию. Осмотр и обслуживание становятся затруднительными.
- Заблуждение «Он скомпилирован, значит, безопасен». Быть скомпилированным не означает быть в безопасности.
- Забыв про контроль доступа. Это одна из самых распространенных и дорогостоящих ошибок.
В заключение
- При написании смарт-контрактов ИИ создает структуры, тесты и проверяет черновики; Человек гарантирует безопасность производства.
- Стройте безопасность не с нуля, а на основе проверенных библиотек (например, OpenZeppelin).
- Актуальность версий и моделей, выпускаемых YZ, всегда подтверждается.
- Тестовые заглушки полезны для выявления «слепых зон» человека (предельные случаи, контроль доступа).
- Быть скомпилированным не означает быть в безопасности; тестовая сеть и аудит обязательны.
Задача приложения
Для простого токена ERC-20 создайте черновик, используя приведенную выше подсказку «скелет на основе стандартов». Затем: (1) проверьте, использует ли она проверенную библиотеку, (2) проверьте элементы управления доступом, (3) сгенерируйте тесты с приглашением «черновик тестового набора» и фактически запустите хотя бы один тест на мошеннического вызывающего абонента. Найдите и отметьте хотя бы одну точку безопасности, которую пропустил ИИ.
контрольный список
- [ ] Я четко указал стандарт и цепочку в подсказке.
- [ ] Мне хотелось проверенного производства на основе библиотеки.
- [ ] Доступна лицензия SPDX и версия прагмы.
- [ ] Для каждой важной функции предусмотрен контроль доступа.
- [ ] Я создал и запустил тесты для предельных случаев.
- [ ] Я подтвердил, что библиотека/шаблон обновлены.
- [ ] Я пометил код для аудита и тестирования; Я не получил это без присмотра в основной сети.