одиниці
1. Вступ до штучного інтелекту в блокчейні та Web3: ролі, межі, автентифікація та критичність безпеки 2. Підтримка написання розумних контрактів: чернетка Solidity/Vyper і генерація безпечного коду 3. Підтримка аудиту розумних контрактів: перевірка безпеки та попередні висновки 4. Сканування вразливостей: загальні шаблони вразливостей і автоматизований аналіз 5. Аналіз даних у мережі: аналіз даних про блоки, транзакції та гаманець 6. DeFi та аналіз протоколів: ліквідність, MEV та економічні атаки 7. Токеномічне моделювання: постачання, розподіл, заохочення та моделювання 8. Документація та технічне написання: Whitepaper, NatSpec та посібник користувача 9. Шахрайство, виявлення несправностей і ризиків: червоні прапорці в мережі 10. Аудит, важливий для безпеки, схвалення експертів і відповідальне використання 11. Наскрізний робочий процес, управління, перевірка та етика
одиниця 3 / 11

Підтримка аудиту розумних контрактів: перевірка безпеки та попередні висновки

Прибуток:

  • Здатність розуміти, що штучний інтелект розширює сферу діяльності аудитора, але не замінює його, і корисний при скануванні категорій і пошуку чернеток.
  • Можливість розпізнати, що штучний інтелект пропустив початкову вразливість і помилку бізнес-логіки, і що плавне «захищене» твердження не є гарантією
  • Здатність класифікувати висновки відповідно до їхнього рівня серйозності та розуміти, що остаточне затвердження та професійна відповідальність лежить на компетентному аудиторі.

Аудит безпеки (систематична перевірка смарт-контракту на вразливості) — найвідповідальніша робота Web3. Один рядок, пропущений аудитором, може призвести до збитків у мільйони доларів. У цьому розділі ви дізнаєтеся, як використовувати ШІ як помічника в аудиті; Ми навчимося від створення підказок до написання плану результатів. Але найбільш критичне речення таке: ШІ не контролює; Це помічник, який загострює око аудитора. Остаточне затвердження належить компетентному аудитору, який бере на себе професійну відповідальність.

Чому аудит є критично важливим для безпеки

Аудиторський звіт запевняє проект та інвесторів у тому, що «цей кодекс переглянуто». Якщо ця впевненість хибна, наслідки катастрофічні: експлуатація протоколу, втрата фінансування, крах проекту. Тому використання штучного інтелекту в інспекції є найбільш ретельною частиною цього модуля. ШІ розширює сферу діяльності аудитора (запам’ятовує більше шаблонів, читає швидше), але не замінює аудитора.

Чому не проходить? Тому що:

  • ШІ не може побачити унікальну/нову вразливість, якої немає в навчальних даних.
  • ШІ часто пропускає недолік у бізнес-логіці протоколу — те, що код є технічно правильним, але економічно корисним.
  • ШІ може дати помилкове запевнення, сказавши «безпечно» вільною мовою; Це найнебезпечніший результат.

Рівні використання ШІ в управлінні

1. Початкове сканування та нагадування про шаблон. Штучний інтелект перевіряє відомі шаблони вразливостей, як контрольний список: повторне входження, контроль доступу, маніпуляції оракулами, передовий запуск. Це гарантує, що аудитор не пропустить жодної категорії.

2. Пояснення коду. Пояснення складної функції штучному інтелекту простою мовою дозволяє аудитору швидко зрозуміти логіку; але опис завжди порівнюється з кодом.

3. Написання чернетки висновків. Коли аудитор виявляє вразливе місце, ШІ економить час на написанні чернетки звіту (опис, вплив, запропоноване рішення).

4. Генерування контргіпотези. Запитайте ШІ "як можна зловживати цією функцією?" Питання" нагадує нам про агресивну перспективу.

Увага: те, що AI говорить «Я не знайшов жодної вразливості в цьому коді», НЕ означає, що «цей код безпечний». Докази відсутності не є відсутністю доказів. Той факт, що штучний інтелект не може щось знайти, не робить аудитором непотрібним перевіряти цю область.

Знаходження рівнів тяжкості

Висновки аудиту класифікуються за ступенем серйозності. AI повинен використовувати цю структуру під час створення чернеток:

Рівень

Значення

приклад

критичний

Можлива безпосередня втрата/блокування коштів

Виведення коштів з повторним входом

висока

Серйозний вплив за певних умов

Несанкціонований друк (монетний двір)

середній

Обмежений вплив або важкий стан

Невеликі втрати з відхиленням Oracle

низький

Незначний ризик, порушення належної практики

Відсутня трансляція події

Інформація

Незахищеність, читабельність

Відсутність NatSpec

Слабка підказка / Сильна підказка

Слабка підказка:

Чи безпечний цей договір?

Це запитання змушує штучний інтелект робити абсолютне, необґрунтоване судження на зразок «так/ні» — саме те, чого ми не хочемо.

Потужна підказка:

Ваша роль: помічник старшого аудитора смарт-контрактів. Проскануйте цей контракт на предмет безпеки. Перегляньте наступні категорії одну за одною: повторне входження, контроль доступу, операції з цілими числами, перевірка вхідних даних, оракул/зовнішні дані, початкове виконання, обмеження газу. Для кожного ВИСНОВКУ: (1) відповідний рядок коду, (2) причина ризику, (3) оцінений ступінь серйозності (Критичний/Високий/Середній/Низький), (4) пропозиція рішення. Це ГІПОТЕЗИ, ЯКІ ПОТРІБНО ПІДТВЕРДИТИ; Не виносьте «безпечний» вердикт. Позначте ті області, в яких ви не впевнені, чітко скажіть «нехай аудитор підтвердить».

Чотири шаблони, які можна копіювати

