Аппаратные кошельки с поддержкой multisig: оправданы ли затраты на инфраструктуру

Один подтверждённый выход, один seed, один координатор — конфигурация с концентрированным риском.

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

Что multisig устраняет, а какие риски остаются

В типичной Bitcoin-схеме мультиподпись реализуется через скрипт, который принимает M валидных подписей из N. Каждый участник хранит собственную пару ключей. Это обычная M-of-N-схема: Shamir Secret Sharing, threshold signatures и MPC здесь не используются. Для расходования средств нужны подписи нескольких независимых держателей.

Основной выигрыш относится к сценариям компрометации и физической потери:

• кража seed-фразы одного участника не даёт возможности подписать транзакцию в одиночку;
• потеря одного устройства в схеме 2-of-3 оставляет доступ к средствам, если сохранилась резервная копия соответствующего ключа;
• отказ или взлом прошивки одного производителя не раскрывает все средства, если остальные подписанты используют независимые устройства;
• координатор можно заменить, если сохранены данные, необходимые для восстановления multisig-политики и адресов.

Граница защиты проходит по числу скомпрометированных ключей. В 2-of-3 атакующему нужны два ключа для самостоятельного расходования средств. В 3-of-5 нужны три. Это не означает, что скомпрометированный участник не сможет подписать вредоносную транзакцию: он сможет, но в одиночку такая подпись не пройдёт quorum.

Есть и другой класс отказа, связанный с потерей доступа. Здесь число устройств работает в обратную сторону: каждый дополнительный подписант увеличивает число резервных копий, seed-фраз, процедур восстановления и потенциальных точек отказа. В 3-of-5 можно потерять два аппаратных кошелька и всё ещё собрать кворум. В 2-of-3 потеря любых двух подписантов остановит расходование, пока не удастся восстановить ключи.

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

Мультиподпись защищает от компрометации одного ключа только тогда, когда кворум действительно требует нескольких независимых подписантов.

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

Архитектура multisig: descriptor, PSBT и роль софта

Рабочий multisig-контур состоит из трёх слоёв:

1. Политика и деривация. Из публичных ключей участников собирается multisig-скрипт, а из него выводятся адреса. Аппаратный кошелёк хранит приватную часть ключа; наружу передаётся xpub.

2. Координация. Sparrow Wallet или Caravan формирует транзакцию, управляет набором подписантов и собирает частичные подписи.

3. Проверка и подписание. Устройство показывает пользователю адреса и суммы, проверяет соответствие зарегистрированной политике и подписывает нужные входы.

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

Для восстановления стоит сохранить полный descriptor. Если это невозможно, нужно отдельно сохранить все параметры политики: как минимум quorum, тип скрипта, xpub каждого коподписанта и соответствующие пути деривации. Одних xpub и путей недостаточно: без порога подписей и типа скрипта из них нельзя однозначно восстановить прежний контур. Эти данные нужны не только для сборки новых транзакций, но и для поиска средств на уже созданных адресах.

Для передачи частично подписанной транзакции используется PSBT, определённый в BIP-174. Практический цикл выглядит так:

1. Sparrow или Caravan создаёт PSBT с выходами платежа и адресом сдачи.

2. Частично подписанная транзакция переносится на устройство через microSD, USB или QR-код.

3. Устройство показывает фактические назначения и выполняет проверку адреса сдачи.

4. После подписи устройство возвращает частичную подпись координатору.

5. Координатор объединяет подписи и формирует финальную транзакцию для отправки в сеть.

PSBT переносит данные и криптографические подписи. Решение об утверждении транзакции принимает аппаратный кошелёк и человек перед ним. Поэтому наличие PSBT само по себе не означает, что транзакция была проверена устройством.

Sparrow Wallet поддерживает схемы вплоть до M-of-15 и офлайн-подписание через microSD-карты или QR-коды. Caravan заявлен для схем до 7-of-N. Для совместимости между устройствами разных производителей и программными координаторами применяются PSBT, а также форматы QR UR 2.0 и BBQR.

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

Аппаратная база: сравнение устройств и вендоров

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

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

Для 2-of-3 рабочая конструкция может включать устройство с регистрацией политики на самом кошельке, второе устройство другого производителя и третьего подписанта в отдельной зоне ответственности. Если третья роль передана провайдеру, это уже collaborative custody.

