🔐 Ключи украдены, но деньги остались: почему UTXO с ковенантами - единственный щит от тотального опустошения кошельков

В конце октября 2026 года криптоиндустрия пережила один из самых шокирующих инцидентов в своей истории. Злоумышленники, получившие доступ к DevOps-инфраструктуре крупнейшей мировой биржи, за считанные часы вывели активы на сумму около $6.3 миллиарда. Не через взлом криптографии. Не через эксплойт смарт-контракта. А через банальную компрометацию сервисных контейнеров и получение доступа к валидным ключам подписи транзакций.

Под ударом оказались более десяти блокчейнов одновременно: Ethereum, Bitcoin, Tron, Solana, BNB Chain и другие. Основную массу украденного составили высоколиквидные стейблкоины (USDT в сетях Ethereum и Tron, USDC) и нативные монеты (BTC, ETH). На Ethereum хакеры особенно эффективно использовали механизм делегирования EIP-7702, превратив горячий кошелек биржи в управляемый извне контракт-«свипер» (sweeper), который за минуты выкачал более $1.6 миллиарда только в стейблкоинах.

Этот инцидент обнажил фундаментальную проблему, о которой в криптосообществе говорили годами, но которая теперь стала осязаемой: в современных account-based сетях (EVM) компрометация ключа подписи означает абсолютную, ничем не ограниченную власть над всеми средствами аккаунта. Сеть не спрашивает «куда» и «сколько». Сеть спрашивает только «подпись верна?».

Но что, если бы среди украденных активов была монета, в архитектуре которой заложены ковенанты (covenants) - жесткие правила расходования, вшитые прямо в монеты на уровне протокола? Что, если бы даже с валидной подписью хакер физически не мог вывести средства на произвольный адрес?

В этой статье мы проведем глубокий архитектурный разбор. Мы не будем слепо рекламировать какую-то одну сеть. Мы разберем, почему модель UTXO с ковенантами меняет парадигму кастодиальной безопасности, как это реализовано в Kaspa, Bitcoin и других сетях, и почему будущее хранения резервов бирж - это не «лучшие ключи», а «умные монеты».

Глава 1. Анатомия катастрофы: что именно произошло на $6.3 млрд 💥

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

Вектор атаки: не криптография, а DevOps

Важно сразу отсечь популярные мифы. Злоумышленники не взламывали:

• Алгоритмы подписи (ECDSA, Ed25519) - они по-прежнему криптографически стойкие.
• Сами блокчейн-сети - Ethereum, Bitcoin, Tron работали штатно.
• Смарт-контракты стейблкоинов (USDT, USDC) - их логика не была скомпрометирована.

Атака была направлена на инфраструктуру вызова подписей: сервисные контейнеры, DevOps-окружение, внутренние системы биржи, которые формируют и подписывают транзакции от имени горячих кошельков. Получив доступ к этому слою, злоумышленники получили возможность формировать валидные с точки зрения протокола транзакции.

АРХИТЕКТУРА АТАКИ НА ИНФРАСТРУКТУРУ ПОДПИСИ

[ БИРЖА ]
  ├─ Пользовательские аккаунты (внутренняя БД)
  ├─ Горячие кошельки (подписывают выводы)
  └─ Холодные кошельки (мультисиг, основное хранилище)

          │
          ▼ (компрометация сервисного слоя)

[ СКОМПРОМЕТИРОВАННЫЙ DEVOPS-СЛОЙ ]
  ├─ Сервисные контейнеры формирования транзакций
  ├─ Хранилища ключей подписи (HSM / KMS)
  └─ API вывода средств

          │
          ▼ (валидные подписи, но от имени хакера)

[ БЛОКЧЕЙН-СЕТИ ]
  ├─ Ethereum (EIP-7702 sweeper) ──> $1.6B+ в USDT/ETH
  ├─ Tron ──> Массовый вывод USDT
  ├─ Bitcoin ──> Вывод BTC
  ├─ Solana, BNB Chain и др.
  └─ Все сети приняли транзакции как легитимные

