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