Social recovery vs multisig: два ответа на потерю ключа

·8 мин. чтения·Автор: SSP Editorial Team
Тёмно-синяя обложка SSP с иконками ключа, щита, отпечатка пальца и замка на тёмном градиенте, глава сравнения social-recovery серии Multisig Deep Dive

Если ты следил за серией, у тебя сложился образ multisig как правила траты: m из n ключей подписывают, chain накладывает порог, деньги двигаются. Мы говорили про протокол, пути деривации и горизонт агрегации Schnorr. На каждом повороте вопрос звучал так: кто должен подписать, чтобы деньги двинулись?

Эта статья — про другой вопрос: что будет, если один из этих подписантов исчезнет навсегда? У multisig один ответ. У social recovery другой. В маркетинговых терминах они кажутся похожими — оба про «более одного человека» — но решают разные задачи. Эта статья — параллельное сравнение, чтобы ты перестал их путать.

TL;DR

  • Multisig отвечает на кто может тратить прямо сейчас. Каждая транзакция требует подписи порога cosigners. Этим управляет сама блокчейн.
  • Social recovery отвечает на кто поможет мне вернуться, если я потерял ключ. У кошелька один обычный подписант (ты). Отдельный набор «guardians» может коллективно одобрить транзакцию восстановления, которая переключает кошелёк на новый ключ.
  • Multisig активен при каждой трате. Social recovery пассивен, пока его не вызовешь — а даже тогда он заменяет ключ траты, а не подписывает твои траты вместе с тобой.
  • Оба защищают тебя от потери доступа. Только multisig реально защищает от того, что атакующий получит доступ, потому что только multisig требует нескольких подписей для обычной траты.
  • Они не взаимоисключающие. Самые устойчивые реальные сетапы сочетают multisig-правило траты с механизмом в стиле social-recovery для ротации одного из подписывающих ключей, если он потерян.

Что на самом деле значит «social recovery»

Social recovery в том смысле, который сделал известным Ethereum, идёт от smart-contract кошельков — Argent был ранним proof of concept, Safe и экосистема ERC-4337 сделали это мейнстримом. Механически: твой кошелёк — это smart contract, в обычной работе управляемый одним подписывающим ключом. У контракта также есть встроенная функция recoverWallet(newKey), которую может вызвать только кворум guardians, назначенных тобой при настройке.

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

Типичный сетап может иметь 5 guardians с порогом 3-of-5 для восстановления. 3-of-5 — это порог восстановления, не траты. Для повседневной траты тебе всё ещё нужен только один свой ключ.

Первородный грех social recovery в том, что он требует smart contract — то есть работает нативно на Ethereum и EVM-сетях (особенно через account abstraction / ERC-4337), но плохо переносится на Bitcoin или другие UTXO-сети. Ближайший аналог на Bitcoin — это multisig, где один из cosigners — это «сервис восстановления или доверенное лицо», а не твоё собственное устройство. Структурно похоже, но концептуально другое — доверенное лицо в варианте Bitcoin подписывает каждую трату, а не только восстановление.

Механика: как каждый из них обрабатывает «я потерял ключ»

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

В 2-of-2 multisig (дефолт SSP): кошелёк заморожен. Для любой траты нужны обе подписи, а у тебя остался только один подписант. Никакого smart-contract трюка для спасения нет; правило траты on-chain — 2-of-2, точка. Твой путь восстановления — вторая seed. Чек-лист self-custody делает оба seed несущими ровно ради этого сценария.

В 2-of-3 multisig (solo-сетап с резервированием из статьи-селектора): кошелёк всё ещё работает. У тебя два ключа из трёх; chain принимает это как валидный кворум. Можешь тратить, можешь перевести средства в новый 2-of-3 кошелёк со свежим третьим ключом, и старый потерянный ключ становится несущественным.

В social-recovery кошельке: кошелёк тоже работает, но другим путём. У тебя нет кворума подписывающих ключей — у тебя один подписывающий ключ (тот самый потерянный). Вместо этого ты связываешься со своими guardians и просишь их подписать восстановительную транзакцию. Когда их порог одобряет, кошелёк переподвязывается к новому ключу траты, который ты контролируешь. Затем возвращаешься к одноключевой трате.

Два восстановления на вид похожи — «попроси кворум доверенных лиц поручиться за меня» — но делают разное. Multisig-восстановление использует существующий кворум, который всегда был. Social recovery активирует латентный кворум, который существует только для обработки именно этого случая.

От чего они защищают (и от чего нет)

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

Где они резко расходятся — это защита от несанкционированной траты.

Multisig защищает от кражи любого одного ключа. Если атакующий фишит твой ноутбук, опустошает hot wallet или крадёт hardware-устройство — у него один из n ключей и он не может двинуть деньги. Полный порог траты не достигнут. Пост о семи режимах отказов из прошлой серии описывает, насколько часто это реально важно: компрометация одного ключа — доминирующий вектор атаки в розничном self-custody, и multisig — ответ.

