Криптонаследство без юристов: как работает мёртвый переключатель Kaspa Safe

Самостоятельное хранение решает одну проблему и порождает другую. Когда вы держите собственные ключи, ни одна биржа не заморозит ваши средства, — но и никто не передаст их вашей семье, если с вами что-то случится. Опрос Кремационного института 2024 года показал, что примерно 72 % владельцев криптовалют не имеют плана передачи цифровых активов после смерти. Традиционное наследственное планирование для крипто означает: доверить хранителю, отдать сид-фразу юристу или собирать мультисиг с родственниками, которые, возможно, не понимают, что подписывают.

Kaspa Safe предлагает иной подход: мёртвый переключатель, работающий on-chain и встроенный в ковенант-хранилище на мейннете Toccata сети Kaspa. Владелец периодически «отмечается» криптографической подписью. Если отметки прекращаются на срок, превышающий настраиваемый тайм-аут, хранилище автоматически — или по подписи наследника, в зависимости от настроек — отправляет средства указанному получателю. Ни одна третья сторона не владеет ключами. Судебного постановления не требуется. Механизм живёт в ковенанте Kaspa — скрипте, который исполняется каждым валидирующим узлом сети.

В этой статье мы разберём, как устроен механизм на уровне протокола, как off-chain вотчер ему помогает и где у текущей конструкции есть объективные ограничения.

Проблема: что происходит с хранимым самостоятельно KAS, когда вас нет?

Сид-фраза в банковской ячейке доступна ровно настолько, насколько доступен человек, знающий код. Аппаратный кошелёк в ящике стола мёртв без PIN-кода. Даже хорошо задокументированный мультисиг требует, чтобы соподписатели были живы, согласны и технически способны действовать.

Пространство решений для криптонаследования имеет несколько известных форм:

• Кастодиальное доверие. Биржи или специализированные сервисы хранят ключи и выдают средства при подтверждении смерти. Вы доверяете платёжеспособности, честности и юридической добросовестности кастодиана.
• Мультисиг на основе социального восстановления. M из N подписей от членов семьи или друзей. Работает, если подписанты понимают управление ключами и остаются на связи. Ломается, если отношения меняются или подписанты теряют свои ключи.
• Контракты с тайм-локом. Средства разблокируются после дедлайна, который продлевается периодическими действиями владельца. Это и есть паттерн мёртвого переключателя — именно его использует Kaspa Safe.

Мёртвый переключатель привлекателен тем, что не требует внешнего доверия: таймер обеспечивает сам блокчейн. Но реализация на блокчейне с доказательством работы и 10 блоками в секунду требует аккуратности в измерении времени, жизненном цикле UTXO и защите от саботажа.

Строительные блоки: состояние хранилища, DAA score и возраст

Хранилище Kaspa Safe — это контракт-ковенант, написанный на Silverscript (vault.sil), скомпилированный в скрипт Kaspa и замкнутый за P2SH-адресом. Контракт хранит небольшой фрагмент персистентного состояния:

mode : 0 = VAULT (normal), 1 = UNVAULTING (withdrawal in progress)
dest : 36-byte version-prefixed scriptPubKey (destination for withdrawals)

При создании хранилище принимает девять параметров: hot (ключ расходования владельца), alarm (ключ отмены кражи), delay (время ожидания вывода в единицах DAA score), heir (публичный ключ получателя наследства), inheritDelay (тайм-аут чекинов в единицах DAA score), autoInherit (0 или 1), feeBudget (лимит сетевой комиссии, максимум 0,1 KAS), а также начальные mode и dest.

Ключевой временно́й примитив — DAA score — кумулятивный счётчик синих блоков плюс успешно смерженных красных блоков с момента генезиса. В отличие от часов стены, DAA score детерминирован и согласован на уровне консенсуса: каждый узел видит одно и то же значение для любого конкретного блока. Когда UTXO хранилища расходуется, ковенант вычисляет разницу между текущим виртуальным DAA score и DAA score блока, создавшего эту UTXO. Эта разница — age (возраст) UTXO. Когда контракт проверяет require(age >= delay), он спрашивает: «существует ли эта UTXO уже не менее delay единиц DAA score без расходования?»

