6 сентября ровно 3 996.01834922 $BTC покинули резерв Liquid Federation.

Естественно, первые заголовки заставили это звучать так, будто это какой-то взлом биткоина.

Это было не так.

Сеть Bitcoin L1 не была скомпрометирована.

Согласно официальному заявлению SideSwap, злоумышленник сначала создал L-BTC на Liquid через уязвимость в программном обеспечении Elements, а затем передал этот L-BTC через процесс, который выглядел как обычная процедура peg-out.

Федерация сочла peg-out корректным и выплатила реальные BTC в сети Bitcoin mainnet.

https://x.com/liquid_btc/status/2096696272447218108

Так что кто-то не взламывал Bitcoin напрямую.

ПО за федерированным sidechain Bitcoin позволило недействительному L-BTC выглядеть как настоящий L-BTC.

И поскольку федерация считала, что эти активы были законно сожжены, она выпустила реальный BTC из своего резерва.

Это различие — по сути вся история.

Блоки Bitcoin, майнеры, консенсус, криптография и обычные кошельки L1 не были скомпрометированы.

Было затронуто то, что относится к Liquid.

L-BTC, инфраструктура peg и возможность перемещать активы по сети — вот в чём была реальная проблема.

Что мы знаем и чего мы всё ещё не знаем

Что мы знаем:

➛ Около 4,000 BTC вышло из резерва Liquid Federation

➛ «Основная сеть Bitcoin была взломана» — это неправда

➛ SideSwap говорит, что её ключ PAK и инфраструктура не были украдены

https://x.com/side_swap/status/2096709838310928674

➛ Проблема возникла из-за ошибки в Elements

➛ Операции Liquid были остановлены

Чего мы всё ещё не знаем:

➛ Будут ли возвращены все средства

➛ точная общая сумма созданного необеспеченного L-BTC

И я думаю, что важно держать эти две группы раздельно.

Вокруг точной ошибки уже есть много догадок. Но пока мы не получим корректный технический post-mortem, некоторые из этих деталей остаются лишь теориями.

Сначала: что такое Liquid?

Сначала давайте сделаем настройку простой.

Биткоин невероятно надёжен, но сам Биткоин не предназначен делать всё то финансовое, что люди хотят делать с BTC.

Liquid — это отдельная сеть, работающая параллельно с Bitcoin.

Это sidechain.

Однако в отличие от Ethereum или других сетей с открытыми валидаторами Liquid управляется группой институциональных участников, называемой Liquid Federation.

Базовый пользовательский сценарий выглядит так:

  1. Вы отправляете BTC в Liquid. Этот BTC блокируется в резерве Bitcoin mainnet федерации.

  2. Вы получаете L-BTC в Liquid.

  3. Вы можете использовать этот L-BTC в Liquid для более быстрых переводов, конфиденциальных транзакций или других продуктов.

  4. Когда вам нужен BTC обратно, L-BTC сжигается, а федерация выпускает BTC из своего резерва в основной сети Bitcoin.

Liquid защищает этот BTC-резерв с помощью multisig 11-of-15.

Как минимум 11 из 15 функционариев должны подписать, прежде чем BTC сможет выйти из резерва.

Звучит довольно сильно.

И для безопасности ключей это тоже

Но этот инцидент показывает, почему одной только безопасности ключей недостаточно.

Вам не нужно красть 11 ключей, если всем 11 честным подписантам показывают одну и ту же неверную информацию.

Если ПО говорит всем «этот вывод средств действителен», то честные подписи всё равно могут одобрить плохую оплату.

Для меня это гораздо интереснее, чем просто говорить «multisig не сработал».

Так что же на самом деле произошло?

1. Ошибка в Elements заставила неверный L-BTC выглядеть действительным

Liquid работает на программном обеспечении с открытым исходным кодом под названием Elements.

Elements добавляет такие вещи, как конфиденциальные транзакции, конфиденциальные активы и федеративный двусторонний peg поверх инфраструктуры, похожей на Bitcoin.

Заявление SideSwap по этой части довольно ясное:

Использованный в peg-out L-BTC был создан из‑за ошибки в программном обеспечении Elements.

Иными словами, у атакующего был L-BTC, которого не должно было существовать.

Это была не ситуация с украденным паролем от кошелька.

Это была проблема валидации.

Сеть приняла как действительное то, что не должно было быть действительным.

Точная техническая механика ошибки до сих пор не опубликована в полном официальном post-mortem.