Social recovery вообще не защищает от кражи одного ключа. В стандартной модели social-recovery твой единственный подписывающий ключ подписывает каждую транзакцию. Если он скомпрометирован, атакующий опустошает кошелёк немедленно — и процесс social recovery не помогает, потому что средства уже ушли до того, как guardians успеют вмешаться. Recovery — инструмент против потери, не против кражи.

Можно их совмещать: smart-contract кошелёк может реализовать и multisig-правило траты, и механизм ротации в стиле social-recovery. Современный стек ERC-4337 (см. объяснение account abstraction для контекста протокола) делает это композируемым. Но чистый social recovery сам по себе — это история восстановления, не история безопасности.

Прагматичное сравнение

СвойствоMultisig (2-of-2 / 2-of-3)Social recovery
Ежедневный UXПодписывать на каждом подписывающем устройствеПодписывать на одном устройстве
Устойчив к краже одного ключаДаНет
Устойчив к потере одного ключа2-of-2: нет; 2-of-3: даДа (через guardians)
Работает на BitcoinДаНет (нужен smart contract)
Работает на Ethereum / EVMДа (BIP48 / Safe)Да (Argent, Safe, ERC-4337)
Время восстановленияМгновенно (подписать выжившим кворумом)Часы-дни (координация guardians)
Допущение доверияУстройства/люди с подписывающими ключамиGuardians, которым ты веришь, что не сговорятся злонамеренно
On-chain видимостьВиден как multisig-выход (если не Schnorr-агрегирован)Большую часть времени выглядит как одноключевой кошелёк

Два паттерна, которые стоит заметить в этой таблице:

Во-первых, multisig — более широкий инструмент. Работает в большем числе сетей, устойчив к большему числу типов атак и сейчас лучше проаудирован на уровне протокола. Social recovery более UX-дружелюбен когда это вариант, но он уже.

Во-вторых, допущения доверия разные. Multisig доверяет тому, что устройства, на которых хранятся твои подписывающие ключи, не скомпрометированы все одновременно. Social recovery доверяет тому, что достаточное число твоих guardians не сговорится украсть твои средства. Оба разумные модели доверия для правильного пользователя, но это не одна и та же модель.

Когда какой нужен

  • Ты solo-пользователь с одним устройством, и остальной мир — UX-пустыня. Social recovery побеждает. Поток Argent / Safe / smart-account реально опция self-custody с наименьшим трением, а сценарий потери ключа — тот, что переживают большинство новичков. Минус — отсутствие защиты от кражи — ты принимаешь осознанно, в идеале в обмен на балансы меньше пяти знаков.
  • Ты solo-пользователь с нетривиальными активами. Multisig побеждает. Дефолт 2-of-2 SSP поднимает планку против кражи, вариант 2-of-3 добавляет устойчивость к потере, и оба опираются на открытые стандарты, а не на конкретную платформу smart contract. Трение реально, но соразмерно ставкам.
  • Ты организация, партнёрство или семейный офис. Multisig обязателен; social recovery — эргономическая надстройка. Тебе нужен настоящий совместный контроль на каждой трате, не только на восстановлении. Большинство орг. приземляются на правило траты multisig с отдельной аккуратной процедурой ротации ключей, когда подписант уходит.
  • Ты где-то посередине, на Ethereum. Складывай слоями. Smart-contract кошелёк типа Safe может выполнять multisig-правило траты 2-of-3 и поток ротации social-recovery поверх. Туда движется экосистема account abstraction.

Для конкретного сетапа SSP 2-of-2, который использует большинство читателей этой серии, social recovery сегодня — не фича, по дизайну. Оба cosigners — твои, история восстановления — «используй вторую seed», ценность — в дешевом доступе к защите от кражи. Social recovery решает другую задачу, ту, что приходит после «я нормально с custody, теперь сделай проще».

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

Три вывода в архив:

  1. Они не заменяют друг друга. Если кошелёк продаёт «у нас есть social recovery, multisig тебе не нужен», это маркетинг, не инженерия. Recovery защищает от потери; multisig защищает от кражи. Вопросы, на которые они отвечают, не пересекаются.
  2. Твой сетап SSP 2-of-2 — это продукт правила траты. Потеря одного устройства восстанавливается из второй seed, не из кворума guardians. Замыкающая статья серии — Режимы отказов multisig и как SSP их сглаживает — проходит ровно как это восстановление разыгрывается на каждый режим отказа.
  3. Строй вперёд, не вбок. Когда твой стек реально перерастает 2-of-2, следующий шаг — обычно 2-of-3 multisig с географически разделённым ключом, а не social recovery вместо multisig. Статья 2-of-3 этой серии (селектор) подготавливает эту миграцию; статья single-signer multisig, идущая дальше, объясняет, как SSP сохраняет для этого будущего сетапа ощущение одного кошелька.

Поделиться статьёй

Похожие статьи