Впровадження Social Recovery для мобільного криптогаманця

Social Recovery криптогаманця: де ламається відновлення

Приватний ключ — це єдиний ключ, який пов'язує власника з адресою гаманця: адреса обчислюється з нього, тому скинути пароль за аналогією з поштою чи банком тут не вийде.

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

Фраза відновлення задумувалася як страховка, а на практиці рветься першою.

Її переписують у нотатки, фотографують, пересилають собі в месенджер; під час перевстановлення застосунку резервна копія не підтягується, якщо номер телефону змінився, а пошта, до якої прив'язано акаунт, заблокована.

Кожен такий сценарій — тиха втрата доступу без жодного повідомлення: людина дізнається про неї в момент, коли хоче надіслати кошти.

Ланцюжок доступу ламається там, де всі ланки сходяться в одну точку: один пристрій, один носій фрази, один номер, один акаунт хмарного сховища.

Схема social recovery у ERC-4337 розносить право на відновлення між кількома охоронцями, і відмова будь-якої однієї ланки перестає бути фатальною для акаунта.

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

Що дає впровадження: швидкість відновлення і клас відмов

Доступ повертається за хвилини замість «назавжди втрачено»

Ключовий зсув — сама можливість повернути доступ. Раніше втрата пристрою разом із єдиною копією ключа означала безповоротну втрату коштів: користувачеві залишалося лише спостерігати за адресою.

Із Social Recovery доступ відновлюється за хвилини — людина підтверджує себе в довірених охоронців, набирає потрібний поріг підтверджень і знову працює з гаманцем на новому пристрої.

Зникає цілий клас відмов, а не окремі випадки

Зникає не частина проблем, а категорія відмов, яку підтримка раніше не могла закрити в принципі: втрата єдиної копії ключа, поломка телефона до створення резервної копії, зміна пристрою без перенесення.

Поріг підтверджень налаштовується під задачу — користувач сам визначає, скільки охоронців і яка їхня кількість має підтвердити відновлення. Якщо один охоронець втратив доступ, його замінюють, не перезбираючи схему повністю.

Самостійне відновлення знімає навантаження з підтримки

Частка звернень «не можу увійти, втратив ключ» переходить у самообслуговування: користувач проходить сценарій усередині застосунку, і підтримка не бере участі у видачі доступу.

Це важливо і для безпеки — команда не має і не повинна мати можливості одноосібно відновити чужий гаманець. Кількість звернень про доступ знижується, а ті, що залишилися, стосуються налаштування охоронців і вирішуються помітно швидше.

Варіанти відновлення доступу: порівняння підходів

Вибір схеми відновлення визначається умовами експлуатації, а не смаком: чи готовий користувач на старті виконати обов'язкові кроки, скільки в нього пристроїв, хто відповідає за зберігання копій.

Різниця між підходами — у тому, кому довіряється доступ і що відбувається, коли один з учасників випадає.

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

Далі рахуємо від кількості охоронців, цільового часу відновлення та моделі загроз — і вже під неї проєктуємо екрани налаштування й обробку помилок.

Етапи впровадження: від аудиту сценаріїв до передачі в підтримку

Порядок робіт однаковий для будь-якого гаманця — відрізняється лише склад охоронців і глибина інтеграції. Ми йдемо від інвентаризації сценаріїв відмови до регламентів, за якими підтримка замовника закриває звернення без участі розробника.

1. Аудит сценаріїв доступу. Збираємо, як користувач отримує і втрачає доступ: втрата пристрою, зміна номера, перевстановлення застосунку, відкликання доступу в охоронця. На виході — карта шляхів відновлення та список місць, де зараз обов'язковий ручний розбір вашою командою.

2. Проєктування схеми відновлення. Фіксуємо поріг спрацювання, склад і ролі охоронців, затримку перед виконанням запиту, правила заміни охоронця, що вибув. Схема узгоджується документом — до написання коду.