Есть утверждения относительно таких вещей, как кэширование rangeproof и компоненты конфиденциальных транзакций, но я бы не считал какие‑либо из них подтверждёнными, пока Blockstream или Liquid не опубликуют техническую расшифровку.

2. Атакующий отправил 4,000 L-BTC в сервис peg-out SideSwap

Согласно SideSwap:

6 сентября, 14:05 UTC

Клиент отправил 4,000 L-BTC в сервис peg-out SideSwap.

С точки зрения системы это выглядело как обычный запрос.

L-BTC был сожжён.

Авторизация peg-out выглядела действительной.

PAK, или Peg-out Authorization Key, — это по сути ещё один механизм контроля, который ограничивает, какие Bitcoin‑адреса могут получать peg-out.

И вот ещё один важный момент:

Ключ PAK не был украден.

Liquid и SideSwap заявили, что ключи PAK и другие ключи для подписи не были скомпрометированы.

Так что ещё раз: проблема была не в том, что кто-то украл ключи и заставил систему отправить BTC.

Сама система считала вывод средств законным.

3. Затем реальный BTC вышел из резерва федерации

В 14:28 UTC Liquid Federation заплатила ровно:

в основной сети Bitcoin.

Вы можете проверить транзакцию Bitcoin здесь: https://mempool.space/tx/8db751a650ae2f12006b7e8c69a75e4df360e8afd6b9e05ae0b9fa6458a7b140

И связанный peg-out Liquid здесь : https://blockstream.info/liquid/tx/ce4caece413cd9d444ce7ed9f54e5b328b3da5e4af301aff59a3571f76e988f2

Так что когда люди говорят «4,000 BTC», они округляют.

Проверяемая оплата в Bitcoin была 3,996.01834922 BTC — на тот момент стоимостью около $318–320M.

Это реальный BTC, который вышел из резервов федерации.

Эта часть не теоретическая.

4. Liquid остановилась

После инцидента Liquid отключила bridge nodes и остановила новые транзакции.

Биржи также начали приостанавливать депозиты и выводы L-BTC.

Так что это было не только проблемой учёта резервов.

Если вы на самом деле использовали Liquid, то и ваша способность передавать, обменивать, выполнять peg-in или peg-out была затронута.

5. Атакующий говорит, что он — вайтхэт

Есть также и эта часть.

Атакующий оставил сообщение в Bitcoin:

«Мы — вайтхаты. Свяжитесь с нами on-chain.»

Но сказать, что вы — вайтхэт, не делает вас таковым.

Пока что, по крайней мере.

Пока средства на самом деле не возвращены, уязвимость добросовестно раскрыта, а ущерб устранён, я думаю, самое безопасное описание — просто такое:

Атакующий заявляет, что он — вайтхэт.

Средства не подтверждены как возвращённые.

Так что пока это всё ещё нерешённый, очень крупный инцидент безопасности.

Почему Bitcoin не взломали?

Потому что с точки зрения Bitcoin ничего недействительного не произошло.

Транзакция имела требуемые подписи.

Майнеры увидели действительную транзакцию Bitcoin.

Консенсус Bitcoin принял это.

Никто не сломал Proof-of-Work.

Никто не сломал криптографию Bitcoin.

Никто не менял лимит в 21M.

У Bitcoin не было способа знать, что учёт внутри Liquid был неверным.

Представьте это как банк.

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

Внутренняя система банка ошибочно сообщает этим подписантам, что клиент действительно владеет $100M.

Они одобряют перевод.

Сам сейф (vault) не отказал.

Процесс авторизации получил неверную информацию.

По сути, в этом и различие.

Итак:

«Bitcoin был взломан» — неверно.

«Федерированная peg Liquid пережила крупный сбой безопасности» гораздо ближе к тому, что реально произошло.

И вот где история становится интереснее

Для меня главный урок — не столько про Liquid конкретно.

Это то, что происходит каждый раз, когда мы берём BTC и делаем его более удобным где-то ещё.

Нативный BTC в вашем собственном кошельке в основном зависит от собственных предположений безопасности Bitcoin.

L-BTC зависит от большего числа вещей.

Консенсус Bitcoin + ПО Liquid

Proof-of-Work + доверие федерации

Ваши ключи + механизм peg

Валидация активов Liquid

И федерация управляет резервом BTC корректно.

Это не означает автоматически, что L-BTC небезопасен.