При текущих ~10 блоках в секунду в Kaspa один час реального времени соответствует примерно 36 000 единицам DAA score, хотя точное соотношение смещается из-за колебаний хешрейта и работы алгоритма корректировки сложности с окном в 2 641 блок.

Сценарий чекина: сброс таймера

Таймер наследования начинает отсчёт в момент поступления UTXO в хранилище. Если владелец ничего не делает, age UTXO в конце концов достигнет inheritDelay — и наследник сможет забрать средства.

Чтобы этого не допустить, владелец периодически вызывает сценарий чекина:

checkin(hotSig):
  require(tx.inputs.length == 1)        // single-input invariant
  verify(checkSig(hotSig, hot))
  → VAULT mode, dest unchanged

Транзакция чекина расходует UTXO хранилища и создаёт новую на том же адресе с идентичным состоянием. Критический эффект: age новой UTXO сбрасывается в ноль. Таймер наследования запускается заново.

Поскольку чекин — это переход VAULT → VAULT без изменения конечного адреса, средства остаются в хранилище. Владельцу достаточно транслировать чекин раз в период inheritDelay — представьте себе это как криптографический сигнал «я ещё здесь».

С точки зрения вотчера это простейший сценарий для мониторинга. Бэкенд Kaspa Forge опрашивает UTXO хранилища каждые 10 секунд через gRPC, сравнивает текущий age с inheritDelay и отправляет напоминания, когда владелец не чекинился в течение 80 % окна тайм-аута.

Два сценария наследования: автоматический и подписной

Kaspa Safe предлагает два режима наследования, выбираемых при создании хранилища через флаг autoInherit. Активен ровно один.

Авто-наследование (autoInherit = 1):

inheritAuto():
  require(autoInherit == 1)
  require(age >= inheritDelay)
  require(heir != [0; 32])              // heir must be set
  → output to P2PK(heir), no signature needed

Это бесключевой сценарий — транзакцию может транслировать кто угодно, как только истечёт таймер. Средства отправляются на P2PK-адрес, выведенный из публичного ключа наследника. Никому не нужно подписывать: конечный выход определяет сам скрипт ковенанта. Инвариант единственного входа и лимит feeBudget (максимум 0,1 KAS) предотвращают злоупотребления — вотчер не может перенаправить средства или обнулить хранилище через сетевую комиссию.

На практике вотчер Kaspa Forge обнаруживает, что age >= inheritDelay, и автоматически транслирует транзакцию inheritAuto. Наследник получает уведомление по электронной почте (указывается при создании хранилища), что средства доступны на его P2PK-адресе. Ему достаточно импортировать или вывести соответствующий приватный ключ, чтобы распоряжаться средствами.

Подписное наследование (autoInherit = 0):

inheritSigned(heirSig):
  require(autoInherit == 0)
  require(age >= inheritDelay)
  require(heir != [0; 32])
  verify(checkSig(heirSig, heir))
  → output to P2PK(heir)

Здесь наследник должен активно заявить права на средства, подписав транзакцию своим приватным ключом. Вотчер по-прежнему может отправлять уведомления, но транзакция не пройдёт без подписи наследника.

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

Установка heir = [0; 32] (32 нулевых байта) полностью отключает наследование. В этом случае хранилище не содержит сценариев наследования — остаются только сценарии вывода и тревоги владельца.

Как помогает вотчер (и чего он не может)

Off-chain вотчер — это цикл опроса каждые 10 секунд в бэкенде Kaspa Forge. Для каждого зарегистрированного хранилища он:

1. Получает текущую UTXO через gRPC от индекса UTXO узла. 2. Вычисляет текущий age на основе DAA score создания UTXO относительно DAA score виртуального блока. 3. Сравнивает age с inheritDelay (и delay для выводов). 4. Отправляет оповещения при пересечении порогов.

В контексте наследования вотчер срабатывает на двух этапах:

• Напоминание о чекине при ≥80 % от inheritDelay: «Таймер чекина вашего хранилищаใกลжается к исчерпанию.» Уведомление уходит во все подключённые каналы — Telegram-бот, электронную почту и Web Push.
• Наследование активировано: когда age >= inheritDelay и autoInherit = 1, вотчер транслирует транзакцию inheritAuto и уведомляет наследника по электронной почте, сохранённой при регистрации.

