Proof-of-Work и самостоятельное хранение: как Kaspa создаёт инструменты без доверия

Самостоятельное хранение — это бинарное свойство: либо вы контролируете свои ключи, либо кто-то другой контролирует ваши деньги. Проблема в том, что «сырое» самостоятельное хранение даёт контроль, но лишает защитных механизмов. Аппаратный кошелёк защищает вашу сид-фразу, но не может наложить задержку на вывод, обозначить кражу в процессе или передать активы наследнику, если вы исчезнете. Исторически эти правила требовали участия кастодиана — биржи, Telegram-бота для эскроу, мультисиг-платформы — что вновь вводило то самое доверие, от которого самостоятельное хранение должно было избавить.

Подход Kaspa — вписать эти правила *непосредственно в UTXO*, обеспечив их выполнение каждым полным узлом сети. Хардфорк Toccata активировал поддержку ковенантов в основной сети, а протокольный proof-of-work blockDAG выступает слоем финализации. В результате получаем программируемые деньги, не зависящие от какого-либо сервера в применении своих правил: хранилище с задержкой вывода, эскроу, направляющий средства только именованным сторонам, аварийный таймер, активирующий наследование, — всё в блокчейне, всё с самостоятельным хранением.

В этой статье рассказывается, как протокольный слой (GHOSTDAG, DAA, PoW) и слой контрактов (ковенанты Toccata на Silverscript) вместе делают возможными инструменты без доверия, а затем показано, как Kaspa Forge применяет этот стек на практике.

GHOSTDAG: упорядочивание блоков без их осиротения

Kaspa — это proof-of-work blockDAG, а не линейная цепочка. Вместо одного блока, наращивающего вершину каждые N секунд, несколько майнеров могут публиковать блоки одновременно. Протокол GHOSTDAG классифицирует каждый блок как синий (хорошо связанный, вносящий вклад в безопасность) или красный (слишком запоздавший для надёжного упорядочения), а затем выбирает «избранную цепочку» из цепочных блоков, чья совокупная синяя работа определяет канонический порядок.

Из любого цепочечного блока C набор слияния — это множество блоков, находящихся в прошлом C, но не в прошлом избранного родителя. GHOSTDAG сортирует этот набор слияния по синей работе (при равенстве — по хешу), и именно этот порядок определяет, какие транзакции принимаются и в какой последовательности. Виртуальный блок — локальный указатель узла на все текущие вершины — имеет собственного избранного родителя (избранную вершину), а проход по ссылкам «избранный родитель» вниз отслеживает избранную цепочку.

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

Для самостоятельного хранения в Kaspa вывод прост: слой финализации на PoW не требует разрешений и неизменяем. Ни одна инстанция не может заморозить UTXO, отменить подтверждённую транзакцию или в одностороннем порядке изменить правила консенсуса. Ковенант, развёрнутый в blockDAG, столь же необратим, как proof-of-work, который его погреб.

Полная спецификация протокола доступна в вики Kaspa.

Ковенанты Toccata: правила расходования внутри UTXO

Обычный P2PK-адрес говорит: «кто обладает закрытым ключом, тот может потратить это». Ковенант добавляет: «кто обладает закрытым ключом, тот может потратить это, *но только* на адрес X, *только* после задержки, *только* если транзакция имеет ровно один вход». Это ограничение проверяется каждым узлом — никакой сервер, оракул или оффлайн-подписант не требуется.

В Kaspa ковенанты были активированы хардфорком Toccata и пишутся на Silverscript (текущая версия ^0.1.0). Скомпилированный скрипт встраивается в P2SH-адрес. Когда транзакция расходования поступает в сеть, узел оценивает ковенант в соответствии с фактической структурой транзакции — входы, выходы, подписи — и отклоняет всё, что нарушает правила.

Именно этот механизм делает самостоятельное хранение в Kaspa программируемым. «Программа» выполняется не на сервере, которому вы вынуждены доверять, — она выполняется в рамках проверки консенсуса, которую каждый полный узел проводит самостоятельно.

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

Ядро Kaspa Safe — единственный ончейн-контракт, vault.sil. Хранилище имеет два состояния — VAULT (обычный режим) и UNVAULTING (вывод в процессе) — и семь путей расходования:

Два инварианта защищают каждый UTXO хранилища:

Ограничение на единственный вход. Каждый путь начинается с require(tx.inputs.length == 1). Это закрывает вектор утечки, при котором два UTXO на одном P2SH-адресе делят один выход транзакции — избыток меньшего UTXO утекал бы в комиссию майнеру. С принудительным единственным входом каждый UTXO хранилища расходуется независимо.

Лимит бюджета комиссии. Шесть из семи путей применяют feeBudget > 0 && feeBudget <= 10_000_000 сомпи (0,1 KAS). Это предотвращает саботажную атаку, при которой наблюдатель или третья сторона транслирует путь без ключа (complete, inheritAuto) с балансом хранилища, сжигаемым в качестве комиссии майнеру. Единственное исключение — migrate, который требует оба ключа: владелец несёт полный контроль и полную ответственность.

Сигнальное значение heir = 32 нулевых байт полностью отключает наследование. Когда наследование активно, ровно один из двух путей наследования работает (автоматический *или* подписанный, но не оба одновременно). Пути без ключа может транслировать кто угодно — средства направляются туда, куда указывает ковенант, независимо от того, кто подал транзакцию.

