Мультиподпись для криптоактивов: сравнение архитектур безопасности

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

Под общим названием «мультиподпись» часто смешивают две разные архитектуры. В Multisig блокчейн или смарт-контракт проверяет правило вида 2-of-3: из трёх назначенных участников транзакцию должны одобрить двое. В MPC участники совместно вычисляют подпись, используя доли ключа. Сеть видит обычную подпись одного ключа, а вычисления остаются за пределами блокчейна.

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

Ончейн-логика Multisig: прозрачные правила и видимая поверхность атаки

В Multisig правило доступа закреплено в блокчейне. В Bitcoin его может задавать нативный скрипт; в Ethereum распространённый вариант — смарт-контракт вроде Gnosis Safe. Контракт хранит участников и порог, а сеть проверяет, достаточно ли подписей для исполнения операции.

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

В простейшем сценарии 2-of-3 три ключа распределены между разными сотрудниками или устройствами. Потеря одного ключа не блокирует доступ, а компрометация одного сама по себе не позволяет потратить средства. Кворум можно усложнить, например, схемами 3-of-5 или 5-of-7. Но увеличение числа подписантов добавляет операционные зависимости: участники должны быть доступны, понимать процедуру подтверждения и проверять содержимое транзакции.

В EVM-кошельках каждый вызов мультисиг-контракта требует исполнения кода. Транзакция также передаёт в сеть несколько подписей. Поэтому комиссия за газ для EVM Multisig может быть в 3–5 раз выше, чем у стандартного перевода с одной подписью. Точное значение в деньгах заранее назвать нельзя: оно зависит от загрузки сети и конкретной реализации.

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

Ончейн-кворум даёт аудитируемое правило доступа. Он не исправляет ошибку в самом правиле и не заменяет проверку контракта.

MPC: ключ как распределённое вычисление

В MPC приватный ключ не создаётся и не хранится целиком в одном месте. Участники получают математические доли, которые используются в совместном протоколе для создания подписи. В блокчейн отправляется стандартная подпись ECDSA или EdDSA. Для сети она выглядит как подпись одного ключа.

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

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

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

Практический выбор зависит от того, что организация считает критичным. Если требуется публично проверяемый кворум и независимая проверка правила сетью, Multisig даёт более прямую архитектуру. Если важнее использовать один адрес в разных сетях и менять участников без ончейн-миграции, MPC может оказаться удобнее. Удобство здесь покупается дополнительной зависимостью от корректности off-chain протокола.

Комиссии и операционный оверхед

Ончейн-операции Multisig дороже стандартного перевода в EVM-сетях: контракт нужно вызвать, а набор подтверждений передать в транзакции. Диапазон в 3–5 раз — ориентир сравнения с обычным переводом, а не универсальный тариф. Реальный расход газа зависит от контракта и состояния сети. Пересчитывать его в фиксированную сумму без привязки к конкретной сети и моменту бессмысленно.

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

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

В MPC resharing может изменить доли без смены публичного адреса. Это упрощает ротацию, но переносит контроль изменений в off-chain-процедуру. Если аудитору нужно подтвердить, что после увольнения участника его доля больше не даёт полномочий, ему придётся изучать механизм ротации и доказательства его корректного выполнения. Одного снимка адреса в блокчейне для этого недостаточно.

Что показывают инциденты: контракт, инфраструктура и люди

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

В 2017 году уязвимость библиотеки Parity привела к заморозке 513 774 ETH. Это пример риска смарт-контрактной логики: средства могут оказаться недоступны из-за ошибки в компоненте, от которого зависит работа кошелька. Кворум сам по себе не гарантирует, что контракт способен корректно исполнять операции во всех состояниях.

В 2022 году при взломе моста Ronin атакующие скомпрометировали пять из девяти ключей, ущерб составил 625 млн долларов. Такой инцидент нельзя корректно описать как провал математики мультиподписи. Порог 5-of-9 был преодолён через компрометацию ключей и инфраструктуры. Механизм кворума сработал согласно своим правилам; проблема заключалась в том, что атакующие получили достаточно полномочий.

Для оценки безопасности мультиподписи в блокчейне эти случаи полезнее рекламных сравнений по числу функций. Они задают конкретные вопросы к архитектуре:

1. Что именно исполняет правило доступа? Для Multisig это контракт или скрипт; для MPC — реализация протокола совместной подписи.

2. Как распределены полномочия и инфраструктура? Несколько ключей на устройствах, подключённых к одной системе управления, могут оказаться одной точкой отказа на практике.

3. Как меняется состав участников? Нужны понятные процедуры отзыва, ротации и подтверждения того, что старые полномочия прекращены.

4. Что произойдёт при недоступности участника или компонента? Кворум, который невозможно собрать в штатной аварийной ситуации, превращает защиту в механизм блокировки.

5. Как проверяется транзакция перед подписанием? Подписант должен видеть сеть, получателя, сумму и значимые параметры вызова, а не только кнопку подтверждения.

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

Как выбрать архитектуру для бизнеса

Выбор решения мультиподписи для бизнеса начинается с модели угроз. Сколько независимых участников требуется для перевода? Кто управляет устройствами и учётными записями? Допустима ли зависимость от конкретного MPC-провайдера? Нужна ли публичная проверяемость состава подписантов? Ответы определяют требования точнее, чем сравнение интерфейсов.

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

Если активы распределены по сетям с разной или отсутствующей поддержкой нативной мультиподписи, MPC обеспечивает совместимость через стандартные подписи. Ротация долей без смены адреса может упростить операционную работу. Цена — требования к доверию в off-chain-протоколе и необходимость самостоятельно подтверждать, как устроены хранение долей, совместные вычисления и восстановление.

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

Жёсткий технический вердикт такой: выбирать нужно не ярлык Multisig или MPC, а проверяемую модель угроз вместе с реализацией. Для ончейн-аудируемого управления подходит Multisig при условии аудита контракта и независимого распределения подписантов. Для мультисетевой инфраструктуры может быть оправдан MPC, если организация способна оценить протокол и не подменяет его проверку доверием к интерфейсу поставщика. Кворум снижает риск единой точки отказа. Архитектуру вокруг него всё равно придётся защищать.