Урок на миллиард долларов: безопасность DeFi смещает фокус с кода на операционное управление

Оригинальный текст: сообщество 登链

Краткое содержание и введение:

За последний год DeFi потерял почти 1 миллиард долларов, и настоящие крупные потери уже не связаны в основном с уязвимостями контрактного кода, а с управлением правами, процессами подписи, социальными атаками, инфраструктурой третьих сторон и рисками межцепочечной композиции. Заимствуя опыт традиционных финансов (TradFi) в операционной устойчивости, трехзащитных линиях, экстренной блокировке, управлении рисками и проверке входных данных активов, а также используя AI для помощи в безопасности, можно одновременно сохранять открытость и композиционность, повышая безопасность пользовательских средств.

Мы не обязаны были терять эти миллиарды

За последние двенадцать месяцев было потеряно около 1 миллиарда долларов из-за инцидентов в DeFi, но большая часть из них могла быть предотвращена.

Начнем с последнего инцидента: 18 апреля — взлом Kelp DAO на сумму 292 миллиона долларов.

AAVE снизился на 15%. В рамках всех развертываний Aave заморозил рынок rsETH, а затем — в целях профилактики — заморозил заимствование WETH. Собственные контракты Aave никогда не были взломаны, но в течение нескольких часов использование WETH на платформе достигло 100%. Те поставщики WETH, которые никогда не взаимодействовали с rsETH, внезапно оказались не в состоянии вывести средства.

Затем появились типичные мнения в крипто-твиттере: мост сломался. DeFi сломался. Вот почему настоящие деньги не идут.

Я считаю, что эти высказывания не отражают сути.

Большая часть этих потерь — это результат атак, по которым уже обсуждались и предлагались решения. Основные потери вызваны привилегированным доступом, подписью, социальными атаками и инфраструктурой третьих сторон, а не отдельными ошибками в смарт-контрактах. Однако эти решения не прописаны в документации DeFi, а находятся в банковских руководствах по управлению рисками, исследованиях операционной устойчивости и операционных playbook, отточенных десятилетиями традиционной финансовой индустрии.

Примером является Kelp.

— это один verifier. Один уязвимый пункт.

Взлом Kelp не связан с ошибками в смарт-контрактах. Истинная причина — в выборе @KelpDAO@ конфигурации децентрализованной сети валидаторов (DVN) на мосте LayerZero, которая использует 1 из 1. По сообщениям, атакующие, связанные с группой Lazarus из Северной Кореи, не взломали сам DVN. Они сначала выявили, какие RPC-провайдеры используют LayerZero DVN. Затем взломали двух из них, чтобы получать фальсифицированные данные. После этого они устроили DDoS-атаку на оставшихся провайдеров, заставив систему переключиться на уже взломанных. В результате DVN подписал ложное межцепочечное сообщение — поскольку других verifier не было, чтобы проверить результат, этого было достаточно.

Один verifier — один уязвимый пункт.

116 500 rsETH было выведено с LayerZero OFT Adapter (управляет токенами на нескольких цепочках) на Ethereum, что привело к утрате поддержки для 16 L2. Атакующие заложили rsETH на Ethereum как залог в Aave, Compound и Euler, и взяли заем на 236 миллионов долларов в WETH, пока об этом не узнали. Теперь все держатели rsETH на L2 фактически имеют претензию на пустой сейф.

Эта очевидная уязвимость была отмечена за двенадцать дней до инцидента.

6 апреля инженер @liliangjya5 из @get_truenorth опубликовал открытый код Claude Code skill, в котором указал на проблему непрозрачности конфигурации DVN, выделил 16 цепочек как основные риски, сравнил их с взломами Ronin и Harmony в 2022 году. Время коммита — публичное, любой может проверить.

[]

Kelp никогда не публиковали порог DVN. В чек-листе интеграции LayerZero явно рекомендуется использовать конфигурацию с несколькими DVN. Однако Kelp выбрали 1 из 1. Никто не заставлял их публиковать или менять.

