27мин. назад
Атака на Kelp DAO: уязвимости DeFi, единые точки отказа и подъём проверяемого интерфейса
В ончейн-DeFi произошёл очередной инцидент на сотни миллионов долларов. 18 апреля злоумышленник воспользовался конфигурацией маршрутизации LayerZero в Kelp DAO: из-за схемы 1 из 1 DVN (без опциональных верификаторов) он смог подделать кроссчейн-сообщения и заставить контракт ошибочно высвободить 116,500 rsETH. Для Aave это вылилось в риск безнадёжной задолженности в диапазоне примерно от 123,7 млн до 230,1 млн долларов — в зависимости от того, как распределяются потери. По масштабу это крупнейший DeFi-инцидент с 2026 года. Важнее другое: он разрушил укоренившееся допущение, будто эффективность, ликвидность и доходность можно незаметно «купить», опираясь на безопасность небольшой группы доверенных промежуточных слоёв.
I. Что именно сломалось в механизме "децентрализации"
Свести историю Kelp DAO к рядовому взлому смарт-контракта — значит недооценить системный сигнал для DeFi. Kelp DAO как liquid restaking-протокол в экосистеме Ethereum принимает ETH и выпускает rsETH — квитанционный токен. Он обращается в мейннете и упакован в стандарт LayerZero OFT, развернут более чем на 20 сетях, включая Base, Arbitrum, Linea, Blast, Mantle и Scroll.
Экономика конструкции проста: весь резерв ETH находится в кроссчейн-контракте на Ethereum mainnet, а rsETH в других сетях — по сути, купоны на погашение из мейннет-резерва. Корректность системы держится на непрерывном паритете: объём заблокированного в мейннете должен всегда быть не меньше объёма, отчеканенного в L2 и других сетях.
Атакующий ударил по этому базовому ограничению. Он сформировал «валидное» на вид кроссчейн-сообщение LayerZero, убедив мейннет-бридж-контракт, что это корректная команда на погашение из другой сети, после чего контракт выпустил 116,500 rsETH.
Ключ к проблеме — настройка верификации LayerZero. В Kelp DAO применялась схема 1/1 DVN: подписи одного валидатора достаточно, чтобы одобрить кроссчейн-сообщение. При этом LayerZero в официальных рекомендациях предлагает 2/2 либо конфигурации с избыточностью через нескольких валидаторов. Риск модели 1/1 исследователи безопасности публично отмечали ещё в январе 2025 года, но в течение 15 месяцев он так и не был устранён.
Поэтому инцидент не сводится к «взломали мост» или «подвели риск-процедуры протокола». Он выявил две наложившиеся единые точки отказа.
Первая — единая точка верификации. DVN задумывался как составная модель безопасности X из Y из N, позволяющая наращивать надёжность независимыми проверками. В Kelp DAO легитимность сообщения фактически свели к предположению: «единственный узел верификации не ошибётся и не будет скомпрометирован».
Вторая — единая точка резерва. Если пробивается пул резерва в мейннете, rsETH в остальных сетях мгновенно перестаёт быть кроссчейн-активом и проявляет природу IOU, полностью завязанного на один мейннет-якорь.
Когда «единая точка верификации» совпадает с «единой точкой резерва», риск перестаёт быть локальным и распространяется по линиям композиционности DeFi. Именно поэтому Aave оперативно заморозила рынки rsETH/wrsETH в нескольких сетях, скорректировала модель процентных ставок WETH и дополнительно заморозила ряд рынков WETH, чтобы не допустить переноса стресса на другие активы. Сам Aave не взламывали, но искажение стоимости залога, сбои в ликвидациях и заёмщики, балансирующие у порога ликвидации, в итоге сформировали для протокола существенный риск bad debt.
Если смотреть шире, логика «передать безопасность в одну точку» характерна не только для мостов и валидаторов. Она скрыта там, с чем пользователь сталкивается каждый день, но почти не обсуждает напрямую: в интерфейсе.
II. От "самостоятельного хранения" к "проверяемому взаимодействию"
В Web3 давно повторяют: Don't trust, verify. В интерпретации Ethereum это означает, что, запуская собственную ноду, вы не обязаны верить чужим утверждениям — вы проверяете данные самостоятельно, не делегируя истину централизованным поставщикам.
Тот же принцип должен работать и при взаимодействии с кошельками и DeFi. Некостодиальные кошельки вроде imToken — это инструмент доступа к аккаунту: окно, через которое вы видите активы, отправляете транзакции и подключаетесь к приложениям. Кошелёк не хранит ваши средства и не контролирует приватные ключи.
Отрасль всё больше ценит self-custody, и всё больше пользователей понимают: децентрализация — это не просто «активы на блокчейне», а прямой контроль пользователей над этими активами. Проблема в другом: усиливая акцент на самоконтроле на уровне активов, индустрия по умолчанию оставила незаметный аутсорсинг на уровне взаимодействия — доверие фронтенду, который интерпретирует смысл транзакций, прогнозирует результат вызовов и определяет, «что именно вы подписываете».
Главный недооценённый риск современного DeFi звучит просто: подписал ли пользователь именно ту транзакцию, которую он считал, что подписывает?
В реальной ончейн-рутинe пользователь почти никогда не взаимодействует с цепочкой напрямую. Перед ним — слои оболочек: веб-интерфейсы DApp, всплывающие окна кошельков, маршрутизация агрегаторов. В перспективе добавятся вызовы, сгенерированные агентами, и подтверждения результатов, где вам будут говорить: "Вы вносите 100 ETH в стратегию", "Вы получаете такую-то годовую доходность" или "Это стандартное разрешение". При этом большинство пользователей не способны самостоятельно проверить, совпадает ли calldata, который подписывается, транслируется и исполняется ончейн, с описанием во фронтенде.
Отсюда и повторяющиеся инциденты — подмена фронтенда, подстановка адресов, мошенническая имитация approvals. На поверхности это разные истории, в основе — одно: подписываемое действие не всегда совпадает с тем, что пользователь думает, что подписывает.
В этом смысле Kelp DAO подсветил не только узкое место верификации в мостовом маршруте. Он также напомнил о другом системном факте: во многих ончейн-сценариях интерфейс остаётся «по умолчанию доверенным», но почти никогда не проверяемым единым узлом отказа. Нажимая "Confirm", пользователь фактически ставит на то, что интерфейс не искажает смысл вызова.
Отсюда появляется концепция "Verifiable UI" — «проверяемого интерфейса». Речь не о красоте фронтенда и не о том, чтобы упростить попапы подписи. Цель — связать то, что показано в интерфейсе, с тем, что будет исполнено ончейн, так, чтобы эту связь мог проверить пользователь, валидировать кошелёк и позже проаудировать.
Практически это означает следующее: перед подписью кошелёк не должен ограничиваться показом шестнадцатеричных данных или описанием, полностью сгенерированным фронтендом. Он должен реконструировать calldata в человекочитаемые, семантически ясные действия. Каждый шаг, описанный интерфейсом, должен иметь ончейн-проверяемое основание, а не опираться на логику «пользователь поверил — значит, верно». Тогда разрыв между тем, что вы думаете, что делаете, и тем, что реально происходит ончейн, начнёт закрываться.
С точки зрения сегодняшнего DeFi проверяемость интерфейса всё ещё сильно недооценена. Если же смотреть на горизонт чуть дальше, она быстро перестанет быть «полезным улучшением безопасности» и станет базовой возможностью, которую нельзя откладывать. Причина — незаметная, но фундаментальная миграция пользовательских путей в Ethereum.
III. Почему "Verifiable UI" станет новой границей безопасности
Если инцидент Kelp DAO вскрыл хроническую проблему единых точек доверия в архитектурах старого DeFi, то "Verifiable UI" соответствует новой фазе, которая уже началась. Карта UX в экосистеме Ethereum явно фиксирует болевые точки ончейн-взаимодействий: ясность транзакций (Transaction Clarity), кроссчейн-потоки (Crosschain Flow), безопасность (Safety & Security). Слепые подписи, усталость от подписаний, трение при бриджинге, фрагментация активов знакомы почти каждому опытному пользователю.
Вывод здесь не в том, что пользователям нужно больше обучения. В ончейн-мире UX и безопасность никогда не были разными вещами. Часто именно непонимание происходящего и есть крупнейший риск.
По мере смены парадигмы с «пользователь кликает шаг за шагом в DApp» на «пользователь формулирует намерение, система исполняет автоматически» проблема будет только усиливаться. В эпоху классического фронтенда человек хотя бы видел кнопки, страницы и окна авторизаций. Даже без полного понимания оставалось ощущение процесса: «я делаю несколько шагов», «это approval или перевод», «я бриджу или депонирую средства». В эпоху агентов этот видимый пошаговый слой резко сожмётся.
Пользователь больше не будет по отдельности открывать Router, Bridge, Vault и Lending Market для подтверждения каждого действия. Он скажет AI-кошельку: "Переведи мой ETH в более стабильную доходную стратегию", "Сделай бридж на Base, контролируя максимальный slippage" или "Разреши этому агенту тратить не больше 100 USDT в течение 24 часов" — и дождётся статуса "выполнено". Эффективность вырастет, но параметры маршрутов, разрешения, последовательности исполнения и промежуточные операции всё чаще будут скрыты от глаз.
На этом фоне imToken обозначил два параллельных вектора. Первый — дальнейшее развитие intent-based взаимодействия, где пользователь сообщает "что хочу", а система находит путь и исполняет. Второй — движение к "Unified & Verifiable UI", где тезис "интерфейс тоже является поверхностью атаки" поднимается до уровня долгосрочного продуктового принципа.
Это подчёркивает и смену роли кошелька следующего поколения. Раньше кошелёк был инструментом подписи, передающим подтверждение пользователя в блокчейн. С вовлечением агентов кошелёк должен стать последним детерминированным контрольным пунктом перед исполнением. AI может понимать запрос, предлагать решения и строить маршрут, но кошелёк обязан превращать вероятностный вывод модели в детерминированное исполняемое содержание, которое пользователь способен проверить, система — валидировать, а правила — принудительно ограничить.
В этом смысле "Verifiable UI" — не про «более продвинутый дизайн». Это новая модель безопасности взаимодействий и недостающий элемент, который некостодиальные кошельки почти неизбежно должны добавить, переходя в следующий этап. Индустрия давно повторяет: "Not your keys, not your coins". В мире intent-driven действий и исполнения через агентов требуется ещё одна формула: ваш интерфейс тоже должен быть интерфейсом, который вы можете проверить.
Вывод
После атаки на Kelp DAO рынок быстро переключился на обсуждение конфигураций DVN, управления рисками LRT, мостовых маршрутов и оценки единых точек отказа. Всё это важно. Но если инцидент на сотни миллионов долларов свести к упрощённому "кто не поставил достаточно подписей в мультисиге", значит его не поняли по-настоящему. Многие ончейн-продукты по-прежнему опираются на единые точки отказа, которых пользователь не видит и не может проверить, даже когда именно они обеспечивают «эффективность, ликвидность и доходность».
Децентрализация — не противоположность эффективности. Это базовый уровень безопасности. Эпоха, когда безопасность строилась на допущениях об одной точке доверия, должна закончиться.