Посібник з безпеки DeFi: як ефективно захищатися від хакерських атак у епоху штучного інтелекту?

Написано: sysls

Компіляція: AididiaoJP, Foresight News

Оригінальне посилання:

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

Вступ

Після ознайомлення з великою кількістю випадків хакерських атак на DeFi-протоколи, у мене виник страх перед «державними акторами». Вони мають високий рівень технічної підготовки, достатньо ресурсів і грають у довгострокову гру; ці суперзлочинці зосереджені на вивченні кожного куточка ваших протоколів і інфраструктури для пошуку вразливостей, тоді як звичайні команди протоколів розпорошені між шістьма-сімома різними напрямками діяльності.

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

Я щиро вірю, що виживає лише той, хто має навички нав’язливої уваги. Жодна команда не починає з думки «Я буду ставитися до безпеки байдуже і поверхнево»; однак атаки все одно трапляються. Нам потрібно робити краще.

AI означає, що цього разу все справді змінюється

(Джерело даних:

Хакерські атаки не є рідкістю, але їх частота явно зростає. Перший квартал 2026 року став рекордним за кількістю хакерських атак на DeFi, а другий квартал тільки починається і вже має всі шанси побити цей рекорд.

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

Це має кардинально змінити наш підхід до аналізу та реагування на хакерські атаки. Старі протоколи, які звикли покладатися на безпеку до того, як AI став потужним, тепер все більше ризикують бути «змазаними» за секунду.

Мислення через поверхні та рівні

(Джерело даних:

Площа поверхні атак у реальності можна звести до трьох: команда протоколу, смарт-контракти та інфраструктура, межі довіри користувачів (DSN, соцмережі тощо).

Якщо визначили ці поверхні, можна накладати захисні шари:

Профілактика: якщо строго дотримуватися, можна максимально знизити ймовірність експлуатації.

Пом’якшення: у разі провалу профілактики обмежити масштаб шкоди.

Пауза: ніхто не може приймати оптимальні рішення під великим тиском. Після виявлення атаки одразу активуйте «загальний аварійний режим». Замороження може запобігти подальшим втратам і дати час подумати…

Відновлення: якщо ви втратили контроль над токсичними або зламаними компонентами, потрібно їх відкинути і замінити.

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

Принципи

Ці принципи керують конкретними діями для реалізації багаторівневої оборони.

Активне використання передового AI

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

Використовуйте навички pashov, nemesis та платформи AI, такі як Cantina (Apex) і Zellic (V12), для швидкого сканування коду перед повним аудитом.

Час і опір — хороші захисні засоби

Додавайте багатоетапні процеси і тайм-локи для будь-яких потенційно шкідливих операцій. Вам потрібно достатньо часу, щоб втрутитися і заморозити при виявленні аномалії.

Раніше аргументували проти тайм-локів і багаторівневих налаштувань через додаткові труднощі для команди протоколу. Тепер це не так: AI може легко автоматично проходити ці перешкоди у фоновому режимі.

Непохитні істини

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

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

Баланс влади

Багато атак походять від зламаних гаманців. Вам потрібно таку конфігурацію, щоб навіть при зломі мульти-підпису швидко обмежити шкоду і повернути протокол у стан, де його можна керувати.

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

Завжди щось трапляється

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

Якщо так думати, то обмеження шкоди у вигляді швидкості і «відключення» протоколу стане вашим найкращим другом. Обмежте шкоду до 5-10%, потім заморожуйте і плануйте реагування. Ніхто не може прийняти найкраще рішення під вогнем.

Найкращий час для планування — зараз

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

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

Відсутність зламаності не означає, що ви не можете бути зламані. Найбільша небезпека — це точка максимальної зручності.

Заходи профілактики

Проектування смарт-контрактів

Після визначення непохитних правил їх потрібно зробити перевіряльними під час виконання. Обдумайте, які з них дійсно варто жорстко контролювати.

Це — модель FREI-PI (Function Requirements, Effects, Interactions, Protocol Invariants): наприкінці кожної функції, що має цінність, повторно перевіряйте, чи дотримуються обіцяні непохитні правила. Багато атак, таких як CEI (Checks-Effects-Interactions) (флеш-атаки, ліквідація через оракул, витік ліквідації через міжфункціональні виклики), можна виявити саме цим підходом.

Гарне тестування

Статичне fuzzing (статичне випадкове тестування) генерує випадкові послідовності викликів для протоколу і перевіряє непохитні правила на кожному кроці. Більшість вразливостей у реальних системах — багатокрокові транзакції, і статичне fuzzing — майже єдине надійне рішення для їх виявлення до зловмисників.

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

Оракули та залежності

Складність — ворог безпеки. Кожна зовнішня залежність розширює площу атак. При проектуванні базових елементів довіряйте користувачам, даючи їм вибір, кому і чому довіряти. Якщо не можна позбавитися залежностей, зробіть їх багатоваріантними, щоб жоден один збій не міг зруйнувати протокол.

Розширюйте аудит, щоб охопити симуляцію збоїв оракулів і залежностей, і накладайте обмеження швидкості на потенційні катастрофи.

Останній приклад — вразливість KelpDAO: вони використовували стандартну конфігурацію LayerZero requiredDVNCount=1, яка не входила до їхнього аудиту. В результаті зламали зовнішню інфраструктуру поза межами аудиту.

Поверхневі атаки

Більшість поверхневих атак у DeFi вже перераховані. Перевірте кожен тип, запитайте себе, чи застосовний він до вашого протоколу, і впровадьте контроль для кожного вектора. Розвивайте навички червоних команд, щоб ваш AI-інтелект самостійно шукав уразливості — це вже стандарт.

Майте вбудовану здатність до допомоги

У децентралізованому управлінні найсильніша влада зосереджена у мульти-підписах команди, але вона потребує часу для поширення. Навіть при широкому розподілі токенів делегування часто зосереджує владу у кількох гаманцях (іноді навіть у одному). При зломі таких гаманців гра закінчується.

Розгорніть «гаманці-охоронці», з обмеженими правами: вони можуть лише призупинити протокол, а при досягненні порогу >=4/7 — у крайніх випадках замінити пошкоджений гаманець на попередньо визначений. Охоронці ніколи не можуть ініціювати управлінські пропозиції.

Таким чином, у вас є резервний рівень допомоги, що може відновити управління, але не скасовує його. Ймовірність зломів >=4/7 охоронців дуже низька (з урахуванням диверсифікації власників), і з часом, коли управління стане більш розподіленим, цей рівень можна поступово зняти.

Гаманці та топологія ключів

Мульти-підпис — мінімальна вимога, 4/7. Ніколи не контролює всі сім ключів один користувач. Регулярно змінюйте підписувачів і робіть це непомітно.

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

Майте кілька мульти-підписів для різних цілей. Припустіть, що хоча б один з них буде зламаний, і плануйте дії відповідно. Ніхто не повинен мати достатньо контролю, щоб зламати протокол навіть у крайніх ситуаціях (викрадення, катування тощо).

Розгляньте винагороду

Якщо у вас є ресурси, встановіть високий рівень винагороди за вразливості, співвідносний із TVL протоколу; навіть для невеликих протоколів винагорода має бути щедрою (мінімум 7-8 цифр).

Якщо ви стикаєтеся з державними акторами, вони можуть не вести переговорів, але ви все одно можете долучитися до програми «білих капелюхів», делегуючи їхні дії для захисту коштів і отримуючи частину від винагороди (фактично — винагороду, сплачену вкладниками).

Знайдіть хороших аудиторів

Я раніше писав, що з розвитком великих мовних моделей цінність найму аудиторів зменшується. Але моє ставлення змінилося.

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

По-друге, ще одна перевага — це репутація. Якщо вони підписують і схвалюють, а вас зламали, вони будуть сильно зацікавлені допомогти. Встановлення зв’язків із професіоналами у цій сфері — великий плюс.

Практика операційної безпеки

Розглядайте операційну безпеку як критерій успіху. Проводьте тренінги з фішингу; наймайте (надійних) червоних команд для соціальної інженерії. Майте запасні гаманці та пристрої для швидкої заміни мульти-підписів. Не готуйтеся до D-day у останню хвилину.

Міри пом’якшення

Ваш шлях виходу — це обмеження збитків

Будь-який шлях виведення коштів із протоколу має мати верхню межу — максимально можливі збитки у разі експлуатації вразливості. Простий приклад: функція емісії без обмежень — це порожній чек для будь-якої безмежної емісії. Функція викупу без тижневого ліміту — це порожній чек для будь-якого зниження балансу.

Обдумайте чітке число для виходу. Це має балансувати між максимально допустимими збитками і потребами користувачів. У разі проблем це — те, що врятує вас від повного руйнування.

Білі та чорні списки

Більшість протоколів мають списки дозволених для викликів, транзакцій або отримання коштів, а також списки заборонених. Навіть якщо вони неформальні, це — межі довіри, які потрібно формалізувати.

Формалізація дозволяє створити двоступеневі механізми управління, ускладнюючи атакам. Атакуючий спершу має додати себе до білого списку (або видалити з чорного), а потім діяти. Мати і білого, і чорного списки означає, що для нових векторів атаки потрібно одночасно зламати обидва процеси: ринок має бути дозволений (інтеграція/лістинг), і дія не має бути заборонена (перевірка безпеки).

Відновлення

Моніторинг алгоритмів

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

Зупинка і переналаштування

Якщо вас зламали, потрібно зупинити кровотечу, а не ухвалювати рішення у поспіху. Для протоколу це — кнопка «зупинити все» (також має бути у UI): один натиск — і всі шляхи переміщення цінностей призупинені. Створіть скрипт «пауза всього», що перераховує всі зупиняємі компоненти і виконує їх одночасно.

Тільки управління може зняти паузу, тому аварійний режим не може зупинити управлінські контракти. Якщо охоронці можуть зупинити управління — зламана охоронна команда може назавжди заблокувати процес відновлення.

Запустіть командний центр

Замороження, зупинка кровотечі, і залучення всіх довірених осіб (заздалегідь узгоджені) у канал зв’язку. Ви хочете тримати інформацію менш відкритою, щоб уникнути витоку до зловмисників, публіки або спекулянтів.

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

Коли всі знають свої ролі і відпрацьовують сценарії, ви зможете діяти за планом, а не панікувати.

Розгляньте ланцюгову реакцію

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

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

Попереднє планування замінників

Заміна заздалегідь відомих кандидатів — безпечна стратегія. Я люблю ідею реєстру попередніх кандидатів: вона ускладнює зловмисникам підміну здорових охоронців або управлінських гаманців на зламані. Це відповідає концепції «білих» і «чорних» списків у профілактичних заходах.

Зареєструйте для кожної важливої ролі адреси наступників. Єдине, що може виконати терміновий обмін — це «замінити роль X на її наступника». Це дозволяє у мирний час оцінювати кандидатів, проводити дью-дилігенс і зустрічатися з ними.

Обережно тестуйте оновлення

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

Не поспішайте з релізом без достатнього тестування. Якщо немає часу на аудит, залучайте білих капелюхів або влаштуйте 48-годинний конкурс перед деплоєм для додаткової перевірки.

Відновлення

Швидкі дії

Зкрадені кошти мають напіврозпад; як тільки вразливість використана, вони швидко потрапляють у схеми відмивання. Попередньо підготуйте інструменти, такі як Chainalysis, для моніторингу адрес зловмисників і повідомлення бірж при їх переміщеннях.

Майте список сторонніх партнерів: бірж, мостів, кастодіанів і інших, хто може заморозити транзакції або депозити у процесі.

Переговори

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

Якщо ви маєте справу з державними акторами, можливо, вам не пощастить, але ви все одно можете долучитися до програми «білих капелюхів», делегуючи їм захист коштів і отримуючи частину від винагороди (фактично — винагороду, сплачену вкладниками).

Знайдіть хороших аудиторів

Я раніше писав, що з розвитком великих мовних моделей цінність найму аудиторів зменшується. Але моє ставлення змінилося.

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

По-друге, ще одна перевага — це репутація. Якщо вони підписують і схвалюють, а вас зламали, вони будуть дуже зацікавлені допомогти. Встановлення зв’язків із професіоналами у цій сфері — великий плюс.

Практика операційної безпеки

Розглядайте операційну безпеку як критерій успіху. Проводьте тренінги з фішингу; наймайте (надійних) червоних команд для соціальної інженерії. Майте запасні гаманці і пристрої для швидкої заміни мульти-підписів. Не готуйтеся до D-day у останню хвилину.

Міри пом’якшення

Ваш шлях виходу — це обмеження збитків

Будь-який шлях виведення коштів із протоколу має мати верхню межу — максимально можливі збитки у разі експлуатації вразливості. Простий приклад: функція емісії без обмежень — це порожній чек для будь-якої безмежної емісії. Функція викупу без тижневого ліміту — це порожній чек для будь-якого зниження балансу.

Обдумайте чітке число для виходу. Це має балансувати між максимально допустимими збитками і потребами користувачів. У разі проблем це — те, що врятує вас від повного руйнування.

Білі та чорні списки

Більшість протоколів мають списки дозволених для викликів, транзакцій або отримання коштів, а також списки заборонених. Навіть якщо вони неформальні, це — межі довіри, які потрібно формалізувати.

Формалізація дозволяє створити двоступеневі механізми управління, ускладнюючи атакам. Атакуючий спершу має додати себе до білого списку (або видалити з чорного), а потім діяти. Мати і білого, і чорного списки означає, що для нових векторів атаки потрібно одночасно зламати обидва процеси: ринок має бути дозволений (інтеграція/лістинг), і дія не має бути заборонена (перевірка безпеки).

Відновлення

Алгоритмічний моніторинг

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

Зупинка і переналаштування

Якщо вас зламали, потрібно зупинити кровотечу, а не ухвалювати рішення у поспіху. Для протоколу це — кнопка «зупинити все» (також має бути у UI): один натиск — і всі шляхи переміщення цінностей призупинені. Створіть скрипт «пауза всього», що перераховує всі зупиняємі компоненти і виконує їх одночасно.

Тільки управління може зняти паузу, тому аварійний режим не може зупинити управлінські контракти. Якщо охоронці можуть зупинити управління — зламана охоронна команда може назавжди заблокувати процес відновлення.

Запустіть командний центр

Замороження, зупинка кровотечі, і залучення всіх довірених осіб (заздалегідь узгоджені) у канал зв’язку. Ви хочете тримати інформацію менш відкритою, щоб уникнути витоку до зловмисників, публіки або спекулянтів.

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

Коли всі знають свої ролі і відпрацьовують сценарії, ви зможете діяти за планом, а не панікувати.

Розгляньте ланцюгову реакцію

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

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

Попереднє планування замінників

Заміна заздалегідь відомих кандидатів — безпечна стратегія. Я люблю ідею реєстру попередніх кандидатів: вона ускладнює зловмисникам підміну здорових охоронців або управлінських гаманців на зламані. Це відповідає концепції «білих» і «чорних» списків у профілактичних заходах.

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

Обережно тестуйте оновлення

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

Не поспішайте з релізом без достатнього тестування. Якщо немає часу на аудит, залучайте білих капелюхів або влаштуйте 48-годинний конкурс перед деплоєм для додаткової перевірки.

Відновлення

Швидкі дії

Зкрадені кошти мають напіврозпад; як тільки вразливість використана, вони швидко потрапляють у схеми відмивання. Попередньо підготуйте інструменти, такі як Chainalysis, для моніторингу адрес зловмисників і повідомлення бірж при їх переміщеннях.

Майте список сторонніх партнерів: бірж, мостів, кастодіанів і інших, хто може заморозити транзакції або депозити у процесі.

Переговори

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

Якщо ви маєте справу з державними акторами, можливо, вам не пощастить, але ви все одно можете долучитися до програми «білих капелюхів», делегуючи їм захист коштів і отримуючи частину від винагороди (фактично — винагороду, сплачену вкладниками).

Знайдіть хороших аудиторів

Я раніше писав, що з розвитком великих мовних моделей цінність найму аудиторів зменшується. Але моє ставлення змінилося.

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

По-друге, ще одна перевага — це репутація. Якщо вони підписують і схвалюють, а вас зламали, вони будуть дуже зацікавлені допомогти. Встановлення зв’язків із професіоналами у цій сфері — великий плюс.

Практика операційної безпеки

Розглядайте операційну безпеку як критерій успіху. Проводьте тренінги з фішингу; наймайте (надійних) червоних команд для соціальної інженерії. Майте запасні гаманці і пристрої для швидкої заміни мульти-підписів. Не готуйтеся до D-day у останню хвилину.

Міри пом’якшення

Ваш шлях виходу — це обмеження збитків

Будь-який шлях виведення коштів із протоколу має мати верхню межу — максимально можливі збитки у разі експлуатації вразливості. Простий приклад: функція емісії без обмежень — це порожній чек для будь-якої безмежної емісії. Функція викупу без тижневого ліміту — це порожній чек для будь-якого зниження балансу.

Обдумайте чітке число для виходу. Це має балансувати між максимально допустимими збитками і потребами користувачів. У разі проблем це — те, що врятує вас від повного руйнування.

Білі та чорні списки

Більшість протоколів мають списки дозволених для викликів, транзакцій або отримання коштів, а також списки заборонених. Навіть якщо вони неформальні, це — межі довіри, які потрібно формалізувати.

Формалізація дозволяє створити двоступеневі механізми управління, ускладнюючи атакам. Атакуючий спершу має додати себе до білого списку (або видалити з чорного), а потім діяти. Мати і білого, і чорного списки означає, що для нових векторів атаки потрібно одночасно зламати обидва процеси: ринок має бути дозволений (інтеграція/лістинг), і дія не має бути заборонена (перевірка безпеки).

Відновлення

Алгоритмічний моніторинг

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

Зупинка і переналаштування

Якщо вас зламали, потрібно зупинити кровотечу, а не ухвалювати рішення у поспіху. Для протоколу це — кнопка «зупинити все» (також має бути у UI): один натиск — і всі шляхи переміщення цінностей призупинені. Створіть скрипт «пауза всього», що перераховує всі зупиняємі компоненти і виконує їх одночасно.

Тільки управління може зняти паузу, тому аварійний режим не може зупинити управлінські контракти. Якщо охоронці можуть зупинити управління — зламана охоронна команда може назавжди заблокувати процес відновлення.

Запустіть командний центр

Замороження, зупинка кровотечі, і залучення всіх довірених осіб (заздалегідь узгоджені