Более 100 тысяч долларов были заблокированы, что подчеркивает важность бездоверительного управления на примере инцидента с замораживанием unibtc

Автор: DeepSafe Research

23 апреля 2025 года пользователь по имени Brain обратился за помощью в Twitter через друга, заявив, что его активы unibtc на сумму более 100 000 долларов были заблокированы официальными представителями Bedrock во время арбитражной операции на одном из биткойн Layer2 блокчейнов.

Согласно информации от W, 17 апреля он обнаружил, что unibtc, выпущенный Bedrock, демонстрирует аномальную цену и отклонился от BTC на одном из биткойн L2 блокчейнов. W считал, что отклонение временное и вскоре произойдет возвращение к привязке, и увидел в этом отличную возможность для арбитража, поэтому перевел часть BTC на этот биткойн L2, обменял их на unibtc и ждал, когда цена вернется к привязке, чтобы продать.

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

Когда он нашел единственный кросс-чейн мост на этом блокчейне, поддерживающий unibtc (названный Free), он получил уведомление: "Торговля требует подписи и авторизации со стороны проекта". W обратился в службу поддержки моста Free, где ему объяснили: "Мультиподписной ключ для кросс-чейна unibtc хранится под управлением Bedrock, без их разрешения пользователи не могут перевести unibtc на другие блокчейны."

Не имея другого выхода, W обратился к представителям Bedrock с вопросом по этому поводу, и их первоначальный ответ был: "Мы можем разрешить вам вывести ваш основной капитал, но сможете ли вы вывести прибыль от арбитража, нужно будет временно проверить."

На этом этапе W осознал, что путь выхода unibtc на этом блокчейне был полностью перекрыт, а его unibtc на сумму около 200 000 долларов был "временно заморожен" — он не мог продать их на этом блокчейне и не мог перевести на другие блокчейны. В этот момент он чувствовал себя совершенно беспомощным и только надеялся на успешное возвращение своего капитала.

Однако отношение представителей Bedrock стало неопределенным — они не уточнили, когда W сможет вернуть свой капитал, и не предоставили никаких письменных обязательств, затягивая процесс под предлогами "проверки рисков" и "технической проверки".

После некоторой задержки Bedrock заявил, что отклонение unibtc произошло из-за того, что на платформе LayerBank кто-то массово заимствовал активы unibtc и начал их распродажу, после чего представители Bedrock предложили W "привлечь LayerBank к ответственности". Однако W долго не получал ответа от LayerBank.

В отчаянии W обратился за помощью к друзьям в Twitter, и после более чем двух недель переговоров он наконец получил активный отклик от официальных представителей LayerBank и Bedrock, что позволило ему успешно вернуть свои активы.

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

Во-первых, анализируя вышеупомянутое событие, мы можем увидеть, что Bedrock, будучи эмитентом unibtc и первоначальным LP ликвидного пула на вторичном рынке, естественно имеет право на выход из вторичного рынка unibtc. Если необходимо ограничить его полномочия, это следует делать через управление, а не технические средства;

Однако, как упоминалось ранее, сговор моста Free с Bedrock в отказе от запросов пользователей выявил явные технические недостатки unibtc на этапах "эмиссия — одноканальное обращение — многоканальное обращение": мост Free, являющийся партнером Bedrock, явно имеет высокую степень централизации.

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

Конечно, подобные случаи, как unibtc, не редкость, и случаи блокировки путей выхода пользователей наблюдаются на многих крупных биржах, а для кросс-чейн мостов или других типов проектов такие случаи с использованием централизационных полномочий также не редкость. В июне 2022 года мост Harmony Horizon был приостановлен из-за хакерской атаки, что привело к приостановке вывода 57 активов. Хотя такое поведение имеет "обоснованные причины", оно все же вызывает у некоторых людей тревогу;

В случае с событием StableMagnet в 2021 году, проект использовал заранее оставленную уязвимость в программе для кражи 24 миллионов долларов, и в конечном итоге в Гонконге и Великобритании было развернуто множество полицейских сил, которые при помощи сообщества смогли вернуть 91% украденных средств. Эти примеры наглядно показывают, что если платформы по управлению активами не могут предоставить услуги без доверия, это в конечном итоге приведет к негативным последствиям.