Роль EIP-7702: как EVM стал оружием против себя

На Ethereum хакеры особенно эффективно использовали стандарт EIP-7702, который позволяет временно делегировать исполнение кода внешнему контракту от имени обычного EOA-аккаунта (Externally Owned Account).

Простыми словами: горячий кошелек биржи, который обычно просто подписывает транзакции, был «перепрограммирован» на лету. Хакеры установили на него контракт-«свипер», который при получении любой входящей транзакции автоматически перенаправлял средства на контролируемый ими адрес. Это создало эффект домино: любые средства, поступавшие на кошелек (включая внутренние переводы биржи), мгновенно уходили к злоумышленникам.

Главный вывод этой главы: в account-based сетях (EVM, Tron, Solana) валидная подпись = абсолютная власть. Сеть не имеет механизмов на уровне протокола, чтобы сказать «стоп, эта транзакция выглядит подозрительно». Все проверки - это внутренние правила биржи, которые можно обойти, если скомпрометирована сама инфраструктура подписи.

Глава 2. Две философии: Account-based vs UTXO 🧠

Чтобы понять, почему ковенанты - это прорыв, нужно разобраться в фундаментальном различии двух архитектурных подходов к блокчейну.

Модель аккаунтов (Ethereum, Tron, Solana)

В этой модели есть Аккаунт (абстрактная сущность с балансом) и Ключ (приватный ключ, который управляет аккаунтом). Сеть хранит состояние как таблицу: «Аккаунт A имеет X монет».

Когда вы хотите отправить средства, вы формируете транзакцию: «Перевести Y монет с аккаунта A на аккаунт B», подписываете её ключом от аккаунта A, и сеть проверяет:

1. Валидна ли подпись?
2. Хватает ли средств на аккаунте A?

Если оба условия выполнены - транзакция проходит. Сеть не знает и не проверяет, куда именно уходят средства, с какой скоростью, в каком контексте. Это делает модель невероятно гибкой (отсюда расцвет DeFi, смарт-контрактов), но и невероятно уязвимой при компрометации ключа.

Модель UTXO (Bitcoin, Kaspa, Litecoin)

В UTXO-модели нет понятия «баланс аккаунта». Есть непотраченные выходы транзакций (Unspent Transaction Outputs). Каждая монета - это конкретный UTXO со своей историей, своим значением и, что критически важно, своими условиями расходования, зашитыми в скрипте блокировки (locking script).

СРАВНЕНИЕ АРХИТЕКТУР: ГДЕ ЖИВУТ ПРАВИЛА?

[ ACCOUNT-BASED (EVM) ]
  Правила: "У аккаунта A есть 1000 ETH"
  Контроль: Только через подпись ключа
  Гибкость: Максимальная (смарт-контракты)
  Уязвимость: Ключ украден = всё потеряно

[ UTXO-BASED (Bitcoin, Kaspa) ]
  Правила: "UTXO #12345 может быть потрачен ТОЛЬКО если..."
  Контроль: Подпись + условия скрипта блокировки
  Гибкость: Ограниченная (но достаточная для защиты)
  Защита: Ключ украден, но правила расходования остались

Это различие - не техническая деталь. Это философский водораздел. В account-модели власть у ключа. В UTXO-модели власть у правил, зашитых в монете, а ключ - лишь один из инструментов для соблюдения этих правил.

Глава 3. Парадигма Covenants: когда правила важнее ключа 🛡️

Ковенанты (covenants, от лат. «соглашение», «обязательство») - это механизм, позволяющий встроить в UTXO дополнительные условия расходования, выходящие за рамки простой проверки подписи.

В классическом Bitcoin UTXO имеет одно базовое условие: «Эти монеты может потратить тот, кто предоставит валидную подпись от приватного ключа, соответствующего публичному ключу в скрипте». Ковенанты добавляют к этому контекстные ограничения:

• Куда могут быть потрачены эти монеты (whitelisting адресов).
• С какой скоростью (rate limiting по времени).
• При каких дополнительных условиях (multisig, timelocks, approval от третьей стороны).

Критически важно понимать: эти условия проверяются каждой нодой сети при валидации транзакции. Это не внутренние правила биржи, которые можно обойти. Это закон физики данной блокчейн-сети. Если транзакция нарушает ковенант, она будет отклонена всеми нодами, независимо от валидности подписи.

Типы ковенантов для защиты кастодиальных резервов

Глава 4. Сценарий «Что если бы среди украденного была Kaspa?» ⚙️

А теперь перейдем к самому интересному. Представим, что хакер, получивший доступ к инфраструктуре подписи биржи, пытается вывести средства, часть из которых хранится в сети с нативной поддержкой ковенантов (например, Kaspa).

Что произойдет на каждом этапе атаки?

Попытка 1: Мгновенный вывод на адрес хакера

Действие хакера: Формирует транзакцию на вывод 100 000 монет с горячего кошелька биржи на свой контролируемый адрес. Подписывает валидным ключом.

Реакция сети (Covenant Whitelisting): Каждая нода сети, получив эту транзакцию, проверяет не только подпись, но и условия ковенанта, зашитые в UTXO. В скрипте блокировки монет жестко прописано:

OP_DESTINATION_WHITELIST = [
  "kaspa:cold_wallet_primary_address",
  "kaspa:cold_wallet_backup_address",
  "kaspa:verified_withdrawal_gateway"
]

Адрес хакера не входит в этот список. Транзакция отклоняется нодами сети. Ключ валиден, подпись корректна, но правило протокола нарушено. Монеты остаются на месте.

Попытка 2: Дробный вывод (Smurfing)

Действие хакера: Понимая, что прямой вывод заблокирован, хакер пытается обойти whitelisting, разбив сумму на тысячи мелких транзакций по 10-100 монет, надеясь, что какие-то проскочат.

Реакция сети (Covenant Rate Limiting): В ковенанте монет прописано условие максимальной скорости вывода:

OP_MAX_VELOCITY = 10000 монет / 24 часа
OP_MAX_SINGLE_TX = 500 монет

Сеть отслеживает историю расходования каждого UTXO. Как только суммарный объем выводов за скользящие 24 часа превышает лимит, все последующие транзакции отклоняются, независимо от валидности подписей.

Попытка 3: Изменение правил ковенанта

Действие хакера: Хакер пытается сформировать транзакцию, которая меняет правила ковенанта (например, добавляет свой адрес в whitelist).

Реакция сети (Covenant Time-locks / Vaults): Протокол требует, что для изменения условий расходования необходимо:

1. Истечение временного периода (например, 24 часа с момента инициации).
2. Мультиподпись от независимых хранителей (например, 2 из 3 ключей от разных юрисдикций).

У хакера есть только один скомпрометированный ключ. Он не может выполнить оба условия. Транзакция отклоняется. Более того, за 24 часа служба безопасности биржи обнаружит аномалию и отменит операцию на уровне своих внутренних систем.

Попытка 4: Установка sweeper-контракта (как на Ethereum)

Действие хакера: На Ethereum хакеры использовали EIP-7702, чтобы «перепрограммировать» горячий кошелек. Хакер пытается сделать то же самое в UTXO-сети.

Реакция сети: Невозможно. В UTXO-модели (особенно в сетях без полноценной виртуальной машины, как Kaspa или Bitcoin) нет механизма «делегирования кода аккаунту». Каждый UTXO имеет фиксированный скрипт блокировки, который нельзя изменить без соблюдения условий ковенанта. Хакер не может «перепрограммировать» монету на лету.

Глава 5. Честные контраргументы: почему Covenants - не серебряная пуля ⚖️

