Kaspa некастодиальное восстановление: три пути без сервера

«Не твои ключи — не твои монеты» — старейшее обещание в мире криптовалют. Но для большинства сервисов подтверждение этого обещания сводится к сид-фразе на бумаге и смутной надежде, что программное обеспечение кошелька ещё будет работать, когда оно понадобится. Что произойдёт, когда сервис, создавший ваше хранилище — сайт, бэкенд, оповещения — просто исчезнет?

В Kaspa Forge ответ заложен в саму архитектуру: три независимых пути восстановления, каждый из которых работает без наших серверов, каждый действует с ончейн-контрактами, существующими независимо от любого сайта. В этой статье мы разберём механику каждого пути и честно оговорим компромиссы.

Испытание некастодиальности

Кастодиальный сервис хранит ваши средства в собственном кошельке. Если он исчезнет — деньги исчезнут вместе с ним. Некастодиальный сервис создаёт средства в *вашем* кошельке — но если восстановление зависит от инфраструктуры сервиса, разница становится чисто теоретической. Настоящий тест таков: сможете ли вы переместить свои деньги инструментами, которые контролируете вы сами, после того как сервис прекратит работу?

Ончейн-ковенанты Kaspa, появившиеся с хардфорком Toccata, делают эту проверку возможной на уровне протокола. Контракт хранилища в Kaspa — это фрагмент скрипта с фиксированными правилами: кто может подписывать, какие задержки применяются, куда отправляются средства. Этот скрипт живёт в BlockDAG, а не на каком-либо сервере. Таким образом, восстановление сводится к трём отдельным способностям: знать, какому контракту вы принадлежите, найти его в блокчейне и собрать корректную транзакцию расходования по нему.

Путь 1 — Расшифровка резервной копии

Когда вы создаёте хранилище через Kaspa Forge, браузер генерирует мастер-сид HD и выводит из него все ключи. Весь профиль — сид, ключи хранилища, параметры, адреса кошельков — шифруется в файл ключа .age, который вы скачиваете один раз при настройке.

Шифрование использует age — современный инструмент на основе деривации ключа scrypt и X25519/ChaCha20-Poly1305. Единственный вход — ваша парольная фраза; выход — текстовый блок в ASCII-формате, который можно сохранить на USB-накопитель, распечатать на бумаге или хранить в менеджере паролей.

Пример расшифрованного профиля (версия 3):

{
  "version": 3,
  "seed": "<64-hex мастер-сид>",
  "wallet": "kaspa:q...",
  "walletOld": "kaspa:q...",
  "vaults": [
    {
      "hot_pk": "...",
      "alarm_pk": "...",
      "address": "kaspa:q...",
      "delay": 86400,
      "heir": "0000...0000",
      "inheritDelay": 0,
      "fee_budget": 5000000,
      "note": "холодное хранение"
    }
  ]
}

Если тревожный ключ хранится на физической карте (за пределами цифрового профиля), в записи будет "alarm_card": true — сама карта является резервной копией этого ключа.

Для расшифровки не требуется наш сервер. Kaspa Forge публикует отдельный инструмент keyfile-decrypt.html — единственный HTML-файл с модулем расшифровки WASM, встроенным в формате base64. Он работает с протокола file:// без единого сетевого запроса. Откройте его в браузере, перетащите файл .age, введите пароль — и вы получите исходный JSON. Инструмент также совместим со штатной командой age -d из командной строки.

Путь 2 — Повторный поиск ваших хранилищ

Иметь сид необходимо, но недостаточно — нужно также знать, *в каких ончейн-адресах* находятся ваши хранилища. Если вы создали три хранилища с индексами деривации 0, 1 и 2, адреса детерминированы: один и тот же сид всегда даёт одни и те же ключи с теми же индексами — на любой машине, в любой момент.

Деривация в Kaspa Forge работает следующим образом:

secret_key = HMAC-SHA512(
  key  = master_seed,
  msg  = "kaspaforge/v1/vault/<index>"
)[0..32]          // первые 32 байта → приватный ключ secp256k1

Каждый индекс хранилища порождает уникальную пару ключей. Механизм сканирования с разрывом (доступен на recover.html) проходит по индексам 0, 1, 2… и проверяет, содержит ли выведенный адрес UTXO в блокчейне. Если сканер находит профинансированный адрес, он сообщает о хранилище — даже если оно было создано через месяцы после создания резервной копии.

Текущая производственная версия сканирования отправляет выведенные публичные ключи на наш эндпоинт, который сопоставляет их с набором UTXO. Важно, что сервер видит только публичные ключи и идентификаторы токенов — ваш приватный ключ и сид никогда не покидают браузер. Если наш сервер также недоступен, вы можете вывести адреса локально (любой SDK Kaspa или даже ручной расчёт HMAC) и проверить их через блок-эксплорер или собственный узел.

Это ключевое свойство HD-деривации: одна резервная копия покрывает все будущие хранилища. Нет необходимости создавать новую резервную копию после каждого нового хранилища.

Путь 3 — Расходование без сервера

Имея запись хранилища (публичные ключи, задержку, бюджет комиссий, параметры) и соответствующий приватный ключ, вам нужно собрать транзакцию Kaspa, удовлетворяющую скрипту ковенанта. Здесь на помощь приходит vaultctl.