Тем не менее, Trustless не является чем-то, что можно получить легко. От платежных каналов и DLC до BitVM и ZK Rollup, люди пробовали различные способы реализации, и хотя это может в значительной степени гарантировать автономию пользователей и предоставить надежные выходные каналы для активов, за этим стоят неизбежные недостатки.

Например, платежные каналы требуют от участников мониторинга потенциально злонамеренных действий со стороны контрагента, DLC зависит от оракулов; в то время как BitVM имеет высокие затраты, и на практике существуют другие предположения о доверии; "спасательная капсула" ZK Rollup должна пройти длительный период ожидания, прежде чем ее можно будет активировать, и для этого необходимо сначала остановить Rollup, что требует значительных затрат.

С точки зрения текущего состояния реализации различных технических решений, не было предложено идеального решения для управления активами и выхода, и рынок все еще нуждается в инновациях. В следующем разделе DeepSafe Research на примере решения по управлению активами, выпущенного официально DeepSafe, объяснит бездоверительную схему верификации сообщений, сочетающую TEE и ZK, MPC. Это решение балансирует между затратами, безопасностью и пользовательским опытом, предоставляя надежные базовые услуги для торговых платформ, кросс-чейн мостов или любых сценариев управления активами.

CRVA: Сеть криптографической случайной верификации

В настоящее время наиболее широко используемые решения для управления активами в основном применяют мультиподпись или MPC/TSS для определения, являются ли запросы на перевод активов действительными. Преимущества этого решения заключаются в его простоте реализации, низких затратах и высокой скорости верификации сообщений, но недостатки очевидны — недостаточная безопасность, что часто приводит к централизации. В случае с Multichain в 2023 году 21 узел, участвующий в вычислениях MPC, контролировался одним человеком, что является типичной атакой ведьмы. Этот случай достаточно хорошо демонстрирует, что просто наличие десятков узлов не может обеспечить высокий уровень децентрализации.

В ответ на недостатки традиционных решений MPC/TSS для управления активами, DeepSafe представил множество улучшений в своем решении CRVA. Во-первых, узлы сети CRVA используют форму допуска на основе залога активов, и основная сеть запускается только после достижения примерно 500 узлов; по оценкам, заложенные активы этих узлов будут долго оставаться на уровне десятков миллионов долларов или выше;

Во-вторых, для повышения эффективности вычислений MPC/TSS CRVA будет случайным образом выбирать узлы с помощью алгоритма抽签, например, каждые полчаса выбирая 10 узлов, которые будут выступать в качестве верификаторов, проверяя, должны ли запросы пользователей быть одобрены, а затем генерируя соответствующую подпись для их разрешения. Чтобы предотвратить внутренние сговоры или атаки внешних хакеров, алгоритм抽签 CRVA использует оригинальный кольцевой VRF, сочетая его с ZK, чтобы скрыть личность выбранных узлов, что делает невозможным для внешних наблюдателей видеть, кто был выбран.

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

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

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

2. Каждый час сеть CRVA случайным образом выбирает несколько узлов. Но перед этим все кандидаты должны локально сгенерировать одноразовый "временный открытый ключ" и одновременно сгенерировать ZKP, чтобы доказать, что "временный открытый ключ" связан с "постоянным открытым ключом", записанным на блокчейне; другими словами, каждый должен доказать с помощью ZK, что он присутствует в списке кандидатов, но не раскрывать, кто он;

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

4. Чтобы еще больше предотвратить утечку идентичности, CRVA планирует сделать так, чтобы вы сами не знали, что такое ваш "временный открытый ключ". Процесс генерации временного открытого ключа завершается в среде TEE узла, и вы, работающий в TEE, не можете увидеть, что там происходит.

5. Затем во внутренней среде TEE временный открытый ключ шифруется в "мусорный код" и отправляется внешнему миру, только определенные узлы Relayer могут его расшифровать. Конечно, процесс расшифровки также проходит в среде TEE узла Relayer, и Relayer не знает, к каким кандидатам относятся эти временные открытые ключи.

