AI-генерація смарт-контрактів: де ламається процес
Модель упевнено видає код, він компілюється, а заглушкові тести проходять — і саме тому збій виглядає нешкідливо.
AI-генерація смарт-контрактів зміщує помилки із синтаксису в семантику: одруківку компілятор зловить, а от порядок перевірок і права на виведення коштів він не аналізує.
Найчастіша група — помилки у згенерованому коді навколо переказів. Відправлення коштів стоїть раніше оновлення балансів, повернене значення низькорівневого виклику ігнорується, десяткові знаки токена й комісія не враховуються.
Перевірка логіки переказів на копії основної мережі з реальними балансами викриває це за хвилини — якщо така перевірка взагалі передбачена.
Друга група — права доступу та зовнішні виклики. Функція виведення залишається публічною без модифікатора, ініціалізація викликається повторно, зовнішній контракт отримує управління до фіксації стану. Така уразливість контракту збірку не ламає, зате дає готовий сценарій виведення коштів.
Окрема ціна — розгортання без перевірки. Скомпільований контракт на Solidity незмінний: неправильний поріг або адресу отримувача не виправити оновленням, потрібна міграція стану й перевипуск адрес у всіх, хто вже взаємодіє з контрактом.
Тому генерацію ми тримаємо як чернетку, а не як реліз: далі йдуть ручний розбір прав, порядок перевірок, автоматичний перебір вхідних даних і симуляція атак на копії мережі. Нижче — як це закривається крок за кроком.
Швидкість генерації проти ціни помилки в логіці
Генерація за формалізованим описом стискає випуск першої версії контракту та правки до неї.
Каркас — ролі доступу, події, перевірки вхідних аргументів, розбір стану — збирається за один прохід, а зміна правила призводить до узгодженого оновлення пов’язаних місць, а не до ручної правки в п’яти функціях.
Найшвидше зникають механічні класи помилок: пропущена перевірка на нульову адресу, неправильний порядок операцій, забутий перехід стану. Найдорожче те, чого генерація не бачить: економічна логіка, порядок зовнішніх викликів, інваріанти стану під конкуруючими транзакціями.
Їх формулюють вручну й перевіряють прогонами властивостей на випадкових входах — Echidna підбирає їх сам і ламає контракт там, де приклади не додумали.
| Що перевіряємо | Чим закриваємо | Що залишається на рев'ю |
|---|---|---|
| Синтаксис, порядок перевірок, обмеження доступу | Генерація за шаблоном і статичний розбір | Модель ролей і межі довіри |
| Інваріанти стану, цілісність балансів | Прогони властивостей на випадкових входах | Формулювання самих інваріантів |
| Економічна логіка, повторний вхід, відкат транзакцій | Ручні сценарії та тести на відмову | Модель загроз |
Бюджет часу варто ділити усвідомлено: генерація закриває випуск і правки, а вкладення йдуть в інваріанти, тести на відмову та перевірку перед розгортанням.
Прогін на тестовій мережі з тими самими параметрами, що в основній, обов’язковий — зекономлене на генерації не можна повертати з перевірки.
Режими створення контрактів: ручний, шаблонний, генеративний
Режим створення контракту визначає не швидкість написання коду, а обсяг уваги, що залишається на перевірку логіки.
Ручна розробка контракту дає повний контроль над структурою зберігання та порядком викликів — це обов’язково там, де помилка в одній гілці умови призводить до втрати коштів. Шаблонні контракти фіксують уже перевірену схему: випуск токенів, ролі, пауза, обмеження на виведення. Залишається заповнити параметри й не винаходити модель прав заново.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Ручна розробка контракту | Унікальна економіка, нестандартні права, розрахунки із зовнішніми джерелами даних | Довший цикл, вищі вимоги до покриття тестами та зовнішнього аудиту |
| Шаблонні контракти | Типові сценарії: токен, розподіл виплат, гаманець із кількома підписами | Логіка обмежена шаблоном, нестандартна вимога ламає його модель прав |
| Генеративний режим | Каркас під нетиповий сценарій, тести, міграції, допоміжні модулі | Обов’язкове рев'ю: арифметика, застарілий синтаксис, приховані зовнішні виклики |
Генеративний режим прискорює чернетку, але не замінює перевірку. Модель збирає каркас й обв’язку під конкретну задачу, а інженер порядково звіряє арифметику, права та зовнішні виклики: неперевірений код не потрапляє в скрипт розгортання.
Вибір режиму йде від характеру задачі, а не від моди. На практиці ми комбінуємо: генеративна чернетка для каркаса, шаблонні модулі для типових частин, ручне доопрацювання ядра та меж, де ціна помилки максимальна.
Етапи роботи: від розбору задачі до передачі в експлуатацію
Генерація коду моделлю — це чернетка, а не готовий артефакт: вона швидко дає структуру контракту, але не відповідає за граничні стани та права виклику. Тому навколо AI-генерації будується звичайний інженерний процес, де кожен результат перевіряється. Нижче — етапи впровадження, які ми проходимо на проєкті.
- Розбір вимог і схема станів. Фіксуємо ролі, переходи та інваріанти: що контракт дозволяє, а що забороняє завжди. Схема узгоджується до написання коду — пізніше її правка коштує дорожче.
- Генерація чернетки. Модель збирає структуру контракту на Solidity за узгодженою схемою: сховище, функції, події. Обмеження та стиль задаємо заздалегідь, щоб код було легко супроводжувати.
- Перевірки безпеки. Статичний аналіз, тести на граничні та випадкові набори даних, ручний розбір прав доступу та зовнішніх викликів. Кожна знайдена проблема перетворюється на тест, який її більше не пропустить.
- Прогін на тестовій мережі. Відтворюємо реальні послідовності операцій, включно з помилковими: відкат транзакції, повторний виклик, недоступність зовнішнього сервісу.
- Приймання результату. Звіряємо покриття ключових шляхів тестами та розбіжність з вихідними вимогами; звіт із перевірками йде замовнику.
- Передача в експлуатацію. Розгортання, фіксація параметрів середовища, навчання команди замовника запуску та спостереженню за роботою контракту.
- Регламент правок. Як вноситься зміна, хто погоджує, які перевірки обов’язкові перед повторним розгортанням.
Артефакти проєкту: специфікації, моделі загроз, регламенти
Після здачі в команди замовника залишається комплект документів, за яким контракти можна розвивати й супроводжувати без нас. Це не папка з файлами, а пов’язаний набір: специфікація задає поведінку, модель загроз — межі довіри, регламент правок — порядок змін.
Кожен артефакт звіряється з кодом під час здачі: якщо опис інваріантів розходиться з логікою, робота не приймається. Нижче — що залишається на руках.
- Специфікація контракту — ролі, стани та переходи, зовнішні виклики й події: що контракт зобов’язаний робити і що заборонено.
- Опис інваріантів — умови, які виконуються за будь-якого сценарію, з прив’язкою до ділянок коду й автотестів.
- Модель загроз — вектори атаки на конкретний контракт, оцінка наслідків і закладені обмеження: ліміти, затримки виведення, пауза.
- Регламент правок — хто і як вносить зміни, які перевірки обов’язкові перед оновленням, як відкотитися на попередню версію.
- Права доступу — карта ролей і ключів: у кого які повноваження, де зберігаються, як передаються й відкликаються.
- Документація супроводу — розгортання, міграції стану, відстеження подій, типові збої та порядок дій.
- Звіт про перевірки — що знайшли під час статичного аналізу та ручного розбору, що закрили, що усвідомлено залишили.
Комплект живе разом із кодом: правка тягне за собою оновлення специфікації та моделі загроз, інакше документація розходиться з контрактом за пару тижнів.
Кейс: частка відмов у логіці переказів знизилася втричі
Клієнт — платформа регулярних виплат партнерам. Контракти на перекази писали вручну під кожну акцію: правами володів один ключ розробника, лімітів на суми й отримувачів не було, окремої ролі для зупинки операцій теж не існувало.
За квартал накопилося кілька розборів: перекази йшли на адресу з тестового середовища, частина виплат проходила двічі при повторному виклику, а відкликати помилкову операцію було нічим.
Наші інженери перевели випуск контрактів на генерацію з перевірених шаблонів: статичний аналізатор Slither проганяє кожен варіант і блокує розгортання при зауваженнях.
Ролі розділили — ініціатор платежу, підтверджувач, адміністратор казни та окрема роль паузи; критичні дії потребують двох підтверджень.
Що змінилося
Частка інцидентів у логіці переказів упала втричі: з дев’яти звернень за квартал до трьох, і всі три — помилки у вхідних даних, а не в коді. Випуск нового контракту займає години замість кількох днів, а частка автоматично перевірюваних шляхів зросла з 40 до 90%.
Ліміти задані і на одну операцію, і на добу, тому одна помилка більше не виносить всю казну.
Розбір іде за журналом: видно, яка роль ініціювала операцію, хто підтвердив і на якому кроці спрацювало обмеження; відкат — пауза й повторний переказ, без правки та повторного розгортання контракту.
Чим формальна перевірка відрізняється від аудиту коду?
Формальна перевірка й аудит коду відповідають на різні питання та не замінюють одне одного. Перша доводить властивості: за специфікацією математично перевіряється, що жоден шлях виконання її не порушує. Другий читає реалізацію й шукає те, чого в специфікації не було.
Доведення властивостей іде по всіх гілках, включно з рідкісними: інваріант балансу, недосяжність від’ємного обліку, збереження прав адміністратора. Але перевіряється рівно те, що сформульовано — властивість, яка не потрапила в модель, формальна перевірка не побачить. У цьому її межа застосовності.
Аудиту дістається те, що не формалізується: економічні припущення, порядок зовнішніх викликів, поведінка оракулів і контрагентів, логіка адмін-функцій. Ручні сценарії ловлять помилку в задумі — коли контракт робить рівно те, що написано, а написано не те, що потрібно продукту. Модель таку помилку підтвердить, а не знайде.
Звідси головний ризик — хибне відчуття безпеки. Позначка «формально верифіковано» не говорить, що специфікація правильна, а пройдений аудит не гарантує відсутності помилки в рідкісному шляху, який вручну не програвали.
Тому контур ділимо: інваріанти ядра — облік, права, ліміти — йдуть у формальні моделі, інтеграції та адмін-контури закриваємо аудитом із ручними сценаріями. У звіті окремо перелічуємо, що залишилося недоведеним.
Часті технічні сумніви перед стартом
Сумніви перед стартом майже завжди одні й ті самі: хто відповідає за помилку в логіці, що робити з уже розгорнутим контрактом, кому належать права на результат і чи можна перевірити код, не викладаючи його у відкритий доступ. Нижче — прямі відповіді, без застережень у дусі «залежить від задачі».
Хто відповідає, якщо в контракті знайдеться помилка?
Ми відповідаємо за відповідність згенерованого коду узгодженій логіці. Граничні стани, права на виклик методів і порядок списань описуємо до генерації, а розбіжність, знайдену на перевірці, усуваємо до приймання — не окремим кошторисом.
У нас уже розгорнуто контракт — його можна доопрацювати?
Так. Знімаємо поточний стан у мережі, звіряємо логіку з фактичною поведінкою та пропонуємо план: точкова правка, розширення через проксі або перерозгортання з перенесенням накопичених записів і прав доступу.
Кому належать права на код?
Виключні права на вихідні коди, конфігурації та опис переходять замовнику після приймання — без обмежень на доопрацювання сторонніми інженерами. Наші внутрішні напрацювання потрапляють у проєкт як звичайні залежності з відкритою ліцензією.
Чи можна перевірити результат, не публікуючи вихідні коди?
Так. Прогін тестів іде в закритому контурі замовника або в ізольованому середовищі, ви отримуєте звіт, схему станів і розбір критичних шляхів. Публікація у відкритому реєстрі — окреме рішення, для перевірки логіки вона не потрібна.
Що входить у супровід після запуску?
Спостереження за подіями контракту, реакція на інциденти, оновлення залежностей і правки за зміною вимог. Окремо фіксуємо порядок чергування та час реакції на звернення.
Обговоримо задачу й повернемося з оцінкою та планом
Точна оцінка робіт тримається не на здогадках, а на вихідних даних. Чим конкретніше ви опишете контракти та їхнє місце в продукті, тим менше припущень закладемо в план впровадження — і тим рідше строки поїдуть уже в процесі.
- Роль контрактів у продукті: токен і розподіл, ескроу, голосування, платний доступ — від цього залежить обсяг логіки та глибина перевірок.
- Цільова мережа та вимоги сумісності: чи потрібні стандарти ERC-20, ERC-721 або ERC-1155, зовнішні виклики до оракулів і мостів.
- Наявний код: поточні контракти, шаблони й напрацювання — розберемо й скажемо, що перевикористаємо, а що переписуємо.
- Модель прав: хто випускає, заморожує та оновлює контракт; чи потрібні ролі, пауза, мультипідпис і механізм оновлення логіки.
- Інтеграції: гаманці, бекенд, індексатори та зовнішні сервіси, з якими контракт обмінюється даними.
- Очікуване навантаження та чутливість до вартості транзакцій — впливає на структури даних і зберігання стану.
- Формат роботи та строки: разова генерація з перевіркою або супровід із доопрацюваннями після запуску.
Після розбору повернемося з планом впровадження за етапами та точками рев'ю, переліком перевірок — статичний аналіз, фаззинг, покриття тестами критичних шляхів, — картою ризиків з оцінкою ймовірності та сценаріями відкату, а також складом робіт і строками за кожним етапом.
Опишіть задачу у вільній формі: цього достатньо, щоб обговорити її предметно та повернутися з оцінкою й планом.
