MPC-кошельки против мультиподписи
И MPC-кошельки, и мультиподписные кошельки обещают один и тот же заголовок: никакой единой точки компрометации. Оба обещание выполняют. Но приходят к этому разными путями, а пути по-разному сказываются на том, что происходит, когда что-то ломается, — а это единственный момент, когда модель безопасности действительно важна.
Эта статья — техническая очная ставка. Если сначала хочется более широкого обзора вариантов самостоятельного хранения, сравнение способов самостоятельного хранения охватывает всё поле, включая аппаратные кошельки и обычные сид-фразы.
Два разных ответа на одну задачу
Задача формулируется одинаково в обоих случаях: один секрет, управляющий всем, неприемлем, значит, полномочия надо распределить.
MPC делит ключ. Концептуально приватный ключ один, но он нигде не собирается воедино. Вместо этого его доли лежат в разных местах, а криптографический протокол позволяет этим долям совместно произвести подпись так, чтобы ни одна сторона не узнала ключ целиком.
Мультиподпись требует нескольких ключей. Здесь действительно есть несколько независимых приватных ключей. Адрес кодирует правило — столько-то из этих ключей должны подписать, — и блокчейн обеспечивает это правило при проверке транзакции.
Различие звучит академично. Это не так. Одно — факт о криптографии, другое — факт о блокчейне. То, что известно сети, определяет, что произойдёт, когда откажет какая-то часть системы.
Как MPC работает на самом деле
MPC — многосторонние вычисления, в этом контексте обычно схемы пороговой подписи — позволяет нескольким сторонам совместно вычислить подпись под сообщением, при том что каждая держит лишь долю подписывающего ключа. У NIST есть проект по пороговой криптографии, если нужна формальная трактовка.
На выходе — одна обычная подпись. В сети транзакция MPC-кошелька неотличима от транзакции, подписанной одним человеком одним ключом. У этого есть настоящие плюсы: работает на любой сети, стоит столько же, сколько транзакция с одной подписью, и не сообщает наблюдателю ничего о вашем устройстве безопасности.
Следствие того же самого свойства — там, где нужна осторожность. Поскольку сеть видит обычную подпись, сеть ничего не обеспечивает и в отношении вашей политики. Сколько существует долей, кто их держит и сколько должны содействовать — это факты о софте и серверах, а не о реестре. Измените софт — измените политику.
Второе, на что смотреть, — хранение долей. Многие потребительские MPC-кошельки держат одну долю в инфраструктуре поставщика. Часто именно это делает возможным гладкое восстановление — и одновременно означает, что дальнейшее существование и содействие поставщика являются несущими элементами вашей схемы. Некоторые конструкции неплохо это смягчают: экспортируемые доли или независимые пути резервирования. Вопрос не в том, можно ли сделать MPC хорошо; вопрос в том, сделал ли это конкретный продукт, который вы рассматриваете, так, чтобы вы могли проверить.
Как мультиподпись работает на самом деле
В мультиподписи политика — часть адреса. В Bitcoin и других UTXO-сетях адрес выводится из скрипта, называющего публичные ключи и порог; трата без достаточного числа действительных подписей попросту недействительна, и её отвергает каждый узел сети. В сетях со смарт-контрактами эквивалент — аккаунт, чей код не действует без требуемых одобрений.
Никому не нужно доверять применение правила, потому что применение правила — это то, что делает сеть. Исчезни завтра всё задействованное кошельковое ПО, правило продолжало бы действовать, и любой, у кого есть ключи и любой совместимый инструмент, по-прежнему смог бы потратить.
Издержки тоже реальны. Вы управляете несколькими ключами вместо одного, резервные копии усложняются, а транзакция становится больше — в Bitcoin больше подписей означает больше байтов и чуть более высокую комиссию. Ваша политика к тому же видна в сети, что является соображением приватности: наблюдатель видит, что адрес 2-из-3, даже если не видит, кто чем владеет.
Что такое мультиподпись и почему это важно разбирает модель подробнее.
Где именно находится SSP
SSP — это мультиподпись 2-из-2, но честность требует здесь уточнения, потому что реализация не одинакова на всех сетях.
В Bitcoin и других UTXO-сетях это нативная мультиподпись на уровне скрипта через BIP-48. Два ключа, один скрипт, обеспечивается консенсусом.
В Ethereum и других EVM-сетях эквивалентного нативного скрипта нет, поэтому SSP использует смарт-аккаунт, проверяющий агрегированную подпись Schnorr, полученную из обоих ключей. Два ваших устройства выполняют протокол в духе MuSig2, и сеть видит одну подпись — механически по форме это ближе к MPC, чем к биткоин-скрипту мультиподписи.
Важно тут не «агрегированная или нет». Важны два факта, верные для каждой поддерживаемой SSP сети:
- Оба ключа генерируются на ваших устройствах и хранятся только у вас. SSP не держит ни доли, ни ключа, ни частичного секрета. На наших серверах нет доли, которую можно потерять, изъять или удерживать как заложника.
- Требование находится в сети. В EVM код смарт-аккаунта не авторизует транзакцию без подписи, которую способны произвести только оба ваших ключа. Этот код развёрнут, открыт и прошёл аудит — это не политика, которую решает применять наш софт.
В Solana это ончейн-программа без создателя и без административного ключа, где адрес хранилища сам по себе является отпечатком набора участников и порога. Другой механизм, та же гарантия.
Если вам интересна криптография агрегации, подписи Schnorr и агрегация мультиподписи объясняет, как одна подпись может требовать двух ключей.
Режимы отказа бок о бок
Модели безопасности лучше всего сравнивать вопросом: что ломается?
Одно устройство скомпрометировано. Обе модели выдерживают. У злоумышленника одна доля или один ключ, и подписать в одиночку он не может.
Поставщик исчезает. Мультиподпись выдерживает: нужны только ключи и правило в сети. MPC выдерживает лишь в том случае, если вы можете получить и использовать свои доли без софта поставщика, а это целиком зависит от конструкции.
Поставщика принуждают действовать. Если поставщик держит долю, её потенциально можно получить по законному принуждению, и в зависимости от схемы этого вместе с другой долей может хватить, чтобы сдвинуть средства. Если поставщик не держит ничего — как в SSP, где оба ключа ваши, — принуждать нечего.
Вы теряете ключ или долю. Это зависит от порога, а не от технологии. Схема 2-из-3 любого из двух типов переживает одну потерю; схема 2-из-2 любого из двух типов — нет. Что будет, если один из ваших ключей скомпрометирован проходит именно по случаю SSP.
Кошельковый софт лжёт вам о том, что вы подписываете. Здесь не помогает ни одна модель, и это стоит сказать прямо. Распределение полномочий защищает от украденного ключа; оно не защищает от одобрения не той транзакции. Поэтому интересный вопрос для обеих моделей — что ваши устройства проверяют независимо перед подписью: декодируют сырую транзакцию или доверяют описанию от сервера.
Где выигрывает каждая
MPC выигрывает на сетях без хороших примитивов мультиподписи, по размеру транзакции и комиссиям, по приватности самой схемы и часто по удобству — особенно в восстановлении, где хорошо сделанный MPC-продукт бывает несравнимо дружелюбнее, чем жонглирование несколькими резервными копиями сид-фраз.
Мультиподпись выигрывает в проверяемости. Правило лежит в реестре. Не нужно верить описанию модели безопасности: можно прочитать адрес или контракт и увидеть политику. Она выигрывает и в независимости: у схемы с ключами, которые держите вы, в модели доверия вообще нет компании.
Нет противоречия в том, чтобы предпочитать разные ответы для разных задач. Небольшой повседневный баланс в хорошо сделанном MPC-кошельке и долгосрочная позиция в мультиподписи с раздельно хранимыми ключами — вполне связная конструкция.
Что спросить, прежде чем связывать себя
Куда бы вы ни склонялись, эти четыре вопроса отделяют сильную реализацию от слабой.
- Кто держит каждый ключ или долю и могу ли я получить их все? Если честный ответ включает «поставщик, и нет», вы выбрали модель с контрагентом.
- Что будет, если поставщик исчезнет завтра? Должен существовать задокументированный путь без него. Проверьте его до того, как он понадобится.
- Где живёт политика? В скрипте или контракте в сети — или в софте? Оба варианта могут быть приемлемы, но переживёт смену софта только один.
- Что каждое устройство проверяет перед подписью? Второй ключ не добавляет ничего, если оба устройства вслепую подписывают присланное сервером. Режимы отказа мультиподписи и как SSP их смягчает проходит по этому и по остальным способам подорвать многоключевую схему на практике.
Если хочется, чтобы модель, на которой построен SSP, объяснили с самого начала, начните с материала что такое мультиподпись 2-из-2. А если тревога, приведшая вас сюда, связана с потерей ключа, а не с потерей контроля над ним, социальное восстановление против мультиподписи разбирает другое семейство ответов.