Через двенадцать дней — 2,92 миллиарда долларов исчезли.

— за последние двенадцать месяцев нельзя отрицать, что DeFi

Взлом Kelp — самый крупный, но не единственный.

  • Еще две недели назад, 1 апреля, — Drift после многомесячной социальной атаки потерял 285 миллионов долларов. Атакующие использовали долговечные nonces Solana для получения действительных подписей администратора, чтобы занести в белый список бесполезный токен как залог и вывести реальные активы. По меньшей мере 20 других протоколов сообщили о пострадавших. После инцидента Drift внедрил специальные signer-устройства, таймлоки для админских операций и пересмотренную мультисиг-главу.

  • 22 марта — Resolv подвергся атаке через внешнюю инфраструктуру. Атакующие проникли в GitHub и облачные сервисы третьих сторон, получив права на подпись minting-процессов, создали 80 миллионов USR без поддержки backing и украли 25 миллионов долларов ETH. Смарт-контракты остались целы, уязвимы — привилегированные ключи и операционная инфраструктура.

  • 10 марта — внутренние инструменты риска Aave при несоответствии параметров двух оракулов вызвали ликвидацию примерно на 26 миллионов долларов, затронув 34 аккаунта. Цена wstETH упала на 2.85%. В этом случае не было злонамеренного актера или взлома. Потеря связана с добросовестным обновлением конфигурации, которое не было протестировано на враждебных сценариях.

  • Еще до начала 2026 года — Cetus на Sui потерял 223 миллиона долларов, Cork после нескольких аудитов — 12 миллионов долларов из-за wstETH, Balancer в ноябре — более 120 миллионов долларов, а Aerodrome — не из-за ошибок в смарт-контрактах, а из-за DNS-хакерской атаки на регистратор, потеряв более 1 миллиона долларов. Вновь подчеркиваю: сами контракты не пострадали. Последний удар нанес фишинг-страница.

Итого — почти 10 миллиардов долларов убытков. Причины разные, но формируется определенная модель.

— эти взломы перешли в оффчейн

Риски смарт-контрактов не исчезли — Cetus, Cork и Balancer — это реальные сбои onchain логики. Любой протокол, считающий invariant testing, adversarial simulation и formal verification необязательными, скоро узнает цену. Но это уже не основная тема.

Глядя на всю крипту, Chainalysis оценивает, что в 2025 году было украдено свыше 6,5 миллиардов долларов, из которых только три крупнейших хакерских взлома составили 69%. Как уже упоминалось, основные потери вызваны привилегированным доступом, подписью, социальными атаками и инфраструктурой третьих сторон, а не отдельными ошибками контрактов.

Я вижу три основные модели неудач: Code layer, Control plane, Composability.

  1. Код — это слой, в котором DeFi наиболее хорошо защищен, однако и он еще не полностью решен. У нас есть fuzzing, статический и динамический анализ, формальная верификация, bug bounty, аудиты, invariant testing — сейчас каждый серьезный проект знает, что делать.

  2. Control plane — это область, в которой DeFi отстает от TradFi минимум на десятилетие. Аппараты для подписи, ротация ключей, проверка привилегий, provenance CI/CD, усиление DNS, безопасность регистраторов. Большинство протоколов даже не имеют полного инвентаря этих поверхностей, не говоря уже о контроле.

  3. Композиционность — одна из сильных сторон DeFi, но одновременно — и самый недооцененный риск. Когда рынок займа включает в себя wrapped-актив, он превращает fail mode моста в свой собственный. Когда залоговая позиция принимает токен с ленивым стейкингом, она наследует задержки в управлении. Aave не писал код Kelp, но пострадал от его провала — что выявляет проблему его governance.

Если протокол включает актив, который он не может самостоятельно оценить, заморозить, применить haircut или ликвидировать в стрессовых условиях, — он фактически переносит tail risk этого актива на баланс. И независимо от одобрения казначейства.

— традиционная финансы давно написали playbook

