Сравнение решений для управления активами Web3: мультиподпись, MPC и CRVA

Автор: Shew, Сянран

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

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

Мультиподписной кошелек: удовлетворительно, но не выдающе

Идея мультиподписного кошелька исходит из простой мудрости: не сосредоточивайте все полномочия в одном месте. Эта мысль давно получила широкое применение в реальности, например, в принципе разделения властей и голосовании в правлении.

Аналогично, в Web3 мультиподписанные кошельки создают несколько независимых ключей для распределения рисков. Наиболее распространенной является модель “M-of-N”, например, в настройках “2 из 3” система создает три закрытых ключа, но достаточно, чтобы любые два из этих закрытых ключей подписали, чтобы разрешить указанному счету выполнять транзакции.

Этот дизайн предоставляет определенную степень отказоустойчивости — даже если потеряна одна из приватных ключей, активы все равно остаются безопасными и контролируемыми. Если у вас есть несколько независимых устройств для хранения ключей, схема мультиподписей будет более надежной.

!

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

Обычное многоподписное решение представляет собой: кошелек Safe и Bitcoin Taproot

Кошелек Safe является одним из самых популярных решений для многофакторной аутентификации, использующим стандартные смарт-контракты на языке Solidity для реализации многофакторной подписи. В архитектуре кошелька Safe каждый участник многофакторной аутентификации контролирует отдельный ключ, в то время как смарт-контракт в сети выступает в роли “арбитра”; только собрав достаточное количество действительных подписей, контракт одобряет выполнение транзакций для связанных аккаунтов.

Преимущества этого метода заключаются в прозрачности и проверяемости: все правила мультиподписей четко закодированы в смарт-контракте, и любой может провести аудит логики кода. Кроме того, пользователи могут добавлять модули к мультиподписному аккаунту, чтобы он имел более丰富功能, такие как ограничение максимальной суммы для каждой транзакции. Однако эта прозрачность также означает, что детали мультиподписного кошелька полностью открыты в блокчейне, что может раскрыть структуру управления активами пользователя.

!

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

!

Следует отметить, что вышеупомянутые обычные алгоритмы мультиподписей поддерживают “M-of-N”, но в последующем описании мультиподписей, основанных на определенных криптографических алгоритмах, некоторые поддерживают только режим “M-of-M”, то есть пользователь должен предоставить все ключи для выполнения транзакции.

Реализация мультиподписей на уровне криптографии

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

1. Мультиподписная алгоритм (Multisignatures). Этот алгоритм подписей поддерживает только режим “M-of-M”, пользователи должны предоставить подписи всех ключей одновременно.

2. Алгоритм пороговой подписи ( Пороговые подписи ). Этот алгоритм поддерживает режим “M-of-N”, но, как правило, его построение сложнее по сравнению с вышеупомянутым алгоритмом многофакторной подписи.

3. Алгоритм разделения ключей ( Secret sharing ). В этом алгоритме пользователь может разделить единственный приватный ключ на несколько частей, и когда пользователь соберет достаточно фрагментов приватного ключа, он сможет восстановить исходный приватный ключ и создать подпись.

Биткойн после обновления SegWit (, внедрившего изоляцию свидетелей, внедрил алгоритм Шнорра, который естественным образом может реализовать многофакторную аутентификацию. А уровень консенсуса Эфириума использует алгоритм BLS с пороговым значением для реализации самой основной функции голосования в системе PoS.

![Шнорр и Тапрут: Динамичный дуэт, встряхивающий сеть!])https://img-cdn.gateio.im/webp-social/moments-c7421c1700b8d77503a380e90ad3e63d.webp(

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

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

) Реальные вызовы многофакторной технологии

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

Более серьезно, мультиподписные кошельки часто переносят риск от управления личными ключами к этапу координации и проверки подписей. Как показал недавний случай кражи на Bybit, злоумышленники смогли обмануть мультиподписного управляющего Bybit, внедрив фишинговый код интерфейса Safe в зависимые от AWS ресурсы. Это показывает, что даже при использовании более современных технологий мультиподписей, безопасность интерфейса и этапов проверки и координации подписей все еще имеет множество уязвимостей.

! []###https://img-cdn.gateio.im/webp-social/moments-18fac951ff23f33f32a1d7151782be3a.webp(

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

MPC: Революционный прорыв

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

! [])https://img-cdn.gateio.im/webp-social/moments-3e0f8cc411f9c5edee87473c9f474c6d.webp(

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

Когда необходимо подписать определенную операцию в блокчейне, все участники могут использовать свои фрагменты ключей для создания “частичных подписей”, а затем с помощью протокола MPC巧妙地 комбинировать эти частичные подписи. В конечном итоге сгенерированная подпись полностью идентична подписи, созданной с использованием единого приватного ключа, и наблюдатели снаружи даже не смогут увидеть, что эта подпись была создана с помощью MPC.

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

) Существенное отличие MPC от мультиподписей

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

! []###https://img-cdn.gateio.im/webp-social/moments-defc997a9dbed36ce34da3c2631d4718.webp(

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

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

) Проблемы, с которыми сталкивается MPC

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

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

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

DeepSafe: построение сети безопасной верификации следующего поколения

На фоне того, что технологии мультиподписи и MPC уже относительно成熟ны, команда DeepSafe предложила более перспективное решение: CRVA (шифрованный случайный верификационный агент). Инновация DeepSafe заключается в том, что она не просто заменяет существующие технологии подписи, а строит дополнительный уровень безопасной верификации на основе существующих решений.

Многофакторная аутентификация CRVA

Основная идея DeepSafe заключается в “двойной страховке”: пользователи могут продолжать использовать свои привычные решения для кошельков, такие как кошелек Safe. После того, как транзакция с множественной подписью будет отправлена в сеть, она автоматически передается в сеть CRVA для дополнительной проверки, аналогично многофакторной аутентификации 2FA в Alipay.

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

Преимущества этой многофакторной аутентификации 2FA заключаются в том, что, даже если процесс многоподписей будет скомпрометирован (например, в случае фишинга в Bybit), CRVA в качестве страховки все равно сможет отклонить рискованные сделки в соответствии с установленными правилами, защищая активы пользователей.

! []###https://img-cdn.gateio.im/webp-social/moments-425718cbadee8e962e697514dbd49b1d.webp(

) Техническое обновление на основе традиционного MPC-решения

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

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

! []###https://img-cdn.gateio.im/webp-social/moments-1b71dbb2881f847407a5e41da7564648.webp(

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

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

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

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

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

! [])https://img-cdn.gateio.im/webp-social/moments-caa631df9f9a68cdab81565ee7b25af0.webp(

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

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

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

Возможно, кто-то спросит, разве каждый узел не знает, выбран ли он, как тогда будет проходить работа? На самом деле, как упоминалось ранее, каждый человек будет генерировать «временные открытые ключи» в локальной среде TEE, и после того как результаты抽签 будут готовы, мы просто транслируем список, и каждый должен передать список в TEE, чтобы проверить, выбран ли он.

! [])https://img-cdn.gateio.im/webp-social/moments-1b4c70d0ea3fc3680e557033d51c11de.webp(

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

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

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

Резюме

Развитие технологии подписи Web3 демонстрирует неустанные усилия человечества в области цифровой безопасности. От первоначального единственного закрытого ключа до мультиподписных кошельков, затем до MPC и новых решений, таких как CRVA, каждое новое достижение открывает новые возможности для безопасного управления цифровыми активами.

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

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