Коли AI Agent отримує право на виконання в ланцюгу: хто перевіряє інформацію, яку він бачить, та видані команди?

1. Що виявила аварія KelpDAO

18 квітня 2026 року крос-ланцюговий міст rsETH KelpDAO зазнав атаки, в результаті якої було аномально звільнено 116 500 rsETH, що на момент події коштувало приблизно 292 мільйони доларів. Звіт про інцидент LayerZero показує, що зловмисник отримав ключі сесії розробника через соціальну інженерію, забруднивши внутрішній RPC, на якому базується LayerZero Labs DVN, і придушивши зовнішній RPC за допомогою атаки відмови в обслуговуванні, що призвело до того, що служба підпису видала підтвердження фальшивих повідомлень на основі помилкових даних. KelpDAO на той момент змінив шлях верифікації з 2-of-2 на 1-of-1 DVN. Якщо єдиний призначений DVN видає помилкове підтвердження, система більше не потребує другого незалежного DVN для перехресної перевірки одного й того ж повідомлення. CrowdStrike та Mandiant з високою ймовірністю пов'язують інцидент з TraderTraitor (UNC4899), пов'язаним з Північною Кореєю.

Цей інцидент не є одиничним випадком. Багато значних інцидентів безпеки в ланцюгах не пов'язані з тим, що криптографічні припущення були спростовані, а скоріше з контролем ключів, джерелами даних, конфігурацією верифікаторів, реалізацією протоколів та правами на експлуатацію. Система повинна не лише відповідати на запитання "чи є цей підпис дійсним", а й "хто має право підписувати, на основі якої інформації підписувати, і чи дійсно відбулася подія, що відповідає підпису".

Все більше AI Agent отримують можливості виконання в ланцюгу через розумні рахунки, стратегічні гаманці або обмежені служби підпису. Один дійсний підпис може лише підтвердити, що певний авторизований шлях був викликаний, але не може підтвердити, що дані, на основі яких діє агент, є надійними, що рішення відповідає встановленій стратегії, або що ця транзакція мала відбутися саме в цей момент. Об'єкт верифікації розширюється з "достовірності підпису" до "чи узгоджуються введення, рішення та виконання".

2. Що вирішують існуючі рішення та що залишають

Існуючі рішення частково вирішують питання довіри, але залишають залишкову довіру на різних ролях:

Оракули та арбітраж: результати ринку Polymarket спочатку пропонуються учасниками, і лише в разі оскарження протягом періоду оскарження вони переходять до голосування власників токенів UMA. Проблема не в тому, що "немає перевірки", а в тому, чи є перевірка надійною. Коли правила нечіткі, реальні події мають кілька тлумачень, або голосування зосереджене на кількох адресах, система фактично передає питання "хто визначає факти" іншій структурі управління.

Мультипідпис для крос-ланцюгових мостів та DVN: обидва реалізуються по-різному, але вимагають від застосунків чіткої конфігурації набору верифікаторів та порогу. Після того, як KelpDAO налаштував шлях на 1-of-1 DVN, весь шлях верифікації залежав від єдиної служби верифікації; дані та механізми реагування на збої, на яких базується ця служба, можуть створити наступну точку відмови.

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

TEE: Довірене середовище виконання може ізолювати код та чутливі дані, але не усуває довіру, а лише змінює її точку. Апаратура кореневої довіри та оновлення мікрокоду зазвичай залежать від виробників чіпів, код enclave, права на оновлення та стратегії сертифікації можуть контролюватися проектом або оператором. TEE може захистити процес обчислення, але не може автоматично децентралізувати ці повноваження управління.

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

3. CRVA: повторне проектування способу розподілу прав верифікації

DeepSafe була перейменована з Bool Network у 2025 році. CRVA продовжує технічну концепцію, запропоновану дослідниками Bool Network у 2022 році. Відповідна стаття була опублікована в IEEE Transactions on Information Forensics and Security (IEEE TIFS, Document ID 9903072) і пропонує платформу крос-ланцюгового нотаріату на основі "еволюційного прихованого комітету".

Конкретний підхід полягає в тому, що вузли беруть участь у випадковому відборі через Ring-VRF, обрані подають підтвердження та тимчасовий публічний ключ, зовнішні спостерігачі можуть перевірити їхню кваліфікацію, але важко визначити їхню тривалу ідентичність. Обраний тимчасовий комітет потім спільно підписує через пороговий MPC, жоден окремий вузол не може самостійно отримати результат. Ключове управління та інші критичні процеси працюють у TEE (наприклад, Intel SGX), щоб зменшити ймовірність того, що оператор хосту зможе прочитати або змінити частини ключа. Комітет також буде змінюватися за епохами, новий склад отримує нові частки через перевіряємий обмін ключами, старі частки втрачають силу, конкретний цикл зміни визначається фактичними параметрами мережі.