Обсуждение о том, чтобы стать “более похожим на TradFi”, зачастую уводит в сторону. В крипте интуиция такова: стать более похожим на TradFi — значит медленнее, более кастодиально, более разрешительно, с большим регулированием.

[]

Я считаю, что это неправильно.

Хотя TradFi и не идеальны, она придумала гораздо более полезные механизмы, чем permissioning. Она разработала способы работы критических систем во время сбоев — эти рамки уже существуют. Они прошли проверку десятилетиями банкротств, сбоев транзакций, кибератак и операционных аварий.

Примеры:

  • NIST Cybersecurity Framework 2.0 — выделяет управление (Govern) как отдельную функцию наряду с Identify, Protect, Detect, Respond и Recover.

  • Basel Committee on Banking Supervision — определяет операционную устойчивость как способность обеспечивать критические операции во время сбоев.

  • Финансовая служба Великобритании (FCA) — требует от компаний выявлять важные бизнес-сервисы, устанавливать impact tolerances и тестировать, не превысит ли сбой эти лимиты.

  • Institute of Internal Auditors — через модель Three Lines разделяет управление, риск и независимую проверку.

Все эти практики не требуют наличия активов или разрешений, их можно легко адаптировать в DeFi. Безопасный DeFi — это не превращение в банк, а сохранение открытости и композиционности на пользовательском уровне, при этом внедряя банковскую дисциплину на контрольном уровне.

Когда Lazarus атаковали RPC-провайдеров LayerZero, они использовали тот же playbook, что и при атаках на SWIFT и цепочки поставок корпоративного программного обеспечения. В этом вопросе у традиционной финансовой индустрии — тридцатилетний опыт. А DeFi, похоже, считает, что из этого ничего не можно почерпнуть.

— привилегии — это системно важная utility

Привилегии должны быть сложнее в использовании, чем обычные функции протокола. Любой ключ, multisig или сервисный аккаунт, который может выставлять залог, перемещать резервы, обновлять оракулы, менять пиров моста или логику ликвидации, — это системно важная финансовая utility. Минимальный стандарт:

  • Аппаратные кошельки

  • Защита от фишинга

  • Независимый signer

  • Внецепочечное декодирование транзакций

  • Разделение quorum

  • Таймлоки для всех неэкстренных операций

  • Ясное отказ от функций, которые могут быть использованы для будущего оружейного использования dormant signatures

После инцидента Drift их план по восстановлению — хороший минимальный эталон.

Оффчейн-стек — тоже часть протокола. Управление исходным кодом, CI/CD, облачные IAM, реестры пакетов, домены, DNS, интерфейсы WalletConnect и фронтенд — все это в зоне реальных угроз. Стандарты включают минимальные права доступа, аппаратную аутентификацию, безсекретную деплой, сборки с BOM, воспроизводимость, закрепление зависимостей. На границе угроз — блокировки регистраторов, усиление DNS и децентрализованные зеркальные фронтенды, обеспечивающие непрерывность в случае аварии.

DNS-хак Aerodrome напоминает, что границы безопасности шире, чем кажется большинству команд.

Каждое изменение должно тестироваться на worst-case сценариях. Verifier для межцепочечных мостов должен проверять proof, а не attestation. Канонический мост — это проверка merkle proof подписанных блоков, что обеспечивает криптографическую гарантию: взломанный узел может отказать в предоставлении данных, но не подделать их. Проверка proof — сильнее attestation, но мосты на основе proof все равно наследуют риски консенсуса, реализации и обновлений. Вопрос — какие сбои исключены, а какие остаются.

Verifier на базе attestation не дает таких гарантий. Он подписывает любой ответ RPC-эндпоинта, что увеличивает поверхность атаки. Если attestation используется для скорости или совместимости цепочек, то quorum — это показатель независимости, а не количества. Пять валидаторов, читающих один и тот же зараженный RPC, подпишут ложь пять раз. Только при наличии действительно независимых источников данных безопасность достигается, желательно — с миксом приватных и доверенных публичных узлов. Kelp — пример, как злоумышленник использует этот пробел.