Любая технология имеет свои ограничения. Чтобы статья была объективной, мы обязаны показать, где ковенанты не работают или работают не так, как ожидают их сторонники.

Контраргумент 1: Уязвимость ключа управления ковенантом

Если хакер украл не только ключ для траты средств, но и ключ администратора ковенанта (тот, что имеет право изменять правила расходования), защита рушится.

Решение: Ключ администратора ковенанта должен храниться в совершенно другой инфраструктуре, чем ключи для траты. В идеале - это мультисиг-схема с географически распределенными хранителями, требующая физического присутствия и биометрии для изменения правил.

Контраргумент 2: Удар по UX и ликвидности бирж

Жесткие лимиты и таймлоки усложняют мгновенные выводы для легитимных пользователей. Если биржа хочет предложить клиентам «мгновенный вывод 24/7», ковенанты с часовыми задержками создают конфликт.

Решение: Гибридная архитектура. Биржа хранит основную массу резервов в «сейфах» с жесткими ковенантами (холодное хранение), а для оперативных выводов использует «горячие» кошельки с меньшими суммами и более мягкими ковенантами (или без них, но с усиленным мониторингом).

Контраргумент 3: Это не эксклюзив Kaspa

Идея ковенантов активно развивается и в Bitcoin через предложения OP_CAT (конкатенация данных в скриптах) и BIP-119 (OP_CHECKTEMPLATEVERIFY). Эти улучшения позволят создавать Vaults и ограничения на вывод даже в консервативной архитектуре Bitcoin, хотя и с меньшей гибкостью из-за ограничений языка скриптов.

Вывод: Ковенанты - это не «фишка» одной монеты, а общий тренд в индустрии. Разные сети реализуют их с разной степенью зрелости и гибкости.

Глава 6. Реализации Covenants в существующих блокчейн-сетях 🌐

Концепция ковенантов - это не теоретическая абстракция. Различные блокчейн-сети уже реализуют или активно разрабатывают механизмы жестких правил расходования на уровне протокола. Давайте посмотрим на ландшафт.

ЛАНДШАФТ РЕАЛИЗАЦИЙ COVENANTS

[ KASPA  -  BlockDAG / UTXO ]
  ├─ Нативная поддержка ковенантов с момента запуска
  ├─ Архитектура BlockDAG: параллельные блоки, 10 блоков/сек
  ├─ Гибкие правила расходования без ущерба для скорости
  └─ Идеально для кастодиальных решений высокой нагрузки

[ BITCOIN  -  UTXO / Консервативная эволюция ]
  ├─ OP_CAT (конкатенация данных в скриптах)
  ├─ BIP-119 (OP_CHECKTEMPLATEVERIFY)
  ├─ Ограничения языка скриптов (без полноценной VM)
  └─ Vaults с временными задержками, но менее гибкие

[ ДРУГИЕ UTXO-СЕТИ ]
  ├─ Alephium (eUTXO с расширенными возможностями)
  ├─ Layer-2 решения поверх Bitcoin
  └─ Различные степени зрелости реализации

[ ACCOUNT-BASED (EVM) ]
  ├─ Нет нативных ковенантов на уровне протокола
  ├─ Защита через смарт-контракты (уязвимы к багам)
  └─ Гибкость vs Безопасность: перевес в сторону гибкости

Kaspa: ковенанты как часть ДНК

Kaspa - одна из первых высокопроизводительных сетей, где ковенанты заложены в архитектуру с самого начала. Благодаря архитектуре BlockDAG (параллельные блоки, а не линейная цепь), Kaspa достигает скорости до 10 блоков в секунду, что критически важно для кастодиальных решений, где нужны и безопасность, и производительность.

В Kaspa ковенанты реализованы через расширенный язык скриптов, который позволяет задавать сложные условия расходования без необходимости в полноценной виртуальной машине (как EVM). Это снижает поверхность атак: нет смарт-контрактов, которые можно взломать через баги в Solidity.

