Как восстановить хранилище Kaspa, когда сайт недоступен

Вы можете восстановить хранилище Kaspa Safe, ни разу не посетив kaspaforge.org. Хранилище — это ончейн-ковенант, смарт-контракт в BlockDAG Kaspa, а не строка в нашей базе данных. Каждое правило, управляющее вашими средствами, живёт в скрипте, а не на нашем сервере. Сайт — это уровень удобства; контракт — это авторитет.

В этой статье разбирается полная цепочка восстановления: как зашифрованный профиль хранит параметры хранилища, как автономный дешифратор keyfile-decrypt.html извлекает их офлайн, и как CLI vaultctl с открытым исходным кодом реконструирует и управляет вашим хранилищем через любой узел Kaspa v2+.

Почему ончейн-контракты меняют подход к восстановлению

Традиционный кастодиальный кошелёк хранит ваш баланс как запись в базе данных. Если компания исчезает, ваш «баланс» исчезает вместе с ней — нет независимого способа переместить эти монеты, потому что ключи хранились у компании.

Kaspa Safe переворачивает эту модель. Когда вы создаёте хранилище, браузер (с помощью Kaspa WASM SDK) генерирует ваши ключи локально, формирует скрипт ковенанта и транслирует транзакцию пополнения. С этого момента средства находятся в UTXO ковенанта Toccata в BlockDAG Kaspa. Контракт кодирует каждое правило расходования — периоды ожидания, отмену по тревоге, таймеры наследования, полномочия на миграцию — непосредственно в скрипте. Сервер никогда не видит ваши приватные ключи и никогда не хранит ваши монеты.

Таким образом, восстановление — это не получение доступа к стороннему аккаунту. Это реконструкция ончейн-состояния и локальная подпись транзакций — задача, с которой справится любой инструмент, работающий с протоколом Kaspa.

Цепочка восстановления: три уровня

Для восстановления используются три компонента, каждый из которых не зависит от сайта Kaspa Forge:

1. Ваш файл профиля .age — зашифрованный архив, сохранённый на ваше устройство при создании хранилища. Он содержит profile.json (параметры хранилища, публичные ключи, метаданные ковенанта) и, внутри него, одну или несколько записей vault.json (по одной на каждое созданное вами хранилище). 2. keyfile-decrypt.html — одностраничный HTML-файл с библиотекой дешифрования age, скомпилированной в WASM и встроенной в виде base64. Работает целиком в браузере по адресу file:// без единого сетевого запроса. Откройте его, перетащите файл .age, введите парольную фразу — и получите дешифрованный profile.json, из которого можно выбрать нужную запись хранилища. 3. vaultctl — open-source офлайн-инструмент командной строки. Он берёт запись хранилища из вашего дешифрованного профиля, подключается к узлу Kaspa, запрашивает ончейн-состояние UTXO и позволяет выполнять любые операции с хранилищем: проверить статус, инициировать вывод, отменить снятие с хранения, выполнить чек-ин, получить наследство или мигрировать.

Представьте аналогию с банковской ячейкой: файл .age — это запечатанный конверт с кодом, keyfile-decrypt.html — это нож для бумаги, лежащий в ящике вашего стола, а vaultctl — это банковский служащий, который откроет хранилище, как только вы предъявите нужные документы. Служащему не обязательно работать в каком-то конкретном банке — подойдёт любой узел Kaspa.

Пошаговое восстановление хранилища

Шаг 1 — Дешифрование профиля