Не все залоги стоит включать в общий баланс. Активы мостов, liquid restaking tokens, доли в vault, синтетические доллары и wrapper-токены — это структурированные продукты. Они требуют отдельного onboarding memo, с оценкой рисков и лимитами. В большинстве случаев их лучше держать в изолированных рынках, а не в общем пуле.

Aave еще в апреле 2025 года при ошибке Kelp по over-minting приостановил rsETH. Через год он вернулся на общий рынок — и это требует более строгого контроля.

Обнаружение и реагирование должны работать на машинном уровне. Когда протокол может быть взломан за несколько минут, ручное управление — это спектакль. Необходима автоматизация: обнаружение аномалий в операциях администратора, mint/burn, рост использования, отклонения оракулов, трафика мостов — с помощью встроенных лимитов, ограничений заимствований и автоматической блокировки по заранее заданным условиям, которые могут быть проверены и откатаны через governance.

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

— управление должно определять, что не может потерпеть сбой

Чтобы помочь командам определить цели безопасности, governance должна четко прописать, что абсолютно недопустимо потерять. Совет директоров, фонд или DAO должны ясно указать важнейшие бизнес-сервисы: депозиты и выводы, ликвидации, обновление оракулов, исполнение governance, вход и выход через мосты, фронтенд, коммуникации по инцидентам.

Для каждого сервиса необходимо установить impact tolerance — максимально допустимый ущерб пользователям, платежеспособность, время простоя и неопределенность данных — и протестировать, выдержит ли сценарий серьезный, но реалистичный сбой.

Это и есть смысл операционной устойчивости в банках, и его можно прямо перенести в DeFi.

DeFi должен внедрить модель трех линий:

  • Первая линия: продукты, инженеры, казначейство и операционные службы отвечают за риски и контрольные меры.

  • Вторая линия: независимые функции по управлению рисками и безопасности — с четкими полномочиями — вызывают вызовы при листингах, настройках, обновлениях и взаимодействии с контрагентами, замедляя или блокируя опасные изменения.

  • Третья линия: независимый аудит подтверждает, что первая и вторая линии действительно работают.

Независимость — это способ предотвратить рост мотивации к самоподдержке.

Asset onboarding должен напоминать кредитное одобрение, а не бизнес-развитие. В мемо должны входить оценки ликвидности, концентрации, централизации управления, путей мостов и обновляемости, механизмов выкупа, circuit breaker, построения оракулов и юридического оформления. Если хотя бы один из этих аспектов нарушается, мемо должен иметь четкий план по снижению уровня риска.

Аварийные полномочия должны быть узкими, заранее определенными и с установленным sunset. Взлом Sui или голосование по восстановлению Cetus показывают два аспекта — экстренное вмешательство может спасти сотни миллионов, но поднимает вопрос: кто и по каким критериям может вмешиваться в системы, которые по сути должны быть недоступны? Ответ — до запуска, а не в кризисной ситуации, с четкими условиями триггера, полномочиями, стандартами доказательств, максимальной длительностью и прозрачностью.

Каждый протокол должен иметь план решения кризиса, подготовленный заранее. Drift создает recovery pool постфактум. Aave после несоответствия оракулов — компенсирует пострадавших. Resolv — возвращает средства по 1:1 постфактум. Это разумные меры, но более строгий стандарт — заранее одобренный waterfall: сначала защита пользователей, затем казначейский резерв, далее — страховые фонды или модули безопасности, потом — ответственность сервис-провайдеров, и четко прописанные лимиты на социальные потери.

Отличие протоколов, серьезно относящихся к управлению, — в трех вопросах: кто может остановить опасный запуск? Кто может заморозить рынок при предопределенных условиях? Кто заплатит, если делегированный сервис-провайдер нанесет ущерб?

Протокол, не способный назвать ответственных, условия триггера и ответственность, — не определил свою governance, а просто надеется, что взлома не произойдет.

— риск-данные определяют успех или провал контроля

