Single-signer multisig: как SSP делает два устройства похожими на один кошелёк

Если ты с этой серией с что такое multisig, ты знаешь протокол: более одного приватного ключа должны подписать, прежде чем деньги двинутся. Ты видел селектор m-of-n, монтаж BIP48, горизонт агрегации Schnorr и сравнение с social-recovery. Всё это — машинерия. Эта статья — о переживании.

Честная историческая критика multisig в том, что он был враждебен к использованию. Несколько кошельков, ручная перетасовка PSBT, координирующее ПО, подписные сессии — протокол был крепким, но UX — наказанием. Single-signer multisig — это продуктовая идея, которая это чинит: кошелёк, использующий полное multisig-правило траты on-chain, но ощущающийся — для пользующегося им человека — как один кошелёк с одной кнопкой. SSP построен вокруг этой идеи.

TL;DR

• «Single-signer» не значит один ключ. Это значит, что протокол по-прежнему имеет m из n ключей, но UX подписи сжат в один поток. Пользователь подписывает в одном месте; кошелёк сам разруливает координацию устройство-к-устройству.
• Конкретная форма у SSP: одно браузерное расширение, одно мобильное приложение (SSP Key), одна личность кошелька. Кликнул Send, подтвердил на телефоне, транзакция бродкастится. Случаются две подписи; ты переживаешь одну.
• Выигрыш в том, что выгода порога (устойчивость к краже, отсутствие single-point-of-failure) сохраняется, а стоимость координации падает почти до уровня single-sig-UX.
• Цена в том, что это работает только пока оба твоих устройства достижимы. В момент, когда UX вынуждена выставить мульти-природу — восстановление, замена устройства, восстановление у третьей стороны — абстракция ломается, by design.
• Этот паттерн — ближайшее, что есть к «бескомпромиссному» ответу для solo self-custody в розничном масштабе. Это ставка SSP и всё чаще ставка любого современного multisig-продукта (Coinbase Wallet, развивающаяся история custody Phantom, поток smart-account Safe на Ethereum).

Идеал single-signer: что пользователи реально хотят

Если спросишь self-custody-пользователя, чего он хочет, получишь противоречащие ответы:

• «Хочу, чтобы мои монеты были в безопасности.» — Подразумевает multisig, hardware, резервирование.
• «Хочу подписать транзакцию за пять секунд.» — Подразумевает одно устройство, одно касание.
• «Хочу восстановиться, если что-то потеряю.» — Подразумевает бэкапы seed, резервирование.
• «Не хочу больше никогда записывать seed.» — Подразумевает платформенно-управляемую custody ключа.
• «Хочу, чтобы было дёшево.» — Подразумевает минимальный on-chain след.

Эти цели не выстраиваются в один ряд. История дизайна self-custody-кошельков — это история того, какие цели чтить, а какие вежливо отклонять. Hardware-кошельки чтят безопасность и восстановление ценой UX. Smart-contract-кошельки чтят UX и восстановление ценой cross-chain досягаемости. Чистые hot wallets чтят UX и дешевизну ценой безопасности.

Single-signer multisig — это попытка чтить все пять — частично — путём разделения семантики протокола и семантики интерфейса. Кошелёк всё ещё делает полный multisig-танец on-chain; пользователю просто не нужно участвовать в этом танце больше одного раза за транзакцию.

Как SSP это даёт

Конкретная реализация SSP, простыми словами:

1. На сетапе ставишь браузерное расширение и мобильное приложение (SSP Key). Каждое генерит свой seed, который бэкапишь отдельно (это шаг из чек-листа первой 1000). Два устройства обмениваются публичными ключами; с этого момента они делят одну личность кошелька на уровне протокола.
2. На повседневной подписи кликаешь Send в браузерном расширении, проверяешь транзакцию и одобряешь. Расширение собирает частично подписанную транзакцию и пушит уведомление на телефон. Мобильное приложение показывает детали транзакции, ты тапаешь approve, и приложение производит вторую подпись. Расширение объединяет обе подписи и бродкастит. Общее время: около 8 секунд, когда оба устройства перед тобой.
3. На приёме показываемый адрес — это BIP48-производный multisig-адрес из обоих xpubs. Сканируешь или копируешь его; отправитель не видит ничего необычного. С его стороны это выглядит как любой другой крипто-адрес.
4. На сверке кошелёк показывает балансы, историю, комиссии и т.д. идентично single-sig-кошельку. Никакого отдельного «multisig-экрана». Форма протокола невидима при обычном использовании.

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

Маленькая, но важная деталь: SSP-расширение для браузера и SSP Key не co-located. Они на разных ОС, разном железе, с разными поверхностями атаки. Это то, что делает сетап с двумя подписями реальным барьером против кражи, а не просто лежачим полицейским UX. (Мы это распаковываем в тексте про семь режимов отказов и в Что такое 2-of-2 multisig.)

Что пользователь никогда не видит

Много работы уходит на то, чтобы пользователю никогда не пришлось трогать multisig-сантехнику. В частности:

• PSBT (Partially Signed Bitcoin Transactions) — это толстые структуры данных, которые ходят между cosign-устройствами. В традиционном multisig-сетапе ты копируешь и вставляешь их вручную. SSP сериализует и передаёт их через собственный координационный канал; пользователь видит уведомление, а не base64-строку.
• Обмен xpubs cosigners — событие однократного сетапа. В традиционном multisig ты явно импортируешь xpubs от каждого cosigner. SSP заворачивает это в pairing-поток на сетапе; ты подтверждаешь QR-код или шестизначный код и никогда не трогаешь подлежащий материал.
• Оценка комиссии, обработка сдачи и ротация адресов обрабатываются кошельком ровно так же, как у single-sig-кошельков, несмотря на то, что сам кошелёк под капотом — multisig.
• Redeem script — BIP48-канонический скрипт, описывающий multisig-правило — строится кошельком автоматически. Пользователи его не видят, не одобряют построчно, не должны знать, что он существует. (Они могут увидеть его в блок-эксплорере, если посмотрят, — это самое чистое свойство «покажи свою работу» у multisig-кошельков.)

Вся эта абстракция — необходимая работа, но это также риск — каждый раз, когда протокол скрыт от пользователя, кошелёк берёт на себя ответственность сделать скрытую часть правильно. Аудиторская работа SSP (Halborn) во многом именно про эти невидимые кодовые пути.

Когда перестаёт ощущаться как single-signer

Абстракция не идеальна, и важно знать, где она ломается. Single-signer UX держится, пока оба устройства доступны. Трещины появляются, когда одно недоступно:

• Замена устройства. Когда меняешь телефон, новое устройство нужно перепарировать. Это однократный шаг multisig-координации, который реально виден — кошелёк проводит тебя через показ обоих устройств друг другу заново.
• Восстановление из seed. Если устройство уничтожено, восстанавливаешь его из его seed phrase на новое устройство, потом перепаристеишь. Факт, что у тебя две seeds (по одной на устройство), становится виден в этот момент — иначе, чем при обычном использовании.
• Cross-software восстановление. Если когда-нибудь загрузишь свои две SSP-seeds в multisig-кошелёк третьей стороны (Sparrow, Electrum и т.д.), вся multisig-сантехника становится видимой — это фича, не баг, потому что это доказывает, что твой кошелёк интероперабельный, но это не UX SSP.
• Трата, когда одно устройство офлайн. Кошелёк не может cosign без обоих устройств; это протокол. Увидишь состояние «жду вторую подпись», пока другое устройство не появится онлайн.

Первые три достаточно редки, чтобы реально не портить средний UX. Четвёртое — самая частая точка трения — и правильная точка трения. Если бы кошелёк позволял тратить без второго устройства, это уже был бы не 2-of-2 кошелёк. Это трение и есть безопасность; ты не можешь инжинирно от него избавиться, не убрав свойство, за которое платишь.

Дизайн вокруг single-signer UX

Три принципа дизайна, которым следуют SSP — и другие сов��еменные multisig-продукты — чтобы держать эту абстракцию плотно:

1. Два cosigners должны жить на разных поверхностях угроз. Кошелёк, который кладёт оба cosign-ключа на одну ОС, на самом деле не даёт выгоду безопасности; он просто размазывает одну поверхность атаки на два замка. Разделение SSP между расширением браузера и мобильным приложением навязывает это естественным образом.
2. Канал координации должен быть неподделываемым. PSBT, которое расширение браузера шлёт мобильному приложению, должно быть криптографически привязано к правильному кошельку и правильной транзакции; иначе абстракция становится своей собственной поверхностью атаки. SSP подписывает и валидирует этот материал на уровне протокола.
3. Контракт с пользователем должен честно говорить, что скрыто. Кошельки, заявляющие «полностью trustless single-signer-опыт», не объясняя, что происходит при восстановлении, готовят пользователю неприятный сюрприз. Онбординг SSP явно проводит через обе seeds, оба бэкапа и оба сценария восстановления — абстракция скрыта при использовании, но обнажена при онбординге, чтобы не подкараулить тебя потом.

Account-abstraction-кошельки на Ethereum получают четвёртый инструмент: смарт-контрактный слой. С ERC-4337 кошелёк может поглощать газовые комиссии, батчить транзакции и показывать ещё более «похожий на single-signer» UX и реализовывать multisig под капотом. У SSP этого слоя на Bitcoin нет (нет смарт-контрактов), поэтому абстракция больше опирается на UX-инженерию, чем на поглощение на стороне сети. Оба пути валидны; путь Ethereum гибче ценой chain-специфичности, путь SSP более переносимый ценой большего труда UI.

Что это значит для тебя

Три вывода:

1. Опыт «ощущается как один кошелёк» — это главная фича, а не сам multisig. Если твой друг спросит «SSP — это multisig-кошелёк?», технически правильный ответ — да, но полезный ответ — «это 2-устройственный кошелёк, в котором одно касание на телефоне подтверждает трату». Это схватывает то, что люди реально чувствуют.
2. Трение, которое ты всё-таки видишь, делает реальную работу. Каждый раз, когда SSP просит подтвердить на телефоне, он навязывает протокол, который не даёт скомпрометированному ноутбуку опустошить твои средства. Это трение — главная причина, почему ты вообще пользуешься 2-of-2 кошельком, а не hot wallet.
3. Воспринимай абстракцию как контракт, а не магию. Финальная статья этой серии, Режимы отказов multisig и как SSP их смягчает, проходит, что происходит, когда каждый кусок абстракции ломается — потеря устройства, компрометация ключа, простой сервера подписания. Прочитай её один раз. Абстракция хорошо спроектирована, но понимание режимов отказа — это то, что делает тебя тем типом self-custody-пользователя, ради которого существует вся эта серия.