Проект також сподівається, що завдяки TEE прихований комітет буде важче визначити, чи бере участь їхній вузол у певній верифікації. Наскільки ця мета може бути досягнута, залежить від коду в поточній мережі, віддаленої сертифікації, метаданих на стороні хосту та захисту від бічних каналів, а не є автоматичним висновком, що "використання TEE" є достатнім.

Але ці механізми вирішують питання "хто верифікує, як безпечно спільно видавати результати", але не визначають автоматично "який результат є правильним". У контексті AI Agent комітет все ще повинен дійти висновку на основі заздалегідь визначених стратегій, джерел даних та виконуваних правил судження. Якщо ці правила самі по собі мають проблеми, джерела даних ненадійні, або об'єкт верифікації не має об'єктивно визначеного відповіді, навіть найбезпечніший комітет може спільно підтвердити помилковий висновок.

CRVA намагається зменшити ризики, пов'язані з тривалим відкриттям фіксованих верифікаторів та концентрацією прав підпису, але не може повністю усунути точки відмови на рівні управління та реалізації. Доступ до вузлів, оновлення протоколів, сертифікація TEE та безпека програмного забезпечення все ще потребують постійного аудиту. За умови, що старі частки надійно втрачають силу, а новий комітет залишається достатньо незалежним, ротація може скоротити вікно атаки на фіксовану групу підписів, але не може покрити системні ризики, такі як ланцюг постачання програмного забезпечення або права на оновлення.

4. Технічна основа та прогрес впровадження

Технічна основа CRVA може бути відстежена до статті, опублікованої в IEEE TIFS, том 17 (2022), DOI 10.1109/TIFS.2022.3209546. Модель протоколу, безпекові докази та оцінка прототипу в статті пройшли рецензування, надаючи академічну основу для динамічних прихованих комітетів, Ring-VRF, порогового управління ключами та захисту TEE. Важливо відзначити, що рецензування стосується моделей та реалізації в статті; як CRVA, що наразі впроваджується DeepSafe, відповідає рішенню в статті, ще потрібно оцінити в контексті актуальних технічних специфікацій, аудиту коду та параметрів мережі.

Згідно з інформацією, наданою DeepSafe у жовтні 2025 року, мережа на той момент обробила близько 120 мільйонів верифікацій, активні рахунки перевищили 2,65 мільйона. Проект також повідомив, що його екосистема охоплює понад 70 проектів, включаючи сумісність гаманців, технічну інтеграцію, інвестиції та ринкові співпраці.

У жовтні 2025 року DeepSafe оголосила про завершення раунду фінансування на 3 мільйони доларів, інвесторами стали Antalpha Global, ViaBTC Capital та Gate. З точки зору часової шкали, це фінансування в основному відповідає технологічним розробкам та розширенню екосистеми після зміни бренду.

5. Від верифікаційних рішень до загальної інфраструктури

З поступовою модульною структурою блокчейн-інфраструктури, консенсус, виконання, доступність даних, взаємодія та система рахунків починають виконуватися різними компонентами. Модульність не усунула проблеми довіри, а лише зробила безпекові межі кожного рівня більш чіткими. Розробники повинні не лише вибрати, яку технологію використовувати, але й визначити, хто надає безпеку на цьому рівні та хто несе відповідальність у разі проблем. Після того, як AI Agent отримує можливості виконання в ланцюгу, виникають нові питання: хто підтверджує, що дані, які він читає, є надійними, що рішення не перевищують повноваження, а остаточна транзакція відповідає авторизації користувача? Ці питання не отримають автоматичних відповідей лише через один дійсний підпис.

DeepSafe сподівається перетворити можливості верифікації з додаткового модуля всередині одного застосунку на інфраструктуру, доступну для різних протоколів та AI Agent. "Докази, а не обіцянки" - використовувати перевіряємий доказ замість обіцянок виконавця. CRVA вже об'єднала анонімний відбір, порогову співпрацю та TEE в єдиний технічний шлях. Чи зможе вона далі охопити різні сценарії, такі як оракули, крос-ланцюги та AI Agent, і розвинутися в загальну верифікаційну інфраструктуру, залежатиме від поточних можливостей мережі, незалежного аудиту та постійного накопичення реальної інтеграції.

Ця стаття є результатом подачі, не відображає думку BlockBeats.