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

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

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

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

Мультиподписной кошелек: сойдет, но не отличный

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

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

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

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

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

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

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

Кроме известного многоподписного решения Safe Wallet в экосистеме 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 ( с изоляцией свидетелей внедрил алгоритм Шнорра, который естественным образом может реализовать мультиподпись. А уровень консенсуса Ethereum использует алгоритм порогового BLS для реализации самой основной функции голосования в рамках системы PoS.

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

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

Реальные проблемы технологии многофакторной подписи

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

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

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

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

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

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

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

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

Существенное различие между MPC и мультиподписью

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

Это различие также проявляется в совместимости. Мультиподписные кошельки требуют родной поддержки блокчейн-сети или зависят от смарт-контрактов, что ограничивает их использование в некоторых местах. В то время как подписи, созданные с помощью MPC, используют стандартный формат ECDSA, который можно использовать в любом месте, поддерживающем этот алгоритм подписи, включая Bitcoin, Ethereum и различные платформы 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 все равно может отклонять рискованные сделки в соответствии с заранее установленными правилами, защищая активы пользователей.

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

В ответ на недостатки традиционных решений по управлению активами на основе MPC, решение CRVA от DeepSafe внесло множество улучшений. Во-первых, узлы сети 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. Релейер восстанавливает все «временные публичные ключи», затем объединяет их и отправляет в функцию VRF на блокчейне, из которой выбираются победители. Эти люди проверяют запросы на транзакции, поступающие от пользовательского интерфейса, а затем на основе результатов проверки генерируют пороговую подпись, которая в конце концов отправляется на блокчейн. (Важно отметить, что релейер здесь также скрывает свою личность и выбирается периодически)

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

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

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

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

итог

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

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

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