Social recovery позволяет вернуть контроль над криптокошельком без единственной резервной фразы, от которой зависит всё. Владелец заранее назначает доверенных участников или устройства – guardians. Если основной ключ потерян, достаточное число guardians подтверждает замену владельца на новый адрес.
Это не служба поддержки и не универсальная функция любого кошелька. Механизм должен быть заложен в smart account или подключён как отдельный модуль. Его безопасность зависит от контракта, порога, независимости guardians, задержки исполнения и возможности остановить чужое восстановление.
Из каких частей состоит social recovery
Владелец – текущий signer, который обычно подтверждает переводы и изменения настроек. Guardians – заранее выбранные адреса, способные участвовать только в процедуре восстановления или в другом ограниченном наборе действий. Порог задаёт минимальное число подтверждений, необходимое для замены signer.
В запросе восстановления указывается новый адрес владельца. Контракт проверяет подтверждения guardians, уникальность запроса и условия политики. После успешного исполнения старый ключ перестаёт управлять аккаунтом, а новый получает установленные полномочия.
Стандартизированные предложения для social recovery также предусматривают nonce против повторного использования старых подписей, период блокировки восстановления и отмену активного запроса. Конкретная реализация может отличаться, поэтому параметры нужно читать в документации и коде выбранного кошелька.
Почему нужен порог
Если восстановление может запустить один guardian, его компрометация превращается в компрометацию кошелька. Пороговая схема требует согласия нескольких участников. Например, политика может требовать две подписи из трёх или три из пяти, но эти числа не являются универсальной рекомендацией.
Чем выше порог, тем труднее злоумышленнику захватить аккаунт. Одновременно растёт риск навсегда потерять восстановление из-за недоступности участников. Надёжная конфигурация учитывает обе стороны: сколько guardians может быть скомпрометировано и сколько может исчезнуть без потери доступа.
Считать нужно не адреса, а независимые факторы. Три кошелька на одном телефоне не дают настоящего распределения. То же относится к нескольким родственникам, которые хранят ключи в одном месте, или к устройствам под одной облачной учётной записью.
Как проходит восстановление
- Владелец создаёт новый чистый signer на безопасном устройстве.
- Один из guardians инициирует запрос с адресом нового владельца.
- Остальные guardians проверяют запрос по независимому каналу и подтверждают его.
- После достижения порога начинается или продолжается защитная задержка, если она предусмотрена.
- Текущий владелец может отменить подозрительный запрос до исполнения.
- Контракт меняет владельца, а новый signer проверяет доступ и настройки аккаунта.
Порядок отдельных шагов зависит от продукта. В одних кошельках задержка начинается после первого подтверждения, в других – после достижения порога. Срок тоже задаётся конкретной реализацией и не должен считаться одинаковым для всех сервисов.
Зачем нужна задержка и отмена
Порог защищает от части атак, но guardians могут быть обмануты или скомпрометированы одновременно. Задержка оставляет владельцу время заметить запрос и отменить его действующим ключом. Уведомления полезны, однако они не заменяют onchain-проверку состояния аккаунта.
Слишком короткая задержка уменьшает время реакции. Слишком длинная мешает владельцу быстро восстановиться после реальной потери. При выборе кошелька важно выяснить, можно ли менять период, кто имеет право его менять и действует ли изменение немедленно.
Nonce или другой уникальный идентификатор не позволяет повторно применить уже использованные подтверждения. Guardians должны подписывать не абстрактное «согласие», а данные, однозначно связанные с аккаунтом, новым владельцем, сетью и конкретным запросом.
Кого выбирать guardians
Guardian может быть человеком, отдельным аппаратным устройством, вторым аккаунтом владельца или специализированным сервисом. Комбинация разных типов снижает зависимость от одной причины отказа. При этом каждый участник должен понимать свою роль и уметь проверить адрес нового signer без пересылки секретных данных.
- Guardians не должны хранить seed-фразу владельца или получать его приватный ключ.
- Участников лучше распределять по разным устройствам, местам и каналам связи.
- Нужно заранее договориться, как проверить личность владельца при запросе.
- Нельзя подтверждать восстановление только по сообщению из одного мессенджера.
- Следует регулярно проверять, что guardians доступны и их адреса не изменились.
Если guardian больше не участвует, его нужно заменить до того, как он станет необходим. Изменение состава само по себе является чувствительной операцией: проверьте, требует ли оно обычной подписи владельца, задержки или дополнительного подтверждения.
Social recovery и другие способы восстановления
Seed-фраза восстанавливает ключи напрямую и не зависит от smart account, но её копия становится единым секретом. Правила работы с ней описаны в материале как безопасно хранить seed-фразу.
Облачная резервная копия может делить или шифровать секрет, но пользователь зависит от схемы доступа, провайдеров и восстановления учётной записи. Кастодиальное восстановление выполняет оператор сервиса и предполагает доверие к его процедурам.
Social recovery меняет право управления самим smart account. Guardians обычно не знают старый секрет и не воссоздают его. Это позволяет восстановиться на новый signer, но привязывает результат к корректности контракта и доступности выбранной сети.
Passkey может быть основным signer или частью другой схемы доступа. Его синхронизация и восстановление у платформы не равны onchain social recovery. Разницу подробно раскрывает статья о passkeys в криптокошельках.
Связь с account abstraction
Обычный внешний аккаунт в EVM-сети управляется одним приватным ключом и не умеет самостоятельно проверять порог guardians. Smart account исполняет программируемые правила подписи, поэтому может поддерживать recovery-модуль, лимиты, несколько signers и защитные задержки.
Account abstraction упрощает доставку пользовательских операций и оплату gas разными способами, но не задаёт одну обязательную recovery-схему. Архитектура UserOperation, bundler и EntryPoint разобрана в материале как устроен ERC-4337.
Некоторые кошельки используют модульную архитектуру. Модуль восстановления получает важные полномочия и должен считаться частью доверенной вычислительной базы. Ошибка в модуле, неправильная инициализация или чрезмерные права способны обойти защиту основного аккаунта.
Основные риски
- Сговор guardians. Достаточное число участников может назначить чужой signer.
- Общая точка отказа. Несколько адресов контролируются одним устройством, человеком или облаком.
- Социальная инженерия. Guardians подтверждают запрос злоумышленника, выдающего себя за владельца.
- Ошибка контракта. Recovery-модуль, proxy или права обновления меняют фактическую модель безопасности.
- Недоступность сети. Восстановление требует onchain-транзакций и комиссии, а иногда работы relayer или другого сервиса.
- Потеря приватности. Публичный набор guardians может раскрывать связи между адресами и людьми.
- Забытый запрос. Владелец не замечает начатое восстановление до окончания задержки.
Для smart accounts полезно изучать не только интерфейс приложения, но и контракты, владельцев proxy, модули и фактический порог. Пример модульного multisig-аккаунта рассмотрен в обзоре Safe, однако наличие похожих элементов не означает одинаковой модели recovery у разных продуктов.
Как настроить механизм безопаснее
- Запишите точный адрес smart account, сеть, список guardians, порог и защитную задержку.
- Распределите guardians между независимыми людьми и устройствами.
- Определите отдельный канал проверки запроса и кодовую процедуру без передачи seed-фразы.
- Подготовьте небольшой запас нативной монеты для необходимых onchain-действий, если продукт не оплачивает их иначе.
- Проведите тестовое восстановление на пустом или малозначимом аккаунте.
- Проверьте отмену запроса, замену guardian и уведомления.
- После смены телефона, отношений с участниками или модели контракта пересмотрите конфигурацию.
Тест важен не меньше настройки. Он показывает, знают ли guardians порядок действий, доступен ли интерфейс, кто оплачивает транзакцию и где владелец увидит период ожидания. Не стоит впервые изучать процедуру после потери основного ключа.
Что делать после восстановления
Новый signer следует создать в чистой среде и проверить до назначения. После смены владельца нужно убедиться, что старый ключ действительно лишён полномочий, отменить незавершённые запросы, пересмотреть guardians, активные модули, лимиты и разрешения токенов.
Если причиной стала компрометация устройства, одного изменения signer может быть недостаточно. Проверьте связанные аккаунты, электронную почту, облачные копии, сессии приложений и каналы связи с guardians. Не используйте новый ключ на заражённом устройстве.
Итог
Social recovery заменяет единственную точку восстановления программируемой процедурой. Guardians подтверждают новый signer, порог ограничивает власть одного участника, задержка даёт время на реакцию, а отмена защищает действующего владельца.
Надёжность схемы определяется не названием функции, а независимостью guardians, параметрами порога, правами recovery-модуля и проверенной процедурой. Настройку нужно тестировать заранее и регулярно пересматривать, иначе формально существующее восстановление может оказаться недоступным именно в момент потери ключа.