В 3-of-5 логика та же, но пять кошельков распределяются между несколькими производителями. Кворум из трёх подписей повышает устойчивость к потере двух устройств. Цена решения — больше оборудования, seed-фраз, резервных копий и согласований.

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

Как выбирать кворум: 2-of-3 или 3-of-5

Наиболее распространены схемы 2-of-3 и 3-of-5. Они дают разный баланс между устойчивостью к потере, стоимостью компрометации и операционным оверхедом.

Выбор кворума — это распределение риска между доступностью и безопасностью. В 2-of-3 любые два ключа образуют потенциально достаточный набор для кражи. В 3-of-5 атакующему нужно собрать три ключа, но каждый участник должен быть доступен для обычных операций.

Отдельно считается риск провайдера. В распространённой схеме collaborative custody два ключа принадлежат пользователю, третий хранится у сервиса для аварийного восстановления. Если третий ключ технически может участвовать в подписании, провайдер является полноправным коподписантом. Формулировка про восстановление не превращает его в наблюдателя. Согласие провайдера и одного пользователя уже дают quorum 2-of-3.

Экономика: DIY, сервис и скрытые издержки

Multisig — не один дополнительный кошелёк. Это комплект оборудования, программный координатор, резервные копии, процедура восстановления и работа с наследованием. Считать только цену устройств некорректно.

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

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

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

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

Инженерная приёмка multisig-контура

Конфигурация становится рабочей только после проверки полного цикла. Простой импорт xpub в интерфейс — подготовка, а не приёмка.

1. Зафиксировать границы доверия. Каждый подписант должен быть определён, у каждого устройства — отдельный владелец или зона хранения. Два кошелька под одним замком в одной комнате слабо улучшают отказоустойчивость.

2. Сформировать набор ключей. Ключи создаются на аппаратных устройствах, наружу передаются только публичные xpub. Полный набор xpub и пути деривации сохраняются отдельно от seed-фраз.

3. Собрать и сохранить политику. Sparrow или Caravan формирует multisig descriptor. Его копия хранится в нескольких независимых местах и включается в план наследования. Если сохраняется не сам descriptor, то отдельно фиксируются все параметры, нужные для его точного восстановления: quorum, тип скрипта, xpub каждого коподписанта и пути деривации.

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

5. Проверить получение. На новый адрес поступает небольшая тестовая сумма. Адрес сверяется на всех устройствах, а не только в интерфейсе координатора. Для Trezor исторически особенно важна ручная сверка ключей всех коподписантов.

6. Проверить сдачу. Формируется транзакция с адресом сдачи. Координатор и каждое подписывающее устройство должны показать один и тот же адрес. Это критическая проверка: скомпрометированный компьютер может подменить именно его.

7. Прогнать air-gapped signing. PSBT переносится через microSD или QR. После возврата частичных подписей проверяются адреса, суммы, комиссия и сборка финальной транзакции.

8. Провести проверку восстановления. Из seed-фраз, сохранённого descriptor или полного набора параметров политики на чистой среде восстанавливаются прежние адреса и выполняется тестовое подписание. Неотработанное восстановление — архитектурная уязвимость, а не бумажная формальность.

Seed-фразы восстанавливают ключи, но не восстанавливают весь multisig-контур. Для прежних адресов нужен полный descriptor либо все параметры политики: quorum, тип скрипта, xpub коподписантов и пути деривации.

Вердикт

Для многих владельцев наиболее рациональная базовая конфигурация — self-custodied 2-of-3: три аппаратных кошелька разных производителей, Sparrow или Caravan в роли координатора, PSBT через офлайн-канал и регистрация политики на каждом устройстве, где она поддерживается. BitBox02 и Ledger подходят для сценария с автоматической проверкой адресов получения и сдачи. Coldcard, Trezor и Blockstream Jade могут участвовать в диверсификации производителей, но конкретную модель и прошивку следует сверять отдельно.

Схема 3-of-5 оправдана, когда необходимо пережить потерю двух устройств, а задержка согласований и дополнительный оверхед приемлемы. Для небольших сумм один аппаратный кошелёк с проверенной резервной копией обычно рациональнее нескольких устройств и сложной координации.

Unchained и Casa имеют смысл, когда владелец покупает поддержку, восстановление и передачу доступа. Их тарифы и роль провайдера нужно включать в модель угроз: третий ключ в 2-of-3 способен участвовать в формировании кворума.

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