3. Налаштування сервісу відновлення. Піднімаємо сервіс, який приймає частки секрету, зберігає їх у зашифрованому вигляді та перевіряє підписи запитів. Розмежовуємо ролі, вмикаємо журнал операцій і повідомлення учасникам.

4. Інтеграція в застосунок. Екрани запиту й підтвердження, зрозумілі статуси, поведінка при обриві зв'язку — відновлення проходить із телефона, без листування з підтримкою.

5. Перевірка сценаріїв на навчальному контурі. Прогоняємо негативні сценарії: охоронець недоступний, частки не сходяться, запит повторюється, пристрій потрапив до третьої особи. Заміряємо кількість кроків для користувача та час до повернення доступу.

6. Передача в підтримку. Віддаємо регламенти першої лінії, чек-листи ескалації, інструкції щодо заміни охоронця та метрики: яку частку відновлень команда закриває самостійно.

Що передаємо на руки: конфігурації та політики криптогаманця

Social Recovery працює автономно лише тоді, коли відновленням доступу займається не один конкретний інженер, а описаний процес. Тому передача — це не набір файлів, а робочі конфігурації, карти ролей і регламенти, за якими ваша команда веде гаманець без нас.

• Схема ролей і довірених контактів: скільки контактів потрібно для порогу, як вони розподілені між пристроями й платформами, що відбувається при втраті одного чи кількох.
• Політики доступу: затримка відновлення, поріг підтверджень, правила заміни й відкликання довіреного контакту, обмеження на зміну власника.
• Конфігурації клієнтської та серверної частини: таймаути, шаблони повідомлень, сценарії блокування при підозрілій активності.
• Документація відновлення: покроковий шлях від запиту до повернення доступу, включно з гілками з помилками та відмовою у відновленні.
• Регламент підтримки: строки реакції, порядок ескалації, зберігання журналів операцій, точки, де потрібен доступ другого інженера.
• Інструкції для користувачів: що бачить власник при втраті пристрою, як додати контакт, як ініціювати відновлення і що робити при зависанні.

Кожен пункт перевіряємо на тестовому відновленні: інженер, який не брав участі у впровадженні, проходить сценарій за документацією без підказок. Поки він робить це сам — передача не закрита.

Кейс: відновлення доступу без єдиної точки відмови

До впровадження

До впровадження доступ повертали двома шляхами: сід-фраза, яку втрачали найчастіше, і звернення в підтримку. Другий шлях займав від трьох діб до тижня: ручна звірка особи та погодження між відділами.

На доступ припадало близько 40% усього потоку звернень, а частка успішних відновлень трималася на 62% — частина користувачів не доводила перевірку до кінця й ішла, так і не отримавши гаманець назад.

Після впровадження

Ми розклали ключ на частки за пороговою схемою, відомою з підходу Argent, і роздали їх охоронцям: основний пристрій, резервний, довірений контакт користувача та сервісний вузол.

Відновлення запускається за порогом «два з трьох» без участі підтримки, а в застосунку з'явилося вікно скасування на 48 годин — якщо пристрій на місці, власник скасовує чужу спробу однією кнопкою.

Після переходу на нову схему час відновлення доступу скоротився до 8–12 хвилин — це весь цикл від запиту до нового ключа. Частка успішних відновлень зросла до 96–98%: сценарій більше не залежить від людини в підтримці. Звернення щодо доступу впали з 40% до менш ніж 5% від загального потоку.

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

Що робити, якщо в частини користувачів уже є мультипідпис?

Нічого ламати не потрібно: мультипідпис і соціальне відновлення закривають різні задачі. Перший ділить право підпису між кількома ключами — ролі, ліміти, спільне сховище; друге повертає доступ, коли ключ втрачено. Схеми співіснують в одному акаунті, якщо конфігурація вміє комбінувати обидва набори правил.

Перехід — це не новий гаманець, а зміна набору сторін, що підтверджують, усередині наявного акаунта. Адреса, історія операцій і баланси залишаються на місці, тому переводити активи вручну не потрібно і доступ не втрачається в момент перемикання.