Эскроу: десять путей, ни одного стороннего получателя

Тот же паттерн ковенантов распространяется на P2P-сделки. Kaspa Escrow использует escrow.sil с тремя именованными открытыми ключами (покупатель, продавец, арбитр) и десятью путями расходования. Ключевой инвариант дизайна: ни один путь расходования не позволяет отправить средства кому-либо, кроме покупателя, продавца или указанного адреса для комиссии. Арбитр, разрешающий споры, может лишь разделить средства между двумя сторонами или направить 100% одной из них. Физически невозможно перенаправить средства куда-либо ещё.

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

Вместе контракты хранилища и эскроу определяют 17 точек входа, все с ограничением на единственный вход и 16 из 17 — с лимитом бюджета комиссии.

Как Kaspa Forge реализует это на практике

Kaspa Forge — это прикладной слой, делающий эти контракты удобными. Три инструмента используют единый зашифрованный браузерный профиль (Desk):

Kaspa Safe — интерфейс хранилища. Мастер создания генерирует ключи в браузере через WASM-ядро (kaspa-safe-core), компилирует контракт на Silverscript с выбранными параметрами (задержка, тревожный ключ, наследник, режим наследования, бюджет комиссии) и формирует P2SH-адрес для депозита. Закрытые ключи существуют только в зашифрованном браузерном профиле — сервер получает открытые ключи и подписанные транзакции, но никогда не видит сид-фразы и секреты.

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

Kaspa Escrow применяет ту же архитектуру к P2P-сделкам. Средства находятся в контракте escrow.sil, а не у посредника. ИИ-медиатор выносит не имеющие обязательной силы вердикты, анализируя зашифрованную переписку (сквозное шифрование через протокол Kasia — сообщения закрепляются в blockDAG в виде транзакций ciph_msg:). Человек-арбитр подписывает обязательные решения оффлайн-ключом. Сервер пересылает зашифрованные данные, но никогда не видит открытого текста.

Desk связывает всё воедино: единый HD-зашифрованный профиль, содержащий ключи для хранилищ, сделок и кошелька — все они выводятся из одного мастер-сида через HMAC-SHA512. Профиль зашифрован пользовательской парольной фразой в виде key-файла .age, совместимого со стандартной утилитой age. Одна резервная копия покрывает все будущие хранилища и сделки, созданные из этого сида.

Восстановление без сервиса

Самый строгий тест некастодиальной архитектуры — что произойдёт, если сервис исчезнет? Ответ Kaspa Forge многоуровневый:

1. Key-файл .age + парольная фраза — зашифрованный профиль, расшифровываемый оффлайн любым совместимым с age инструментом. Содержит мастер-сид и все параметры хранилищ и сделок. 2. CLI-утилита vaultctl — бинарный файл на Rust с открытым исходным кодом, который реконструирует и транслирует транзакции хранилища через любой узел Kaspa версии 2 и выше. Тот же исходный код Silverscript (vault.sil) встроен в бинарник и опубликован на GitHub. Самотестирование: 18 из 18. 3. recover.html — одностраничное веб-руководство по оффлайн-восстановлению.

Контракт — это источник истины. Сервер — это слой удобства. Если сервер исчезнет, контракт останется в blockDAG, а CLI сможет взаимодействовать с ним напрямую.

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

Самостоятельное хранение на основе ковенантов не обходится без издержек:

• Вычислительный бюджет. Контракт хранилища допускает COMPUTE_BUDGET в 20 единиц для стандартных путей и 30 для migrate (единственного пути с двойной проверкой подписи). Это ограничение, применяемое узлом, работает в текущем виде, но сужает объём логики, который можно вложить в один ковенант.

• Бета-лимиты. Kaspa Escrow ограничивает размер сделок диапазоном 50–10 000 KAS на этапе бета-тестирования. Ниже 50 KAS комиссии за разрешение споров поглощают более 10% суммы сделки. Выше 10 000 KAS соотношение риска и вознаграждения при использовании неаудированного контракта оправдать сложнее.

• migrate требует оба ключа. Запасной выход полного владельца из хранилища нуждается одновременно в горячем *и* тревожном ключах. Это означает полную власть, но компрометация обоих ключей — мгновенная и невосполнимая потеря. Дисциплина разделения ключей обязательна.

• Без оракулов, но не без рисков. Ковенанты применяют правила в коде. Если в коде есть ошибка — или если параметры (задержка, адрес наследника, бюджет комиссии) заданы некорректно — службы поддержки, которая могла бы это отменить, не существует. Лимит feeBudget в 0,1 KAS защищает от саботажа, но не от ошибок владельца в конфигурации.

• Зависимость от наблюдателя для оповещений. Ковенант обеспечивает выполнение правил без какого-либо сервера, но слой *оповещений* (Telegram, электронная почта, веб-пуш) работает на инфраструктуре Kaspa Forge. Если сервер недоступен, у вас по-прежнему есть всё окно задержки для действий — но вы не получите уведомление через наши каналы.

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

Всё это — не оговорки мелким шрифтом в сносках, а форма самого дизайна. Финализация на proof-of-work плюс ковенанты Toccata дают программируемость без доверия, но «без доверия» означает, что код *и есть* контракт. Вы — аудитор, оператор и хранитель ключей. Kaspa Forge — это инструмент, а не гарант.