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