Старі підписи приймаються, поки діє вікно підтвердження: перехід без втрати доступу забезпечує конфігурація, а не користувач.

Для власників апаратного гаманця схема залишається такою ж: пристрій підтверджує операції, а відновлення підключається лише як резервний шлях.

Міграцію користувачів ведемо поетапно — спочатку добровільне вмикання для нових, потім підказки в клієнті для активних, і лише згодом зміна схеми за замовчуванням.

Кожен крок керується флагом у конфігурації, тому відкат займає хвилини й не потребує оновлення застосунку в усіх одразу.

Сумісність схем перевіряємо в тестовій мережі за сценаріями: втрата ключа, заміна довіреного контакту, відкликання згоди, одночасний підпис кількома сторонами.

Сценарій, який не проходить на старій версії клієнта, блокує крок міграції — ніхто не залишається між двома несумісними наборами правил.

Технічні сумніви: довіра, затримки та зберігання даних

Довіра в соціальному відновленні тримається не на обіцянках, а на математиці: сервіс не може зібрати ключ самотужки.

Гаманець ділить секрет за пороговою схемою — частки отримують власник і довірені контакти, а нижче порогу (наприклад, три частки з п'яти) відновлення неможливе навіть за повного доступу до нашої інфраструктури.

Згоду користувача фіксується до активації, а не за фактом: екран із переліком даних, які йдуть на сервер, ролями охоронців і способом відкликати згоду.

Затримка відновлення задається вікном скасування — заявка виконується через час, за який усі охоронці отримують повідомлення, а власник може зупинити операцію.

Що якщо довірений контакт недоступний?

Поріг завжди менший за кількість охоронців, тому один-два контакти, що випали, не блокують відновлення. Склад охоронців змінюється перевипуском часток — адреса гаманця й баланс при цьому не зачіпаються.

Де зберігаються дані?

У узгодженому регіоні, в мінімізованому вигляді: контакти — хешами, метадані — без прив'язки до сум. Доступ журналюється, відкликання згоди видаляє записи.

Як це співвідноситься з вимогами регуляторів?

Користувач явно підтверджує розкриття даних, охоронців інформують про активацію, а вікно скасування дає право на заперечення. Журнал згод вивантажується на запит для перевірок.

Обговоримо задачу: з чого почати і що уточнити

Оцінка Social Recovery для криптогаманця спирається не на кількість екранів, а на модель відновлення доступу і те, як вона вбудовується в уже працюючий продукт. Нижче — ввідні, яких зазвичай достатньо, щоб повернутися з планом етапів, складом пілота та строками. Якщо частину даних ще не визначено — не блокер, зафіксуємо варіанти разом.

• Сценарії відновлення та модель загроз: що вважаємо втратою доступу — втрата пристрою, недоступність фрази відновлення, компрометація охоронця — і від кого захищаємося.
• Параметри схеми: поріг k з n, кількість і типи охоронців (контакти користувача, другий пристрій, сервісний утримувач), порядок і строки заміни.
• Ввідні щодо продукту: платформи, поточний стек гаманця, підтримувані мережі та тип ключів — фраза відновлення, ключ на смарт-контракті чи апаратний модуль.
• Логіка безпеки: затримка перед зміною охоронців, вікно скасування для власника, повідомлення всіма довіреними каналами.
• Межі пілота: на якій частці користувачів запускаємо і які метрики вважаємо успіхом — частка доведених до кінця відновлень, кількість звернень у підтримку.
• Оцінка строків: що закриваємо ми, що лягає на вашу команду, де потрібна зовнішня перевірка безпеки до релізу.
• Доступи та дані: тестова мережа й тестові акаунти, збірки для внутрішнього тестування, прямий канал із вашим техлідом.

Опишіть задачу у вільній формі — повернемося з оцінкою, планом впровадження та строками за етапами. Пілот на частині користувачів запропонуємо першим кроком: він показує поведінку схеми на реальних сценаріях відновлення, не зачіпаючи всю базу.