6. После расшифровки всех "временных открытых ключей" Relayer объединяет их и отправляет в функцию VRF на блокчейне, откуда выбираются выигравшие, которые затем проверяют запросы на транзакции, отправленные пользователем, и на основе результатов проверки генерируют подпись, которая затем отправляется на блокчейн. (Следует отметить, что здесь Relayer также скрывает свою личность и выбирается периодически)

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

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

Реализация схемы самостоятельного управления активами с использованием CRVA

В вышеописанном мы представили основные принципы CRVA и объяснили, как CRVA реализует децентрализованный бездоверительный подход. Далее мы рассмотрим пример биткойн-стабильной монеты под названием HelloBTU, чтобы более подробно прояснить применение CRVA в схемах управления активами.

Как известно, поскольку на блокчейне биткойна отсутствует среда с полной вычислительной мощностью, невозможно напрямую реализовать сложную логику смарт-контрактов, такую как DeFi, поэтому основные решения BTCFi заключаются в том, чтобы мостить биткойн на другие блокчейны для взаимодействия со смарт-контрактами. Смарт-контракты HelloBTU размещены на Ethereum, пользователи могут отправить BTC на указанный адрес получения HelloBTU, а затем официальный мост HelloBTU переведет BTC на блокчейн Ethereum, после чего они смогут взаимодействовать со смарт-контрактами HelloBTU.

Предположим, сейчас пользователь хочет заложить 10 BTC на платформе HelloBTU, конкретные действия заключаются в том, чтобы сначала перевести 10 BTC на адрес Taproot на блокчейне биткойна, для разблокировки которого требуется 2/2 мультиподпись, одна подпись генерируется пользователем, а другая — CRVA.

Здесь рассматриваются несколько ситуаций:

Предположим, 10 BTC поступили на указанный адрес Taproot, и пользователь использует эти 10 BTC для выпуска стабильной монеты, теперь он намерен вернуть BTC. В этом случае пользователь и CRVA генерируют по одной подписи, чтобы разблокировать эти 10 BTC и вернуть их на адрес пользователя. Если CRVA долго не будет сотрудничать с пользователем, по истечении срока блокировки пользователь сможет в одностороннем порядке вернуть эти 10 BTC, эта функция называется "самостоятельный выкуп пользователя".

В другой ситуации BTC, служащие залогом, подверглись ликвидации, и теперь пользователь должен сотрудничать с CRVA, чтобы перевести эти BTC и передать их под контроль одностороннего канала CRVA. Но пользователь может отказаться сотрудничать, в этом случае эти BTC временно застрянут, и никто не сможет их забрать; по истечении срока блокировки эти деньги могут быть переведены CRVA на адрес Taproot, контролируемый CRVA (односторонний канал CRVA);

Здесь есть деталь: срок блокировки BTC, поступающих в односторонний канал CRVA, относительно короткий, в то время как срок блокировки для самостоятельного выкупа пользователя более длительный, другими словами, если CRVA и пользователь не могут сотрудничать, эти BTC в конечном итоге первыми поступят в односторонний канал CRVA. Таким образом, действия пользователя по уклонению от ответственности могут быть эффективно ограничены.

Что касается злоупотреблений со стороны CRVA, поскольку CRVA представляет собой автоматизированную сеть узлов, если в коде, запущенном в момент его первоначального старта, нет злонамеренной логики, то не возникнет ситуации, когда CRVA откажется сотрудничать с пользователем, поэтому это можно практически игнорировать;

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

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

Таким образом, мы в общих чертах изложили схему самостоятельного управления активами DeepSafe для биткойна, а для активов ERC-20 ее принципы аналогичны, здесь не будем углубляться. Что касается упомянутого ранее случая с заморозкой unibtc, если кросс-чейн мост unibtc использовал бы схему самостоятельного управления CRVA, было бы трудно допустить возможность того, что эмитент активов контролирует ситуацию в одностороннем порядке.