Это просто означает, что модель риска шире.

Каждый мост, sidechain, продукт с обёрнутым BTC или кастодиан добавляет что-то полезное.

И обычно это ещё добавляет что-то, что тоже должно работать правильно.

11-of-15 звучит безопасно. Но что именно подписывают эти 11?

Это, вероятно, моя любимая часть этого инцидента.

Когда люди думают о безопасности multisig, вопрос обычно такой:

Сколько ключей должен получить атакующий, чтобы украсть?

11-of-15 звучит надёжно, потому что украсть 11 независимых ключей подписи, очевидно, сложно.

Но согласно текущему официальному объяснению, этого здесь не произошло.

Похоже, подписантам представили состояние, которое выглядело корректным.

Так что, возможно, более важный вопрос такой:

Что на самом деле проверяют эти 11 подписантов?

И все ли 11 зависят от одной и той же логики ПО?

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

Это совсем другой тип риска.

И это то, о чём люди говорят гораздо реже.

Даже proof-of-reserves становится сложнее

Обычно очевидный вопрос для чего-то вроде L-BTC звучит так:

Соответствует ли количество BTC, лежащих в резерве, количеству L-BTC в обращении?

Логично.

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

И есть ещё одна проблема.

Если можно создать неверный L-BTC и затем сжечь его в том же процессе, который выводит реальный BTC, то базовый снимок (snapshot), сделанный позже, может не рассказать вам всю историческую картину.

Вы потенциально могли бы посмотреть на систему после события и не заметить, как именно возникло несоответствие.

Но я не хочу идти дальше представленных здесь доказательств.

Это не окончательное суждение о дизайне резервов Liquid.

Это проблема согласования, выявленная в результате инцидента.

Нам нужен полный технический отчёт, сверка резервов и полная учётность mint/burn, прежде чем делать более жёсткие утверждения.

Это системно для Bitcoin?

Я не думаю так.

Около 4,000 BTC — это огромные деньги.

Но по отношению к самому Bitcoin это не является системным шоком предложения.

Безопасность протокола Bitcoin также не была затронута.

Так что я бы не превращал это в рыночную историю «Bitcoin сломан».

Но что насчёт инфраструктуры, строящейся вокруг Bitcoin?

Да, это важно.

Особенно когда BTC оборачивается, мостится, хранится и финансово используется через большее число систем.

Есть ещё одно различие вокруг других активов Liquid.

Liquid заявила, что активы вроде USDT, DePix и RWA не были напрямую скомпрометированы из‑за инцидента безопасности.

Но «не скомпрометированы напрямую» не означает «полностью не затронуты».

Если сеть остановлена, у вас всё равно могут быть проблемы с переводами и ликвидностью, даже если сам токен не был взломан.

Так кто вообще должен об этом беспокоиться?

Если вы храните нативный BTC у себя в кошельке

Этот инцидент напрямую не влияет на безопасность вашего протокола.

Bitcoin L1 не был скомпрометирован.

Если вы держите L-BTC

У вас есть операционное воздействие из‑за привязки Liquid (peg), переводов и перезапуска сети.

То, что остановились peg-outs, свапы и переводы, очевидно, важно.

Если вы держите USDT или токенизированные активы на Liquid

Нет подтверждения, что сами эти активы были взломаны.

Но если Liquid работает не в обычном режиме, доступ и ликвидность всё равно могут стать проблемой.

Если вы используете продукт, созданный на Liquid

Тогда я бы хотел понять, от чего именно зависит этот продукт (от Liquid), какие обеспечительные активы он использует и как выглядит план восстановления/перезапуска.

Моё мнение

Это не был взлом Bitcoin.

И я думаю, что описание таким образом на самом деле скрывает более полезный урок.

Ошибку в Elements позволила необеспеченному L-BTC пройти как то, что выглядело как законный процесс peg-out.

Затем Liquid Federation выплатила 3,996 BTC в основной сети Bitcoin.

Ключи, похоже, не были украдены.

Подписи сработали.

Bitcoin работал.

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

И это заметно меняет вопрос безопасности.

Это не только:

сколько ключей защищают резерв?

Это ещё и:

какую именно информацию эти ключи доверяют до того, как подписать?

Bitcoin может быть крайне безопасным, но что-то, построенное на Bitcoin, всё равно может потерпеть неудачу.

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

Но мы также добавляем ещё одно допущение о доверии.

Вот в чём реальная история