После ряда атак на DeFi в апреле в дискуссиях о безопасности децентрализованных финансов заметен явный сдвиг. Раньше чаще всего проверяли, проходили ли смарт-контракты аудит и есть ли в коде уязвимости; однако основатель Flying Tulip Андре Кронье в недавнем интервью Cointelegraph заявил, что сегодня риски многих DeFi‑протоколов уже заключаются не только в коде на блокчейне, а исходят из прав на обновление, multisig‑управления, инфраструктуры вне сети и операционных процессов команды.
DeFi уже не является неизменяемым кодом
Кронье прямо сказал: если придерживаться строгого определения раннего DeFi — «децентрализовано, неизменно, не требует доверия», — то сейчас многие протоколы фактически уже нельзя назвать чистым DeFi. Он даже включил в это рассмотрение Flying Tulip, заявив, что отрасль сегодня больше похожа на финансовые услуги ради прибыли, которыми управляют команды, а не на полностью неизменяемую публичную финансовую инфраструктуру.
Он сказал: «Я считаю, что сегодня, включая Flying Tulip, у нас уже нет DeFi. Это не децентрализованные финансы и не неизменяемый код. Это — команды, которые ведут прибыльный бизнес».
Эта позиция вскрывает наиболее неловкую реальность для индустрии DeFi: многие протоколы по‑прежнему используют нарратив DeFi, его оценочные подходы и язык бренда, но в реальной работе они уже давно зависят от большого объёма ручного контроля и off‑chain‑процессов.
Главный риск DeFi больше не только в уязвимостях контрактов
По мнению Кронье, модель безопасности раннего DeFi была относительно простой: после развёртывания протокола смарт‑контракт неизменяем, а основную часть рисков несут пользователи в виде риска логики кода. Но сейчас DeFi‑системы обычно куда сложнее: протоколы могут использовать proxy upgrade для обновления контрактов, управлять ключевыми полномочиями через multisig, опираться на внешних поставщиков инфраструктуры и при инцидентах проводить антикризисное реагирование силами основной команды.
Это означает, что вопросы безопасности расширились от «есть ли баг в коде» до «кто имеет право обновлять контракт», «кто контролирует multisig», «достаточно ли времени‑локов», «может ли быть атакована серверная/управляющая инфраструктура вне сети», «сможет ли команда корректно отреагировать в аномальной ситуации».
Кронье отметил, что в прошлом отрасль по‑прежнему чрезмерно фокусировалась на аудитах смарт‑контрактов, однако в последнее время многие атаки больше напоминают проблемы безопасности, характерные для традиционного Web2 или TradFi, например вторжение в права доступа к инфраструктуре, атаки через social engineering, злоупотребление управленческими процессами или компрометацию узла с одним единственным полномочием.
Иными словами, DeFi не означает, что аудит не нужен, — скорее, одного аудита уже недостаточно. Когда протокол можно обновлять, им можно управлять и в него можно вмешиваться вручную, он должен признать, что несёт и операционные риски, с которыми сталкиваются традиционные финансовые организации.
Flying Tulip добавляет механизм «предохранителя» вывода средств
На этом фоне Flying Tulip недавно добавил механизм «предохранителя» вывода средств (withdrawal circuit breaker): протокол может задерживать или ставить в очередь обработку вывода при обнаружении аномального оттока средств. Кронье подчеркнул, что этот механизм не предназначен для того, чтобы навсегда запретить вывод средств пользователям, и не нужен для произвольной заморозки средств командой. Его смысл — получить краткое «окно реагирования» в ситуации, когда происходит аномалия.
На примере Flying Tulip этот механизм примерно даёт команде около 6 часов. Кронье считает: если команда небольшая, а распределение участников недостаточно глобальное, может понадобиться 12–24 часа или даже больше, чтобы при возникновении атаки завершить внутренние проверки, подписание и выработку мер реагирования.
Логика таких решений очень похожа на остановку торгов или «ворота» риск‑контроля на традиционных финансовых рынках: когда в системе возникает аномальная ликвидность или отток активов, это не означает немедленную отмену всех сделок — сначала система замедляется, чтобы злоумышленники не смогли в течение нескольких минут вывести все средства.
При этом Кронье также отмечает, что механизм предохранителя может быть лишь частью многоуровневой системы безопасности и не должен рассматриваться как панацея. Настоящая защита по‑прежнему должна включать аудит, распределённый multisig, time‑lock, управленческие процессы, механизмы мониторинга и контроль полномочий.
Цена механизма «предохранителя»: защита пользователей или создание нового централизованного «чёрного хода»?
Однако сам механизм предохранителя тут же вызвал разногласия среди разработчиков DeFi. Основатель Curve Finance и Yield Basis Майкл Егоров согласился с тем, что недавние атаки действительно вскрыли off‑chain‑централизованные риски, но к решению в виде «усиления ручного экстренного контроля» он относится с высокой настороженностью.
Егоров отметил, что многие недавние крупные события в DeFi произошли не потому, что взломали сами смарт‑контракты, а из‑за single point of failure вне сети. В качестве примера он привёл события, связанные с rsETH: по его словам, смарт‑контракты Aave, Kelp и LayerZero не были скомпрометированы, а реальная проблема — в off‑chain‑инфраструктуре.
Поэтому, как считает Егоров, если главный риск изначально идёт от людей и off‑chain‑полномочий, то добавление управляемого людьми механизма предохранителя может лишь сильнее сосредоточить власть в руках небольшого числа подписантов или администраторов.
Егорова беспокоит, что если право на экстренное управление позволяет подписантам изменять контракты, приостанавливать вывод средств или вмешиваться в направление потоков капитала, то в случае атаки на подписанта изначально предназначенный для защиты пользователей механизм может, наоборот, превратиться в инструмент для «высасывания» средств хакерами или стать «чёрным ходом» для централизованной заморозки активов. Его вывод: дизайн DeFi должен по возможности сокращать число ручных single point of failure, а не решать проблему, вызванную ручными полномочиями, добавляя ещё больше ручных полномочий.
DeFi нужно признать, во что он превратился
Расхождения Кронье и Егорова на поверхности выглядят как спор вокруг механизма предохранителя, но по сути это спор о самосознании DeFi. Позиция Кронье более прагматична: раз уж многие протоколы — это уже не неизменяемые контракты, а финансовые продукты с правами на обновление, управленческими процессами и операциями команд, то нужно признать эту реальность и внедрить соответствующие меры контроля рисков.
Егоров же ближе к «дефи‑ортодоксу»: если безопасность DeFi строится на децентрализации, то решение не должно заключаться в передаче ещё большего контроля людям — нужно проектировать системы, которые требуют меньшей зависимости от ручного вмешательства.
В итоге оба признают одно и то же: сейчас главная проблема DeFi уже не в том, насколько хорошо написаны контракты, а в том, кому именно доверяет пользователь. Если протокол можно обновлять, можно приостанавливать, можно ставить выводы в очередь и можно изменять ключевую логику через multisig, то пользователь берёт на себя не только риск смарт‑контрактов, а ещё и риск управления командой, риск подписантов, риск инфраструктуры и операционный риск.
Эта статья: DeFi ещё децентрализован? Андре Кронье: примите это — большинство протоколов — поддающийся изменению код. Впервые опубликовано в «Chain News» ABMedia.