Поскольку inheritAuto — бесключевой сценарий, вотчер может транслировать его, не владея ни одним приватным ключом. Выходы транзакции полностью определяются скриптом ковенанта. Даже если серверы Kaspa Forge отключатся навсегда, любая сторона, обладающая публичными параметрами хранилища, сможет транслировать ту же бесключевую транзакцию с любого узла Kaspa версии 2 и выше.

Полный жизненный цикл хранилища с наследованием

Чтобы увидеть, как наследование вписывается в полную работу хранилища, приведём все семь сценариев расходования:

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

Офлайн-восстановление: смерть сервиса ≠ смерть средств

Критическое свойство мёртвого переключателя — его реализация on-chain. Вотчер Kaspa Forge — это слой удобства, а не зависимость. Если сервис исчезнет:

1. Бесключевые сценарии продолжают работать. Любой, кто располагает P2SH-адресом хранилища и байткодом ковенанта, может собрать и транслировать complete() или inheritAuto() с любого узла Kaspa версии 2 и выше. 2. Резервная копия .age ключ-файла сохраняется. Профиль Desk — включая горячий ключ, тревожный ключ и данные наследника — зашифрован паролем scrypt в ASCII-армированный файл .age. Этот файл совместим с open-source CLI-утилитой age. 3. CLI-утилита vaultctl имеет открытый исходный код. Она собирает любую из семи транзакций хранилища офлайн и отправляет их на любой публичный узел. Набор автотестов хранилища покрывает все 18 проверок контракта.

Механизм наследования переживёт команду, серверы и домен. Правила ковенанта впечатаны в блокчейн.

Объективные ограничения

Ни одна конструкция не обходится без компромиссов:

DAA score ≠ часы стены. inheritDelay измеряется в единицах DAA score, а не в часах или днях. Если хешрейт сети существенно изменится, реальная длительность сдвинется. inheritDelay в 30 дней при текущем хешрейте может растянуться до 33 суток при падении хешрейта или сократиться до 27 суток при его всплеске. Сглаживание DAA с окном в 2 641 блок помогает, но не устраняет дрейф.

Наследник должен быть на связи (в подписном режиме). Если autoInherit = 0, наследнику нужен его приватный ключ и достаточно осознанности, чтобы заявить права. Если контактные данные изменятся после создания хранилища, уведомление может не дойти — хотя on-chain механизм по-прежнему работает независимо от этого.

Один наследник, без частичного деления. Хранилище отправляет всё одному адресу наследника. Распределение наследства между несколькими получателями требует нескольких хранилищ или off-chain договорённостей.

heir = [0; 32] означает отсутствие наследования. Если владелец создаст хранилище, не указав наследника, пути восстановления на случай недоступности не будет — средства фактически заблокированы, если только migrate с обоими ключами по-прежнему возможен.

v3 guard выхода — мягкий. Ковенант контролирует значение outputs[0], но не tx.outputs.length. Специально сконструированная транзакция может добавить дополнительные выходы в рамках лимита feeBudget. Официальные билдеры Kaspa Forge всегда генерируют канонические транзакции с единственным выходом; это ограничение отмечено для аудиторского цикла v4.

Философия проекта: доверяй математике, а не институтам

Паттерн мёртвого переключателя старше криптовалюты на столетия — мёртвые рукояти в поездах, мёртвые переключатели на детонаторах. Блокчейн-версия добавляет два свойства, которых физические аналоги никогда не имели:

1. Правила публичны. Любой может изучить байткод ковенанта и проверить условия наследования. Нет скрытого исполнителя, нет тайной поправки к завещанию. 2. Исполнение автоматично. Никакого судьи, никакого наследственного суда, никакого письма от юриста на биржу. Когда таймер истекает и условия выполнены, блокчейн исполняет правила.

Это не заменяет наследственное планирование — смарт-контракт не подаст свидетельство о смерти и не пообщается с налоговой. Но он решает узкую техническую задачу — *как именно движутся деньги* — не вводя кастодиальное доверие. Для сторонников самостоятельного хранения KAS это та часть, которая действительно важна.