vaultctl — это утилита командной строки на Rust с открытым исходным кодом, публикуемая вместе с Kaspa Forge. Она принимает запись хранилища из расшифрованного профиля, подключается к узлу Kaspa и формирует корректную транзакцию расходования для любого из семи путей расходования хранилища:

# Завершение ранее инициированного вывода
# (подпись не нужна — требуется только истечение задержки):
vaultctl complete \
  --vault vault.json \
  --dest kaspa:q... \
  --node grpc://any-kaspa-node:16110

# Инициация нового вывода (требуется подпись горячим ключом):
vaultctl initiate \
  --vault vault.json \
  --dest kaspa:q... \
  --key hot.key

# Проверка для сброса таймера наследования:
vaultctl checkin \
  --vault vault.json \
  --key hot.key

Критически важная деталь: vaultctl работает с любым узлом Kaspa v2+, не только с нашим. По умолчанию используется публичный эндпоинт, но флаг --node принимает любой синхронизированный экземпляр kaspad — ваш собственный, общественный узел или развёрнутый специально для этого случая. Скрипт ковенанта идентичен везде, потому что он живёт в блокчейне. Транзакции, отправленные через RPC (как это делает vaultctl), никогда не истекают в пуле неподтверждённых транзакций Kaspa, поэтому транзакция восстановления сохраняется до тех пор, пока не будет включена в блок — сколько бы времени это ни заняло.

Инструмент поставляется с 18 автотестами, проверяющими каждый путь расходования по логике верификации контракта. Вы можете запустить их локально, чтобы убедиться, что бинарный файл соответствует опубликованному исходному коду.

Как Kaspa Forge связывает всё воедино

Руководство по восстановлению на Kaspa Forge последовательно описывает все три пути: расшифровка резервной копии → поиск хранилищ → расходование через vaultctl. На странице также указаны контрольные суммы SHA-256 для проверки опубликованных инструментов.

Принцип дизайна недвусмыслен: для восстановления мы не нужны. Контракт хранилища в BlockDAG не знает и не заботится о том, существует ли kaspaforge.org. Путь complete() — самый частый сценарий восстановления после попытки кражи — вообще не требует подписи; любой может отправить его, как только истечёт задержка. Путь inheritAuto() работает аналогично для случая наследования.

Конкретно для хранилищ Kaspa Safe сервис-наблюдатель отправляет оповещения (Telegram, электронная почта, веб-пуши) при любых изменениях ваших UTXO — но оповещения — это слой удобства, а не обязательное условие. Таймлоки контракта и пути расходования работают с уведомлениями или без них.

Компромиссы и честные ограничения

Ни одна система восстановления не обходится без трений. Вот что стоит такая конструкция:

• Вы должны сохранить резервную копию. Если вы потеряете и файл ключа .age, и мастер-сид, средства в хранилище утрачены. Никакого «забыли пароль» — в этом суть и в этом риск. Kaspa Forge никогда не видит ваш сид, поэтому мы не сможем помочь с восстановлением.

• Тревожный ключ на физической карте хранится за пределами цифровой резервной копии. Если ваше хранилище использует тревожную карту (физический ключ для пути cancel), эта карта не входит в файл .age. Потеряете карту — потеряете возможность отменить кражу в процессе. Хранилище по-прежнему восстановимо через initiate + complete или через migrate (если горячий ключ всё ещё у вас), но тревожный путь будет утрачен.

• Сканирование с разрывом в настоящее время использует наш серверный эндпоинт для сопоставления выведенных адресов с набором UTXO. Сервер видит только публичные ключи, но не приватные — однако если вы хотите нулевой зависимости от нашей инфраструктуры, вам придётся выводить адреса локально и проверять их через эксплорер или собственный узел вручную. Офлайн-инструмент для сканирования с разрывом пока не опубликован.

• vaultctl — это инструмент командной строки. Нетехнические пользователи могут найти процесс восстановления пугающим. Руководство по восстановлению смягчает это пошаговыми инструкциями, но это не процесс «одной кнопкой». Это честный компромисс: восстановление по кнопке в HTML потребовало бы серверной инфраструктуры, что обессмыслило бы весь замысел.

• Тайм задержки реальны. Задержки хранилищ в Kaspa измеряются в DAA score, который при текущих 10 блоках в секунду увеличивается примерно на 10 единиц в секунду. Задержка 86 400 DAA — это примерно 2,4 часа. Именно так работает окно тревоги — но это означает, что вам придётся подождать, прежде чем complete() можно будет отправить.

• Путь migrate требует оба ключа. Миграция (перемещение средств в новую версию хранилища или ротация ключей) требует подписей как горячим, так и тревожным ключом. Если один ключ утерян навсегда, миграция невозможна — вместо этого вы будете использовать initiate → ожидание → complete для вывода средств.

Честный итог: система восстановления Kaspa Forge надёжна для пользователей, которые сохраняют резервную копию и готовы воспользоваться CLI-утилитой в экстренной ситуации. Она не рассчитана на пользователей, которым нужна кастодиальная страховка — потому что именно кастодиальная страховка и есть то, что исчезает вместе с сервисом.