Безопасный DeFi требует live data plane: onchain и offchain сигналы, которые управляют заморозками, лимитами и ликвидациями. control plane — действует, data plane — сообщает, когда и что нужно делать.

Стандарты данных и сами данные важны одинаково. Входные данные для оракулов, заморозок и изменений параметров должны иметь четкое окно актуальности, provenance, уровень доверия и кросс-проверку с независимыми источниками. В случае расхождения — заранее прописаны fallback-методы, а не решения в последний момент.

Aave предложил risk-managed oracle для USDe и взвешенный по времени Slope2 Risk Oracle — правильное направление. Событие с wstETH напоминает: любой автоматический цикл контроля должен иметь защиту от ошибок конфигурации.

Раскрытие информации — тоже контроль. У пользователей должна быть публичная страница статуса, список подозреваемых адресов, лог инцидентов в реальном времени, быстрый и точный initial statement, а также post-mortem — с разделением фактов и гипотез, точной оценкой потерь, списком изменений и объяснением путей компенсации. Отчеты Drift, Resolv и Aave — лучше, чем молчание после неясных твитов. Стандарты индустрии — это заранее отработанный communication playbook.

Риск-данные нужны для принятия решений. Ограничение кредитов, снижение лимитов, приостановка рынков, обновление вручную, подтверждение безопасности — все это должно управляться автоматизировано. Аналитика, которая не влияет на control, limit или assurance — не заслуживает называться risk infrastructure.

— AI-угрозы изменились

В апреле 2026 года произошли изменения в модели угроз AI. Claude Mythos Preview от Anthropic доказал способность выявлять и эксплуатировать zero-day уязвимости в большинстве ОС и браузеров. Более 99% обнаруженных уязвимостей еще не опубликованы, потому что патчи не выпущены. Банки и регуляторы в Великобритании, США и Германии уже воспринимают возможности Mythos как реальный cyber risk.

DeFi протоколы должны поступать так же.

С практической точки зрения, spear-phishing становится дешевле, разработка эксплойтов — быстрее, разведка — более автономной, а малосигнальные кейсы — обнаруживаются раньше. Защита и реакция должны включать:

  • Защищенные рабочие станции разработчиков, как привилегированные endpoint

  • Анализ кода с помощью AI в контролируемом доступе

  • Защиту workflow signer от фишинга по умолчанию

  • Обнаружение аномалий и ограничение автоматических ответов, предполагающих, что злоумышленник действует быстрее любой команды

Kelp — пример оптимистичного сценария. Тот же AI, который угрожает протоколу, может его и защитить. Открытый аудит на Claude Code за двенадцать дней до атаки выявил точные риски Kelp. Он не идеален: оценка риска — medium, а должна быть critical; не может проникнуть без onchain verification; и, что важно, конфигурацию DVN можно проверить через LayerZero EndpointV2 contracts.

Но он задает правильные вопросы, которых никто не поднимал.

Это — модель, которую следует использовать. AI как отдельный уровень безопасности, любой LP, протокол или аудитор могут опережать за счет него.

— безопасный DeFi не означает медленный DeFi

После инцидента с Kelp сложилось мнение, что DeFi — это риск. Я считаю, что это неправда.

DeFi — это вопросы control plane, композиционности и дисциплины управления. У них есть решения, многие из которых прописаны в банковских руководствах тридцатилетней давности. Единственное, что мешает — это нежелание основателей их реализовать.

Безопасный DeFi — это не медленный DeFi. Slow и safe — разные свойства. Открытый доступ, композиционность и глобальные 24/7 расчеты; банковская дисциплина, независимый challenge, машинная скорость и постоянное assurance — все это возможно одновременно.

Инструменты есть. Playbook есть. Капитал для безопасного DeFi — есть.

DeFi только начинается. И мы должны обеспечить его существование еще на десятилетия.

Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
  • Награда
  • комментарий
  • Репост
  • Поделиться
комментарий
Добавить комментарий
Добавить комментарий
Нет комментариев
  • Закрепить