Bitcoin: осторожная эволюция через BIP

Bitcoin, как самая консервативная сеть, движется к ковенантам через предложения по улучшению протокола (BIP). OP_CAT позволяет конкатенировать данные в скриптах, что открывает возможности для создания сложных условий. BIP-119 (OP_CHECKTEMPLATEVERIFY) позволяет создавать «шаблоны» транзакций, которые могут быть исполнены только при соблюдении определенных условий.

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

Другие сети: эксперименты и инновации

Alephium реализует модель eUTXO (extended UTXO), которая расширяет классическую UTXO-модель возможностями, близкими к смарт-контрактам, но с сохранением преимуществ UTXO для параллельной обработки.

Различные Layer-2 решения поверх Bitcoin (например, Lightning Network с определенными ограничениями каналов) также используют элементы ковенантов для защиты средств.

Глава 7. Эволюция кастодиальной безопасности: от «Доверяй ключу» к «Доверяй протоколу» 🚀

Взлом на $6.3 миллиарда - это не просто инцидент. Это сигнал индустрии о том, что текущие подходы к безопасности горячих кошельков исчерпали себя.

Старая парадигма: «Доверяй ключу»

Традиционный подход к безопасности бирж фокусировался на защите приватных ключей:

• HSM (Hardware Security Modules): Специализированное оборудование для хранения ключей.
• Мультисиг: Требование нескольких подписей для транзакций.
• Географическое распределение: Хранение ключей в разных юрисдикциях.
• Внутренние лимиты: Программные ограничения на сумму вывода.

Все эти меры полезны, но они имеют общий недостаток: они реализованы на уровне инфраструктуры биржи, а не на уровне протокола блокчейна. Если хакер получает доступ к инфраструктуре подписи, все эти защиты можно обойти.

Новая парадигма: «Доверяй протоколу»

Ковенанты переносят защиту на уровень самого блокчейна. Теперь правила расходования - это не внутренние политики биржи, а закон физики сети, который нельзя нарушить, даже если у вас есть валидная подпись.

Это фундаментальный сдвиг:

Гибридное будущее

Будущее кастодиальной безопасности - это не выбор между «старой» и «новой» парадигмой, а их комбинация:

• Холодное хранение (основные резервы): UTXO с жесткими ковенантами (whitelisting, timelocks, multisig). Компрометация ключа не приведет к мгновенной потере.
• Горячее хранение (оперативные выводы): Меньшие суммы, более мягкие ковенанты или account-based сети с усиленным мониторингом.
• Мониторинг и реагирование: Системы обнаружения аномалий, которые могут инициировать отмену транзакций в период таймлока.

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

Заключение: Математика против человеческого фактора ✅

Взлом инфраструктуры подписи на $6.3 миллиарда - это провал операций безопасности биржи. Но то, превратится ли этот провал в катастрофу или в заблокированную, безвредную транзакцию, зависит от архитектуры блокчейна.

В account-based сетях (EVM) компрометация ключа дает хакеру абсолютную власть. Сеть не задает вопросов. Она исполняет команды.

В UTXO-сетях с ковенантами власть принадлежит не ключу, а правилам протокола. Ключ - это лишь инструмент для соблюдения этих правил. Если правила нарушены, транзакция отклоняется, независимо от валидности подписи.

Сети нового поколения, такие как Kaspa с её нативной поддержкой ковенантов, или Bitcoin с развивающимися улучшениями протокола (OP_CAT, BIP-119), показывают, что будущее кастодиальной безопасности - это не только в том, как мы храним ключи, но и в том, какие правила мы закладываем в саму природу транзакций на уровне блокчейна.

Гибкость EVM прекрасна для DeFi-инноваций. Но для хранения колоссальных резервов жесткие, неумолимые правила UTXO-ковенантов являются единственным надежным барьером между валидной подписью хакера и пустым кошельком.