Social Recovery криптокошелька: где ломается восстановление
Приватный ключ — это единственный ключ, который связывает владельца с адресом кошелька: адрес вычисляется из него, поэтому сбросить пароль по аналогии с почтой или банком здесь не получится. Потеря устройства вместе с локальным хранилищем ключей означает потерю доступа к кошельку: баланс по-прежнему виден в публичном обозревателе сети, но подписать транзакцию уже нечем.
Фраза восстановления задумывалась как страховка, а на практике рвётся первой. Её переписывают в заметки, фотографируют, пересылают себе в мессенджер; при переустановке приложения резервная копия не подтягивается, если номер телефона сменился, а почта, к которой привязан аккаунт, заблокирована. Каждый такой сценарий — тихая потеря доступа без единого уведомления: человек узнаёт о ней в момент, когда хочет отправить средства.
Цепочка доступа ломается там, где все звенья сходятся в одну точку: одно устройство, один носитель фразы, один номер, один аккаунт облачного хранилища. Схема social recovery в ERC-4337 разносит право на восстановление по нескольким хранителям, и отказ любого одного звена перестаёт быть фатальным для аккаунта.
Дальше разбираем, как это закрывается: какая логика хранителей нужна приложению, как пережить смену устройства и номера без остановки сервиса и где проходит граница между удобством и контролем над чужими средствами.
Что даёт внедрение: скорость восстановления и класс отказов
Доступ возвращается за минуты вместо «навсегда потерян»
Ключевой сдвиг — сама возможность вернуть доступ. Раньше потеря устройства вместе с единственной копией ключа означала безвозвратную потерю средств: пользователю оставалось только наблюдать за адресом. С Social Recovery доступ восстанавливается за минуты — человек подтверждает себя у доверенных хранителей, набирает нужный порог подтверждений и снова работает с кошельком на новом устройстве.
Уходит целый класс отказов, а не отдельные случаи
Исчезает не часть проблем, а категория отказов, которую поддержка раньше не могла закрыть в принципе: утрата единственной копии ключа, поломка телефона до создания резервной копии, смена устройства без переноса. Порог подтверждений настраивается под задачу — пользователь сам определяет, сколько хранителей и какое их число должно подтвердить восстановление. Если один хранитель потерял доступ, его заменяют, не пересобирая схему целиком.
Самостоятельное восстановление снимает нагрузку с поддержки
Доля обращений «не могу войти, потерял ключ» уходит в самообслуживание: пользователь проходит сценарий внутри приложения, и поддержка не участвует в выдаче доступа. Это важно и для безопасности — у команды нет и не должно быть возможности единолично восстановить чужой кошелёк. Число обращений о доступе снижается, а оставшиеся касаются настройки хранителей и решаются заметно быстрее.
Варианты восстановления доступа: сравнение подходов
Выбор схемы восстановления определяется условиями эксплуатации, а не вкусом: готов ли пользователь на старте выполнить обязательные шаги, сколько у него устройств, кто отвечает за хранение копий. Разница между подходами — в том, кому доверяется доступ и что происходит, когда один из участников выпадает.
| Вариант | Когда подходит | Ограничения схемы |
|---|---|---|
| Пороговое разделение секрета | Нужна независимость от одной стороны: ключ делится на части, доступ возвращается по порогу из нескольких | Состав доверенных контактов должен быть жив и доступен годами; утечка порогового числа частей равна потере кошелька; при смене состава нужна ротация всех частей |
| Подтверждение доверенными контактами без хранения частей | Аккаунт с программной логикой: хранители лишь одобряют смену владельца | Требует поддержки на уровне аккаунта и сети; окно задержки перед выдачей доступа; хранители уязвимы к социальной инженерии |
| Резервный ключ | Один пользователь, минимальная настройка, редкие смены устройства | Единая точка отказа: потеря носителя — потеря доступа; нет защиты от принуждения; носитель где-то хранится и стареет |
| Хранение частей ключа на стороне сервиса | Нужен сценарий «забыл — вернул доступ за минуты» | Доверие к третьей стороне и её доступности; требования к хранению и раскрытию данных; отказ сервиса блокирует восстановление |
На практике схемы комбинируют: пороговое разделение как основной путь и резервный ключ для крайнего случая, когда часть контактов недоступна. Дальше считаем от числа хранителей, целевого времени восстановления и модели угроз — и уже под неё проектируем экраны настройки и обработку ошибок.
Этапы внедрения: от аудита сценариев до передачи в поддержку
Порядок работ одинаков для любого кошелька — отличается только состав хранителей и глубина интеграции. Мы идём от инвентаризации сценариев отказа до регламентов, по которым поддержка заказчика закрывает обращения без участия разработчика.
-
Аудит сценариев доступа. Собираем, как пользователь получает и теряет доступ: потеря устройства, смена номера, переустановка приложения, отзыв доступа у хранителя. На выходе — карта путей восстановления и список мест, где сейчас обязателен ручной разбор вашей командой.
-
Проектирование схемы восстановления. Фиксируем порог срабатывания, состав и роли хранителей, задержку перед исполнением запроса, правила замены выбывшего хранителя. Схема согласуется документом — до написания кода.
-
Настройка сервиса восстановления. Поднимаем сервис, который принимает доли секрета, хранит их в зашифрованном виде и проверяет подписи запросов. Разграничиваем роли, включаем журнал операций и уведомления участникам.
-
Интеграция в приложение. Экраны запроса и подтверждения, понятные статусы, поведение при обрыве связи — восстановление проходит с телефона, без переписки с поддержкой.
-
Проверка сценариев на учебном контуре. Прогоняем негативные сценарии: хранитель недоступен, доли не сходятся, запрос повторяется, устройство попало к третьему лицу. Замеряем число шагов для пользователя и время до возврата доступа.
-
Передача в поддержку. Отдаём регламенты первой линии, чек-листы эскалации, инструкции по замене хранителя и метрики: какую долю восстановлений команда закрывает самостоятельно.
Что передаём на руки: конфигурации и политики криптокошелька
Social Recovery работает автономно только тогда, когда восстановлением доступа занимается не один конкретный инженер, а описанный процесс. Поэтому передача — это не набор файлов, а рабочие конфигурации, карты ролей и регламенты, по которым ваша команда ведёт кошелёк без нас.
- Схема ролей и доверенных контактов: сколько контактов нужно для порога, как они распределены между устройствами и платформами, что происходит при потере одного или нескольких.
- Политики доступа: задержка восстановления, порог подтверждений, правила замены и отзыва доверенного контакта, ограничения на смену владельца.
- Конфигурации клиентской и серверной части: таймауты, шаблоны уведомлений, сценарии блокировки при подозрительной активности.
- Документация восстановления: пошаговый путь от запроса до возврата доступа, включая ветки с ошибками и отказом в восстановлении.
- Регламент поддержки: сроки реакции, порядок эскалации, хранение журналов операций, точки, где нужен доступ второго инженера.
- Инструкции для пользователей: что видит владелец при потере устройства, как добавить контакт, как инициировать восстановление и что делать при зависании.
Каждый пункт проверяем на тестовом восстановлении: инженер, не участвовавший во внедрении, проходит сценарий по документации без подсказок. Пока он делает это сам — передача не закрыта.
Кейс: восстановление доступа без единой точки отказа
До внедрения
До внедрения доступ возвращали двумя путями: сид-фраза, которую теряли чаще всего, и обращение в поддержку. Второй путь занимал от трёх суток до недели: ручная сверка личности и согласования между отделами.
На доступ приходилось около 40% всего потока обращений, а доля успешных восстановлений держалась на 62% — часть пользователей не доводила проверку до конца и уходила, так и не получив кошелёк обратно.
После внедрения
Мы разложили ключ на доли по пороговой схеме, известной по подходу Argent, и раздали их хранителям: основное устройство, резервное, доверенный контакт пользователя и сервисный узел. Восстановление запускается по порогу «два из трёх» без участия поддержки, а в приложении появилось окно отмены на 48 часов — если устройство на месте, владелец отменяет чужую попытку одной кнопкой.
После перевода на новую схему время восстановления доступа сократилось до 8–12 минут — это весь цикл от запроса до нового ключа. Доля успешных восстановлений выросла до 96–98%: сценарий больше не зависит от человека в поддержке. Обращения по доступу упали с 40% до менее 5% от общего потока.
Попытка восстановления с нового устройства попадает в журнал, а смена состава хранителей требует подтверждения текущим порогом. Метрики снимаем с серверной телеметрии, поэтому видно, на каком шаге сценарий отваливается, если отваливается.
Что делать, если у части пользователей уже есть мультиподпись?
Ничего ломать не нужно: мультиподпись и социальное восстановление закрывают разные задачи. Первая делит право подписи между несколькими ключами — роли, лимиты, общее хранилище; вторая возвращает доступ, когда ключ утрачен. Схемы сосуществуют в одном аккаунте, если конфигурация умеет комбинировать оба набора правил.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Мультиподпись остаётся, восстановление добавляется поверх | участники с аппаратным кошельком и общим хранилищем | две системы прав — нужен регламент подтверждений |
| Поэтапная миграция на пороговую схему | активные пользователи без внешнего носителя | добавляется шаг подтверждения от доверенных контактов |
| Гибрид: мультиподпись для крупных операций, восстановление для доступа | продукты с разными лимитами | сложнее проверки и документация |
Переход — это не новый кошелёк, а смена набора подтверждающих сторон внутри существующего аккаунта. Адрес, история операций и балансы остаются на месте, поэтому переводить активы вручную не нужно и доступ не теряется в момент переключения. Старые подписи принимаются, пока действует окно подтверждения: переход без потери доступа обеспечивает конфигурация, а не пользователь.
Для владельцев аппаратного кошелька схема остаётся прежней: устройство подтверждает операции, а восстановление подключается только как резервный путь. Миграцию пользователей ведём поэтапно — сначала добровольное включение для новых, затем подсказки в клиенте для активных, и только потом смена схемы по умолчанию. Каждый шаг управляется флагом в конфигурации, поэтому откат занимает минуты и не требует обновления приложения у всех сразу.
Совместимость схем проверяем на тестовой сети по сценариям: утрата ключа, замена доверенного контакта, отзыв согласия, одновременная подпись несколькими сторонами. Сценарий, который не проходит на старой версии клиента, блокирует шаг миграции — никто не остаётся между двумя несовместимыми наборами правил.
Технические сомнения: доверие, задержки и хранение данных
Доверие в социальном восстановлении держится не на обещаниях, а на математике: сервис не может собрать ключ в одиночку. Кошелёк делит секрет по пороговой схеме — доли получают владелец и доверенные контакты, а ниже порога (например, три доли из пяти) восстановление невозможно даже при полном доступе к нашей инфраструктуре.
Согласие пользователя фиксируется до активации, а не по факту: экран с перечнем данных, которые уходят на сервер, ролями хранителей и способом отозвать согласие. Задержка восстановления задаётся окном отмены — заявка исполняется спустя время, за которое все хранители получают уведомление, а владелец может остановить операцию.
Кто видит доли ключа?
Сервер хранит только зашифрованные фрагменты. Ключ шифрования выводится на устройстве владельца и у контакта, поэтому администратор сервиса не собирает кошелёк ни в одиночку, ни вместе с коллегами.
Что если доверенный контакт недоступен?
Порог всегда меньше числа хранителей, поэтому один-два выпавших контакта не блокируют восстановление. Состав хранителей меняется перевыпуском долей — адрес кошелька и баланс при этом не затрагиваются.
Где хранятся данные?
В согласованном регионе, в минимизированном виде: контакты — хешами, метаданные — без привязки к суммам. Доступ журналируется, отзыв согласия удаляет записи.
Как это соотносится с требованиями регуляторов?
Пользователь явно подтверждает раскрытие данных, хранители информируются об активации, а окно отмены даёт право на возражение. Журнал согласий выгружается по запросу для проверок.
Обсудим задачу: с чего начать и что уточнить
Оценка Social Recovery для криптокошелька опирается не на число экранов, а на модель восстановления доступа и то, как она встраивается в уже работающий продукт. Ниже — вводные, которых обычно достаточно, чтобы вернуться с планом этапов, составом пилота и сроками. Если часть данных пока не определена — не блокер, зафиксируем варианты вместе.
- Сценарии восстановления и модель угроз: что считаем потерей доступа — утеря устройства, недоступность фразы восстановления, компрометация хранителя — и от кого защищаемся.
- Параметры схемы: порог k из n, число и типы хранителей (контакты пользователя, второе устройство, сервисный держатель), порядок и сроки замены.
- Вводные по продукту: платформы, текущий стек кошелька, поддерживаемые сети и тип ключей — фраза восстановления, ключ на смарт-контракте или аппаратный модуль.
- Логика безопасности: задержка перед сменой хранителей, окно отмены для владельца, уведомления по всем доверенным каналам.
- Границы пилота: на какой доле пользователей запускаем и какие метрики считаем успехом — доля доведённых до конца восстановлений, число обращений в поддержку.
- Оценка сроков: что закрываем мы, что ложится на вашу команду, где нужна внешняя проверка безопасности до релиза.
- Доступы и данные: тестовая сеть и тестовые аккаунты, сборки для внутреннего тестирования, прямой канал с вашим техлидом.
Опишите задачу в свободной форме — вернёмся с оценкой, планом внедрения и сроками по этапам. Пилот на части пользователей предложим первым шагом: он показывает поведение схемы на реальных сценариях восстановления, не затрагивая всю базу.