1) Перегляд за категоріями:

Проскануйте цей контракт на наявність таких категорій: повторне входження, контроль доступу, переповнення цілих чисел, перевірка введення, залежність від оракула, початкове виконання, DoS/газ. Для кожної категорії скажіть «немає/немає ризику/я не впевнений» і зв’яжіть своє обґрунтування з рядком у коді. Не виносьте остаточного судження.

2) Контрагіпотеза з точки зору зловмисника:

Подумайте як зловмисник: як можна зловживати цією функцією? Напишіть кожен сценарій крок за кроком і вкажіть, які умови потрібні. Ці сценарії є гіпотезами, які необхідно перевірити; НЕ генеруйте фактичний код експлойту, просто опишіть ризик.

3) Проект висновків:

Повідомте про такі підтверджені знахідки офіційною мовою аудиту: назва, серйозність, опис, вплив, код, на який впливає код, кроки для відтворення, запропоноване рішення. Використовуйте виважену та технічну мову; перебільшення. Припустимо, що висновок підтверджено аудитором, не створюйте новий висновок.

4) Перевірка виправлення:

Нижче наведено вразливість і виправлення, застосовані розробником. Перевірте, чи справді виправлення закриває вразливість; позначити, чи створює це новий побічний ефект або вразливість. Не кажіть точно «зачинено»; Закінчіть словами "має бути підтверджено тестуванням".

Три міні кейси (в кількості)

Випадок 1 — штучний інтелект запобіг перестрибуванню категорії. Аудитор збирався зосередитися на контракті з 400 рядків і пропустити категорію оракулів. Сканування категорій ШІ дало попередження, що «дані про ціни отримані з одного джерела, відкриті для маніпуляцій». Аудитор перевірив його і виявив, що це дійсно середній ризик. Урок: AI підтримує дисципліну покриття.

Випадок 2 — Хибна гарантія «безпеки». Інша команда запитала ШІ «це безпечно?» запитав він; «Схоже, що серйозної проблеми немає», — сказав AI. Огляд бригади був легким. Потім незалежний аудитор виявив недолік бізнес-логіки: технічно правильний розрахунок, але стимули якого можна було використовувати. Урок: AI пропускає помилку бізнес-логіки; Йому не можна довіряти, щоб сказати «безпечно».

Кейс 3 — Складання звіту заощадило 3 години. Аудитор витратив половину дня, звітуючи вручну про 8 висновків. Після того, як я надав перевірені висновки ШІ та надрукував офіційну чернетку, час скоротився приблизно на 3 години; Ревізор присвятив час поглибленню. Урок: штучний інтелект є безпечним і ефективним у звітності, оскільки результати вже перевірені людьми.

Вразливість бізнес-логіки: сліпа пляма ШІ

Найдорожчі уразливості часто походять не від технічної помилки в коді, а від можливості використання бізнес-логіки: використання округлення винагородного облікового запису, швидке викрадення голосу, миттєва маніпуляція ціною. Це випадки, коли код працює «правильно», але протокол можна економічно обдурити. ШІ, швидше за все, пропустить такі помилки, особливо ті, що стосуються протоколу. Таким чином, перевірка бізнес-логіки є найбільш інтенсивною людиною сферою роботи аудитора та найменшою мірою залежить від ШІ.

Підказка: Запитайте ШІ «як можна використати економічні стимули цього протоколу?» і використовуйте запропоновані сценарії як відправну точку, але пам’ятайте, що ви та ваша команда повинні провести справжній аналіз.

Поширені помилки

  • Запитайте ШІ: "це безпечно?" Запитуючи і довіряючи своєму так. Абсолютне судження не потрібне.
  • Зупинка перегляду, коли AI каже «Я не зміг знайти». Відсутність не є доказом.
  • Делегування перевірки бізнес-логіки ШІ. Це його найбільша сліпа пляма.
  • Без використання незалежних інструментів (Slither тощо). Одного штучного інтелекту недостатньо.
  • Внесення висновку, зробленого ШІ, до звіту без його перевірки. Ризик галюцинацій.
  • Спроба покласти відповідальність за контроль на ШІ. Відповідальність лежить на експерті.

Підсумовуючи

  • Аудит є критично важливим для безпеки; ШІ розширює сферу діяльності аудитора, але не замінює її.
  • ШІ пропускає вихідну вразливість і помилку бізнес-логіки; Сказати «безпечно» не є впевненістю.
  • Результати класифікуються за ступенем тяжкості; AI корисний для створення чернеток.
  • Контргіпотеза та перевірка категорій зберігають дисципліну включення.
  • Остаточне затвердження та професійна відповідальність завжди лежить на компетентному аудиторі.

Аплікаційне завдання

Знайдіть зразок контракту, який містить відому вразливість (з метою навчання приклади «вразливих контрактів» доступні у відкритому коді). Застосуйте підказку «сканування на основі категорій» до ШІ. Зверніть увагу, чи штучний інтелект: (1) виявив справжню вразливість, (2) зробив сфабриковані/хибні висновки, (3) зробив абсолютне судження, наприклад, «безпечно». Потім порівняйте його з інструментом статичного аналізу.

контрольний список

  • [ ] Запитайте ШІ "це безпечно?" Натомість у мене було сканування на основі категорій.
  • [ ] Я розглядав кожне відкриття як гіпотезу.
  • [ ] Я сам/команда перевірив бізнес-логіку.
  • [ ] Я перевірив його за допомогою незалежного інструменту статичного аналізу.
  • [] Я підтвердив, що штучний інтелект не фабрикує висновки.
  • [ ] Я класифікував результати за ступенем серйозності.
  • [ ] Я погодився з тим, що остаточне затвердження належить компетентному аудитору.