Прибуток:
- Розуміння критично важливої для безпеки природи блокчейну та причин, чому штучний інтелект не може виявити початкову помилку, надає помилкові гарантії, застарів і не бере на себе відповідальність.
- Можливість запобігти витоку єдиної помилки в живу систему за допомогою багаторівневої перевірки, яка ставить шлюз перевірки людиною на кожному етапі
- Критично важливе для безпеки остаточне затвердження належить компетентному експерту та здатності прийняти принципи людської відповідальності, оборонної мети, конфіденційності, прозорості та чесності.
Це найважливіший блок цього модуля. Наразі ми бачили, як штучний інтелект прискорює все: від написання смарт-контрактів до аналізу в ланцюжку, від токеноміки до виявлення шахрайства. У цьому розділі ми відступаємо назад і розглядаємо суть питання: чому результат штучного інтелекту не може замінити схвалення компетентних експертів у критично важливих для безпеки роботах. І як експерт, яка основа для відповідального використання ШІ? Розробка блокчейнів є критично важливою для безпеки сферою, де помилки безпосередньо й незворотно перетворюються на гроші; Цей підрозділ відповідає вимогам цієї реальності.
Що означає «важливий для безпеки» і чому він відрізняється?
Область є критично важливою з точки зору безпеки, якщо наслідки помилки є незворотними та серйозними: загибель людей під час будівництва мостів, недбалість у медицині, негайна та безповоротна втрата мільйонів доларів у блокчейні. Прийнятий стандарт у цих областях повністю відрізняється від звичайного програмного забезпечення:
- «Ймовірно, це працює» недостатньо; має бути доведено.
- «Ми виправимо це пізніше» недійсне; Безповоротність не прощає.
- Остаточне затвердження покладається на компетентного експерта, який несе професійну та юридичну відповідальність.
ШІ – помічник; не може брати на себе відповідальність, не може нести відповідальність і не може стояти за результатами. Якщо звіт про аудит пропускає вразливість, відповідальність лежить на експерті, який підписав, а не на ШІ. «ШІ так сказав» не є захистом техніки.
Чому ШІ не може замінити експерта: чотири ключові причини
1. ШІ не бачить вихідну та контекстну помилку. ШІ розпізнає шаблони в навчальних даних. Нова вразливість, специфічна для протоколу помилка бізнес-логіки або унікальна взаємодія компонентів є сліпою плямою ШІ. Найдорожчі атаки Web3 відбуваються саме через ці унікальні вразливості.
2. AI дає помилкові впевненості. ШІ може вільно й впевнено сказати, що «цей код виглядає безпечним», але помиляється. Ця «галюцинація безпеки» є найнебезпечнішим результатом у критичній для безпеки зоні; тому що це створює помилкове відчуття безпеки.
3. ШІ застарів. Знання штучного інтелекту закінчуються на кінцевій даті навчання. Останні атаки, найновіші версії бібліотек, найновіші передові практики вже за горизонтом. Безпека – це гонка, яка постійно змінюється; Вчорашньої інформації сьогодні може бути недостатньо.
4. ШІ не несе відповідальності. Це, мабуть, найосновніша причина. Технічне схвалення є не лише технічним, а й юридичним та етичним зобов’язанням. Машина не може взяти на себе це зобов'язання.
Застереження: у виході, критичному для безпеки, запитання: "Що сказав AI?" але "Хто є компетентною особою, яка перевіряє, затверджує та стоїть за цим результатом?" має бути. Жодне неекспертне схвалення — ні штучним інтелектом, ні інструментом — не може вважатися гарантією.
Багаторівнева перевірка: запобігання витоку окремих помилок
Відповідальний робочий процес передбачає перевірку людиною на кожному етапі. Ви не можете пройти через одні двері, не пройшовши через інші:
етап
внесок ШІ
шлюз перевірки людини
правопис
проект кодексу
Збірка + тест + огляд
сканування
Вразливість кандидата
Статичний аналіз + підтвердження аудитора
Аудит
Підказка, звіт про чернетку
Підпис компетентного аудитора
тест
проект сценарію
Testnet + фаззинг + симуляція
Розподіл
контрольний список
Підтвердження мультипідписом + поступовий вихід
Моніторинг
знак аномалії
план реагування людини
Ця багаторівнева структура запобігає витоку однієї помилки ШІ в основну мережу. Кожні двері мають чітку умову проходження: чи пройшов тест, чи підписав аудитор, чи витримала симуляція?
Слабкий підхід / Сильний підхід
Слабкий підхід:
ШІ згенерував код, він виглядає чистим, давайте розмістимо його в основній мережі.
Це рецепт катастрофи в безповоротній сфері.
Потужний підхід:
1. ШІ створив чернетку → ми її скомпілювали, протестували.2. Статичний аналіз + сканування AI → підтверджено аудитором.3. Незалежний аудит безпеки → підписаний звіт.4. Testnet + фаззинг + симуляція → витримані сценарії.5. Мультипідпис, каскадний вихід з основної мережі + моніторинг. На кожному порту: немає прогресу, доки не буде виконано умову переходу.
Чотири шаблони, які можна копіювати
1) Контроль воріт перевірки:
Створіть контрольний список перевірки для цього критично важливого для безпеки результату: якими незалежними етапами (компіляція, статичний аналіз, аудит, тестування, моделювання) його потрібно перевірити? Напишіть умову переходу для кожного кроку. Вкажіть, який ризик виникне, якщо пропустити один крок.
2) Позначення рівня достовірності вихідних даних ШІ:
Перегляньте наведені нижче результати, згенеровані штучним інтелектом, і позначте кожне твердження: «перевірено / має бути перевірено / слабкі місця ШІ». Виділіть моменти, які потребують досвіду людини, особливо ті, що стосуються бізнес-логіки та унікального ризику.
3) Перевідна записка експерта:
Щоб передати цей результат компетентному експерту, підготуйте резюме: що робив ШІ, з якими припущеннями, де він невпевнений, де конкретно експерт повинен підтвердити? Дайте зрозуміти, що відповідальність лежить на експерті.
4) Підготовка реагування на інцидент:
Створіть схему реагування на надзвичайні ситуації/інциденти для цього протоколу: які кроки (повноваження перехоплення, зв’язок, захист коштів) будуть задіяні, якщо вразливість буде використана в істоті? Це чернетка; Команда та експерт повинні відкалібрувати.
Три міні кейси (в кількості)
Випадок 1 — Стрибок у двері приніс катастрофу. Через брак часу команда пропустила незалежний аудит і покладалася на власні тести AI + і перейшла до основної мережі. Через 11 днів через уразливість бізнес-логіки видалено ~4 мільйони доларів. Оглядові ворота, мабуть, уловлять це. Урок: не обходьте двері в критичній для безпеки зоні.
Випадок 2 — Рівнева автентифікація збережена. Інша команда керувала кожним шлюзом: схема ШІ → статичний аналіз → аудит → тестова мережа → моделювання. Під час етапу аудиту повторне входження, ризик оракула було виявлено в симуляції. Обидва вони закриті перед основною мережею. Урок: шари запобігають витоку поодиноких помилок.
Випадок 3 — «Безпечна галюцинація». Розробник запитав ШІ про код; "Схоже, немає жодних значних проблем із безпекою", - сказав AI. Команда все одно відправила його на перевірку, і виявилося два знахідки високого рівня. Якби ми довіряли штучному інтелекту, вони б ожили. Урок: вираз впевненості ШІ не є підтвердженням.
Принципи відповідального використання
Ми можемо звести суть цього модуля до шести принципів:
- Відповідальність людини: критично важливе для безпеки остаточне затвердження належить компетентному експерту; ШІ не може бути притягнутий до відповідальності.
- Рівнева автентифікація: умова шлюзу та пропуску людини на кожному етапі.
- Оборонне використання: для захисту та контролю інформації; Не використовувати/пастку.
- Конфіденційність: код і дані клієнта не надаються відкритим інструментам без дозволу.
- Прозорість: у звіті чесно зазначено використання ШІ; Ніяких перебільшень чи фальшивих запевнень не дається.
- Чесність: інвестори та користувачі не введені в оману; Ризик не прихований, поради не приховані.
Порада. Ставте собі одне запитання для кожного критично важливого для безпеки рішення: «Якщо це неправильно і гроші втрачено, чи була компетентна перевірка людини, яка б стояла за цим і брала на себе відповідальність?» Якщо відповідь «ні, так сказав ШІ», процес не завершено.
Поширені помилки
- Обхід незалежного аудиту. Це невблаганно в безповоротній області.
- Приймаючи вираз довіри ШІ за підтвердження. «Безпечна галюцинація» — найнебезпечніша.
- Спроба покласти відповідальність на ШІ. Відповідальність несе експерт, який підписав.
- Припускаючи своєчасність. ШІ не знає після завершення навчання.
- Скорочення дверей через тиск часу. Джерело найдорожчої помилки.
- Виїзд без плану реагування на інцидент. Коли відбувається витік, людина залишається непідготовленим.
Підсумовуючи
- Блокчейн має критичне значення для безпеки; Помилки незворотні і обертаються безпосередньо грошима.
- ШІ не бачить початкової помилки, дає помилкові гарантії, застарів і не може нести відповідальність.
- Ось чому остаточне схвалення, яке має важливе значення для безпеки, завжди належить компетентному експерту.
- Багаторівнева перевірка запобігає витоку однієї помилки в живе середовище, розміщуючи захисні ворота на кожному етапі.
- Відповідальне використання: людська відповідальність, оборонна мета, конфіденційність, прозорість і цілісність.
Аплікаційне завдання
Уявіть проект смарт-контракту (або візьміть реальний приклад). Напишіть багаторівневий план перевірки для всього шляху від ідеї до основної мережі: що робить штучний інтелект на кожному етапі, які там людські ворота, яка умова переходу? Потім додайте сценарій «тиску часу»: які двері було б найнебезпечніше обійти і чому? Також додайте схему реагування на інцидент.
контрольний список
- [ ] Я погодився, що остаточне схвалення, яке має важливе значення для безпеки, належить експерту.
- [ ] Я ставлю шлюз перевірки людиною на кожному етапі.
- [ ] Я не вважав вираз впевненості ШІ підтвердженням.
- [ ] Я не обійшов двері незалежного аудиту.
- [ ] Я не припускав актуальності; Я підтвердив останню інформацію з людиною.
- [ ] Я не покладав відповідальність на ШІ.
- [ ] Я підготував план реагування на інцидент.