Откройте keyfile-decrypt.html в браузере (локально, через file:// — сервер не нужен). Файл автономен: библиотека дешифрования age скомпилирована в WASM и встроена прямо в HTML как base64 data URI. Нет внешних скриптов, нет зависимостей от CDN, нет автоматических сетевых запросов.

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

Каноническая сборка этого файла создаётся скриптом tools/build-keyfile-decrypt.py и публикуется в наборе для восстановления на GitHub.

Шаг 2 — Установка vaultctl

vaultctl опубликован в репозитории Kaspaforge/kaspaforge на GitHub в директории spike/vaultctl/. Вы можете собрать его из исходного кода (это стандартный проект на Rust) или использовать готовый бинарный файл. Инструмент полностью офлайн для всех локальных операций; подключение к сети требуется только для запросов к узлу или трансляции транзакций.

Шаг 3 — Проверка статуса хранилища

Укажите vaultctl узел Kaspa и передайте ему запись вашего хранилища:

vaultctl --node grpc://your-node:16110 status --vault vault.json

Команда status запрашивает все UTXO ковенанта, принадлежащие адресу вашего хранилища, и для каждого выводит: outpoint (txid:index), стоимость, текущий возраст (в единицах DAA) и оставшееся время активного таймера (задержка снятия с хранения или задержка наследования). Также перечисляются обычные (не ковенантные) UTXO на адресе хранилища — это случайные депозиты, которые ковенант не может потратить напрямую, но которые vaultctl может собрать через транзакцию checkin.

Узел по умолчанию — grpc://node.kaspaforge.org:16110 (публичный gRPC-фронт), но вы можете — и для максимальной независимости должны — указать свой собственный узел Kaspa с помощью --node.

Шаг 4 — Операции с хранилищем

После загрузки записи хранилища vaultctl предоставляет доступ ко всем путям расходования ковенанта:

• initiate — начать вывод средств (требуется горячий ключ; хранилище переходит в состояние UNVAULTING, запускается таймер задержки).
• cancel — отменить снятие с хранения (требуется аварийный ключ; средства возвращаются в состояние VAULT).
• complete — завершить вывод после истечения задержки (подпись не нужна — трансляцию может выполнить любой; средства поступают на адрес, указанный при инициации).
• checkin — сбросить таймер наследования (требуется горячий ключ).
• inherit — получить средства как наследник (требуется ключ наследника, после истечения задержки наследования при отсутствии чек-инов).
• migrate — переместить всё хранилище на новый адрес или версию контракта (требуются оба ключа — горячий и аварийный; мгновенно, полный контроль).

Каждый из них соответствует одной из семи ончейн-точек входа в скрипте ковенанта vault.sil. Скрипт обеспечивает соблюдение правил — vaultctl лишь формирует и подписывает транзакции.

Работа с несколькими UTXO

Если в вашем хранилище несколько UTXO ковенанта (например, от повторных депозитов), vaultctl обрабатывает их пакетной стратегией с прерыванием при ошибке. Флаг --all предварительно формирует полный набор транзакций и отправляет по одной транзакции с одним входом на каждый UTXO. Если какая-либо транзакция в пакете отклоняется узлом, пакет немедленно останавливается и сообщает, какие outpoint'ы были приняты, а какие нет. После этого вы можете повторить попытку для оставшихся. Флаг --outpoint txid:index указывает на конкретный единичный UTXO.

Команда migrate --all специально предназначена для экстренной миграции хранилища с большим количеством UTXO — она явно показывает операционные затраты (одна транзакция на UTXO), а не скрывает их.

Как Kaspa Forge использует эту архитектуру

Цепочка восстановления — не запоздалая мысль, а осознанный архитектурный выбор, заложенный в каждый продукт Kaspa Forge, который хранит средства пользователей.

Kaspa Safe — главный пример. Мастер создания хранилища генерирует ваш профиль .age и предлагает сохранить его. Страница восстановления (recover.html) документирует полную офлайн-процедуру. CLI vaultctl и дешифратор keyfile-decrypt.html опубликованы в публичном наборе для восстановления на GitHub с контрольными суммами SHA-256 для верификации.

Kaspa Escrow и Deposit используют ту же ончейн-модель ковенанта: средства находятся в UTXO контракта, а не в кошельке платформы. Сценарии расходования закодированы в скрипте, и действует тот же принцип — контракт является авторитетом, а не сервер.

Desk хранит ваш зашифрованный профиль локально в браузере. Это тот же архив .age, который keyfile-decrypt.html может дешифровать офлайн. Desk — это удобный интерфейс; инструменты восстановления — это гарантия независимости.

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

Ни одна система восстановления не обходится без компромиссов. Вот что стоит этот подход и чего он не решает:

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

Вы должны хранить свои ключи. Горячий ключ, аварийный ключ и ключ наследника генерируются на стороне клиента и распечатываются на вашем листе восстановления при создании хранилища. Kaspa Forge никогда их не видит. Если вы потеряете оба ключа — горячий и аварийный — доступными останутся только пути complete (после задержки снятия с хранения) и inheritAuto (после задержки наследования, если она включена). Мастер-переопределения не существует.

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

vaultctl нуждается в узле Kaspa. CLI подключается через gRPC для запроса UTXO и трансляции транзакций. Вы можете использовать публичный фронт на node.kaspaforge.org:16110, но для настоящей независимости запустите свой собственный узел. Этап дешифрования (keyfile-decrypt.html) полностью офлайн — только взаимодействие с узлом требует подключения.

Инвариант одного входа на транзакцию. Каждый UTXO ковенанта должен расходоваться отдельно (один вход на транзакцию). Это функция безопасности — она предотвращает атаки на множественное хищение UTXO — но означает, что хранилище с множеством депозитов потребует нескольких транзакций для полной миграции. vaultctl обрабатывает это прозрачно с помощью --all и понятных сообщений об ошибках, но затраты на комиссии и время реальны.

Бюджет комиссий ограничен на уровне контракта. Ковенант устанавливает максимальный бюджет комиссий в 0,1 KAS на каждый безключевой путь расходования (complete, inheritAuto). Это защищает от грифинга — никто не может сжечь ваше хранилище на комиссиях — но также означает, что в условиях экстремальных комиссий безключевые пути могут стать экономически невыгодными. Путь migrate (требующий оба ключа) не имеет такого ограничения — по замыслу.

В v3 есть известное ограничение на количество выходов. Ограниченные пути расходования проверяют требуемую сумму на выходе, но не контролируют tx.outputs.length. Составитель транзакции может направить оставшийся бюджет комиссий на дополнительный выход вместо сетевой комиссии. Официальные сборщики всегда создают канонические транзакции с одним выходом, и это ограничение будет ужесточено в v4. Это зазор в многоуровневой защите, а не уязвимость потери средств — инвариант стоимости хранилища по-прежнему выполняется.

Принцип, лежащий в основе дизайна

Основная идея проста: правила хранилища-ковенанта живут в блокчейне, а не на каком-либо сервере. Сайт, вотчер, уведомления в Telegram — это уровни удобства. Они упрощают повседневное использование хранилища. Но они не несут ответственности за сохранность средств.

Если бы все серверы Kaspa Forge исчезли завтра, ваше хранилище по-прежнему соблюдало бы свои периоды ожидания, по-прежнему выполняло бы таймеры наследования и по-прежнему принимало бы ваши подписи. CLI vaultctl и дешифратор keyfile-decrypt.html дают вам инструменты для взаимодействия с этим контрактом с любого устройства, через любой узел, имея лишь ваш зашифрованный профиль и ваши ключи.

Вот что на практике означает некастодиальность — не маркетинговое обещание, а инженерная гарантия, подкреплённая открытым исходным кодом и ончейн-исполнением.